Fiche de concept · Norme ou spécification
Profils IHE de partage de documents (XDS, XCA, XCPD, MHD et apparentés)
- Norme ou spécification
- normatif
- International
- Union européenne
- Architecture et infrastructure
- Identité, accès et audit
- Consentement et relation thérapeutique
- Échange transfrontalier
Identifiant Atlas ihe-documentdeling · 71 affirmations · 41 sources · Dernière vérification09-11-2026
· Version 2026.11.13-2
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.
En bref
✎ Commenter- Quoi : XDS.b règle l'enregistrement, la diffusion et la consultation des dossiers de patients d'une institution de soins à l'autre, au sein d'un groupe d'institutions partageant des accords et une infrastructure communs.[1][1]
- Comment : XCPD trouve les communautés qui détiennent des données sur un patient, XCA les interroge et les récupère, et ATNA, XUA et BPPC fournissent l'audit, l'identité de l'utilisateur et les codes de consentement.[2][3][4]
- État : les profils en final text figurent dans la révision 20.2 de l'IT Infrastructure Technical Framework (11 novembre 2025) ; MHD 4.2.5 sur FHIR R4 est en trial implementation.[5][5]
- Europe : la mise en œuvre de référence du point de contact national pour MaSanté@UE utilise XCPD, XCA et XDR, mais un point de contact national peut choisir une autre solution conforme.[6][7]
- Belgique : les hubs se connectent via des services web KMEHR ; Brusafe+ d'Abrumet utilisait IHE XDS et, selon le rapport annuel 2025, a évolué vers FHIR.[8][9][10]
- Planning : la Commission doit fixer l'EEHRxF au plus tard le 26 mars 2027, y compris les normes et les profils ; le projet d'EU Health Data API fait passer l'échange de documents par MHD.[11][12]
- Principale incertitude : quels profils IHE les spécifications techniques européennes imposeront finalement n'a pas encore été décidé.[13]
Qu'est-ce que c'est ?
✎ CommenterLes 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]
Deux 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]
| Profil | Ce qu'il règle | Stade | Preuve |
|---|---|---|---|
| XDS.b | enregistrer, diffuser et consulter des documents au sein d'un affinity domain | final text | [1] |
| XCA (Cross-Community Access) | interroger d'autres communautés et y récupérer des données de patients | final text | [3] |
| XCPD (Cross-Community Patient Discovery) | trouver les communautés qui détiennent des données sur un patient et traduire les identifiants | final text | [2] |
| XDR (Document Reliable Interchange) | envoyer directement des documents et des métadonnées pour un seul patient, même sans XDS | final text | [15] |
| XDM (Document Media Interchange) | documents par CD, clé USB ou courriel dans une structure de dossiers fixe | final text | [16] |
| PIX (Patient Identifier Cross-referencing) | relier entre eux des identifiants de patient issus de plusieurs domaines | final text | [17] |
| PDQ (Patient Demographics Query) | interroger un serveur central de patients sur des données démographiques | final text | [18] |
| ATNA (Audit Trail and Node Authentication) | authentification des nœuds et des utilisateurs, journalisation d'audit, chiffrement | final text | [4] |
| XUA (Cross-Enterprise User Assertion) | transmettre des assertions sur l'utilisateur dans les transactions entre institutions | final text | [19] |
| CT (Consistent Time) | synchroniser les horloges avec une erreur médiane inférieure à une seconde | final text | [20] |
| BPPC (Basic Patient Privacy Consents) | codes de politique de confidentialité au sein d'un affinity domain | final text | [21] |
| MHD (Mobile access to Health Documents) | une API standardisée unique pour le partage de documents, sur FHIR | trial implementation | [22][5] |
| PIXm et PDQm | équivalents RESTful de PIX et PDQ pour des applications légères | trial implementation | [23][24][5] |
| APPC et RESTful ATNA | consentement avancé ; interrogation et flux ATNA via REST | trial implementation | [5] |
| mXDE | rendre interrogeables des éléments de données individuels issus de documents partagés (MHD avec QEDm) | trial implementation | [22][5] |
Identification du patient, sécurité et consentement
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]
La variante mobile : MHD
MHD 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]
Comment est-ce structuré ?
✎ CommenterLes 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]
Les 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]
Dans la liste européenne pour les marchés publics
La 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]
Où est-ce utilisé ?
✎ Commenter| Contexte | Profils | État | Preuve |
|---|---|---|---|
| epSOS (précurseur de MaSanté@UE) | XCPD, XCA, XDR, XCF facultatif | historique | [29] |
| MaSanté@UE, mise en œuvre de référence OpenNCP | XCPD, XCA, XDR, piste d'audit ATNA ; services FHIR en complément | production (logiciel de référence de la Commission) | [6][6][6] |
| Système belge hubs-métahub | services web KMEHR, pas de partage de documents IHE trouvé | production | [8][30] |
| Brusafe+ (Abrumet) | composants conformes à IHE XDS, passerelle XCA ; MHD en développement (2017) | a évolué vers FHIR | [9][9][10] |
| Imagerie | XDS-I.b et XCA-I | voir Profils IHE d'imagerie (XDS-I.b, XCA-I, MADO) | [31][32] |
| Logiciels d'intégration | briques pour XDS, PIX, PDQ et XCPD dans IPF | produit | [33] |
Transfrontalier : MaSanté@UE
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]
Un 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]
En Belgique : les hubs et Brusafe+
Les 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]
Selon 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]
Logiciels et formation
Les 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]
Planning
✎ CommenterLe 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]
Qu'est-ce que cela signifie pour un hôpital ?
✎ Commenter- Obligation : aucune règle belge imposant à un hôpital un profil IHE de partage de documents n'a été trouvée dans les sources traitées ; l'échange national via les hubs passe par des services web KMEHR.[8]
- Achats : XDS.b, XCA, XCPD, XDR, XDM, PIX, PDQ, ATNA, XUA, CT et BPPC sont éligibles depuis 2015 comme référence dans les marchés publics.[28][28][28]
- Transfrontalier : ce qu'un hôpital atteint via MaSanté@UE passe, dans le logiciel de référence, par XCPD, XCA et XDR au niveau du point de contact national, et non directement depuis l'hôpital.[6][6]
- Avenir : le projet européen place MHD sur FHIR au centre de l'échange de documents, mais ce n'est pas encore décidé.[12][13]
- Recommandation (propre) : demandez aux fournisseurs de DPI, de PACS et de logiciels d'intégration quels acteurs de XDS.b, XCA, PIX/PDQ, ATNA et MHD leur produit prend en charge et si MHD sur FHIR R4 figure dans leur feuille de route ; un raccordement ultérieur à un canal européen ou basé sur FHIR reste ainsi possible sans remplacer la gestion documentaire.
Incertitudes et informations contradictoires
✎ Commenter- Choix européen des profils ouvert : le règlement d'exécution admet des alternatives conformes au logiciel de référence, et les profils du catalogue des exigences et des spécifications techniques n'ont pas été trouvés.[7]
- Statut de Brusafe+ : la documentation de 2017 décrit XDS et une passerelle XCA, le rapport annuel 2025 une évolution vers FHIR ; la question de savoir si des composants XDS fonctionnent encore n'a pas été établie.[9][10]
- MHD non officiel en Belgique : la modernisation MHD des transactions interhubs est une implémentation de référence non officielle, et non une spécification publiée par la Plate-forme eHealth.[37]
- Point de contact belge : le logiciel, et donc les profils, qu'utilise le point de contact belge n'ont pas été trouvés.[34]
Relations 7 relations · 1 hypothèse
Type de relation tous
Statut tous
| Relation | Concept cible | Type | Statut | Précision |
|---|---|---|---|---|
| relève de | IHE (Integrating the Healthcare Enterprise) | Organisation | établi | IHE publiceert de profielen in het IT Infrastructure Technical Framework; het technische comité van dat domein werkt ze ook uit. [5][25] |
| dépend de | HL7 FHIR | Norme ou spécification | établi | Geldt voor het mobiele profiel MHD (4.2.5 op FHIR R4, 5.0.0 op FHIR R5). [22][5] |
| est comparé à | Hubs & Metahub (répertoire des références) | Plateforme ou service | établi | Het Belgische hub-metahubsysteem gebruikt KMEHR-webservices; Brusafe+ sloeg met XDS/CDA en een mapping een brug naar internationale standaarden. [8][38] |
| implémente (entrant) | Réseau Santé Bruxellois (Abrumet) | Plateforme ou service | établi | [9][10] |
| implémente (entrant) | MaSanté@UE (MyHealth@EU) | Plateforme ou service | établi | [6][7] |
| dépend de (entrant) | EEHRxF (format européen d'échange des dossiers de santé informatisés) | Norme ou spécification | hypothèse | [12][13] |
| dépend de (entrant) | Profils IHE d'imagerie (XDS-I.b, XCA-I, MADO) | Norme ou spécification | établi | [32] |
Questions ouvertes 6
- Welke IHE-profielen schrijven de technische specificaties en de requirements catalogue van MyHealth@EU onder Uitvoeringsverordening (EU) 2026/2083 voor, en zijn die publiek? Aidez-nous à répondre à cette question
- Gebruikt het Belgische nationale contactpunt (project Setup BE-NCPeH PS-A) OpenNCP of een eigen implementatie, en dus XCPD, XCA en XDR? Aidez-nous à répondre à cette question
- Zal de uitvoeringshandeling over het EEHRxF (art. 15 EHDS) MHD, PDQm of andere IHE-profielen bij naam opleggen, zoals het ontwerp van de EU Health Data API voorstelt? Aidez-nous à répondre à cette question
- Ondersteunt de Belgische FHIR-modernisering van de interhubdiensten (HubsOnFHIR) MHD, of een eigen profiel? Aidez-nous à répondre à cette question
- Draait Brusafe+ vandaag nog deels op XDS, of is het volledig naar FHIR overgegaan? Aidez-nous à répondre à cette question
- Noemen de EHDS-verordening en de uitvoeringsverordeningen 2026/2083 en 2026/2099 IHE ergens bij naam, of laten ze de profielkeuze volledig aan de technische specificaties? Aidez-nous à répondre à cette question
Sources 41 sources · toutes les sources
- ITI TF Vol. 1 - 10 Cross-Enterprise Document Sharing (XDS.b). IHE International.
SRC-e2a1a566eeLien cassé ? - ITI TF Vol. 1 - 27 Cross-Community Patient Discovery (XCPD). IHE International.
SRC-82a460cfb4Lien cassé ? - ITI TF Vol. 1 - 18 Cross-Community Access (XCA). IHE International.
SRC-0fe2b95777Lien cassé ? - ITI TF Vol. 1 - 9 Audit Trail and Node Authentication (ATNA) Profile. IHE International.
SRC-0c3b6c1d28Lien cassé ? - IT Infrastructure (ITI) Domain. IHE International.
SRC-c8de2ba61aLien cassé ? - MyHealth@EU OpenNCP - README. Europese Commissie (DG SANTE).
SRC-a97a9d1bb7Lien cassé ? - Implementing regulation - EU - 2026/2083 - EN - EUR-Lex. Europese Commissie (EUR-Lex); 21-09-2026.
SRC-403fc76309Lien cassé ? - Reglement betreffende de uitwisseling van gezondheidsgegevens tussen gezondheidssystemen verbonden via het verwijzingsrepertorium van het eHealth-platform. eHealth-platform / Informatieveiligheidscomité; 18-02-2014.
SRC-f4d7f1af3aLien cassé ? - IHE XDS Components (Brusafe+). Abrumet.
SRC-d81b432dd2Lien cassé ? - Abrumet - Rapport annuel 2025. Abrumet asbl; 01-06-2026.
SRC-d88dd8ca9bLien cassé ? - Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011/24/EU and Regulation (EU) 2024/2847. Europees Parlement en Raad van de EU (EUR-Lex); 05-03-2025.
SRC-af26b6d770Lien cassé ? - EU Health Data API 1.0.0-ballot - Home. HL7 Europe; 13-03-2026.
SRC-5b23061c0dLien cassé ? - EU Health Data API 1.0.0-ballot - Regulatory Anchors. HL7 Europe; 13-03-2026.
SRC-11eab7dc48Lien cassé ? - IHE Process. IHE International.
SRC-b6e5852d6dLien cassé ? - ITI TF Vol. 1 - 15 Cross-Enterprise Document Reliable Interchange (XDR). IHE International.
SRC-75219362dfLien cassé ? - ITI TF Vol. 1 - 16 Cross-Enterprise Document Media Interchange (XDM). IHE International.
SRC-c7f27cf640Lien cassé ? - ITI TF Vol. 1 - 5 Patient Identifier Cross-referencing (PIX). IHE International.
SRC-c07c242acdLien cassé ? - ITI TF Vol. 1 - 8 Patient Demographics Query (PDQ). IHE International.
SRC-02d82932e9Lien cassé ? - ITI TF Vol. 1 - 13 Cross Enterprise User Assertion (XUA). IHE International.
SRC-e04ee076d2Lien cassé ? - ITI TF Vol. 1 - 7 Consistent Time (CT). IHE International.
SRC-5f8536838bLien cassé ? - ITI TF Vol. 1 - 19 Basic Patient Privacy Consents (BPPC). IHE International.
SRC-b3c3903b2dLien cassé ? - Mobile access to Health Documents (MHD). IHE International.
SRC-773b64a361Lien cassé ? - Patient Identifier Cross-referencing for mobile (PIXm). IHE International.
SRC-9865210329Lien cassé ? - Patient Demographics Query for Mobile (PDQm). IHE International.
SRC-368e5d9143Lien cassé ? - IHE Domains. IHE International.
SRC-9b92891d8dLien cassé ? - IHE Technical Frameworks General Introduction - 8 IHE Technical Framework Development and Publication Process. IHE International.
SRC-35ac7378b0Lien cassé ? - European Health Data Space. IHE-Europe.
SRC-aacfd03cb1Lien cassé ? - Besluit (EU) 2015/1302 van de Commissie van 28 juli 2015 over de identificatie van IHE-profielen voor verwijzing bij overheidsopdrachten (PB L 199 van 29.7.2015, Engelse versie). Europese Commissie (Publicatiebureau van de EU); 29-07-2015.
SRC-1d5e0fe877Lien cassé ? - eHealth Network Guideline on Electronic exchange of health data under the Cross-border Directive 2011/24/EU. eHealth Network; 07-06-2016.
SRC-65c8f7ca7bLien cassé ? - KMEHR Web Services (hub-metahub intrahub/interhub). eHealth-platform.
SRC-48cdc8b063Lien cassé ? - Cross-enterprise Document Sharing for Imaging - IHE Wiki. IHE International.
SRC-23e8a71af0Lien cassé ? - Cross-Community Access for Imaging - IHE Wiki. IHE International.
SRC-bfc1950430Lien cassé ? - Open eHealth Integration Platform (IPF) - GitHub. Open eHealth Foundation.
SRC-54855d801fLien cassé ? - 2024 EU4Health Work Programme: new projects advancing digital healthcare across the EU. European Health and Digital Executive Agency (HaDEA); 03-12-2025.
SRC-32a456bf46Lien cassé ? - Pilotage - A propos du RSW. Réseau Santé Wallon (FRATEM asbl).
SRC-d326a67e9cLien cassé ? - HubsOnFHIR - How will the Belgian HUB/METAHUB system embrace FHIR. eHealth-platform (GitHub ehealthplatformstandards); 20-06-2023.
SRC-1b19ae6fc4Lien cassé ? - Belgian eHealth Interhub FHIR Simulator. GitHub (nhermab).
SRC-1abe55e4ecLien cassé ? - About Brusafe+. Abrumet.
SRC-32c4c82d84Lien cassé ? - Actieplan e-Gezondheid 2019-2021 (Wayback-kopie). Interministeriële Conferentie Volksgezondheid / FOD Volksgezondheid; 28-01-2019.
SRC-0f93303116Lien cassé ? - Metadata (Brusafe+ XDS). Abrumet.
SRC-f6d53cdda3Lien cassé ? - Advies: Technical and regulatory affairs (HealthTech). Agoria.
SRC-b739dcc2e3Lien cassé ?
ihe-documentdeling · dernière vérification le 09-11-2026 · version 2026.11.13-2 · texte sous CC BY 4.0, sources uniquement liées