HL7 et FHIR : en quoi v2, CDA et FHIR diffèrent, et où chacun a encore sa place
Une introduction à l'interopérabilité en santé construite autour de la question HL7 ou FHIR : le rôle de HL7 v2, de CDA et de FHIR, un comparatif détaillé, la même admission ADT dans les deux formats, quand garder la v2, et les autres normes (DICOM, IHE, LOINC, SNOMED CT, openEHR) à connaître.
Ala Ben Aicha
Réponse directe
HL7 est un organisme de normalisation et FHIR l'une de ses normes : opposer « HL7 et FHIR » revient en général à comparer la messagerie HL7 version 2 à FHIR. HL7 v2 transmet des messages d'événements délimités par des barres verticales, le plus souvent en TCP à l'intérieur d'un établissement, et porte encore l'essentiel des admissions, demandes d'examens et résultats. FHIR expose des ressources fines comme Patient ou Observation via des API REST en JSON, ce qui convient aux applications, aux partenaires et aux API réglementées. CDA, la troisième famille HL7 d'usage courant, encapsule un document clinique complet. La plupart des établissements utilisent les trois ; la vraie question est de savoir quelle interface utilise quoi.
HL7 est l'organisme, FHIR est l'une de ses normes
HL7 International publie plusieurs familles de normes. Celles que les équipes d'intégration manipulent chaque semaine :
- HL7 version 2, la norme de messagerie événementielle. La dernière version normative est la v2.9.1, publiée en septembre 2024, mais les interfaces en production tournent souvent en 2.3 à 2.5.1, car émetteur et récepteur doivent s'accorder sur une version.
- CDA (Clinical Document Architecture) Release 2, une norme de documents XML. Aux États-Unis, elle est contrainte par C-CDA, dont la version 5.0.0, publiée en juin 2026, repose toujours sur CDA R2.0.
- FHIR, la norme de ressources et d'API. FHIR R4 (4.0.1) est la version la plus déployée, R5 (5.0.0) a été publiée en 2023 et R6 est encore en ballot. Le guide de l'API FHIR détaille les versions et le REST.
La messagerie HL7 v3 et son modèle de référence (RIM) ont été peu adoptés en dehors de quelques programmes nationaux ; on les croise surtout aujourd'hui à travers CDA, qui en dérive.
HL7 v2, CDA et FHIR en un tableau
| HL7 v2 | CDA / C-CDA | FHIR | |
|---|---|---|---|
| Format | Segments délimités (MSH, PID, PV1, OBX) ; un encodage XML existe mais reste rare | Document XML : en-tête et sections avec une partie narrative lisible obligatoire | Ressources en JSON ou XML |
| Transport | MLLP sur TCP avec ACK/NAK ; aussi fichiers et SFTP | Infrastructures de partage de documents (IHE XDS), messagerie sécurisée, pièces jointes | REST sur HTTPS ; aussi messagerie, documents et Subscriptions |
| Granularité | Un message par événement, avec les segments que prévoit l'événement déclencheur | Un document clinique complet et attestable | Une ressource par concept, assemblées en Bundles |
| Usage type | Mouvements (ADT), demandes, résultats, rendez-vous, actes facturables au sein de l'établissement | Lettres de liaison, comptes rendus, dossiers partagés | Applications patients et professionnels, API partenaires et payeurs, extractions analytiques |
| Interrogation | Surtout en push ; des messages de requête existent mais sont peu utilisés | Recherche et récupération de documents entiers via un registre | API de recherche avec paramètres typés |
| Personnalisation | Champs optionnels et segments Z ; chaque interface exige sa propre spécification | Modèles (templates) dans les guides d'implémentation | Profils et extensions dans les guides d'implémentation |
| Outillage | Moteurs d'interfaces (Mirth Connect, Rhapsody, Cloverleaf), parseurs v2 | Validateurs Schematron et de templates, XSLT | Outils HTTP et JSON génériques, serveurs FHIR, validateur HL7 |
| Adoption | Présente dans quasiment tous les établissements | Exigée pour les DSE certifiés aux États-Unis ; base de nombreux dossiers nationaux | Exigée pour les API des DSE certifiés aux États-Unis ; format de la plupart des nouveaux guides nationaux et européens |
Deux de ces cases méritent une source. Aux États-Unis, les DSE certifiés doivent proposer une API FHIR R4 au titre du §170.315(g)(10). En France, les volets de contenu du CI-SIS pour les documents partagés dans le DMP reposent sur CDA, tandis que les spécifications nationales plus récentes utilisent FHIR.
La même admission en HL7 v2 et en FHIR
Une admission en hospitalisation fictive (ADT^A01) sous forme de message HL7 v2.5.1 :
MSH|^~\&|DEMO_EHR|DEMO_FACILITY|DEMO_API|DEMO_DEST|20261005100000+0100||ADT^A01^ADT_A01|DEMO-MSG-001|P|2.5.1
EVN|A01|20261005100000+0100
PID|1||DEMO-P001^^^DEMO_HOSPITAL^MR||DOE^JANE||19900101|F
PV1|1|I|WARD1^101^A^DEMO_FACILITY||||||||||||||||DEMO-V001|||||||||||||||||||||||||20261005100000+0100
Les mêmes informations sous forme de ressources FHIR R4, envoyées en transaction :
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"fullUrl": "urn:uuid:5b2f6c1e-0d6a-4f1e-9a51-2a1f0c0e7a01",
"resource": {
"resourceType": "Patient",
"identifier": [{ "system": "https://example.org/demo-hospital/patients", "value": "DEMO-P001" }],
"name": [{ "family": "DOE", "given": ["JANE"] }],
"gender": "female",
"birthDate": "1990-01-01"
},
"request": { "method": "POST", "url": "Patient", "ifNoneExist": "identifier=https://example.org/demo-hospital/patients|DEMO-P001" }
},
{
"resource": {
"resourceType": "Encounter",
"identifier": [{ "system": "https://example.org/demo-hospital/visits", "value": "DEMO-V001" }],
"status": "in-progress",
"class": { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "IMP" },
"subject": { "reference": "urn:uuid:5b2f6c1e-0d6a-4f1e-9a51-2a1f0c0e7a01" },
"period": { "start": "2026-10-05T10:00:00+01:00" }
},
"request": { "method": "POST", "url": "Encounter" }
}
]
}
| Champ HL7 v2 | Élément FHIR | Remarque |
|---|---|---|
MSH-9 ADT^A01^ADT_A01 |
Pas de champ direct en REST | L'événement devient un état : une venue hospitalière en cours |
| MSH-10 | Clé de dédoublonnage des livraisons | Ni un identifiant patient, ni un identifiant de venue |
| PID-3 | Patient.identifier |
L'autorité d'attribution devient l'URI system |
| PID-5, PID-7, PID-8 | Patient.name, Patient.birthDate, Patient.gender |
F devient female via une table de correspondance |
| PV1-2 | Encounter.class |
I devient IMP |
| PV1-19 | Encounter.identifier |
Un espace de noms distinct de celui du patient |
| PV1-44 / EVN-2 | Encounter.period.start |
Conservez le décalage horaire |
La différence essentielle n'est pas syntaxique. Un message v2 dit « cet événement a eu lieu » ; une écriture FHIR REST dit « voici l'état actuel ». Une mise à jour A08 ou une annulation A11 doit être traduite en mise à jour de l'Encounter existant, et quelqu'un doit décider si une admission annulée devient cancelled ou entered-in-error. Le guide d'implémentation v2-to-FHIR de HL7 (1.0.0, publié en octobre 2025) fournit des correspondances réutilisables par segment et par type de données ; la référence des types de messages HL7 détaille les messages source.
FHIR remplace-t-il HL7 v2 ?
Pas à court terme. FHIR remplace la v2 aux frontières de l'établissement, là où applications, partenaires et autorités demandent des API, et c'est le choix par défaut des nouveaux programmes nationaux. À l'intérieur de l'hôpital, les flux v2 continuent de tourner parce qu'ils sont peu coûteux, rapides et déjà testés, et parce que beaucoup de systèmes départementaux n'ont aucune interface FHIR. Il faut s'attendre à des années de coexistence, avec un moteur d'interfaces qui traduit de l'un à l'autre.
Quand garder HL7 v2 et quand passer à FHIR
Gardez la v2 là où elle fonctionne :
- Les flux à fort volume au sein d'un même établissement (ADT vers le SIL, résultats en retour du laboratoire), stables et supervisés.
- Les systèmes de laboratoire, de radiologie et les dispositifs qui ne parlent que v2.
- Les workflows qui dépendent des acquittements MLLP et d'un ordre strict des messages.
Ajoutez FHIR là où la v2 ne va pas :
- Applications externes, accès patient et intégrations partenaires qui exigent des API authentifiées.
- API réglementées, comme celles des DSE certifiés et des payeurs aux États-Unis.
- Cas d'usage qui demandent des requêtes (« tous les résultats de ce patient depuis janvier ») plutôt que des événements poussés.
- Plateformes de données dans le cloud et nouveaux produits, où le JSON sur HTTPS raccourcit l'intégration d'un partenaire.
L'architecture courante est une façade : la v2 continue d'arriver dans un moteur d'interfaces, qui maintient des ressources FHIR pour les consommateurs d'API. Remplacer des flux v2 qui fonctionnent est rarement rentable en soi. La stratégie de migration v2 vers FHIR traite du séquencement, de la double exécution et des pièges (segments Z, groupes OBX répétés, codes locaux à transcoder).
CDA garde sa place quand un document signé et lisible est l'objectif : lettres de liaison, comptes rendus, dossiers partagés nationaux. FHIR a son propre Bundle document, et de nombreux programmes convertissent désormais de l'un à l'autre ; voir l'échange de documents C-CDA vers FHIR.
Les niveaux d'interopérabilité
L'ONC définit l'interopérabilité comme l'échange et l'usage sécurisés de données de santé électroniques entre utilisateurs autorisés. La HIMSS décrit quatre niveaux, une grille de contrôle utile pour toute interface :
- Fondamental : la donnée passe d'un système à l'autre.
- Structurel : le format est normalisé ; c'est le niveau de la syntaxe v2, CDA et FHIR.
- Sémantique : les deux parties partagent le sens, grâce à des terminologies comme LOINC et SNOMED CT.
- Organisationnel : gouvernance, consentement, conventions et politiques autorisent l'échange.
La plupart des projets d'intégration qui dérapent le font aux niveaux 3 et 4, pas au niveau du parseur.
Les autres normes à connaître
- DICOM est la norme d'imagerie : formats d'objets et services réseau entre modalités, PACS et visionneuses. DICOMweb ajoute des services RESTful (QIDO-RS, WADO-RS, STOW-RS) qui cohabitent bien avec la ressource FHIR ImagingStudy.
- Les profils IHE assemblent des normes en workflows testés : XDS.b pour le partage de documents, PIX et PDQ pour l'identité patient, et des profils fondés sur FHIR comme MHD et PDQm. Voir le catalogue des profils IHE et le guide IHE pour l'intégration en Europe.
- Les terminologies portent le sens dans tous ces formats : LOINC pour les analyses et observations, SNOMED CT pour les constats cliniques et les actes (vérifiez les conditions de licence nationales), ainsi que la CIM-10 pour la classification et UCUM pour les unités.
- openEHR spécifie des entrepôts de données cliniques fondés sur des archétypes. Il répond à une question de stockage et de modélisation, FHIR à une question d'échange, et les deux sont souvent combinés. Voir openEHR et le comparatif openEHR et FHIR.
Pour commencer
- Lisez un vrai message v2 segment par segment, puis les ressources FHIR qu'il doit produire.
- Lancez un serveur FHIR en local (HAPI FHIR est un point de départ courant) et pratiquez la recherche, les transactions et la validation.
- Construisez une interface dans un moteur comme Mirth Connect : MLLP en entrée, FHIR en sortie, avec acquittements et files d'erreurs.
- Apprenez les terminologies de votre domaine avant les formats ; la plupart des erreurs de mapping sont des erreurs de terminologie.
- Posez vos questions sur chat.fhir.org, où répondent des membres des groupes de travail HL7.
Si vous devez décider quelles interfaces garder en v2 et lesquelles exposer en FHIR, le service d'interopérabilité en santé numérique couvre ce type de revue d'architecture.