CDA Document Structure — Header and Body

CDA preserves document-ness

HL7 v2 commonly communicates events; FHIR commonly exposes resources and API interactions. The Clinical Document Architecture (CDA) represents a persistent clinical document such as a discharge summary, consultation note, operative note, or continuity-of-care document. Its root is ClinicalDocument, with a header and a body ¹.

A CDA document is designed to remain a whole, identifiable record with context, stewardship, authorship, and human-readable content. It is not merely a bag of coded observations and not simply any XML file whose tags look clinical.

The header answers who, what, and under whose authority

The header supplies context used to identify, classify, route, index, secure, and manage the document. Depending on the implementation guide, important elements include:

• document identifier, type code, title, effective time, confidentiality, and language;
• recordTarget for the patient;
• author and authoring time;
• custodian responsible for maintaining the document;
• legal authenticator or other participants where applicable;
• encounter context, service event, information recipient, and related documents;
• templateId values declaring the constraints the instance claims to follow;
• setId and versionNumber for document version lineage.

The patient in the header is not resolved safely from name alone. Identifiers, assigning roots, dates, and provenance matter. A repository should validate identity and document metadata before filing; displaying a beautiful note in the wrong chart is still a severe failure.

Context can propagate from the document to sections and entries unless explicitly overridden. The CDA core specification describes propagation for authorship, confidentiality, language, subject, and other contextual properties ¹. A parser that reads an entry in isolation can miss inherited context.

The body may be unstructured or structured

CDA permits an unstructured body for content such as a referenced or embedded document under the applicable constraints. A structured body contains sections, and sections can nest. Each section can have:

• a code and title identifying the kind of section;
• a text narrative block for human rendering;
• zero or more machine-processable entries;
• references connecting narrative items to entries or external objects.

A simplified skeleton looks like:

<ClinicalDocument>
  <!-- header: identity, type, author, custodian, encounter -->
  <component>
    <structuredBody>
      <component>
        <section>
          <code code="..." codeSystem="..."/>
          <title>Allergies</title>
          <text>Human-readable narrative...</text>
          <entry>
            <observation>...</observation>
          </entry>
        </section>
      </component>
    </structuredBody>
  </component>
</ClinicalDocument>

The actual template constrains required attributes, identifiers, codes, and relationships. Copying this skeleton does not create a conformant clinical document.

Narrative and entries serve different consumers

The narrative block is content a conformant receiver can render for a human. Coded entries support computation such as reconciliation, search, quality measurement, or decision support. CDA’s design requires a deterministic rendering path without depending on a sender-specific style sheet ¹.

Entries frequently encode clinical statements also represented in narrative, but they are not automatically equivalent. A dangerous document can contain:

• narrative that says “no known allergies” while entries list an active allergy;
• a medication dose in narrative that differs from the structured entry;
• a corrected result in narrative with an obsolete entry;
• coded content that has no visible narrative counterpart.

Creation and validation should check narrative-entry consistency under the implementation guide. A receiver should know which content is attested and rendered, which is computable, and how discrepancies are handled. Do not silently choose the convenient representation.

Templates turn broad CDA into a usable contract

Base CDA is flexible. templateId assertions indicate conformance to more specific constraints at document, section, and entry levels. In the United States, Consolidated CDA (C-CDA) provides templates for common clinical note types and header constraints. The active C-CDA 5.0.0 guide includes document types such as the Continuity of Care Document, discharge summary, consultation note, and operative note ².

Version matters. A receiving system should validate against the exact template and release it claims to support. “This is CDA” is no more complete than “this is HL7.” Record the template identifiers, guide version, validation tool version, and accepted local extensions.

Released documents are revised, not silently edited

Once a clinical document has been released for patient care, corrections require formal versioning or replacement with provenance. setId can identify the document set while versionNumber distinguishes revisions; related-document relationships can state replacement or transformation under the relevant rules.

Keep the prior document, replacement relationship, author, time, reason, and status. A file overwritten in place destroys the record of what was previously communicated. Repositories and downstream systems also need a policy for reindexing, notifications, and duplicate arrivals.

Validate on several layers

A practical CDA pipeline checks:

1. XML well-formedness: the payload can be parsed safely.
2. Schema or model constraints: elements, attributes, and datatypes are legal.
3. Template conformance: required sections, entries, cardinalities, and vocabulary bindings match the claimed guide.
4. Terminology: codes, systems, values, and units are valid for their context.
5. Narrative safety: required content renders, links resolve, and prohibited active content is not introduced.
6. Identity and provenance: patient, encounter, author, custodian, and document lineage resolve correctly.
7. Clinical reconciliation: narrative and entries are acceptably consistent.

Validation success does not prove that the content is clinically true. It proves that the instance satisfies the checked rules. Preserve errors with precise template and location information so authors can correct the source.

Rendering is a security boundary

CDA narrative is constrained XML markup, not arbitrary web content. Use a renderer built for CDA rules, escape untrusted text, control external references, and do not enable scripts or active content. Handle embedded media and external links under policy. The document can contain sensitive health information even when its transport envelope is gone, so storage, access, audit, retention, and disclosure controls still apply.

Practice: perform a two-view review

Take a sample CDA or C-CDA document. In the human view, render the title, patient, author, encounter, and each section narrative. In the machine view, list template IDs, document identifiers, version lineage, section codes, and entries. Then compare the two views for missing or contradictory facts. Finish with a test plan covering wrong patient identifier, unknown template, missing narrative, invalid code system, unresolved narrative reference, duplicate document, and formal replacement.