HL7v2 has been in use for quite a long time in the healthcare industry. It powers much of the communication that goes on behind the scenes at the hospital, and despite the emergence of other languages, it continues to be used today. I go into more definition and background here: An Interoperability Primer Part 1: HL7 and Jargon.
HL7 can get a bum rap, especially from experienced developers moving into the healthcare space. Here are some of the reasons HL7 is so prevelant and the things that people complain about (and what I think about them).
- The message format.
It’s closer to X12 than to JSON or XML. People in the interface world learn the basics and go on with their lives. A LARGE number of people miss the very important concept of groups in message structure. - Inconsistency across message types.
ADT (Admissions, Discharges, Transfers) has a huge number of event types and ORM (Orders) only has one, with statuses being communicated via a field. This is super confusing to outsiders. - Industry reluctance to move away from MLLP for transport.
This is a huge problem we solve for our customers at Redox, so I’m not complaining, but it would make our lives so much easier. - Lack of true models.
This kind of goes back to the inconsistency across messages, but basically HL7, the organization, tried to solve this with HL7v3 and failed miserably (see Second-system effect – Wikipedia). FHIR is taking a similar approach but with less of a cognitive load. I personally think v2 is easy enough to grasp – it’s just about grabbing data from the places you care about at the end of the day. - Long implementation times.
Vendors don’t do a good job of documenting the quirks their v2 interfaces (and all of them have some), so implementations usually take weeks and months. Most EHRs don’t come with every inbound and outbound HL7 interface out of the box, so health systems must license and implement the needed interfaces from the EHR vendor.
Because of its widespread use, we leverage HL7 for a majority of our integration work. Pretty much every EHR and system used at a hospital supports HL7 integrations. Our engine abstracts away the complexity and inconsistency that often makes it so difficult to work with and our customer success team works with health systems and developers to ensure the interfaces and mappings support the integration in the long run. Developers working with Redox get clean, consistent JSON models over HTTPS.
To review our API documentation and see how we leverage HL7 but present JSON, signup for a free Developer account today.