HL7 vs FHIR: Healthcare Integration Guide

Radiatus Engineering Healthcare Published 25 Jun 2026 Updated 4 Oct 2026 5 min read

If you work in healthcare IT, "HL7" and "FHIR" come up constantly — often as if they were competitors. They aren't. FHIR is itself an HL7 standard; HL7 v2, CDA and FHIR are 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 such as Mirth Connect ties them together in the real world.

The healthcare interoperability landscape

A single hospital might run an EHR, a laboratory information system (LIS), radiology (RIS/PACS), pharmacy, 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 of systems.

HL7 v2: the workhorse

HL7 version 2 is the most widely deployed healthcare messaging standard. It uses compact, delimited text messages (segments separated by carriage returns, fields by the pipe | character, components by the caret ^) triggered by real-world events:

• ADT — admit, discharge, transfer and patient-update events
• ORM / OML / OMG — orders (ORM in older versions; OML for lab orders and OMG for general clinical orders in later v2 releases)
• ORU — observation results, such as lab results returning to the EHR
• SIU — scheduling; MDM — medical documents; DFT — financial transactions and charges

Messages usually travel over TCP using the MLLP framing protocol, inside a VPN or TLS tunnel, and each one is acknowledged with an ACK. HL7 v2 is battle-tested and everywhere — but it is loosely specified and highly customisable (Z-segments, optional fields), so real-world messages vary between vendors and even between sites running the same product. That variability is exactly why an integration engine and experienced mapping are essential.

HL7 v3 and C-CDA

HL7 v3 introduced a rigorous, model-driven XML approach but saw limited adoption for messaging. Its most successful descendant is the Clinical Document Architecture, and in the US specifically C-CDA (Consolidated CDA) — the XML document format used for care summaries, referrals and discharge documents, and for exchange through Health Information Exchanges (HIEs). If you're sharing documents across organisations, you're very likely dealing with C-CDA.

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. FHIR R4 is the release most production systems implement today, and it is the foundation of US regulatory interoperability under the 21st Century Cures Act through the US Core implementation guide and the USCDI data set. Outside the US, national programmes build on it too — India's Ayushman Bharat Digital Mission (ABDM), for example, uses FHIR R4-based profiles for health records.

FHIR adds modern building blocks older standards lacked: SMART on FHIR for OAuth 2.0-secured app launch and access to EHR data, Bulk FHIR ($export) for population-level extracts, and CDS Hooks for decision support inside the clinician's workflow. FHIR can also be used for messaging and documents, but its REST API is where most adoption is.

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, analysers' middleware and ancillary systems already speak.
• Use C-CDA for document-level exchange, especially with HIEs and for transitions of care.
• Use FHIR for modern APIs, patient- and provider-facing apps, analytics extracts, payer and patient-access APIs, and anywhere Cures Act / US Core conformance is required.

In practice most organisations run all of them at once — new FHIR APIs on top of an estate that still moves large volumes of HL7 v2 messages every day. The question is rarely "HL7 or FHIR?" but "where does each one belong, and what translates between them?"

Where the integration engine comes in

That translation is the job of an integration engine. Mirth Connect is the best-known example: for years it was open source, and from version 4.6 NextGen Healthcare made it a commercially licensed product, while the community continues the last open-source codebase as the Open Integration Engine. Commercial engines such as Rhapsody and InterSystems products fill the same role.

An engine receives messages in one format, validates and transforms them, applies routing and filtering, and delivers them reliably — with queuing, error handling, alerting 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 sending a C-CDA to an HIE. It's the translation layer that makes a mixed-standard estate behave like one system.

Lab software is a good example of all of this in one place: our own PathLab Software interfaces with analysers over HL7 and ASTM before results are validated and reported.

Getting it right

The standards are only half the battle; the other half is the messy reality of:

• Vendor-specific variations and Z-segments that need per-interface mapping
• Code systems — local lab codes versus LOINC, SNOMED CT and ICD — and the terminology mapping between them
• Patient identity matching across systems with different identifiers
• Character encodings, time zones and date formats
• Secure transport (MLLP over VPN or TLS, HTTPS with OAuth for FHIR) and audit logging of every message containing PHI — see our guide to HIPAA-aligned workloads on AWS
• Monitoring, alerting and a reprocessing procedure for when (not if) a downstream system is unavailable

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, C-CDA and X12 EDI — through HL7, FHIR & EDI integration, Mirth Connect development and support, FHIR & SMART on FHIR, interface engine support and HIE integration. Talk to an integration engineer about your interoperability roadmap.