HIE 101

Health Information Exchange 101

No two HIE organizations (HIOs) are alike, and more than one HIE solution may be available in a given public health jurisdiction. HIE standardization and accreditation are in their infancies, and some branches of the HIE evolutionary tree may yet become dead ends as others thrive. Therefore, health departments need to "look under the hood and kick the tires" when assessing available HIE options.

This section of the Public Health and HIE Toolkit builds on concepts introduced in What is HIE?, and will help to identify and put into context many of the HIE concepts, technologies and practices that will be important in the decision-making process.

Virtually all HIE employs the same Internet used by the general public. This means that there is no need for separate expensive "wiring" from one partner to the next, but it also means that privacy and security must be protected.

Basic Requirements

At the most fundamental level, several things are needed for one organization to send private health information another securely and confidentially:

  • The sender must assure the recipient's authority to see information (authorization) and confirm their identity (authentication). These are jointly referred to as identity management.
  • The information must be delivered to the appropriate address (email, drop-box, IP address, port or secure website).
  • Patient consent may be needed, particularly when dealing with highly sensitive information.
  • There must be a system for the sender to encrypt information, allowing only the intended recipient to decrypt it.
  • The sender must format the information so that the recipient's system can interpret it (e.g., Adobe Acrobat PDF files cannot be sent to most fax machines).
  • If the recipient intends to automate the management of incoming information, semantic interoperability is essential. Both sender and receiver must use compatible data elements - the "fields" in a database, or "items" in a form or questionnaire - and vocabularies - text- or machine-readable code standards, such as ICD-10, LOINC or SNOMED.
  • There must be agreement about the ways the recipient may use the information (e.g., can she sell it to Google?).
  • There must be trust between sender and recipient, often summarized in legal agreements (such as Business Associate or Data Use agreements) that spell out expectations and consequences for their violation. When such trust must extend to many different roles using information in different ways, a fabric of trust or trust framework is needed in order to successfully address these needs while protecting privacy and security.

Query / Assembly Requirements

To query and assemble a patient record from multiple provider record systems, the following requirements must also be met:

  • A way to find which providers hold records about which patient (record locator)
  • A system to assure that one patient's information from various sources can be matched and linked, without sending information about other patients with similar names (master person index [MPI])
  • A way to access information stored in others' information systems without threatening the integrity or security of their data

For an overview of other terms and acronyms that are sometimes confused with HIE, including their actual definitions and distinctions, see the following resource:

DOWNLOAD: Terms Confused with HIE

Going It Alone

Before HIOs emerged, many health department programs (like immunization registries or disease surveillance systems) established one-to-one exchange arrangements with several healthcare providers.

Given the complexity of managing multiple different exchange relationships, it's not surprising that this approach resulted in slow and uneven adoption by exchange partners. Recruitment of smaller doctor offices and hospitals often lagged, and many healthcare providers were left mired in hand-typing data into public health websites. Thus, many health departments have looked to HIOs, hoping that shared technology and uniform participation rules would accelerate exchange.

There are trade-offs, however. For example:

  • Since HIOs must operate, to some extent, by consensus, public health programs cannot always have exactly the exchange relationship they would like.
  • In some situations, more providers are already connected to public health systems (e.g., successful immunization registries) than to younger HIOs. Ripping out and replacing those connections may not make sense in the short term.
  • Some programs engage in a very intricate "push" and "pull" of information (e.g., when immunization systems seek to use EHRs to help clinicians manage inventory). Such complex "conversations" using web services go behond the current capabilities of some HIOs.

Using an HIO may not always be the best answer. The advent of DIRECT secure email may also make it simpler in the future to push messages without an HIO.

Sharing the Load

HIOs work by supplying both a shared set of core technical services and a shared set of participation agreements that simplify exchange between multiple partners. These shared technologies and participation agreements are the building blocks that then permit many different services and products to be offered to members.

The information governance of the HIO, which usually includes considerable member representation, directs the development of both technology and agreements. Health departments will need to asses whether HIO agreements and governance structures are appropriate to public health needs, and should consider seeking a role in governance if they join.

Core Technologies

Secure Internet technology delivers encrypted information only to authorized users, who are listed in a directory. Portals are designed for data viewing by various users (providers, health departments, patients). To assemble and provide information about a patient from multiple providers, a record locator service and a Master Person Index (MPI) are required to accurately match and link records.

Some HIOs also provide a shared service called normalization, sometimes referred to as integration capability. This service converts information to the standardized machine-readable formats and vocabularies that enable semantic interoperability. Normalization services may be optional, and affect the price of participation. Other HIE organizations may depend heavily on their members to normalize data before sharing.

