C-CDA to FHIR: CCD sections, Composition, DocumentReference, MHD vs XDS

Direct answer

A CCD is a CDA document. Map required sections onto a FHIR Composition, then choose a Composition document Bundle or a DocumentReference to Binary. MHD is the FHIR API over XDS, including Swiss EPR.

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 C-CDA on FHIR 1.2.0 (official URL http://hl7.org/fhir/us/ccda/ImplementationGuide/hl7.fhir.us.ccda, STU 1, based on FHIR R4). It profiles Composition for C-CDA document types and maps entries toward US Core. It does not require coded entries in every section — a deliberate departure from C-CDA, which used nullFlavors when a section was empty.

CCD (Continuity of Care Document) is one C-CDA document type (template 2.16.840.1.113883.10.20.22.1.2, LOINC 34133-9 Summarization of Episode Note). C-CDA R2.1 CCD SHALL contain Allergies, Medications, Problem List and Results. Later C-CDA publications also call out Social History and Vital Signs as required — pin the C-CDA version the sender actually uses.

CDA section/text maps to Composition.section.text. The mapping guidance is explicit: 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. 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">
  <id root="2.16.840.1.113883.19.5" extension="CCD-EXAMPLE-0001"/>
  <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>

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.CCD-EXAMPLE-0001"
  },
  "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: Composition profile from C-CDA on FHIR 1.2.0.
5. 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.