FHIR vs. Traditional HL7: What Makes This Standard So Different?
Sidharth Ramesh
Founder and CEO
Forget everything you thought you knew about HL7; FHIR is not just an upgrade—it's a complete game changer.
In this article, we'll explore why FHIR is gaining so much attention and how it differs from traditional standards like HL7v2, HL7v3, and CDA.
Whether you're a clinician or developer new to Health IT, join us to understand the benefits of FHIR and its growing adoption in healthcare. We'll start by looking at older standards like HL7v2, HL7v3, and CDA, and why they were hard to work with. We'll look at how FHIR is different and why governments around the world are adopting FHIR to improve healthcare.
HL7 before FHIR - HL7v2, HL7v3, and C-CDA
Before diving into FHIR, it’s essential to understand the background of earlier HL7 standards and why there was a need for something new and improved.
HL7v2 was the early leader
HL7v2 messages are sent in response to something happening in the healthcare enterprise. One example of events is Admission, Discharge, or Transfer (abbreviated to ADT). Whenever a patient gets admitted or discharged, the system handling the encounter will emit an HL7v2 message to all other systems that need to be notified. An example of such a message looks like this:
MSH|^~\&|HIS|HOSPITAL|ADT|RECEIVING_APP|20240826095525||ADT^A01|MSG00001|P|2.3
EVN|A01|20240826095525
PID|1||123456^^^HOSPITAL^MR||DOE^JOHN^A||19800101|M|||1234 ELM ST^^METROPOLIS^NY^10001||(555)555-2000|||M||123456789|987654321
PV1|1|I|ICU^101^1^HOSPITAL|||1234^ATTENDING^PHYSICIAN^MD|5678^REFERRING^PHYSICIAN^MD|7890^CONSULTING^PHYSICIAN^MD|||||||||||1234567890^PRIMARYCARE^PHYSICIAN^MD|I|||||||||||||||||||20240826090000
ZEV|Emergency Admission^Fast track admission for critical patient
HL7v2 used its own TCP-based protocol called MLLP to communicate most of the time. Although we now have HL7v2 over HTTP, most vendors implementing HL7v2 still do it over MLLP.
Also, notice the different segments spaced out by | in the above example message, and short forms like MSH, EVN, and PV1? If you wanted to really understand what they meant, you had to pay HL7 a license fee just to see the specification!
HL7v2 was also notorious for the variety of different variations between implementations due to a segment called Z-Segments that vendors can use to add whatever data they wanted. There's an adage that goes something like:
Once you've seen one HL7 v2 implementation – you've seen one HL7 v2 implementation
So all of these factors combined:
- Usage of its own transmission protocol - MLLP
- Blocking access to the specification behind a license
- Usage of use-case specific Z-segments
Equated to HL7 specialists needing to know how to work with a whole domain-specific tech stack (remember MLLP?). They were extremely expensive and not easily available. And the specification license had to be paid upfront.
To solve most of these issues, HL7 started working on HL7 v3. They wanted to have a consistent way to represent healthcare information and avoid the proliferation of v2 profiles.
HL7v3 overpromised and underdelivered
HL7v3 aimed to correct the deficiencies seen in both HL7v2 and C-CDA by adopting a more rigorous, model-driven approach. It was designed to be more comprehensive, with well-defined data structures and improved semantics.
The HL7 committee spent close to 10 years refining the specification, and they came out with a class-based representation of everything in healthcare.
The inception of the Reference Implementation Model (RIM) marked a significant milestone. However, this type of "rewrite," particularly when led by a committee, is generally viewed unfavorably in the software industry (See Joel Spolsky's article on the subject here).
Although HL7v3 had ambitious objectives, it faced significant challenges in gaining widespread acceptance. Its complexity surpassed that of its predecessors, making implementation and adoption difficult. Many organizations found it too complicated and resource-intensive to utilize effectively.
The transition from the standards committee to implementers and developers was problematic.
The rigorous consistency of HL7v3, initially seen as an advantage, turned out to be a major disadvantage because healthcare institutions were inconsistent in the types of data they wanted to capture and transfer.
Consequently, HL7v3 was largely considered a failure, leading many to revert to using HL7v2. However, a specific variant of HL7v3 known as Consolidated Document Architecture (CDA) did achieve considerable success.
CDA is the widely accepted legacy of HL7v3
HL7 + Documents + XML = CDA
A group of people with an interest in both HL7 and XML met at the Kona Mansion in New Hampshire, where they set out a road map for using XML in medical documents, along with the HL7 Version 3 reference model (yes, the RIM mentioned above). This became known as the Kona Proposal, and later on evolved into the HL7 Clinical Document Architecture (CDA).
CDA adopted the document paradigm to its core. Documents were great because they are often how clinical documents are really represented. This made it easier for healthcare professionals to adopt and trust the system, as it aligned closely with their existing workflows.
Along with computer representation, the XML documents also had a human-readable component. This ensured that they were always viewable by humans, facilitating better communication and understanding among medical staff.
CDA + Continuity of Care + US Meaningful Use Stage 2 = C-CDA
C-CDA or Consolidated CDA was a specific profile of CDA that was mandated by the US in the Meaningful Use Stage 2 regulation. It was mainly concerned with the Continuity of Care Document and implemented a version of the same using CDA.
Here's a short excerpt from a C-CDA document to show you how it looks:
<?xml version="1.0" encoding="UTF-8"?>
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
<!-- Patient Information -->
<recordTarget>
<patientRole>
<id root="2.16.840.1.113883.19.5" extension="987654"/>
<patient>
<name>
<given>John</given>
<family>Doe</family>
</name>
<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
<birthTime value="19800101"/>
</patient>
</patientRole>
</recordTarget>
<!-- Clinical Section -->
<component>
<structuredBody>
<!-- Allergies Section -->
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.22.2.6"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Allergies and Adverse Reactions"/>
<title>Allergies</title>
<text>NKA (No known allergies)</text>
</section>
</component>
<!-- Medications Section -->
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.22.2.1"/>
<code code="10160-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="History of medication use"/>
<title>Medications</title>
<text>
<table border="1" width="100%">
<thead>
<tr>
<th>Medication</th>
<th>Dosage</th>
<th>Frequency</th>
<th>Route</th>
<th>Start Date</th>
<th>End Date</th>
</tr>
</thead>
<tbody>
<tr>
<td>Lisinopril</td>
<td>10 mg</td>
<td>Once daily</td>
<td>Oral</td>
<td>2022-01-01</td>
<td>2024-01-01</td>
</tr>
</tbody>
</table>
</text>
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>
Below is an example of how a C-CDA document is rendered for human consumption:
As a result of the regulation by the Meaningful Use Stage 2, C-CDA was widely implemented. Healthcare organizations across the US adopted C-CDA to meet regulatory requirements, and since most of these vendors sold internationally, they took the same standards with them around the world.
Despite its advancements, CDA encountered notable difficulties. Although it was a great leap forward in using existing standards like XML, the XML-based format was intricate and frequently unwieldy. It failed to address the larger challenge of interoperability, primarily due to varying interpretations and implementations, similar to its predecessor, HL7v2.
FHIR is based on existing internet standards
FHIR was strongly inspired by Basecamp's Highrise CRM APIs. Once you get used to the possibility of being able to read documentation online, connect to an API endpoint, and get things done in a matter of minutes, there's no going back.
Instead of reinventing the wheel with its own protocols like MLLP, FHIR just used what already worked for other industries - HTTP, JSON, and XML. FHIR started defining how RESTful interfaces can be built on a data repository that will house all healthcare information. We do a more thorough deep dive on FHIR resources and how to make sense of them in our article - What is FHIR? A Beginner's Guide.
This is a complete change of paradigms from the previous messaging and document exchange that used to happen with HL7 v2, v3, and CDA.
Specifications that complemented FHIR like SMART on FHIR made it even simpler to work with FHIR and authenticate to said servers without needing back and forth between organizations.
FHIR is open-source
FHIR was initially called Resources for Health and it was a part-time project worked on by Grahame Grieve. When it became incorporated into HL7's Fresh Look Task Force and it came out the winner, Grahame was very clear that it was to be published under an open-source license. This became FHIR as we know it.
Here's Grahame explaining in an interview on the Digital Health Hacker's Podcast on how his life has never been the same after that decision:
While previous standards from HL7 were pay-to-access and had a huge barrier to entry, FHIR, for the first time, can be accessed on the internet for free by anyone. You can do it right now.
And because the content was open and anyone can read and understand it, the educational content around FHIR and open source implementations of FHIR exploded as well.
FHIR is simple and easy to use
The 5-5-5 rule of FHIR explains the unreasonable focus on simplicity:
- 5 seconds to find the specification on the web.
- 5 minutes to understand it.
- 5 hours to have some working code.
This is in contrast to the extraordinary domain expertise required to understand something like HL7v3. It is reminiscent of the worse is better philosophy in software development where one favors simplicity even over rigor and correctness.
The design should be correct in all observable aspects. It is slightly better to be simple than correct.
- Worse is Better or New Jersey Style
The design must be correct in all observable aspects. Incorrectness is simply not allowed.
- The MIT approach
FHIR also adopts the 80/20 rule when modeling information and tries to represent only the most commonly used data points in the core international specification, and leaves the rest to be implemented by Profiles and Implementation Guides.
This makes it extremely easy for people getting started to really understand FHIR, and how it works. As a result, FHIR has a rapidly growing community that meets at connectathons and FHIR-specific events.
FHIR fosters a diverse community
A FHIR Connectathon is closely related to a Hackathon event but the FHIR community chooses to use the word connectathon because the focus is on connecting different systems together.
I was at a FHIR DevDays event to deliver a talk on Generative AI. The energy and community that I felt in the room was something else.
HL7 along with some key partner companies working on FHIR like Firely and Health Samurai have been doing an excellent job conducting events and fostering a community of clinicians, lawmakers, developers, and everyone in between.
When lawmakers and attendees see the adoption and successful usage of FHIR in one country, they immediately go back and try to implement it in their own country.
Lawmakers worldwide are adopting FHIR
Firely recently published a state of FHIR report that covers how countries around the world are adopting FHIR. Regulation is a key reason behind why FHIR is going mainstream now. Here's a list of different regulations around the world that adopt FHIR in a serious way.
Here's a list of countries that mandate FHIR:
- Argentina: The Ley 27.706 mandates the use of FHIR in the national healthcare system, ensuring interoperability across digital health records.
- Belgium: The EHealth Action Plan mandates the use of FHIR for interoperability in the healthcare sector.
- Brazil: The Rede Nacional de Dados em Saúde (RNDS) mandates the use of FHIR for electronic health data exchange across the country.
- France: The CI-SIS (Interoperability Framework) mandates FHIR for electronic health data exchange, supporting initiatives like Mon Espace Santé and HOPEN.
- Germany: Multiple regulations, including Sozialgesetzbuch V (SGB V) and Digital-Gesetz (DigiG), mandate the use of FHIR for interoperability and electronic health data exchange.
- India: The Ayushman Bharat Digital Mission (ABDM) mandates FHIR R4 as the standard for health data exchange across the country.
- Italy: Several national and regional regulations currently advise the use of FHIR, with future EU regulations expected to make it mandatory.
- Japan: The JP-CLINS mandates the use of FHIR for clinical information sharing across healthcare facilities.
- Lithuania: National regulations require linking health information systems using FHIR for interoperability. Regulation.
- Netherlands: The Wegiz and the upcoming EU EHDS regulation require the use of FHIR for electronic health data exchange.
- Philippines: The National Health Data Repository Framework mandates FHIR for data exchange across the healthcare system.
- Saudi Arabia: The nphies Implementation Guide outlines the adoption of FHIR for the national healthcare platform, ensuring standardized health data exchange for insurance preauthorization and claims.
- Switzerland: The Ordinance on the Electronic Patient Record (OEPR) mandates the use of FHIR for the exchange of health data, including eMedication and eVaccination.
- Taiwan: The Ministry of Health and Welfare has issued guidance for the mandatory adoption of FHIR for inter-agency data exchange.
- United States: The Health Data, Technology, and Interoperability: Certification Program Updates mandates FHIR for electronic health data exchange, particularly under the ONC’s certification criteria.
And note, this is just the list of countries that mandate FHIR. There are a lot more who still highly recommend it. Read the full report from the 2024 FHIR Survey if you want more details.
Summary
The world of healthcare IT has seen big changes, shifting from the outdated and difficult standards of HL7v2, HL7v3, and CDA to the new, flexible, and widely accepted FHIR standards.
FHIR's open-source nature and use of familiar internet standards like HTTP, JSON, and XML have made it easier to access healthcare data. This new approach is much simpler and quicker, unlike the old, complex HL7 standards.
The FHIR community is diverse and rapidly growing. Gatherings like Connectathons and DevDays foster collaboration, innovation, and mutual learning, helping to drive FHIR's continuous improvement and widespread adoption. Today, 16 countries have recognized the value of FHIR and are mandating its use in their healthcare systems.
If you're ready to be part of this healthcare revolution and unlock the full potential of FHIR, my 90 min FHIR Masterclass may be the perfect place to start.
If you want to join me and 20 other participants from around the world to build 5 real-world applications and become a certified FHIR expert, sign up for a free preview of our FHIR Bootcamp today!