Health-information exchange: why are we doing it, and what are we doing?

Abstract

Health-information exchange, that is, enabling the interoperability of automated health data, can facilitate important improvements in healthcare quality and efficiency. A vision of interoperability and its benefits was articulated more than a decade ago. Since then, important advances toward the goal have been made. The advent of the Health Information Technology for Economic and Clinical Health Act and the meaningful use program is already having a significant impact on the direction that health-information exchange will take. This paper describes how interoperability activities have unfolded over the last decade and explores how recent initiatives are likely to affect the directions and benefits of health-information exchange.

Introduction

A vision of health-information exchange as a key enabler of high-quality and efficient healthcare has been in place for more than a decade, and various policy approaches have been used to advance capabilities in this arena. The advent of the Health Information Technology for Economic and Clinical Health Act (HITECH) and meaningful use is adding the latest chapter to the efforts. The goal of this paper is to review the motivations for health-information exchange, what has been done about it previously, what the latest approaches may portend, what benefits may be realized in the near term, and what benefits may take longer to realize.

Need for interoperability and early work by the Office of the National Coordinator for Health Information Technology

In the 1980s and 1990s, such leading healthcare organizations as Intermountain HealthCare, Partners HealthCare, and Wishard Memorial Hospital began to demonstrate the quality and efficiency potential of electronic health records (EHRs). However, even in the midst of those successes, it became clear that there are key healthcare problems that ‘siloed’ EHRs do not solve. Examples of problems that could only be addressed by interoperability included support for the patient across transitions of care, the ability to perform longitudinal analyses of care, and public-health needs. Key hurdles to solving the interoperability problem recognized at that time included the need for standards to represent clinical data, the need to identify a patient consistently as they moved among different providers and a framework to assure the patient's privacy. There were also questions of who should play a leadership role to address these issues and the kinds of organizational models that could best support interoperability.

In November 2001, the National Committee for Vital and Health Statistics (NCVHS) published a report titled ‘A Strategy for Building a National Health Information Infrastructure (NHII).’¹ The report noted that such a capability would improve response in individual and public-health emergencies, reduce unnecessary care, decrease the likelihood of adverse events, improve patients' self-management capabilities, and generally enable improved management of chronic disease. The report noted that an NHII would positively impact the quality, safety, cost, and efficiency of care. The report recommended that the Department of Health and Human Services (HHS) should lead a public–private process to advance the effort. The proximity of the report to the events of September 11, 2001 helped add urgency to the problem.

In 2004, President Bush established the Office of the National Coordinator for Health Information Technology (ONC) within HHS to advance broad adoption of EHRs. The ONC strategic framework included interoperability as a key component.² Since there was no direct governmental financial support for the adoption of EHRs, interoperability was appealing because enabling providers to ‘connect to’ something might increase the value of an EHR sufficiently so that a provider might be enticed to adopt it.³ Health-information exchange was felt to be feasible because leading communities (eg, Indianapolis) had demonstrated regional interoperability. ONC established the Health Information Technology and Standards Panel (HITSP) to harmonize the standards necessary to support data sharing. ONC promoted the concept of regional health information organizations (RHIOs), which would address the governance, privacy, business, legal, technical and other organizational issues necessary to implement health-information exchange. The Agency for HealthCare Research and Quality (AHRQ) funded five state and regional health-information exchange demonstration projects. By 2010, the eHealth Initiative reported that there were 73 operational health-information-exchange initiatives nationwide.⁴ These initiatives typically were supporting the exchange of visit data, laboratory results, medications, allergies, and radiology reports. A key component of many of the initiatives is a ‘record locator service,’ which serves to identify all the locations where a patient has received care. Increasingly, the term ‘health-information exchange’ (as a noun) is being used to represent an organization that addresses the business issues of interoperability, though the term RHIO also continues to be used.

Early Nationwide Health Information Network projects

To demonstrate that creating regional exchanges would not result in simply larger silos, ONC funded the $18.6 million Nationwide Health Information Network (NHIN) Prototype Architecture initiative, which ran from late 2005 to early 2007. The four projects in the program demonstrated that health-information-exchange initiatives could be successfully connected to one another using a ‘network of networks’ approach that did not require a national patient identifier or a large-scale centralized operation. These lessons affirmed that regional health-information exchanges that ‘played by the rules’ would be able to participate in a nationwide network. ‘Playing by the rules’ meant using standard data services, consent services, security services (such as user authorization and auditing documentation), and other network management services.⁵

