HL7 CDA and C-CDA
The document standard between v2 messages and FHIR resources: an XML clinical document that is both human-readable and machine-processable — and the compromise at its heart is the whole lesson.
In one line
CDA (Clinical Document Architecture) is an XML standard for a clinical document — a discharge summary, a referral — designed so that the same file is readable by a human and processable by a machine. C-CDA is the consolidated set of templates that made it practically implementable in the US.
Document, not message
The mental model matters more than the syntax. Compare the three eras:
- HL7 v2 — a message: "this event just happened." A patient was admitted. A result is ready. Transient, event-driven.
- CDA — a document: "here is a complete, attested, signed account." A discharge summary has an author, a date, a legal standing, and it doesn't change. Like a PDF, but structured.
- FHIR — a resource: "here is a thing you can query." Granular, API-shaped.
The document is a genuinely distinct concept, and it survives because clinical practice runs
on documents. A discharge summary is not a data feed; it is an accountable statement by a named
clinician at a moment in time. That is a legal artefact as much as a clinical one, and FHIR
eventually had to grow Composition and DocumentReference to say the same thing.
The compromise at its heart
CDA's defining design decision — and the source of both its success and its disappointment — is that every document carries two representations of the same content:
- A narrative block — the text a clinician actually reads, and the legally attested content.
- Structured entries — coded, machine-processable data alongside it.
The idea was elegant: humans read the narrative, machines read the entries, and they say the same thing.
The reality is the lesson. Nothing forces them to agree. Many real CDA documents have a rich narrative and thin, minimal, or subtly divergent entries — because the narrative is what gets clinically reviewed and the entries are what get generated. When the two disagree, which one is true? The narrative is the attested one. So the machine-readable half — the entire point — is the half nobody guarantees.
That's the general principle worth taking beyond CDA: when a format lets you say the same thing twice, it has created a way for you to contradict yourself.
C-CDA and why it exists
Base CDA is a framework, not an implementable spec — so open that two conformant documents could share nothing useful. Sound familiar? It's the same failure as plain FHIR without profiles.
C-CDA fixed it the same way: by taking freedom away. It consolidated templates into a defined set of document types — Continuity of Care Document, Discharge Summary, Referral Note, Progress Note — with required sections and bound vocabularies. C-CDA became the backbone of US health information exchange, largely because Meaningful Use required it.
Where you'll meet it
Still very much alive, particularly in the US: C-CDA is what moves between hospitals through health information exchanges, what patients get from a portal, and what IHE profiles shuttle around in XDS document repositories.
FHIR has not displaced it. As with X12, the honest picture is coexistence: new APIs are FHIR, established document exchange is C-CDA, and converting between them is real, ongoing work — with predictable information loss in both directions, which is why your ConceptMap equivalences matter.
The practical warning
C-CDA documents are large, deeply nested XML, and the same clinical fact can legitimately live in several places. Two conformant documents from two vendors can look nothing alike. If you're parsing them, expect to write far more defensive code than the spec suggests — and expect the narrative to contain things the entries never mention.