IHE Response to Markle Principles

This is a DRAFT page representing only a work in progress. Comments are welcome and should be directed toward the editor of the page (John Moehrke). Authorized IHE Editors may edit the wiki page directly.

Introduction

The Markle Foundation Connecting for Health collaborative has put forth proposed principles necessary to improve healthcare when implementing a Health Information Exchange (HIE), and recommends that technology and policy requirements must be considered in parallel. These principles set the groundwork to enable accurate, timely, understandable, and relevant information management. These principles enable consumers, patients, and health professionals to communicate more accurately and efficiently. These principles direct the healthcare industry to use information appropriately, to protect privacy, and to create a climate of public trust. This white paper demonstrates how these principles are realized using the Integrating the Healthcare Enterprise (IHE) integration profiles for health information exchange

The Markle Principles

The Markle Foundation Connecting for Health collaborative has put forth the following consumer principles for healthcare in a paper titled Electronic Health Data Exchanges: Patient and Consumer Principles for System Design.

Implementing an HIE

This white paper describes a set of Technology Controls that satisfy the Markle Principles. The solution is based around use of the Integrating the Healthcare Enterprise (IHE) profiles. Policies and Risk Management The implementation of a Healthcare Information Exchange (HIE) must flow from a high level Policy. One of the things that this high level HIE Policy will drive is a Risk Assessment with a defined level of risk that is reasonable and acceptable. When developing the HIE Policy one must consider and rationalize all the Policies of each entity interacting with the HIE.

The HIE Policy and the Risk Assessment drive the implementation of a reasonable balance of risk controls; including Physical Controls, Procedural Controls, and Technology Controls. It is important that as the risks are mediated, the resulting system is examined to determine the new level of overall risk, including any new risks that might have been introduced by the mediation. General Security Controls

The IHE model presumes that the clinical applications in place today include the necessary security to protect patient data within the entity (e.g. hospital, clinic). These applications include controls to authenticate users, to check that the users have rights to perform functionality, and to account for the actions of users within the application. These applications are installed within a facility that has taken care to physically and electronically protect these applications with physical barriers, air-conditioning, backup electricity, backup of data, etc. These are the types of controls currently required by the CCHIT certification criteria for Ambulatory EMR systems.

The entities that are joining the HIE have appropriate policies for their entities that have driven their choice of appropriate implementation. These entities have control over their users (employees). These entities understand their environment and can apply locally appropriate authentication methods (passwords, smartcards, 2-factor token, etc). They can react quickly to provision, suspend, authorize, and de-provision users in a way that is sensitive to the employees’ rights. As these entities join an HIE the clinical applications that touch the HIE can be visualized as being at the edge of the entity (i.e. edge application, or edge system).

In healthcare we must be sensitive to patient care and safety. The applications closest to the patient are best suited to determining the context of the situation. It is only at this level that emergency mode can be handled in an expedient way (often called break-glass).

The IHE model leverages the general security controls in the edge applications in a distributed way to protect the assets of the HIE. The IHE model is very careful to include security while allowing for flexible and safe provision of healthcare. The IHE model reinforces the need for these basic security functionalities through the Audit Trail and Node Authentication (ATNA) profile. This same profile ensures that the edge systems are strongly authenticated to the HIE to ensure that only trusted systems are allowed to have access.

Further details about the IHE profiles can be obtained by going to the IHE web site

Implementing the Markle Principles

We begin by recognizing that in the IHE model the edge application must meet the necessary general security controls shown above. The IHE models only define the interaction (network protocols) between logical applications and not the behavior within an application (e.g. clinical decision support, medications management). In many cases it is application functionality which provides the solution to the Markle Foundation consumer principles. In other cases the principle needs to be handled in the HIE Policy. In both these cases, neither the functionality nor the principles are specified by the IHE profile.

This section will not fully describe how the IHE profiles satisfy the principle. Rather it directs the reader to the individual IHE profile and topic within the profile. The following is a list of IHE profiles that can be leveraged to satisfy the Markle principles.

• Cross-Enterprise Document Sharing (XDS)
• Audit Trail and Node Authentication (ATNA)
• Basic Patient Privacy Consents (BPPC)
• Cross-Enterprise Personal Health Record interface (XPHR)
• Enterprise User Authentication (EUA)
• Consistent Time (CT)
• Digital Signatures (DSG)
• Notification of Document Availability (NAV)
• Patient Demographics Query (PDQ)
• Patient Administration Management (PAM)
• Patient Identity Cross-Reference (PIX)
• Cross-Enterprise Document sharing via Reliable messaging (XDR)
• Cross-Enterprise Document sharing on Media (XDM)

1. Individuals should be able to access their health and medical data conveniently and affordably.

This first principle is asking for Personal Health Record (PHR) application functionality. The IHE profiles provide a mechanism for applications such as a PHR to have access to and participate in publication of healthcare documents. The IHE profiles provide the access from the PHR application and the document store.

The XPHR profile further refines this interface to provide a way to manage the typical healthcare attributes such as allergies, problems, and medications.

2. Individuals should be able to decide (i.e., authorize) when their health data are shared, and with whom. Individuals should be able to refuse to make their health data available for sharing (i.e., opt-out). The XDS model at a high level supports a simple patient use consent policy allowing for the support of opt-in or opt-out depending on the way the specific HIE chooses. In this way a patient can choose to be included or not included in the HIE. This would be recorded at the edge application and controlled by that application.

