Contact us
10 minutes read

HL7 standards and FHIR are extensively employed in healthcare, making the FHIR vs HL7 comparison a popular topic of discussion. Why?

The majority of healthcare providers use a wide range of healthcare apps to keep track of patients’ data, manage billing systems, provide care remotely, etc. The problem they face is the difficulty of “communicating” this information. 

HL7 is an international exchange standard that addresses this challenge and helps healthcare providers to bridge the gap between their applications.

As a healthcare software provider we also can’t skip this topic. In this blog, we’ll provide an in-depth comparison of FHIR vs HL7, explain how are they different, and what are the use cases.

HL7 Explained

What is HL7?

Health Level Seven (or simply HL7) is a well-known set of international clinical and administrative health data-sharing standards designed and popularized by Health Level Seven International, which is a non-profit organization, mainly aimed at healthcare interoperability. 

HL7 served as an early encoding framework to support secure healthcare messaging and document exchange between healthcare organizations. Given there are multiple related public and private healthcare data providers, each of them having their own ways of working, data exchange standards like HL7 are essential for efficient communication between all elements of the healthcare system.  

Understanding HL7 Standards

Health Level Seven International considers the following six healthcare standards as primary ones, and those are most used and implemented:

  • Version 2 Messaging Standard – an interoperability specification for health and medical transactions
  • Version 3 Messaging Standard – an interoperability specification for health and medical transactions
  • Clinical Document Architecture (CDA) – an exchange model for clinical documents, based on HL7 Version 3
  • Continuity of Care Document (CCD) – a US specification for the exchange of medical summaries, based on CDA
  • Structured Product Labeling (SPL) – the published information that accompanies a medicine, based on HL7 Version 3
  • Clinical Context Object Workgroup (CCOW) – an interoperability specification for the visual integration of user applications

There are more standards and methodologies introduced by HL7 International, including FHIR, which will be explained later in this article.

HL7 Versions           

HL7 versions

HL7 version 2 was introduced for the first time in the late 80s and is a non-XML encoded syntax with segments and delimiters. In order to identify segments a 3-character identifier is used. Each segment consists of a standard set of fields (composites) which are separated by the delimiter and can have sub-fields, or sub-composites with sub-delimiters, respectively. Each segment is divided by carriage return from the others and fields are separated by a ‘|’ delimiter, and, finally, ‘^’ separates sub-components.

Every message starts with the ‘MSH’ segment, which identifies key message data like sending and receiving systems, message type, version, or timestamp. HL7 v2 has multiple release versions from 2.1 to 2.8 offering backward compatibility across them. 

HL7 version 2 messaging is fully supported by all Electronic Medical Records systems in the United States. The general acceptance and support of this standard made it a suitable protocol to connect various systems, especially within one organization. Those interfaces are still in use and when someone refers to “HL7”, most likely this person has HL7 v2 in mind.

Despite being so popular, HL7 v2 also has its downsides. The syntax used by HL7 v2 is quite challenging in application development. Every single message contains many data elements that might be not relevant to some workflows. Additionally, since the standard is event-driven, the frequency of message generation is high, which means that some unwanted traffic might be created on a particular interface. Also, HL7 uses Minimum Lower Layer Protocol, which relies on IPsec or Transport layer Security while communicating outside a secure network. Considering this, one can assume that the HL7 v2 protocol works well when connecting applications within the same hospital or healthcare system since those are usually on the same network, however, it becomes bulkier when linking applications and systems on multiple networks. 

HL7 messaging version 3 was introduced in the 1990s as a standard that is intended to support all healthcare workflows. The previous version provided a standard for implementation; however, it was still quite difficult to support at scale across many systems due to the significant localization that occurs in messages. HL7 v3 tries to ensure a more rigid message structure compared to the previous standard while supporting interactions like events in HL7 v2. HL7 v3 messages rely on XML encoding syntax and follow object-oriented principles.

The intention of HL7 version 3 was good, but due to its complexity healthcare software community found it challenging to implement. Additionally, no backward compatibility with version 2 was offered, hence organizations willing to use the new standard were forced to completely migrate to the new one. As mentioned earlier, when someone refers to HL7, in the vast majority of cases they think about v2, not v3, and bad perception of the third version is one of the reasons for that. 

FHIR Explained

What is FHIR?

The Fast Healthcare Interoperability Resources (FHIR, pronounced “fire”) standard is a set of rules and specifications for electronic healthcare data exchange. It became a next-generation standards framework that combines the best elements of HL7 v2, HL7 v3, and HL7 Clinical Document Architecture (CDA) leveraging the most modern web service technology at the same time. FHIR design is based on RESTful web services and consists of modular components, or ‘resources’, and supports both JSON and XML. Specific resources can be accessed through a discrete URL, which allows for their retrieving, sending, and manipulation via an API request. 

Sometimes FHIR resources are similar to HL7 segments of the messaging version 2, however, there are no standardized conversion rules or direct relationship between the two. Conversion of healthcare data between various HL7 standards is relatively tricky, and the FHIR structure is completely different from the structure of other message types.

Exploring the FHIR Standard

FHIR is deemed to be a standard that is easier to learn and implement, especially for developers who started their careers in recent years and specialize mostly in web services. It uses more efficient data structures that are flexible and extensible. It has greater scalability potential, better cost efficiency, and is directed towards future healthcare interoperability.

HL7 International released FHIR Normative version 4 in 2019, and this standard is built to be backward compatible with all next versions of FHIR. There is a global tendency to build new cloud-based healthcare and other digital health-related applications that employ architectures that support web-service protocols like FHIR. 

