C-CDA Healthcare Guide: Clinical Document Architecture

C-CDA (Consolidated Clinical Document Architecture) is the HL7 standard for exchanging structured clinical documents between healthcare systems. When a patient is discharged from a hospital, referred to a specialist, or transitions between care settings, C-CDA is the format that carries their clinical summary. It is the backbone of document-based health information exchange in the United States, mandated by ONC for certified EHR technology and used by every major health information exchange network.

Despite its importance, C-CDA is often confused with related standards like CCD and CCR, and many healthcare IT professionals encounter it without fully understanding its structure. This guide covers what C-CDA is, how it works, what document types it defines, how its XML structure is organized, and when to use C-CDA versus FHIR for clinical data exchange.

What Is C-CDA?

C-CDA stands for Consolidated Clinical Document Architecture. It is a set of document templates built on top of HL7 CDA (Clinical Document Architecture) Release 2. CDA itself is an XML-based standard for representing clinical documents — discharge summaries, progress notes, referral letters, and other narrative documents that clinicians produce during patient care.

The “Consolidated” in C-CDA refers to the fact that it merges multiple earlier implementation guides into a single, unified specification. Before C-CDA, there were separate implementation guides from HL7, IHE (Integrating the Healthcare Enterprise), and HITSP (Health Information Technology Standards Panel), each defining slightly different templates for the same document types. C-CDA consolidated these into one authoritative guide, eliminating ambiguity and reducing implementation variability.

C-CDA was first published in 2011 as part of the Meaningful Use program. C-CDA 2.1 was published in 2015 and is the version most widely deployed and historically required by ONC certification criteria. HL7 has since published C-CDA R3.0, and C-CDA 4.0.0 is the most recent published version of the implementation guide. The current ONC certification criteria still reference earlier versions for production use; check the latest ONC guidance for which C-CDA version applies to a given certification path before standardizing on it.

Key Characteristics of C-CDA

• XML-based: All C-CDA documents are valid XML conforming to the CDA R2 schema.
• Human-readable and machine-readable: Every C-CDA document contains a narrative section (rendered HTML) and structured entries (coded data elements). A clinician can read the narrative; a system can parse the entries.
• Template-driven: Document structure is defined by templates, each identified by a unique OID (Object Identifier). Templates constrain what sections and entries a document must, should, or may contain.
• Vocabulary-bound: C-CDA requires specific code systems — SNOMED CT for problems, RxNorm for medications, LOINC for lab results and document sections, ICD-10-CM for diagnoses.

C-CDA vs CCD vs CCR: Clarifying the Terminology

These three acronyms are frequently confused. Here is what each means and how they relate.

CCD (Continuity of Care Document)

The CCD is a specific document type within C-CDA. It is a clinical summary document that contains a patient’s active problems, medications, allergies, immunizations, procedures, and other relevant clinical information. The CCD is designed for care transitions — when a patient moves from one provider to another, the sending system generates a CCD that gives the receiving provider a snapshot of the patient’s current clinical state.

The CCD is the most commonly exchanged C-CDA document type. When people say “we send C-CDAs,” they usually mean they send CCDs.

CCR (Continuity of Care Record)

The CCR is a separate standard developed by ASTM International (ASTM E2369). It predates C-CDA and uses a simpler XML schema that is not based on CDA. The CCR was designed with the same goal as the CCD — providing a clinical summary for care transitions — but it uses a different structure and different vocabularies.

The CCD was explicitly designed to bridge the gap between HL7 CDA and ASTM CCR. It carries the same data elements as a CCR but uses the CDA R2 XML structure. In practice, CCR adoption declined after CCD became the Meaningful Use standard. Most systems today produce CCDs, not CCRs.

How They Relate

Think of it this way: CDA R2 is the foundation. C-CDA is the implementation guide that constrains CDA R2 for US healthcare. CCD is one specific document type defined by C-CDA.

C-CDA Document Types

C-CDA defines 12 document-level templates. Each corresponds to a different clinical scenario. The four most commonly implemented:

Continuity of Care Document (CCD)

Template ID: 2.16.840.1.113883.10.20.22.1.2

The CCD is a patient summary document for care transitions. It contains the patient’s active problems, medications, allergies, immunizations, vital signs, procedures, results, social history, and functional status. It is the “passport” document that travels with the patient between care settings.

Required sections (C-CDA R2.1 §3.1, conformance SHALL): Allergies, Medications, Problem List, Results. The Procedures section is SHOULD (cardinality 0..1), strongly recommended but not strictly required.

Discharge Summary

Template ID: 2.16.840.1.113883.10.20.22.1.8

