Levels of CDA and the C-CDA Templates

Three levels of one document

The previous lesson described a CDA document as a machine-readable header plus a body of sections, where each section holds narrative text and optional coded entries. That phrase optional coded entries is the key to CDA’s most practical idea: a document can carry as much or as little machine-readable structure as a sender can produce. CDA names three levels to describe how far the body has been coded, and — this is the part that surprises newcomers — all three are perfectly valid CDA ¹.

Level 1 is the floor. The header is fully structured and coded, but the body is essentially unstructured: a block of narrative, or even a wrapped PDF, scanned image, or other blob. A Level 1 document is still a legal CDA because the header gives a repository everything it needs to file, index, and retrieve it — the body just is not machine-interpretable beyond “here is the text” ².

Level 2 adds structure at the section level. The body is divided into sections, and each section carries a code identifying its type — a section tagged as “Medications,” another as “Allergies,” another as “Problems.” A receiving system cannot necessarily read the individual medications as data, but it can reliably find the medications section and show it, sort it, or route it. Coding the sections makes the document navigable by machine ².

Level 3 pushes coding down into the entries within each section. Now the individual clinical statements — an observation, a problem, a single medication — are expressed as structured, coded entries that software can extract and act on: a specific drug with a coded ingredient, dose, and route, rather than a sentence about it ². A Level 3 medications section lets a system compute against the data (check interactions, reconcile lists), not merely display it.

The levels are cumulative and incremental. A sender does not have to jump to Level 3 to be conformant; it can publish readable Level 1 or Level 2 documents today and add coded entries later as its systems mature, without changing the document model. This “add machine-readability over time” stance is exactly the incremental-interoperability philosophy CDA was built around ¹.

Templates: constraints that make documents predictable

Saying a document is “Level 3” still does not tell a receiver which entries to expect or how they are shaped. That precision comes from templates. A template is a named set of additional constraints layered on top of base CDA for a specific document, section, or entry type, and it is identified by a templateId ². A template might say, in effect, “a Medications section conforming to this template must contain substance-administration entries, each with a coded medication and a dose.”

This is directly analogous to the v2 world’s message profiles: just as a profile constrains a general v2 message into a predictable, agreed-upon shape for a particular use, a template constrains general CDA into a predictable shape for a particular kind of clinical content. When a document declares conformance to a templateId, a receiver knows what is inside and how to process it — turning flexible CDA into something interoperable in practice, not just in theory.

C-CDA: a consolidated US template library

Templates only help if everyone uses the same ones. In the United States, that shared set is Consolidated CDA (C-CDA), a US-realm implementation guide developed by HL7 that harmonizes CDA templates for common clinical notes ³. Before C-CDA, several overlapping CDA guides existed, and the same clinical idea could be templated in incompatible ways. Beginning in 2011, work under the ONC Standards & Interoperability (S&I) Framework consolidated those earlier guides into one definitive, reconciled library ³.

C-CDA is organized exactly along CDA’s structure. It defines document templates — for example, the Continuity of Care Document (CCD) and the Discharge Summary — and the section and entry templates those documents reuse ³. Because a CCD and a Discharge Summary both need a Medications section, they cite the same section template rather than reinventing it; templates are shared building blocks, which is what “consolidated” means in the name.

The payoff was concrete. C-CDA became the backbone for US clinical document exchange under federal programs: it was named in the Meaningful Use EHR certification criteria, and it remains the document format for exchanging the data classes defined by the United States Core Data for Interoperability (USCDI) ³. By giving vendors one agreed library of templateIds, C-CDA turned CDA’s flexibility into the kind of predictability that lets one hospital’s system actually consume another’s summary of care.

Where this leaves you

The levels explain how much of a document is machine-readable; templates and C-CDA explain exactly what that machine-readable content looks like for a given purpose. Together they are why CDA scaled into nationwide document exchange — and they set up the contrast with FHIR, which later re-expressed the same clinical content as small, independently addressable resources rather than whole documents.