CDA et C-CDA expliqués : documents cliniques HL7

Réponse courte : l'Architecture de Documents Cliniques (CDA) est la norme HL7 pour les documents cliniques : résumés de sortie, lettres de référence, notes de consultation, résumés de patient. Un document CDA est un fichier XML avec un en-tête (qui, quand, à propos de qui) et un corps de sections, chacune avec une narration lisible par l'homme et, facultativement, des entrées codées lisibles par machine. C-CDA (Consolidated CDA) est le guide d'implémentation américain qui fixe les modèles pour les types de documents les plus courants ; le CCD (Continuity of Care Document) en est le membre le plus connu. La version 2 de CDA date de 2005 et est toujours obligatoire dans plusieurs programmes nationaux et transfrontaliers.

À quoi ressemble un document

Un document CDA est un fichier XML dont la racine ClinicalDocument contient un en-tête (le type de document sous forme de code LOINC, les OID de templateId, un identifiant, la date d'effet, le code de confidentialité, le patient, l'auteur et le dépositaire) et un corps de sections, chacune avec un code LOINC, un élément texte obligatoire lisible par l'homme et des entrées codées optionnelles pour la lecture par logiciel.

<ClinicalDocument xmlns="urn:hl7-org:v3">
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <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" extension="DOC-2026-0314"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of Episode Note"/>
  <effectiveTime value="20260314101500+0100"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <recordTarget><patientRole>…</patientRole></recordTarget>
  <author>…</author>
  <custodian>…</custodian>
  <component><structuredBody>
    <component><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" displayName="Allergies and adverse reactions"/>
      <title>Allergies</title>
      <text><table><tr><td>Penicillin</td><td>Rash</td></tr></table></text>
      <entry>…coded Allergy Concern Act…</entry>
    </section></component>
  </structuredBody></component>
</ClinicalDocument>

Trois points à noter. Le type de document et chaque section sont identifiés par un code LOINC (34133-9, 48765-2). Les modèles sont identifiés par des OID (2.16.840.1…), pas par des URL. L'élément <text> est obligatoire et est ce que voit un clinicien ; l'élément <entry> est facultatif et est ce que lit le logiciel.

Les trois niveaux

CDA définit trois niveaux de structure. Le niveau 1 est un en-tête valide avec un corps non structuré tel qu'un PDF intégré. Le niveau 2 ajoute un corps structuré avec des sections codées et un récit, mais sans entrées codées. Le niveau 3 ajoute des entrées codées suivant des modèles, permettant aux logiciels d'importer les allergies, les médicaments et les problèmes. La plupart des documents réels se situent entre les niveaux 2 et 3.

Niveau 1 : un en-tête valide plus un corps non structuré, par exemple un PDF intégré. Légalement un document CDA ; les ordinateurs peuvent le classer mais pas le lire.
Niveau 2 : corps structuré avec des sections codées et une narration, sans entrées codées. Le logiciel sait qu'il y a une section d'allergies ; il ne peut pas lister les allergies.
Niveau 3 : sections avec des entrées codées suivant des modèles. Le logiciel peut importer les allergies, les médicaments et les problèmes dans le dossier de réception.

La plupart des CDA du monde réel se situent entre les niveaux 2 et 3 : certaines sections sont codées, d'autres sont uniquement narratives.

Six principes qui le façonnent encore

Les six principes derrière CDA sont la persistance (un document vit inchangé pendant des années), la gestion (un dépositaire en est responsable), le potentiel d'authentification (il peut être signé), le contexte (l'en-tête s'applique à l'ensemble du document), l'intégrité (une section perd son sens en dehors de son document) et la lisibilité par l'homme (le récit s'affiche sans logiciel spécial). Les documents FHIR adoptent les mêmes six principes.

CDA a été conçu autour de la persistance (un document vit inchangé pendant des années), de la gestion (un gardien en est responsable), du potentiel d'authentification (il peut être signé), du contexte (l'en-tête s'applique à l'ensemble du document), de l'intégrité (une section hors de son document perd son sens) et de la lisibilité humaine (la narration doit être rendue sans logiciel spécial). Les documents FHIR (un Bundle de type document avec une Composition) adoptent les mêmes principes ; le modèle de données sous-jacent est différent, comme l'explique CDA vs FHIR.

C-CDA : la consolidation américaine

C-CDA (Consolidated CDA) est le guide d'implémentation américain qui, depuis 2011, a fusionné plusieurs guides CDA qui se chevauchaient en un seul, avec une douzaine de modèles de documents tels que le Continuity of Care Document, le Discharge Summary et le Referral Note, ainsi qu'une bibliothèque partagée de modèles de sections et d'entrées. C-CDA R2.1 est requis par la certification ONC pour les transitions de soins et les résumés de patients.

Avant 2011, les implémenteurs américains utilisaient plusieurs guides CDA qui se chevauchaient. Consolidated CDA les a fusionnés en un seul, avec une douzaine de modèles de documents (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report et autres) et une bibliothèque partagée de modèles de sections et d'entrées. C-CDA R2.1 est requis par la certification des DSE américains (ONC) pour les transitions de soins et les résumés de patients, et le reste ainsi aux côtés de FHIR US Core pour les API.

Où vit CDA en 2026

En 2026, CDA est utilisé dans les échanges entre prestataires américains sous forme de C-CDA via la messagerie Direct et les échanges d'informations de santé, dans le résumé de patient et la prescription électronique transfrontaliers européens MyHealth@EU, dans les programmes nationaux tels que l'eArztbrief et l'ePA allemands, l'ELGA autrichien, le FSE italien, aux Pays-Bas et en Suisse, et partout ailleurs comme en-tête enveloppant des documents numérisés ou PDF.

États-Unis : C-CDA pour l'échange de documents entre prestataires, dans la messagerie Direct et les échanges d'informations sur la santé.
Europe, transfrontalier : MyHealth@EU échange le Résumé de Patient et la Prescription Électronique sous forme de documents CDA (les modèles eHDSI), avec des formats basés sur FHIR arrivant sous l'EHDS. Voir Prescription Électronique à travers les frontières de l'UE.
Programmes nationaux : la lettre médicale électronique allemande (eArztbrief) et des parties de l'ePA, les documents ELGA autrichiens, la FSE italienne, les Pays-Bas et la Suisse utilisent CDA pour les documents, souvent via les registres IHE XDS.
Partout : documents numérisés et PDF encapsulés dans un en-tête CDA, afin qu'un registre de documents puisse les indexer.

Ce qu'un récepteur obtient réellement

Un destinataire d'un document CDA reçoit toujours un récit lisible, mais les données codées ne peuvent être importées que si l'expéditeur a utilisé les modèles de niveau 3 de manière cohérente. Les systèmes récepteurs affichent généralement le récit et proposent de réconcilier les problèmes, les médicaments et les allergies à partir des entrées une par une, car deux documents de niveau 3 de fournisseurs différents codent rarement le même fait de manière identique.

Un document CDA est fiable pour la lecture et inégal pour l'importation. La narration est toujours présente ; les entrées codées dépendent du niveau et de la discipline du modèle de l'expéditeur. Les systèmes récepteurs affichent généralement la narration au clinicien et proposent de "réconcilier" les problèmes, les médicaments et les allergies à partir des entrées dans le dossier local, un par un. Cette étape de réconciliation existe car deux documents de niveau 3 de différents fournisseurs codent rarement le même fait de la même manière.

Dans Anpheros, un document CDA provenant d'un hôpital est stocké tel quel, en tant que DocumentReference avec le XML attaché, et son contenu codé, lorsqu'il est présent, est mappé dans des ressources FHIR (Condition, AllergyIntolerance, MedicationStatement) avec une provenance pointant vers le document. Voir DocumentReference vs DiagnosticReport vs Binary.

Pages connexes

Sources

Questions fréquentes

CDA est-il la même chose que HL7 v3 ?

CDA est construit sur le modèle d'information de référence HL7 v3 et utilise les types de données v3, c'est pourquoi son XML ressemble à ce qu'il est. Le reste de la messagerie HL7 v3 a connu peu d'adoption ; CDA est la partie de v3 qui a réussi.

Qu'est-ce qu'un CCD ?

Le Continuity of Care Document est le type de document C-CDA pour un résumé de patient : problèmes, médicaments, allergies, immunisations, résultats, procédures, signes vitaux, plan de soins. C'est l'équivalent américain du Résumé International du Patient.

CDA est-il remplacé par FHIR ?

Pour les nouvelles API et applications, oui ; pour l'échange de documents entre institutions, lentement. Les réglementations aux États-Unis et en Europe exigent toujours CDA pour des documents spécifiques, et les documents FHIR sont introduits en parallèle plutôt qu'en remplacement.

Un document CDA peut-il être converti en FHIR ?

Oui, avec des limites. Le guide d'implémentation HL7 C-CDA sur FHIR mappe les types de documents et les sections ; les entrées codées sont mappées aux ressources FHIR lorsque les modèles correspondent. Les sections uniquement narratives deviennent des sections de Composition avec du texte et aucune donnée structurée.

Anpheros Platform

Essayez gratuitement dans le sandbox

Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.

Créer un sandbox gratuit Lire les guides développeurs →

Gratuit · 30 patients synthétiques · sans carte

Ce guide est informatif et ne remplace pas une consultation médicale. Pour toute décision concernant votre santé, parlez-en à votre médecin. En cas d’urgence, appelez le numéro d’urgence local (112 en Europe).

Rédigé par

L'équipe Anpheros

Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.

À propos d'Anpheros →