In addition to this basic capability, the BPPC profile indicates the patient’s willingness to participate in the HIE, or to NOT participate. The BPPC profile is powerful enough to handle a small number of different policies that generally will cover most types of patients’ privacy consent.

The BPPC profile is not powerful enough to handle individual patient’s exceptions to the basic set of policies. We recognize that there are patients that want to single out individuals that are authorized and individuals that must not be given access. This more advanced level of control is not readily expressible in current standards. There is ongoing standards work within HL7 and OASIS to address this.

A powerful feature of the IHE model is a built in accountability system. The ATNA profile’s audit log can be examined for unacceptable behavior, and the HIE can react according to their Policy. For expressly sensitive patients, it might be best to keep their data within the edge application EMR and not share any of that patient’s data with the HIE.

3. Individuals should be able to designate someone else, such as a loved one, to have access to and exercise control over how their records are shared.

At this time the IHE BPPC profile does not fully enable this level of control. This level of control is simply not available in current standards, but is included in the ongoing standards development work.

One of the complexities is the need for a way to identify the delegated person without confusing that person’s identity. For example a guardian needs a guardian identifier that is distinct from their personal, patient or work identifier. The standard work groups are struggling with this issue.

Again, the ATNA audit log can show if the delegated individual was given access and if they are using it appropriately.

4. Individuals should receive easily understood information about all the ways that their health data may be used or shared.

The IHE solution does recommend that specific topics be covered in HIE creation of their Policy. The BPPC profile requires that the HIE publish their privacy policies. It is very important that these policies be understandable and complete.

5. Individuals should be able to review which entities have had access to their personal health data.

The IHE solution to the HIE requires that all edge applications that access the XDS Registry and Repositories must implement the ATNA profile. The ATNA profile includes a very detailed list of auditable security events and a schema for describing when one of these events happens. This list of auditable events includes:

• All publications are tracked as Export events
• All queries are tracked as patient specific queries
• All uses of documents are tracked as Import events.

These audit trails are user specific, and time synchronized. These audit logs can be used in the creation of an accounting of disclosures report

6. Electronic health data exchanges must protect the integrity, security, privacy, and confidentiality of an individual's information.

The following IHE profiles include methods to meet confidentiality, integrity, security and privacy of an individual’s information. Confidentiality

• ATNA: Encryption with 3DES or AES
• ATNA: All systems must authenticate users before providing access to PHI
• ATNA: Required audit log format and specific auditable events
• XDS: All Queries are patient specific
• XDS: Metadata has minimal PHI
  • Integrity controls: Times, size, hash, oid, uri
  • If Known: Author Institution, Author Name, Author Specialty
  • HIE specific: Healthcare facility type, Practice Setting code, Patient Identifier number, Document Format Code
  • Document MIME-TYPE
  • Document Source Specific: Patient demographics (Full Name, Gender, Date of Birth, and Address)

Integrity

• ATNA: Node Authentication with Certificates ensures non-trustable systems are kept out
• ATNA: Integrity using SHA1 to ensure the transaction is whole
• XDS: Integrity (SHA1) controls built into metadata to ensure the document lifespan is covered
• XDS: Document management model ensures that documents are not removed but are deprecated with clear successors
• XDS: Document model and standards formats ensure that the data can be maintained over long time
• DSG: Certificate based Digital Signatures can be applied to the documents

Security

• All parties are bound by the HIE Policy
• All systems must implement access controls that enforce the HIE Policy

Privacy

• All systems must implement access controls that enforce the HIE patient privacy use consent policy
• BPPC: all systems must further enforce the HIE set of patient privacy use consent policies
• ATNA: Provides accountability

7. Independent bodies, accountable to the public, should oversee the electronic health data exchanges. No single stakeholder group should dominate these oversight bodies. Consumer representatives selected by their peers should participate as full voting members.

IHE does not directly provide independent bodies to oversee the operation of a health information exchange. However, the IHE profiles provide standards based implementation guide for exchanging health information along with appropriate audit trails that can be leveraged by an oversight body.

• XDS family is all standards based ensuring that the information managed in XDS is not locked into a proprietary system
• XDS is document centric assuring Persistence, Stewardship, Potential for Authentication, and Wholeness.
• ATNA: All actions are discoverable allowing for monitoring for appropriate use, test for leaks. Security is an actively managed process allowing for oversight and vigilance.

Conclusion

The IHE solution provides much of the basic infrastructure necessary to build an HIE while supporting the Markle Foundation’s patient and consumer principles. The HIE must have good governance guided by Policies. These HIE Policies must drive a risk assessment. The HIE must be put together using standards such as those profiled by IHE. Given that important information needs to be secured and managed by edge applications in a way consistent with the HIE, one should leverage the edge applications security and privacy capabilities and configure them to enforce the HIE policies.

This paper has shown that there are known gaps in the handling of complex individual consents. These issues are currently being worked on in standards organizations with the expectation that more complex privacy consents can be handled in the future. For now these complex privacy consent conditions can be handled through selective publication.

There is room for optimizations to the solution, for example around federated user management, and centralized access control decisions. These improvements and optimizations are eagerly expected but require a maturity in many of the newer standards and technologies that are necessary to handle such sensitive data and such critical patient safety.

This paper has shown that the Markle Foundation Connecting for Health collaborative “Patient and Consumer Principles for System Design” can be addressed through the IHE Integration Profiles. This system is available today and has been shown in implementation demonstrations as well as used in multiple pilot projects in the USA and Europe.