# What Is C-CDA? CCD, Document Types and C-CDA to FHIR Mapping (Composition, DocumentReference, MHD) > What C-CDA is (CDA R2, C-CDA R2.1 through 5.0, CCD and the other document types, templateIds, ONC requirements) and how to map C-CDA documents to FHIR Composition and DocumentReference, including MHD versus XDS and Swiss EPR MHD. Author: Ala Ben Aicha Canonical page: https://alabenaicha.me/insights/c-cda-to-fhir-document-exchange Updated: 2026-10-06 ## 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 | Version | Published | Notes | | -------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------- | | C-CDA R2.1 | 2015, errata since | Templates versioned `2015-08-01`. Still the version named in ONC certification | | Companion Guide R4.1 | 2023 | Guidance for carrying USCDI v3 inside C-CDA R2.1 | | C-CDA 3.0 | May 2024 | First release in the FHIR StructureDefinition publishing format; USCDI v4. Templates versioned `2024-05-01` | | C-CDA 4.0 | June 2025 | USCDI v5 | | C-CDA 5.0 | June 2026 | Current STU; USCDI v6 | 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](https://hl7.org/cda/us/ccda/)) 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`): | Document | templateId root | Typical use | | --------------------------------- | ------------------------------------- | --------------------------------------- | | Continuity of Care Document (CCD) | 2.16.840.1.113883.10.20.22.1.2 | Patient summary at a point in time | | Discharge Summary | 2.16.840.1.113883.10.20.22.1.8 | End of an inpatient stay | | Referral Note | 2.16.840.1.113883.10.20.22.1.14 | Request to another clinician | | Transfer Summary | 2.16.840.1.113883.10.20.22.1.13 | Transfer to another care setting | | Progress Note | 2.16.840.1.113883.10.20.22.1.9 | Ongoing encounter documentation | | Consultation Note | 2.16.840.1.113883.10.20.22.1.4 | Response to a consultation request | | History and Physical | 2.16.840.1.113883.10.20.22.1.3 | Admission or pre-procedure assessment | | Operative Note / Procedure Note | 2.16.840.1.113883.10.20.22.1.7 / .1.6 | Surgery and other procedures | | Care Plan | 2.16.840.1.113883.10.20.22.1.15 | Goals, interventions, outcomes | | Unstructured Document | 2.16.840.1.113883.10.20.22.1.10 | PDF or scanned content in a CDA wrapper | ### 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](https://www.healthit.gov/test-method/transitions-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](https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-astponc-deregulatory-actions-unleash-prosperity) (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](https://alabenaicha.me/insights/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](https://hl7.org/fhir/R4/composition.html). 2. **Share the document as a document**: keep the CDA bytes (or a FHIR document Bundle) and index them with [DocumentReference](https://hl7.org/fhir/R4/documentreference.html) for XDS or MHD. Pin the [C-CDA on FHIR](https://hl7.org/fhir/us/ccda/) 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](https://hl7.org/fhir/uv/fhir-clinical-document/) 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. | CCD section (LOINC) | C-CDA role | FHIR Composition.section.entry | Notes | | ---------------------- | ---------- | ------------------------------------------------- | ---------------------------------------------------------- | | Allergies 48765-2 | SHALL | `AllergyIntolerance` (US Core) | Empty section still exists; do not drop narrative | | Medications 10160-0 | SHALL | `MedicationStatement` / `MedicationRequest` | Mood/status maps are in the IG ConceptMaps | | Problem List 11450-4 | SHALL | `Condition` (US Core) | Concern vs problem status is not 1:1 with `clinicalStatus` | | Results 30954-2 | SHALL | `Observation` / `DiagnosticReport` | Narrative in `section.text` is authentic, not a preview | | Social History 29762-2 | SHALL | `Observation` (US Core smoking status and others) | Check which observations the sender actually codes | | Vital Signs 8716-3 | SHALL | `Observation` (US Core vital signs) | Check units and LOINC panel codes | | Procedures 47519-4 | SHOULD | `Procedure` | | | Immunizations 11369-6 | MAY | `Immunization` | | CDA `section/text` maps to `Composition.section.text`. The [mapping guidance](https://hl7.org/fhir/us/ccda/mappingGuidance.html) 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): | Job | XDS.b (SOAP) | MHD (FHIR) | | ------------------ | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | Provide / register | ITI-41 Provide and Register Document Set | **ITI-65** Provide Document Bundle (`transaction` Bundle: SubmissionSet List + DocumentReference + Binary) | | Find | ITI-18 Registry Stored Query | **ITI-67** Find Document References (`GET DocumentReference`) | | Retrieve | ITI-43 Retrieve Document Set | **ITI-68** Retrieve Document (`Binary` or attachment URL) | | Metadata object | XDS DocumentEntry | DocumentReference (`masterIdentifier` ← uniqueId, `identifier` ← entryUUID) | 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](https://alabenaicha.me/insights/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](https://fhir.ch/ig/ch-epr-fhir/index.html) 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](https://alabenaicha.me/insights/swiss-electronic-patient-dossier-integration). REST FHIR resource APIs in general are the [FHIR integration guide](https://alabenaicha.me/insights/hl7-fhir-integration-guide). ## Identifier traps | Trap | Symptom | Fix | | ------------------------------------------------ | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | ClinicalDocument/id lost | Cannot replace or deprecate the document later | `DocumentReference.masterIdentifier` from CDA ClinicalDocument/id. Root-only: `urn:oid:` + root. With an extension, MHD serialises it as `oid^extension` | | Patient id in CDA ≠ MHD subject | ITI-65 rejected | US: Patient.identifier aligned with US Core. Swiss: logical reference with EPR-SPID; do not mint a national Patient URL | | Mapping sections and discarding `section/text` | Legal/clinical content missing in FHIR | Copy narrative; entries are structured *support*, not a licence to drop text | | Composition document vs MHD Binary mixed up | Consumer asks for Bundle, gets CDA, or the reverse | Pick one payload per flow: FHIR document Bundle **or** CDA Binary + DocumentReference. Both can exist; they are different contracts | | XDS uniqueId without `urn:oid:` on MHD | Affinity-domain mismatch | MHD encodes OIDs and UUIDs as URIs with system `urn:ietf:rfc:3986` | | Ignoring `templateId` extensions | R2.1 and 3.0+ templates treated as identical | Route on root **and** extension; `2015-08-01` and `2024-05-01` carry different rules | | Using a generic FHIR server as an EPD connection | Community rejects metadata | Swiss value sets (classCode, typeCode, formatCode, confidentialityCode) from eHealth Suisse, not US LOINC-only CCD metadata | ## Test fixtures De-identified. OIDs below are examples, not a real organisation. Minimal CCD header shape (truncated): ```xml Example Continuity of Care Document JANEEXAMPLE ``` Allergies section with narrative and no coded allergy (truncated): ```xml
Allergies No known allergies (example).
``` Composition projection (truncated): ```json { "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": "
No known allergies (example).
" } } ] } ``` MHD DocumentReference metadata (truncated; Binary would hold the CDA bytes): ```json { "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 | Failure | Detection | Rollback | | ----------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | Partial section map | Missing SHALL section on the Composition | Reject the document; do not register MHD metadata for a half-projected CCD | | Dual write (CDA + FHIR resources) diverges | Condition list ≠ problem-section narrative | One authoritative store. Prefer keeping CDA as the legal document and FHIR as a projection | | ITI-65 succeeds, ITI-68 URL wrong | Consumer 404 on Binary | Source in ITI-65 points at the Bundle Binary; responder in ITI-67 points at the ITI-68 endpoint | | Replacement without `relatesTo` | Two current documents for one ClinicalDocument/id | `DocumentReference.relatesTo.code = replaces` toward the previous reference | | Treating MHD as “the EPD is FHIR resources now” | Community still expects document metadata | Swiss EPR remains document-centric; MHD is the mobile API onto XDS | 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](https://alabenaicha.me/services/hl7-fhir-integration). For a scoped document-exchange spike, use [contact with project intent](https://alabenaicha.me/contact?intent=project). 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.