HL7 vs FHIR: The Complete Technical Comparison for Healthcare Engineers in 2026

Healthcare interoperability has been plagued by competing standards for decades. If you are building on or integrating with healthcare systems in 2026, you will encounter HL7 v2, HL7 v3, CDA (Clinical Document Architecture), and FHIR R4 — sometimes all four in the same project. Understanding the fundamental differences between these standards is not academic — it directly affects your architecture decisions, integration costs, and the long-term viability of what you build.

I have worked with all four standards in production healthcare systems, including building a FHIR R4 data warehouse that ingests HL7 v2 ADT feeds from 20,000+ facilities and transforms them to FHIR R4 resources. This comparison is grounded in that real-world experience.

The Quick Answer

If you are building anything new in 2026, use FHIR R4. Full stop. If you are maintaining or integrating with existing systems, you need to understand HL7 v2 deeply because it is still everywhere and will remain so for years. HL7 v3 and pure CDA are legacy — understand them enough to work with existing implementations, but do not build new systems using them.

Now let us understand why.

HL7 v2: The Standard That Runs Healthcare

HL7 version 2 (v2) was first published in 1987 and has been continuously updated through version 2.9. Despite being designed before the world wide web existed, HL7 v2 is still the most widely deployed healthcare messaging standard globally. The vast majority of hospital laboratory, ADT, and order/results interfaces in the United States run on HL7 v2.

What HL7 v2 Looks Like

HL7 v2 messages are pipe-delimited text messages. Here is a simple ADT A01 (Admit) message:

MSH|^~\&|SENDING_APP|FACILITY|RECEIVING_APP|FACILITY|20260312143000||ADT^A01|MSG001|P|2.5
EVN|A01|20260312143000
PID|1||12345^^^FACILITY^MR||Smith^John^A||19680412|M|||123 Main St^^Springfield^IL^62701^USA|||||||555-12-3456
PV1|1|I|3 WEST^301^A^MH|||^Attending^Doctor^^MD|^Referring^Physician^^MD||||||||||||V001|

Each segment (MSH, EVN, PID, PV1) starts with a three-letter identifier. Fields are separated by |, components by ^, sub-components by &, and repetitions by ~. This syntax made sense on 1980s hardware. It is hostile to modern tooling.

HL7 v2 Strengths

• Ubiquity — virtually every hospital system, laboratory, and legacy EMR speaks HL7 v2. If you need to connect to existing infrastructure, you will speak HL7 v2.
• Simplicity (for experienced implementers) — the message structure is deterministic and well-understood by anyone who has worked with it.
• Performance — HL7 v2 messages are compact. High-throughput ADT feeds (millions of messages per day) are practical.
• Battle-tested — 35+ years of production use has flushed out implementation bugs in every major system.

HL7 v2 Weaknesses

• No semantic consistency — HL7 v2 is deliberately flexible, which means every implementation is different. The same concept might live in different fields across different vendor implementations. Field Z-segments (custom extensions) are everywhere.
• No standardised API — HL7 v2 messages are exchanged over MLLP (Minimum Lower Layer Protocol), a simple TCP-based transport that predates HTTP. There is no REST API, no OAuth, no standard query interface.
• No structured terminology enforcement — HL7 v2 allows free text where terminology codes should be, making automated semantic processing unreliable.
• No versioning mechanism — version negotiation between HL7 v2 systems is fragile. Version 2.3 and version 2.5 messages are sometimes incompatible in ways that cause silent data loss.

When You Still Use HL7 v2 in 2026

• High-volume ADT event streams from legacy hospital systems and post-acute care EMRs — HL7 v2 ADT is still more efficient than FHIR for pure event notification at millions of messages per day
• Interfacing with laboratory systems and radiology PACS that have not migrated to FHIR
• Maintaining integrations with existing hospital infrastructure where replacing the interface would require renegotiating vendor contracts

HL7 v3: The Standard Nobody Uses

HL7 version 3 was developed in the 1990s and 2000s as a comprehensive re-design of HL7 v2 — addressing its semantic inconsistencies with a formally-defined Reference Information Model (RIM) and XML-based message format. It was ambitious, theoretically rigorous, and a practical failure.

HL7 v3 adoption was limited to a small number of national health information architectures (the UK NHS spine used it, some Canadian provincial systems) and is not in common use in the US healthcare system. If you encounter it, it is almost certainly in a legacy national or regional health information exchange context.

The v3 lesson for FHIR: The HL7 organisation explicitly designed FHIR to avoid the complexity that made v3 impractical. FHIR R4's Pareto design — covering 80% of healthcare data exchange needs with 20% of the complexity of v3 — reflects what the committee learned from v3's failure.

