Standards

Les standards d'interopérabilité en santé : la carte complète (FHIR, HL7 v2, CDA, DICOM, IHE, openEHR, OMOP)

Carte des standards données santé : HL7 v2, CDA, FHIR, DICOM/DICOMweb, IHE, openEHR, OMOP. Comprenez leur rôle, usage en 2026 et lequel choisir.

par Publié 8 min de lecture

Réponse courte : les données de santé circulent à travers quatre couches de normes. Les normes d'échange transportent les données entre les systèmes : messages HL7 v2, documents CDA, ressources FHIR et DICOM pour les images. Les normes de modélisation et de stockage définissent la structure d'un dossier à l'intérieur d'un système : openEHR pour les dossiers cliniques, OMOP pour les bases de données de recherche. Les terminologies attribuent à chaque concept un code que les deux parties comprennent : SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Les normes d'identité et de sécurité déterminent qui peut lire quoi : OAuth 2.0 et SMART on FHIR, ainsi que les profils IHE qui combinent tout ce qui précède en recettes éprouvées. Personne n'utilise une seule norme ; un hôpital utilise généralement les quatre couches simultanément.

La carte

Les normes d'interopérabilité des soins de santé forment quatre couches. Les normes d'échange (HL7 v2, CDA, FHIR, DICOM et DICOMweb) déplacent les données entre les systèmes, et les profils IHE les combinent en recettes testées. openEHR structure l'enregistrement stocké et OMOP structure les bases de données de recherche. Des terminologies telles que SNOMED CT et LOINC, et des normes d'identité telles que SMART on FHIR, sont utilisées à l'intérieur de toutes ces normes.

Couche Norme Qu'est-ce que c'est Où la rencontrer en 2026
Échange HL7 v2 Messages délimités par des pipes (ADT, ORU, ORM, SIU) sur MLLP À l'intérieur des hôpitaux : admissions, résultats de laboratoire, commandes, planification. Toujours l'interface la plus courante
Échange CDA / C-CDA Documents cliniques XML avec une partie lisible par l'homme et des entrées codées Rapports de sortie, lettres de référence, le C-CDA américain, résumés transfrontaliers dans MyHealth@EU
Échange FHIR (R4, R4B, R5) Ressources web (Patient, Observation, Condition…) sur REST et JSON Applications patient, API nationales, API EHR, US Core, le format d'échange EHDS
Échange DICOM et DICOMweb Objets image avec métadonnées intégrées ; DICOMweb est son interface REST Chaque scanner, PACS et visionneuse de radiologie ; les visionneuses web utilisent DICOMweb
Recettes Profils IHE Combinaisons testées des éléments ci-dessus pour un cas d'utilisation (XDS, PIX/PDQ, XCA, SWF) Partage de documents entre hôpitaux et régions, identité du patient, flux de travail radiologique
Stockage openEHR Modèle de données cliniques basé sur des archétypes pour le dossier lui-même Plateformes EHR hospitalières et nationales dans certaines parties de l'Europe, de la Scandinavie, du Brésil
Recherche OMOP CDM Un modèle relationnel commun pour la recherche observationnelle Réseaux de recherche, preuves du monde réel, utilisation secondaire EHDS
Terminologie SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM Codes pour les découvertes, les tests, les diagnostics, les médicaments, les unités À l'intérieur de chacune des normes ci-dessus
Identité OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA Qui est l'utilisateur et à quoi l'application peut accéder Chaque application destinée aux patients et chaque plateforme d'application EHR

Comment les couches s'articulent

Les couches des normes d'interopérabilité des soins de santé s'articulent en ce que chacune effectue une tâche dans le même flux de travail : un message HL7 v2 transporte une demande de laboratoire, LOINC et UCUM codent le résultat, une plateforme openEHR le stocke, une API FHIR le sert à une application patient après une connexion SMART on FHIR, et un document CDA le partage avec un autre hôpital.

Une analyse de sang met en évidence les quatre couches en un après-midi. La commande quitte le service sous forme de message HL7 v2 ORM (échange). Le résultat de l'analyseur revient sous forme de HL7 v2 ORU, avec le test codé en LOINC et l'unité en UCUM (terminologie). L'hôpital le stocke dans sa propre base de données, peut-être une plateforme openEHR (stockage). L'application du patient la lit via une API FHIR en tant qu'Observation, après que le patient se soit connecté avec SMART on FHIR (identité). Si l'hôpital partage le rapport complet avec un autre hôpital, il peut le faire sous forme de document CDA via un registre IHE XDS. Si le résultat rejoint plus tard une cohorte de recherche, il est converti en OMOP.

Les normes ne sont pas des concurrentes. Chacune a été conçue pour une tâche différente, et remplacer l'une par l'autre signifie généralement reconstruire quelque chose qui fonctionne déjà.

Laquelle avez-vous besoin ?

La norme d'interopérabilité des soins de santé dont vous avez besoin dépend de la tâche : FHIR R4 avec SMART on FHIR pour les applications patient ou clinicien, HL7 v2 pour la connexion aux systèmes hospitaliers existants, DICOM et DICOMweb pour les images, des documents CDA ou FHIR pour des documents complets, openEHR pour le stockage d'enregistrements à long terme, OMOP pour la recherche, et les profils IHE lorsque deux systèmes doivent se comporter de manière identique.

  • Vous créez une application pour les patients ou les cliniciens : FHIR R4, avec les profils de votre marché (guides d'implémentation), SMART on FHIR pour la connexion.
  • Vous vous connectez aux systèmes existants d'un hôpital : attendez-vous d'abord à du HL7 v2 ; FHIR là où le fournisseur le propose. Voir Messages HL7 v2 expliqués.
  • Vous gérez des images : DICOM pour le stockage et le transfert, DICOMweb pour tout ce qui est dans un navigateur, FHIR ImagingStudy uniquement pour les métadonnées. Voir DICOMweb expliqué et ImagingStudy vs DICOMweb.
  • Vous échangez des documents complets (résumés, lettres) : CDA là où il est obligatoire, documents FHIR (un Bundle de type document) là où vous pouvez choisir. Voir CDA et C-CDA expliqués.
  • Vous concevez la manière dont un dossier est stocké pendant des décennies : openEHR, avec FHIR comme couche d'échange. Voir openEHR vs FHIR.
  • Vous menez des recherches sur de nombreux dossiers : OMOP, avec FHIR comme source. Voir Utilisation secondaire des données de santé.
  • Vous avez besoin que deux systèmes se comportent de la même manière : choisissez le profil IHE pour votre cas d'utilisation et testez-le.

Où se situe Anpheros

La plateforme Anpheros se situe dans la couche d'échange de la carte des normes en tant que serveur FHIR R4 avec accès OAuth 2.0 et webhooks pour les notifications de changement, recevant les résultats de laboratoire via un connecteur à partir de HL7 v2 ORU, CSV ou JSON. Elle ne stocke pas les images DICOM et n'offre pas de service CDS Hooks ; ceux-ci restent dans les systèmes hospitaliers.

Anpheros Platform est un serveur FHIR R4 avec les ressources nécessaires à un dossier centré sur le patient (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance et autres), OAuth 2.0 pour l'accès, et des webhooks pour les notifications de changement. Les résultats de laboratoire arrivent via le connecteur de laboratoire depuis HL7 v2 ORU, CSV ou JSON. Il ne stocke pas d'images DICOM et n'offre pas de service CDS Hooks ; ceux-ci restent dans les systèmes de l'hôpital, et le dossier y fait référence.

Ordre de lecture

Un bon ordre de lecture pour les normes d'interopérabilité des soins de santé commence par ce qu'est FHIR et en quoi il diffère de HL7 v2, puis la ressource FHIR Observation, puis les terminologies LOINC et SNOMED CT utilisées en son sein, puis DICOMweb pour les images, CDA pour les documents et enfin openEHR comparé à FHIR pour la manière dont les enregistrements sont stockés.

Si vous êtes nouveau dans le domaine : Ce qu'est FHIR → HL7 vs FHIR → FHIR Observation → LOINC et SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.

Pages associées

Sources

Questions fréquentes

FHIR remplace-t-il toutes les autres normes ?

Non. FHIR remplace les API personnalisées et, lentement, certains échanges de documents CDA. HL7 v2 reste le cheval de bataille à l'intérieur des hôpitaux, DICOM reste la seule norme pour les images, et openEHR et OMOP répondent à des questions (stockage, recherche) pour lesquelles FHIR n'a pas été conçu.

Quelle est la différence entre une norme et un profil IHE ?

Une norme telle que FHIR ou DICOM définit des blocs de construction. Un profil IHE sélectionne des blocs spécifiques, fixe leurs options et indique exactement comment les systèmes doivent les utiliser pour une tâche donnée, de sorte que deux fournisseurs qui réussissent les tests IHE puissent travailler ensemble sans projet.

Quelles normes les systèmes de santé nationaux utilisent-ils ?

La plupart des systèmes européens ont commencé avec des documents CDA et HL7 v2, et ajoutent des API FHIR ; le format d'échange EHDS est basé sur FHIR et l'IPS. Les États-Unis imposent FHIR US Core pour l'accès des patients et C-CDA pour l'échange de documents.

Où se situent SNOMED CT et LOINC ?

Ce ne sont pas des normes d'échange ; ce sont des vocabulaires utilisés à l'intérieur de toutes ces normes. Un code LOINC identifie le test dans un segment OBX HL7 v2, une entrée CDA et une Observation FHIR de manière similaire.

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.

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 →