Following the completion of the NHIN prototype projects, in 2007 ONC chartered the NHIN Trial Implementations project. The purpose of this project was to demonstrate data exchange among operational health-information exchanges. Nine communities were the initial participants; eventually a total of 20 organizations participated. The specific goals included demonstrating the ability to (1) identify a patient across disparate health-information exchanges, (2) retrieve the patient's clinical data from the other exchanges and display the aggregated data, and (3) incorporate patient permissions. The project also sought to demonstrate that technical specifications to support eight interoperability use cases that had been specified by the American Health Information Community (AHIC) could be developed and implemented. These eight use cases included:

1. EHR-laboratory results—incorporate new lab results into the ordering clinician's EHR;

2. emergency responder—provide the clinician with access to the patient's data in an emergency scenario;

3. medication management—support access to the patient's medication and allergy data in a medication reconciliation scenario;

4. quality—communicate quality-related information from a provider organization to another organization;

5. social security administration (SSA)—allow the SSA to retrieve the patient's data to make a disability-benefits determination;

6. biosurveillance—data collection to support situational awareness, event detection, and outbreak management;

7. consumer access to clinical information—allow consumers to access their data via a personal health record; and

8. consumer empowerment—allow the consumer to authorize the provider to have a view of his or her data.

For each use case, a formal technical ‘interoperability specification’ was developed by HITSP. Each interoperability specification described in detail the software services and data structures that the participants in the Trial Implementations project needed to adhere to. Examples of services were patient identification, data retrieval, consent services, and security services (eg, declaration of who is the data requester and audit trail information). Examples of data structures included patient summary records, detailed medication data, detailed laboratory data, and consent declarations. The interoperability specifications also referenced base standards (eg, HL7, Systematized Nomenclature of Medicine, Logical Observation Identifiers, Names, and Codes, etc) as well as composite standards in which base standards would be combined to create a standard for a particular function—for example, the Integrating the Health Enterprise (IHE) Cross-Enterprise Document Sharing (XDS) profile. In general, the interoperability specifications were comprehensive because they needed to take into account all potential actors, actions and events in the use case. A diagram of the interoperability use case for the integration of laboratory results into the EHR is shown in figure 1.⁶ The NHIN Trial Implementations project was completed in the fall of 2008, with a demonstration of the exchange of data among operational systems. Mock data were used because a data-sharing agreement that took into account all the relevant state healthcare privacy laws had not been developed by the time of the demonstration.

Figure 1.

Graphical depiction of EHR-Laboratory Results Interoperability Specification. Reprinted from HITSP Electronic Health Records Laboratory Results Reporting Interoperability Specification, Version 2.1, p8. Cxx, component; CDA, Clinical Document Architecture; ebRS, eBusiness Registry Standard; IETF, Internet Engineering Task Force; IHE, Integrating the Healthcare Enterprise; ISO, International Organization for Standardization; NAV, Notification of Document Availability; PDQ, Patient Demographic Query; PIX, Patient Identifying Cross-reference; TPxx, transaction package; XD-Lab, Sharing Laboratory Reports; XDS, Cross-enterprise Document Sharing.

The NHIN Trials Implementation project has continued in an operational mode as the NHIN Exchange.⁷ An open-source version of the Exchange protocols is available through the Connect project.⁸ Participants in the Exchange initiative include the Social Security Administration, the Department of Defense, Kaiser-Permanente, the Veterans Administration, and MedVirginia (a health-information exchange in Virginia). These organizations have signed data-sharing agreements, have completed technical testing and are now exchanging live patient data.

Advent of HITECH

