The Healthcare Interoperability Family Tree: 60 Years of HL7, Its Roots and Its Neighbours

Introduction

This is part of my series on HL7 and healthcare interoperability. Most of the articles in the series zoom in on one thing: an HL7 v2 message, a FHIR resource, a DICOM association. This one zooms all the way out. I set out to sketch a quick timeline of HL7 for a talk, and a few evenings later I had dug past MUMPS and ASTM committees, down to RS-232 serial cables and the OSI model, and up through FHIR accelerators and prior-authorization rules. The result is the family tree below.

Honestly, what surprised me most was how staggering the full picture is once it sits on one page. Sixty-odd years, dozens of standards bodies, hundreds of releases, several false starts, and one stubborn goal that never changed: get System A to understand System B without writing a custom interface for every pair. Most of us working in this field learn one branch of this tree very well - the interface engine, the FHIR server, the PACS - and rarely get to see the whole thing. The complete lineage tends to live in the heads of a small number of people: long-serving work group co-chairs, committee leads and the engineers who were actually in the room when these decisions were made. This article is my attempt to write that picture down for everyone else.

Who this is for: engineers, analysts and architects who work with one or two of these standards and want to understand where they came from, why they look the way they do, and how they relate to everything else. No prior healthcare knowledge is assumed, and there is no code in this one - just context.

The short version

  • Healthcare interoperability is best understood as a tree, not a timeline. New standards rarely replace old ones; they grow alongside them, borrow from them, and share the same soil.
  • HL7 (founded 1987) is the trunk. Its branches are v2 messaging (still running most hospitals), v3/RIM and CDA (clinical documents), decision support logic (Arden Syntax to CQL and CDS Hooks) and FHIR, the newest and fastest-growing crown.
  • HL7 has roots older than itself - MUMPS, ASTM lab messages, MEDIX, Arden Syntax - and it stands in networking soil (TCP/IP, the OSI model, XML, HTTP, JSON, OAuth) that it never had to invent.
  • It grew next to neighbouring trees: DICOM for imaging, IEEE 11073 for devices, SNOMED CT/LOINC/ICD for meaning, and X12/NCPDP for claims and pharmacy. IHE is the vine that ties them together.
  • Policy is the weather. HIPAA, HITECH, the Cures Act, TEFCA and the EU Health Data Space explain why particular branches grew fast when they did.

“If you want to understand today, you have to search yesterday.” ~ Pearl S. Buck

The Picture

Here is the whole thing. Click the image to open the full-resolution version in a new tab - it is an SVG, so you can zoom in as far as you like without losing detail.

The Healthcare Interoperability Family Tree: networking foundations as soil, pre-HL7 efforts as roots, HL7 as the trunk with v2, v3/CDA, decision support and FHIR branches, neighbouring trees for imaging, terminologies and claims, IHE as a connecting vine, and policy as the climate above

How to read it

Part of the treeWhat it represents
SoilNetworking and data-format foundations. Deeper layers are older: serial lines and ARPANET at the bottom, TCP/IP and the OSI model in the middle, then HTTP, XML, JSON and OAuth near the surface.
RootsThe pre-HL7 efforts that HL7 grew out of, each labelled with what it passed on.
TrunkHL7 International, the standards body itself.
BranchesProduct families. Lower on the trunk means older. An arrowhead at the tip means the branch is still growing.
LeavesReleases and milestones, with years. Filled leaves marked ★ are landmarks.
Grey twigA line that withered.
Dashed arrowsOne standard feeding into another.
VineIHE integration profiles connecting the trees.
SkyUS policy, national networks and global bodies - the climate that drove adoption.

Now let's walk the tree from the ground up.

The Soil: Networking Foundations

None of the healthcare standards had to invent a network, and that is the first thing the picture makes obvious. In the deepest layer sit RS-232 serial links (1960), which is how the first lab analyzers talked to computers and, in more than a few hospital basements, still do. Above it are ARPANET (1969) and the TCP/IP design of the mid-1970s, cut over to become the Internet in 1983.

The middle layer holds my favourite piece of trivia in this whole field. The OSI reference model (1984) describes networking as seven layers, and layer 7 is the application layer - the layer concerned with the meaning of what is exchanged rather than how bits travel. That is where the "Seven" in Health Level Seven comes from. The founders were declaring, right there in the name, that they would leave the wires to someone else. The same layer also gave us MLLP, the almost comically minimal framing protocol that carries HL7 v2 messages over TCP to this day.

The top layer is the web era: HTTP (1991), SSL/TLS, XML (1998), SOAP and REST (2000), JSON (2001), OAuth 2.0 (2012) and OpenID Connect (2014). Two dashed arrows climb out of this layer: XML feeds HL7 v3 and CDA, and REST, JSON and OAuth2 feed FHIR. Each generation of HL7 standards has essentially adopted whatever the mainstream software industry was using at the time, and that is a large part of why each one felt "modern" when it arrived. If this layer is fuzzy for you, my networking quiz and REST API quiz are a painless way to fill the gaps.

