Written and maintained by CASRAI Editorial Board
Last updated
C-CDA (Consolidated Clinical Document Architecture)—formally published by Health Level Seven International as HL7 CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Release 2.1—is the foundational XML-based clinical document exchange standard used across United States healthcare systems, electronic health records (EHRs), and Health Information Exchanges (HIEs). Built on the ANSI/HL7 Clinical Document Architecture Release 2.0 (CDA R2) base standard and the HL7 Version 3 Reference Information Model (RIM), C-CDA consolidates earlier fragmented implementation guides—including HITSP C32, Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC), and prior HL7 CDA templates—into a unified library of reusable document-level, section-level, and entry-level XML templates.
In clinical informatics and biomedical data engineering, C-CDA serves as the primary document payload for transitions of care, longitudinal patient record aggregation across networks such as Carequality and CommonWell, and retrospective clinical research data extraction alongside resource-level APIs defined by HL7 FHIR and US Core.
What Is C-CDA? Architectural Principles and Template Hierarchy
Every C-CDA document is an XML instance rooted in the <ClinicalDocument xmlns="urn:hl7-org:v3"> element that adheres to the six core characteristics of the HL7 CDA R2 specification:
- Persistence: A clinical document continues to exist in an unaltered state for a time period defined by local and regulatory record-retention requirements.
- Stewardship: A CDA document is maintained by an organization (
custodian) entrusted with its care. - Potential for Authentication: A CDA document is an assemblage of clinical information intended to be legally authenticated (
legalAuthenticator) by a clinician. - Context: The document header establishes the default clinical context (patient identity, author, encounter timeframe, and originating facility) for all observations inside its body unless explicitly overridden at the section or entry level.
- Wholeness: Authentication applies to the entire clinical document as a complete clinical attestation, not merely to isolated data fields in flight.
- Human Readability: Every C-CDA section must include a human-readable narrative block (
<text>) that can be rendered in any standard web browser using an XSLT stylesheet, ensuring that a receiving clinician can always read the full clinical narrative even if the receiving system cannot parse discrete coded XML entries.
The Three-Tier C-CDA Template Reuse Architecture
C-CDA Release 2.1 achieves modularity through a three-tier hierarchy of templates identified by globally unique HL7 Object Identifiers (OIDs) in <templateId root="..." extension="..."/> elements:
- Document-Level Templates: Define the specific clinical note type (identified by a LOINC document code in
<code>) and constrain which section-level templates are required (SHALL) or optional (MAY/SHOULD). All C-CDA documents inherit header constraints from the overarching US Realm Header template (OID2.16.840.1.113883.10.20.22.1.1). - Section-Level Templates: Represent distinct clinical headings within the document body—such as Problems (OID
2.16.840.1.113883.10.20.22.2.5.1), Medications (2.16.840.1.113883.10.20.22.2.1.1), Allergies and Intolerances (2.16.840.1.113883.10.20.22.2.6.1), Results (2.16.840.1.113883.10.20.22.2.3.1), Vital Signs (2.16.840.1.113883.10.20.22.2.4.1), Procedures (2.16.840.1.113883.10.20.22.2.7.1), and Immunizations (2.16.840.1.113883.10.20.22.2.2.1). - Entry-Level Templates: Encode machine-computable clinical statements inside a section using HL7 V3 RIM clinical act classes—
<act>,<observation>,<substanceAdministration>,<procedure>,<supply>,<encounter>, and<organizer>—bound to standardized clinical terminologies (SNOMED CT, LOINC, RxNorm, ICD-10-CM, CVX, and UCUM).
Anatomy of the C-CDA Format: Header vs. Structured Body
A conforming C-CDA XML document is divided into two top-level components: the CDA Header and the CDA Body (which may be a <structuredBody> containing coded XML sections or a <nonXMLBody> wrapping an unstructured PDF or scanned image).
1. The US Realm CDA Header
Appearing immediately inside <ClinicalDocument> before <component>, the header captures provenance, patient demographics, and care-team attribution:
- Document Metadata:
<realmCode code="US"/>,<typeId>,<templateId>(declaring conformance to US Realm Header and the specific document type), globally unique document<id>, LOINC document<code>,<title>, creation timestamp<effectiveTime>, and<confidentialityCode>. - Participants:
<recordTarget>/<patientRole>: Patient identifiers (MRNs, enterprise MPI IDs), legal name, birth date, administrative gender, race, ethnicity (CDC Race and Ethnicity Code System), preferred language, address, and telecom.<author>: The clinician or EHR system that authored the document, including National Provider Identifier (NPI) under root OID2.16.840.1.113883.4.6.<custodian>: The healthcare organization legally responsible for maintaining the document archive.<legalAuthenticator>and<authenticator>: Clinicians attesting to the legal validity of the signed note.<documentationOf>/<serviceEvent>and<componentOf>/<encompassingEncounter>: The clinical service timeframe, care team performers, and inpatient/outpatient encounter facility.
2. The Structured Body: Dual Narrative and Coded Entries
Inside <component><structuredBody>, each <component><section> pairs a human-readable block with machine-computable entries:
- Narrative Block (
<text>): Written in CDA Narrative Block markup (a constrained subset of XHTML featuring<table>,<list>,<paragraph>, and<content ID="...">anchors). - Machine-Computable Entries (
<entry>): Structured XML statements that reference the exact narrative span in the<text>block via<originalText><reference value="#..."/></originalText>, preserving provenance between what the clinician saw on screen and the underlying SNOMED CT, RxNorm, or LOINC code.
Core C-CDA Document Types and LOINC Codes
While the Continuity of Care Document (CCD) is the most widely exchanged C-CDA template (often colloquially conflated with C-CDA itself), C-CDA Release 2.1 specifies multiple clinical document templates tailored to specific clinical workflows:
| C-CDA Document Type | Template OID (R2.1) | Primary LOINC Code | Primary Clinical & Research Use Case |
|---|---|---|---|
| Continuity of Care Document (CCD) | 2.16.840.1.113883.10.20.22.1.2 |
34133-9 (Summarization of episode note) |
Longitudinal patient summary (problems, medications, allergies, results, vitals, procedures, immunizations, social history, plan of treatment) |
| Discharge Summary | 2.16.840.1.113883.10.20.22.1.8 |
18842-5 (Discharge summary) |
Hospital inpatient transition of care detailing admission diagnosis, hospital course, discharge medications, and discharge disposition |
| Referral Note | 2.16.840.1.113883.10.20.22.1.14 |
57133-1 (Referral note) |
Ambulatory-to-specialist transition of care communicating reason for referral, active problem list, and diagnostic results |
| Consultation Note | 2.16.840.1.113883.10.20.22.1.4 |
11488-4 (Consult note) |
Specialist evaluation response back to the referring clinician |
| History and Physical (H&P) | 2.16.840.1.113883.10.20.22.1.3 |
34117-2 (History and physical note) |
Comprehensive admission or pre-procedural history, review of systems, and physical examination |
| Progress Note | 2.16.840.1.113883.10.20.22.1.9 |
11506-3 (Progress note) |
Encounter-specific inpatient or outpatient clinical progress note (subjective, objective, assessment, plan) |
| Procedure Note & Operative Note | 2.16.840.1.113883.10.20.22.1.13 / .7 |
28570-0 / 11504-8 |
Interventional or surgical procedure documentation, anesthesia, complications, and implanted device UDI data |
| Care Plan | 2.16.840.1.113883.10.20.22.1.15 |
52521-2 (Overall plan of care/advance care directives) |
Patient-centered health concerns, measurable goals, planned interventions, and outcome evaluations |
ONC Certification Requirements and C-CDA to FHIR R4 Mapping
Under the Assistant Secretary for Technology Policy / Office of the National Coordinator for Health IT (ASTP/ONC) Certification Program rules at 45 CFR § 170.315, certified health IT modules must support C-CDA Release 2.1 populated with United States Core Data for Interoperability (USCDI) data elements across three key certification criteria:
- Transitions of Care (
45 CFR § 170.315(b)(1)): Creating, sending, and receiving C-CDA R2.1 CCD, Referral Note, and Discharge Summary documents using Direct Project secure messaging protocols or IHE Cross-Enterprise Document Sharing (XDS.b / XCA) profiles. - Clinical Information Reconciliation and Incorporation (
45 CFR § 170.315(b)(2)): Parsing incoming C-CDA documents so clinicians can reconcile and incorporate discrete Problems (SNOMED CT / ICD-10-CM), Medications (RxNorm), and Medication Allergies (RxNorm / UNII) directly into the local EHR chart. - Consolidated CDA Creation Performance (
45 CFR § 170.315(g)(6)): Validating C-CDA XML syntax, vocabulary bindings, and HL7 C-CDA R2.1 Companion Guide rules (verified via the ONC SITE C-CDA Validator).
Transforming C-CDA XML to HL7 FHIR R4
Because document exchange networks (eHealth Exchange, Carequality, CommonWell) transmit hundreds of millions of C-CDA XML documents annually while modern analytics pipelines and clinical research platforms operate on HL7 FHIR R4, data engineering teams and interoperability platforms such as Health Gorilla implement the HL7 C-CDA on FHIR Implementation Guide:
- Document Wrapper Mapping: The C-CDA
<ClinicalDocument>root maps to a FHIR R4Bundleresource withBundle.type = "document", where the first entry is a FHIRCompositionresource representing the C-CDA Header and section structure. - Section-to-Resource Extraction: Coded C-CDA
<entry>elements are parsed, deduplicated across multiple historical CCDs, and normalized into US Core FHIR R4 resources—mapping Problem Observations toCondition, Medication Activities toMedicationRequest/MedicationStatement, Allergy Intolerance Observations toAllergyIntolerance, Result Observations toDiagnosticReportandObservation, and Vital Sign Organizers to vital-signsObservationprofiles.
