System Certification FAQs


This document reflects current work-in-progress responses to frequently-asked questions of information security and related areas. Over time, some elements may get pushed to the appropriate Columbia University Policies and Procedures; however, this document should never be considered authoritative!

Q1: What is a “System”?

A1: The current, work-in-progress definition is:
A System is a multi-user application or service used for University purposes which resides on one or more computing device(s) and transmits, stores, or processes University data. Any business process and/or application running on a Server is a System. Individual Endpoints are not considered Systems, unless they are performing Server functions.

With the formalization of the System Certification program, and the recent requirements to charge CUIMC Certified IT Groups annually for information security services based on the number and type of Systems, this was developed to more clearly define a System (CUIMC System). Historically, the term System had been intentionally defined somewhat vaguely with the idea that IT professionals and departmental administrators would work together in the specific business context to decide what is and isn’t part of a given System.

In the context of the Information Security Office, this definition of System is used to drive System Registration and Risk Assessment.

Q2: What is a “Server”?

A2: The current, work-in-progress definition is:
A Server is a computer that provides a service to other computers, such as processing communications, file storage, or accessing a printing facility. There are many types of Servers including web, database, application, authentication, DNS, mail, proxy, and NTP Servers.

References

Q3: What is a “Modality”?

A3: The current, work-in-progress definition is:
A Modality is a type of medical data acquisition device, such as X-Ray, MRI, or ophthalmology imaging device, which is used in patient care. Medical devices that collect, maintain, and/or communicate ePHI must be in compliance with HIPAA rules.

The word “modality” has evolved and now shows some variability in meaning, according to various authoritative sources, see below. Note that Dr. Elliot B. Sloane of Drexel University Health Systems, at the NIST-OCR HIPAA Conference 2010, pointed out that “Medical devices that collect, maintain, and/or communicate ePHI are covered by HITECH!”

References
For further interest, the following sources provide their respective definitions of “modality”:

  1. The American Heritage® Medical Dictionary:  “A therapeutic method or agent, such as surgery, chemotherapy, or electrotherapy, which involves the physical treatment of a disorder.”
  2. HL71 V2.5 Section 4.5.6.5: “The type of equipment requested to acquire data during performance of a Procedure Step. The acquired data will be used to create the images for the Imaging Study corresponding to the Requested Procedure."
  3. Wikipedia ("http://en.wikipedia.org/wiki/Modality"):  "In medical imaging, any of the various types of equipment or probes used to acquire images of the body, such as radiography, ultrasound and magnetic resonance imaging."
  4. DICOM2: “Type of data acquisition device.”

1 “Founded in 1987, Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.”

2 “DICOM — Digital Imaging and Communications in Medicine — is the international standard for medical images and related information (ISO 12052). It defines the formats for medical images that can be exchanged with the data and quality necessary for clinical use. DICOM is implemented in almost every radiology, cardiology imaging, and radiotherapy device (X-ray, CT, MRI, ultrasound, etc.), and increasingly in devices in other medical domains such as ophthalmology and dentistry…Since its first publication in 1993, DICOM has revolutionized the practice of radiology, allowing the replacement of X-ray film with a fully digital workflow.”

Q4: Is a modality considered to be a System? 

A4: Yes, although a set of modalities may be considered a single System if they perform the same function and are managed in the same way.

Q5: Three of us use a web/database/file/etc. application that runs on a workstation under my desk. Is that considered a System? 

A5: Yes, the fact that a networked or multi-user application is being run on desktop hardware does not mean it does not qualify as a System. Any computing device performing multi-user functions is considered a server, and therefore this would be considered a System.

Q6: How and when can multiple components be grouped together as a single System group?

A6: First, a single System may include multiple Servers, e.g., a database, application, and web Server for a web-based application System; SMTP Servers for a mail System; FTP Servers for general file transfer System; etc.

The term “System Group” extends this concept, principally for IT infrastructure services, where a set of inter-related IT components are configured and managed as a System providing IT services. For example, a load balancing Server and a virtual hypervisor supporting a Virtual Machine environment may be treated as a single System Group.

Q7: If a Server hosts more than one application, is it a single System or multiple Systems?

A7: This depends on the nature of the applications and the technical and operational/business process controls that are in place. On the technical side, multiple applications on a single server are probably managed using the same IT procedures and resources, which would argue that they be considered a single System. However, if one application is used to store patient information (ePHI), and another has no sensitive or confidential data at all, it may make more sense to treat them separately. Further, if the different applications are used by different people performing different functions, then logical access controls such as user authorization are probably managed by different System Owners with different requirements, which would argue that be considered to be multiple Systems.

Q8: Are the charges the same if a System has multiple Servers? 

A8:  Yes, there is one charge for the System, independent of how many Servers are involved. Remember that this is an annual charge which is based on an overall cost-recovery for information security to help ensure the continuous safety of CUIMC Systems.

Q9: When do I have to notify ISO about a new System and what does ISO need to know?

A9:  For purchased Systems, the initial notification to ISO will typically coincide with the submission of the purchase requisition. Before it can be approved, the purchase requisition must include the System ID, which is a 4-digit number generated when the System has been registered in RSAM. For a System being developed internally, it is usually appropriate for the System to be registered once the initial design has been developed.