Generated when a patient is discharged from an inpatient stay. Contains the admission diagnosis, hospital course, discharge diagnosis, discharge medications, discharge instructions, and follow-up plan. This document is critical for post-acute care coordination and reducing readmissions.

Required sections: Allergies, Hospital Discharge Diagnosis, Hospital Course, Plan of Treatment, Discharge Medications.

Referral Note

Template ID: 2.16.840.1.113883.10.20.22.1.14

Sent when a provider refers a patient to a specialist or another provider. Contains the reason for referral, relevant history, current medications, allergies, and pertinent results. The referral note replaces the traditional paper referral letter.

Required sections: Allergies, Medications, Problem List, Reason for Referral, Results.

Progress Note

Template ID: 2.16.840.1.113883.10.20.22.1.9

Documents a single clinical encounter — an office visit, a follow-up, or a check-in. Contains the chief complaint, assessment, plan, and relevant findings from the visit.

Required sections: Assessment and Plan (or Assessment, Plan of Treatment).

Other Document Types

C-CDA XML Structure

Every C-CDA document follows the CDA R2 XML structure. Understanding this structure is essential for building, parsing, or validating C-CDA documents.

Document-Level Structure

A C-CDA document has two main parts: the header and the body. The body contains sections, and each section carries a human-readable narrative plus machine-readable entries — that dual-layer design is what makes CDA documents universally displayable yet computable.

<?xml version="1.0" encoding="UTF-8"?>
<ClinicalDocument xmlns="urn:hl7-org:v3"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <!-- ===== HEADER ===== -->
  <realmCode code="US"/>
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

  <!-- US Realm Header (general C-CDA US realm header) -->
  <templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2015-08-01"/>
  <!-- CCD document template (this declares the doc as a CCD) -->
  <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.99999.1" extension="DOC-001"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1"
        displayName="Summarization of Episode Note"/>
  <title>Continuity of Care Document</title>
  <effectiveTime value="20260327120000-0400"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>

  <!-- Patient -->
  <recordTarget>
    <patientRole>
      <id root="2.16.840.1.113883.19.5" extension="MRN123456"/>
      <addr use="HP">
        <streetAddressLine>123 Main St</streetAddressLine>
        <city>West Palm Beach</city>
        <state>FL</state>
        <postalCode>33401</postalCode>
      </addr>
      <patient>
        <name use="L">
          <given>John</given>
          <family>Doe</family>
        </name>
        <administrativeGenderCode code="M"
          codeSystem="2.16.840.1.113883.5.1"/>
        <birthTime value="19800115"/>
      </patient>
    </patientRole>
  </recordTarget>

  <!-- Author (documenting clinician) -->
  <author>
    <time value="20260327120000-0400"/>
    <assignedAuthor>
      <id root="2.16.840.1.113883.4.6" extension="1234567890"/>
      <assignedPerson>
        <name><given>James</given><family>Smith</family></name>
      </assignedPerson>
    </assignedAuthor>
  </author>

  <!-- Custodian (organization responsible for the document) -->
  <custodian>
    <assignedCustodian>
      <representedCustodianOrganization>
        <id root="2.16.840.1.113883.19.5"/>
        <name>General Hospital</name>
      </representedCustodianOrganization>
    </assignedCustodian>
  </custodian>

  <!-- ===== BODY ===== -->
  <component>
    <structuredBody>
      <!-- Sections go here -->
    </structuredBody>
  </component>

</ClinicalDocument>

Header Elements

The header contains metadata about the document and the patient:

• templateId: Identifies which C-CDA document type this is. A CCD has two template IDs — one for the general US header and one for the CCD specifically.
• code: The LOINC code identifying the document type. 34133-9 is “Summarization of Episode Note” (used for CCDs).
• recordTarget: The patient the document is about, including demographics and identifiers.
• author: The clinician or system that created the document.
• custodian: The organization responsible for maintaining the document.
• documentationOf: The encounter or event the document describes.

Section Structure

The body of a C-CDA document is organized into sections. Each section represents a clinical domain — problems, medications, allergies, results, and so on. Each section has a LOINC code, a human-readable narrative, and optionally machine-readable entries.

