FHIR vs. HL7: We explain the key differences

Historically, access to healthcare information has been largely restricted to the application within which it was collected. Because there are so many different applications that can collect clinical information, it can be difficult for clinicians caring for a patient to get the complete picture of the person’s current health. There are numerous examples of where actual patient harm — including death — has resulted from this lack of access to data.

The Health Level 7 (HL7) standard was developed by a group of highly dedicated volunteers who formed the HL7 committee in 1987 to address the growing challenges associated with connecting data among healthcare applications. This initial group of volunteers, and thousands who have since followed, continue to give their time in building what is the foundation on which most clinical interfaces are now deployed.

A standard is simply a commonly agreed way of doing something, and they are widely used in our society. Basic examples include the voltage in our electricity supply, the grades of petrol used in our vehicles, or the rules that apply to driving on our roads.

In the technology world, the adoption of standards has allowed cell phones from different vendors to talk to each other, banks to support e-commerce applications, and airlines to allow external applications to make reservations. While these activities are still possible without standards, it is considerably more difficult for a vendor to deal with a number of different, bespoke interfaces rather than a single, commonly used one.

Healthcare has always had standards, of course. Health Level-7 (HL7) is a collection of data definitions and message formats that allow the integration of healthcare systems. HL7 is also the name of the ANSI-accredited organization that defines the HL7 standard. HL7 has been defining and refining the HL7 standard since 1987. Its members include healthcare providers, healthcare vendors, and consultants dedicated to creating a flexible protocol for healthcare integration. 

In recent years, there have been a number of changes in healthcare data.

• The volume and variety of information has expanded enormously, driven largely by devices of many sorts (including personal ones) and the availability of genomic data
• Population health analytics and quality metrics requires vast amounts of data from many different sources to function effectively
• The complexity of healthcare continues to expand, making easy access to decision support services an increasing requirement
• There has been an increased demand for real-time access to data. As the use of mobile devices has exploded, so has the need for information to be available immediately upon request
• And most importantly, there has been a big demand from the consumers of healthcare for their data to be freely available — both to their providers and to themselves — regardless of where it was captured. And a side-effect of this access has shown that the quality of data collection is often not optimal.

In 2011 HL7 commissioned the “Fresh Start” project to consider how best to meet these needs. Coordinated by Grahame Grieve, this resulted in the FHIR standard, now in its fourth release.

FHIR (Fast Healthcare Interoperability Resources) was initially thought of purely as an interoperability standard, but as its use has grown and the community has grown, it has expanded into other parts of healthcare. It’s possible to think of FHIR in three ways:

• The core specification
• Adapting it for specific uses (Profiling)
• Other standards and uses that build on FHIR as a core capability.

This article offers a deep dive into the differences between HL7 and FHIR. It’s intended to help industry insiders and newcomers better understand how healthcare standards have evolved over time and what’s on the horizon.

Subscribe to our newsletter and stay up to date on all the latest FHIR news.

What is HL7?

Health Level Seven International, a non-profit organization dedicated to developing standards for the exchange of electronic healthcare data, created the HL7 standard. 

HL7 is a set of international exchange standards used to transfer and share data between various healthcare providers. More specifically, HL7 helps bridge the gap between health IT applications and makes sharing healthcare data easier and more efficient when compared to older methods.

Most healthcare providers use a variety of applications for everything from billing to keeping up with patient information. The problem is that communication between these different types of software is hard to achieve, even though they often need to “talk to” each other. 

More challenges arise when two healthcare providers need to share information. HL7 provides several standards and guidelines to help software vendors and healthcare providers store and uniformly move data.

In short, HL7 aims to make exchanging data easy, which in turn reduces the administrative burden on providers and staff while improving care delivery.

What is HL7?

To set the context for both HL7 V2 and V3, it’s important to understand the user types of the messaging standards and how each user type influences the development and use of the standard. Users can be divided into three segments:

1. Clinical interface specialists who are tasked with moving data, creating tools to move data, or creating clinical applications that need to share or exchange data with other systems. These users are responsible for moving clinical data between applications or between healthcare providers.
2. Government or other politically homogeneous entities that are looking to the future of sharing data across multiple entities or in future data movement–generally, few legacy systems are present. Often these users are looking to move clinical data in a new area not covered by current interfaces and have the ability to adopt or mandate a messaging standard.
3. Medical informaticists who work within the field of health informatics, which is the study of the logic of healthcare and how clinical knowledge is created. These users seek to create or adopt a clinical ontology–a sort of hierarchical structure of healthcare knowledge (a data model), terminology (a vocabulary), and workflow (how things get done). An informaticist is interested in the theoretical representation, semantic interoperability, and extensive modeling of the acts and actors of healthcare.

HL7 V2

Before HL7 V2, every interface between systems was custom designed and required programming on the part of the sending and receiving application vendors. Interfaces were expensive because there was no standard collection of patient attributes or standard set of “interesting events.”

The primary reason for the challenge of interfacing is that as internal hospital teams or software vendors create new clinical applications, each application is developed without input or collaboration with other application development teams. That is, rarely do commercial development teams share proprietary data on how their applications are built so it is difficult for other teams to build compatible applications.

