HL7 & FHIR: a plain-language primer
Almost every story about health data exchange comes down to two standards from HL7 International: the long-serving HL7 v2 messaging standard, and FHIR, its modern web-based successor. This is the newcomer's guide to what each one is, where it is used, and how the two fit together today.
Start with the names
What "HL7" actually refers to
HL7 stands for Health Level Seven International, the standards body that publishes most of the rules for moving clinical data between systems. The name is also used as shorthand for its oldest and most widespread standard, HL7 Version 2 (HL7 v2), first released in the late 1980s and still carrying the majority of clinical messaging in the United States today.
FHIR — Fast Healthcare Interoperability Resources, pronounced "fire" — is HL7's newer standard, first published in 2014. Where HL7 v2 is a messaging format, FHIR is built on the same web technology as the rest of the modern internet: it uses REST APIs and the JSON and XML data formats, so a developer who has worked with any web service will recognise how it behaves.
Messages versus resources
HL7 v2 is a push standard. When something happens — a patient is admitted, a lab result is finalised — the source system builds a pipe-delimited message and pushes it to the systems that need to know. An ADT message announces an admission, discharge or transfer; an ORU message carries an observation result. The format is compact and proven, but it allows so much local variation that two hospitals can both send "standard" ADT messages that look quite different in practice.
FHIR organises the same information into resources — discrete, well-defined objects such as Patient, Observation, MedicationRequest or Device — that a system can request on demand through an API. Instead of waiting for a message to be pushed, a clinician's application can ask a server directly: give me this patient's recent observations. That pull model, plus the consistent JSON structure, is why FHIR is far easier and cheaper to build against for new integrations.
How the two standards are used today
HL7 v2 and FHIR are not a clean before-and-after. Most health systems run both at once, and understanding why is the key to the whole picture.
HL7 v2 still moves the routine traffic
Decades of hospital interfaces — admissions, lab orders and results, scheduling — run on HL7 v2. These interfaces are stable and expensive to replace, so v2 is not going away; it is the workhorse carrying the high-volume, system-to-system messaging that already works.
C-CDA carries the document-level summary
When a full clinical summary needs to travel between organisations — a transition-of-care document at discharge, for example — it is often packaged as a Consolidated Clinical Document Architecture (C-CDA) document. C-CDA sits alongside v2 messaging in many exchanges.
FHIR powers new apps and patient access
FHIR is the standard behind app-based access to records, patient-facing apps, and modern point-of-care integrations. In the US, the 21st Century Cures Act made FHIR Release 4 (R4) the required baseline, so the major EHRs all expose certified FHIR R4 APIs.
Bridges connect the old to the new
In practice, integration engines translate between v2 messages, C-CDA documents and FHIR resources so that a hospital's existing v2 infrastructure can still feed a FHIR-based app. The migration is gradual and layered, not a switch that gets flipped.
R4 is the version that matters in the US right now
FHIR has had several releases. Release 4 (R4), published in 2019, is the current production standard and the US regulatory baseline — the 21st Century Cures Act rules point to it, and Epic, Oracle Health (Cerner) and other major EHRs have certified R4 APIs. Release 5 (R5), published in 2023, refines several areas, notably real-time subscriptions, but is not yet widely deployed. Release 6 (R6) is still in ballot.
The practical advice AzHeC gives Arizona stakeholders is the same advice the wider community gives: build on R4 today because that is where compliance and EHR support actually live, and design with enough flexibility to adopt R5 capabilities as support matures.
Frequently asked questions
01Is FHIR replacing HL7 v2?
Not in the near term. FHIR is the future for new applications and patient access, but HL7 v2 still carries most of the routine hospital messaging in production today, and those interfaces are stable. The realistic picture is the two running side by side for years, with integration engines bridging between them.
02What is the difference between an HL7 v2 message and a FHIR resource?
An HL7 v2 message is a pipe-delimited block of text pushed from one system to another when an event occurs. A FHIR resource is a structured object — in JSON or XML — that a system can request on demand through a web API. The message is sent to you; the resource is fetched by you.
03What is C-CDA, and how does it fit?
C-CDA (Consolidated Clinical Document Architecture) is an HL7 standard for full clinical documents, such as a continuity-of-care or discharge summary. It is document-level rather than message-level or resource-level, and it is widely used to move complete summaries between organisations in an exchange.
04Do I need to understand all of this to benefit from exchange?
No. Clinicians and administrators see the result — a complete record at the point of care — not the plumbing. This primer exists so that the people planning, governing or procuring exchange can speak the language accurately. For anything unfamiliar, our glossary gives one-line definitions.
Ready to see standards at work?
The HL7 and FHIR ideas here are exactly what carry a patient's record across The Network, Arizona's statewide health information exchange. See how the pieces connect end to end.