<component>
  <section>
    <!-- Section template ID (Allergies 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 Document"/>
    <title>Allergies</title>

    <!-- Human-readable narrative (REQUIRED) -->
    <text>
      <table>
        <thead><tr><th>Substance</th><th>Reaction</th><th>Severity</th></tr></thead>
        <tbody>
          <tr>
            <td>Penicillin</td>
            <td>Hives</td>
            <td>Moderate</td>
          </tr>
        </tbody>
      </table>
    </text>

    <!-- Machine-readable entries -->
    <entry typeCode="DRIV">
      <act classCode="ACT" moodCode="EVN">
        <templateId root="2.16.840.1.113883.10.20.22.4.30"
                    extension="2015-08-01"/>
        <code code="CONC" codeSystem="2.16.840.1.113883.5.6"/>
        <statusCode code="active"/>
        <entryRelationship typeCode="SUBJ">
          <observation classCode="OBS" moodCode="EVN">
            <templateId root="2.16.840.1.113883.10.20.22.4.7"
                        extension="2014-06-09"/>
            <code code="ASSERTION"
                  codeSystem="2.16.840.1.113883.5.4"/>
            <statusCode code="completed"/>
            <value xsi:type="CD"
                   code="419199007"
                   codeSystem="2.16.840.1.113883.6.96"
                   displayName="Allergy to substance"/>
            <participant typeCode="CSM">
              <participantRole classCode="MANU">
                <playingEntity classCode="MMAT">
                  <code code="7980"
                        codeSystem="2.16.840.1.113883.6.88"
                        displayName="Penicillin G"/>
                </playingEntity>
              </participantRole>
            </participant>
          </observation>
        </entryRelationship>
      </act>
    </entry>
  </section>
</component>

This dual-layer approach — narrative plus entries — is a defining feature of CDA. The narrative ensures that any system can display the document, even if it cannot parse the structured entries. The entries enable computable processing, decision support, and data extraction.

C-CDA Templates and templateId

Templates are the mechanism that makes C-CDA work. A template is a set of constraints on the CDA R2 schema that define what elements are required, optional, or prohibited for a specific clinical concept. Every template has a unique OID (Object Identifier) called a templateId.

Template Hierarchy

C-CDA templates are organized in a four-level hierarchy. Each level constrains what the level below it can contain — so a Document template determines which Section templates are valid, which in turn determine which Entry templates can appear inside each section.

The four levels:

1. Document-level templates: Constrain the overall document structure (CCD, Discharge Summary, Referral Note).
2. Section-level templates: Constrain individual sections within the document (Allergies Section, Medications Section, Problem Section).
3. Entry-level templates: Constrain the clinical entries within a section (Allergy Concern Act, Medication Activity, Problem Observation).
4. Subentry-level templates: Constrain elements within entries (Severity Observation, Reaction Observation).

How templateId Works

When a C-CDA validator encounters a templateId element, it looks up the corresponding template and checks that all constraints are satisfied. For example, the Allergy Concern Act template (2.16.840.1.113883.10.20.22.4.30) requires:

• A code element with code="CONC" from ActClass
• A statusCode element (active, completed, or resolved)
• At least one entryRelationship containing an Allergy-Intolerance Observation

If any required element is missing or any prohibited element is present, the document fails validation.

Template Versioning

Templates include an extension attribute that indicates the version:

<!-- C-CDA R2.1 (2015 edition) -->
<templateId root="2.16.840.1.113883.10.20.22.4.7"
            extension="2014-06-09"/>

<!-- C-CDA R1.1 (original, no extension) -->
<templateId root="2.16.840.1.113883.10.20.22.4.7"/>

The presence of the extension attribute distinguishes C-CDA R2.1 templates from the original R1.1 templates. Systems should include both the versioned and unversioned templateId for backward compatibility.

C-CDA in ONC and CMS Regulations

C-CDA is deeply embedded in US healthcare regulation. Understanding the regulatory context helps explain why C-CDA is required and where it fits in the broader interoperability landscape.

Meaningful Use / Promoting Interoperability

The Meaningful Use program (now Promoting Interoperability) established C-CDA as the standard format for clinical document exchange. Certified EHR systems must be able to generate and consume C-CDA documents for care transitions, patient summaries, and clinical information reconciliation.

ONC Certification Criteria

The ONC Health IT Certification Program requires certified EHR modules to support C-CDA for several certification criteria:

• Transitions of Care (§170.315(b)(1)): Create, receive, display, and incorporate C-CDA documents.
• Clinical Information Reconciliation (§170.315(b)(2)): Reconcile medications, allergies, and problems from received C-CDA documents.
• Electronic Prescribing (§170.315(b)(3)): C-CDA content for medication reconciliation.

USCDI and C-CDA

The United States Core Data for Interoperability (USCDI) defines the minimum data elements that must be exchangeable. USCDI v1 through v4 progressively expand the required data classes, with v5 currently in draft. C-CDA templates are updated to support new USCDI data elements — USCDI v1 included Sexual Orientation and Gender Identity (SOGI) demographics; v2 expanded Clinical Notes and added Encounter Information; v3 added Health Insurance Information and refined SOGI; v4 refined Care Team Member structures. Each USCDI release maps to corresponding C-CDA Companion Guide updates (currently Companion Guide Release 4.1 for the certification period beginning January 1, 2026).

Health Information Exchange

Health Information Exchanges (HIEs) use C-CDA as their primary document format. When a patient visits an emergency department and the clinician queries the local HIE for the patient’s records, the response is typically one or more C-CDA documents (usually CCDs) from the patient’s other providers. Carequality and CommonWell Health Alliance, the two major national HIE networks, both use C-CDA for document exchange.

C-CDA vs FHIR: When to Use Each

C-CDA and FHIR are both HL7 standards for healthcare data exchange, but they serve different purposes and work in fundamentally different ways.

Architectural Differences

When C-CDA Is the Right Choice

Care transitions and referrals. When a patient moves between providers and the receiving clinician needs a comprehensive summary, a C-CDA document (specifically a CCD or Referral Note) is the standard mechanism. The document format ensures that the clinician gets a complete, coherent narrative — not a collection of disconnected data elements.

Health information exchange queries. HIE networks are built on document exchange. Carequality, CommonWell, eHealth Exchange, and state HIEs all use C-CDA as their primary response format. If your system participates in an HIE, you need C-CDA support.

Regulatory compliance for EHR certification. ONC certification criteria explicitly require C-CDA for transitions of care and clinical information reconciliation. Meeting these criteria requires C-CDA generation and consumption.

Clinical documentation. Discharge summaries, operative notes, and consultation notes are inherently document-like. The CDA model of sections with narrative and entries maps naturally to clinical documentation workflows.

When FHIR Is the Right Choice

Patient-facing applications. FHIR’s REST API model, combined with SMART on FHIR authentication, is designed for patient portals and mobile health apps. The 21st Century Cures Act requires FHIR-based patient access APIs.

Real-time data queries. When an application needs to look up a patient’s current medications or latest lab results on demand, a FHIR API call is far more efficient than requesting, parsing, and extracting data from a full C-CDA document.

Third-party application integration. The SMART on FHIR app ecosystem enables third-party applications to integrate with EHRs through standardized FHIR APIs. This is not possible with C-CDA alone.

Bulk data and population health. FHIR’s $export operation enables efficient extraction of population-level data. C-CDA is designed for individual patient documents, not bulk extraction.

Coexistence in Practice

Most healthcare organizations need both C-CDA and FHIR. C-CDA remains the standard for document exchange, care transitions, and HIE participation. FHIR is the standard for APIs, patient access, and modern application development. Integration engines like Mirth Connect bridge the two by transforming between formats — extracting FHIR resources from C-CDA documents and assembling C-CDA documents from FHIR resources.

The HL7 FHIR standard includes an International Patient Summary implementation guide that serves a similar purpose to the CCD but uses FHIR resources instead of CDA XML. Over time, FHIR-based document exchange may supplement or replace C-CDA in some workflows, but this transition will take years given the installed base of C-CDA-producing systems.

Implementation Guide: Working with C-CDA

Building C-CDA support means handling both directions: producing documents from your internal data model, and consuming documents your partners send you. The two paths share infrastructure (XML libraries, template registries, vocabulary maps) but have different failure modes.

Generating C-CDA Documents

When building a system that produces C-CDA documents, follow these steps:

1. Choose the right document type. Match the clinical scenario to the appropriate C-CDA template. Discharge? Use the Discharge Summary template. Referral? Use the Referral Note template. Generic summary? Use the CCD template.

2. Map your data to C-CDA sections and entries. Identify which sections are required for your chosen document type. Map your internal data model to the corresponding entry templates. Use the required vocabulary standards — SNOMED CT for problems, RxNorm for medications, LOINC for lab results.

3. Generate the narrative. Every section must include a human-readable narrative in the <text> element. This narrative must accurately represent the structured entries. Many implementations generate the narrative automatically from the entry data, but it can also be authored separately.

4. Include templateIds at every level. Every document, section, entry, and subentry must include its templateId. Omitting templateIds will cause validation failures and may prevent receiving systems from processing the document correctly.

5. Validate before sending. Run your documents through a C-CDA validator before sending them to production partners.

Parsing C-CDA Documents

When consuming C-CDA documents:

1. Parse the XML. Use a standard XML parser. C-CDA documents can be large (100KB to several MB), so use a streaming parser if performance is a concern.

2. Identify the document type. Check the document-level templateId to determine what type of document you have received.

3. Extract sections by LOINC code. Each section has a LOINC code in its <code> element. Use these codes to find specific sections — 48765-2 for allergies, 10160-0 for medications, 11450-4 for problems.

4. Process entries for structured data. Within each section, parse the entries to extract coded, structured data elements. This is where the clinical value lives — discrete medications, coded diagnoses, and quantitative lab results.

5. Fall back to narrative. If a section lacks structured entries (which is valid in C-CDA), display the narrative text to the clinician. Some sections may only contain narrative, especially in documents from older or less capable systems.

Common Implementation Pitfalls

• Ignoring nullFlavor. C-CDA uses nullFlavor attributes to indicate missing or unknown data. A problem observation with nullFlavor="NI" (no information) is different from a missing problem observation. Handle nullFlavors explicitly.
• Hardcoding OIDs. C-CDA uses numerous OIDs for code systems, template identifiers, and identifiers. Maintain a lookup table rather than hardcoding OIDs throughout your code.
• Neglecting the narrative. Some implementations generate structured entries but produce poor-quality narratives. The narrative is what clinicians actually read. Invest in generating clear, accurate narratives.
• Assuming all CCDs are identical. C-CDA allows significant optionality. Two CCDs from different EHR vendors may structure the same data differently, use different optional sections, and vary in the level of coding detail. Build your parser to handle this variability.

C-CDA Validation Tools

Validating C-CDA documents is essential for ensuring interoperability. Invalid documents may be rejected by receiving systems or, worse, may be accepted but misinterpreted.

ONC SITE C-CDA Validator

The ONC Standards Implementation and Testing Environment (SITE) provides an online C-CDA validator at site.healthit.gov. This is the reference validator for ONC certification testing. It checks:

• XML schema compliance
• Template conformance (required elements, cardinality, vocabulary)
• USCDI content requirements
• Vocabulary validation (SNOMED CT, RxNorm, LOINC, ICD-10-CM)

HL7 CDA Validator (Lantana Consulting Group)

Lantana, the organization that develops and maintains the C-CDA implementation guide, provides validation tools and schematron files. The schematron rules encode the template constraints as executable validation rules that can be run against any CDA document.

MDHT (Model-Driven Health Tools)

MDHT is an open-source Eclipse-based toolset for CDA development. It includes a validation framework, Java API for CDA document construction, and code generation from CDA templates. While aging, MDHT remains used in some legacy C-CDA implementations.

Integration Engine Validation

Interface engines like Mirth Connect can validate C-CDA documents inline as part of integration workflows. This is useful for catching errors before documents reach production endpoints.

Frequently Asked Questions

What does C-CDA stand for?

C-CDA stands for Consolidated Clinical Document Architecture. It is an HL7 implementation guide that defines templates for clinical documents used in US healthcare.

Is C-CDA the same as CCD?

No. C-CDA is the standard (implementation guide) that defines multiple document types. CCD (Continuity of Care Document) is one specific document type defined within C-CDA. Other C-CDA document types include Discharge Summary, Referral Note, Progress Note, and Operative Note.

Is C-CDA being replaced by FHIR?

Not yet, and not entirely. FHIR is becoming the standard for API-based data access, but C-CDA remains the standard for document-based exchange, care transitions, and HIE participation. Both standards coexist, and most healthcare organizations need to support both. Over time, FHIR-based document exchange (using FHIR Documents or the International Patient Summary) may replace some C-CDA use cases.

What is the difference between C-CDA and HL7 v2?

HL7 v2 is a messaging standard for real-time event notifications (admissions, orders, results). C-CDA is a document standard for clinical summaries. They serve different purposes: HL7 v2 tells systems that something happened (a patient was admitted, a lab result is ready), while C-CDA provides a comprehensive clinical summary of the patient’s state. Most healthcare organizations use both.

Next Steps

C-CDA remains a critical standard for clinical document exchange in US healthcare. Whether you are implementing C-CDA for ONC certification, integrating with health information exchanges, or building document processing pipelines, the standard’s XML structure and template system reward careful, standards-compliant implementation.

• Healthcare Interoperability Services — We help organizations implement C-CDA document exchange, HIE connectivity, and clinical data integration.
• FHIR API Integration — Building FHIR APIs alongside C-CDA document exchange for comprehensive interoperability.
• HL7 Integration Services — Connecting HL7 v2 messaging with C-CDA document workflows through integration engines.
• HL7 v2 vs FHIR — Compare HL7 v2 and FHIR messaging architectures for healthcare integration.
• HL7 Documentation — Technical reference for HL7 standards, message types, and segments.