Qu'est-ce que le C-CDA ? CCD, types de documents et passage du C-CDA à FHIR (Composition, DocumentReference, MHD)

Réponse directe

Le C-CDA (Consolidated Clinical Document Architecture) est la bibliothèque américaine de templates HL7 CDA R2 pour les documents cliniques, comme le Continuity of Care Document (CCD), la lettre de sortie (Discharge Summary) ou le courrier d'adressage (Referral Note). Un CCD est un document XML CDA composé d'un en-tête et de sections codées. Pour le passer en FHIR, on projette les sections sur une Composition FHIR et leurs entrées sur des ressources, ou on conserve les octets CDA en les indexant avec DocumentReference. MHD est l'API FHIR posée sur le partage de documents XDS, y compris pour le DEP suisse.

Qu'est-ce que le C-CDA ?

CDA R2 est le standard HL7 de base pour les documents cliniques, approuvé en 2005. Il définit un document XML avec un en-tête (qui est le patient, qui a rédigé le document, qui le conserve) et un corps fait de sections. Chaque section porte un texte lisible et, en option, des entrées codées. CDA seul reste générique : ce sont les guides d'implémentation qui le contraignent au moyen de templates.

Le C-CDA est le guide du domaine américain (US Realm) qui a regroupé ces templates dans une bibliothèque unique. Chaque template est identifié par un templateId composé d'un OID root et, depuis la R2, d'une extension qui en porte la version. L'émetteur déclare les templates auxquels il se conforme ; les validateurs contrôlent le document par rapport à eux.

Les versions du C-CDA en 2026

Le format d'échange n'a pas changé avec la 3.0 : les documents restent du XML CDA. Ce qui a changé, c'est la manière dont HL7 publie les templates (sous forme de modèles logiques sur le site du C-CDA 5.0) et les éléments USCDI qu'ils peuvent porter. HL7 précise que le guide R2.1 n'a connu que des errata depuis 2015. Demandez à l'émetteur quelle version et quel companion guide il produit avant d'écrire un parseur.

Types de documents

Le C-CDA 5.0 définit les templates de documents suivants, tous bâtis sur l'en-tête US Realm Header (2.16.840.1.113883.10.20.22.1.1) :

En-tête, sections et entrées

