Testimony Prepared for
National Committee on Vital and Health Statistics
Subcommittee on Privacy and Confidentiality
January 12, 2005
Dixie B. Baker, Ph.D.
Science Applications International Corporation
Healthcare Information and Management Systems Society
Introduction
My name is Dixie Baker, and I’m a Group Vice President for Technology and Chief Technology Officer for the health and life sciences practices at Science Applications International Corporation. I have worked in the areas of information protection and high-assurance architecture for over two decades, and for the past six years I have applied my knowledge and expertise to the areas of health care and public health. Today I am representing the Healthcare Information and Management Systems Society (HIMSS), the largest membership organization representing healthcare information systems users, vendors, and consultants.
Summary
We applaud the Subcommittee’s recognition of the privacy risks posed by the release of electronic health records to third parties. Clearly, given today’s technology and business environment, limiting the exposure of electronic health information released to third parties is a daunting challenge. Yet some emerging and existing technologies offer potential solutions. I will begin my testimony today by describing the prevailing security model. Then I will set forth the business and personal imperatives that drive a set of requirements. Finally, I will describe what I see as the most promising technology solutions.
Current Security Model
The historical and currently prevailing security model is based on the granting and denying of subjects’ requests for access to objects. Security mediation and enforcement within this model consists of four steps:
- Authentication of the subject’s identity;
- Mapping of the subject’s identity to a set of access rules relating to a requested object or privileged action;
- Allowing or denying access to the requested object or privileged action; and
- Auditing the access or action.
This model is designed to “keep the bad guys out.” It is not very useful for allowing controlled sharing and collaboration. The first problem is that this model assumes and requires that all subjects and objects be under the control of a single trusted mediator. Secondly, this model is too rigid; it does not allow context-specific flexibility. For example, the model does not allow for emergency access, as required by the Health Insurance Portability and Accountability Act (HIPAA) security regulation. Third, this model enforces security policy on “protected objects” at a uniform level of granularity throughout the system, with “protected objects” usually taking the form of files, folders, database tables, and file systems. Finally, this model does not enable security policy to persist throughout the life of the object – when a subject is granted “read” access to an object, she is also able to copy that object, and can then share it with others. For example, if I am able to read a file, I can save it to another name and email the copy to whomever I choose. Today, the ease with which digital files can be copied and transmitted is resulting in serious breaches of copyright law, particularly in the entertainment industry.
Cryptographic schemes follow this same basic model, with two important exceptions. First, encryption is applied to “data” and not to the “objects” in which those data are stored. The “bad guy” might have access to a file containing secret data, but if those data are encrypted, then the “information” is still protected. Secondly, cryptographic solutions control access to information through the distribution of secret keys, rather than by mediating each subject’s access to an object. That is, at some point, someone (or something) authorizes a subject to access encrypted data by giving them a secret cryptographic key. Once they have this key, they can “unlock” the data whenever they want – with no further mediation required.
Public-key cryptography adds a new twist by eliminating the need for two people to share a secret key. Public-key cryptography uses two keys that are mathematically related in a way that if one is used to encrypt data, the other is needed to decrypt those data. One key is made public, and the other is kept private. So if I want to give someone access to my data, I simply encrypt the data using the person’s public key so that the only person who can decrypt the data is the person holding the associated private key.
Business and Personal Imperatives
The business imperative we are addressing today is the need for third parties, such as employers and insurance companies, to review an individual’s health information in order to effectively manage business risks that might be accrued in a relationship with that individual. Naturally, the third parties’ desire is to have as much of the individual’s health information as possible so that they can construct a complete picture of associated risks.
The personal imperative is to protect personal privacy by releasing a minimal set of information to as few people as possible. Further, we want assurance that the rules we place on our information will be enforced into perpetuity, not just for the initial release. We do not want our insurer to be able to pass our health information on to other business partners. Because privacy is values-based, no consistent set of rules will work for every person or for every third party.
These conflicting business and personal imperatives present a significant challenge from both social and technological perspectives. Addressing these imperatives is clearly beyond the reach of today’s security technology model, and clearly beyond what is required by the HIPAA security regulation.
Solution Requirements
To effectively and safely share information with third parties requires a solution capable of operating across multiple organizations governed by different security policies and controls. The solution must enable the owner of an electronic health record to assign privacy attributes in accordance with his own value system (within the bounds of law and regulations). These attributes, captured as metadata, must persist with the information throughout its life cycle and must be uniformly interpreted and translated into security rules that are enforced across enterprises, organizations, applications, and systems. This will require the specification and adoption of uniform metadata standards for representing privacy attributes.
To assure the integrity of the rules captured, the solution must be capable of authenticating the identity of the “owner” of the information – that is, the individual or system authorized to establish the security policy rules to be enforced with respect to that information – and the third party to which the information is authorized for release. The solution also must be capable of authenticating the data. That is, assurance must be provided that the data that are shared, and the rules governing their release, are authentic and have not been corrupted or modified in any unauthorized way. The specific granularity of protection must be flexible enough to be applied to a complete medical record or to an ICD-9 code or to anything in between.
We also need for the security solution to be able to evolve with technology. For example, encryption historically has struggled to keep one step ahead of the speed of processors. As processors have gotten faster, and more recently as processors have begun to collude with each other, both the complexity of encryption algorithms and the length of encryption keys have had to be extended.
Technology Solutions
I want now to address the feasibility of using technology to address the challenge of providing continuing protection of personal privacy when electronic health records are released to third parties. My objective here is not to recommend a particular solution, but to assure you that this is not an intractable problem. Existing and emerging technologies can be applied to effectively manage the risks associated with third-party release of electronic health records.
The technology that I believe is most capable of meeting the requirements we have discussed is digital rights management, or DRM. DRM is a highly controversial technology developed primarily to enforce copyright protections on digital content distributed over the Internet, such as eBooks, music, and movies. Ironically, the controversy around DRM stems from the perception that the very features that make DRM attractive for controlling electronic health records released to third parties are in fact serious threats to individual privacy. Specifically, DRM systems enforce restrictions on what individuals can do with copies of works they have purchased, and collect information about purchasers’ activities and report back to the copyright owner – both viewed by many as infringements on personal privacy.
The first generation of DRM emerged in the mid-1990s and used access control and encryption to lock content and to limit its distribution to only those who had paid for it. The second generation has greatly expanded the capabilities of DRM to include a broad range of technologies that give parties varying degrees of control over how digital content and services are used, including by whom and under what conditions. A DRM system enforces usage rights based on originator-controlled policies addressing permissions, constraints, obligations, and rights holders, and automates a workflow that includes the following steps.
- A user obtains an encrypted resource, such as an eBook, a video, or an electronic health record, and attempts some use of it.
- A trusted DRM client sends the attributes of the user’s request to a license server, which checks applicable policies to determine whether the requested use is allowed.
- A financial transaction may be conducted, if required.
- The license server constructs a license package consisting of a rights specification, identifiers, revocation information, and cryptographic keys to the content, and returns it to the DRM client over a secure connection.
- The DRM client authenticates the license package, evaluates the policies, decrypts the content, and issues an authorization to a viewing component.
- The content is rendered in accordance with the license authorizations.
First-generation DRM solutions were proprietary, client applications that offered very weak assurance. However, as trusted computing principles are migrating into end-user systems, DRM is being implemented at the operating system level, increasing its practical application and market demand. DRM policies are explicit, conditional statements written using standard policy language to specify how to handle actions that authenticated users attempt on protected resources. For example, a DRM policy applied to an electronic health record might enable an insurance company to view those portions of the record necessary for coverage authorization purposes, but not allow the record to be saved on the company’s server.
A number of vendors, industry groups, and standards bodies are involved in DRM standardization efforts. A proposed, XML-based Rights Expression Language (REL) standard called eXtensible rights Markup Language, XrML, is widely considered the most technically capable rights expression language. The Motion Picture Experts Group (MPEG), a working group of the International Standards Organization (ISO), used XrML as the basis for its own REL. The MPEG REL and its associated Rights Data Dictionary (RDD) establish standards for managing the consumption rights of all forms of content. Although the MPEG REL is targeted toward the protection of rights for coded representations of digital audio and video, the Open eBook Forum is using the MPEG REL specification as the basis for its REL specification for digital text, and I believe it could serve as the basis for developing an REL specification for electronic health records.
DRM technology could be useful in defining rights associated with electronic health records, and in enforcing those rights as these records are passed to third parties. The ability to control, and to receive reports on what third parties do with records released to them would indeed be highly valuable in protecting individual privacy while enabling sharing. A DRM solution could enable the direct transfer of electronic health records from healthcare providers to third parties, with assurance that privacy rules would be enforced throughout the lifetime of the information. This solution would require that the healthcare provider implement a DRM server and that third parties implement DRM clients – something that is likely to become a standard feature of personal computer operating systems in the relatively near future. Unfortunately, at this point, DRM is mired in controversy and plagued by accusations of patent infringements, which could thwart efforts to develop and implement open standards.
A more immediately feasible, though less capable, approach the healthcare industry could consider is the use of a trusted intermediary to manage the sharing of electronic health records with third parties in accordance with privacy rules prescribed by the information owners. In this solution, the trusted third party could use the prevailing security model and existing technology to enable a patient to authorize the sharing of specific information with a designated third party. Many, though not all, of the functions provided by DRM could be implemented using this model. For example, the trusted intermediary could provide a user interface that would enable an individual to request and authorize the sharing of her electronic health record and to prescribe specific permissions, constraints, and obligations relating to that information. These rules could be managed in a relational database management system and enforced at the time the third party requested access. Screen-sharing technology could be used to prevent third parties from making copies of the information and sharing it in unauthorized ways. That is, third parties would be able to display an image of the information on their screens, but the data would not persist as a file on the client machine. While disabling the print-screen capability would require a more complex solution, simply replacing a file transfer with a shared-screen image would greatly increase the privacy protection afforded to the patient. More complex rules that DRM technology enables, such as enforcing a limit on the number of digital copies that can be made, would not be possible using this solution.
Of course the trusted intermediary itself would need to gain the trust of record owners that their health information would be managed safely and responsibly. In order to do that, the intermediary would need to be perceived as independent and trustworthy. The intermediary would need to implement very strong security protection and to communicate these protections in a way that would provide users assurance that their information was safe. Also, depending upon the business model, the trusted intermediary might need to execute Business Associate agreements with the healthcare organizations that provided Protected Health Information to them.
Both DRM and trusted intermediary solutions assume the availability of a security infrastructure that includes user authentication, metadata management, cryptography, and auditing. Authentication is required to irrefutably establish the identity of the health record “owner” and the third party to whom the information is being released. Metadata will be needed to specify rules in XrML and to specify confidentiality attributes. The evolving HL7 Clinical Document Architecture (CDA) standard could be useful in standardizing the metadata used for electronic health record sharing.
Cryptographic capabilities will be needed to protect data confidentiality, data integrity, and data authenticity. A trusted intermediary will want to encrypt data stored in its repository. Both DRM and trusted intermediary solutions will require an encrypted communication link, such as Secure Sockets Layer (SSL), to protect information exchanged between the information provider and the third party to whom that information is being released. SSL protection will be required for exchanges between the information provider and the information owner; for example, for enabling the owner to specify rules to be enforced. Also, both solutions could potentially use Public Key encryption as part of their user authentication strategies.
Conclusion
Thank you very much for the opportunity to present this testimony. I hope I have given you useful information about some of the existing and emerging technologies that could be applied to the protection of electronic health records released to third parties. As a strong advocate of initiatives and standards to advance the implementation and use of electronic health records, HIMSS is gratified to have the opportunity to contribute to your work. As an organization recognized for its expertise in healthcare information legislation, regulations, policies, standards, technologies, and practices, HIMSS continues to dedicate resources toward activities that contribute to the advancement of the safe exchange of electronic health records. Uniform adoption of data standards in healthcare is critical to our vision of advancing the best use of information and management systems for the betterment of human health. We look forward to working with other industry leaders and the Subcommittee on Privacy and Confidentiality to further this cause.
About HIMSS:
HIMSS (Healthcare Information and Management Systems Society) is the healthcare industry’s membership organization exclusively focused on providing leadership for the optimal use of healthcare information technology and management systems for the betterment of human health. Founded in 1961 with offices in Chicago, Washington D.C., and other locations across the country, HIMSS represents more than 14,000 individual members and some 220 member corporations that employ more than 1 million people. HIMSS frames and leads healthcare public policy and industry practices through its advocacy, educational and professional development initiatives to promote information and management systems’ contributions to ensuring quality patient care. Visit www.himss.org for more information.