- HL7 version 2 is probably the most commonly used, having been around since 1987.
- HL7 CDA is widely used for sharing documents.
- DICOM is an imaging standard.
- There are a host of bespoke solutions.
Challenges with Converting Message Types
The problem is that converting from one type of message to another isn’t simply a matter of converting between different structures. You have to take into account the actual meaning of each element, which isn’t as straight forward as it might seem, especially as the usage of elements (especially in version 2) can vary between implementations. There are a couple of HL7 projects looking at conversions for version 2 and CDA, and likely others for the more specialized ones as well.
And the problem is further complicated by the need to convert coded elements between different terminologies as well. Not only can they be from different code systems (e.g., one might be using ICD9, but the desired target is SNOMED), but it’s not always straightforward to pick matching concepts from each code system.
There are many different approaches to authoring and executing these transforms, from customized scripting for each transform to graphical UI tools that allow a “drag and drop” operation, but this variability in approach brings quality issues into question. How do you know that a particular transform is correct? And how can you test it?
Mapping Language
To address some of these issues, the FHIR specification describes a formal Mapping Language. Used in conjunction with ConceptMap resources that describe the terminology conversions, it’s a way to express these transforms using structures that can be directly executed by a mapping engine.
This will not completely solve the problem as healthcare information exchange is extremely complex with many approaches and requirements, but it does mean that it’s possible for an HL7 expert to construct a “transform map” for a particular use case, which can then be used by others — as a starting point at least — instead of repeating the exercise each time. Not only will this save considerable time and money, but it also helps to address the quality issue.
As an example, think of a common use case — converting from an HL7 version 2 ADT (Admission/Discharge/Transfer) message to a set of FHIR resources. The ADT message will need to have a number of FHIR resources to represent it:
- Patient
- Encounter
- Practitioner
- Condition
- Allergy Intolerance
- And others
Each of these will likely need profiling (such as adding extensions) to match the information in the ADT message. Each field within the ADT message will require a transform to its FHIR equivalent element (e.g., for HL7 version 2 PID-3 is a Patient.identifier, PID-11 the address, and so forth). Plus, you’ll need to convert from the code systems that the ADT message uses to the ones that FHIR uses. They may be the same, but they may not.
And to add to the complexity, there are regional and national differences between the ways that common data is represented.
Think of the amount of work that will be involved to do all this from scratch — even assuming that you have the expertise available to do it.
Avoiding Bespoke Solutions
Now imagine that someone who has that expertise could create this mapping once, and then anyone can use it — maybe for free, maybe with some payment to cover costs. The time and effort savings could be immense, not to mention the comfort from knowing that the author knew what they were doing, and the corresponding increase in quality. It also raises the possibility of a “marketplace” of these transform maps, allowing people to share their expertise.
It’s important to note that this will not completely solve the interoperability problem. Many implementations do not property follow the specifications — and the specifications themselves generally allow latitude for their use. This is a particular issue for HL7 v2—which has led to the saying that once you’ve seen one v2 implementation, you’ve seen one implementation!
But it’s a considerable head start and does make it feasible to contract expertise for specific implementations as the contractors will be dealing with a known specification, rather than some bespoke JavaScript or other mechanism.
How Mapping Language Works
Here’s the overall picture (copied from a post at fhirblog.com):
It shows how there is an input message that is passed into a “mapping engine” that uses the “mapping instructions” to produce the output message. Note that the word “message” is being used loosely to represent the input and output; it could just as easily be a document or even a collection of single resources.
The mapping language specification covers how the engine should work, and also defines the structure of the mapping instructions. In this way, anyone can create a compliant mapping engine, and it can work with any set of compliant instructions.
Each part of the specification is represented by FHIR resources.
- The input and output structures are represented by StructureDefinition resources; there can be multiple StructureDefinitions for each.
- The mapping instructions have two main parts.
- The structural mappings are represented by StructureMap resources, which map between the StructureDefinition resources. There is also a text based syntax for the mapping instructions to make it easier to read. This can be converted into the StructureMap by the engine.
- Coded element conversions are described by ConceptMap resources, that maps concepts between different terminologies (like ICD and SNOMED).
One likely scenario is that there will be a small number of engine vendors that produce products that are licensed to implementers, who will then create or source the mapping instructions from other suppliers, tweaking them as required for specific implementations. Alternatively, a vendor may choose to develop an engine themselves, ensuring it is compliant to the specification.
For example there is a .net engine supplied by firely that exposes a web service interface. You upload the mapping instructions once (as StructureDefinition, StructureMap, and ConceptMap resources), then you can just pass the input into a service and get back the response. This blog post describes it in more detail.
There’s also a freely available java–based engine from the FHIR project, and others are doubtless under development around the world. (I believe the clever folk at Health Samurai are working on a JavaScript one.)
Interestingly, the mapping language is used internally by the spec to produce conversions between the different FHIR versions using the java engine, and these maps are freely available.
So what’s the catch? There are a number of gotchas:
- Some of the resources used by the spec are still quite immature and will change over time as we gain implementation experience, as will the mapping language itself.
- Specific expertise is required to create the mapping instructions.
- The engines that are currently available do not necessarily cover all the aspects of the language.
- Instructions are specific to a single transform in a single direction — e.g., from HL7 Version 2 to FHIR.
- Some customization (i.e., altering the instructions) is likely to be needed for specific implementations.
But nevertheless, the mapping language offers a vendor–agnostic approach to the tricky issue of conversion between FHIR and other message standards, and the possibility of a market place for mapping instructions and implementation consultants.
This is worth working toward!
