FHIR vs. HL7: Key Differences and Which Is a Better Choice?

Navigating the intricate world of healthcare data standards? Uncover the key differences and strengths between HL7 and FHIR, the revolutionary standards shaping healthcare interoperability today. This deep dive will clarify common misconceptions and talk about how these standards are helping to build a more efficient, interconnected healthcare ecosystem.

For many years, the lack of a health data exchange process resulted in poor care coordination and patient performance. Now, we have revolutionary standards that allow better patient care, reduce the cost of care, improve healthcare efficiency, and exchange health data securely. 

HL7 standards and FHIR are widely used within global healthcare. So it’s no wonder the FHIR vs HL7 topic is popular. In our previous publications, we discussed the importance of seamless data exchange and described how to facilitate healthcare interoperability.

Today, we will talk you through the most transformative healthcare standards and define the difference between FHIR and HL7. The development of health data standards has led the world to an understanding of health data accessibility and exchangeability significance and allowed us to build a modern healthcare ecosystem based on interoperability principles. 

What Is the Difference Between HL7 and FHIR?

Despite their commonality, that is an incorrect formulation of the question. 

Health Level 7 International is a not-for-profit ANSI-accredited standards-developing organization. Its goal is to develop standards and provide a framework for exchanging, integrating, and retrieving health data that supports clinical data practices and management, delivery, and evaluation of health services. 

FHIR is the standard developed by Health Level Seven International, as well as other standards whose names start with HL7. FHIR is an innovative healthcare standard that summarizes strong points, fills gaps in previous HL7 standards, and employs existing web technologies that simplify its implementation.
FHIR profiles are a key feature of the FHIR standard, allowing for the creation of specialized data definitions and constraints to support specific use cases and interoperability requirements within the healthcare industry.

What Is HL7?

HL7 (Health Level Seven) is the organization that created HL7 V2, HL7 V3, CDA, the HL7 FHIR standard, etc. Most of the standards are widely used around the world today. 

Most of the standards defined by HL7 are widely used worldwide by various healthcare providers to ensure the simplicity of data transfer. Standards developed by HL7 help minimize administrative burdens and focus on quality healthcare delivery.  

Standardization of healthcare is necessary to achieve a uniform mechanism of health information processing and exchange. HL7 specifies the number of healthcare standards that define rules for communication between various health systems. 

The newer standard of HL7 targets implementers, not clinicians. Such an approach considerably simplifies implementation and stimulates developers to create new healthcare IT solutions.

HL7 V2

Health Level Seven Version 2 (V2) is a messaging standard that allows communication between various systems within a hospital. HL7 developed this standard back in 1989 to ensure enterprise-level interoperability in healthcare. It is the world’s most widely implemented healthcare standard—95% of US healthcare organizations use HL7 V2.x.

Technical characteristics

StructureMessage built with text, pipes, and hats
PurposeMedical record and events exchange
LearningHas a big learning curve
Platforms supportEMR, EHR, HIS, LIMS
ExtensibilityNon-extensible
Interoperability typeSyntactic
SecurityOn the transmission layer
Code systemsLimited support to ICD, LOINC, DICOM
CompatibilityBackward compatible with all V2 versions
SamplesAvailable
Required toolsHL7 Message Parser

Use cases: HL7 V2 messages allow data transmission between systems (e.g., admit discharge transfer patients, medical prescriptions, financial transactions, observation results, measurement results). 

Let’s look at the HL7 ORU (Observation Result) message. Clinical system A sends the Observation Result message in response to a request created in clinical system A. ORU messages include the following types of observations: lab results, EKG results, study reports, symptoms, allergies, etc. 


Message Structure: HL7 V2 message consists of texts, pipes, and hats.

MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|iFW|XYZ|||ORU^R01|MESA3b|P|2.4||||||||
PID|||CR3^^^ADT1||CRTHREE^PAUL|||||||||||||PatientAcct||||||||||||
PV1||1|CE||||12345^SMITH^BARON^H|||||||||||
OBR|||||||20010501141500.0000||||||||||||||||||F||||||||||||||||||
OBX|1|HD|SR Instance UID||1.113654.1.2001.30.2.1||||||F||||||
OBX|2|TX|SR Text||Radiology Report History Cough Findings PA evaluation of the chest demonstrates the lungs to be expanded and clear. Conclusions Normal PA chest x-ray.||||||F||||||
CTI|study1|^1|^10_EP1

