Figure 1: The CareWebTM Architecture
John D. Halamka MD1, Peter Szolovits Ph.D2, David Rind MD1, Charles Safran MD,MS1
1Department of Medicine, Beth Israel Deaconess Medical Center and the Center for Clinical Computing, Harvard Medical School, Boston MA
2
Laboratory for Computer Science, MIT, Cambridge, MA.This is a paper published as:
Halamka, J., P. Szolovits, D. Rind, et al. (1997). "A WWW implementation of national recommendations for protecting electronic health information." J Am Med Inform Assoc 4(6): 458-464.
Funded in part by a cooperative agreement with the Agency for Health Care Policy and Research and the National Library of Medicine, Sharing Paperless Records among Networks of Providers (U01- 08749), and the Douglas Porter Fellowship, Center for Clinical Computing, Harvard Medical School.
In March of 1997, the National Research Council (NRC) of the National Academy of Sciences issued the report "For the Record: Protecting Electronic Health Information". Concluding that the current practices at the majority of health care facilities in the United States are insufficient, the Council delineated both technical and organizational approaches to protecting electronic health information. At the Beth Israel Deaconess Medical Center we recently implemented a proof-of-concept, web-based cross-institutional medical record, CareWebTM which incorporates the NRC security and confidentiality recommendations. We report on our WWW implementation of the NRC recommendations and an initial evaluation of the balance between ease of use and confidentiality.
Keywords: Internet, Security, Confidentiality, Electronic Medical Records
In his 1997 state of the Union address, President Clinton noted that "we should connect every hospital to the Internet, so that doctors can instantly share data about their patients with the best specialists in the field."[1]. The security and confidentiality implications of web-connecting the nation's clinical data are a major impediment to realizing this noble goal.
In 1995, the National Research Council of the National Academy of Sciences was charged with evaluating the practical measures that can be used to reduce the risk of improper disclosure of confidential health information while providing justified access to those interested in improving the quality and reducing the cost of care. Their March 1997 report, "For the Record: Protecting Electronic Health Information" presents the findings of two years of collaborative investigations and site visits.[2]
The report reviews the public policy context, the internal and external threats to organizations which possess health information and outlines technical and organizational approaches to protecting health information.
We implemented all of the technical recommendations of the report in the context of CareWebTM, a proof-of-concept web-based multi-institutional medical record which integrates the Beth Israel and New England Deaconess Hospitals. Creating such a system presented many issues, both technical and political.
The NRC recommended eight technical practices for immediate implementation and five for future implementation. We found that the these thirteen recommendations provided the foundation on which to design a robust security architecture and chose to implement and evaluate them using CareWebTM.
The NRC recommendations are separated into two categories, practices for immediate implementation and practices for future implementation. This discrimination is made with the assumption that the immediate practices will suffice as a minimum for the current state of technology. However, as more health information is available in electronic form and as more security technology becomes generally available, the need for more complete security implementations becomes necessary.
Individual Authentication of Users. The NRC site visits discovered that many health care organizations have generalized login usernames/passwords such as MD for physicians and RN for nurses. To properly authentic individuals on any computer system containing health care data, every individual should have a unique username/password for access. Such a policy allows individuals to be held accountable for all actions taken while logged on.
Access controls. Many healthcare computing systems allow all users to view all information. There is, however, no good reason for a laboratory technician to read the confidential full text data contained in a patient psychiatric profile. Healthcare providers should be allowed to view clinical information on a need to know basis. The most obvious implementation of such controls would be to assign access to different healthcare computing functions based on job role.
Audit trails. Although newspaper articles highlight the threat of computer break-ins by unauthorized "hackers" from outside healthcare organizations, inappropriate healthcare data access from inside the organization is far more common. Normal human curiosity leads individuals not involved in a patient's care to lookup the records of VIPs, celebrities and fellow employees. If authenticated users are to be held accountable for actions taken while using the health care computing system, retrievable audit trails that log all accesses to information should be kept. These logs should include time, date, information accessed, and user ID. Audit trails should be available for patient review on demand.
Physical Security and Disaster Recovery. Computer terminals should be positioned where they cannot be accessed by unauthorized users. Unauthorized personnel must be denied access to paper printouts and electronic storage. Backup tapes should be made frequently and tapes should be housed off-site in the case of a physical disaster.
Protection of remote access points. Firewalls should be implemented to provide strong, centralized security and to allow outside access to only those systems critical to outside users. All remote accesses should be protected by single session or encrypted passwords.
Protection of External Electronic Communications. All patient-identifiable data transmitted over public networks should be encrypted.
Software Discipline. Virus checking programs should be installed on all servers and downloads from the internet to servers should be limited.
System Assessment. Audits should be performed on a monthly basis to examine vulnerability to password cracking programs and to verify procedures implemented to detect system vulnerabilities.
Strong Authentication. Healthcare providers occasionally share usernames/passwords or write them down near a computer terminal. Such practices defeat the authentication, access controls and audit trails offered by unique usernames/passwords. Authentication is substantially strengthened by requiring that logon be paired with physical possession of "hardware tokens" such as smartcards, magnetic strip IDs or devices with constantly changing passwords..
Enterprise-wide Authentication. Healthcare environments typically have many heterogeneous computing systems. If users are forced to have different logon information for each computer system, remembering such information is an inconvenience and users will have a tendency to write down login information. To minimize such behavior, users should authenticate once and then have access to all relevant systems.
Access Validation. In the simplest form of access control, different system functions are available based on job role. A more sophisticated implementation would tailor content within functions by job role. For example, a discharge summary could be viewed by both a physician and a billing coder, but details of the patient's psychiatric evaluation would not appear for the coder.
Expanded Audit Trails. Simple audit trails capture information at a single organization. An expanded auditing system would provide inter-organizational audit trails that trace information as it passes thorough the health care complex.
Electronic Authentication of Records. Electronic signature should be used to "sign" submitted medical records and cryptographic digital signature should be used when retrieving records to insure that records are not modified during the transmission process.
We implemented all thirteen NRC recommendations in the CareWebTM system.
The clinical data at the Beth Israel Hospital is stored in a comprehensive, custom built MUMPS based system composed of 28,000 programs. The clinical data at the Deaconess Hospital is stored in a Sybase clinical data repository. CareWebTM unites these systems using an implementation of the W3EMRS architecture. [4,9]
CareWebTM site servers operate behind the web servers of each hospital and create a link to the underlying legacy systems at each institution. These site servers interpret incoming HL7 [5] requests for information, translate them into specific legacy system queries and package the resulting information into an HL7 response.
To allow users to query multiple hospitals simultaneously, we developed a CareWebTM "Consolidator", which processes user requests, dispatches them to multiple hospitals' site servers, and processes the information retrieved (Figure 1).
Figure 1: The CareWebTM Architecture
A typical session begins when a health care provider on a standard web browser creates a query for information by specifying patient identification. This information is submitted via standard HTML forms to the Consolidator. The Consolidator generates an HL7 request for information to both the Beth Israel and Deaconess site servers. The site servers return HL7 encoded demographics, problems, medications, allergies, notes and visits. The Consolidator interprets the incoming messages and creates a single unified presentation which it sends back to the health care provider as a series of web pages. Full navigational control is enabled with tool bars that allow the medical record to be scanned using a tab folder-like paradigm.
To implement the NRC recommendations, we reduced the present and future recommendations to eight action areas: Strong enterprise-wide authentication, access validation, expanded audit trails, encryption of public network transmissions, electronic authentication of records, physical security, disaster recovery, software discipline, and system assessment.
We guarantee the authenticity of each user with Security Dynamics SecurID hardware tokens. These tokens are small, handheld devices containing microprocessors that calculate and display unpredictable codes. These codes change at a specified interval, typically 60 seconds. Our implementation requires that each user accessing CareWebTM begin a session by entering a username, a memorized personal identification number (PIN) and the currently displayed password from the SecurID device. This information is transmitted to a security server which authenticates the user and verifies that the correct password was entered. The security server compares the user-entered password with its knowledge of what password should have been entered for that 60 second period. If the password does not match, it also checks the password from the previous 60 second period to account for delays in typing and transmission. Once a password is verified, the user is authenticated for the entire enterprise for the duration of the web session or 15 minutes, whichever is less. An encrypted security "cookie" is sent back to the user's browser and this cookie is automatically used for all future security dialogs. Using Visual Basic Script and Microsoft's Active Server Pages, we dynamically decrypt the cookie within the web server and invisibly re-verify authentication before responding to additional requests for healthcare data.
If the SecurID token is lost or stolen, it can be immediately deactivated for the entire enterprise by disabling it at the security server.
In addition to storing encrypted username and password information, the security cookie contains the job role of the user. Displays of healthcare information are generated dynamically by Active Server page scripts which assemble the multi-institutional medical record. The scripts can tailor delivered health care information based on the job role indicated by the cookie. In our proof-of-concept implementation, we have restricted this tailoring of access to specific areas of the medical record such as discharge summaries. We have not created a facility to scan for and restrict specific content within an area, such as removing a psychiatric evaluation from a dischange summary.
It has been the security policy of the Beth Israel hospital to provide auditing at the level of the specific patient queried and the individual menu selections used [6]. CareWebTM implements a complete multi-organizational audit trail.
In any multi-institutional architecture there are two places to capture the audit - either at the institutional level where the information is stored (the sites) or at the point where the information is delivered (the CareWebTM "Consolidator"). We elected to capture the information at the site level. Although only a single CareWebTM "Consolidator" exists today, CareWebTM could be expanded such that other regional or national "Consolidators" might query information from the CareGroup institutions. If the audit was captured at the "Consolidator" level, each institution would have to rely on the security practices of the "Consolidator" operators. By storing audit trails at each site, each hospital can control and audit the information that leaves its site, regardless of where it is delivered. Each hospital site server captures patient identification information, requester, the requester's IP address, date, time, and information requested.
Although information is stored at the site level we have implemented a multi-institutional auditing system that provides patients with the details of the movement of their medical information throughout the healthcare enterprise. The auditing query system has the same hardware token authentication and access controls as are required for any CareWebTM healthcare data request. Once authenticated, an auditor enters patient identification information and submits the information to an "Auditing Consolidator". This "Auditing Consolidator" uses secure, password protected Open Database Connectivity (ODBC) connections to query the audit trails of the individual hospitals. It produces a consolidated report showing all flows of information about the patient for all institutions.
The existing legacy systems at the Beth Israel and Deaconess hospitals employ a complex series of hardware controls which limit internet transactions from outside the institution. Using routers and firewalls, network administrators limit legacy system access to hardware devices physically located within the campus.
To create security between a browser running on a user's desktop and the Consolidator web server, we implemented the Netscape standard Secure Sockets Layer [7]. The SecurID username and passcode are only exchanged after an encrypted connection has been established by the Secure Sockets Layer.
For communications between the Consolidator and site servers, we implemented RSA public key encryption for key exchange, session key cryptography for data exchange, and digital signature for authentication of the Consolidator and site servers [8]. This is shown in Figure 2.
Figure 2: Encryption of Public Network Transmissions
Each Consolidator HL7 request is signed with the Consolidator's RSA private key. The request is sent to the site server which uses the Consolidator's public key to validate the digital signature through standard hashing and signature verification methods. The site server retrieves the information requested and signs the HL7 response with its private key. The site server then generates a session key which it uses to encrypt the HL7 response. The session key is then encrypted using the Consolidator's public key. The encrypted session key and encrypted data are sent back to the Consolidator. The session key is decrypted using the Consolidator's private key. The encrypted HL7 response is decrypted using the decrypted session key. Finally, the HL7 response is validated using the site server's public key. All decrypted site server messages are consolidated into a single web page and returned to the original requesting browser over the Secure Sockets Layer.
The use of hardware tokens for system access also facilitates electronic signature. Since possession of the hardware device authenticates the user, the SecurID token is used as the official electronic signature for "signing" all CareWebTM documents and audit trails.
As noted above, digital signature cryptography methods are used for all network transmissions, ensuring the integrity of all health data delivered. The NRC recommends an implementation of hashing and digital signature to insure that medical records are not changed on the individual systems where they are stored. In the CareWebTM architecture we have no control of the integrity of the data stored at each institution. We have created a secure mechanism to transport each institution's data and can guarantee that the data was not changed during the retrieval process. The reputability of the data is dictated by security policies of each institution providing the data.
The notion of a multi-institutional architecture provides significant physical protection for health data. Instead of physically locating all patient records in a central data source which is vulnerable to physical disasters, the CareWebTM architecture depends upon the consolidator which stores no health care information. All that is needed to restore a physically destroyed "Consolidator" system is to connect another computer containing the "Consolidator" software and its required cryptographic keys to the hospital network. Currently, all site servers are geographically dispersed and are locked in secure computer rooms accessed by electronic keycode. In the CareWebTM architecture we have no control of the physical security and disaster recovery practices of the individual sites which provide data. However, if any sites sustain a disaster and cease to provide data, the Consolidator notes that a site is currently unavailable and provides a virtual medical record comprised of all functioning sites.
When deployed in the production environment, the personal computers used to perform CareWebTMlookups will be located at emergency department nursing stations with screens specifically turned away from care areas, as is the standard practice of the medical center.
No browser software is installed on either the site servers or the Consolidator machines, precluding inappropriate downloads. Virus checking programs are in place on all CareWebTM systems and are executed daily by a system daemon.
On the end-user workstation, we have been careful not to cache pages returned by the Consolidator. In our laboratory environment we have verified that neither Netscape nor Internet Explorer cache pages that have been returned via a secure socket connection such as that used by CareWebTM. We cannot protect against an authenticated user who installs a new type of browser that does cache secure pages. However, all pages returned by the Consolidator have an HTML header which indicates that they expire on delivery. Even if a new browser was installed which cached information, this expiration forces the browser to replace each cached page as new requests for information are made, minimizing the amount of information that is stored on the end-user workstation.
Daily assessment is performed on both the Consolidator and site server systems. On the Consolidator, a security log lists all SecurID tokens used, all failed login attempts, and all changes made to the token database. Web server log analysis (WebTrends) shows all attempts to contact the Consolidator web server showing IP address, time, date and page accessed. System assessments are also performed on a daily basis at each institutional site, per their own institutional guidelines.
As an early evaluation of the CareWebTM architecture, we sought and received Institutional Review Board (IRB) approval to web-expose selected medical records from actual patients who have records at more than one CareGroup institution. Patient approval was obtained and patients were allowed to view the CareWebTM versions of their medical record before making them generally available. Furthermore actual patient names and addresses were pseudonymized, but medical information was not altered.
The security architecture was implemented in one man month using standard Microsoft Windows NT architectures and ActiveX components costing under $10,000.
The proof of concept security architecture implementation was web-exposed and the web site processed 3000 requests for health care information with fast response times and high reliability as evidenced by 100% transaction completion on the first request. Reviewing our audit trails and security logs, we found neither unauthorized access nor inappropriate denial of access to the site.
The system was evaluated by 25 healthcare providers, chosen at random from both institutions, who assessed CareWebTM's ease of use, response times and utility in patient care. Further evaluation was performed by 25 information systems staff members who evaluated CareWebTM's robustness, security and potential for deployment in the live environment. Initial reactions to the prototype appear positive.
Further evaluation in a live environment is planned over the next six months. CareGroup is currently extending internet services to all of the Emergency Departments in its healthcare delivery network. After institutional approval, CareWebTM will be made available as an Emergency Department resource.
The political sensitivity of web-exposing confidential data was emphasized in March of 1997 when the Social Security Administration created a publicly accessible web page for display of social security benefits information. The page was discontinued in April 1997 because of outcry from privacy and citizen's rights groups [3].
To protect our web-based medical record system, we implemented all thirteen of the National Research Council's recommendations including those suggested for future implementation. Our architecture includes several innovations for protection of healthcare data. These include the use of hardware tokens for authentication, the use of cryptographic methods for protection of information flows over public networks and the creation of a multi-organizational auditing system.
Although individual elements of the proof-of-concept CareWebTM security architecture have been implemented elsewhere, CareWebTM provides a unique multi-institutional approach. Building on the Beth Israel tradition of providing patient-focused services, we have created a multi-institutional auditing architecture which gives the patient a comprehensive view of all lookups performed in an integrated healthcare delivery system. Such a view maximizes the meaningfulness of the audit trail from the patient's viewpoint as it provides a snapshot of patient information flow throughout the health care enterprise.
We are currently mobilizing the resources to transition CareWebTM from proof of concept to a production system. Issues include administration of security hardware tokens, providing twenty-four hour per day, seven day per week support and obtaining all necessary institutional approvals.
CareWebTM provides a rapidly deployable, low cost architecture which leverages the strengths of existing institutions merging to form an integrated health care delivery system. Current limitations of the architecture are that it does not address the validity of data provided by the individual hospital sites, it relies on the physical security and disaster policies of each site to protect site specific data, and it makes no attempt to duplicate patient data at a central location to use as a secondary resource in case of site failure.
Health care organizations face many threats, both internal and external, to the confidentiality of health care information [9-12]. Technical and organizational practices are needed to insure that critical health information is always available to authorized users and denied to those without the need to know. The balance between ease of use and confidentiality requires careful implementation. Denial of appropriate access to patient records imposed by a failure of the security technology can lead to disastrous healthcare consequences.
Although convenience concerns were raised by a minority of health care providers surveyed, the majority of healthcare providers interviewed were satisfied with the CareWebTM implementation.
To date, the evaluation of the CareWebTM security architecture has been limited to the proof-of-concept system. An expanded evaluation of the deployed version will include detailed feedback from over 50 daily users of the system.
Any technical implementation must be complemented by a strong organizational policy to sanction those who inappropriately access healthcare data. The Beth Israel Deaconess Medical Center has a long standing tradition of protecting patient confidentiality within its legacy systems and organizational policies are already in place. This greatly facilitated the implementation of the CareWeb security architecture and minimized the barriers to implementation which would be found at institutions without such existing policies.
The Health Insurance and Portability and Accountability Act of 1996 (Kassebaum-Kennedy) requires that the Secretary of Health and Human Services submit to Congress, by August of 1997, detailed recommendations on protecting the privacy of individually identifiable health information. The CareWebTM security architecture offers an early trial implementation of several potential strategies.
Our experience with the CareWebTM system has demonstrated the feasibility of using the web to allow access to longitudinal patient record data which is distributed across multiple sites, providers and institutions. We have demonstrated that a security architecture can be built around this system to provide a balance between ease of access to emergency health care data and protecting patient confidentiality. This security architecture builds on the work of others [4,9] to create the first web-based implementation of the National Research Council's recommendations for present and future security practices.
We have learned many valuable lessions during the development of CareWebTM. First, the organizational barriers to deploying a secure web-based medical record can outweigh the technical challenges. Continuing reports of flaws in internet security give a public impression that the web is not a suitable environment for sensitive information and this creates difficulty in obtaining institutional support. Consensus for deploying such a system must include information systems personnel, hospital administrators, public relations and the clinicians themselves.
Secondly, the existing hospital infrastructure provides a strict limitation on the types of technology that may be deployed. Although the Beth Israel Deaconess Medical Center has a campus-wide high speed network infrastructure, many machines are incapable of running the current versions of web browsers, preventing the use of Java and browser-side scripting languages.
CareWebTM will be deployed in the live production environment over the next six months and we will further report on the challenges encountered.