Introduction
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 Program Final Rule (July, 2010), standards identified in the Final Rule for Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology (July, 2010) are most relevant.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:
- American Health Information Community (AHIC) Use Cases (2006-9)
- Direct Project User Stories
- Standards & Interoperability (S&I) Framework Use Cases
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).
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.
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: Another ONC-sponsored 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 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.
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 NwHIN Data Use and Reciprocal Support Agreement, or DURSA, is but one example). Finally, in March 2012 ONC released the Privacy and Security Framework Requirements and Guidance for the State Health Information Exchange Cooperative Agreement Program which offers some additional recommendations and requirements for state-level HIE grantees.
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:
- Security: The Electronic Healthcare Network Accreditation Commission (EHNAC) Health Information Exchange Accreditation Program (HIEAP) provides an independent assessment of an HIE's security and privacy policy and implementation. Some HIEs require EHNAC HIEAP certification. The National Institute of Standards and Technology (NIST) also provides some useful information on the HIPAA security rule.
- Consent: Much of the practical concerns related to privacy center around the policy and corresponding implementation of a patient's consent to disclose health information. A number of approaches have been taken by various states, and the National Governor's Association (NGA) Center for Best Practices Health Division provides useful guidance on this issue; HLN has also defined some Options for Storing Electronic Consent.
Additional standards include the use of HL7 v2 ADT messages to convey consent captured in EHR systems to HIEs, HL7's Version 3 Domain Analysis Model: Medical Records; Composite Privacy Consent Directive DSTU relevant for CDA documents, and IHE's Basic Patient Privacy Consents (BPPC) in a Cross Enterprise Document Sharing (XDS) environment. Some HIEs (particularly those based on the CONNECT Open Source product) support the OASIS Cross-enterprise Security and Privacy Authorization (XSPA) profile, which uses the eXtensible Access Control Markup Language (XACML), an access control language in XML.
The S&I Framework Initiative Data Segmentation for Privacy project is working to "Enable the implementation and management of varying disclosure policies in an electronic health information exchange environment in an interoperable manner."
- Authentication and Authorization: Security Assertion Markup Language (SAML) is often used to pass authentication and authorization information between systems participating in an HIE and the HIE itself. Another standard for maintaining clinical context between systems in an HIE is HL7's Context Management Specifications (CCOW) which allows one system to pass user credentials and/or patient search criteria to an HIE to facilitate a smoother query to an HIE portal through closer integration with a user's EHR system. Directory services provide a mechanism for an HIE to ensure that users (and other services) can be identified and validated.
- Transport: The transport strategies discussed above all have their own security protocols and strategies embedded within them.
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:
| Standard | Description |
|---|---|
| CMS' Healthcare Common Procedure Code System (HCPCS)/American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4) | This is the standard coding for procedures widely used in the healthcare community:
|
| Centers for Disease Control and Prevention (CDC) Vaccines Administered (CVX) and Manufacturers of Vaccines (MVX) Codes | 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, Ninth Edition, Clinical Modifications (ICD-9-CM) | This is the standard coding used for diagnoses and procedures by hospitals:
|
| International Classification of Diseases, 10th revision, Related Health Problems (ICD-10 CM) | This revision to ICD-9-CM contains a number of important improvements. This standard is not yet widely implemented. |
| 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. |
Pulling it All Together
A number of organizations and efforts try to pull together or harmonize standards across a number of areas, including:
- Care Connectivity Consortium: A group of leading private healthcare systems created this consortium to implement electronic records exchange for treatment purposes across their organizations by implementing a "private" network using NwHIN technologies and policies. By implememnting the network privately they are able to move faster than Federal NwHIN implementation and incorporate a broader set of data.
- EHR/HIE Interoperability Workgroup: This group is a collaboration of a number of State HIE projects, EHR system vendors, and HIE vendors whose goal is to draw from existing standards and publish a compendium of agreed-upon specifications to simplify the process of implementing interfaces. An initial set of documents are available upon request from the organization's website.
- Health Information and Management Systems Society (HIMSS): HIMSS is a large member organization that conducts many activities related to HIE, including an HIE Topics and Tools resource page, a standing HIE Committee, a new Interoperability & Standards Committee, and a monthly Information Xchange eNewsletter (subscription is free). HIMSS has a lot of good resources, though their website tends to list only material developed by its staff and members and not links to other material from other sites.
- 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)).
- Health Informatics Standards Users and Developers Portal: This resource is a little more academic in focus, and very much focused on an international audience. But it has sections for both developers and users with most of the information spread across several wikis.
- Office of the National Coordinator for Health Information Technology (ONC): Established by Congress in 2004, ONC is responsible for guiding and promoting health information technology nationally. A number of efforts are managed by ONC including the development and harmonization of standards to support a vision for a nationwide health information network (NwHIN).
- Standards & Interoperability Framework: This ONC-sponsored and supported project is in many ways a successor to the Health Information Technology Standards Panel (HITSP) and coordinates a number of standards harmonization projects. The S&I Community Enabling Toolkit (CET) explains the projects methodology and activities.
- State and Local Specifications: Many states have defined local specifications, architectures, and guidelines for HIE. These should be consulted as appropriate.