HL7 vs FHIR: how v2, CDA and FHIR differ, and where each still fits

Direct answer

HL7 is a standards organization, and FHIR is one of its standards, so "HL7 vs FHIR" usually means HL7 Version 2 messaging versus FHIR. HL7 v2 sends pipe-delimited event messages, mostly over TCP inside a hospital, and still carries most admissions, orders and results. FHIR exposes granular resources such as Patient and Observation through REST APIs in JSON, which suits apps, partners and regulated APIs. CDA, the third HL7 family in daily use, packages a whole clinical document. Most organizations run all three; the real decision is which interface uses which.

HL7 is the organization, FHIR is one of its standards

HL7 International publishes several standard families. The ones integration teams handle every week:

• HL7 Version 2, the event-messaging standard. The latest normative release is v2.9.1, published in September 2024, but interfaces in the field commonly run on 2.3 to 2.5.1 because sender and receiver must agree on a version.
• CDA (Clinical Document Architecture) Release 2, an XML document standard. In the US it is constrained by C-CDA, whose 5.0.0 release was published in June 2026 and still builds on CDA R2.0.
• FHIR, the resource and API standard. FHIR R4 (4.0.1) is the most deployed release, R5 (5.0.0) was published in 2023, and R6 is still in ballot. The FHIR API guide covers versions and REST details.

HL7 v3 messaging and its Reference Information Model saw limited adoption outside a few national programmes; you mostly meet them today through CDA, which was derived from the RIM.

HL7 v2 vs CDA vs FHIR at a glance

Two of those cells deserve a citation. In the US, certified EHRs must offer a FHIR R4 API under §170.315(g)(10). In France, the content profiles of the CI-SIS for documents shared in the DMP are CDA-based, while newer national specifications use FHIR.

The same admission in HL7 v2 and in FHIR

A synthetic inpatient admission (ADT^A01) as an HL7 v2.5.1 message:

MSH|^~\&|DEMO_EHR|DEMO_FACILITY|DEMO_API|DEMO_DEST|20261005100000+0100||ADT^A01^ADT_A01|DEMO-MSG-001|P|2.5.1
EVN|A01|20261005100000+0100
PID|1||DEMO-P001^^^DEMO_HOSPITAL^MR||DOE^JANE||19900101|F
PV1|1|I|WARD1^101^A^DEMO_FACILITY||||||||||||||||DEMO-V001|||||||||||||||||||||||||20261005100000+0100

The same facts as FHIR R4 resources, sent as a transaction:

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "urn:uuid:5b2f6c1e-0d6a-4f1e-9a51-2a1f0c0e7a01",
      "resource": {
        "resourceType": "Patient",
        "identifier": [{ "system": "https://example.org/demo-hospital/patients", "value": "DEMO-P001" }],
        "name": [{ "family": "DOE", "given": ["JANE"] }],
        "gender": "female",
        "birthDate": "1990-01-01"
      },
      "request": { "method": "POST", "url": "Patient", "ifNoneExist": "identifier=https://example.org/demo-hospital/patients|DEMO-P001" }
    },
    {
      "resource": {
        "resourceType": "Encounter",
        "identifier": [{ "system": "https://example.org/demo-hospital/visits", "value": "DEMO-V001" }],
        "status": "in-progress",
        "class": { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "IMP" },
        "subject": { "reference": "urn:uuid:5b2f6c1e-0d6a-4f1e-9a51-2a1f0c0e7a01" },
        "period": { "start": "2026-10-05T10:00:00+01:00" }
      },
      "request": { "method": "POST", "url": "Encounter" }
    }
  ]
}

The difference that matters most is not syntax. A v2 message says "this event happened"; a FHIR REST write says "this is the current state". An A08 update or an A11 cancellation has to be translated into an update of the existing Encounter, and someone must decide whether a cancelled admission becomes cancelled or entered-in-error. HL7's v2-to-FHIR implementation guide (1.0.0, published October 2025) gives reusable segment and data-type mappings; the message types reference shows the source messages in more detail.

Is FHIR replacing HL7 v2?

Not in the near term. FHIR is replacing v2 at the edges of the organization, where apps, partners and regulators need APIs, and it is the default for new national programmes. Inside the hospital, v2 feeds keep running because they are cheap, fast and already tested, and because many departmental systems have no FHIR interface at all. Expect years of coexistence, with an interface engine translating between the two.

When to keep HL7 v2 and when to move to FHIR

Keep v2 where it works:

• High-volume feeds inside one organization (ADT to the lab system, results back from the LIS) that are stable and monitored.
• Lab, radiology and device systems that only speak v2.
• Workflows that depend on MLLP acknowledgements and strict message ordering.

Add FHIR where v2 cannot reach:

• External apps, patient access and partner integrations that need authenticated APIs.
• Regulated APIs, such as US certified EHR APIs and payer APIs.
• Use cases that need queries ("all results for this patient since January") rather than pushed events.
• Cloud data platforms and new products, where JSON over HTTPS cuts onboarding time.

The common architecture is a facade: v2 keeps flowing into an interface engine, which maintains FHIR resources for API consumers. Replacing working v2 feeds rarely pays for itself on its own. The v2 to FHIR migration strategy covers sequencing, dual running and the pitfalls (Z-segments, repeating OBX groups, local codes that need terminology mapping).

CDA keeps its place where a signed, human-readable document is the point: discharge letters, referral summaries, national shared records. FHIR has its own document Bundle, and many programmes now convert between the two; see C-CDA to FHIR document exchange.

Interoperability levels

ONC frames interoperability as secure exchange and use of electronic health information among authorized users. HIMSS describes four levels, a useful checklist for any interface:

1. Foundational: data moves from one system to another.
2. Structural: the format is standardized, which is where v2, CDA and FHIR syntax sit.
3. Semantic: both sides share the meaning, through code systems such as LOINC and SNOMED CT.
4. Organizational: governance, consent, contracts and policy allow the exchange.

Most integration projects that slip do so at levels 3 and 4, not at the parser.

Other standards you will meet

• DICOM is the imaging standard: object formats plus network services between modalities, PACS and viewers. DICOMweb adds RESTful services (QIDO-RS, WADO-RS, STOW-RS) that sit comfortably beside FHIR ImagingStudy.
• IHE profiles combine standards into tested workflows: XDS.b for document sharing, PIX and PDQ for patient identity, and FHIR-based profiles such as MHD and PDQm. See the IHE profile catalogue and the IHE guide for European integration.
• Terminologies carry meaning inside any of these formats: LOINC for lab tests and observations, SNOMED CT for clinical findings and procedures (check national licensing), plus ICD-10 for classification and UCUM for units.
• openEHR specifies archetype-based clinical data repositories. It answers a storage and modelling question, while FHIR answers an exchange question, and the two are often combined. See openEHR and the openEHR vs FHIR comparison.

Getting started

1. Read a real v2 message segment by segment, then the FHIR resources it should become.
2. Run a FHIR server locally (HAPI FHIR is a common starting point) and practise search, transactions and validation.
3. Build one interface in an engine such as Mirth Connect: MLLP in, FHIR out, with acknowledgements and error queues.
4. Learn the code systems your domain depends on before the formats; most mapping bugs are terminology bugs.
5. Ask questions on chat.fhir.org, where HL7 work group members answer.

If you are deciding which interfaces to keep on v2 and which to expose as FHIR, the digital health interoperability service covers that kind of architecture review.