The HL7 V2 message includes the following segments:

  • The Message Header (MSH) – a required segment that cannot be excluded. It consists of data about the message sender and recipient.
  • The Patient Identification (PID) – segment includes demographic data of a specific patient (identifier, name, date of birth). PID segment is required. 
  • Patient Visit (PV1) – a required message segment with patient visit details (visit ID, caregiver, servicing facility).
  • The Observation Request (OBR) – a required segment that allows the identification of the observation ordered for Observation Result message generation. 
  • The Observation Result (OBX) – an optional segment that includes information about the observation result. This segment identifies the type of observation, its result, the date of observation, and observation-related information. The segment can be repeated.
  • Clinical Trial Identification (CTI) – this segment links the result to a clinical trial. This segment is optional and can be repeated. The segments contain the clinical trial identification information, phase, and time point of the study. 

The HL7 V2 standard is suitable for communication between systems with no option to store data in databases. This type of messaging works for data transmission between medical systems in one organization and cannot scale across different organizations.

HL7 V3

In the early 2000s, the recognition of data importance in the context of healthcare workflows became obvious and pushed HL7 to develop a more comprehensive messaging standard. 

As a result, they introduced the Health Level Seven Version 3 (V3) standard, which represents all the data needed for healthcare interoperability. This standard is based on a common Reference Information Model (RIM), which constitutes a universal reference model for all information that needs representation within healthcare.

Reference Information Model example

All RIMs implementation is obligatory for all users of the third version of HL7, which makes the implementation process too complex and costly.

Technical characteristics

StructureStructured message in XML format
PurposeMedical record and events exchange
LearningTakes months to learn
Platforms supportEMR, EHR, HIS, LIMS
ExtensibilityNon-extensible
Interoperability typeSyntactic and Semantic
SecurityOn the transmission layer
Code systemsAllows ICD object embedding; LOINC and DICOM can be embedded in a RIM object. 
Samples
Required toolsModel compiler

Use cases: The HL7 V3 standard was developed in response to data exchange gaps that could not be fixed with HL7 V2. This standard was meant to cover the same use cases as the previous HL7 standard and address communication issues within healthcare.

Message example:

<observationEvent>
   <id root="2.16.840.1.113883.19.1122.4" extension="1045813"
       assigningAuthorityName="GHH LAB Filler Orders"/>
   <code code="1554-5" codeSystemName="LN"
         codeSystem="2.16.840.1.113883.6.1"
         displayName="GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN"/>
   <statusCode code="completed"/>
   <effectiveTime value="200202150730"/>
   <priorityCode code="R"/>
   <confidentialityCode code="N" 
      codeSystem="2.16.840.1.113883.5.25"/>
   <value xsi:type="PQ" value="182" unit="mg/dL"/>
   <interpretationCode code="H"/>
   <referenceRange>
      <interpretationRange>
          <value xsi:type="IVL_PQ">
          <low value="70" unit="mg/dL"/>
          <high value="105" unit="mg/dL"/>
        </value>
        <interpretationCode code="N"/>
      </interpretationRange>
   </referenceRange>

The HL7 V3 message consists of three layers: 

  • Transport Wrapper – this level contains all the message transport information, such as the data about the sender and receiver and systems interaction ID message.
  • Event Wrapper – contains information about the event, defines its type, trigger, responsive parties, and the date on which the event occurred.  
  • Domain Payload – the core layer of the V3 message that includes the administrative and clinical data.

Thanks to the RIM, the third version of the standard covers every possible healthcare use case imaginable, which made the V3 an unbearably complex and cost-prohibitive standard with a big learning curve.  

HL7 CDA

CDA (Clinical Document Architecture) is a flavor of HL7 V3. CDA is a document markup standard that defines the structure of clinical documents to establish the exchange of clinical data between patients and caregivers. CDA defines the following characteristics for all clinical documents: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness, and 6) Human readability.

Technical characteristics