The Roots: Before HL7

Before 1987, every hospital system spoke its own dialect. The 1960s and 70s gave us pioneering systems such as MUMPS (1966, Massachusetts General Hospital) and COSTAR (1968), but each connection between two systems was a custom project. With n systems you potentially need n × (n − 1) / 2 interfaces. Twenty systems means up to 190 bespoke interfaces, each with its own quirks, which is exactly the maintenance nightmare HL7 was created to end.

Several early efforts showed that a shared approach was possible, and each left a visible fingerprint on what came next:

  • ASTM E31 (1970) was one of the earliest standards committees for health informatics.
  • ASTM E1238 (1988) standardized the exchange of lab results. Its observation segment is the direct ancestor of the OBX segment you meet in every ORU message.
  • MEDIX / IEEE P1157 (1987) pursued a formal, model-driven, OSI-based approach. It never took off, but its ideas resurfaced a decade later in the HL7 v3 Reference Information Model.
  • Arden Syntax (1989) encoded medical logic as shareable "Medical Logic Modules". It moved under HL7 in 1998 and became the root of the decision-support branch.

If you are interested in the human story of those early years, René Spronk's history of HL7 is the definitive account.

The Trunk and Its Branches: HL7

HL7 was founded in 1987 and became an ANSI-accredited standards development organization in 1994. The trunk is thick for a reason: everything above it shares the same community, governance and ballot process, even when the products look nothing alike.

Branch 1: HL7 v2 messaging (1987 onwards)

The lowest and oldest branch, and still one of the sturdiest. Pipe-delimited, event-triggered messages for admissions, orders, results, scheduling and billing inside the enterprise. The leaves run from v2.1 (1990, the first version widely implemented) through the ever-popular v2.3.1 and v2.5.1 to v2.9 (2019). The arrowhead at the tip is not decoration: HL7 International estimates v2 is still in use at roughly 95% of US healthcare organizations. Pipes and carets, forever. |^~\&

To go deeper, start with HL7 v2 Explained, then my free 14-chapter HL7 v2 tutorial (chapter 2 covers the version history in the tree). If you want to write code, the Java/HAPI series and the .NET/NHAPI series cover creating, sending, receiving, parsing, validating and acknowledging messages.

Branch 2: HL7 v3, the RIM and CDA (1997 onwards)

This is the most interesting branch to look at closely, because it contains the tree's only withered twig. Work on v3 began in the late 1990s with a hugely ambitious goal: a formal Reference Information Model (RIM) from which every message would be derived, fixing v2's optionality and giving everyone shared semantics. v3 messaging itself, published in the 2005 Normative Edition, proved too complex and costly for most implementers and saw little adoption outside a few national programmes.

