HL7 v2, CDA, and FHIR
Healthcare has produced three major data exchange standards over 40 years. Each generation solved a real problem. Each brought new problems. Understanding all three explains why FHIR is the way it is.
HL7 v2 — the pipe standard (1987)
HL7 version 2 was designed when network bandwidth was expensive, computers were slow, and JSON did not exist. It encodes messages as pipe-delimited text — a compact format that could be transmitted efficiently over serial connections.
MSH|^~\&|HISSYS|HOSPITAL|LABSYS|LAB|202606061200||ADT^A01|MSG001|P|2.5 EVN|A01|202606061200 PID|1||HORVATH001^^^HOSPITAL^MR||Horváth^Jana^||19790312|F|||Bratislava PV1|1|O|CARDIO^101^1^HOSPITAL||||DR^Novák^Ján
Strengths: Compact. Fast. Implemented everywhere — virtually every hospital system in the world sends and receives HL7 v2.
Problems: No formal schema. The "standard" has hundreds of regional variants. Segment Z (custom extensions) proliferated — every vendor has their own flavour. Parsing requires specialized knowledge. No standard for querying — only event-driven push messages.
Still used today: Hospital ADT feeds, lab result delivery, radiology worklists. The integration engine market (Mirth, Rhapsody, Infor Cloverleaf) exists almost entirely to translate between HL7 v2 variants.
CDA — Clinical Document Architecture (2005)
CDA was designed to represent clinical documents — discharge summaries, referral letters, lab reports — in a structured, signed, human-readable format. It is XML-based and defines a document model with a mandatory human-readable section and an optional machine-readable body.
<ClinicalDocument xmlns="urn:hl7-org:v3">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<id root="2.16.840.1.113883.3.933" extension="DOC-2026-001"/>
<code code="34133-9" displayName="Summarization of Episode Note"
codeSystem="2.16.840.1.113883.6.1"/>
<title>Patient Summary</title>
<effectiveTime value="20260606120000+0100"/>
<recordTarget>
<patientRole>
<id extension="HORVATH001" root="2.16.840.1.113883.2.9.4.3.2"/>
<patient>
<name><family>Horváth</family><given>Jana</given></name>
<administrativeGenderCode code="F"/>
<birthTime value="19790312"/>
</patient>
</patientRole>
</recordTarget>
</ClinicalDocument>Strengths: Structured clinical document with legal validity. Human-readable narrative always present — a doctor can read it without a system. Supports digital signatures.
Problems: Verbose XML — a full CDA document can be hundreds of kilobytes. No standard REST API — CDA documents are sent, not queried. Implementation is complex and specialist. CDA templates (C-CDA, HL7 CDA R2 IGs) are difficult to create and validate.
Still used today: Patient summaries in many European countries (especially Germany, Austria). Cross-border exchange in some EU eHealth services. Legacy hospital portals.
FHIR — Fast Healthcare Interoperability Resources (2019)
FHIR was designed by people who had worked with HL7 v2 and CDA and knew exactly what was wrong with both. The design principles: use existing web standards (HTTP, REST, JSON, OAuth2), make it implementable by any developer in a few days, and make the spec machine-readable with formal schemas.
Strengths: REST API — queryable, not just push. JSON by default — any developer can read it. Formal StructureDefinitions — machine-validatable profiles. SMART on FHIR for OAuth2 authorization. Growing ecosystem of tools.
Problems: Base spec is too loose without profiles. Profiling ecosystem is fragmented — many IGs, regional variations. Terminology bindings require external services (SNOMED CT, LOINC). R4 → R5 migration pressure starting.
Dominant use today: US ONC mandate (all payers must expose FHIR APIs). EHDS mandate (all EU member states must implement FHIR for cross-border exchange). New EHR implementations globally.
Comparison
| Property | HL7 v2 | CDA | FHIR R4 |
|---|---|---|---|
| Format | Pipe-delimited text | XML | JSON / XML |
| Transport | MLLP, file drop | XDS, IHE | HTTP REST |
| Query support | None | Limited (XDS) | Full REST + Search |
| Schema | Informal | XML Schema | StructureDefinition |
| Granularity | Events (ADT, ORM) | Documents | Individual resources |
| Developer onboarding | Weeks–months | Weeks–months | Days |
| Adoption | Universal legacy | EU, some US | Dominant new standard |
They coexist
HL7 v2, CDA, and FHIR are not in a winner-takes-all competition. They coexist in every large healthcare environment:
- — The lab system sends results to the EHR via HL7 v2 ADT/ORM messages (1990s integration, working fine, not worth replacing).
- — The EHR produces CDA discharge summaries that go to the national patient portal.
- — The patient-facing app queries the FHIR API to show the patient their own data.
- — The cross-border exchange (MyHealth@EU) uses FHIR IPS Patient Summary.
The integration engine translates between all three. FHIR is not replacing v2 overnight — it is the standard for new interfaces and the mandatory standard for regulatory compliance (EHDS, US ONC).