Existing conversion tools for HL7v2, v3, ... to FHIR?

FHIR
1

HI all,

I have what’s probably a naive question for you all. I’m wondering what’s out there that can help convert HL7v2 and v3 (e.g. CCDA, …) to FHIR. That could be FHIR resources as JSON files on disk, or pushed to a FHIR server. Research indicates that there are lots of pitfalls involved. I’ve located some paid products that do things like this, e.g. 1upHealth, but they don’t address the use case of being in possession of files containing HL7v2 or v3, and being able to convert those to some form of FHIR. I’d be keen to hear about:

  • paid or free products,
  • open source or not,
  • converters with very limited abilities that may be extensible,
  • toolkits that require additional work to implement this kind of conversion,
  • handlers for various sources of HL7, e.g. files, net API, database, …

As you can tell, I’m not too fussy, due to limited success in finding anything myself. Does anyone out there have any ideas?

Regards,
Mike

2

Not looked at HL7v3/CDA.

I use Apache Camel plus HAPI HL7 v2+FHIR to do the conversions. It is not automated but HL7 have produced mapping guidance v2-to-FHIR Map Inventory - جداول بيانات Google
I’ve used this.

3

Robert Worden (http://www.openmapsw.com/) may have some code to support this.

My code is awaiting testing but the company I’ve wrote the code for may offer as a service.

4

As you may have seen there is no perfect solution. Despite it all being HL7, the problem space is actually really wide.

A good start may be the open source HAPI Java HL7 v2 libraries, and the HAPI FHIR Java libraries. There are also .net equivalents. These are code level solutions. So you have to do the “mapping” yourself. However there is no escaping that, because any HL7 V2 you find is likely to have local customisation, so there is no out of the box mapping possible. The effort to create the mechanics of conversion is often not that great, compared to effort of understanding what data you have in front of you, including code mappings.

There are commercial “integration engines” that can do this, but not completely automatically. I won’t list them here, you can google them. They may make the mapping mechanics, and things like pipelines, scalability etc easier, but are expensive (except free ones such as Mirth - however nothing is really free). And you still have you own local data discovery issues.

To be honest, most people are not converting V2 (or V3) data directly to FHIR, although you might expect that to be very common. If an existing interface works people tend to leave it, or create new in parallel. And even if they rip and replace, they probably don’t convert the messages - which are meant to be transient. Normally the raw messages get turned into records in some clinical system, where they can be exported from, e.g. into CSV/XML/Excel which are then easier to turn into FHIR. So you can sometimes leverage the fact the the messaging systems understand their own flavour(s) of V2 and can turn it into something “standard” for that system e.g. a set of exportable SQL data.

There are not many good HL7 V3 tools out there, but it’s XML, so you can just code against it. CDA is a special case, more widely adopted (apart from in the UK, where we have a few large volume V3 systems), so there are some libraries for it, MDHT etc, and mappings for CCDA as part of CDA-on-FHIR.

Yet another issue is the mismatch between messaging and REST/database type data. V2 messages are snapshots that build up a picture over time e.g. test started, intermediate result, final result. You would want to turn that into a lab result in FHIR and not keep all the intermediate states (probably). You could do FHIR messaging as a more direct conversion, but that would achieve little.

So yes, it’s a wide area :slight_smile: But for any specific case it’s not that hard to just “write the code”. It’s just that generic solutions are not always practical because there is no generic problem.

1 Like
5

You mean people aren’t converting a v2 message system into a FHIR message system. Agree I wouldn’t convert that unless I had reason to.

I would replace HL7v3/CDA messaging because very few understand that and it is difficult to maintain. Some UK suppliers are refusing to do any more work on V3/CDA and NHS UEC is looking to move to FHIR from CDA/V3.

People are converting from v2 to FHIR, at least on NHS LHCRE intends to. Yes the message system is v2 but population of the CDR is via FHIR Messaging.

1 Like
6

good to hear. I’ve not seen much of this yet, but I am sure it is happening. No reason why not if interfacing a new system. You have to interface your system to V2 (assuming it doesn’t support it), so why build that if you can interface to FHIR instead. Better to get the sender to change to FHIR, but you may not have control over that of course.

7

Hi all (especially @mayfield.g.kev and @riksmithies) - just thought I’d say thanks for your input here! I’ve ended up going down the route that Rik suggested: “There are not many good HL7 V3 tools out there, but it’s XML, so you can just code against it.” and “But for any specific case it’s not that hard to just “write the code”. It’s just that generic solutions are not always practical because there is no generic problem.” I’m making some good progress on this, it’s an interesting project.

1 Like
8

We are also terrible at identifying generic solutions.

It amazes me how many problems my wife (nhs england) mentions as requirements that fall into this category.
Yet at the other end of the process, generic has disappeared.

9

“We are also terrible at identifying generic solutions.”

I disagree with this statement. I think you do too :grinning: - you are “amazed” at how many problems could be solved using generic capabilities.

Systemically, the NHS is often poor at commissioning and implementing generic capabilities as they are at a level of abstraction higher than the existing organisational units. These capabilities cross domains, don’t fit the funding model and don’t directly improve outcomes. There are some exceptions; for example, NHSMail, HSCN, PDS provide capabilities that form incredibly useful building blocks for a solution.

10

Royal we?? :slight_smile:

Looking at this from a people, process and tech pov at the mo.

It’s good that tech can see generic capabilities but we really need people and process to do likewise.

Early version but you can get the drift.

11

All I can say is, I’m very curious as to how far I can get with my generic solution! Having said that, my goals aren’t extremely ambitious, for now - just getting a decent amount of CCD content across to FHIR would be a win.