CDA: Structured Clinical Documents

The Clinical Document Architecture (CDA) is an HL7 standard for clinical documents — discharge summaries, continuity of care documents, procedure notes, and similar long-form clinical records. CDA documents use a combination of a structured header (based on HL7 v3 RIM) and a body that can contain either structured XML or human-readable narrative.

C-CDA: The US Meaningful Use Implementation

The Consolidated CDA (C-CDA) is the US-specific implementation guide for CDA, required by ONC Meaningful Use criteria. C-CDA defines specific document templates for common clinical documents:

• Continuity of Care Document (CCD) — a patient health summary containing problems, medications, allergies, results, and procedures
• Discharge Summary — documentation of a hospital stay at discharge
• Progress Note — ambulatory visit documentation
• Referral Note — referral from one provider to another

C-CDA Strengths

• Mandated for Meaningful Use — health systems are required to generate and exchange C-CDA documents for transitions of care and patient access requests
• Human-readable section — every C-CDA section contains both machine-readable coded data and human-readable narrative, making it robust to parsing errors
• Document-centric — well-suited for clinical document exchange (discharge summaries, referral packets) where the document as a complete unit has legal and clinical significance

C-CDA Weaknesses

• Verbose XML — a single CCD document can exceed 1MB of XML for a patient with a rich clinical history, most of it structural boilerplate
• Inconsistent structured content — the narrative section is required; the coded data in the structured section is frequently incomplete, incorrect, or missing entirely, making automated processing unreliable
• Not queryable — C-CDA is document-exchange, not a queryable API. Getting a specific lab result from a patient's history requires retrieving and parsing the full CCD document
• Complex template structure — C-CDA templates nest deeply, and template conformance validation is complex

When You Still Use C-CDA in 2026

• Transition of care document exchange (required for hospital discharge to post-acute care)
• Direct messaging (the Carequality and CommonWell networks exchange C-CDA documents)
• Patient access to their complete health record via patient portal download
• State and federal public health reporting where C-CDA is specifically required

FHIR R4 has a C-CDA-to-FHIR conversion specification, and FHIR DocumentReference and Bundle[type=document] are the FHIR equivalents for document exchange. Migration from C-CDA to FHIR document exchange is a work in progress across the industry.

FHIR R4: The Modern Standard

FHIR R4 was designed from the ground up to address the failures of HL7 v2, v3, and CDA:

• The simplicity and REST API approach that HL7 v3 lacked
• The semantic structure and terminological rigour that HL7 v2 lacked
• The granular queryability that CDA lacked
• The developer experience that none of the predecessors had

What Makes FHIR Different

REST API by default. FHIR resources are accessed and manipulated through a standard REST API using HTTP methods. This is something every modern developer knows how to use.

GET /Patient/12345                           # Read a patient
GET /Observation?patient=12345&code=2339-0   # Search lab results
PUT /MedicationRequest/67890                 # Update a medication order
POST /Bundle                                 # Transaction bundle

JSON-native. FHIR resources are defined and primarily exchanged as JSON. Every modern programming language and framework handles JSON natively.

Structured terminology. FHIR resources use coded values from standard terminologies (SNOMED CT, LOINC, RxNorm) with explicit system URLs, making automated semantic processing reliable.

Granular resources. Instead of monolithic documents, FHIR exchanges granular resources. Want a patient's active medications? GET /MedicationRequest?patient=12345&status=active. No need to retrieve and parse a 1MB CCD document.

Profile framework. US Core Implementation Guide profiles constrain base FHIR resources for US healthcare interoperability. Profiles define which fields are required, which terminology bindings apply, and which extensions are standard. This is what HL7 v3's RIM tried to achieve with formal modelling — FHIR achieves it practically through StructureDefinitions and Implementation Guides.

Implementation Guide ecosystem. Beyond US Core, the FHIR IG ecosystem covers specific use cases: Da Vinci (payer-provider data exchange), SMART on FHIR (security), Bulk Data Access (population health), and dozens of specialty-specific IGs. The standards ecosystem around FHIR is rich and actively developed.

FHIR R4 vs R5

FHIR R5 was published in 2023 with significant improvements — particularly for subscriptions, logical models, and extensions. However:

• ONC mandates FHIR R4, not R5
• All major EHR FHIR APIs are R4 (Epic, Athena, PointClickCare)
• US Core profiles are based on FHIR R4
• Production implementations are R4