• En-tête : recordTarget (le patient), author, custodian, documentationOf (l'acte ou la prestation documentés) et, pour les documents liés à une venue, componentOf. C'est à partir de l'en-tête que l'on construit les métadonnées de partage.
• Sections : chacune possède un templateId, un code LOINC, un title et un bloc narratif text. Le texte narratif constitue le contenu clinique attesté.
• Entrées : énoncés codés à l'intérieur d'une section, par exemple l'Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) qui encapsule une Allergy - Intolerance Observation. Les entrées viennent à l'appui du texte et ne doivent pas le contredire.

Où le C-CDA est exigé

Aux États-Unis, le critère de certification ONC § 170.315(b)(1) Transitions of care impose depuis le 1er janvier 2026 de produire des documents C-CDA R2.1 conformes au Companion Guide Release 4.1 (USCDI v3), et d'accepter en réception les versions R1.1 et R2.1. La proposition de règle HTI-5 (décembre 2025) prévoit de supprimer plusieurs critères propres au CDA au profit de FHIR. Aucune règle définitive n'avait été identifiée lors de cette mise à jour : vérifiez son statut avant de modifier un produit certifié. Hors des États-Unis, des documents CDA circulent dans des programmes nationaux européens avec leurs propres templates ; le C-CDA reste un guide du domaine américain. Pour situer les documents parmi les autres modes d'échange, voir Interopérabilité en santé numérique : les bases.

Correspondance entre messages et ressources

Deux travaux différents se cachent derrière l'expression « C-CDA vers FHIR » :

1. Projeter le contenu clinique dans des ressources FHIR (Condition, AllergyIntolerance, MedicationStatement, Observation) rattachées à une Composition.
2. Partager le document en tant que document : conserver les octets CDA (ou un Bundle document FHIR) et les indexer avec DocumentReference pour XDS ou MHD.

Figez la version de C-CDA on FHIR que vous utilisez (URL officielle http://hl7.org/fhir/us/ccda/ImplementationGuide/hl7.fhir.us.ccda). La version actuelle est la 2.0.0 (STU 2, juin 2026, FHIR R4). Elle se concentre sur les correspondances au niveau des entrées, dans les deux sens, pour les allergies, venues, vaccinations, médicaments, problèmes, actes, résultats, mode de vie et signes vitaux, avec US Core 6.1.0 comme cible. Les profils Composition des types de documents C-CDA n'ont pas été repris dans la STU 2 : le guide renvoie à la STU 1.1 pour ces profils et à l'IG FHIR Clinical Documents pour les Bundles documents, et annonce que la prochaine version vise à réintroduire des profils de documents.

Le CCD (template 2.16.840.1.113883.10.20.22.1.2, LOINC 34133-9 Summarization of Episode Note) DOIT contenir six sections, en C-CDA R2.1 comme en C-CDA 5.0 : allergies, médicaments, problèmes, résultats, mode de vie (Social History) et signes vitaux. Figez la version du C-CDA réellement utilisée par l'émetteur, car les templates d'entrées et les jeux de valeurs varient d'une version à l'autre.

Le section/text CDA correspond à Composition.section.text. Les consignes de correspondance définissent aussi la conversion des identifiants CDA en identifiants FHIR : un OID connu est traduit en son URI ; un identifiant réduit à un root utilise urn:ietf:rfc:3986 comme system et l'OID préfixé par urn:oid: comme value. Le texte narratif fait partie intégrante du document et doit être conservé.

MHD face à XDS (partage de documents, pas correspondance des sections) :

Les échanges américains (Direct, documents TEFCA, nombreux HIE) gardent souvent le XML C-CDA comme contenu et exposent DocumentReference + Binary en FHIR. Lorsqu'un DPI propose les deux, le guide des API d'intégration DPI aide à choisir entre API documents et API ressources. Le DEP suisse utilise la même couche MHD au-dessus du XDS des communautés : CH EPR FHIR profile CH MHD DocumentReference Comprehensive et CH MHD Provide Document Bundle Comprehensive pour ITI-65. L'identité nationale du patient est l'EPR-SPID, utilisé comme identifiant logique et non comme ressource Patient adressable au niveau national. L'architecture des communautés est décrite dans l'article sur le DEP suisse. Les API REST de ressources FHIR en général sont traitées dans le guide d'intégration FHIR.

Pièges liés aux identifiants

Jeux de test

Données désidentifiées. Les OID ci-dessous sont des exemples, pas une organisation réelle.

Forme minimale d'un en-tête CCD (tronqué) :

<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>

Section allergies avec texte narratif et sans allergie codée (tronquée) :

<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>

Projection en Composition (tronquée) :

{
  "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>" }
    }
  ]
}

Métadonnées DocumentReference MHD (tronquées ; le Binary contiendrait les octets CDA) :

{
  "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"
      }
    }
  ]
}

Tests minimaux :

1. Aller-retour du texte : le section/text CDA des allergies, médicaments, problèmes et résultats est présent dans la Composition.
2. Section allergies vide (aucune entrée, texte « aucune allergie connue ») : la section existe toujours, sans AllergyIntolerance fictive.
3. Bundle ITI-65 : List (lot de soumission) + DocumentReference + Binary ; la transaction réussit ou échoue d'un bloc.
4. Parcours américain : correspondances d'entrées vérifiées par rapport à C-CDA on FHIR 2.0.0 et aux profils US Core ; profil de document figé explicitement.
5. Aiguillage par version : un même CCD avec des extensions de template R2.1 et 3.0+ est traité par la bonne correspondance.
6. Parcours suisse : métadonnées CH MHD Comprehensive + sujet logique EPR-SPID ; n'exigez pas d'URL Patient résolvable.

Ne versionnez jamais dans git du XML C-CDA réel contenant des noms de patients.

Modes de défaillance et retour arrière

Retour arrière après un dépôt erroné : rendez obsolète ou remplacez le DocumentReference (availabilityStatus / status), ne supprimez pas l'identité Patient et conservez le CDA d'origine dans le système source. Les remplacements XDS/MHD sont des associations, pas des suppressions SQL.

Service associé

Si vous avez besoin d'une projection C-CDA et du câblage MHD ou XDS (CCD américain ou EPR FHIR suisse), cela relève de l'intégration HL7 FHIR. Pour un prototype d'échange de documents bien délimité, passez par le formulaire de contact projet.

Cette page n'est ni un certificat de validation C-CDA, ni une procédure d'affiliation à une communauté eHealth Suisse, ni un avis juridique sur le document qui constitue le dossier de soins.