The software for HIE services is rarely developed from scratch. Several vendors have emerged to support exchange, making the evaluation of vendor performance and dependability an essential part of assessing an HIE solution.

Technical Architectures

HIOs offering "pull" query exchange have different technical architectures related to accessing data, each with different advantages. These may include centralized, decentralized or hybrid architectures. A concise comparison of these architectures is found in the HIMSS resource HIMSS HIE Presentation Putting the HIE into Practice (starting on page 10).

Few health departments will be in a position to "pick" an HIE architecture unless they are engaged in forming or governing an HIE organization, but understanding the risks and benefits of each may help inform choice when competing HIE options are available.

Participation Rules

Membership agreementsdata use/sharing agreements and other participation rules about sharing and using information are as critical as the technology. For example, always requiring patient consent before information is shared may void the usefulness of HIO for public health functions like mandatory reporting.

Use Case Services and Products

HIOs and members can use the "push" and "pull" technologies separately or in combination to design many different services that meet communication needs for different types of users. These are what customers really want and use. The "story" that defines what a service or product will deliver is called a use case. HIOs may use this term, or the terms exchange services or products or functional capabilities, to describe the value they can provide to members.

As an example, lab results can be pushed to ordering physicians, to a public health surveillance program, or directly to patients - all different use cases. Information about an Emergency Department visit might be messaged to a public health syndromic surveillance system, or to the members of a patient's care team (also different use cases). A query of multiple providers' medical records might be used to support Emergency Department care for an individual patient (one use case), or to assemble a statistical portrait of diabetes across a community (a very different use case).

DOWNLOAD: HIE Services and Data Sharing Examples

Once a large number of members begin exchanging a wide variety of information, the number of possible use cases becomes enormous. Different HIOs offer different assortments of these services, and establish new service offerings on an ongoing basis according to member demand. Now that the EHR Incentive Program ("Meaningful Use") is creating nationwide incentives and standards for HIE use cases, several involving public health reporting, these will likely be offered by more HIE organizations and will use more uniform technology standards.

DOWNLOAD: Public Health HIE Use Cases


Ten years ago, there was a largely shared vision of HIE. This focused on regional collaborations among healthcare providers, and often included health departments and insurers. These regional health information organizations (RHIOs) are typically not-for-profit, though they may deploy software from a for-profit vendor. These were typically viewed as utilities, serving virtually all providers in a community. RHIO members connect using many different brands of EHR systems, typically participate in governance, and support the organization through membership and/or use fees. These organizations have developed and operate successfully in many communities. However, different technical and organizational developments have spawned alternative models that have called into question the long-term prospect of the "universal utility RHIO" model.

Other HIOs focus on a common EHR system, sharing among different customers working with a particular EHR vendor. While relatively simple technically, this approach may create barriers for providers using a different EHR brand. As more universal standards emerge for inter-HIE exchange, however, these barriers may lower.

Some HIOs begin by serving a selected network of organizations, such as those serving military personnel and veterans, members of an Accountable Care Organization (ACO) or community health centers belonging to a Health Center Controlled Network.

The 2009 HITECH Act funded states and their State-Designated Entities (SDEs) to assure state-wide HIE services, and to support a nationwide model of change. Some SDEs accommodated existing HIOs, while other competed with them. SDEs have quasi-official status in many state governments, so they are powerful features of the HIE landscape, though federal funding is rapidly waning and the importance of SDEs in relation to other HIE initiatives is likely to evolve.

Also, large provider integrated delivery networks (IDNs) or hospital provider systems may launch an HIO. These may or may not have a separate organizational structure, such as an LLC. It is anticipated that these enterprise HIOs will continue to grow and develop, especially in areas that may not have another HIO option available.

The business model for HIOs keeps changing rapidly in response to both technical and public policy developments. In this tumultuous environment, there has been considerable turnover of HIOs across the nation. Picking a long-term HIE partner ideally includes selecting a management team that studies and responds promptly to such environmental changes.

If a health department's frequent information sharing partners, or trading partners, aren't connecting to an HIO, there will be no benefit no matter how elegant the technology.

In addition to the different organizational models listed above, two alternate systems for sending health information have emerged that call into question the model of an HIO at the center of all such "push exchange."

Patient ability to View, Download and Transmit (VDT) EHR information has been required for Meaningful Use certified EHR systems, and a new Blue Button+ standard enables downloading record files for personal use, as well as to transfer them to a third party. This "patient-mediated exchange" enables a possible alternative system for exchanging health information online.