Some forward thinking, like-minded healthcare community members formed a volunteer group to make interfacing “easier.” HL7 was born.

HL7 V2 is a well-established standard that works well within institutions to connect applications. This standard has unique syntaxes, custom tools, and a hefty learning curve for those entering the healthcare IT industry. The standard’s design is also limiting to modern devices and apps that are trying to access and make use of patient data. Privacy and security are also difficult to implement. These limitations have become a barrier to patient engagement and making patient data available in the most convenient formats.

When most people say “HL7” they are referring to “HL7 V2.” 

HL7 V3

The fact that HL7 V2 interfaces still require some amount of local negotiation, sometimes large amounts, is a major shortcoming of the V2 standard. In the 1990s, a subset of the HL7 standards community decided to address some HL7 V2 challenges.

HL7 V3 provides more rigid messaging rules for HL7 messages and was born out of the desire to make a standard that was plug-and-play.   

It used modern standards technologies available when it was released in the early 2000s. HL7 V3 ended up being overly complex to implement with a steep learning curve. It also had no backward compatibility with HL7 V2, which made switching to the new standard even more complex given how embedded HL7 V2 is within the U.S. healthcare system.

It’s important to recognize that HL7 V2 was initially created by clinical interface specialists, while V3 has been strongly influenced by medical informaticists. Consequently, the initial use case and focus for each standard is keenly different.

HL7 CDA

HL7 CDA (Clinical Document Architecture), first introduced with HL7 V3, standardizes the specific framework and language of clinical documents. This was done to support the transfer of documents between those involved in patient care. It is most commonly used for inter-enterprise information exchange

HL7 CDA was incorporated into the Meaningful Use criteria, a federal incentive program in the U.S. that was designed to promote the use of a certified EHR system in hospitals, and thus has broad penetration in that country. However, HL7 CDA has limitations: 

• Due to the same complexity as HL7 V3, the learning curve is still steep
• Interoperability beyond a human-to-human level is still challenging
• CDA documents do not fit well in many workflows
• Extensibility is difficult

What is FHIR®?

Fast Healthcare Interoperability Resources (FHIR®), released in 2014, began with an open-ended question: What would health data exchange look like if we started from scratch using modern approaches? To answer this question, the HL7 International organization turned to other industries for ideas. 

Interoperability successes in other industries pointed strongly to the use of RESTful based APIs.

The FHIR standard is based on the following simple five key points: 

1. Faster to learn and implement 

2. Lower cost 

3. Scales well from simple to complex 

4. Flexible 

5. Free

For a closer look at these key points, skip to HL7 FHIR differentiators.

FHIR® has been steadily gaining traction since its initial draft release in 2014. Two advancements have drastically increased the adoption of FHIR. 

In 2019, HL7 International released FHIR R4, the first normative version — meaning future changes to the standard will be backward compatible. Then in March 2020, two divisions under the U.S. Department of Health and Human Services — the Centers for Medicare and Medicaid Services (CMS), and the Office of the National Coordinator for Health IT (ONC) — published two rules requiring the use of FHIR APIs for data exchange between providers, payers, and patients.

What are FHIR Resources?

Resources are small, logically discrete units of exchange. Resources:

• Define behavior and meaning
• Have a known identity and location
• Are the smallest possible unit of transaction
• Provide meaningful data that is of interest to healthcare. 

Resources are sometimes compared to an HL7 V2 segment. Resources can be extended and adapted to provide a more manageable solution to the healthcare demand for optionality and customization. See Table 1.

Table 1: Resource Examples

 

 

Learn more about FHIR

FHIR: The basics (blog): FHIR will allow clinicians to become more involved in the delivery of health-related IT projects – it is widely recognized that clinician led IT projects have a higher success rate than technically led ones. FHIR® represents a major standards upgrade that will boost access to health information, which will improve access to a patient’s electronic health record.

FHIR, the CMS & ONC Rules, & COVID-19: What Health Leaders Need to Know: (blog and video): With the interoperability rules from the ONC & CMS, and COVID-19, data exchange with FHIR is critical. Here’s what health leaders need to know now. 

FHIR: 3 Real-world scenarios: (blog and video) Learn about FHIR use cases for prior authorization support, payer coverage decision exchange, and medical reconciliation process. Links to additional tools: IHE profiles, HL7 FHIR Guides.

Converting data feeds to FHIR: (blog) Mapping language offers a vendor-agnostic approach to the tricky issue of conversion between FHIR and other message standards.

What are the similarities between HL7 and FHIR?

HL7 and FHIR can be thought of as two siblings from the same family, as both were cultivated and developed by Health Level Seven International.

FHIR combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. FHIR is based on modular components called “resources,” which can be combined to solve clinical and administrative problems in a practical way. They also are built with strong forward/backward compatibility rules for seamless integration, while taking advantage of the extensibility element that makes the FHIR specification simple for everyone.

