Short answer: CDA gives you one document: a signed XML file about one patient at one moment, with narrative a human reads and entries a computer may read, that must stay whole and unchanged. FHIR gives you resources: a Patient, forty Observations, three Conditions, each with its own URL, fetched, searched and updated independently through a REST API. FHIR can also package resources into a document (a Bundle of type document led by a Composition), which is the direct equivalent of CDA. Choose CDA where a regulation or a partner requires it; choose FHIR for APIs, apps and anything that must be queried rather than read.
The two shapes
CDA and FHIR have two different shapes. CDA exchanges whole XML documents built on HL7 v3 data types, identified by OIDs, with mandatory narrative, no querying, no updating and whole-document signing. FHIR exchanges individual JSON or XML resources or Bundles, identified by canonical URLs, with built-in REST querying, versioned updates and profiles published in implementation guides.
| CDA / C-CDA | FHIR | |
|---|---|---|
| Unit of exchange | A whole document | A resource, or a Bundle of resources |
| Format | XML, HL7 v3 data types | JSON or XML, FHIR data types |
| Identification | OIDs for templates and code systems | URLs (canonical) for profiles and code systems |
| Human-readable part | Mandatory <text> in every section |
Optional text.div narrative per resource; mandatory in documents |
| Transport | Not defined; carried by XDS, Direct, MLLP, email | REST over HTTPS defined by the standard; also messaging and documents |
| Querying | Not possible inside a document; registries index the header | Built in: GET /Observation?patient=…&code=… |
| Updating | Never; a new document replaces the old one | Resources are versioned and updated in place |
| Signing | Whole document, XML-DSig | Whole Bundle possible; individual resources rarely signed |
| Profiles | Templates (templateId) per section and entry | StructureDefinition profiles per resource, published in implementation guides |
| Terminology | LOINC section codes, SNOMED/ICD/RxNorm entries | Same code systems, as CodeableConcept |
What the difference means in practice
In practice the difference between CDA and FHIR is that CDA suits content written once and preserved whole, such as a signed discharge summary, while FHIR suits data that grows and is queried, such as a blood pressure series. A CDA receiver can display but must reconcile to import; a FHIR receiver gets resources already shaped like its own record.
A discharge summary is naturally a document: it is written once, signed by one doctor, and must be reproducible years later exactly as it was read. A blood pressure series is naturally a set of resources: it grows every day, is plotted and filtered, and nobody signs it. CDA handles the first well and the second badly (you would re-send the whole document for each new reading). FHIR handles the second natively and the first through its document mechanism.
The other practical difference is what the receiver can do. A CDA receiver can always display the document; importing its entries requires reconciliation, section by section. A FHIR receiver gets resources that are already in the shape of its own record; the hard questions move to identity (is this the same patient?) and provenance (who asserted this and when?). See Patient matching.
FHIR documents: the meeting point
A FHIR document is a Bundle with type: "document" whose first entry is a Composition. The Composition plays the role of the CDA header and section list: type (LOINC), date, author, subject, custodian, status, and section[] with a title, a code, narrative text and references to the resources that carry the data.
{
"resourceType": "Bundle",
"type": "document",
"identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
"timestamp": "2026-03-14T10:15:00+01:00",
"entry": [
{"fullUrl": "urn:uuid:comp-1", "resource": {
"resourceType": "Composition", "status": "final",
"type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
"subject": {"reference": "urn:uuid:pat-1"},
"date": "2026-03-14T10:15:00+01:00",
"author": [{"reference": "urn:uuid:prac-1"}],
"title": "Patient summary",
"section": [{
"title": "Allergies and intolerances",
"code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
"text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
"entry": [{"reference": "urn:uuid:allergy-1"}]
}]
}},
{"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
{"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
{"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
]
}
The International Patient Summary is exactly this: a FHIR document profile, with a CDA twin for systems that still need it. See also FHIR Bundle explained.
Converting between them
Converting between CDA and FHIR works in both directions with limits. The HL7 C-CDA on FHIR implementation guide maps document types, sections and entries to Composition profiles and resources; narrative-only sections become text without data. FHIR to CDA works for resources that fit C-CDA templates. In either direction, the original should be kept as a DocumentReference with Provenance.
- CDA → FHIR: the HL7 C-CDA on FHIR implementation guide maps the US document types and sections to Composition profiles; entries map to resources (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). The mapping is deterministic for well-templated Level 3 content and lossy for narrative-only sections, which become text without data.
- FHIR → CDA: possible for documents whose resources fit the C-CDA templates. Free-form FHIR resources that were never meant as a document (a stream of wearable Observations) do not become a sensible CDA.
- Keep the original. Whichever direction you convert, store the source as it was received, as a DocumentReference, and let Provenance point from the converted resources to it. Conversion is a view, not a replacement.
When CDA is still the right answer
CDA is still the right answer when the receiving party requires it (US transitions of care, MyHealth@EU patient summary and ePrescription, several national document registries), when the content is legally a document that must be signed and preserved whole, or when the partner's infrastructure is IHE XDS, which indexes documents rather than resources. Otherwise, start with FHIR.
When the receiving party requires it (US transitions of care, MyHealth@EU patient summary and ePrescription today, several national document registries); when the content is legally a document that must be signed and preserved whole; when the partner's infrastructure is IHE XDS, which indexes documents and not resources. In every other case, start with FHIR and produce a FHIR document where a document is needed.
Related pages
- CDA and C-CDA explained
- FHIR Bundle explained
- The International Patient Summary
- HL7 vs FHIR
- DocumentReference vs DiagnosticReport vs Binary
- Patient matching
Sources
- HL7 FHIR R4: Documents
- HL7 FHIR R4: Composition
- HL7 C-CDA on FHIR implementation guide
- HL7 FHIR: comparison with CDA (Appendix)
- HL7 International Patient Summary IG
Frequently asked questions
Is a FHIR document just CDA in JSON?
No. It shares the principles (whole, signed, human-readable, with a header) but its content is ordinary FHIR resources, so the same Observation can live in a document and be served by the API. In CDA, an entry exists only inside its document.
Can I sign a FHIR document?
Yes. Bundle.signature holds a digital signature over the bundle, and the IPS and national guides describe how. In practice many deployments rely on transport security and provenance rather than signatures.
Does FHIR have templateId?
The equivalent is meta.profile, a list of canonical URLs of the StructureDefinitions the resource claims to conform to. Validators check conformance the way CDA schematrons check templates.
Which should a new national programme choose?
Recent programmes (the EHDS exchange format, US patient access rules, the IPS) choose FHIR, with FHIR documents for summaries and letters, and keep a CDA path only for legacy partners.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
