CDA vs FHIR : documents ou ressources, quand utiliser chacun et comment les convertir

Réponse courte : CDA vous donne un document : un fichier XML signé concernant un patient à un instant T, avec un texte que l'on peut lire et des entrées que l'ordinateur peut lire, qui doit rester entier et inchangé. FHIR vous donne des ressources : un Patient, quarante Observations, trois Conditions, chacune avec sa propre URL, récupérées, recherchées et mises à jour indépendamment via une API REST. FHIR peut également regrouper des ressources dans un document (un Bundle de type document dirigé par une Composition), qui est l'équivalent direct de CDA. Choisissez CDA lorsqu'une réglementation ou un partenaire l'exige ; choisissez FHIR pour les API, les applications et tout ce qui doit être interrogé plutôt que lu.

Les deux formes

CDA et FHIR ont deux formes différentes. CDA échange des documents XML complets construits sur des types de données HL7 v3, identifiés par des OID, avec un récit obligatoire, pas de requêtes, pas de mises à jour et une signature de document complet. FHIR échange des ressources JSON ou XML individuelles ou des Bundles, identifiés par des URL canoniques, avec des requêtes REST intégrées, des mises à jour versionnées et des profils publiés dans des guides d'implémentation.

Ce que la différence signifie en pratique

En pratique, la différence entre CDA et FHIR est que CDA convient au contenu rédigé une fois et conservé dans son intégralité, comme un résumé de sortie signé, tandis que FHIR convient aux données qui évoluent et sont interrogées, comme une série de mesures de tension artérielle. Un récepteur CDA peut afficher mais doit réconcilier pour importer ; un récepteur FHIR reçoit des ressources déjà structurées comme son propre dossier.

Un résumé de sortie d'hôpital est naturellement un document : il est rédigé une fois, signé par un médecin, et doit être reproductible des années plus tard exactement tel qu'il a été lu. Une série de mesures de tension artérielle est naturellement un ensemble de ressources : elle s'enrichit chaque jour, est tracée et filtrée, et personne ne la signe. CDA gère bien la première situation et mal la seconde (vous renverriez le document entier pour chaque nouvelle mesure). FHIR gère la seconde nativement et la première via son mécanisme de document.

L'autre différence pratique réside dans ce que le destinataire peut faire. Un récepteur CDA peut toujours afficher le document ; l'importation de ses entrées nécessite une réconciliation, section par section. Un récepteur FHIR obtient des ressources qui sont déjà dans la forme de son propre dossier ; les questions difficiles portent sur l'identité (est-ce le même patient ?) et la provenance (qui a affirmé cela et quand ?). Voir Correspondance des patients.

Documents FHIR : le point de rencontre

Un document FHIR est un Bundle avec type: "document" dont la première entrée est une Composition. La Composition joue le rôle de l'en-tête CDA et de la liste des sections : type (LOINC), date, auteur, sujet, dépositaire, statut, et section[] avec un titre, un code, un texte narratif et des références aux ressources qui portent les données.

{
  "resourceType": "Bundle",
  "type": "document",
  "identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
  "timestamp": "2026-03-14T10:15:00+01:00",
  "entry": [
    {"fullUrl": "urn:uuid:comp-1", "resource": {
      "resourceType": "Composition", "status": "final",
      "type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
      "subject": {"reference": "urn:uuid:pat-1"},
      "date": "2026-03-14T10:15:00+01:00",
      "author": [{"reference": "urn:uuid:prac-1"}],
      "title": "Patient summary",
      "section": [{
        "title": "Allergies and intolerances",
        "code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
        "text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
        "entry": [{"reference": "urn:uuid:allergy-1"}]
      }]
    }},
    {"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
    {"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
    {"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
  ]
}

Le Résumé International du Patient est exactement cela : un profil de document FHIR, avec un jumeau CDA pour les systèmes qui en ont encore besoin. Voir aussi FHIR Bundle expliqué.

Conversion entre les deux

La conversion entre CDA et FHIR fonctionne dans les deux sens avec des limites. Le guide d'implémentation HL7 C-CDA sur FHIR mappe les types de documents, les sections et les entrées aux profils Composition et aux ressources ; les sections de récit uniquement deviennent du texte sans données. FHIR vers CDA fonctionne pour les ressources qui correspondent aux modèles C-CDA. Dans les deux sens, l'original doit être conservé comme un DocumentReference avec Provenance.

• CDA → FHIR : le guide d'implémentation HL7 C-CDA on FHIR mappe les types de documents et sections américains aux profils de Composition ; les entrées sont mappées aux ressources (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). Le mappage est déterministe pour le contenu de niveau 3 bien structuré et est sujet à perte pour les sections purement narratives, qui deviennent du texte sans données.
• FHIR → CDA : possible pour les documents dont les ressources correspondent aux modèles C-CDA. Les ressources FHIR libres qui n'ont jamais été conçues comme un document (un flux d'Observations de dispositifs portables) ne deviennent pas un CDA cohérent.
• Conservez l'original. Quelle que soit la direction de la conversion, stockez la source telle qu'elle a été reçue, sous forme de DocumentReference, et laissez Provenance pointer des ressources converties vers celle-ci. La conversion est une vue, pas un remplacement.

Quand CDA reste la bonne réponse

CDA reste la bonne réponse lorsque la partie réceptrice l'exige (transitions de soins aux États-Unis, résumé patient et ordonnance électronique MyHealth@EU, plusieurs registres nationaux de documents), lorsque le contenu est légalement un document qui doit être signé et conservé dans son intégralité, ou lorsque l'infrastructure du partenaire est IHE XDS, qui indexe des documents plutôt que des ressources. Sinon, commencez par FHIR.

Lorsque le destinataire l'exige (transitions de soins aux États-Unis, résumé de patient et ordonnance électronique MyHealth@EU aujourd'hui, plusieurs registres nationaux de documents) ; lorsque le contenu est légalement un document qui doit être signé et conservé en entier ; lorsque l'infrastructure du partenaire est IHE XDS, qui indexe des documents et non des ressources. Dans tous les autres cas, commencez par FHIR et produisez un document FHIR lorsqu'un document est nécessaire.

Pages connexes

• CDA et C-CDA expliqués
• FHIR Bundle expliqué
• Le Résumé International du Patient
• HL7 vs FHIR
• DocumentReference vs DiagnosticReport vs Binary
• Correspondance des patients

Sources

• HL7 FHIR R4 : Documents
• HL7 FHIR R4 : Composition
• Guide d'implémentation HL7 C-CDA on FHIR
• HL7 FHIR : comparaison avec CDA (Annexe)
• HL7 FHIR : Résumé International du Patient IG

Questions fréquentes

Un document FHIR est-il simplement du CDA en JSON ?

Non. Il partage les principes (entier, signé, lisible par l'homme, avec un en-tête) mais son contenu est constitué de ressources FHIR ordinaires, de sorte que la même Observation peut exister dans un document et être servie par l'API. Dans CDA, une entrée n'existe qu'à l'intérieur de son document.

Puis-je signer un document FHIR ?

Oui. Bundle.signature contient une signature numérique sur le bundle, et les guides nationaux et IPS décrivent comment faire. En pratique, de nombreux déploiements s'appuient sur la sécurité du transport et la provenance plutôt que sur des signatures.

FHIR a-t-il templateId ?

L'équivalent est meta.profile, une liste d'URL canoniques des StructureDefinitions auxquelles la ressource prétend être conforme. Les validateurs vérifient la conformité de la même manière que les schematrons CDA vérifient les modèles.

Qu'un nouveau programme national devrait-il choisir ?

Les programmes récents (le format d'échange EHDS, les règles d'accès des patients aux États-Unis, l'IPS) choisissent FHIR, avec des documents FHIR pour les résumés et les lettres, et ne conservent un chemin CDA que pour les partenaires existants.

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 gratuitLire les guides développeurs →

Gratuit · 30 patients synthétiques · sans carte

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 →