StructureXML document
PurposeClinical document exchange
LearningTakes months to learn
Platforms supportEMR, EHR, HIS, LIMS
ExtensibilityNon-extensible
Interoperability typeSyntactic and Semantic
SecurityOn the transmission layer
Code systemsAllows ICD object embedding; LOINC and DICOM can be embedded in a RIM object. 
Samples
Required toolsModel compiler

Use Cases: The Clinical Document Architecture is used to exchange data about the patient. A typical CDA includes text, images, sounds, and other content. CDAs are widely used across healthcare within hospitals, immunization clinics, and other types of healthcare organizations.

Message example:

<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" xmlns:cda="urn:hl7-org:v3" xmlns:sdtc="urn:hl7-org:sdtc">
	<!-- ** CDA Header ** -->
	<realmCode code="US"/>
	<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
	<!-- US General Header Template -->
	<templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2014-06-09"/>
	<!-- *** Note: The next templateId, code and title will differ depending on what type of document is being sent. *** -->
	<templateId root="2.16.840.1.113883.10.20.22.1.8" extension="2014-06-09"/>
	<id extension="TT988" root="2.16.840.1.113883.19.5.99999.1"/>
	<code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" code="18842-5" displayName="Discharge summarization note"/>
	<title>Community Health and Hospitals: Discharge Summary</title>
	<effectiveTime value="201409171904-0500"/>
	<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
	<languageCode code="en-US"/>
	<setId extension="sTT988" root="2.16.840.1.113883.19.5.99999.19"/>
	<versionNumber value="1"/>

The full-size example is available in the CDA examples repository on GitHub.

CDA Document Structure:

  • Header includes metadata and sets the context for the document. The information in the header covers the CDA creation date, its creator, organization, and the related patient.
  • Bodycontains human-readable and machine-readable content for the document in non-XML format. The body represents the authenticated clinical report.  
  • Section(s)a combination of one narrative block and zero-to-many entries. 
  • Narrative Block(s) a text section representing the content for viewing.
  • Entries discrete data for machine processing. 

CDA includes all the patient-related information, including medical history, medications, insurance, lab results, and more. A clinical document includes detailed information about a patient that healthcare providers can freely exchange.

What Is FHIR?

FHIR is the data exchange standard produced by HL7. Its goal is to speed up and simplify the development of IT solutions that address healthcare interoperability challenges. This standard is a collection of specifications that define its elements and data formats. 

FHIR is based on HTTP protocol and supports the RESTful API approach. So, what is the FHIR standard? REST is a widely used exchange standard that defines a set of operations within an application programming interface, such as create, read, update, delete, and more. REST APIs simplify data migration between servers and separate clients from a server. That improves the scalability of a FHIR data model. The FHIR standard enables the development of tools for fast access and exchange of EHRs data. 

Technical characteristics

StructureMessages in XML/JSON; access is based on REST API 
PurposeHealth data exchange
TrainingTakes weeks to learn and adopt
Platforms supportEMR, EHR, HIS, LIMS applications
ExtensibilityFeatures extensible resources
Interoperability typeSyntactic and Semantic
SecurityBuilt in the transmission layer; allows SSL usage
Code systemsAllows ICD object embedding; LOINC and DICOM can be embedded in a RIM object. 
SamplesA catalog of samples is available on the FHIR website.
Required tools

Use cases:

An FHIR resource or a combination of resources can cover the most common use cases within healthcare. FHIR provides a seamless exchange of lab test results, clinical letters, scans, and other documents that affect the patient’s outcome.

FHIR functionality is based on REST API, which defines a set of operations on a resource. CRUD operations are the most commonly used for interaction with an FHIR resource within an FHIR server.

Let’s take a look at the structure of the FHIR Diagnostic report resource. A report usually includes the actual text report, images, and codes. The Diagnostic report resource allows laboratory reports (e.g., clinical chemistry), imaging and radiology (x-ray, CT, MRI), pathology, gastroenterology reports, and other diagnostics. 

In the case of lab test results, the resource allows sharing information about a laboratory test and the specimen. You can find more information on messaging using FHIR Resources at hl7.org/fhir to compare FHIR to HL7 V2 messages. 

Message example:

