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
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 Mapping, Concept 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:
– 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.
