I’m not a fan of automated HL7 to FHIR conversion.
No matter how automated the tool says it is, there’s always a mapping piece in the middle that contains custom logic for each data source.
It’s never as easy as the sales pitch suggests.
Microsoft have a HL7 to FHIR converter that I tried out some time ago.
It’s open source and free to use. But how does it fare against real HL7 messages?
Here’s what happened when I took it for a test drive.
1 — I downloaded and built the converter tool. It’s a C# project, and builds without issue out-of-the-box.
2 — I extracted the template files from the Hl7v2DefaultTemplates.tar.gz file inside the project into a folder I created.
3 — I found a sample HL7 ORM message on the AthenaHealth developer portal.
4 — I located the template name that corresponded to the HL7 message. In my case it was “ORM_O01”. Here’s the list.
5 — I ran the command line tool I built earlier as outlined in the documentation.
That’s it.
My new FHIR bundle appeared a couple of seconds later. Here’s what it contained:
– MessageHeader
– Provenance
– Organization [x]
– Patient
– Account
– RelatedPerson [x]
– Practitioner [x]
– Location
– Coverage
– ServiceRequest
– PractitonerRole
– Specimen
There was a lot in the bundle — not all of it of use to me.
It contained duplicate resources for Practitioner and RelatedPerson.
The Provenance and MessageHeader resources had no value, and some Organization resources were only shells.
Beyond that, the FHIR resources were well populated from the HL7 message, and all the resource reference links worked.
Here’s the bundle that was produced: http://hapi.fhir.org/baseR4/Bundle/21892704
My conclusion?
It’s a starting point, not a polished utility you can use against production data.
You’d need a LOT of custom mapping for the data coming in before you could trust the converter to run on its own. The project’s liquid template files help with this.
You’d need to wrap your own code around the converter to validate where necessary and trim and clean the data before letting it into your FHIR server.
It’s an impressive tool. But tools are only as good as the person using them.
The devil and the time is in the mapping. This can’t be automated!
---