What Is C-CDA? CCD, Document Types and C-CDA to FHIR Mapping (Composition, DocumentReference, MHD)

Direct answer

C-CDA (Consolidated Clinical Document Architecture) is the US library of HL7 CDA R2 templates for clinical documents such as the Continuity of Care Document (CCD), Discharge Summary and Referral Note. A CCD is a CDA XML document with a header and coded sections. To move it to FHIR, project the sections onto a FHIR Composition and its entries onto resources, or keep the CDA bytes and index them with DocumentReference. MHD is the FHIR API over XDS document sharing, including the Swiss EPR.

What is C-CDA?

CDA R2 is the HL7 base standard for clinical documents, approved in 2005. It defines an XML document with a header (who the patient is, who wrote the document, who keeps it) and a body made of sections. Each section carries human-readable narrative and, optionally, coded entries. CDA on its own is generic; implementation guides constrain it with templates.

C-CDA is the US Realm guide that consolidated those templates into one library. Every template is identified by a templateId with a root OID and, since R2, an extension that versions it. Senders declare the templates they conform to; validators check the document against them.

C-CDA versions in 2026

The wire format did not change in 3.0: documents are still CDA XML. What changed is how HL7 publishes the templates (as logical models on the C-CDA 5.0 site) and which USCDI data elements they can carry. HL7 notes that the R2.1 guide has had only errata releases since 2015. Ask a sender which version and companion guide it produces before you write a parser.

Document types

C-CDA 5.0 defines these document templates, all on top of the US Realm Header (2.16.840.1.113883.10.20.22.1.1):

Header, sections and entries

• Header: recordTarget (patient), author, custodian, documentationOf (the service event) and, for encounter documents, componentOf. The header is what document-sharing metadata is built from.
• Sections: each has a templateId, a LOINC code, a title and a text narrative block. The narrative is the attested clinical content.
• Entries: coded statements inside a section, such as the Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) wrapping an Allergy - Intolerance Observation. Entries support the narrative; they must not contradict it.

Where C-CDA is required

In the US, ONC certification criterion § 170.315(b)(1) Transitions of care requires certified health IT to create C-CDA R2.1 documents following Companion Guide Release 4.1 (USCDI v3) since 1 January 2026, and to receive both R1.1 and R2.1. The HTI-5 proposed rule (December 2025) proposes removing several CDA-specific criteria in favour of FHIR. No final rule had been located when this page was updated, so check its status before changing a certified product. Outside the US, CDA documents appear in European national programmes with their own templates; C-CDA itself is a US Realm guide. For where documents fit among other exchange patterns, see Digital health interoperability 101.

Message and resource mapping

Two different jobs get labelled “C-CDA to FHIR”:

1. Project the clinical content into FHIR resources (Condition, AllergyIntolerance, MedicationStatement, Observation) hanging off a Composition.
2. Share the document as a document: keep the CDA bytes (or a FHIR document Bundle) and index them with DocumentReference for XDS or MHD.

