Security Considerations for Computerized Patient Records and Data Interchange
National Committee on Vital and Health Statistics
Testimony for August 6th, 1997
Carl Dvorak
Vice
President & Head of Research and Development
Epic Systems Corporation
Madison,
Wisconsin
Thank you for affording me the opportunity to present our views on this important topic today.
Epic develops software for large integrated healthcare delivery systems, managed care organizations, medical groups, and hospitals. Our systems include Computerized Patient Records, Managed Care, Appointment Scheduling, and Patient Accounting.
Epic developed its first clinical systems in 1979. In early 1993 we released the Windows-based EpicCare Computerized Patient Record. This was the first robust Windows-based Computerized Patient Record System for production use in large organizations. Today there are approximately 13,000 licensed EpicCare users, giving EpicCare one of the largest user bases of any ambulatory CPR. EpicCare also has one of the single largest CPR sites: almost 800 providers, plus several thousand trained users, all sharing common patient information and last year processed over 2.5 million patient encounters and over 5 million orders online.
Epic believes that a medical records system should protect the confidentiality and privacy of patient information. A computerized system can in many instances provide higher levels of security than possible with conventional paper records. Audit trails can show how and when records are accessed and the types of information accessed, the computer can deny inappropriate access, etc. Through improper management, however, computerized systems can provide a fast and efficient means to compromise the privacy of hundreds of thousands of patients in a single incident. Efficiency not possible with traditional paper records.
We, as well as any other vendor or healthcare organization, have at our disposal an excellent set of policies and implementation details to chose from in order to provide excellent security and privacy. Most responsible vendors already adhere closely to guidelines created, summarized and published by such groups as CPRI, NRC, AHIMA and others. We recommend the committee utilize this existing work to its fullest.
Epic supports server platforms that conform to "C2" level security, many of which can be configured to "B2" levels.
Internal and external security auditors have reviewed our systems from both a features and use perspective at several large organizations over the last several years. The most common findings from these audits were procedural in nature including issues like retiring of user accounts for persons no longer employed.
With the introduction of medical information systems, especially when with a Computerized Patient Record, Epic recommends that healthcare organizations define the role of an Application Security Administrator. This person's job would be to manage all of the security aspects of these applications, with a defined support commitment from technical, legal, and user communities. This Security Administrator should have a high level of competence in the information systems area and in the medical field.
One of the most significant problems we find when installing medical systems is that customers struggle to clearly understand what kind of information they should protect from whom. We generally work in a consultative manner with our customers to help them develop and implement security policies and procedures. Although most misuse of computerized medical data is via internal access, both internal and external incidents can be equally damaging and require planning to avoid.
We generally characterize security needs in the following categories:
Each organization should maintain a policy on password management and login use. Users should be required to identify themselves before gaining access to the system, and while using the system, in a manner similar to that in which they identified themselves on paper, by signing orders and medications as they are placed.
A password-management module should support a standard set of password-aging and format rules such as minimum password length, password history rules (to control re-use of passwords) and presence of non-alpha characters. However, the rules should not be so stringent that they backfire. A password that is too complex to remember will often be written on a Post-It note and attached to the clinician's monitor.
Other emerging technologies may be helpful in providing access to medical data. These include biometrics devices (e.g., thumbprint, voiceprint) and one-time password generators.
It is important that access controls not encumber clinicians to the extent that, to avoid the inconvenience of re-identifying themselves, they leave devices signed on to the system in an insecure state. Even with session time outs, unattended devices represent the most common means for inappropriate access to any system.
The development of a security classification database is critical to the implementation of an acceptable security system. These classifications represent a mesh between job function and user access permissions. Users should be assigned a security classification for each job function or unique role they play in the healthcare delivery process.
Every healthcare organization is unique and therefore systems should provide flexibility in the setup and definition of the user security classifications.
In a paper world, run by people, exceptions can be explained, understood, and acted upon, at least most of the time. In a computerized world, provisions need to be employed that allow users to manage the exceptions that can arise in critical patient care areas. Appropriate security overrides are needed, so that, in cases where medical necessity dictates, users can override the often rigid security structures employed in a CPR. Most often these override mechanisms employ a dual user sign off, a statement of justification for the access, and a supervisory notification system.
Each organization needs to create and clearly communicate a common definition of sensitive information. This varies from state to state and even between facilities within a state.
This can be a complex area, due to the potential inference issues when studying medical data. For example, a pattern of pneumonia prophylaxis may be indicative of HIV. Based on this pattern, a user can suspect the presence of HIV without ever having access to the patient's problem list.
A medical data system should provide security that prevents viewing of orders and encounters that have been marked as sensitive, by anyone other than the providers responsible for the orders or encounters, or their supervisor (if a resident), or their designated proxies.
The ability to secure tests and encounters should be available on demand, for use in cases where a patient requests that information be held confidential and not be available for use as part of the patient's general medical record.
Careful monitoring of user access to information should be implemented. Periodic reviews of access to information may be used to identify inappropriate access patterns.
A CPR should provide a comprehensive audit trail of all user accesses to modules for each patient. This audit trail should include the user ID, date and instant of access, module accessed, and operation performed.
This information should be accessible easily by either patient or user. Patients should have the ability to request a listing of all users who have accessed their medical records. Having audit trail information indexed by patient would provide that information. Organizations may also want to consider a process to provide the patient with an explanation of what information was accessed and for what purpose. The ability to monitor access by individual users will help an organization identify patterns of inappropriate access.
This deferred method of user monitoring can play an important role in managing access to information. Clearly, real time checks should and do prevent obvious breaches of security. But there are situations where it is not clear whether or not a provider has legitimate need to access the information. This is especially common in large facilities where providers cover for each other frequently or rotating staff provides service.
Audit trails not only provide a deterrent to misuse of data, they also provide an important mechanism to allow organizations to discover new techniques for the misuse of data.
In many situations it is necessary to "re-validate" the user who is placing an order or updating a chart, to ensure that an unauthorized party is not using another person's unattended workstation. The re-validation verifies that the original user is the person placing the order, by requesting his or her user ID and password.
A CPR should also support co-signatures, which can be optionally required for controlled or non-controlled medications, and for other order types such as lab tests and referrals. The co-signature requirement should be configured for each security class. A co-signature should be generated when a user orders a medication, and that user's security only allows co-signature medication orders places. The user should be prompted to specify an authorizing person, who will in turn receive an electronic co-signature request.
Attempting to place orders for controlled substances can be one of the more common misuses of clinical systems.
Organizations need to consider appropriate physical security measures, including procedures and policies for printers, workstations, remote networks, and modem access.
Operating systems provide various levels of protection against unauthorized logins via dialups or remote access. Dial-back modems and password-protected remote access servers are two common "front ends" that provide remote-access security for a medical information systems.
Printers should be thought of as photocopiers in a medical-records room. Access to printers must be controlled and output distribution should be regulated and managed.
Standard procedures should be followed to guarantee the integrity and availability of the computer systems including backups, highly available configurations with failover provisions and disaster recovery planning.
A major difference between a computerized environment and a paper environment is the accessibility of large amounts of data. This access provides one of the most significant benefits to automating patient records. At the same time, it represents the greatest potential danger to patient privacy. A single breach of security in this area could compromise the privacy of thousands of patients in literally minutes.
Malicious use of a large volume of data by an employee or an organization is an obvious misuse of data. This should be punishable by law.
Data for use in analysis should be scrubbed before allowing access. The scrubbing techniques might include encoding patient identifiers with a special report key. Users would be able to study the reports, but not obtain any patient specific data without obtaining the report key. Access to report keys could be controlled administratively by internal review boards.
It is important to realize that there can also be security issues with the use of aggregate data, especially when trying to prevent access to information about a particular patient. A user can take data elements that are, in general, considered available for anonymous analysis, and combine them with other information the user possesses, to synthesize a reasonably accurate assumption. For example, if you know a friend of a certain age, gender, ethnicity and physical dimensions was seen in a certain facility by a certain provider at a certain time for a certain complaint, you may be able to obtain the detail for that encounter, even if the encounter has been stripped of all patient-specific information.
The Internet plays a key role in the future sharing of healthcare patient data. Internet-based approaches will likely be more popular than point-to-point, interface-based sharing of data through traditional means such as HL7.
Information will not only be shared with other healthcare providers, but also with patients themselves. This provides a unique opportunity for improved service and outcomes for patients who participate in their own care via an Internet-enabled CPR.
The Internet security area is experiencing vast investments in technologies to exploit the potential for electronic commerce. The array of technology developed for general Internet use will likely allow for the use of medical data to be safely extended across the Internet.
Security considerations are naturally of paramount importance for our extranet modules. We plan to provide multiple security mechanisms in addition to the extensive security controls already implemented within the core application. These additional measures include insuring basic authorization and authentication via isolated Extranet user identifiers and access codes; and providing extensive audit trails of Extranet access. In addition we provide confidentiality via SSL. We will employ a web-server Verisign certificate and, for clients who wish to use them, client-side certificates. We expect to adhere to additional low-level security standards as they are adopted by the IETF.
We recognize that our clients' security policies and technology standards will vary significantly, and for this reason we plan to provide mechanisms that will allow our clients to employ additional security mechanisms of their own -- for example, Smart Cards, Certificates, Kerberos, and Virtual Private Networks.
Third parties such as electronic commerce clearinghouses and reference laboratories or other testing agencies have traditionally provided adequate protection for data through use of secured internal systems and private networks.
For any potential transmission over public networks or the Internet we recommend simple and effective security measures such as PGP file level encryption be used.
The largest potential for compromising data when dealing with a third party is typically not the transmission of the data to the third party, but rather how well the third party manages their responsibility for that data once they have it.
In light of the recent legislation and the timeframe specified therein, the government could play many key roles in defining security guidelines for healthcare. We suggest consideration be given to the following:
In summary, we think it is important to remember that a simple standard that is theoretically less secure, but widely implemented, will likely protect more patients than a complex standard that is theoretically more secure but not widely implemented. We would hope that simplicity of implementation and management is given a high priority as recommendations are presented.
Epic appreciates the opportunity to have participated in this process and extends an invitation for further discussions in this area, as the committee may feel appropriate.