Iguana User Conference 🏔️ May 6-8  Denver, CO

The Complete Guide to HL7

What is HL7?

Health Level Seven (HL7) is the standard that ensures data consistency across disparate systems, and plays a major role in healthcare interoperability.

Learn more about working with HL7.

HL7 Standard Versions

Contents

A
A Practical Guide to HL7 Interface Development: Building Custom Integrations for Healthcare Systems
Download the FREE Guide

Background: HL7 Standards

Since the late 1980’s HL7 has developed a framework for modelling, exchanging and integrating electronic health information across systems. HL7 standards can be divided into three versions: HL7 Version 2 (v2), Version 3 (v3) and FHIR.

HL7 Timeline

While most HL7 messaging uses versions 2.3 and 2.3.1, it is important to understand the differences between the 2.X and 3.X versions in order to properly address the unique interfacing needs of your organization or project.

HL7 Version 2

HL7v2 is the most widely used healthcare messaging standard for exchanging clinical and patient information between systems. The goal of HL7v2 was to provide enterprise-wide interoperability between health information systems using standardized messages representing clinical event information - such as patient administrative activities, demographics, medical orders, results and financial information. 

With no other standards available at the time, a custom HL7v2 format was created based on pipe and hat encoding and has continued to be developed “ad hoc” over the years. All v2.X versions maintain backward compatibility to ensure legacy and modern applications can communicate simply by ignoring unexpected content or repetitions. 

The HL7v2 standard is not a complete plug-and-play solution for interoperability and it is often referred to as the “non-standard standard” as it provides around 80% of the interface foundation with 20% still requiring some customization on an interface-by-interface basis. This is due to the nature of healthcare and its different interactions with patients, healthcare personnel, clinical and operational data. Each hospital, urgent care center, ambulatory care facility, imaging center, laboratory, and other care facilities have unique clinical systems and operations, making each implementation of HL7 require a slightly unique representation of the data. The standard enables this flexibility through allowing flexibility in defining optional and repeating segments, optional fields, and additional custom z-segments.

HL7 Version 3

HL7v3  has been developed over a 10+ year period using lessons learned and best practices from previous versions with the goal of creating a more firm and context rich standard that supports healthcare workflows through the exchange of data between healthcare organizations and providers. HL7 developed v3 based on a methodology of shared models, the Reference Information Model (RIM), enabling more reuse, standardization and format consistency. XML is used as the message syntax for a more human readable, but larger message. 

Due to several reasons, including its complexity and the fact that HL7v3 is not backwards compatible with HL7v2.X, has hindered its adoption across healthcare organizations with existing v2 implementations. HL7v3 is primarily referenced when implementing Clinical Documentation Architecture (CDA) for exchanging electronic documents, typically between provider and patient or for public health and quality reporting initiatives.

FHIR (Fast Healthcare Interoperability Resources)

FHIR is the latest standard to be developed under the HL7 organization.  Pronounced ‘Fire’ , FHIR stands for Fast Healthcare Interoperability Resources. It is a standard for exchanging healthcare information electronically and combines the best features from HL7 v2, HL7 v3, and CDA, while also adding several significant improvements over previous standards. 

FHIR includes data formats (resources on patients, medications, encounters, etc.) as well as application programming interfaces (APIs) that exchange these resources. It was developed to become a dominant standard that allows external parties to access information from EMRs through the use of applications. It also allows third parties to create their own applications that can access these servers. For example, EHRs such as Epic and Cerner, have their own FHIR app stores where providers (doctors, clinicians, etc.) as well as patients can access their data through these 3rd party applications. FHIR standards utilize SMART (Substitutable Medical Applications, Reusable Technologies), an authentication framework for the connection of 3rd party applications to EMRs.

Comparatively, FHIR offers several advantages over existing HL7 standards: 

  • Ease of implementation is at the core of the FHIR standards design. Therefore, it is quick and easy to create interfaces
  • It offers many implementation libraries, providing the resources necessary to jump-start interface development
  • Specification is free for use, and presents no restrictions
  • In many cases, FHIR’s base resources are robust enough to be used as-is, but they can also be adapted to meet more specific requirements.
  • FHIR cooperates with previous HL7 standards
  • Based on RESTful web services rather than SOAP web services, allowing for basic HTTP operations including Create, Read, Update and Delete
  • FHIR “modules”, or “resources”, can be combined in order to present more holistic data sets, and allows for a more manageable approach to providing clinical solutions.
  • Provides a basic set of data resources that can satisfy most use cases. 

Similar to the previous HL7 standards, FHIR has also undergone several rounds of versioning, with each new version implementing changes and improvements around resource types, bindings, code elements, modifier statuses and default values:

 

Dec 27, 2018 4.0.0 Release 4 (1st Normative Content and Trial Use Developments)
Feb 21, 2017 3.0.0 Release 3 (STU - Standard for Trial Use)
Oct 24, 2015 1.0.0 DSTU2 (Second Draft Standard for Trial Use)
Sept 30, 2014 0.0.82 DSTU1 (First Draft Standard for Trial Use)

 

Each FHIR version is both forwards and backwards compatible, allowing for older specification versions to remain interoperable with future versions. Iguana is able to support all four FHIR versions and has the flexibility to allow SMART on FHIR applications to be built within it. These applications are able to connect to EMRs and can be authenticated according to SMART standards. In addition, SMART on FHIR apps built within Iguana can be made to adhere to Da Vinci Project use cases.

To learn more about how Iguana can assist in connecting to EMRs through the use of SMART on FHIR application or for anything else integration related, contact us.

Challenges with Different HL7 Versions

Each version of the HL7 standard aims to be more robust by building on the strengths of its predecessor. However, to fully support the exchange of healthcare data, HL7 standards need to be both backwards and forwards compatible which, unfortunately, is not always a straightforward process.

How does Iguana support different HL7 Standard Versions?

Are you working with systems that each implement a different version of HL7? Iguana is a data integration platform that allows you to seamlessly convert from one HL7 version to another. Whether you are looking to connect a legacy or modern application, with Iguana you can map forwards or backwards from any version of HL7, ensuring that you have a normalized set of messages to work with.

Get a demo: See Iguana's HL7 mapping schemas in action

Easily parse and map data from one version of HL7 to another using Iguana. We'll walk you through how it's done:

Request a Free Demo