A Healthcare Interoperability Primer Part 1: HL7 and Jargon

Posted March 30, 2017
By Nick Hatt

Interoperability—it’s a buzzword, a marketing tool, and something that impacts the quality of healthcare. In this post I will help demystify jargon and explain how the big standards players fit together.


  • Resource – A real-world piece of data. The term resource is FHIR jargon, but it extends to most other standards as well. Think of a Resource as an atom: it’s a smallest discrete piece of data that can be combined into bigger, useful things (molecules). We need standards bodies to define resources because each vendor has different implementations of Patients, Appointments, Orders, etc.
  • Profile – An assembly of resources or other profiles that fits into a workflow. For example, if I need to send a lab order to my lab system, I will need to send information like the Patient, the test to be performed, and the provider who ordered the test. The profile here would specify which information needs to be sent, to varying levels of specificity.
  • Implementation – If resources are the who and profiles are the what, then implementation is the how. Specifically, how to do I get the data from system A to system B? This can involve any number of layers of the technology stack, from the network to the actual code processing the data. Different standards offer differing levels of specificity when it comes to Implementation. FHIR, for example, offers a diverse array of options for ways to share data. HL7v2 is less specific about how to get the bits from point A to B. We have yet to find any documented instances of communicating HL7v2 via carrier pigeon; instead, most prefer the archaic MLLP standard that was published around 30 years ago.
  • Standard – some combination of resourcesprofiles, and/or implementations that have been agreed upon as a way to share data.

Not everyone in the interoperability world would agree with these definitions, but I use them for the sake of diving into the organizations that drive healthcare interoperability.


Health Level 7 International is the main character in the interoperability fairy tale. To better understand HL7, I’m going to dive into the major standards that they develop.

HL7 Version 2 – This nearly-30-year-old standard is the most widely deployed method of interoperability. Commonly referred to as v2, it predates much of the technology you are using to read this article (http, xml, json, etc.) Still, it has a very wide scope of profiles defined ranging from orders/results to ADT and scheduling. When implementing HL7v2 interfaces, the Pareto principle applies: 80% of the standard is written, but the implementers are often left to work out the last 20%.

HL7 Version 3 – Commonly referred to as v3, this standard is heavily concerned with removing the 20% ambiguity that implementers faced in v2. Despite covering most of the same profiles areas that v2 does, we don’t see many of these interfaces in the wild. Part of the reason for this may be the intense amount of work that was put into the defining resources—the dreaded Reference Information Model (RIM). Everything described by the RIM derives from three basic objects. This leads to a lot of inherited relationships that both vex developers and make the standard unreadable to humans. The theoretical model is sound, but a common criticism is that resulting product is too “academic”. For kicks, here is an academic article about problems with the v3 model. And for further kicks, read about the Second System Effect.

CDA – The “Clinical Document Architecture” represents a way of exchanging “documents”. It is built on top of the RIM, making it almost impossible to understand as a human, but it adds some improvements for the sake of information sharing. Most notably is the inclusion of freetext human-readable sections. If you’ve ever had your “chart” moved electronically between two health systems, it’s likely that CDA was involved. Meaningful Use has rapidly accelerated CDA implementation, and will likely continue spur growth in this area. A number of profiles sit on top of CDA, most notably Continuity of Care Documents (CCD).

FHIR – FHIR is the new kid on the block. I recently blogged about the good and the bad it promises. Comparing FHIR to v3 and the RIM is like comparing Javascript to assembly language—they both do the same thing (move numbers around a computer), but one is clearly easier and faster to use. FHIR describes things as people would think about them—an allergy is an “AllergyIntolerance”. It also makes strong recommendations about how health systems and vendors should share the data – and it’s stuff familiar to modern web developers.

Well, there’s a high-level overview of HL7 and some of the key pieces of interoperability jargon. If you’d like to continue the conversation, feel free to send me a note.

Learn more in Part 2: Stylin’ and Profilin’: The Profile Playas.