The branch did not die, though. The Clinical Document Architecture (CDA R1 in 2000, R2 in 2005) grew vigorously, producing the Continuity of Care Document (2007, a graft between CDA and ASTM's CCR), QRDA for quality reporting, FDA's Structured Product Labeling, and eventually Consolidated CDA (2012), which US Meaningful Use turned into the document almost every certified EHR can produce. The lesson I take from it: an elegant model is no substitute for adoptability. I cover the whole family in HL7 V3 Standard - A High Level Overview, and chapter 7 of my healthcare standards tutorial focuses on document standards.

Branch 3: Decision support and quality logic (1998 onwards)

A branch people often forget belongs to HL7 at all. It turns clinical knowledge and quality measures into shareable, executable logic: Arden Syntax, then GELLO (2005), HQMF eMeasures (2010), Clinical Quality Language (CQL) (2015), and CDS Hooks (2019), which lets an EHR call out to external decision-support services at precisely the right moment in a clinician's workflow. Most recently, CMS's digital quality measure roadmap moves quality reporting onto FHIR. Chapter 4 of my healthcare standards tutorial places this branch alongside the rest of the HL7 family.

The crown: FHIR (2011 onwards)

At the top sits the newest growth. FHIR started as Grahame Grieve's 2011 "Resources for Health" proposal, and the tree shows why it caught on so quickly: it was grafted from three sources. From v2 it took pragmatism and a focus on what implementers actually need. From CDA it took clinical content and hard-won modelling experience. From the web soil it took REST, JSON and OAuth2, which meant any web developer could be productive in an afternoon.

The crown splits three ways. The core releases run from DSTU1 (2014) through R4 (2018, the first release with normative content and still the workhorse) to R5 and R6. The apps and APIs twig includes SMART on FHIR, US Core, Bulk Data and SMART Health Cards. The HL7 FHIR Accelerators - Argonaut, Da Vinci, Gravity, Vulcan, CARIN, CodeX and Helios - are where industry groups cultivate FHIR for specific domains such as payer exchange, social determinants of health, research, oncology and public health.

If you are new to FHIR, start with Basics of FHIR and my 18-chapter FHIR tutorial, including chapters on version history and bulk data. For hands-on work, there are complete series in Java with HAPI FHIR and .NET with the Firely SDK, ending with building a SMART on FHIR app in Java or .NET. If you work in Canada, see my articles on the Canadian FHIR profiles in Java and .NET.

The Neighbouring Trees

HL7 never grew alone. Much of the confusion newcomers feel ("wait, is DICOM part of HL7?") disappears once you see these as separate trees standing in the same soil.

  • Imaging, devices and lab. ACR-NEMA (1985) became DICOM 3.0 in 1993, the moment medical imaging moved onto TCP/IP networks, and later gained a RESTful face with DICOMweb (2013). Alongside it grew ASTM E1394/LIS2 for lab analyzers and ISO/IEEE 11073 for bedside and personal devices. My DICOM series starts with DICOM Explained and continues in the DICOM tutorial. FHIR and DICOM covers where the imaging tree touches the FHIR crown.
  • Terminologies. SNOP (1965) and SNOMED (1975) led to SNOMED CT (2002). LOINC (1994) standardized lab and observation codes, RxNorm normalized drug names, and ICD grew from ICD-9-CM to ICD-11. This tree supplies the meaning that rides inside every message, document and resource the HL7 tree produces. See Use of Coded Vocabularies in HL7 and DICOM and chapter 6 of the healthcare standards tutorial.
  • Claims and pharmacy. NCPDP (1977) and ANSI X12 (1979) handle the money and the medications: eligibility, claims, remittance and e-prescribing. HIPAA (1996) turned their transactions into federal mandates, which is why the X12 4010 and 5010 leaves line up with regulatory deadlines rather than technical milestones.

The Vine: IHE

Standards on their own do not make a workflow. IHE (Integrating the Healthcare Enterprise, 1998) is the vine winding between the trees. Its integration profiles specify exactly which parts of HL7, DICOM and the terminologies to combine, and how, to accomplish a real task: sharing documents across organizations (XDS, 2005), matching patient identities (PIX/PDQ), or doing the same over FHIR (MHD, 2014). See my overview of IHE and DICOM, HL7 and IHE integration to watch the vine in action.

The Climate: Policy and Networks

The sky band at the top is where I finally understood why certain branches sprouted when they did. Standards grow fastest when regulation makes it rain.

  • HIPAA (1996) mandated standard transactions and created privacy and security obligations. See HIPAA and Regulatory Compliance for Healthcare.
  • HITECH and Meaningful Use (2009) paid providers to adopt certified EHRs - and that is precisely when C-CDA and v2.5.1 reporting interfaces spread everywhere.
  • The 21st Century Cures Act (2016) and the ONC Cures Act Final Rule (2020) required standardized FHIR R4 APIs and prohibited information blocking. That is the dashed arrow from FHIR R4 into the sky.
  • TEFCA (2022), HTI-1 (2024) and CMS-0057-F (2024, with payer prior-authorization APIs due in 2027) continue that trajectory.
  • Globally, CEN/TC 251, ISO/TC 215, openEHR, the International Patient Summary and the European Health Data Space (2025) shape the weather outside the US.

Chapter 11 of my healthcare standards tutorial covers the regulatory landscape in more depth.

Five Things the Tree Taught Me

  1. Nothing is ever really replaced. v2 did not die when v3 arrived, and it is not dying now that FHIR is here. Hospitals end up layered like tree rings, and a working engineer needs to be comfortable in several of those layers at once.
  2. Adoptability beats elegance. The branches that grew fastest (v2, FHIR) were the ones an ordinary developer could pick up quickly. The most intellectually rigorous one (v3 messaging) withered.
  3. Syntax is easy; meaning is hard. The terminology tree is quiet and unglamorous, but without it every message is just well-formatted ambiguity.
  4. Policy is an accelerant. Several of the big growth spurts in the picture line up with legislation or incentive programmes rather than with technical breakthroughs.
  5. Lineage explains quirks. Why does OBX look the way it does? Why does a FHIR Composition feel like a CDA header? Why does MLLP exist at all? Knowing the family history turns "legacy weirdness" into "oh, that's why".

A note on dates

The years on the tree mark first publication, founding or regulatory effective date. A few are approximate: openEHR emerged from the GEHR project over several years around 2000, and the R6 leaf reflects FHIR R6 still being balloted at the time of writing. If you spot something you remember differently - especially if you were in the room - please tell me and I will happily prune or graft accordingly.

Test Yourself

If the tree has you curious about a particular branch, these quizzes are a quick way to check how well you know it:

Where to Go Next

If you work with HL7, FHIR or DICOM and want to compare notes with other engineers doing the same, join the discussion in my LinkedIn group on healthcare interoperability engineering. I would especially love to hear which leaf you started on, and which branch has kept you busiest since.

For the early history of HL7 in the words of someone who lived it, read René Spronk's article. For the current state of each branch, the HL7 International, DICOM and IHE websites are the authoritative sources.