Such exchange may end up being very helpful for voluntary patient sharing of information with health departments (for example, during disease outbreak investigations) or research, but may not prove satisfactory for population-wide surveillance. It is important to note, howeer, that if patient-mediated exchange becomes very widespread, it might decrease the demand for HIE-mediated exchange, and thus disrupt the business model of HIOs.

Another alternative is to enable the secure emailing of messages between EHRs and other health information systems without requiring a full-scale HIE in the middle. This is facilitated by the development of an open-source protocol called Direct (also sometimes written as DIRECT or NwHIN Direct), and its required inclusion in Meaningful Use certified EHR technology. 

Senders are required to have the appropriate email address for one another, and to use a Health Information Service Provider (HISP) to assist with encryption and decryption. Theoretically, if both EHRs and public health information systems were all equipped to send and receive Direct messages, and if they could easily access address directories and HISP services, and if a set of generalized trust agreements appropriate to public health were developed, Direct services might reduce the need for HIO involvement in information exchange. Today, many - if not most - HIOs are beginning to provide the HISP role, so it is too early to know if Direct messaging risks undercutting the HIO business model (and revenue streams) in a significant way.

Decentralized information exchange protocols like Direct and Blue Button+ don't necessarily make the future of HIE organizations untenable, but they do add some flexibility to the notion of an HIO sitting in the middle of most "push" messaging. A forward-looking health department will monitor these developments, assessing their impact on the business models of HIOs with which they are working, and adjust their approach to secure messaging over time.


There is no single nationwide HIE organization, but HIOs in different parts of the country still need to exchange information with one another - for example, when a Florida hospital admits a vacationing patient from Ohio. The Office of the National Coordinator for Health Information Technology (ONC) sponsors efforts to standardize different use cases and governance policies for exchange under the lable Nationwide Health Information Exchange (NwHIN).

ONC currently oversees open-source development of the CONNECT gateway (formerly known as NwHIN, or NHIN, CONNECT). CONNECT is considered a reference implementation for inter-HIE exchange, meaning that it embodies the current standards for national exchange prescribed by ONC. The software code can be used to create a new HIO, and it may be used by other exchange software vendors to enhance their products.

Although there is currently (summer 2014) no "NwHIN compliant" certification for HIOs, compliance with NwHIN standards should be considered a routine part of evaluating any HIE opportunity in order to assure national connectivity.

The eHealth Exchange, previously known as the NwHIN or NHIN Exchange, is a public-private network of nearly 40 participants including federal agencies, states, Beacon communities and over a dozen HIOs and health systems. They use a shared trust framework and a set of technical standards for coast-to-coast exchange. eHealth Exchange members originally used the CONNECT gateway, but the network now says it anticipates most members will use commercial solutions. The eHealth Exchange is supported by Healtheway, a non-profit corporation.

The Centers for Disease Control and Prevention (CDC) also continues to support a framework for public health information exchange, the Public Health Information Network (PHIN), which is foreseen as becoming integrated and consistent with the NwHIN over time.


HIOs today may bring to mind the old phrase about health departments:

"If you've seen one HIO, you've seen one HIO."

At this point, although some states require local registration, certification or accreditation, there is no single widely recognized certification or accreditation for HIOs. However, a handful of efforts are currently underway:

  • Direct Trust and the Electronic Healthcare Network Accreditation Commission (EHNAC) have been selected by the ONC to perform accreditation of Direct messaging, one of the core infrastructure services needed by HIE service providers.
  • EHNAC also offers a separate HIE Accreditation Program which assesses the entire HIO, including a site visit, rather than just the software or technical compliance. However, as of March 2014, only four organizations had been accredited, with four more in "Candidate" status.
  • In March 2013, the Certification Commission for Health Information Technology (CCHIT) announced a pilot of a voluntary compliance testing and certification program for HIE software products, but not for the organizations that use them.
  • eHealth Exchange states that it will deem technical solutions, presumably including HIE software, that meet all of its interoperability tests as "Exchange Ready," but has not yet (March 2014) released a list of such products.

As the information in this section illustrates, it can be difficult to keep track of changing concepts, labels, policies and organizations in the HIE space. A helpful review of the historical evolution of the HIE domain is available in the HIMSS resource HIMSS HIE Presentation: The Basics.

Continue to Next Page: Deciding to Engage

Navigate the Toolkit


Deciding to Engage

Engaging with HIE

Case Studies

Toolkit Downloads

A PDF of the complete Toolkit can be downloaded on the Public Health & HIE Toolkit Downloads page.  The PDF includes illustrations, footnotes and references not visible using the web version.  Individual tools and reference materials can also be downloaded from the Downloads page.

Return to the Public Health & HIE Toolkit Homepage.