Pin the C-CDA on FHIR version you use (official URL http://hl7.org/fhir/us/ccda/ImplementationGuide/hl7.fhir.us.ccda). The current release is 2.0.0 (STU 2, June 2026, FHIR R4). It concentrates on entry-level mappings in both directions, for allergies, encounters, immunizations, medications, problems, procedures, results, social history and vital signs, targeting US Core 6.1.0. The Composition profiles for C-CDA document types were not carried into STU 2: the guide points to STU 1.1 for them and to the FHIR Clinical Documents IG for document Bundles, and says the next release aims to reintroduce document profiles.

CCD (template 2.16.840.1.113883.10.20.22.1.2, LOINC 34133-9 Summarization of Episode Note) SHALL contain six sections in both C-CDA R2.1 and C-CDA 5.0: Allergies, Medications, Problems, Results, Social History and Vital Signs. Pin the C-CDA version the sender actually uses, because entry templates and value sets differ between releases.

CDA section/text maps to Composition.section.text. The mapping guidance also defines how CDA identifiers become FHIR identifiers: a known OID is translated to its URI, an id with only a root uses urn:ietf:rfc:3986 as system and the OID prefixed with urn:oid: as value. Narrative is an authoritative part of the document and must be preserved.

MHD versus XDS (document sharing, not section mapping):

US exchanges (Direct, TEFCA documents, many HIEs) often keep C-CDA XML as the payload and expose FHIR DocumentReference + Binary. When an EHR offers both, the EHR integration API guide covers how to choose between document and resource APIs. Swiss EPR uses the same MHD layer on community XDS: CH EPR FHIR profiles CH MHD DocumentReference Comprehensive and CH MHD Provide Document Bundle Comprehensive for ITI-65. National patient identity is the EPR-SPID as a logical identifier, not a nationally addressable Patient resource. The community architecture is the Swiss EPD article. REST FHIR resource APIs in general are the FHIR integration guide.

Identifier traps

Test fixtures

De-identified. OIDs below are examples, not a real organisation.

Minimal CCD header shape (truncated):

<ClinicalDocument xmlns="urn:hl7-org:v3">
  <templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2015-08-01"/>
  <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"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1"
        displayName="Summarization of Episode Note"/>
  <title>Example Continuity of Care Document</title>
  <recordTarget>
    <patientRole>
      <id root="2.16.840.1.113883.19.5" extension="MRN-EXAMPLE-0001"/>
      <patient>
        <name><given>JANE</given><family>EXAMPLE</family></name>
        <birthTime value="19770412"/>
      </patient>
    </patientRole>
  </recordTarget>
</ClinicalDocument>

Allergies section with narrative and no coded allergy (truncated):

<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"/>
  <title>Allergies</title>
  <text>No known allergies (example).</text>
</section>

Composition projection (truncated):

{
  "resourceType": "Composition",
  "status": "final",
  "type": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "34133-9",
        "display": "Summarization of Episode Note"
      }
    ]
  },
  "subject": {
    "identifier": {
      "system": "https://hospital.example.org/mrn",
      "value": "MRN-EXAMPLE-0001"
    }
  },
  "date": "2026-09-17T10:30:00+01:00",
  "title": "Example Continuity of Care Document",
  "section": [
    {
      "title": "Allergies",
      "code": {
        "coding": [{ "system": "http://loinc.org", "code": "48765-2" }]
      },
      "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">No known allergies (example).</div>" }
    }
  ]
}

MHD DocumentReference metadata (truncated; Binary would hold the CDA bytes):

{
  "resourceType": "DocumentReference",
  "masterIdentifier": {
    "system": "urn:ietf:rfc:3986",
    "value": "urn:oid:2.16.840.1.113883.19.5.99999.1"
  },
  "status": "current",
  "type": {
    "coding": [{ "system": "http://loinc.org", "code": "34133-9" }]
  },
  "content": [
    {
      "attachment": {
        "contentType": "application/xml",
        "url": "Binary/example-ccd"
      }
    }
  ]
}

Minimum tests:

1. Round-trip narrative: CDA section/text for allergies/meds/problems/results present on Composition.
2. Empty allergies section (no entries, narrative “no known”): still a section, no fake AllergyIntolerance.
3. ITI-65 Bundle: List (submission set) + DocumentReference + Binary; transaction succeeds or fails as a unit.
4. US path: entry mappings checked against C-CDA on FHIR 2.0.0 and US Core profiles; document profile pinned explicitly.
5. Version routing: the same CCD with R2.1 and 3.0+ template extensions parsed by the right mapping.
6. Swiss path: CH MHD comprehensive metadata + EPR-SPID logical subject; do not require a resolvable Patient URL.

Never put real C-CDA XML with patient names into git.

Failure modes and rollback

Rollback for a bad provide: deprecate or replace the DocumentReference (availabilityStatus / status), do not delete Patient identity, and keep the original CDA in the source system. XDS/MHD replacements are associations, not SQL deletes.

Related service

If you need C-CDA projection plus MHD or XDS wiring (US CCD or Swiss EPR FHIR), that is HL7 FHIR integration. For a scoped document-exchange spike, use contact with project intent.

This page is not a C-CDA validator certificate, not an eHealth Suisse community onboarding, and not legal advice about which document is the record of care.