Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 82
--> 4 Technical Approaches to Protecting Electronic Health Information Technological security tools are essential components of modern distributed health care information systems. At the highest level, they serve five key functions:1 Availability—ensuring that accurate and up-to-date information is available when needed at appropriate places; Accountability—helping to ensure that health care providers are responsible for their access to and use of information, based on a legitimate need and right to know; Perimeter identification—knowing and controlling the boundaries of trusted access to the information system, both physically and logically; Controlling access—enabling access for health care providers only to information essential to the performance of their jobs and limiting the real or perceived temptation to access information beyond a legitimate need; and Comprehensibility and control—ensuring that record owners, data stewards, and patients understand and have effective control over appropriate aspects of information privacy and access. Health care organizations evaluate security technologies in terms both 1 Note that these functions—aimed at improving system security—are conceptually different from those that would be required by the work of a database administrator or a network manager.
OCR for page 83
--> of their functional benefits for protecting patient privacy and their costs: the cost of impeding or preventing clinicians from accessing information relevant to their decision making; the cost of purchasing and integrating them into the information system environment; the cost of ongoing management, operations, and maintenance of the evolving information system; the cost of user frustration with suboptimal interfaces and procedures; and the cost of user time lost in satisfying security requirements. They must also attempt to implement a balanced approach to protecting against threats to information security and the risks posed by violations. For example, if there are two equally likely and costly threats—e.g., power outages and insiders divulging information—resources should be allocated to protect approximately equally against these threats.2 Individual technologies vary widely in terms of these cost-benefit characteristics, and as new technologies are developed and reduced to commercial practice, their characteristics change with time. System managers must choose a set of technological interventions that provide effective protection against perceived threats to system security but impose acceptable overall costs. This choice is difficult at best and requires ongoing updates of threat models; evaluations of technologies; reconsideration of integration and operation strategies; and education of management, systems staff, and users. This trade-off almost never includes any direct input from patients—one of the main stakeholder groups whose privacy is at risk—or sometimes even from health care providers—another deeply affected stakeholder group. Patient preferences and utilities are represented only implicitly, and patients can voice their assessment of system design only indirectly by their decisions about where to go for care or by their pursuit of legal redress for damages resulting from lost privacy. This chapter addresses the technological aspects of privacy and security in health care information systems. It outlines the types of technical security tools that can help manage security risks and then describes the types of tools used by health care organizations. It examines technological issues associated with patient identifiers and other means of linking patient records, and discusses the role of rights management technologies in imposing accountability and control on secondary uses of health information. Finally, the chapter examines obstacles that impede the more widespread use of advanced technical security practice in the health care industry. 2 This statement does not minimize the difficulty of developing a quantitative metric of likelihood. Given the limited data available on violations of privacy and security, it is far more difficult to determine the likelihood of an insider leaking information than to estimate the likelihood of power outages based on good data obtained from the power company.
OCR for page 84
--> Observed Technological Practices At Studied Sites Through its site visits and subsequent deliberations, the committee sought to determine what practices were currently in place in health care organizations, and whether these were prudent practices, as defined primarily in other non-health care settings. Most health care systems are very heterogeneous, meaning that excellent security practices may be in effect in some localized subsystem, but may be entirely missing in other parts of the organization (possibly violating the principle of balance). Thus, summary reporting on the security practices of a widely distributed organization is only a superficial approximation of the range of practices in force. The committee examined a range of technological practices and mechanisms that can be organized into the following main areas: Authentication; Access control; Audit trails; Physical security of communications, computer, and display systems; Control of external communications links and access; Exercise of software discipline across the organization; System backup and disaster recovery procedures; and System self-assessment and maintenance of technological awareness. These types of practices address different combinations of the five key functional areas of technological intervention listed above (Table 4.1). Authentication, for example, supports accountability, perimeter identification, access control, and comprehensibility. Physical security addresses system availability and perimeter identification. As a result, combinations of these practices are necessary for robust security. These security considerations are focused on protecting information within provider institutions and do not address the problems of unrestricted exploitation of information (e.g., for data mining) after it has passed outside the provider institution to secondary payers or to other stakeholders in the health information services industry. A relatively new technological approach (rights management software) is discussed below in ''Control of Secondary Users of Health Care Information" that may help in controlling the use of information both across and within organization boundaries. The following sections discuss in more detail the eight categories of
OCR for page 85
--> TABLE 4.1 Functions Served by Different Technological Mechanisms Function Mechanism Availability Accountability Perimeter Identification Access Control Comprehensiblity and Control Authentication x x x x Access control x x x x Audit trails x x x Physical security x x Control of links x x Software discipline x x x x Backup and disaster recovery x System self-assessment x x x x
OCR for page 86
--> security practice described above and the committee's findings based on its site visits. These findings are reported in terms of examples of observed current practice in health care computing environments. As the committee's site visits revealed, the protection of patient information could be greatly improved if existing, but currently undeployed, technologies were brought into more routine practice in health care settings. Specific technologies include strong cryptographic tools for authentication (Box 4.1), uniform methods for authorization and access control, network firewall tools, more aggressive software management procedures, and effective use of tools for monitoring system vulnerability. In the discussion below, instances in which other undeployed technologies could improve security are pointed out. Obstacles to the use of these tools and techniques are addressed later in the chapter. Authentication Authentication is any process of verifying the identity of an entity that is the source of a request or response for information in a computing environment. It is the linchpin for making decisions about appropriate access to health care information, just as it is for controlling legal and financial transactions. Generally, authentication is based on one or more of four criteria: Something that you have (e.g., a lock key, a card, or a token of some sort); Something that you know (e.g., your mother's maiden name, a password, or a personal ID number); Something related to who you are (e.g., your signature, your fingerprint, your retinal or iris pattern, your voiceprint, or your DNA sequence); or Something indicating where you are located (e.g., a terminal connected by hardwired line, a phone number used in a callback scheme, or a network address). These, of course, all depend on user's integrity in not sharing the key, token, secret, or characteristic that purports to identify them. The classical method for authentication in computing environments is to assign each user a unique identifier (user or account name) and to associate a secret personal password with each such account. IDs and passwords can work reasonably well but are subject to a number of problems. For example, besides sharing their accounts with others, users may forget their password or they may pick passwords that can be guessed easily. Passwords may also be compromised if users write them down where others
OCR for page 87
--> BOX 4.1 Cryptographic Technologies At present two kinds of cryptography are of potential use symmetric or secret-key cryptography, a system in which the same key is used for encryption and decryption, and asymmetric or public-key cryptography, a system in which two different keys are used, one for encryption and one for decryption The most common secret-key system in use today is the Data Encryption Standard (DES) developed by IBM and the National Bureau of Standards in the early 1970s and adopted as a federal standard in 1976.1 DES uses a 56-bit key to encrypt and decrypt information based on a bit manipulation algorithm that is well suited to rapid execution on modern computers. Because only a single key is involved, it must be shared (and therefore transported) between parties wishing to exchange information securely. Safe key transport can be a major problem. The most common public-key system available today is the Rivest, Shamir, Adleman (RSA) system patented in 1983. RSA depends on the difficulty of factoring very large numbers and uses Euclid's algorithm from algebra to define key pairs that are used to encrypt and decrypt information by modular exponentiation. The order of key use is commutative so that if data are encoded by key 1 of a set, key 2 is used to decode the data and if data are encoded by key 2, key 1 is used to decode them. Because two keys are required, only one need be kept secret by the user to whom the key set is assigned. The other (public) key can be made generally available. If the public key is used to encrypt information, the sender can be assured that only the holder of the (other) secret key can decrypt it. Similarly, if the holder of the secret key encrypts information, someone with the public key can be sure the information came from the secret key holder. With proper certification that a public key is assigned to a given individual, this is the basis of the digital signature and related services. Public-key systems run about 1,000 times more slowly than DES systems and require keys about 10 times longer.2 For this reason secret-key cryptography and public-key cryptography are often used together. Public-key cryptography is used for transactions in which the certified identity of the sender and/or receiver of a given message is crucial (and hence worth the computational cost). One such application is to transfer secure DES session keys to be used in higher-volume subsequent encrypted communication between entities. 1 U.S. Department of Commerce, National Bureau of Standards. 1977. "Data Encryption Standard," FIPS Publication 46. National Bureau of Standards, Washington, D.C 2 Diffie, Whitfield. 1988. "The First Ten Years of Public-Key Cryptography," Proceedings of the IEEE, Vol. 76, No. 5, May, pp. 560-577. SOURCE: Computer Science and Telecommunications Board, National Research Council. 1996. Cryptography's Role in Securing the Information Society National Academy Press, Washington, D.C.
OCR for page 88
--> can see them or if they are sent across communication lines in an unencrypted form. Log-in credentials (accounts, passwords, physical tokens, etc.) must be linked closely to the user's employment status or relationship to the organization. Often information is slow to propagate through the organization to individual system managers when the status of a user changes: students and temporary workers come and go and employees terminate or are terminated. Leaving system accounts accessible after a user no longer has rights of access is a major source of security vulnerability. Authentication Technologies Observed on Site Visits As might be expected with the rapidly evolving computing environments of today's health care organizations and the integration of many legacy information systems with more modern ones, there is little uniformity in the use of authentication methodologies. Many systems are dependent on the authentication procedures built in by the vendor, and the lengths and formats of valid account names and passwords are often incompatible. The most common practice in the sites visited was the use of unique account IDs (generally assigned by a system administrator) and conventional unencrypted passwords for each individual user. Often some attempt was made to ensure that users chose difficult-to-guess passwords and that passwords were changed every few months, but enforcement was lax. In many environments, users must remember multiple passwords, depending on which information server they are accessing, and the trade-off is user convenience (not forgetting passwords) versus security. In situations with complex or rapidly changing passwords, users are often tempted to write down the codes for easy reference, most often in personal notebooks but sometimes on slips attached to their workstations, although the committee did not observe passwords written openly during its site visits. Where password changes are required periodically and the new password is not allowed to be the same as the previous one, the most common practice was to have two easy-to-remember passwords that the user alternated between at change intervals. Controls over passwords and account deactivation were most rigorous in centrally controlled systems and became much more relaxed in more decentralized and loosely affiliated groups. The strongest practice observed was the experimental use of centrally issued user token cards (magnetic strip swipe cards) in conjunction with a user's personal identification number (PIN). This scheme was applied to only one of the clinical information systems in the organization, and the software to support it was written in-house. User acceptance was high
OCR for page 89
--> and was enhanced by the fact that the swipe card served other uses such as parking lot or building entry authentication. Other examples of strong authentication technologies included localized use of encrypted password-checking schemes for modem dial-up services, although subsequent communications across the network were generally unencrypted. Such examples of good authentication technology usage were rare and were not deployed organization-wide across information resources. One weak practice observed by the committee was the use of systems in a few sites where the user ID and authentication functions were combined into a single PIN. Each user had a different PIN, but the PIN was so short that a large fraction of all possible PINs was being used, and it was relatively easy for an unauthorized user to guess a usable PIN. An even weaker practice observed at one site was the use of common shared log-in accounts for large classes of providers with shared (and widely known) passwords—e.g., a common account password shared by all physicians and another by all nurses (passwords such as "doc"). Such systems provide almost no protection and depend entirely on the ethical integrity of the entire population of providers, administrators, patients, and visitors—a practice workable in only the most fortunate of organizations. Some sites use a location-based authentication system. For health care systems, the committee believes that authentication based solely on the location of the user is very weak and should be used only under very exigent and carefully controlled circumstances. First of all, with the proliferation of personal computers and the use of high-speed packet-switched communications systems, many users move from machine to machine in the course of their workdays and there is no single applicable location. Second, network addresses change often enough to make it difficult to keep the location database up-to-date and validated. Third, it is relatively easy to fake (Internet) addresses in current communications systems so that apparent location is not a useful or verifiable criterion for identification. Location-based denial of access is used in some sites and may be a helpful adjunct to access control (see below), but it is not sufficient for authentication. Authentication Technologies Not Yet Deployed in Health Care Settings In addition to procedures that strengthen the use of passwords by requiring users to change them frequently, employing codes that are hard to guess, and instituting incentives or sanctions against sharing them, a number of technological schemes are available to strengthen the use of passwords. These are not in general use in the health care industry but include single-session passwords (those that are valid for one log-on session only), encryption technologies (either secret or public key), and
OCR for page 90
--> "smart cards" (described below) or other tokens (e.g., the swipecard in limited use at one of the sites the committee visited). Each of these approaches helps avoid exposing passwords to snooping when the user's identity is being verified, and cryptographic tools provide stronger validation of the source and content of information sent between machines. The most prudent and safe approach to authentication today in health care environments appears to be the use of a unique account identifier for each user with an encrypted password or PIN system (e.g., a secret or public-key Kerberos system as described below) in conjunction with a token. Both the password and the token must be presented to identify a user. This approach combines something you know with something you have and will be the basis, for example, for authentication in Internet commerce systems. Furthermore, this kind of password-token approach can be used for organization-wide identification so that users need be asked only once to log into the organization environment and thereafter have access privileges based on the role they fulfill and the information service they attempt to access, no matter where it is located in the organization. Kerberos Organization Authentication. An important system for organization authentication of users, clients, and servers is called Kerberos. Kerberos was developed at the Massachusetts Institute of Technology (MIT) as part of Project Athena in the mid-1980s.3 The central contribution of Kerberos is the practical management of secret keys for secure communications among thousands of workstations in a distributed organizational computing environment. The current Kerberos implementation functions without public-key encryption technology, yet limits the number of secret keys that must be used in an interconnected system. For example, in a simplistic system, if each of 1,000 users in an organization is to communicate securely with any of the other 999 workstations, the system must generate a unique password for each possible combination of workstations. This implies managing some 1,000,000 keys (1,000 possible senders times 1,000 possible recipients). If on the other hand a central key distribution service existed that could dispense secret keys securely to pairs of users as needed for communications, then on the order of 1,000 fixed keys would be needed—one for each user to employ in communi- 3 See Miller, S., C. Neuman, J. Schiller, and J. Saltzer. 1987. "Section E.2.1: Kerberos Authentication and Authorization System," MIT Project Athena, Cambridge, Mass. See also Needham, R., and M. Schroeder, 1978, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM, Vol. 21, No. 12; and Kohl, J., and C. Neuman, 1993, ''The Kerberos Network Authentication Service (V5)," RFC 1510, Internet Working Group, available on-line at http://ds.internic.net/rfc/rfc1510.txt.
OCR for page 91
--> cating with the key distribution center (KDC). The Kerberos system takes such an approach and has to manage a number of keys that is directly proportional to the number of users in the organization. It distributes time-limited secret session keys without the need for passwords to pass in cleartext over any part of the computer network. Although the KDC represents a focal point of vulnerability in the system, Kerberos is a major step forward in organization management of secure communications and is the basis of strong authentication in the Distributed Computing Environment being promoted by the Open Software Foundation (OSF). Kerberos is being used actively in some health care and other facilities that the committee did not visit, in which secure authentication of more than 30,000 entities is required. Smart Card Tokens. Internet commerce interests are pushing forward aggressively on standards for developing and deploying token-based cryptographic authentication and authorization systems (e.g., the Mastercard-Visa consortium and CyberCash Inc.). These technologies should be adapted to health care organization and interorganization applications, including the establishment of certification authorities with adequate trust levels to be effective in health care settings. Commercial deployment of these technologies will drive the prices of tokens and related software down to the point at which they can be used cost-effectively for protecting access to personal health care information, and user acceptance will be high because use of the technologies will be familiar in other settings. In support of this direction, health care organizations, elements of the health care information services industry, professional organizations, and government agencies should strongly support the development of Internet and commercial efforts in this arena. One example of a smart card token is a card about the size of a credit card but somewhat thicker that has a liquid crystal display in which a number appears that changes every minute or so (the length of the number and frequency of change depend on the card model). Each user card generates a unique sequence of numbers over time, and, through a shared secret algorithm, servers for which the user has been assigned access privileges can generate the corresponding sequence of numbers. Since only the bona fide user (nominally) possesses the card and the number sequence is unique, the number at any given time is used as a session password. Any snooper who detects the number being sent over the network must replay it within the cycle time of the card; otherwise a new random number, known only to the holder of the card, is required for login. Other devices suitably packaged as buttons, smart cards, or similar tokens are becoming available at economically affordable prices. These have write-controlled internal memory (devices with 8 kilobytes of stor-
OCR for page 92
--> age are readily available today) along with processing capacity to support services such as user-specific information storage, authentication, and cryptographic certificate management. Some even have biometric access control features. Biometric Authentication Technologies. Various systems that measure the physical features of an individual (e.g., fingerprints, voiceprints, retinal or iris patterns of the eye, hand geometry patterns, or facial features) or the features of repetitive actions (e.g., signature dynamics) have been studied as the basis of identification systems.4 Such biometric systems have the potential advantage of convenience and difficulty in forging an access pattern, since the basis of identification is always physically with the subject and is typically a complex pattern. However, biometric systems must be evaluated in terms of their reliability (false-positive and false-negative identification rates), the time and user frustration involved in the repeated authentication attempts that may be needed, and the difficulty of fooling the system with simulated patterns. The most extensive objective measurements of the reliability of biometric methods have been done by Sandia National Laboratories.5 These studies evaluated a number of commercial systems using voiceprint analysis, signature dynamics, retinal patterns, iris patterns, fingerprint analysis, and hand geometry. The Sandia data indicate that the most effective technologies currently available for identification verification (i.e., verifying the claimed identity of an individual who has presented a magnetic stripe card, smart card, or PIN) are systems based on retinal or hand geometry patterns. These systems have one-try false-rejection and false-acceptance rates of less than 1 percent. User pattern collection and verification processing take about 5 to 7 seconds. Biometric systems have already progressed to the point at which they are being put into operation to help verify identities in applications such as personal and electronic banking, human and social services delivery, driver's license verification, industrial security, immigration control, and other settings where convenient, nonforgeable identification is necessary.6 4 See, for example, Daugman, J.G. 1993. "High Confidence Visual Recognition of Persons by a Test of Statistical Independence," IEEE Transactions on Pattern Analysis and Machine Intelligence 15(11):1148-1161. 5 Holmes, J.P., L.J. Wright, and R.L. Maxwell. 1991. "A Performance Evaluation of Biometric Identification Devices," Sandia Report SAND91-0276. Sandia National Laboratories, Albuquerque, N. Mex., June. See also Bouchier, F., J.S. Ahrens, and G. Wells. 1996. "Laboratory Evaluation of the IriScan Prototype Biometric Identifier," Sandia Report SAND961033. Sandia National Laboratories, Albuquerque, N. Mex., April. 6 See, for example, Biometrics in Human Services User Group Newsletter, Vol. 1, No. 1, July 1996.
OCR for page 116
--> Site Security Feature A B C D E F Mobile access protection Intruder script protection • ControlInternet Protocol addresses • Encryption Cryptography-based authentication Encrypt network traffic Encrypt database contents Digital signatures Document integrity Transaction nonrepudiation Encrypt backup media Software Discipline Use antivirus technology • Checksum, validate software • Control user software Control PC software loading Network software census • Integrated software tools Backup and Disaster Recovery Backups, multiple storage sites • • • • • Data content integrity Operations recoverability • • • • • System Self-Assessment Evaluation, Staying Technically Current Run anti-intrusion programs • Vulnerability evaluation • Stay up on CERT alerts • Avoid or update obsolete technologies •
OCR for page 117
--> of a check mark means that the site pays only minimal attention to the given security feature or, in the opinion of the site visit team, could have made significantly more effective use of existing, proven technologies and practices. These judgments may differ from those of individual site managers and system administrators, who judge the need for a particular precaution on the basis of the perceived threat (or lack of it) within the organization. These security considerations are focused on preserving information confidentiality within provider organizations and do not address the problems of unrestricted use of information (e.g., for data mining) after it has passed, with consent, outside the provider organization to secondary payers or to other stakeholders in the health information services industry. Key Issues In Using Technology To Protect Health Information In addition to securing health information systems, as described above, technical tools can play a role in protecting patient privacy by facilitating or impeding the distribution of health information. While advanced computing and communications technology, in general, facilitates the dissemination of health information, technologies exist that can help limit unauthorized or inappropriate distribution of health information. Such technologies include patient identifiers and other approaches for linking records contained in disparate databases, as well as rights management technologies for limiting secondary distribution of health information. Patient Identifiers and Techniques for Linking Records Developing robust methods of indexing and linking patient records is critical to ensuring that providers have reliable data on which to base medical decisions.18 Patient-specific health care information must be bound uniquely and unambiguously to the person to whom it relates through the use of an identifying label such as a medical record number. To ensure that the identifier is unique, organizations must prevent assignment of the same number to two different patients; to ensure that it is unambiguous, organizations must prevent indexing of any single patient's 18 Within the computer science community, data integrity and availability are considered an integral element of system security. See Computer Science and Telecommunications Board, National Research Council. 1991. Computers at Risk: Safe Computing in the Information Age. National Academy Press, Washington, D.C.
OCR for page 118
--> records by two or more different numbers. Otherwise it may be difficult to find all the data associated with a person. In a traditional health care environment, each organization—whether a hospital, a physician's office, or a pharmacy—generates its own identifier for each new patient. That identifier is used for all transactions involving the patient and provider, but the identifier is different for each organization. Names and addresses are generally inadequate as unique identifiers because they are not necessarily unique within large populations of patients. As a result, health care organizations have developed other mechanisms for generating patient identifiers. Some assign patient numbers sequentially; as new patients register with the hospital, physican, or insurer, they are assigned the next number in sequence. Other organizations use the Social Security number (SSN), relying on the Social Security Administration to ensure that numbers are assigned uniquely and unambiguously.19 Still others have their own specific algorithms for generating numbers. One site visited for this study generated identifiers from the patient's first and last names, year of birth, and gender using an algorithm developed for generating driver's license numbers. An extra "tie breaker" digit is used to differentiate between multiple patients with otherwise identical numbers. Administering patient identifier systems can be a cumbersome task, especially in organizations with large patient populations. Patients change addresses frequently or report their names differently (using a nickname versus a full name or a maiden name instead of a married name); this makes it difficult to use demographic information to determine whether two records with different numbers actually belong to the same patient. As health care systems merge into larger enterprises and integrated delivery systems, they increasingly face the problem of integrating and linking records from organizations that used incompatible identifier systems. Each of the sites the committee visited is concerned with the problem of managing unique and consistent patient identifiers within its enterprise. One proposal for addressing this difficulty is to assign each patient a universal identifier to be used throughout the health care system. The Health Insurance Portability and Accountability Act of 1996 (Public Law 104-191) directs the Secretary of Health and Human Services to promulgate standards for a universal health identifier by February 1998. The proposed identifier would be assigned to each patient, employer, health 19 Not all Social Security numbers are unique or assigned unambiguously. There are an estimated 4 million to 12 million false, invalid, or ambiguously assigned numbers in the current system, although improvements in management of the SSN continue to reduce the rate of error.
OCR for page 119
--> plan, and health care provider in the United States. One candidate for the universal health identifier is the Social Security number. Use of the SSN appears to have many potential advantages: it is already the basis for the medical record number in many organizations (including Medicare) or is elsewhere contained in the medical record, and a system already exists for assigning numbers. Use of the SSN as a universal patient identifier, however, raises the concern that it might facilitate linking of medical records with other types of records that are also referenced by SSN, such as Social Security, employment, financial, and driving records. To circumvent this problem, it may be possible to use a system in which individuals have different unique identifiers to index information about them in different domains such as health care, banking, and insurance. Thus, Social Security records could continue to be indexed by SSN, but driving records would use a different numeric scheme, as would medical records, educational history, and so forth. Someone who desires to collate these disparate data sets would find that they contain no convenient shared identifier. Collation would depend on the presence of other distinguishing data in each database, perhaps including name, address, and birthdate. Because each database is likely to contain different subsets of such data and because none of them alone is enough to identify someone uniquely, the collation process would be fraught with greater uncertainties, and would be more difficult and costly. Linking information between domains would require an overt act to translate different identifiers; however, those organizations with legitimate needs to link data could routinely collect the data necessary to create the links without requiring a universal identifier, though possibly at greater expense. Cryptographic methods allow many other variations in identification schemes. The British Medical Association, for example, is encouraging adoption of an identifier scheme wherein the patient's identifier at any institution is computed from public information about the individual (name, part of the postal code, and date of birth) combined with a secret identifier unique to the institution.20 Other options include the use of temporary pseudonymous identifiers for tracking independent pieces of data such as laboratory results. Many managed care organizations and integrated delivery systems are addressing the records-linking problem by developing master patient indexes. Such systems allow records at each affiliated institution to retain their original identifiers, but generate an overall index listing the various 20 See Anderson, Ross J. 1996. "An Update on the BMA Security Policy," Notes of the Workshop on Personal Information Security, Engineering and Ethics, University of Cambridge, England, June 21-22.
OCR for page 120
--> numbers by which each patient's records are referenced in different institutions. Several companies now offer a service for creating master patient indexes for health care organizations. Typically, they use demographic data and incident information to link patient records across the enterprise and can determine unambiguously the patient to whom all but a small percentage of existing patient records refer. Another approach to linking records across disparate organizations is to rely not on a particular number but on a limited set of specific patient attributes. One experimental system that is taking this approach allows providers in the emergency rooms of three Boston area hospitals to query each other's clinical databases for information about patients.21Because the three hospitals have their own patient identifier systems, the experimental system uses four attributes to search for related records: first name, last name, date of birth, and gender. Each system returns only unambiguous matches to the requester. In its present form, this system may not be feasible for linking larger numbers of records over a larger number of organizations, but it does highlight the possibility that additional research may yield innovative ways of linking records that do not rely on a single, universal identifier (See Chapter 6, Recommendation 5). Control of Secondary Users of Health Care Information From a technical perspective, the problem of controlling the use of information among secondary users is analogous to the problem of controlling intellectual property rights for vendors of on-line publications and other valuable information. Instead of wanting to ensure payment for information access, however, health care organizations want to authenticate, authorize, and record who accessed what information and for what reason in the health care setting. One approach to this type of control may be to pursue adaptations of rights management technologies being developed to manage intellectual property rights.22Such software controls would operate internally within provider organizations and also externally, as records pass to payers and other secondary users. The essential elements of a rights control system include the following: Chunks of information (components of the patient record, includ- 21 Kohane, Isaac S., F.J. van Wingerde, James C. Fackler, Christopher Cimino, Peter Kilbridge, Shawn Murphy, Henry Chueh, David Rind, Charles Safran, Octo Barnett, and Peter Szolovits. 1996. "Sharing Electronic Medical Records Across Multiple Heterogeneous and Competing Institutions," available on-line at www.emrs.org/publications/. 22 See, for example, a description of IBM cryptolope technology: Rodriguez, Karen. 1996. "Pushing the Envelope," Communications Week, May 13, p. 37. Similar technology is being developed by Xerox and AT&T.
OCR for page 121
--> ing text, laboratory results, and images) to be transmitted outside the organization are encrypted by a server within a health care provider's information system. The encryption is designed so that the information can be accessed only by special software (possibly a Java "applet") with an encryption key supplied by the server on receipt of properly authenticated user credentials. Potential users authenticate themselves through one of the public-key schemes and present authorization credentials for access to an appropriate part of the record. Types of access might include viewing demographic information only; viewing details of the most recent provider visit; viewing the full patient record except for potentially sensitive areas; or viewing, printing, and copying the entire record. Each access request would be logged to ensure accountability, and the software would destroy the access key after each use so that subsequent uses require reauthentication. The user downloads special access software from the provider (or trusted third party) that contains a key to decrypt the document upon authentication and tracks the use of portions of the document according to authorized privileges. Viewing software must be secure against tampering, and the system must make it difficult to implement work-arounds, such as "screen scraping" and core dump analyses, that would give users uncontrolled access to the decrypted material. Some workers in this field have gone so far as to propose that this approach could succeed only in the context of closed "network appliance" machines to which the user would have no access for software reconfiguration. If the encrypted document were sent to other users, they could access it only with the viewer application supplied by the provider, which would require new authentication and authorization before allowing access. Although it is unlikely that such a rights management system can be made foolproof against the most technically competent unethical user, it may provide an audit trail of access up to a point of abuse, including recording that a local copy has been made (presumably against privacy protection laws) or that an overt act to circumvent software controls had occurred. Further it might be possible cryptographically to watermark digital medical record documents with the identities of the users to whom they were issued in confidence so that if a subsequent inappropriate disclosure is made, its source could be identified. An obvious extension of these ideas would be to use rights management inside organizations as well, to enforce organizational policy on data collection, access, and dissemination. For example, an organization could use rights management tools to ensure that clinical data cannot be collected or aggregated even by internal staff except with the approval of
OCR for page 122
--> an institutional review board. Rights management tools, coupled with legal reform to define acceptable use and disclosure, may also make it feasible to deploy a uniform health care identifier system with appropriate accountability for bona fide use within the health care industry. Obstacles To Use Of Security Technology The move to computerized patient records is made more urgent by many pressures: the need to allow simultaneous access to records by various providers involved in patient care in modern streamlined clinical settings; the push toward increased cost-effectiveness, meeting the needs of highly mobile patients, regional integration of providers and referral systems, and the use of telemedicine and telecare; the push toward evidence-based care; the need to analyze outcomes and utilization; the need for better clinical research support; attempts to improve health through more thorough immunization and nutrition programs; and so on. Despite an aggressive move toward computerized health care records in recent years and ongoing parallel technological improvements, there are still many obstacles and impediments to achieving usable and secure systems. The following are the principal hurdles related to the use of security technology that the committee found. Difficulty of Building Useful Electronic Medical Records The challenge of developing digital health care record systems that are useful, efficient, and cost-effective has proved to be so difficult that deployment of any system that works in the clinical care arena is the primary priority. Security is often relegated a much lower priority in this process. One of the goals of computerized patient record systems is to make care more cost-effective while maintaining high quality. Although minimizing inappropriate, expensive tests and treatments is an important part of these goals, the most direct goal is to save provider time (i.e., allow providers to care for more patients in less time). To date, the committee has been unable to document any clinical information system that saves provider time overall. Stronger security measures can only exacerbate this shortcoming by creating more hurdles that a provider must overcome to use a system; thus, security is often sacrificed in the interest of user acceptance and efficiency. As one chief information officer of a large health care organization told the committee, ''Every minute of time a system costs a user to enforce security controls is multiplied 20,000 times across our physician population, and this translates into the loss of real dollars." The transition period between paper-based records and electronic records adds to the cost and increases the threshold to move to-
OCR for page 123
--> ward electronic medical records since health care organizations must manage both the old paper and the new electronic record systems at the same time. Lack of Market Demand for Security Technology Few organizations can afford to develop and integrate strong information security technologies into their operational systems. Until vendors incorporate stronger, integrated, standard, open technologies, reliance on old and vulnerable technologies for user authentication, access control, network protection, and so forth, will persist. This seems to be a chicken-and-egg problem, however. Although some vendors do not appear to put much effort into security mechanisms, others reported that they have invested considerable effort in developing sound security features in clinical information systems they were marketing, but that these features do little to enhance sales. Vendors contend that there is little market demand for security that can help motivate a vendor to invest heavily in it. If this is true, at least some vendors may be prepared to deliver stronger security capabilities quickly if health care organizations make those capabilities a requirement for future system purchases. This suggests that a two-pronged approach is needed: (1) make technological interventions more acceptable by making them less of an annoyance to users; and (2) increase purchaser awareness regarding security issues, thus creating a market demand for these technologies so that vendors will integrate strong security tools in health care information system products. Organizational Systems Accumulate—They Are Not Designed Many of the provider sites visited by committee members are in acquisition mode; that is, they are actively pursuing mergers and acquisitions of other health care providers with the hope of achieving economies of scale in managing a larger organization, benefiting from referrals of patients from larger and larger population areas, and reducing competition. The merger of diverse hospitals and clinics entails inheriting legacy information systems that do not communicate information well with each other, much less share a common security framework. Such systems are not designed but evolve within the exigencies of business goals. Relying on the overriding ethical behavior of providers within the systems, security integration and reinforcement often receive lower priority. At a technological level, it would help greatly if commercial tools were available to integrate legacy systems into modern distributed computing environments. Beyond that, however, many other database content inconsisten-
OCR for page 124
--> cies have to be overcome, including patient identifier systems, database terminology, information types, and units of measurement. Cryptography-based Tools Are Still Out of Reach As noted in the discussion of encryption, there is almost no common use of cryptographic tools in any modern public distributed computing setting today. It seems clear that cryptography-based technologies and standards specification are available for inclusion in health care systems, but this has not happened to any real extent, except in a few specialized commercial products and in more adventuresome academic settings. Much more aggressive demonstration of these tools and their integration into real systems are needed. Effective Public-key Management Infrastructures Are Essential but Still Nonexistent The basis for many of the features desired for security in health care information systems depends on deploying public-key cryptographic technologies—authentication, digital signatures, information integrity management, session key exchange, rights management, and so on. Trusted and effective key management is at the heart of these tools but is not a well-established process at this time. Substantial challenges remain to demonstrate a key management system (or systems) that connects keys reliably with bona fide organizations, providers, patients, and service personnel; that provides rapid and unassailable operational verification of credentials; that makes theft of key information difficult in systems deployed to non-computer expert user groups; that enables recovery of information in the case of lost keys; and that ensures rapid revocation of compromised keys and prevents exploitation of compromised information with protection based on those keys. Preliminary efforts to establish public-key management infrastructures are under way in the banking and Internet commerce communities but, to date, nowhere in the health care industry. Such systems must be set up to certify provider organizations, physicians, nurses, and other support personnel, as well as patients themselves, and these must operate effectively, conveniently, and in a setting of unquestioned trust and confident risk management. Considerable challenges remain to demonstrate a key management capability that is usable for health care, and demonstration projects should begin at once.
OCR for page 125
--> Helpful Technologies Are Hard to Buy and Use Providers can rarely afford to develop their own information systems, and those sold by most vendors do not offer organizational solutions for security controls. Thus, with the push to more distributed systems, providers are forced to put up with multiple, incompatible authentication and authorization technologies or to construct special solutions for parts of their organizations. The tools to manage heterogeneous computing environments in terms of security, reliability, and so forth are not well developed. Standard ways are needed to link component systems together that meet requirements and do not overburden the system administrator. A great deal of technology already exists that can help protect health care information, but much of it has not been brought into routine practice yet. Specific technologies include strong cryptographic tools for authentication, uniform methods for authentication and access control, network firewall tools, more aggressive software management procedures, and effective use of system vulnerability monitoring tools. Some of these technologies—token authentication cards, for example—have been relatively expensive for wide deployment in large organizations. However, the costs of these technologies are decreasing (through volume adoption and competition) at the same time that their usability is improving. The tools to manage software across distributed heterogeneous systems consisting of many thousands of machines and users, including program census management, version control, and integrity control, are poorly developed. Overall the lack of standards for security controls and for vendor products that interoperate between disparate systems means that chief information officers postpone decisions about implementing and enforcing effective security solutions. Education and Demystifying Issues of Distributed Computing and Security The revolution in distributed computing and communications systems that has been brewing since the 1960s and 1970s has taken hold full force in commercial organizations during the past decade. Health care organizations have been among the slowest to adopt these new technologies, however, and existing management and information systems personnel are not fully prepared. The lack of technical understanding, the lack of direct experience with these new tools, the lack of confidence in their management, the lack of a peer group of successful adopters (except for a few academic medical organizations), and uncertainties about reasonable risks and expectations all leave conservative organizational managers hesitant to make decisions. The design, implementation, and opera-
OCR for page 126
--> tion of effective, secure distributed systems are still not well understood by many users or designers, nor are methods for the detection and control of intrusions. Management ignorance and uncertainties translate into delays in defining requirements for, procuring, and deploying modern health care information systems. Distributed system technologies, including security, need to be demystified, and managers must be educated about realistic goals, alternative solutions, and operational practices to take advantage of these tools. Only in this way can the health care industry improve its practices for protecting electronic health information.
Representative terms from entire chapter: