Health information exchange (HIE) is complicated and the standards that support them are abundant. Here is a quick (or maybe not so quick) guide to HIE standards. The guide is divided into a number of standards categories for easier navigation. The resources listed here are by no means exhaustive but do provide the most relevant material for understanding the landscape for achieving health data interoperability. For transactions supporting the Medicare and Medicaid Programs Electronic Health Record Incentive Programs see the Meaningful Use and Public Health page.

Additional background and information can be found in:

Process Standards

Process standards define how health data should be used within the workflow of the organizations participating in interoperability. Unless the participants understand the context within which data is being used the data itself may not be understood correctly. For many participants this is the least tangible type of standard. Functionality for interoperability is often described in use cases, user stories, and use narratives that describe the clinical or other healthcare-related functions being performed by the intended users. Some examples include:

In addition, HLN developed a set of normative HIE use narratives which cover a wide range of HIE scenarios.

Technical Standards

Technical standards are used to define the structure, syntax, and reliability of interoperable transactions. Structure and syntax often go together; reliability is largely a function of the transport mechanism selected for the transaction and the underlying stability of the network transporting it (usually the Internet).

Structure and Syntax

A number of standards and efforts are underway with respect to structure and syntax.

Health Level 7 (HL7) represents the core of standards-based interoperability. HL7 develops a wide range of standards beyond those used to represent the structure and syntax of messages, so only a subset will be discussed here. HL7 Version 2 messaging standards are the most dominant in the industry. They exist in multiple sub-versions which are not always compatible with one another. Due to their complexity, HL7 (and other organizations) provide implementation guides to help explain and define the nuances of using a particular message (or set of messages) in a particular setting. HL7 V2 messages are most commonly used to exchange laboratory orders and results, patient admissions, discharges and transfers from in-patient facilities, immunizations, and many other types of information. HL7 Version 3 messages are newer and not yet used much in the United States.

An additional standard — Clinical Document Architecture (CDA) — is sometimes confused with Version 3 messages but represents data in a different paradigm, that of clinical documents (see discussion on HIE and data formats). The most important and widely-used implementation of CDA is the Continuity of Care Document (CCD®). This format supports clinical summaries which contain a wide variety of information about a patient encounter and/or history available for system-to-system transmission and viewing through a standard web browser with the aid of an external style sheet that helps define the aesthetic look of the document. Its flexibility has led to a number of efforts to limit, or constrain, what might appear in a CCD to focus its use on a particular need or set of needs. The most important is the Health Information Technology Standards Panel (HITSP) C 32 specification which is referenced by many HIE deployments and many organizations. Though HITSP has been eclipsed by other activities, many of its artifacts continue to be foundational for healthcare data interoperability. The Consolidated CDA is a library of CDA templates bringing together the work of various organizations and is the basis for Meaningful Use clinical documents.

Finally, the newer HL7 Fast Healthcare Interoperability Resources (FHIR) provide another option for representing clinical content as either XML or JSON objects. FHIR resources are defined for most clinical content and can be assembled with as much or as little as is needed to fulfill a particular use case. While FHIR is simpler to use than any other data representations, it still needs to be consistently deployed among data trading partners to ensure compatibility. SMART Health IT represents one project promoting a constrained version of FHIR  to promote interoperability, and the Argonaut Project is a private sector initiative trying to leverage these advancements.


It is important that both parties participating in an interoperability transaction agree on the means that will be used to transport data reliably and securely. Various Federal, State and local laws exist to protect identifiable health data both in transit and at rest — these will not be dealt with here. The most common transport encryption protocol of the Internet is IETF Transport Layer Security (TLS) Version 1.2 (and sometimes only Version 1.0 based on the web browser)/Secure Socket Layer (SSL) Version 3.0. Many of the transport strategies identified below use TLS.

Additional transport strategies of interest include:

  • Direct: An ONC-sponsored open-source software project to develop an easy-to-use “push” technology for moving protected health information between known parties. It uses the paradigm (and much of the infrastructure) of e-mail. Participants need to acquire a “Direct address” (similar to an e-mail address) from a Health Information Technology Service Provider (HISP) and be included in a “trust domain” with the intended recipient (so that you can be sure the recipient is who s/he says s/he is). Many Direct projects are focused on creating or accessing electronic directory services.
  • CONNECT: An open-source software project to provide standards and tools for more sophisticated “pull” or “query” interoperability that can be used within a local, state, or regional HIE. It also forms the technical foundation for the eHealth Exchange (EHE, formerly the Nationwide Health Information Network, or NwHIN, Exchange), which originally provided interoperability for some key Federal agencies and their partners, but now allows any organization that signs its Data Use and Reciprocal Support Agreement (DURSA). Much of CONNECT is built upon IHE profiles. The EHE is now managed by the Sequoia Project (formerly Healtheway), a non-profit, non-government entity.
  • Web Services: Systems that implement a service-oriented architecture often use Simple Object Access Protocol, or SOAP, as the transport mechanism. This strategy is becoming more and more popular among EHR system vendors as it allows XML-based, system-to-system transactions to be constructed easily.
  • HTTP POST: Some processes will rely on the method used by web-based forms to send information filled in from a browser to a web server. This is a relatively simple, secure (if encrypted, typically with SSL or TLS) method for pushing data from one system to another (see also the S&I Framework’s RESTful Health Exchange (RHEx) project and HL7’s Fast Healthcare Interoperability Resources (FHIR) project).
  • Virtual Private Network (VPN): At its essence, a VPN allows a computer (or network) in one organization to function securely as if it is part of a secure network in another organization, often using the Internet as the connection between the two. This can be done using hardware or software-based solutions. Most often a VPN is used to create a point-to-point connection between two participants, but VPNs can become difficult to manage when many such connections are necessary. Note that a VPN by itself is not a transport solution; a transport protocol such as HTTP or FTP must be selected to run inside the VPN connection.
  • Proprietary Solutions: Many HIEs use proprietary, vendor-supplied solutions to transport data from one participant to another. These solutions may build upon one or more of the strategies identified in this section or may use different technologies.

For additional information see Architectures and Transport Mechanisms for Health Information Interchange of Clinical EHR Data for Syndromic Surveillance (ISDS, 2012).NIST also provides some transport testing tools.

Privacy and Security

In the US, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) is the primary guide for privacy and security of health information handled by health care providers, payers, data processors, and their business associates. HIPAA provides detailed guidelines, though it establishes a floor, not a ceiling, of guidance. Other federal laws, such as the Family Educational Rights and Privacy Act (FERPA) and 42 CFR Part 2 (Confidentiality of Alcohol and Drug Abuse Patient Records) impose stricter standards when health data is found in certain settings. Often state (and even local) law also imposes more strict requirements. When it comes to HIE, many things need to be taken into consideration including the legal environment and the standards of practice in the particular community or state.

The Federal Health IT Policy Committee has made several recommendations with respect to privacy and security. It is important that all HIE participants understand both the legal and policy framework within which they operate – data sharing agreements between HIEs and their participants often capture these understandings (the Sequoia Project Data Use and Reciprocal Support Agreement, or DURSA, is but one example). Finally, ONC maintains a set of resources on Privacy and Security Policy for HIEs which offers some additional recommendations and requirements.

Technical standards for privacy and security are still developing, but here are some useful guides. Note that while most of the policies mentioned just above apply to the US only, many of the technical standards below are international:

Semantic Standards

Semantic standards are concerned with preserving the meaning of data as it is sent from one organization or system to another by ensuring that consistent codes are used, or that codes are translated correctly. In many cases, semantic standards are embedded within the technical standards that use them (for example, many HL7 V2 messaging implementation guides include code tables for use in the messages).

Here are some key semantic standards in use; a more comprehensive set is included in the ONC Interoperability Standards Advisory (ISA) which is updated annually:

Standard Description
CMS’ Healthcare Common Procedure Code System (HCPCS)/American Medical Association (AMA) Current Procedural Terminology (CPT®) This is the standard coding for procedures widely used in the healthcare community
Centers for Disease Control and Prevention (CDC) Vaccines Administered (CVX), Manufacturers of Vaccines (MVX) Codes, and Vaccine National Drug Codes (NDC) These are widely-used codes for vaccines and manufacturers.
College of American Pathologists Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) This is the standard coding used for a wide variety of medical and health care terms.
International Classification of Diseases, 10th revision, Related Health Problems (ICD-10-CM/PCS) This revision to ICD-9-CM contains a number of important improvements.
Logical Observation Identifiers Names and Codes (LOINC®) This is the standard coding for laboratory and clinical observations used by health care systems and messaging (like HL7).
National Library of Medicine (NLM) Unified Medical Language System (UMLS) RxNorm This is the standard for coding the names of drugs and dose forms.
National Drug Code (NDC) This is a universal product identifier for human drugs.

Through its Public Health Information Network Vocabulary Access and Distribution System (PHIN VADS) initiative, the CDC promotes the use of standard vocabularies among its own projects as well as the activities of its Federal, state, local, and international partners. Access to PHIN VADS data is available both interactively via a public web page as well as system to system through a standards-based web service which allows local systems to draw upon semantic standards represented in VADS actively in system development or implementation. To help use vocabulary correctly, the United States Health Information Knowledgebase (USHIK) was created as a central repository of data elements and their corresponding attributes and meaning. The S&I Framework Public Health Reporting Initiative has released a Data Harmonization Profile which identifies the common, core data elements required for public health reporting across a wide variety of use cases. Both the structure/definition of data, as well as its coding, is provided within this documentation. Finally, the value sets relevant for clinical quality measures are captured and made available in the National Library of Medicine’s Value Set Authority Center (VSAC).

Pulling it All Together

A number of organizations and efforts try to pull together or harmonize standards across a number of areas, including:

HIE Consortia:

  • Commonwell Health Alliance, a consortium of leading EHR system vendors “devoted to the simple vision that a patient’s data should be available to patients and providers regardless of where care occurs” with an explicit goal “to adopt common standards and protocols to provide sustainable, cost-effective, trusted access to patient data.” Commonwell’s architecture is centered around a central coordinating hub with both a master patient index (MPI) and Record Locator Service (RLS) which acts as a broker for participating organizations in performing queries of patient data; it only returns an aggregated C-CDA document in response to a query. In December 2016 Commonwell and Carequality announced an interoperability collaboration.
  • The Sequoia Project, a non-profit, non-government entity formerly known as HealtheWay that now manages the eHealth Exchange (EHE, formerly the Nationwide Health Information Network, or NwHIN, Exchange). In February 2014 they launched Carequality, a new collaboration that they hope “will unify industry to adopt and implement a common health information exchange interoperability framework to interconnect healthcare organizations, vendors, providers and geographies, ultimately improving care outcomes, increasing efficiency and reducing healthcare costs.” Carequality facilitates point-to-point queries by providing a look-up service for participating sites, and the response to a query is not restricted to any particular data format. Currently, Carequality does not support an MPI or Record Locator Service, and responses to a query are not consolidated into a single document or message. In December 2016 Commonwell and Carequality announced an interoperability collaboration.
  • Strategic Health Information Exchange Collaborative (SHIEC) describes itself as a “national trade association for health information organizations.” One of its major projects is a Patient Centered Data Home project which “puts into practice the vision that clinical data should be available whenever and wherever care occurs.”

Standards and Enabling Initiatives:

  • DirectTrust is “an independent non-profit trade association created by and for participants in the Direct community, our common goal being to establish and maintain a national Security and Trust Framework in support of Direct exchange.”
  • Health Level 7 (HL7) represents the core of standards-based interoperability. HL7 develops a wide range of standards covering  many areas of health IT.
  • Healthcare Services Platform Consortium (HSPC): HSPC is a provider-led membership organizations whose mission is to “improve health by creating a vibrant, open ecosystem of interoperable applications, knowledge, content, and services.” Their primary activities involve creating a general-purpose healthcare systems-oriented architecture model and reference implementation to improve interoperability.
  • Integrating the Healthcare Enterprise (IHE): IHE is a collaboration of industry and other healthcare stakeholders which builds upon existing standards to define more precise interoperability specifications for particular transactions. Largely vendor-driven, IHE writes somewhat complicated “profiles” and encourage vendors to demonstrate their compliance at live “connectathon” events. Many EHR system vendors demonstrate compliance, though their ability to deploy compliant products “in the field” is sometimes limited. Of particular interest to HIEs are a set of IHE profiles related to IT Infrastructure which define core functionality for cross organization and cross community information exchange (see in particular Cross-Community Access (XCA),Cross Enterprise Document Sharing (XDS), Patient Identifier Cross Referencing (PIX)/Patient Demographics Query(PDQ), and Cross-enterprise Document Media Interchange (XDM)).
  • The National Association for Trusted Exchange (NATE) is a consortium of states focused on consistent implementation of the Direct protocol ultimately supporting interoperability with users between their jurisdictions.

Other Organizations and Efforts