Build R4. Monitor R5. The FHIR community expects R5 adoption to accelerate starting around 2027-2028 as ONC regulations evolve.

Side-by-Side Comparison

| Feature | HL7 v2 | HL7 v3 | CDA/C-CDA | FHIR R4 | |---------|--------|--------|-----------|---------| | API style | MLLP (TCP) | SOAP/HTTP | HTTP document exchange | REST/HTTP | | Data format | Pipe-delimited text | XML | XML | JSON (primary) | | Query capability | None | Limited SOAP queries | None (document fetch only) | Full REST search | | Semantic consistency | Low (flexible) | High (over-specified) | Medium | High (profile-constrained) | | Developer experience | Poor | Very poor | Poor | Good | | EHR support | Universal | Very limited | Universal (C-CDA) | Mandatory (ONC) | | US regulatory status | Legacy (still required) | Not mandated | Required for transitions | Mandated (ONC 21st CC) | | Real-time event support | Yes (ADT feeds) | Limited | No | Yes (Subscriptions) | | Bulk data access | No | No | No | Yes ($export) | | OAuth security | No | No | Via Direct messaging | Yes (SMART on FHIR) |

The Migration Reality: HL7 v2 to FHIR

For most healthcare organisations, the practical question is not "HL7 v2 vs FHIR" — it is "how do we migrate from HL7 v2 to FHIR while maintaining existing integrations."

The migration approach I use:

1. Transform at ingest, not at source. Do not attempt to modify source systems. Build a transformation layer that converts HL7 v2 messages to FHIR R4 resources at the integration boundary. Azure API for FHIR includes an HL7 v2 converter; HAPI FHIR supports custom message parsers; Mirth Connect can transform HL7 v2 to FHIR with custom channel scripts.

2. Maintain HL7 v2 feeds for high-volume event streams. ADT event streams at 1M+ messages/day are best maintained as HL7 v2 for performance and cost reasons, even as the downstream storage is FHIR. Transform HL7 v2 ADT to FHIR Encounter and Patient resources in the processing pipeline.

3. Preserve source HL7 v2 messages. Store original HL7 v2 messages alongside the FHIR representation. HL7 v2 messages contain nuances (Z-segments, local codes) that may be important later. Treat FHIR as the canonical representation but keep the source.

4. Migrate systematically by data domain. Start with the highest-value, most frequently-accessed data domains (Patient demographics, Encounters, Observations). Migrate progressively — do not attempt a big-bang migration.

5. Validate US Core conformance. After transformation, validate FHIR resources against US Core profiles. Transformation errors will produce non-conformant resources that fail downstream system expectations.

C-CDA to FHIR: The Document Migration

Converting C-CDA documents to FHIR resources is complex because C-CDA sections contain both structured data (machine-readable) and narrative (human-readable), and the structured data is frequently incomplete or inconsistent.

The practical approach:

• Use the HL7-published C-CDA on FHIR Implementation Guide as your mapping reference
• Convert structured sections (medications, problems, allergies, results) to corresponding FHIR resources
• Preserve the C-CDA document as a FHIR DocumentReference with the original XML attached for auditability
• Validate extracted FHIR resources and flag low-confidence conversions for human review

Commercial tools (Microsoft's FHIR Converter, Health Gorilla's C-CDA converter) can handle the mechanical conversion. But no automated tool handles all the edge cases in real-world C-CDA documents — plan for manual review and exception handling.

Choosing the Right Standard for Your Use Case

After all of this, the guidance is straightforward:

Building a new healthcare application: Use FHIR R4. Design your data model in FHIR resources from day one.

Integrating with hospital systems: You will receive HL7 v2 from most existing interfaces. Transform to FHIR at the integration layer.

Implementing patient access to records: FHIR R4 patient access API is the ONC mandate. Implement this.

Exchanging clinical documents (referrals, discharge summaries): C-CDA for existing document exchange networks; FHIR DocumentReference for new FHIR-native implementations.

High-volume event streaming from legacy post-acute EMRs: HL7 v2 ADT feeds are still the most practical approach for millions of events per day. Transform to FHIR downstream.

Building payer-provider data exchange: FHIR R4 and the Da Vinci Project implementation guides.

The standards landscape is not either/or. Production healthcare systems in 2026 use FHIR R4 as the canonical data representation while maintaining HL7 v2 ingest capabilities for the legacy system reality that will persist for another decade.

Muhammad Moid Shams is a Lead Software Engineer specialising in FHIR R4 platform architecture and healthcare interoperability. He has built FHIR platforms that process 50+ million FHIR data points across 20,000+ US Skilled Nursing Facilities.