HL7 to FHIR: Converting Between Healthcare Data Standards

Daniel Pluard

November 7, 2022
Intely HL7 covert HFIR

Right now, or when you have a minute, try Googling ‘converting HL7 to FHIR’ or ‘map HL7 to FHIR’. Likely, the search will not return what you expect – a clean mapping and translation guide or even a complete tool to convert the older HL7 v2 message standard to HL7 FHIR. That’s because there isn’t one out there.

You’ll likely find a few open-source libraries or frameworks that need to be heavily modified to meet your specific needs. You’ll also encounter several services and software that provide tools for managing healthcare data. The best resource is a result directly from HL7 FHIR called message maps. However, it only provides a small list of all supported message types and FHIR resources. Let’s dig into why.

To clarify a few things, we’ll leave HL7 v3 and HL7 CDA out of this for now but will cover them in a separate blog. When we use “HL7”, we are referring to “HL7 v2.”

Differences in Design and Architecture

The fact that there is no simple mapping and conversion process is a symptom of dealing with different standards and is not inherently bad. HL7 and FHIR were designed for different purposes and employ very different architectures. Both standards and protocols have strengths and weaknesses for healthcare data and system integration.

HL7 v2

HL7 was developed as one of the first interfacing standards and is primarily event-driven. Specific healthcare and clinical events produce a specific HL7 message type that contains multiple segments or related data. The data has a unique syntax and many vocabularies and reference sets, which pose challenges for any developer or user without extensive experience.


FHIR is a newer standard that leverages modern web services and RESTful API architecture. The idea was to introduce a scalable and flexible standard well understood by current technology users, making it easier to implement and cost-effective. FHIR resources can expand and adapt to meet system and workflow requirements. EMR (electronic medical record) implementation of FHIR is primarily query-based and does not yet support event-driven models. FHIR is particularly efficient when requesting data but less effective when notifying another system of an event.

Message and Resource Conversion

The FHIR resource and data structure design represent data in small, logical transactional units, while HL7 messages produce multiple data segments in a single message for a particular event. One standard is not better than the other, and they are both efficient in specific use cases.

HL7 message segments loosely compare to FHIR resources, but certainly not in the absolute sense. Although many HL7 data fields map directly to a FHIR property and have a direct relationship, HL7 messages have multiple segments. A single HL7 message generally represents data that belongs to many FHIR resources.

Health Level Seven provides resources around Structure MappingConcept Mapping, and Mapping Language that can serve as a north star to interface developers.

For example, an HL7 DFT message requires the following FHIR resources to represent and build a complete message:

– Patient

– Encounter

– Financial Transaction

– Possibly Procedure, Practitioner, and more

Since there is no one-to-one relationship between transactions, mapping data in practice is quite difficult. There is not a “one-size-fits-all” or an “out-of-the-box” mapping. The transformation between the two standards is largely predicated on a workflow that may require mapping many resources into a single message or a single message to many resources. A business use case may also receive both HL7 and FHIR data formats and require one standard output.

Data Mapping and Transformation Challenges

HL7 and FHIR terminologies and code sets differ, and systems implement and use the standards with some variation. When you convert between an HL7 and FHIR transaction, there will need to be some method to convert code set values and terminology to the one used by the other standard.

It is critical to keep the purpose of each element at the forefront of designing a transformation. A straightforward interpretation of each data element’s actions within a workflow will help create an efficient mapping solution.

What Does a Mapping Engine Do?

A mapping engine stores a set of mapping instructions that convert the structure and concepts of an input data structure. An engine enables some automation when interfacing with healthcare data. A channel or request feed receives an input message(s) and/or transactions(s), processes it through the engine, applies the mapping instructions, and produces an output. The output from this process should be in a standard that the destination system can accept and interpret.

Solutions Available Today

When the need arises in healthcare technology to convert between data standards, there are typically two options – build and buy. There is no “right” decision here, and considering factors such as time, cost, and expertise is critical.

It’s time-consuming and sometimes tricky, yet entirely feasible to develop your own mapping engine with instructions. By using this method, you can ensure that the interface is compliant and designed to meet your specific needs. When a business process or requirement changes or updates to a standard, it allows full autonomy to modify the mapping instructions to satisfy a workflow’s needs completely.

There are a few open-source solutions that you can use when building a mapping engine (you may have found them in that earlier Google Search!). Keep in mind these will generally require some modification to work for you effectively and efficiently. Here is a couple:

–      Microsoft FHIR Converter

–      LinuxForHealth HL7 to FHIR Converter

If you prefer to buy a solution, software providers have pre-built mapping tools in their interface engine. The mapping instructions will likely need some modification to meet your requirements. The good news is that you can often make these localizations easily. Some healthcare software providers reduce the technical burden and programming required with intuitive “drag-and-drop” interfaces that create the mapping instructions in a configuration file.

Interoperability and interfaces are constantly evolving and growing with innovation. There will be many more open-source solutions and software platforms to convert healthcare data and improve the process of creating interface transformations and engines.

Why is there no simple tool or guide for converting HL7 to FHIR?

Converting HL7 to FHIR is complex due to the fundamentally different designs and architectures of the two standards. HL7 v2 is event-driven, producing specific message types with multiple data segments for clinical events, whereas FHIR uses modern web services and RESTful APIs to represent data in smaller, logical units called resources. This structural difference makes straightforward conversion tools or guides challenging to develop.

What are the main differences between HL7 v2 and FHIR?

HL7 v2 is an older standard that is event-driven and uses a unique syntax with multiple segments in each message. FHIR is a newer standard leveraging modern web services, using RESTful APIs to represent data in flexible, scalable resources. While HL7 v2 is efficient for specific clinical events, FHIR is better suited for querying data and integrating with current technology platforms.

How do HL7 message segments compare to FHIR resources?

HL7 message segments loosely compare to FHIR resources, but there is no direct one-to-one relationship. A single HL7 message may represent data that spans multiple FHIR resources. For example, an HL7 DFT message might require Patient, Encounter, Financial Transaction, and possibly Procedure and Practitioner resources in FHIR to be fully represented.

What challenges are involved in mapping data from HL7 to FHIR?

The primary challenges in mapping HL7 to FHIR include differences in terminologies and code sets, variations in how systems implement standards, and the complex nature of aligning data elements between the two. Accurate mapping requires a deep understanding of each data element’s purpose within the workflow and often necessitates custom solutions tailored to specific business needs.

What solutions are available for converting HL7 to FHIR?

Solutions for converting HL7 to FHIR include building custom mapping engines or purchasing pre-built tools from software providers. Open-source options like the Microsoft FHIR Converter and LinuxForHealth HL7 to FHIR Converter are available but often require modifications to meet specific needs. Commercial software providers offer interface engines with customizable mapping instructions, sometimes featuring user-friendly interfaces for easier configuration.

Download Your Interoperability Strategy Guide

Not Sure where to start? This 9-page guide helps you build an actionable strategy in 4 proven steps. 

4 Steps to Interoperability Hero

Share This Post

Subscribe to our blog and updates via email

Recent Articles

Resource Guides

White paper

The Realities of Interoperability & Technology Infrastructure in the Healthcare Market

Now more than ever, it is impossible to overstate how critical it is to grasp the impact of interoperability.


White paper

How to Not Fall Victim to the Healthcare Scheduling Trap

You can solve the patient scheduling problems in healthcare with the right toolkit.

Want to learn more?
One of our team members can help.