{
  "resourceType" : "DiagnosticReport",
  "id" : "ultrasound",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2><span title=\"Codes: {http://snomed.info/sct 45036003}\">Abdominal Ultrasound</span> (<span title=\"Codes: {http://snomed.info/sct 394914008}, {http://terminology.hl7.org/CodeSystem/v2-0074 RAD}\">Radiology</span>) </h2><table class=\"grid\"><tr><td>Subject</td><td><b>Jim </b> male, DoB: 1974-12-25 ( Medical record number: 12345 (use: USUAL, period: 2001-05-06 --&gt; (ongoing)))</td></tr><tr><td>When For</td><td>2012-12-01T12:00:00+01:00</td></tr><tr><td>Reported</td><td>2012-12-01T12:00:00+01:00</td></tr></table><p><b>Report Details</b></p><p>Unremarkable study</p></div>"
  },
  "status" : "final",
  "category" : [{
    "coding" : [{
      "system" : "http://snomed.info/sct",
      "code" : "394914008",
      "display" : "Radiology"
    },
    {
      "system" : "http://terminology.hl7.org/CodeSystem/v2-0074",
      "code" : "RAD"
    }]
  }],
  "code" : {
    "coding" : [{
      "system" : "http://snomed.info/sct",
      "code" : "45036003",
      "display" : "Ultrasonography of abdomen"
    }],
    "text" : "Abdominal Ultrasound"
  },
  "subject" : {
    "reference" : "Patient/example"
  },
  "effectiveDateTime" : "2012-12-01T12:00:00+01:00",
  "issued" : "2012-12-01T12:00:00+01:00",
  "performer" : [{
    "reference" : "Practitioner/example"
  }],
  "media" : [{
    "comment" : "A comment about the image",
    "link" : {
      "reference" : "DocumentReference/1.2.840.11361907579238403408700.3.1.04.19970327150033",      "display" : "WADO example image"
    }
  }],
  "conclusion" : "Unremarkable study"
}

A resource consists of four parts:

  • Metadata – contains the resource details (date of the resource creation, resource version ID)
  • Narrative – the HTML representation of the resource’s content; the human-readable summary. 
  • Extensions – the part of a resource used to add data that initially is not a part of a defined resource structure.
  • Standard data – the block includes the medical record number, patient name, gender, birth date, info about the care provider, etc.

As you can see, an FHIR resource has a user-friendly structure. All the data, including coded elements, are represented in human-readable form. The standard leverages existing web technologies, encouraging developers to create new healthcare IT solutions. 

What Are the Similarities Between HL7 and FHIR?

HL7 and FHIR standards are parts of one family of standards. HL7 and FHIR protocols vary since FHIR sticks to commonly used web technologies and protocols. However, FHIR includes all the best features and practices of previous HL7 standards. 

For example, CDA and HL7 V3 both are based on RIM, and FHIR includes many components of CDA that are used for exchanging information about the patient. 

The FHIR interoperability standard brings the concept of resources as the smallest exchange unit within healthcare, which becomes a solution to clinical and administrative issues. Resources can be extended to fit a specific use case, making the FHIR standard way more flexible in comparison to HL7 V2, V3, and CDA.

Pros and Cons of HL7 and FHIR?

FHIR is a part of the HL7’s family of healthcare standards, which is the best choice for ensuring interoperability in healthcare. However, implementation of the standards has its pros and cons that should be noted by healthcare stakeholders:

Pros:

  • Wide Adoption: all HL7 standards, including FHIR, are globally recognized and ensure consistent data exchange.
  • Backward Compatible: FHIR, compared to some previous standards by HL7, prioritizes backward compatibility, easing communication between older and newer systems.
  • Specific Messaging: Tailored messaging solutions for various healthcare scenarios support standardized data exchange.

Cons:

  • Legacy System Compatibility: Some legacy healthcare systems may not support FHIR, requiring hard work to ensure semantic interoperability in healthcare. 
  • Learning Curve: Despite accessibility, professionals may need time to learn these standards for effective implementation.
  • Data Security: When implementing any healthcare standards, complying with data privacy regulations is a must to avoid catastrophic consequences of healthcare data breaches.

In summary, FHIR, among HL7 standards, excels in achieving semantic interoperability in healthcare. The choice between different HL7 standards should align with an organization’s needs.

Comparison of FHIR With HL7 (V2, V3, and CDA)

V2 is a legacy system that defines messaging only. The standard doesn’t cover data storage and interoperability problems. The V2 message has an outdated design that does not help the scalability and is impossible to read for non-V2 experts. 

V3 is HL7’s attempt to build an electronic healthcare model with rigid types and XML-based messaging. The HL7 V3 introduces the concept of RIM (Reference Information Model), which represents a static model of healthcare information. It provides messages, terminologies, and data types. 

FHIR is the implementers-focused standard that relies on the open-source paradigm. It is published on the page https://hl7.org/fhir/. Unlike previous healthcare standards, it is available for study and use. Accessibility of the standard greatly contributes to the community interest and involves developers in standard development and testing.

It should be noted that regardless of whether HL7 or FHIR are revolutionizing healthcare interoperability and paving the way for seamless data exchange and integration in the industry.

Making the Choice: Considerations and Decision Factors

There’s no universal choice between FHIR and other HL7 standards, but there are several aspects to consider before adopting any of the healthcare data standards by HL7:

  • Resources: Evaluate expertise and technology availability. FHIR may appeal to web-savvy developers but may require training costs and additional time. Hence, it is better to go for the help of certified FHIR experts at Edenlab when adopting the FHIR standard.
  • Scalability: Pick solutions with proven scalability, for example, the Kodjin FHIR Server: its performance and scalability are proven under national-level healthcare projects. 
  • Industry Trends and Requirements: Stay updated on industry standards. FHIR aligns with evolving data exchange requirements and healthcare data privacy laws.
  • Use Cases: Analyze data exchange needs. For instance, the HL7 V2 is suitable for data exchange between systems within one organization, while FHIR excels in complex scenarios supporting global interoperability in healthcare.

In short, base your decision on your organization’s unique requirements, existing infrastructure, and long-term goals.

Summary

We tried to demystify the false ideas about HL7 and FHIR and define the main differences between previous HL7 standards vs. FHIR. Here at Edenlab, the creators of the Kodjin Interoperability Suite, we focus on interoperability challenges. For more than seven years, we’ve been helping our customers solve healthcare data management issues.

Contact us if you want to know how to apply healthcare standards for your project. Our team will be pleased to meet your needs.

Frequently Asked Questions:

Why is FHIR better than HL7?

When choosing between FHIR integration or HL7, remember, there is no right or wrong choice between HL7 and FHIR. FHIR is a standard developed as HL7, as well as HL7 V2, V3, and other standards. FHIR is the newest standard that addresses healthcare interoperability problems, whereas HL7 V2 is used for communication within different systems in a healthcare establishment. Adopting FHIR is necessary for providers who want to comply with industry standards. 

How is FHIR different from HL7?

The main difference between FHIR and HL7’s previous standards is the fast and simple implementation of FHIR resources compared to leveraging older standards and RESTful architecture support.

Why Is FHIR More Powerful Than HL7?

One reason FHIR is more powerful lies in the HL7 vs. FHIR format difference. The older HL7 standards support XML; the HL7 V2 format is based on pipe and hat encoding. 

FHIR leverages modern web technologies, such as RESTful APIs, XML, and JSON. Widely-used open technologies enable more developers to create new healthcare IT solutions. 

More article about Featured

no-image
Introduction to FHIR Data Model: Diagram & Examples

April 21, 2023

  • Featured
  • FHIR
no-image
FHIR Data Mapping in Healthcare for Improved Interoperability

December 8, 2022

  • Featured
  • FHIR
no-image
SMART on FHIR: Benefits, App Development, and Future of SMART on FHIR

November 21, 2022

  • Featured
  • FHIR
no-image
How to Configure Notifications for an FHIR Server (Subscriptions)

October 25, 2022

  • Featured
  • FHIR
  • Kodjin Updates
no-image
FHIRPath Profile Validation: Real-World Examples

August 15, 2022

  • Featured
  • FHIR

Let`s chat

We would be glad to share more details about our enterprise-level FHIR software solutions and other cases based on the HL7 FHIR standard.

    Your form has been submitted successfully

    We will contact your shortly

    Kodjin White Paper

    Please leave your email to get Kodjin White Paper

      By downloading files from this site you agree to the Policy

      The Kodjin White Paper has been successfully sent to your email

      We have sent a copy to your email

      Back to website content