Blog

I survived HL7 v3. Don’t go to version 3, go to HL7 FHIR!

I was the manager of an HL7 project in Mexico. We developed HL7 v3 adapters for Electronic Health Records (EHR) during which we received continuous feedback on our solutions from the authors of the HL7 v3 implementation guide for Mexico.

Here are the problems my team and I stumbled on with HL7 v3:

• It’s not sexy. Try to attract talented programmers to work with XML! It’s difficult! Talented developers want to work with JSON or YAML. You cannot change that. Just accept it.
• It requires a lot of time to read about the HL7 v3 concepts. There are so many documents on HL7. To get the concepts of clinical history first you have to read the introduction, two sections: primary and secondary sets of standards then browse over 37 documents of standards until you understand the Clinical Document Architecture 2.0. And finally the specific implementation guide.
• HL7 v3 specifications are designed on purpose to be high-level, expecting country-specific extensions for country-specific implementations. So, there is no assurance of interoperability between international systems and services. Furthermore, a lot of nations simply don’t have the resources and expertise to invest in elaborating HL7 v3 implementation guides.
• Assuming an implementation guide exists, it is too abstract for developers. It has a lot of information about the -already very complex- content and format on XML. But it is of little help for the developer on topics about the communication channels, protocols, scale-out related problems. I won’t rant against a specific implementation guide. But just google: “HL7 v3 Implementation guide” for a random country. You’ll find that for most of it, it’s just the same class diagrams which are already found on the HL7 site documentation, including a table of fields-descriptions and a big copy-pasted XML document.
• Static hierarchical data structures as in HL7 v3 do not scale. Object identifiers (OIDs) are allocated in a hierarchical manner, so that, for instance, the object with OID ‘1.2.3’ is the only object which can be connected to object with OID “1.2.3.4”. However, relationships between organizations, patients, even authorities are not hierarchical. Wake up to social networks please! This is the 21th century! Relationships are best described by graphs instead of hierarchies!

What about an architecture which uses developer-friendly technology? And what about if that technology supported widely adopted standards, was decades-proven, and was designed for scale-out by providing universal identifiers ready for ad-hoc links between data?

Enter the new HL7 FHIR. It is based on Linked Data. It gives you out-of the box:

• Support for W3C Web standards, such as HTTP, REST, JSON-LD and OAuth.
• Based on the proven scalable Web architecture
• Supported by a large community of web developers
• Based on open developer-friendly documentation
• Having a more complete scope than HL7 v3 by for example covering concepts related to communication protocols such as RESTful APIs

It is interesting to note that not everything is yet specified to the last detail in HL7 FHIR. For example, FHIR does not specify a REST API standard to be used, such as smartAPI or Open Services for Lifecycle Collaboration (OSLC). These Hypermedia REST API standards allow clients to discover resources and services of a healthcare system without having to lookup human-readable documentation. Instead, client applications can use the standardized API to discover on their own available resources and services by simply understanding the metadata returned by the API.

I intend to explain in more detail benefits of HL7 FHIR for automation in a next blog article.

Have a nice day Compadres!