In 2009, the election of the Obama administration heralded a fundamental shift in the country's health-information technology and health-information exchange policy. The HITECH act introduced $14–27 billion of net incentive funding directly for EHRs. With direct financial incentives for the adoption of EHRs, the relative role of interoperability as a driver of adoption was decreased. However, interoperability remained a key component of the nation's health IT strategy. For example, the State HIE Cooperative Agreement Program awarded by ONC in March 2010 provided $548 million for 56 states and territories to expand their HIE capabilities in support of healthcare quality and efficiency improvement. In addition, several of the stage 1 meaningful use objectives, which were announced in mid-2010, involve health-information exchange.⁹ For example, to achieve stage 1 meaningful use, providers must demonstrate that their certified EHRs can exchange key clinical data among providers. One of the ‘menu set’ stage 1 meaningful use objectives is for a provider to transmit a summary record electronically in the course of a referral or other patient transition. Other meaningful use objectives involve interoperability in one form or another—for example, e-prescribing (the ability to route a prescription to a pharmacy), providing patients with access to their clinical data, the ability to integrate laboratory results into the EHR, and the ability to report immunization and surveillance data to public health authorities. Eligible providers are required to report quality measures electronically to the Center for Medicare and Medicaid Services (CMS) as part of stage 1 meaningful use and eligible hospitals likely will be required to do so in future stages. The interoperability-related EHR certification criteria were more modular and EHR-focused than the interoperability specifications that had been developed for the Trial Implementations project.

The final rules regarding meaningful use and EHR certification allow a fair amount of flexibility about how providers and hospitals can meet the interoperability-related meaningful use objectives as long as criteria related to vocabularies and data structures are met.¹⁰ Implementing the Connect protocols would be one approach. However, several stakeholder groups expressed concern that the Connect protocols were overly complex for initial levels of health-information exchange and that the excessive complexity would unnecessarily increase the costs of EHRs to providers.

In response to the concerns, based on guidance from the NHIN Workgroup of the ONC Health IT Policy Committee, the NHIN Direct project was initiated in the beginning of 2010.¹¹ (In October 2010, the project was renamed the ‘Direct’ project.) The goal of Direct is to create specifications to enable the secure exchange of health information between authorized healthcare providers to support stage 1 meaningful use. Specifically, the policies and specifications that would be developed under the Direct project would allow an authorized provider to send a patient's health information to another authorized provider. An analogy for Direct is email, whereby a person can send a message to another person as long as the recipient's email address is known. The Direct protocols have several features distinct from regular email—for example, the ability to keep information private and the ability to assure that senders and recipients are authorized.

Direct services are designed to support such use cases as (1) a primary care physician (PCP) sending a patient summary to a specialist as part of a referral, (2) a specialist sending their findings to a PCP, (3) an acute care facility sending a discharge summary to the patient's subsequent care giver, (4) a care provider sending a visit summary to a patient, (5) a provider sending a reminder to a patient for needed care, and (6) the transmission of results from a laboratory to an EHR. A guiding vision for the Direct project is to provide services that would allow an EHR to be used to replace paper-based methods of communications between healthcare providers. The goal of the Direct project is to develop specifications that EHR vendors can integrate into their product offerings, which would enable eligible providers to meet stage 1 meaningful use information exchange objectives. Pilot implementations of Direct services were announced in early 2011.¹²

Direct is an example of a ‘push’ model of health-information exchange. The Connect protocols support push-based transactions but also support a ‘pull’ of data, that is, the retrieval of data from multiple sources. The Connect protocols enable aggregation of a patient's data across a community, whereas Direct services would not.

There are notable examples of successful health-information exchange initiatives that use a push model. Founded in 1997, the New England Health Exchange Network (NEHEN) offers administrative and clinical data exchange services based on sending and receiving messages.¹³ Since 2004, the Indiana Health-information exchange (IHIE) has provided an electronic results and document delivery service to clinicians in a multistate region.¹⁴ These push-oriented initiatives do not require a record locator service or a consistent patient identifier. They do, however, require a sufficient mass of data providers and of recipients who are eager to receive the data.

The constrained information flows supported by Direct and other push models of health-information exchange leverage existing privacy frameworks. The ONC Privacy and Security Tiger Team recently recommended that for stage 1 meaningful use, directed exchange of health information for treatment should not require patient consent beyond what is required by to make a disability determination law or has been customary practice.^{15 16} Federal privacy guidelines for more complicated models of health-information exchange, for example, retrieving a patient's health data from multiple sources with a single query, have yet to be created.

A push model, such as Direct, avoids problems that arise when trying to integrate a patient's data across a community. Most notably, it is not necessary to link a patient's identifiers across systems before data can be transferred. The cost and complexity of developing a record locator service, as well as developing privacy policies to support the retrieval of data from multiple sources, can be avoided. An inbound message is linked to a particular patient file by the message recipient, and the linking may be done manually.