US regulatory bodies like the Center for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator for Health IT (ONC) have already published new rules that require the usage of API to enable access to patient information, and that’s where FHIR can demonstrate its strength.

how FHIR works

Comparison of HL7 and FHIR Standards

Data Exchange: HL7 vs FHIR

The API standards implemented in FHIR streamline data exchange and reconcile the processing of processing in different formats. This enables more in-depth processing and makes it easier to extract contextual information from the data sources compared to HL7 which mostly suits for data exchange within the same network.

Benefits and Use Cases

Exhaustive data standards help bring the healthcare industry a step closer to achieving Electronic Health Records interoperability, no matter whether it is an independent medical practice or a national-level market player. If there were no standards such as those published by HL7, clinicians would still be faxing and carrying paper documents everywhere. No need to explain that this would lead to tremendous healthcare data silos, which always is linked to excessive time spent on manual activities.

By leveraging different data integration solutions, healthcare organizations can integrate HL7 data from HER systems, streamlining workflows and making access to crucial data easier than before. 

Let’s take a closer look at how HL7 standards benefit the healthcare industry:

Advantages of HL7 in Healthcare

  1. Interoperability - HL7 standards enable seamless communication and data exchange between various healthcare systems and applications. This streamlined communication allows healthcare providers to access and share patient data in a more efficient way, leading to improved patient care. The holistic view allows medical personnel to make more informed decisions and provide more accurate, personalized, and timely care to patients. 
  2. Enhanced Data Accuracy – those standards support the transmission of structured healthcare data, which helps to reduce data entry errors and inconsistencies. Standardization of data exchange formats ensures that the critical data is critically communicated across various systems, significantly decreasing the probability of errors and miscommunications.
  3. Cost Savings – by implementing HL7 standards, healthcare organizations have a great chance to reduce their costs associated with bespoke integration projects, as HL7 has a ready framework for data exchange. 
  4. Global Acceptance – HL7 is widely recognized and accepted across the world, making it easier to collaborate and exchange information across borders. The fact of global acceptance undoubtedly supports international research and the development of new healthcare solutions. 

Benefits of Adopting FHIR

  1. Focus on Patient Experience – FHIR aspires to empower patients by making it simple to implement and integrate across all devices and applications. With FHIR in place, patients have greater control over their records when such data is shared with them, which leads to increased trust in healthcare services and specialists. 
  2. Improved Clinical Treatment – clinical researchers can deliver better care and, as a result, improve patient’s experience if they have access to EMR and other patient-related data. Undoubtedly, such kind of data is extremely valuable for research and analysis in the healthcare industry. Implementation of FHIR with REST web services sets it apart from the remaining data-sharing standards.  REST can be easily implemented with the help of open-source technologies.
  3. Improved Data Management – FHIR enhances data management by retrieving real-time records, which helps to ensure data accuracy. Clinical data is driven in various formats and obtained from multiple sources, each having its own dimension and volume. Each resource in FHIR has its own link to a unique identifier. It makes it easier to acquire access to the proper set of information from any device or application, the same way as URLs make it possible and simpler to reach certain website pages regardless of which device or browser you’re using. 

Let’s sum up our FHIR and HL7 comparison with a table.



After this comprehensive FHIR and HL7 comparison, let’s finally sum up: FHIR vs HL7 which one is the best option to choose?

Although HL7 has been the healthcare data exchange standard for years, FHIR presents a more adaptable, efficient, secure, and developer-friendly solution. Its expanding community support indicates that FHIR is going to become the future standard for healthcare interoperability.

At inVerita, we leverage FHIR to ensure that our customers’ projects will benefit from the latest in healthcare interoperability and data exchange technologies. Feel free to reach out to us if you're considering developing healthcare software.
Frequently Asked Questions
Which use cases are best suited for FHIR and which for HL7 standards?
FHIR is the best option for modern healthcare use cases that require real-time data exchange, mobile applications, and integration with modern web technologies. HL7 standards, especially HL7 V2 and V3, are suitable for more traditional healthcare use cases, administrative data exchange, and scenarios where well-defined message formats are necessary.
Is it possible to integrate FHIR and HL7, or are they incompatible systems?
FHIR and HL7 can be used together. FHIR is designed to complement existing standards like HL7, allowing seamless integration and interoperability between modern applications and legacy healthcare systems.
What development tools and resources exist for FHIR and HL7 implementation?
Various development tools and resources are available for both FHIR and HL7, including official documentation, open-source libraries, SDKs, and online communities.
What is the difference between HL7 and FHIR?

The key difference between HL7 and FHIR standards lies in their approach to healthcare data exchange. HL7, a legacy standard, uses structured messages in a point-to-point communication model. In contrast, FHIR is a modern standard that employs a web-based API approach, representing data as discrete resources and enabling interoperability through RESTful APIs. 

Choosing FHIR vs HL7, it’s worth mentioning that FHIR's lightweight, resource-oriented design and ease of integration make it more adaptable to the evolving needs of healthcare systems, distinguishing it from the more complex and traditional HL7 standard.

1 people like this

This website uses cookies to ensure you get the best experience on our website.

Learn more
Thank you for getting in touch!
We'll get back to you soon.
Sending error!
Please try again later.
Thank you, your message has been sent.
Please try again later, or contact directly through email:
Format: doc, docx, rtf, txt, odt, pdf (5Mb max size)
Thank you, your message has been sent.
Please try again later, or contact directly through email: