Short answer: the Clinical Document Architecture (CDA) is HL7's standard for clinical documents: discharge summaries, referral letters, consultation notes, patient summaries. A CDA document is one XML file with a header (who, when, about whom) and a body of sections, each with human-readable narrative and, optionally, machine-readable coded entries. C-CDA (Consolidated CDA) is the US implementation guide that fixes the templates for the most common document types; the CCD (Continuity of Care Document) is its best-known member. CDA Release 2 dates from 2005 and is still mandated in several national and cross-border programmes.
What a document looks like
A CDA document is an XML file with a ClinicalDocument root containing a header (the document type as a LOINC code, templateId OIDs, an id, effective time, confidentiality code, patient, author and custodian) and a body of sections, each with a LOINC code, a mandatory human-readable text element and optional coded entries for software to read.
<ClinicalDocument xmlns="urn:hl7-org:v3">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="2.16.840.1.113883.10.20.22.1.2" extension="2015-08-01"/>
<id root="2.16.840.1.113883.19.5" extension="DOC-2026-0314"/>
<code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of Episode Note"/>
<effectiveTime value="20260314101500+0100"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<recordTarget><patientRole>…</patientRole></recordTarget>
<author>…</author>
<custodian>…</custodian>
<component><structuredBody>
<component><section>
<templateId root="2.16.840.1.113883.10.20.22.2.6.1" extension="2015-08-01"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies</title>
<text><table><tr><td>Penicillin</td><td>Rash</td></tr></table></text>
<entry>…coded Allergy Concern Act…</entry>
</section></component>
</structuredBody></component>
</ClinicalDocument>
Three things to notice. The document type and every section are identified by a LOINC code (34133-9, 48765-2). Templates are identified by OIDs (2.16.840.1…), not URLs. The <text> element is mandatory and is what a clinician sees; the <entry> is optional and is what software reads.
The three levels
CDA defines three levels of structure. Level 1 is a valid header with an unstructured body such as an embedded PDF. Level 2 adds a structured body with coded sections and narrative but no coded entries. Level 3 adds coded entries following templates, so software can import allergies, medications and problems. Most real documents sit between levels 2 and 3.
- Level 1: a valid header plus an unstructured body, for example an embedded PDF. Legally a CDA document; computers can file it but not read it.
- Level 2: structured body with coded sections and narrative, no coded entries. Software knows there is an allergy section; it cannot list the allergies.
- Level 3: sections with coded entries following templates. Software can import the allergies, medications and problems into the receiving record.
Most real-world CDA sits between levels 2 and 3: some sections coded, others narrative only.
Six principles that still shape it
The six principles behind CDA are persistence (a document lives unchanged for years), stewardship (a custodian is responsible for it), potential for authentication (it can be signed), context (the header applies to the whole document), wholeness (a section loses meaning outside its document) and human readability (the narrative renders without special software). FHIR documents adopt the same six principles.
CDA was designed around persistence (a document lives unchanged for years), stewardship (a custodian is responsible for it), potential for authentication (it can be signed), context (the header applies to the whole document), wholeness (a section out of its document loses meaning) and human readability (the narrative must render without special software). FHIR documents (a Bundle of type document with a Composition) adopt the same principles; the data model underneath is different, as CDA vs FHIR explains.
C-CDA: the US consolidation
C-CDA (Consolidated CDA) is the US implementation guide that, from 2011, merged several overlapping CDA guides into one, with about a dozen document templates such as the Continuity of Care Document, Discharge Summary and Referral Note, and a shared library of section and entry templates. C-CDA R2.1 is required by ONC certification for transitions of care and patient summaries.
Before 2011, US implementers used several overlapping CDA guides. Consolidated CDA merged them into one, with about a dozen document templates (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report and others) and a shared library of section and entry templates. C-CDA R2.1 is required by US EHR certification (ONC) for transitions of care and patient summaries, and remains so alongside FHIR US Core for APIs.
Where CDA lives in 2026
In 2026 CDA lives in US provider-to-provider exchange as C-CDA through Direct messaging and health information exchanges, in Europe's cross-border MyHealth@EU Patient Summary and ePrescription, in national programmes such as Germany's eArztbrief and ePA, Austria's ELGA, Italy's FSE, the Netherlands and Switzerland, and everywhere as a header wrapped around scanned or PDF documents.
- United States: C-CDA for document exchange between providers, in Direct messaging and health information exchanges.
- Europe, cross-border: MyHealth@EU exchanges the Patient Summary and the ePrescription as CDA documents (the eHDSI templates), with FHIR-based formats arriving under the EHDS. See ePrescription across EU borders.
- National programmes: Germany's electronic doctor's letter (eArztbrief) and parts of the ePA, Austria's ELGA documents, Italy's FSE, the Netherlands and Switzerland use CDA for documents, often through IHE XDS registries.
- Everywhere: scanned and PDF documents wrapped in a CDA header, so that a document registry can index them.
What a receiver actually gets
A receiver of a CDA document always gets a readable narrative, but coded data it can import only when the sender used Level 3 templates consistently. Receiving systems typically display the narrative and offer to reconcile problems, medications and allergies from the entries one by one, because two Level 3 documents from different vendors rarely code the same fact identically.
A CDA document is reliable for reading and uneven for importing. The narrative is always there; the coded entries depend on the sender's level and template discipline. Receiving systems usually show the narrative to the clinician and offer to "reconcile" problems, medications and allergies from the entries into the local record, one by one. That reconciliation step exists because two Level 3 documents from different vendors rarely code the same fact the same way.
In Anpheros, a CDA document from a hospital is stored as it is, as a DocumentReference with the XML attached, and its coded content, where present, is mapped into FHIR resources (Condition, AllergyIntolerance, MedicationStatement) with provenance pointing back to the document. See DocumentReference vs DiagnosticReport vs Binary.
Related pages
- CDA vs FHIR
- HL7 vs FHIR: v2, CDA and FHIR
- FHIR Bundle explained
- DocumentReference vs DiagnosticReport vs Binary
- The International Patient Summary
- Healthcare interoperability standards: the map
- TEFCA and QHINs explained
Sources
- HL7 CDA Release 2 product brief
- HL7 C-CDA R2.1 product brief
- HL7 C-CDA online navigation (templates)
- ONC Certification: C-CDA requirements
- MyHealth@EU (European Commission)
Frequently asked questions
Is CDA the same as HL7 v3?
CDA is built on the HL7 v3 Reference Information Model and uses v3 data types, which is why its XML looks the way it does. The rest of HL7 v3 messaging saw little adoption; CDA is the part of v3 that succeeded.
What is a CCD?
The Continuity of Care Document is the C-CDA document type for a patient summary: problems, medications, allergies, immunizations, results, procedures, vital signs, plan of care. It is the US equivalent of the International Patient Summary.
Is CDA being replaced by FHIR?
For new APIs and apps, yes; for document exchange between institutions, slowly. Regulations in the US and Europe still require CDA for specific documents, and FHIR documents are being introduced alongside rather than instead.
Can a CDA document be converted to FHIR?
Yes, with limits. The HL7 C-CDA on FHIR implementation guide maps document types and sections; coded entries map to FHIR resources where the templates match. Narrative-only sections become Composition sections with text and no structured data.
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