If Direct services are to provide clinically useful health-information exchange capabilities, there are important related challenges that will need to be addressed. Directories will be needed to represent healthcare organizations as well as individual providers. Methods will be needed to allow an authorized sender to look up an authorized recipient. The Information Exchange Work Group of the ONC Health IT Policy Committee is developing recommendations to promote the creation of such provider directories.¹⁷ An overall trust fabric¹⁸ that includes business, policy, and legal requirements; transparent oversight; enforcement and accountability; identity assurance; and minimum technical requirements will need to be established. A governance model will be needed to develop the relevant policies and a process to assure compliance. At a technical level, the Direct project has grappled with coordinating the addressing and transport of messages between healthcare organizations. These issues need to be handled in a way that supports security and does not disrupt the way organizations manage messages internally.^{19 20}

Implementation of Direct services may present some pragmatic challenges as well. For example, if a small physician's office receives a message containing a patient's data, it might be easy to use the patient's name to find the corresponding patient record. Large organizations, such as academic medical centers that have large registration databases, may have several patients with the same name; linking an incoming message to a specific patient's chart may be time-consuming and complicated. Also, even in small practice settings, it is unclear how much volume might be generated by incoming messages. An undesirable outcome would be to have provider offices overwhelmed by messages appearing in the EHR's inbox, akin to email overload.

From a policy perspective, an interesting question is: What proportion of the problems that health-information exchange was intended to solve would the Direct project solve? It is not possible to answer this question directly, but to get a sense, we could return to the use cases proposed by the AHIC for the NHIN Trial Implementations. This list is not sacrosanct in anyway, but it represents a set of interoperability goals that was identified previously by a federal advisory committee. The use cases that rely predominantly on one party sending data to another party could be satisfied solely by the Direct approach; those that require the aggregation of the patient's data from a broad set of locations cannot. Thus, delivering laboratory results to an EHR, supporting the transmission of quality reports to a central authority (assuming all the requisite data are available), biosurveillance, and sending a visit summary to a patient could be satisfied by the implementation of Direct protocols. Allowing an emergency provider to retrieve all the data known about the patient and allowing the Social Security Administration to retrieve all the patient's data to make a disability determination could not be satisfied solely by Direct services. Some forward-looking approaches could leverage a Direct-based model to allow a patient to aggregate data from a collection of providers and even forward the data to other providers.²¹ Certain medication reconciliation scenarios could be satisfied by Direct services (ie, those where the relevant providers are actively sending the patient to a new setting) but trying to retrieve a patient's medication history from all the providers in a community would not be supported as easily.

From an informatics perspective, the Direct project offers a model of health-information exchange that is more constrained than models that involve record locator services. Whereas the Direct project supports the transmission of messages between providers, more complex protocols are needed to support the retrieval of data across an entire community. The ability to push clinical data from one provider to another and the ability to pull clinical data from an entire community are distinct approaches to health-information exchange; each addresses a set of problems in healthcare. Most clinicians would agree that they would like to have both approaches available to them in the care of patients. ONC has been vocal that the Direct project is not an end in itself and is not an alternative to approaches to interoperability that allow all the patient's data to be aggregated. Indeed, ONC has noted that the Direct project is intended to be a first, perhaps easier, step that allows eligible providers to meet the objectives of stage 1 meaningful use and allows both providers and EHR vendors to participate in interoperability activities. ONC notes that the Direct project and the retrieval capabilities of Connect are complementary components of a complete ultimate interoperability vision. Eventually, the nation will need interoperability capabilities that are robust enough to support innovative healthcare delivery models, such as those that will be piloted under the Affordable Care Act.

The way that RHIOs choose to make best use of the Direct project remains to be seen. Many RHIOs have created policy and technical infrastructures to support a “pull” approach to health information exchange. As RHIOs grapple struggle to support interoperability-based services that improve the quality and efficiency of care, they will have the opportunity to understand how best to combine pull- and push-oriented capabilities. A state that is developing a health-information exchange strategy as part of its response to the ONC's State HIE Cooperative Agreement Program will have to determine how Direct-based health-information exchange will fit in with its plans.

Lastly, the Direct project is relatively recent. The vision emerged in early 2010, and there is much to be learned about the technical, policy, privacy, security, and business aspects of this approach to interoperability as well as the clinical problems that it will solve. Direct has a strong chance of being an important step forward. It remains to be seen how much of the interoperability problem it will solve and what other components are needed to meet the interoperability needs of clinicians, the needs of the healthcare reform program, and the vision of interoperability that was laid out over a decade ago.