HL7 vs FHIR: A Practical Guide to Healthcare Integration

Healthcare  ·  June 25, 2026  ·  10 min read

If you work in healthcare IT, "HL7" and "FHIR" come up constantly — often as if they were competitors. They aren't. They're different generations and styles of the same mission: letting healthcare systems exchange data reliably. This guide explains what each standard is, when to use it, and how an integration engine like Mirth Connect ties them together in the real world.

The healthcare interoperability landscape

A single hospital might run an EHR, a lab system (LIS), radiology (RIS/PACS), a pharmacy system, billing, and a dozen departmental applications — often from different vendors. None of them speaks the others' internal language. Interoperability standards are the shared vocabulary that lets them exchange orders, results, admissions and documents without custom point-to-point code for every pair.

HL7 v2: the workhorse

HL7 version 2 is the most widely deployed healthcare messaging standard in the world. It uses compact, pipe-and-hat delimited messages triggered by events:

• ADT — admit, discharge, transfer (patient movement)
• ORM / OMG — orders (e.g. a lab test request)
• ORU — observation results (e.g. lab results returning)
• SIU — scheduling; MDM — documents; DFT — billing

HL7 v2 is battle-tested and everywhere — but it is loosely specified, so real-world messages vary between vendors. That variability is exactly why an integration engine and experienced mapping are essential.

HL7 v3 and CCDA

HL7 v3 introduced a rigorous XML model but saw limited adoption. Its most successful survivor is CCDA (Consolidated Clinical Document Architecture) — the XML document format used for care summaries and for exchange with Health Information Exchanges (HIEs). If you're sharing documents across organisations, you're very likely dealing with CCDA.

FHIR: the modern API standard

FHIR (Fast Healthcare Interoperability Resources) is the current direction of travel. Instead of event-triggered messages, FHIR models healthcare concepts as resources (Patient, Observation, Encounter, MedicationRequest) exposed through a RESTful web API using JSON or XML. It's developer-friendly and, crucially, it's the foundation of US regulatory interoperability under the 21st Century Cures Act via US Core and USCDI.

FHIR adds modern building blocks that older standards lacked: SMART on FHIR for OAuth 2.0-secured app access to EHR data, Bulk FHIR ($export) for population-level extracts, and CDS Hooks for decision support inside the clinician workflow.

HL7 vs FHIR: when to use which

• Use HL7 v2 for real-time, event-driven feeds between clinical systems inside and between facilities — it's what labs, EHRs and ancillary systems already speak.
• Use CCDA for document-level exchange, especially with HIEs and for care transitions.
• Use FHIR for modern APIs, patient- and provider-facing apps, analytics extracts, and anywhere Cures Act / USCDI compliance is required.

In practice most organisations run all of them at once — new FHIR APIs on top of an estate that still moves millions of HL7 v2 messages a day.

Where the integration engine comes in

This is the job of an integration engine like Mirth Connect (now the community-driven Open Integration Engine). It receives messages in one format, transforms and validates them, applies routing and filtering, and delivers them reliably — with error handling and reprocessing. A single engine can accept an inbound HL7 v2 ORU, map it to a FHIR Observation, and post it to an EHR's FHIR API, while also archiving a CCDA to an HIE. It's the translation layer that makes a mixed-standard estate behave like one system.

Getting it right

The standards are only half the battle; the other half is the messy reality of vendor-specific variations, character encodings, timezone handling, patient-identity matching and secure transport (TLS, MLLP, VPN). This is where experience pays for itself — a well-designed channel is reliable and maintainable for years, while a rushed one becomes a 2am support call.

HL7 and FHIR aren't rivals — they're layers of the same interoperability story. The winning move is a clean integration architecture that speaks all of them.

Radiatus builds and supports healthcare interfaces across HL7 v2, FHIR, CCDA and EDI — with Mirth Connect development, FHIR & SMART on FHIR, and HIE integration. Talk to an engineer about your interoperability roadmap.