The advantage of FHIR is that all advancements made through the HL7 V2, V3 & CDA development stages comes built in to the wider, more modern ecosystem. This includes the introduction of HL7 RIM (Reference Information Model), which formed the foundation of all information modeling with the release of HL7 V3. This Reference Information Model was developed with the combined consensus of the HL7 working group and HL7 partners to create a static model of healthcare information as viewed within the scope of HL7.

What are the differences between HL7 and FHIR?

FHIR can meet the needs covered by HL7 V2, V3, and CDA, and provide further benefits for ease of interoperability. In addition to the functionality of these previous standards, FHIR engages REST APIs and open web technologies such as JSON and RDF data formats that may be more familiar to developers, minimizing the potential learning curve.

The critical integration of REST APIs in tandem with previously available functions opens the possibility for more diverse interoperability services, such as with medical and mobile devices, mobile apps, and wearables.

Tables 2 through 5, below, offer a detailed look at the differences between FHIR and HL7 standards.

Table 2: HL7 V2 and FHIR

 

 

Table 3: HL7 V3 and FHIR

 

 

Table 4: HL7 CDA and FHIR

 

 

“As FHIR starts to take off, it’s not going to displace the existing standards,” says Drew Ivan, chief strategy officer at Rhapsody. “There are a lot of existing interfaces built on standards like HL7 version 2, CCD, and DICOM. The volume of migrating them to FHIR is too big of an effort to contemplate when it’s already working fine. Plus, these [older] standards were built to solve a specific problem, and even though there’s a new standard coming out—FHIR—that doesn’t mean that the problems those old standards have solved have gone away.”

 Watch Interoperability Evolved: Connect/21 Keynote with Drew Ivan. 

What is HL7 FHIR?

HL7 FHIR and FHIR are interchangeable names for the same standard. While some may refer to it simply as FHIR, HL7 denotes that the standard was created by Health Level-7 International. Whether written as HL7 FHIR or simply FHIR alone, both reference the same standard.

HL7 FHIR differentiators

HL7 FHIR differentiates itself from past standards technologies by focusing on the following: 

• Focus on those who are implementing the standard 
• Ensure common scenarios are easily supported
• Leverage cross-industry web technologies 
• Require human readability as base level of interoperability, same as CDA 
• Make the standard freely available 
• Deliver flexibility by supporting multiple paradigms and architectures 
• Provide for modern governance of data 

Focus on the implementers

HL7 FHIR was written with implementers as the target audience in mind. Of high importance was the use of reference implementations, which were incorporated into the design of FHIR from the beginning. Robust testing was deemed important as well for implementers, which led to the availability of public test servers. 

Starter APIs have been made available for a variety of programming methods including C#, Java, JavaScript, Objective C, and Delphi. And to allow implementers to test with others along the way, Connectathons were established to verify specification approaches and continue at HL7 workgroup meetings.

Support for commonly used workflows 

The content in the core specification is meant to cover the top 80% of use cases. This is similar to the focus of the HL7 V2 standard, only the extensions will be cleaner and easier. The idea is to focus on the real needs of the industry but allow for all the special use cases as well. HL7 V3 was commonly criticized for trying to account for too many use cases in the core standard, thus leading to an overly complex standard that was difficult to achieve

Embrace web technologies 

The use of RESTful web services as an API has been on the rise over the last decade across all industries. RESTful web services is embraced by organizations such as Facebook, Twitter, and Amazon as their primary API. In addition, related technologies such as XML, JSON, and Oauth, are also common when dealing with encoding and authorization. These technologies have well supported tools and a large talent pool of IT resources. Thus, healthcare will not be locked in to unique industry standards, but it can embrace what is used across all industries.

Human readability

The concept of human readability being the minimum level of interoperability was introduced with the CDA standard. The idea is that if none of the structured data is able to be imported into the receiving system, the data could be viewed in a standard web browser. HL7 FHIR continues with this concept to ensure that human readability will always be an option.

Paradigms for packaging the payload

HL7 FHIR supports four interoperability paradigms, which are distinct ways of using FHIR to best accommodate varying workflows. The four paradigms and when they might be used are:

• REST: Small, light-weight exchanges with low coupling between systems
• Messages: Communicate multiple resources in a single exchange
• Documents: Focus is on persistence when data spans multiple resources
• Services: Use a custom service when capabilities of other paradigms don’t fit requirement

Regardless of the paradigm, the content is still based on resources. The resources are just bundled into different data sets depending on the paradigm.

Table 5 details some of the key differences among the paradigms.

 

 

Which is better HL7 or FHIR?

When it comes to picking a winner between HL7 and FHIR, the question is not which is better, but rather, which is better suited for your use case.

The good news is that even as FHIR proliferates in healthcare, it will not displace existing standards. All those investments made into HL7 interfaces will continue to remain relevant, and there will be no immediate need to migrate them.

Many of the recent directives by the CMS and ONC mandate the use of HL7 FHIR APIs for patient access to data and anti-information blocking initiatives. Taking advantage of this new data sharing paradigm creates the opportunity for new data and new clinical insights that promote quality data sharing and improving patient care.

Kindle your FHIR knowledge with our training.

Start your path to FHIR adoption and integration now.

Ready for a demo with a FHIR expert? Schedule one now.