Les profils IHE de partage de documents décrivent comment les institutions de soins enregistrent, recherchent et récupèrent des documents relatifs à un patient. XDS.b le fait au sein d'un groupe d'institutions qui collaborent, XCA et XCPD entre de tels groupes, XDR et XDM en cas d'envoi direct ou via un support. PIX et PDQ règlent l'identification du patient ; ATNA, XUA, CT et BPPC la sécurité, l'identité de l'utilisateur, l'heure et le consentement ; MHD offre une API légère sur FHIR. Le logiciel de référence européen pour MaSanté@UE utilise XCPD, XCA et XDR. Les hubs belges fonctionnent avec des services web KMEHR ; le Brusafe+ bruxellois utilisait XDS.
", "last_verified": "2026-11-09", "verification_outdated": false, "sections": [ { "id": "en-bref", "title": "En bref", "kind": "tekst", "html": "Les profils IHE de partage de documents sont des spécifications d'IHE dans le domaine IT Infrastructure (ITI). Comme tout profil IHE, chacun définit les acteurs, les transactions et le contenu informationnel d'un cas d'usage en renvoyant à des normes existantes.[14] Le profil central est XDS.b (Cross-Enterprise Document Sharing) : il règle l'enregistrement, la diffusion et la consultation des dossiers électroniques de patients d'une institution de soins à l'autre, du cabinet médical à l'hôpital de soins aigus.[1]
\nDeux notions portent l'ensemble du système. Un XDS Affinity Domain est un groupe d'institutions de soins qui appliquent des accords communs et partagent une infrastructure.[1] Une communauté (community) au sens de XCA est un groupe d'institutions ayant des accords communs pour le partage d'informations cliniques, identifiable par un homeCommunityId unique au niveau mondial.[3] XDS fonctionne au sein d'une communauté ; les profils cross-community font le pont entre communautés, par exemple entre pays.[2][3]
\n| Profil | \nCe qu'il règle | \nStade | \nPreuve | \n
|---|---|---|---|
| XDS.b | \nenregistrer, diffuser et consulter des documents au sein d'un affinity domain | \nfinal text | \n[1] | \n
| XCA (Cross-Community Access) | \ninterroger d'autres communautés et y récupérer des données de patients | \nfinal text | \n[3] | \n
| XCPD (Cross-Community Patient Discovery) | \ntrouver les communautés qui détiennent des données sur un patient et traduire les identifiants | \nfinal text | \n[2] | \n
| XDR (Document Reliable Interchange) | \nenvoyer directement des documents et des métadonnées pour un seul patient, même sans XDS | \nfinal text | \n[15] | \n
| XDM (Document Media Interchange) | \ndocuments par CD, clé USB ou courriel dans une structure de dossiers fixe | \nfinal text | \n[16] | \n
| PIX (Patient Identifier Cross-referencing) | \nrelier entre eux des identifiants de patient issus de plusieurs domaines | \nfinal text | \n[17] | \n
| PDQ (Patient Demographics Query) | \ninterroger un serveur central de patients sur des données démographiques | \nfinal text | \n[18] | \n
| ATNA (Audit Trail and Node Authentication) | \nauthentification des nœuds et des utilisateurs, journalisation d'audit, chiffrement | \nfinal text | \n[4] | \n
| XUA (Cross-Enterprise User Assertion) | \ntransmettre des assertions sur l'utilisateur dans les transactions entre institutions | \nfinal text | \n[19] | \n
| CT (Consistent Time) | \nsynchroniser les horloges avec une erreur médiane inférieure à une seconde | \nfinal text | \n[20] | \n
| BPPC (Basic Patient Privacy Consents) | \ncodes de politique de confidentialité au sein d'un affinity domain | \nfinal text | \n[21] | \n
| MHD (Mobile access to Health Documents) | \nune API standardisée unique pour le partage de documents, sur FHIR | \ntrial implementation | \n[22][5] | \n
| PIXm et PDQm | \néquivalents RESTful de PIX et PDQ pour des applications légères | \ntrial implementation | \n[23][24][5] | \n
| APPC et RESTful ATNA | \nconsentement avancé ; interrogation et flux ATNA via REST | \ntrial implementation | \n[5] | \n
| mXDE | \nrendre interrogeables des éléments de données individuels issus de documents partagés (MHD avec QEDm) | \ntrial implementation | \n[22][5] | \n
PIX relie entre eux des identifiants de patient issus de plusieurs domaines d'identification, mais ne prescrit lui-même ni politique d'institution ni algorithme de liaison ; cela reste du ressort du Patient Identifier Cross-reference Manager et de l'institution.[17][17] PDQ permet à des applications d'interroger un serveur central de patients selon des critères de recherche et de récupérer directement les données démographiques d'un patient.[18] ATNA fixe les bases de la sécurité : authentification des nœuds et des utilisateurs, journalisation d'audit et chiffrement des communications.[4] De nombreux autres profils IHE exigent ou recommandent de grouper leurs acteurs avec des acteurs ATNA.[4] XUA transmet, dans les transactions entre institutions, des assertions sur un utilisateur ou une application authentifiés, de sorte que le destinataire puisse décider de l'accès et réaliser un audit correct.[19] CT synchronise les horloges des ordinateurs d'un réseau, ce qui rend l'audit et les horodatages comparables.[20] BPPC permet à un affinity domain de fixer un vocabulaire de base de codes de politique de confidentialité et prend en charge aussi bien le consentement présumé que le consentement explicite.[21][21]
\nMHD définit une API standardisée unique pour le partage de documents, destinée aux applications mobiles et autres applications légères.[22] Il peut servir d'API au-dessus d'un environnement de partage de documents utilisant XDS ou XCA, ou de mécanisme push à côté de XDR et XDM.[22] MHD repose sur HL7 FHIR : la version publiée actuelle, 4.2.5, s'appuie sur FHIR R4.[22] mXDE combine MHD avec le profil QEDm, de sorte que des éléments de données individuels issus de documents partagés deviennent interrogeables.[22]
" }, { "id": "comment-est-ce-structure", "title": "Comment est-ce structuré ?", "kind": "tekst", "html": "Les profils figurent dans l'IHE IT Infrastructure Technical Framework, qui, comme tout framework de domaine, est élaboré par le comité technique du domaine.[25] Les profils normatifs en final text figurent dans la révision 20, mise à jour en dernier lieu jusqu'à la révision 20.2 le 11 novembre 2025.[5] Un nouveau contenu paraît d'abord sous la forme d'un supplément qui passe par les stades public comment, trial implementation et final text, et dès qu'une spécification est en final text, la gouvernance d'IHE interdit les modifications incompatibles.[26][26] IHE met les spécifications librement à disposition sous une licence Creative Commons.[27]
\nLes profils mobiles sont encore des suppléments en trial implementation. MHD 4.2.5 pour FHIR R4 a été révisé pour la dernière fois le 18 octobre 2026, et MHD 5.0.0 pour FHIR R5 a été publié le 19 décembre 2025.[5][5] PDQm 3.2.0 et PIXm 3.1.0 ont tous deux été révisés le 6 novembre 2025.[5] RESTful ATNA (révisé le 25 novembre 2025) et APPC (révisé le 2 juillet 2021) sont également en trial implementation, tout comme mXDE (révisé le 4 août 2023).[5][5]
\nLa décision (UE) 2015/1302 rend les profils IHE de son annexe éligibles comme référence dans les marchés publics.[28] Cette annexe commence par XCPD, XCA, XCF et XDR, comprend aussi CT, ATNA, BPPC et XUA, et ensuite PIX, PDQ, XDS.b, XDS-I.b et XDM.[28][28][28][28]
" }, { "id": "ou-est-ce-utilise", "title": "Où est-ce utilisé ?", "kind": "tekst", "html": "| Contexte | \nProfils | \nÉtat | \nPreuve | \n
|---|---|---|---|
| epSOS (précurseur de MaSanté@UE) | \nXCPD, XCA, XDR, XCF facultatif | \nhistorique | \n[29] | \n
| MaSanté@UE, mise en œuvre de référence OpenNCP | \nXCPD, XCA, XDR, piste d'audit ATNA ; services FHIR en complément | \nproduction (logiciel de référence de la Commission) | \n[6][6][6] | \n
| Système belge hubs-métahub | \nservices web KMEHR, pas de partage de documents IHE trouvé | \nproduction | \n[8][30] | \n
| Brusafe+ (Abrumet) | \ncomposants conformes à IHE XDS, passerelle XCA ; MHD en développement (2017) | \na évolué vers FHIR | \n[9][9][10] | \n
| Imagerie | \nXDS-I.b et XCA-I | \nvoir Profils IHE d'imagerie (XDS-I.b, XCA-I, MADO) | \n[31][32] | \n
| Logiciels d'intégration | \nbriques pour XDS, PIX, PDQ et XCPD dans IPF | \nproduit | \n[33] | \n
Dans le projet epSOS, la spécification d'échange reposait sur les profils IHE XCPD, XCA, XDR et, de manière facultative, XCF.[29] OpenNCP, la mise en œuvre de référence du point de contact national, assure l'échange transfrontalier de résumés patients, de prescriptions électroniques, de dispensations électroniques et d'images médicales au moyen de profils IHE, et est maintenu par la Commission européenne (DG SANTE).[6][6] XCPD y sert à l'identification transfrontalière du patient, XCA à la recherche et à la récupération de documents et XDR à leur soumission, et OpenNCP tient une piste d'audit ATNA de chaque opération.[6][6] OpenNCP offre en outre des services FHIR.[6] Le règlement d'exécution (UE) 2026/2083 permet aux points de contact nationaux d'utiliser cette mise en œuvre de référence ; s'ils choisissent une autre solution, celle-ci doit être conforme au catalogue des exigences et aux spécifications techniques.[7] Le projet EU4Health 'Setup BE-NCPeH PS-A' prépare le raccordement de la Belgique à MaSanté@UE ; le logiciel qu'utilise le point de contact belge n'a pas été trouvé.[34]
\nUn travail préparatoire belge a été mené via Bruxelles : la Commission européenne a mandaté Abrumet pour développer sur quatre ans (2018-2021) les faisabilités techniques de l'échange du SUMEHR en Europe, parce qu'Abrumet pouvait proposer un système avec des normes internationales IHE.[35] Le travail technique pour le service PS B (lecture du SUMEHR d'un patient européen en Belgique) a été présenté le 20 décembre 2019 dans le groupe de travail architecture de la Plate-forme eHealth.[35]
\nLes interfaces techniques entre les hubs et avec le métahub sont des services web standard (« services web KMEHR ») dont la Plate-forme eHealth publie les spécifications.[8] L'architecture hub-métahub définit, dans le cadre de KMEHR, deux ensembles d'opérations : intrahub et interhub.[30] Aucun cookbook de la Plate-forme eHealth, de Vitalink, des hubs ou de MyCareNet prescrivant XDS, XCA, XCPD, ATNA ou XUA n'a été trouvé dans les sources traitées. Un projet GitHub, HubsOnFHIR, porte sur la manière dont le système Hubs & Metahub adoptera FHIR.[36] Une implémentation de référence non officielle modernise les transactions interhubs getTransactionList et getTransaction vers IHE MHD sur FHIR R4.[37]
\nSelon la documentation pour développeurs de 2017, l'environnement Brusafe+ utilise des composants conformes à IHE XDS, l'échange entre environnements XDS passe par une passerelle XCA et la communication avec le Réseau Santé Bruxellois repose sur KMEHR.[9][9] Un MHD Document Recipient et un Document Responder étaient alors en développement.[9] Abrumet affirmait en 2020 que l'e-santé belge n'utilise que KMEHR et que Brusafe+ fait le lien avec les standards internationaux via XDS/CDA et un mapping.[38] Le plan d'action e-Santé 2019-2021 décrivait Brusafe+ comme un échange de données structurées selon certains profils IHE reconnus par la Commission européenne ; des projets pouvaient se connecter à Brusafe+ au moyen d'un cookbook en ligne et d'une plateforme de test open source basée sur Gazelle.[39][39] Ce même plan citait le serveur IHE bruxellois, avec le profil XDW, comme référence possible pour les prescriptions et ordonnances électroniques ; il s'agissait d'une proposition.[39] Selon la documentation de 2017, il n'existait en Belgique aucune organisation chargée de maintenir un ensemble de codes commun pour les métadonnées XDS.[40] Le rapport annuel 2025 indique que Brusafe+ était initialement basé sur la norme XDS, a évolué vers la norme FHIR, et que tous les investissements futurs seront concentrés sur FHIR uniquement.[10]
\nLes logiciels d'intégration fournissent les profils sous forme de briques : IPF propose des briques pour des profils IHE tels que XDS, PIX, PDQ et XCPD (voir Apache Camel).[33] Agoria propose depuis 2016 des académies portant notamment sur IHE XDS.[41]
" }, { "id": "planning", "title": "Planning", "kind": "tekst", "html": "Le règlement relatif à l'espace européen des données de santé oblige la Commission à établir au plus tard le 26 mars 2027 l'EEHRxF, avec notamment des spécifications techniques d'interopérabilité, y compris les normes et les profils.[11] Le projet d'EU Health Data API associe chacune des catégories prioritaires résumé patient, résultats d'examens, rapport de sortie et imagerie à un échange de documents via MHD, et laisse le workflow de la prescription électronique et de la dispensation électronique à IHE MPD.[12][12] Ce projet est une proposition de HL7 Europe et d'IHE Europe sur laquelle la Commission et les États membres doivent encore se prononcer.[13]
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "