CDA Document Structure — Header and Body

A document, not a message

The v2 and FHIR worlds think in messages and resources — small units that fly between systems as events happen. CDA thinks in documents. The Clinical Document Architecture, Release 2, is an HL7 standard (ANSI-approved in 2005) for representing a complete clinical document — a discharge summary, an operative note, a consultation letter — as a single XML file ¹. A document has properties a message does not: it is persistent (meant to be stored and retrieved later), whole (a complete attestable unit), and authenticated (signed by a responsible author). CDA exists to move those documents between systems without losing their document-ness ².

The header: context a machine can read

Every CDA document opens with a header that establishes who and what the document is about, in structured, coded form. The header carries the patient, the author, the custodian (the organization responsible for maintaining the document), the document type, and the encounter it describes ¹. This matters because the header is what lets a repository index and route a document without parsing its prose: a system can file a discharge summary against the right patient and encounter, and find it later, purely from the header — even if it never interprets the clinical narrative.

Because CDA is derived from the HL7 v3 Reference Information Model, the header’s elements are not ad hoc fields but instances of RIM classes (acts, participations, roles, entities). That shared model is what makes one vendor’s CDA header interpretable by another’s software.

The body: sections of narrative and entries

Below the header sits the body, the clinical content itself. The body is organized into sections — Allergies, Medications, Problems, and so on — and each section contains two complementary things:

1. Narrative text — the human-readable account, which is what a clinician actually reads. CDA guarantees this text is always present and renderable.
2. Coded entries — optional machine-readable data (observations, substance administrations, problems) that restate the narrative in structured, coded form so software can process it ¹.

This dual nature is CDA’s defining design choice: the narrative is authoritative for humans and always there, while the coded entries add machine-processability on top of it rather than replacing it. A receiver that cannot process the codes can still display the document faithfully.

The “incremental semantic interoperability” idea

That layering is deliberate, and it leads directly to CDA’s notion of levels, which the next lesson examines. The short version: a CDA document can be minimally structured (a readable body with little coding) or richly coded (machine-readable entries throughout), and everything in between is valid. A document never has to be fully coded to be a legal, useful CDA — coding can be added incrementally as systems mature ².

This is the conceptual bridge from v2 to FHIR. CDA keeps the document as the unit of exchange — the thing clinicians sign and the record retains — while borrowing the RIM’s structured, coded backbone. Understanding it explains both why CDA is still everywhere in document exchange and why FHIR later re-imagined the same clinical content as small, independently addressable resources.