Registration of the System entails providing basic information in RSAM on various Attributes of the planned System, such as software and vendor information, where the System will be hosted and how it will be supported, etc., as well information about various Criticality Factors associated with the System, such as whether the System will be accessible by the outside world over the Internet, or if it will house Protected Health Information (ePHI). Thereafter, any time there is a significant change in the nature of the System, and at least annually, the RSAM Registration should be reviewed and updated as needed.

Q10: What happens when a System is registered and risk assessed?

A10: Once the System Owner and IT Custodian (collectively, Stakeholders) have Registered the system by completing the Attribute and Criticality information in RSAM and submitted the Registration to ISO, the ISO Risk Analyst reviews the information to gauge the level of information security risk.

There are five Risk Triage Ratings: Critical, High, Medium, Low, and Minimal. Systems rated as Low or Minimal are classified in RSAM workflow as “41 Reviewed” or "43 Inventoried".

All others are classified in RSAM workflow as “03 Controls Self-Assessment”, and the Stakeholders are notified that there are additional questions about controls in and over the System that need to be answered in RSAM. Based on the responses to those questions, follow-up discussions with the ISO Risk Analyst(s) assigned, and the results of a scan for technical vulnerabilities (internal systems only), an Information Security Risk Assessment report is generated. The report contains the findings from the assessment, recommendations for each finding, and a timetable for remediation based on the severity of the findings. All findings must be remediated within 90 days.

The report is peer-reviewed by the ISO Risk Assessment team, and when approved by the CISO, distributed via email to the Executive Sponsor and all Stakeholders listed in RSAM. Once distributed, the remediation timetable is in effect.

In the case of a new System, a Pre-Implementation Risk Assessment can be performed when the System is installed and relatively stable, but well before production migration. The Assessment provides the System Owner and IT Custodian with an analysis of potential security risks that generally should be resolved before the System goes live. For internally hosted Systems, a scan for technical vulnerabilities will be conducted; any vulnerabilities identified will need to be resolved before the System may go live. Once the System is implemented and ready for Production, the System Owner and/or IT Custodian should update the RSAM Registration to reflect the details of the actual implementation of the System and notify ISO the System is being prepared to go live.

Q11: What do I need to provide ISO when I decommission a System?

A11:  ISO requires evidence that all components of a decommissioned System have been removed from the production environment. For example:

  1. A completed IT tracking ticket showing the decommission activity was completed is required. This may be a ticket in ServiceNow, or it may be a ticket from the IT Custodian.
  2. The IT tracking ticket and other available evidence should show that:
    1. The System’s data (files and databases) have been removed from the production Server and archived (if necessary) with appropriate access controls;
    2. The software has been removed from the production Server and the software inventory updated to remove the application; and
    3. The IP address has been disabled and associated URLs (if any) removed from the DNS.
  3. If equipment is being retired, recycled, or removed from the premises, evidence is required that data on the equipment has been removed or erased, and the hardware inventory has been updated to account for the equipment.

Q12: How can I see all of the Systems registered in RSAM for my department?

A12:  Use the following steps to get a report of all Systems registered for a department:

  1. Log in to RSAM (https://rsam.cumc.columbia.edu)
  2. Click tab “1.0 System Inventory”
  3. Click sub-tab “1.3 System Inventory by Business Unit”
  4. Select Your Business Unit from the pull-down list.
  5. Click “View Report”. The report may have multiple pages, and may be downloaded into a number of common formats (CSV, Excel, etc).

Q13: How do I correct a mistake or delete a duplicate entry in RSAM?

A13:  Once a System has been successfully Registered, the RSAM questionnaire is “locked down” to prevent any further changes. If changes are needed to a Registered System entry, or a duplicate record removed because it was created by accident, the Registrant, System Owner, or IT Custodian can send a request in an email to security@cumc.columbia.edu. Be sure to provide the System ID (4-digit RSAM number) in the request.

Q14: Does the HIPAA audit-log requirement apply only to source-system formal EHR's or also to secondary research databases?

A14:  It applies to anything that is EPHI, that is, covered by HIPAA. HIPAA does not care about system of record.

Q15: What is the current policy on using database packages like MS Access?

A15:  There is no formal CUIMC statement, but if there is only one user on a desktop, it is essentially an endpoint and so must meet CUIMC security requirements (encryption with pre-boot authentication, attached to a domain controller, etc.). Multiuser MS Access databases must be housed on a certified RSAM System that meets server-room requirements, etc.

Q16. Do users accessing HIPAA-protected data have to be logged and an audit trail for all events? 

A16:  Yes. Certified IT Groups are charged to comply with CU policy for Information Resource Access Control and Log Management, which requires the following:

“D. Log Management Each System Owner and IT Custodian must ensure that the following protections are implemented for each Information Resource that processes, transmits or stores Sensitive Data:

  1. Logging is activated on each Server.
  2. Logging is configured to keep track of access to Systems, Data and the Server itself.
  …
  8. Logs have audit mechanisms that generate reports of auditable events such as:…”

EPHI is a subset of Sensitive Data.  The “such as” list of events included later is provided as an example, not as a comprehensive list.

References:

Q17: How do I know if a system needs to be certified?

A17:  System with any of the following properties must be certified: