L'EEHRxF est le format européen dans lequel les dossiers médicaux électroniques doivent pouvoir émettre et lire six catégories prioritaires de données de santé, au sein d'un État membre comme par-delà les frontières. Il réunit des ensembles de données harmonisés, des systèmes de codage et des spécifications techniques ; un DPI doit pouvoir l'exporter et l'importer, mais n'est pas obligé de l'utiliser en interne. Le règlement EHDS fournit la base juridique ; l'acte d'exécution qui le fixe sur le plan technique n'est pas encore publié. Entre-temps, HL7 Europe publie des guides d'implémentation FHIR qui l'anticipent. L'État membre doit garantir cette émission, de manière échelonnée : à partir de 2029 pour le résumé patient, la prescription électronique et la dispensation électronique, et à partir de 2031 pour l'imagerie, les résultats d'examens et les rapports de sortie.
", "last_verified": "2026-11-05", "verification_outdated": false, "sections": [ { "id": "en-bref", "title": "En bref", "kind": "tekst", "html": "Quoi : l'EEHRxF est le format d'échange européen dans lequel les dossiers médicaux électroniques doivent pouvoir fournir six catégories prioritaires de données de santé, du résumé patient au rapport de sortie[1][2].
\nComment : il comprend des ensembles de données harmonisés, des systèmes de codage et des valeurs, ainsi que des spécifications techniques d'interopérabilité, et il doit être lisible par machine[2].
\nÉtat : l'acte d'exécution qui fixe techniquement le format n'avait, au 27 octobre 2026, pas encore été publié à l'état de projet[1], tandis que HL7 Europe a fait passer, le 16 octobre 2026, le rapport de sortie à une première STU et a mis à jour le rapport de laboratoire de la version 2.0.0 (STU 2, 5 mai 2026) vers la version 2.1.0, avec une modification de rupture, et que le résumé patient et l'imagerie sont restés en ballot[3][4][5][6].
\nPlanning : la Commission prévoit l'adoption au quatrième trimestre de 2026[1], avec le 26 mars 2027 comme date limite légale[2] ; les obligations elles-mêmes s'appliquent à partir de 2029 et de 2031[2].
\nHôpital : un DPI doit pouvoir exporter et importer le format mais n'est pas obligé de l'utiliser en interne[7] ; quiconque a construit son échange de laboratoire sur Laboratory Report 2.0.0 doit revalider, parce que la version 2.1.0 rend invalides certaines instances auparavant valides[4].
\nPrincipale incertitude : sans projet publié, on ne sait pas si l'acte d'exécution renverra aux guides de HL7 Europe ou aux modèles logiques Xt-EHR[1][8].
\nL'EEHRxF est le format d'échange européen pour les dossiers médicaux électroniques issu du règlement EHDS\n(EHDS (Espace européen des données de santé)). Au plus tard le 26 mars 2027, la Commission doit fixer par des actes d'exécution, pour les\ncatégories prioritaires, les spécifications techniques qui forment ensemble l'EEHRxF[2] ; le\ntexte néerlandais authentique de l'article 15(1) emploie à cet effet le terme « Europees uitwisselingsformat\nvoor elektronische patiëntendossiers »[9], que l'on retrouve également dans les documents\nnéerlandophones de la Commission[1]. En français, la Commission utilise « format européen\nd'échange des dossiers médicaux électroniques »[1]. Le format doit être lisible par machine,\nprendre en charge des données structurées et non structurées, et comprend des ensembles de données\nharmonisés, des systèmes de codage et des valeurs, ainsi que des spécifications techniques\nd'interopérabilité : il désigne donc des spécifications techniques au lieu d'en être une lui-même\n[2].
\nLes États membres doivent veiller à ce que les catégories prioritaires soient émises dans l'EEHRxF ; lorsque\nles données sont transmises par des procédés automatisés, le prestataire de soins destinataire accepte le\nformat et est en mesure de le lire[2]. L'échange via MaSanté@UE (MyHealth@EU) repose sur l'EEHRxF\n[2]. L'acte d'exécution prévu couvre l'ensemble des six catégories prioritaires : résumé\npatient, prescription électronique, dispensation électronique, imagerie avec comptes rendus, résultats\nd'examens y compris de laboratoire et rapports de sortie[1].
" }, { "id": "comment-est-il-structure", "title": "Comment est-il structuré ?", "kind": "tekst", "html": "Base légale et échelonnement. L'EEHRxF (art. 15) s'applique à partir du 26 mars 2029 pour le résumé patient, la prescription électronique et la dispensation électronique, et à partir du 26 mars 2031 pour l'imagerie, les résultats d'examens et les rapports de sortie[2]. L'acte d'exécution ne devient applicable qu'à ces dates échelonnées[2]. La Commission elle-même cite mars 2027 comme date limite pour l'adoption de plusieurs actes d'exécution clés[10] et mars 2031 comme le moment où l'échange des images médicales, des résultats de laboratoire et des rapports de sortie d'hôpital devrait être opérationnel dans tous les États membres[10].
\nStatut de l'acte d'exécution. Au 27 octobre 2026, la phase de projet (REG_IMPL_DRAFT) de l'initiative Have your say 17512 est toujours sur « UPCOMING » : aucun projet n'a été publié pour commentaires[1]. L'initiative s'appuie sur l'article 15(1) du règlement (UE) 2025/327 et est attribuée au comité C131500[1]. La Commission prévoit toujours l'adoption au quatrième trimestre de 2026 (planification, pas une décision)[1] ; HL7 Europe s'attendait à ces actes début 2027[11]. Le projet de règlement MaSanté@UE renvoyait au règlement EEHRxF comme à un acte encore à adopter[12]. Les deux actes qui s'y rattachent directement se font eux aussi attendre : les common specifications pour les composants logiciels harmonisés des systèmes de DME (initiative 18579, article 36(1))[13] et celles relatives à l'environnement d'essai numérique européen (17513)[14] sont toutes deux sur « UPCOMING » (voir Actes d'exécution de l'EHDS (état des lieux)). Les EHDS Logical Information Models de Xt-EHR (1.0.0) constituent la base de la conception de l'EEHRxF, mais peuvent encore changer pendant la procédure de comitologie et ne sont donc pas une spécification légale arrêtée[8]. Le projet de consultation Xt-EHR D7.2 (septembre 2025) indique qu'il donne des orientations sur les normes internationales largement utilisées à employer, \"such as HL7 FHIR, DICOM, IHE Integration profiles, LOINC, SNOMED CT and other international code systems\"[15]. Il s'agit d'une énumération d'exemples dans un document de consultation, non d'une prescription ; la page n'en déduit donc aucune relation vers DICOM (avec DICOMweb), LOINC et le sous-ensemble belge (ReTaM) ou SNOMED CT (interprétation, voir la question ouverte).
\nHistorique. La recommandation (UE) 2019/243 pose les bases, et le règlement y renvoie expressément[2]. La baseline de cette recommandation s'appuyait, pour le résumé patient et la prescription électronique, sur HL7 CDA R2[16], mais demandait déjà d'envisager FHIR[16]. La Commission s'attend à ce que les spécifications s'appuient sur la Joint Action Xt-EHR, qui s'appuie elle-même sur XpanDH, x-eHealth, epSOS et la recommandation[7].
\nGuides d'implémentation HL7 Europe (pas une spécification légale). Les IG de HL7 Europe sont alignés sur le modèle logique de Xt-EHR[11]. État au 27 octobre 2026, selon la package-list de chaque guide :
\n| IG | \nVersion et statut | \nSource | \n
|---|---|---|
| Base and Core | \n2.0.1, STU 2, 13 septembre 2026 (correction technique de 2.0.0) ; les premiers IG Base et Core (R4 et R5) ont paru à l'automne 2025 | \n[17][11] | \n
| Laboratory Report | \n2.1.0, STU 2, 16 octobre 2026 ; publication précédente 2.0.0 du 5 mai 2026 | \n[4] | \n
| Medication Prescription and Dispense | \n1.0.0, première STU, 11 mai 2026 | \n[18] | \n
| Hospital Discharge Report | \n1.0.0, première STU (STU 1), 16 octobre 2026 ; publication précédente 0.1.0-ballot du 3 juin 2025 | \n[3] | \n
| Imaging Report (FHIR R4) | \n1.0.0-ballot, 16 mars 2026 ; aucune publication STU trouvée | \n[6] | \n
| Imaging Report (FHIR R5) | \n1.0.0-ballot, 20 mars 2026 ; guide distinct à côté de la variante R4 | \n[19] | \n
| European Patient Summary | \n1.0.0-ballot, 6 juin 2026 ; ballot ouvert le 17 juin 2026, commentaires jusqu'au 31 août 2026 ; aucune publication STU trouvée | \n[5][20] | \n
L'IG Hospital Discharge Report veut fixer une spécification européenne commune pour le rapport de sortie et poser ainsi la base de l'EEHRxF, pour la catégorie prioritaire « rapports de sortie d'hôpital » de l'article 14 du règlement EHDS[21] ; HL7 Europe veut que ce guide serve aussi de base aux guides nationaux européens et donc à MaSanté@UE[21]. La même ambition figure dans l'IG European Patient Summary[22], qui vise la conformité avec l'IPS international[23]. Tant que l'acte d'exécution n'est pas arrêté, aucun de ces guides n'est une spécification légale de l'EEHRxF[1].
\nModification de rupture dans Laboratory Report 2.1.0. La version 2.1.0 aligne les mappings de modèles sur la version 1.0.0 des Xt-EHR EHDS logical models et met à jour les dépendances vers HL7 Europe Base 2.0.1 et Extensions 1.3.1[4]. Certaines de ces modifications rendent invalides des instances qui étaient valides sous la version 2.0.0 ; le journal des modifications les signale[4].
\nLa maturité des guides ne suit pas l'échelonnement légal (interprétation) : Hospital Discharge Report et Laboratory Report relèvent des catégories de 2031 et sont tous deux en STU[3][4][2], tandis que l'European Patient Summary — une catégorie de 2029 — est encore en ballot[5] ; Medication Prescription and Dispense (également 2029) est bien en STU[18] et l'imagerie (2031) est en ballot dans les deux variantes FHIR[6][19]. Quiconque planifie pour 2029 ne peut donc pas compter sur un IG stable pour le résumé patient.
" }, { "id": "ou-est-il-utilise", "title": "Où est-il utilisé ?", "kind": "tekst", "html": "En Belgique, la plate-forme eHealth coordonne l'usage primaire[24]. La\nBelgique plaide pour un standard FHIR européen unique par type de message[24] et, par champ, pour\nun seul ensemble de valeurs européen, de préférence sur la base de SNOMED CT, LOINC et le sous-ensemble belge (ReTaM), DICOM et ISO\n[24]. La Belgique choisit d'utiliser les champs des types de messages européens également dans les\ncaresets belges, et de créer un message au plus près de la source, pour les informations disponibles dans le\nDPI par le logiciel du DPI[24] (voir Guides d'implémentation FHIR belges). La roadmap EHDS de la plate-forme eHealth\n(version du 20 mai 2026) place l'imagerie médicale dans la Wave 2 (2031), avec les hubs comme source\nauthentique et le statut « Analysis in Progress », sans date d'approbation ou de mise en œuvre\n[25] ; dans cette même roadmap, les rapports de sortie relèvent également des hubs\n[25] (voir BIHR (Belgian Integrated Health Record)). En vertu du règlement d'exécution (UE) 2026/2083, les États membres sont\nresponsables de la traduction et de la correspondance des systèmes de codage et des ensembles de valeurs vers\nl'EEHRxF[26] (il existe une incertitude sur la date d'application de 2026/2083, voir\nMaSanté@UE (MyHealth@EU)) ; les points de contact peuvent utiliser à cet effet le service central de terminologie de\nla Commission\n[26] (voir aussi Serveur national de terminologie (FHIR)).
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "Obligation (règlement) :\n- Les catégories prioritaires sont émises dans l'EEHRxF, et le prestataire de soins destinataire doit, en cas d'envoi automatisé, accepter le format et être en mesure de le lire (art. 15(4) ; obligation que l'État membre doit garantir, échelonnée 2029/2031)[2].\n- Un système de DME doté d'une saisie structurée doit permettre une saisie d'une granularité suffisante pour pouvoir fournir les données dans l'EEHRxF (annexe II)[2].\n- Le règlement impose en outre aux systèmes de DME deux composants logiciels harmonisés, un composant d'interopérabilité et un composant de journalisation, pour lesquels la Commission doit encore arrêter des common specifications[13].
\nSelon la FAQ de la Commission (document interprétatif, pas un texte législatif) :\n- Les hôpitaux doivent pouvoir exporter et importer des données dans l'EEHRxF ; le choix entre une mise à niveau du DPI et un système de traduction leur est laissé[7]. Le DPI n'est pas tenu d'utiliser l'EEHRxF en interne[7].\n- Un système qui convertit en EEHRxF la sortie de systèmes hérités est lui-même un système de DME[7] ; quiconque construit ou gère un tel composant de traduction peut avoir des obligations de fabricant (voir EHDS (Espace européen des données de santé)).
\nCe qu'il est déjà possible de faire :\n- Pour les rapports de laboratoire, il existe depuis le 5 mai 2026 une spécification STU sur laquelle s'exercer, et depuis le 16 octobre 2026 en version 2.1.0[4] ; pour les rapports de sortie, depuis le 16 octobre 2026[3] ; pour le résumé patient, qui doit déjà fonctionner à partir de 2029, pas encore[5][2].\n- Quiconque a construit son échange de laboratoire sur Laboratory Report 2.0.0 doit tenir compte des instances qui ne sont plus valides sous 2.1.0[4], et des nouvelles dépendances vers Base 2.0.1 et Extensions 1.3.1[4][17].
\nRecommandation : planifiez les catégories de 2029 (résumé patient, médication) avant celles de 2031 (labo, imagerie, lettre de sortie), utilisez les versions STU de HL7 Europe comme matière d'exercice technique mais ne les traitez pas comme une exigence définitive, inscrivez au planning une revalidation du labo par rapport à 2.1.0, et demandez aux fournisseurs si un composant de traduction relève de leur marquage CE ou est géré par l'hôpital lui-même.
\n