--- id: kmehr type: Specification type_label: Norme ou spécification title: KMEHR aliases: - Kmehr - Kind Messages for Electronic Healthcare Records - KMEHR-bus - KMEHR-webservices names: nl: KMEHR fr: KMEHR en: KMEHR (Kind Messages for Electronic Healthcare Records) jurisdiction: - belgie themes: - architectuur-en-infrastructuur - medicatie lifecycle: normatief lifecycle_note: Activement maintenu (schéma 1.43.1, 10/02/2026; aucune release plus récente trouvée au 08/10/2026). Selon l'INAMI (mars 2026, planification), KMEHR deviendra en lecture seule au « Point T »; aucune date de fin pour une suppression progressive complète n'a été trouvée. version: 1.43.1 (schéma XML, 10/02/2026) summary: KMEHR est la norme belge de messages XML pour l'information clinique structurée, introduite en 2002 et gérée par la plate-forme eHealth. Elle comprend un schéma XML, des transactions reconnues (dont le Sumehr et le schéma de médication partagé), des tables de référence et des services web comme ceux du système hubs-métahub. KMEHR est utilisé dans Vitalink et dans les hubs et figure dans la spécification publique la plus récente de Recip-e (2023); la base hub des BMUC relie des types de documents à des profils de transaction. Les nouveaux flux utilisent de préférence FHIR et, dans Vitalink, les types de données KMEHR sont progressivement remplacés par FHIR; selon une planification de l'INAMI de mars 2026, KMEHR deviendra en lecture seule après une bascule coordonnée (« Point T »). links: - soort: documentatie url: https://www.ehealth.fgov.be/standards/kmehr/en label: KMEHR-standaarden (eHealth-platform) taal: en last_verified: '2026-10-08' relations: - type: ownedBy direction: uit target: ehealth-platform target_url: https://ehealth-atlas.be/fr/plate-forme-ehealth/ status: established - type: usesTerminology direction: uit target: ucum target_url: https://ehealth-atlas.be/fr/ucum-unified-code-for-units-of-measure/ status: established - type: usesTerminology direction: uit target: icpc-2 target_url: https://ehealth-atlas.be/fr/classification-internationale-des-soins-primaires-cisp-2/ status: established - type: implements direction: in target: abrumet target_url: https://ehealth-atlas.be/fr/reseau-sante-bruxellois-abrumet/ status: established - type: implements direction: in target: cozo target_url: https://ehealth-atlas.be/fr/cozo/ status: established - type: implements direction: in target: ebirth target_url: https://ehealth-atlas.be/fr/ebirth-notification-electronique-de-naissance/ status: established - type: implements direction: in target: emsr target_url: https://ehealth-atlas.be/fr/emsr-ambureg-enregistrement-prehospitalier/ status: established - type: implements direction: in target: gedeeld-farmaceutisch-dossier target_url: https://ehealth-atlas.be/fr/dossier-pharmaceutique-partage/ status: established - type: implements direction: in target: hubs-metahub target_url: https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/ status: established - type: implements direction: in target: implantatenregister target_url: https://ehealth-atlas.be/fr/registre-central-de-tracabilite-implants/ status: established - type: implements direction: in target: medicatieschema target_url: https://ehealth-atlas.be/fr/schema-de-medication-partage/ status: established - type: implements direction: in target: mult-emediatt target_url: https://ehealth-atlas.be/fr/mult-emediatt/ status: established - type: implements direction: in target: recip-e target_url: https://ehealth-atlas.be/fr/recip-e/ status: established - type: implements direction: in target: rsw target_url: https://ehealth-atlas.be/fr/reseau-sante-wallon/ status: established - type: implements direction: in target: vitalink target_url: https://ehealth-atlas.be/fr/vitalink/ status: established - type: implements direction: in target: vzn-hub target_url: https://ehealth-atlas.be/fr/vzn-hub/ status: established - type: involves direction: in target: arbeidsongeschiktheid-digitaal target_url: https://ehealth-atlas.be/fr/incapacite-de-travail-et-reintegration-flux-numeriques/ status: established - type: involves direction: in target: lab-e-ordering target_url: https://ehealth-atlas.be/fr/demande-electronique-d-analyses-de-laboratoire/ status: established - type: involves direction: in target: uc-medicatieschema-ziekenhuis target_url: https://ehealth-atlas.be/fr/schema-de-medication-a-l-admission-et-a-la-sortie/ status: established - type: involves direction: in target: uc-verslagen-delen-via-hub target_url: https://ehealth-atlas.be/fr/partage-des-rapports-hospitaliers-via-le-hub/ status: established - type: about direction: in target: bihr target_url: https://ehealth-atlas.be/fr/belgian-integrated-health-record-bihr/ status: established - type: about direction: in target: bihr-contactrapport target_url: https://ehealth-atlas.be/fr/contact-report-bihr/ status: established - type: about direction: in target: rechtsgrond-fhir-snomed target_url: https://ehealth-atlas.be/fr/base-legale-pour-snomed-ct-caresets-et-fhir/ status: established - type: requires direction: in target: bmuc-epd-criteria target_url: https://ehealth-atlas.be/fr/belgian-meaningful-use-criteria-bmuc/ status: established - type: replaces direction: in target: fhir target_url: https://ehealth-atlas.be/fr/hl7-fhir/ status: established - type: partOf direction: in target: kmehr-labresult target_url: https://ehealth-atlas.be/fr/transaction-kmehr-resultat-de-laboratoire/ status: established - type: partOf direction: in target: sumehr target_url: https://ehealth-atlas.be/fr/sumehr/ status: established - type: dependsOn direction: in target: vaccinnet target_url: https://ehealth-atlas.be/fr/vaccinnet/ status: established release: 2026.11.12-3 url: https://ehealth-atlas.be/fr/kmehr/ license: CC BY 4.0 --- # KMEHR KMEHR est la norme belge de messages XML pour l'information clinique structurée, introduite en 2002 et gérée par la plate-forme eHealth. Elle comprend un schéma XML, des transactions reconnues (dont le Sumehr et le schéma de médication partagé), des tables de référence et des services web comme ceux du système hubs-métahub. KMEHR est utilisé dans Vitalink et dans les hubs et figure dans la spécification publique la plus récente de Recip-e (2023) ; la base hub des BMUC relie des types de documents à des profils de transaction. Les nouveaux flux utilisent de préférence FHIR et, dans Vitalink, les types de données KMEHR sont progressivement remplacés par FHIR ; selon une planification de l'INAMI de mars 2026, KMEHR deviendra en lecture seule après une bascule coordonnée (« Point T »). ## En bref - **Quoi** : KMEHR est la norme belge de messages XML de 2002 (schéma, transactions reconnues, tables de référence et services web)[^1] ; la release de schéma la plus récente est la 1.43.1 du 10/02/2026[^2]. - **Comment** : les services hub (intrahub et interhub) font partie de la spécification KMEHR[^3][^4] ; une version hub n'a été trouvée que pour le Réseau Santé Wallon : XSD 1.40.2 depuis le 25/03/2025, auparavant 1.26[^5]. - **Pour les hôpitaux** : la base hub des BMUC (AR du 10/04/2025, annexe 19) relie les rapports opératoires et d'anesthésie au profil Report[^6] et l'imagerie à Procedure result[^6], qui exige CD-TRANSACTION « result »[^7]. - **État** : dans ses spécifications publiques les plus récentes (2023), Recip-e cite KMEHR 1.28 comme version actuelle[^8]. - **Planning (planification de l'INAMI, mars 2026)** : pour les nouveaux flux, FHIR est la norme préférentielle[^1] ; après une bascule coordonnée, KMEHR deviendrait en lecture seule[^9], le Point T se situe 12 mois après le dernier CareSet patient summary[^9] ; aucune date de fin n'a été trouvée. - **Plus grande incertitude** : une spécification interhub FHIR officielle n'a pas été trouvée ; CoZo a testé en juin 2026 un échange FHIR fédéré avec un hub simulé (test, pas de production)[^10]. ## Qu'est-ce que c'est ? KMEHR (Kind Messages for Electronic Healthcare Records) est la norme belge de messages pour l'information clinique structurée. Elle a été introduite en 2002 comme implémentation de la quatrième recommandation de la Belgische Commissie voor Gezondheidstelematica[^1]. KMEHR se compose d'un schéma XML comportant une grammaire générale de messages, d'un ensemble de transactions médicales reconnues et de tables de référence, le tout complété par des webservices[^1]. Parmi les transactions connues figurent le [Sumehr](https://ehealth-atlas.be/fr/sumehr/)[^11] et les transactions qui forment ensemble le [schéma de médication partagé](https://ehealth-atlas.be/fr/schema-de-medication-partage/)[^12]. Il n'est pas nécessaire que chaque transaction soit structurée au même degré : un « contactreport » n'exige que le niveau de normalisation 1, où le contenu peut être envoyé en texte libre ou comme document encapsulé[^13]. ## Quel problème résout-il ? KMEHR permet l'échange d'informations cliniques structurées entre les acteurs de soins belges[^1]. KMEHR définit en outre les webservices du [système Hubs & Metahub](https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/) : les opérations intrahub (du hub vers ses propres clients) et les opérations interhub (de hub à hub)[^3]. Les services des hubs font donc partie de la spécification KMEHR[^4]. getTransactionList permet de rechercher au sein du hub propre ou dans l'ensemble du système de hubs[^14]. Selon la spécification de 2015, tous les échanges interhub reposeront exclusivement sur le numéro d'identification de la sécurité sociale du patient [^4]. ## Gestion, versions et statut [Plate-forme eHealth](https://ehealth-atlas.be/fr/plate-forme-ehealth/) gère la norme KMEHR et le site des standards[^1] ; ce site propose notamment le dernier XSD KMEHR et le validateur KMEHR[^1]. KMEHR est encore activement maintenu[^15] : selon le tableau des versions, la version la plus récente du schéma est la 1.43.1 (10/02/2026)[^2], après la 1.42.1 (01/06/2025)[^2] et la 1.41.0 (01/08/2024)[^2]. La release 1.40.2 (2024) a ajouté les mediatypes `application/fhir+json` et `application/fhir+xml`, afin que du contenu FHIR puisse être signalé dans un message KMEHR[^2]. Les définitions des webservices hub-métahub (xsd-hubservices 3.6.0, 2024-03-27) sont « draft » selon le texte introductif, alors que les opérations individuelles sont répertoriées comme « Published »[^3]. La table de référence CD-TRANSACTION, qui contient les types de transaction reconnus, est à la version 1.17 du 21/03/2024 ; certaines valeurs y sont marquées comme obsolètes (deprecated)[^16]. Attention : la table CD-STANDARD (la version la plus récente du Belgian Healthcare Telematics Standard à laquelle un message se conforme) est à la version 1.45 du 13/02/2026[^17] ; il s'agit d'une version de table, non du numéro de version du schéma (1.43.1). La release 1.43.1 a notamment ajouté la valeur « ixchiq » à CD-VACCINEINDICATION[^2]. Pour l'incapacité de travail, la transaction Incapacity notification 2.2.1 (Production, iteration 1) figure comme Published sur le site ; elle a été créée pour une nouvelle mesure de janvier 2026[^18]. **Services interhub (état au 30/09/2026).** Pour l'interhub getTransactionList, le site des standards mentionne le statut Published, version 1.1 du 06/12/2018[^19]. L'historique du document de cette spécification ne connaît que la version 1.0 (30/07/2010) et la version 1.1 (06/12/2018)[^20]. Déduction propre : le pied de page « v1.2 dd XXXX » dans le même PDF est probablement une ligne de modèle non complétée, car aucune version 1.2 n'a été trouvée sur le site[^20]. Pour l'interhub getTransaction, le site web date la version 1.1 du 24/07/2019[^21], le PDF lié du 04/10/2018[^22] (voir les incertitudes). **Validation.** Chaque version de l'ehValidator est liée à une seule version de KMEHR et à une seule version des spécifications Sumehr et de migration[^23] ; la plus récente (en haut du tableau des versions : 3.4.5, 21/09/2022) correspond à KMEHR 1.36.0, donc pas au schéma 1.43.1[^23]. L'outil valide le Sumehr et le GP Software Migration Format sur le plan syntaxique et n'est pas adapté à l'évaluation de la qualité du contenu médical[^23]. Attention à la différence entre version du schéma et version de transaction : Sumehr 2.0 exige par exemple KMEHR 20161201 ou plus récent[^11]. Selon les directives de contenu de [Recip-e](https://ehealth-atlas.be/fr/recip-e/) de 2019/2020, les prescriptions électroniques pouvaient s'appuyer sur KMEHR 1.28 à partir du 01/05/2020, et devaient obligatoirement le faire à partir du 01/06/2020[^24]. Ces directives de production sont obsolètes depuis le 23/03/2021 et ont été intégrées dans les spécifications générales de dématérialisation [^25]. Les plus récentes d'entre elles (version du document 20230224, package du 02/06/2023) désignent toujours KMEHR 1.28 comme la version actuelle[^8], et le SDK destiné aux prescripteurs valide par rapport à kmehr-1.28.xsd[^8]. Aucune spécification Recip-e de 2024-2026 n'a été trouvée (lacune, 30/09/2026). ## Application belge KMEHR est en production auprès de [Vitalink](https://ehealth-atlas.be/fr/vitalink/), des progiciels intégrés, de la plate-forme eHealth, des [réseaux hospitaliers](https://ehealth-atlas.be/fr/reseau-hospitalier-clinique-locoregional/) et des autres coffres-forts santé[^26]. Vitalink fonctionne en 2026 avec deux environnements : FHIR comme norme actuelle et un environnement KMEHR legacy qui est encore utilisé notamment pour le schéma de médication partagé, le Sumehr, le Kindrapport et les éléments de journal[^27]. Recip-e utilise KMEHR XML comme format de message pour la prescription électronique[^24], et se situe, selon les spécifications publiques les plus récentes (2023), à KMEHR 1.28[^8]. Les hubs et le métahub communiquent via des « webservices KMEHR » dont la spécification est publiée par la plate-forme eHealth[^28]. ### Publication via les hubs : version par hub *Interprétation* : la version de KMEHR qu'un hub accepte détermine en partie quels codes de transaction un hôpital peut publier ; au RSW, des valeurs se sont ajoutées avec la nouvelle version[^5]. Données publiques par hub (consultation du 30/09/2026) : | Hub | Version KMEHR des services hub | Ce qui est documenté | |---|---|---| | [Réseau Santé Wallon (RSW)](https://ehealth-atlas.be/fr/reseau-sante-wallon/) | XSD 1.40.2 pour intrahub, interhub et cosites, en production depuis le 25/03/2025 ; auparavant 1.26[^5] | nouveaux codes de transaction et règles d'accès par type de document (voir ci-dessous) | | [CoZo (Collaboratief Zorgplatform)](https://ehealth-atlas.be/fr/cozo/) | non trouvé (lacune) | webservices KMEHR selon le règlement des hubs[^28] ; documentation pour partenaires non publique | | [VZN-hub](https://ehealth-atlas.be/fr/vzn-hub/) | non trouvé (lacune) | aucune documentation technique publique trouvée | | [Réseau Santé Bruxellois (Abrumet)](https://ehealth-atlas.be/fr/reseau-sante-bruxellois-abrumet/) | non trouvé (lacune) | échange selon KMEHR, les documents accessibles sont disponibles en format PDF[^29] | Au RSW, la migration a été motivée par le projet [DIGIRELAB](https://ehealth-atlas.be/fr/digitalisation-des-resultats-de-laboratoire-digirelab/) et les mediatypes FHIR ; la XSD fédérale des webservices n'était, selon le RSW, pas mise à jour depuis de très nombreuses années[^5]. Ces mediatypes ont été ajoutés avec la release 1.40.2[^2]. Depuis lors, les webservices du RSW acceptent notamment les valeurs CD-TRANSACTION belrai-report, nursingsummaryreport, pharmaceuticalmedicationscheme et geriatrictransferreport[^5]. Le RSW renvoie à cet égard à Hub Services 3.5.3, dont la XSD KMEHR 1.22 fournie dans le package doit être remplacée par la 1.40[^5] ; la plate-forme eHealth publie elle-même déjà xsd-hubservices 3.6.0 (27/03/2024, comme « draft »)[^3]. Au niveau du cosite, la plupart des valeurs qui sont des énumérations strictes pour les webservices fédéraux sont des valeurs libres[^5]. Le RSW gère les droits d'accès par défaut par type de documents[^30], et la classification d'un document détermine en partie qui le voit en cas d'accès « limité »[^30]. ### Profils KMEHR dans la base hub des BMUC L'AR du 10/04/2025 (annexe 19, fonctionnalité de base 9 « Communication automatisée avec les hub's ») relie les rapports des opérations et le rapport d'anesthésie au profil de transaction Report et les rapports de consultations à Contact report[^6]. Les rapports des examens médico-techniques et les rapports d'imagerie médicale telle que radiologie et médecine nucléaire relèvent de Procedure result[^6]. La liste cite aussi Discharge letter, Referral letter, Laboratory result, Medication scheme (element), Pharmaceutical prescription et les attestations médico-administratives[^6]. La circulaire du 11/03/2024 utilisait la même liste sous l'intitulé « Lijst van type documenten en hun metadata »[^31] ; voir [BMUC : financement du DPI intégré](https://ehealth-atlas.be/fr/belgian-meaningful-use-criteria-bmuc/). Sur le site des standards, Procedure result sert aux résultats d'un examen technique qui est typiquement identifié comme prestation INAMI ; les examens cliniques relèvent de Contact report et les résultats de laboratoire de Laboratory result[^7]. Procedure result exige CD-TRANSACTION « result »[^7] et seulement le niveau de normalisation 1 (texte libre, objet encapsulé ou items)[^7] ; Referral letter exige « referral »[^32]. Des codes locaux peuvent à chaque fois être ajoutés en complément[^7][^32]. **Déduction propre** (ne figure ni dans l'AR ni sur le site des standards) : si l'on combine l'AR (Report pour les rapports des opérations et d'anesthésie) avec les exigences de profil, ces rapports sont publiés comme « report »[^6][^33] et les rapports d'imagerie et les rapports médico-techniques comme « result »[^6][^7]. Les codes de spécialisation (CD-TRANSACTION-TYPE) sont des valeurs distinctes qui ne sont pas combinables avec chaque code de transaction[^34] ; l'AR ne les fixe pas[^6]. ### Transition de KMEHR vers FHIR Cette section regroupe la transition vers [HL7 FHIR](https://ehealth-atlas.be/fr/hl7-fhir/) ; il n'existe pas de page de concept distincte, les affirmations sous-jacentes figurent en partie dans l'ensemble d'affirmations `kmehr-fhir-transitie`. - **Politique** : depuis le plan d'action eSanté 2019-2021, FHIR est la norme préférentielle ; les nouveaux flux de données utilisent de préférence FHIR[^1]. Les flux existants sont encouragés à migrer lors d'itérations futures ; la migration des services de base est itérative et en « best effort »[^35]. - **Pas de big bang** : la plate-forme eHealth affirme qu'une conversion sans effort supplémentaire de codage et de structuration apporte peu de valeur ajoutée, et qu'un « big bang » n'est pas possible[^1]. - **Planification BIHR** : au sein de [BIHR (Belgian Integrated Health Record)](https://ehealth-atlas.be/fr/belgian-integrated-health-record-bihr/), les flux KMEHR existants restent pris en charge en lecture seule, et les échanges nouveaux et modifiés passent par FHIR à partir de 2028[^36]. - **Fin de KMEHR : « Point T » (INAMI, mars 2026, planification)** : après une bascule coordonnée, FHIR devient opérationnel et KMEHR passe en read-only[^9] ; le Point T se situe 12 mois après la publication du dernier CareSet patient summary[^9]. C'est un jalon relatif, et non une date calendaire ni un arrêt ; l'explication complète figure sur [BIHR (Belgian Integrated Health Record)](https://ehealth-atlas.be/fr/belgian-integrated-health-record-bihr/). - **Flux sans KMEHR** : pour la prescription de renvoi électronique (eReferral), il existe un CareSet « Digital Referral Prescription »[^37], mais le DRP-IG est deprecated au profit de Referral[^38]. Déduction propre : aucune variante KMEHR de la prescription de renvoi électronique n'a été trouvée, le flux semble passer directement à FHIR. Un aperçu par flux de données figure sur [BIHR (Belgian Integrated Health Record)](https://ehealth-atlas.be/fr/belgian-integrated-health-record-bihr/). - **Vitalink** : les pouvoirs publics, les prestataires de soins et l'industrie ont décidé de remplacer progressivement les types de données KMEHR dans Vitalink par des CareSets FHIR[^39]. L'environnement FHIR de Vitalink est en production depuis le 22/03/2024 à côté de l'environnement KMEHR[^40]. Depuis le 1er juillet 2025, les données de dépistage du CVKO ne sont plus disponibles que via FHIR ; la consultation via KMEHR a été arrêtée[^41]. - **Hubs** : une spécification interhub FHIR officielle de la plate-forme eHealth, de l'INAMI ou de HL7 Belgium n'a pas été trouvée (lacune, 08/10/2026) ; aucun guide interhub belge n'a non plus été trouvé dans l'organisation GitHub de HL7 Belgium. Il existe toutefois : - un simulateur dans un dépôt GitHub personnel non officiel (« fhir-ehealth-hub-simulator ») ; la README décrit une implémentation de référence côté serveur, qui modernise des transactions legacy KMEHR/SOAP[^42] vers IHE MHD sur FHIR R4[^42] ; il s'agit d'un projet communautaire, et non d'une spécification officielle ; - le dépôt GitHub officiel « HubsOnFHIR » de la plate-forme eHealth, sur la manière dont le système hubs-métahub adoptera FHIR[^43] ; selon les métadonnées du dépôt (créé en juin 2023, interprétation), aucune élaboration publique actuelle d'un rôle FHIR pour les hubs n'y a été trouvée (lacune)[^43], et le GitHub transversal « FHIR Strategy in Belgian eHealth Ecosystem » mentionne HubsOnFHIR[^44] ; - un **atelier de test** « Federated FHIR exchange » de CoZo avec Amaron à la BE FHIR-A-THON de juin 2026, dans le cadre de SHIFT et de DIGIRELAB phase 3[^10], avec un hub CoZo simulé par Amaron[^10], des patients synthétiques et sans sécurité eHealth formelle[^10] ; il s'agit d'un test, et non d'une production (voir [CoZo (Collaboratief Zorgplatform)](https://ehealth-atlas.be/fr/cozo/)) ; - la documentation historique d'Abrumet (2017) dans laquelle Brusafe+ utilise des composants IHE XDS et une gateway XCA, tandis que Brusafe+ communique avec le Réseau Santé Bruxellois via KMEHR[^45] ; des profils IHE donc au sein d'un coffre-fort, et non comme protocole interhub (voir [Réseau Santé Bruxellois (Abrumet)](https://ehealth-atlas.be/fr/reseau-sante-bruxellois-abrumet/)). - **Recip-e** : une revue spécialisée francophone (source secondaire, 24/06/2026) écrit que FHIR est appelé à remplacer « progressivement » les développements historiques de Recip-e basés sur KMEHR[^46] ; c'est une affirmation de la source, et non une date ni une décision. - **Retrait progressif (état au 08/10/2026)** : aucune nouvelle source sur le retrait progressif de KMEHR n'a été trouvée (lacune) ; la dernière release du schéma reste la 1.43.1 du 10/02/2026[^2]. Le contexte du retrait par flux figure sur [BIHR (Belgian Integrated Health Record)](https://ehealth-atlas.be/fr/belgian-integrated-health-record-bihr/) et, pour Vitalink, sur [Migration de Vitalink vers FHIR (de KMEHR vers Vitalink 2.0)](https://ehealth-atlas.be/fr/migration-de-vitalink-vers-fhir/). ## Portée pratique pour les hôpitaux - **Condition de financement** : les conditions BMF de l'arrêté royal du 10 avril 2025 exigent la consultation, par les prestataires de soins au sein de l'établissement et via les hubs et les coffres-forts santé, des informations de santé d'autres établissements, du Sumehr et de l'aperçu de la médication[^47]. Le document BMUC de 2016 (la version trouvée est une copie Wayback de la version 0.1) le demandait déjà dans la fonctionnalité clé 15[^48]. Ces flux passent aujourd'hui par KMEHR : entre hubs via les webservices KMEHR[^28], et le Sumehr et le schéma de médication chez Vitalink via l'environnement KMEHR legacy [^27][^49]. Voir [BMUC : financement du DPI intégré](https://ehealth-atlas.be/fr/belgian-meaningful-use-criteria-bmuc/). - Selon la réponse ministérielle flamande (2025), tous les hôpitaux ont accès aux données Vitalink KMEHR, mais pas toujours de manière optimale et parfois par un détour via le métahub[^49]. - **Condition de financement (base hub)** : les hôpitaux annotent avec les métadonnées correctes toutes les données partagées via hubs-métahub[^47] ; la liste de l'arrêté royal cite à cet égard des profils KMEHR, pas des codes[^6]. Le choix du code « report » ou « result » ne découle que des profils figurant sur le site des standards (déduction propre)[^33][^7]. - **Version du hub** : le RSW avertit que les partenaires ont pu établir leurs règles business sur la base des anciennes versions des XSD et qu'il est important de leur signaler les nouvelles valeurs[^5]. - **Recommandation :** faites documenter par le fournisseur du DPI, pour chaque type de document de l'annexe 19, le code CD-TRANSACTION et la spécialisation utilisés, et demandez par écrit au hub de l'établissement quelle version de KMEHR et quelles valeurs il accepte ; pour les hubs autres que le RSW, cela n'est pas documenté publiquement. - **Recommandation :** planifiez la réduction progressive de KMEHR autour du Point T (voir [BIHR (Belgian Integrated Health Record)](https://ehealth-atlas.be/fr/belgian-integrated-health-record-bihr/)), et non autour d'une date fixe. Partez de plusieurs années de double prise en charge (KMEHR pour la publication via les hubs, le Sumehr, le schéma de médication et Recip-e ; FHIR pour les nouveaux flux Vitalink) et suivez les releases du schéma KMEHR, car il n'y a pas de date de fin. ## Conditions de mise en œuvre et limites Selon la description fonctionnelle du 26/03/2015, le stockage de dossiers médicaux dans le hub lui-même (putTransaction) n'est pas une fonctionnalité standard d'un hub dans le projet hub-métahub [^4]. Cela porte sur le stockage dans le hub, non sur le partage de rapports via le hub en général ; voir [Hubs & Metahub (répertoire des références)](https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/). Selon la spécification de 2015, le couplage interhub dépend entièrement du numéro d'identification de la sécurité sociale[^4]. Un faible degré de normalisation (texte libre, documents encapsulés) est autorisé pour certaines transactions[^13], ce qui limite la réutilisabilité du contenu ; c'est précisément pourquoi une conversion vers FHIR sans meilleur codage apporte peu, selon la plate-forme eHealth[^1]. ## Incertitudes et informations contradictoires - Le statut des webservices des hubs est ambigu : « draft » dans l'introduction, « Published » par opération [^3]. Le texte introductif est probablement dépassé, mais cela n'est pas confirmé. - Aucune date de fin officielle n'a été trouvée pour le retrait progressif complet de KMEHR ni par flux KMEHR ; le seul jalon est le Point T relatif, après lequel KMEHR reste read-only[^9]. Cela ne signifie pas qu'il n'existe pas d'autre planification. Le jalon BIHR 2028[^36] et la politique « FHIR de préférence » depuis 2019[^1] ne se contredisent pas, mais ne donnent pas ensemble de date par flux. Aucun arrêté royal, arrêté ministériel, condition BMUC ou critère d'homologation imposant la migration aux hôpitaux n'a été trouvé (état au 1/10/2026) ; la transition relève de la planification (Point T) et de la préférence[^9][^50] ; voir [Obligation ou planification ? Base légale pour SNOMED CT, CareSets et FHIR](https://ehealth-atlas.be/fr/base-legale-pour-snomed-ct-caresets-et-fhir/). - Aucun statut officiel d'une spécification interhub basée sur FHIR n'a été trouvé ; seuls le simulateur dans un dépôt personnel[^42], le dépôt officiel HubsOnFHIR sans élaboration trouvée [^43] et l'atelier de test de CoZo avec un hub simulé[^10]. - **Datation de l'interhub getTransaction (contradiction ouverte)** : le site web date la version 1.1 du 24/07/2019[^21], le PDF lié du 04/10/2018[^22]. Il n'est pas confirmé laquelle des deux dates est correcte. De même pour getTransactionList « v1.2 » : l'historique du document ne connaît pas de version 1.2[^20] ; que le pied de page « v1.2 dd XXXX » soit un reste de modèle est une interprétation [^20]. - **Brusafe+ contre BruSafe (contradiction ouverte)** : la documentation pour développeurs d'Abrumet (2017, 2020) décrit Brusafe+ comme un environnement IHE XDS/CDA[^45][^51], alors que le site web du RSB qualifie le coffre-fort BruSafe de dépôt KMEHR contenant des pdf[^52]. Il s'agit peut-être de deux composants (le coffre-fort classique et Brusafe+) ou d'une évolution dans le temps ; voir [Réseau Santé Bruxellois (Abrumet)](https://ehealth-atlas.be/fr/reseau-sante-bruxellois-abrumet/). - **Versions des hubs** : une version de KMEHR propre au hub n'a été trouvée que pour le RSW[^5] ; pas pour CoZo, la VZN-hub ni Abrumet (lacune, aucune preuve qu'ils utilisent une version plus ancienne). Recip-e : la spécification publique la plus récente date de 2023[^8][^25] ; cela ne prouve pas qu'il n'existe pas d'exigence plus récente et non publique. - Le fait que la plate-forme eHealth gère KMEHR repose sur le site des standards (« the standards that we manage here »)[^1] ; la loi confie bien à la plate-forme la mission générale de fixer des normes et des standards TIC[^53], et la page des standards de la plate-forme indique que les standards ne portent que sur les aspects TIC[^54] ; aucun texte attribuant KMEHR nommément n'a été trouvé. ## Relaties - relève de: [Plate-forme eHealth](https://ehealth-atlas.be/fr/plate-forme-ehealth/) (établi)[^1]. Beheer van de standaard en de standaardensite (Standards-afdeling). - utilise la terminologie: [UCUM](https://ehealth-atlas.be/fr/ucum-unified-code-for-units-of-measure/) (établi)[^55]. KMEHR-referentietabel UCUM (sinds 01/03/2015); daarnaast de eigen tabel CD-UNIT. - utilise la terminologie: [CISP-2 (et CISP-3)](https://ehealth-atlas.be/fr/classification-internationale-des-soins-primaires-cisp-2/) (établi)[^56]. KMEHR-tabel ICPC (1.0, 2009) bevat enkel een illustratief uittreksel. - implémente (entrant): [Réseau Santé Bruxellois (Abrumet)](https://ehealth-atlas.be/fr/reseau-sante-bruxellois-abrumet/) (établi)[^52][^29] - implique (entrant): [Incapacité de travail et réintégration – flux numériques](https://ehealth-atlas.be/fr/incapacite-de-travail-et-reintegration-flux-numeriques/) (établi)[^57][^58] - porte sur (entrant): [BIHR (Belgian Integrated Health Record)](https://ehealth-atlas.be/fr/belgian-integrated-health-record-bihr/) (établi)[^36][^9] - porte sur (entrant): [Contact Report (BIHR) : enregistrement après chaque contact](https://ehealth-atlas.be/fr/contact-report-bihr/) (établi)[^59] - exige (entrant): [BMUC : financement du DPI intégré](https://ehealth-atlas.be/fr/belgian-meaningful-use-criteria-bmuc/) (établi)[^6] - implémente (entrant): [CoZo (Collaboratief Zorgplatform)](https://ehealth-atlas.be/fr/cozo/) (établi)[^28][^60] - implémente (entrant): [eBirth (notification électronique de naissance)](https://ehealth-atlas.be/fr/ebirth-notification-electronique-de-naissance/) (établi)[^61] - implémente (entrant): [EMSR / Ambureg (enregistrement préhospitalier)](https://ehealth-atlas.be/fr/emsr-ambureg-enregistrement-prehospitalier/) (établi)[^62] - remplace (entrant): [HL7 FHIR](https://ehealth-atlas.be/fr/hl7-fhir/) (établi)[^39][^36] - implémente (entrant): [Dossier Pharmaceutique Partagé](https://ehealth-atlas.be/fr/dossier-pharmaceutique-partage/) (établi)[^63] - implémente (entrant): [Hubs & Metahub (répertoire des références)](https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/) (établi)[^28][^3] - implémente (entrant): [Registre central de traçabilité des implants (CTR) et SADMI](https://ehealth-atlas.be/fr/registre-central-de-tracabilite-implants/) (établi)[^64] - fait partie de (entrant): [Transaction KMEHR résultat de laboratoire (1.1 et 2.0)](https://ehealth-atlas.be/fr/transaction-kmehr-resultat-de-laboratoire/) (établi)[^65] - implique (entrant): [Demande électronique d'analyses de laboratoire](https://ehealth-atlas.be/fr/demande-electronique-d-analyses-de-laboratoire/) (établi)[^66] - implémente (entrant): [Schéma de médication partagé](https://ehealth-atlas.be/fr/schema-de-medication-partage/) (établi)[^12][^67] - implémente (entrant): [Mult-eMediatt](https://ehealth-atlas.be/fr/mult-emediatt/) (établi)[^58][^57][^68] - porte sur (entrant): [Obligation ou planification ? Base légale pour SNOMED CT, CareSets et FHIR](https://ehealth-atlas.be/fr/base-legale-pour-snomed-ct-caresets-et-fhir/) (établi)[^9][^69] - implémente (entrant): [Recip-e (prescription électronique dans le secteur ambulatoire)](https://ehealth-atlas.be/fr/recip-e/) (établi)[^24][^8] - implémente (entrant): [Réseau Santé Wallon (RSW)](https://ehealth-atlas.be/fr/reseau-sante-wallon/) (établi)[^70] - fait partie de (entrant): [Sumehr](https://ehealth-atlas.be/fr/sumehr/) (établi)[^11] - implique (entrant): [Cas d'usage : schéma de médication à l'admission et à la sortie](https://ehealth-atlas.be/fr/schema-de-medication-a-l-admission-et-a-la-sortie/) (établi)[^12][^49] - implique (entrant): [Cas d'usage : partage des rapports et résultats hospitaliers via le hub](https://ehealth-atlas.be/fr/partage-des-rapports-hospitaliers-via-le-hub/) (établi)[^4][^14][^28] - dépend de (entrant): [Vaccinnet](https://ehealth-atlas.be/fr/vaccinnet/) (établi)[^71] - implémente (entrant): [Vitalink](https://ehealth-atlas.be/fr/vitalink/) (établi)[^27][^26][^72][^73] - implémente (entrant): [VZN-hub](https://ehealth-atlas.be/fr/vzn-hub/) (établi)[^74] ## Open vragen - Komt er een officiële einddatum voor KMEHR, per stroom (hubs, Sumehr, medicatieschema, Recip-e), en hoe lang blijven KMEHR-gegevens na Point T read-only raadpleegbaar? - Wat betekent 'KMEHR-stromen blijven beschikbaar als alleen-leesbestanden' (BIHR) concreet voor publicatie door ziekenhuizen na 2028? - Welke CD-TRANSACTION-codes, specialisatiecodes (CD-TRANSACTION-TYPE) of andere metadata verwacht de FOD voor de BMUC-telling van operatie-, anesthesie- en beeldvormingsverslagen? Het KB van 10/04/2025 noemt enkel profielnamen. - Welke KMEHR-XSD-versie gebruiken CoZo, de VZN-hub en Abrumet vandaag (RSW: 1.40.2 sinds 25/03/2025), en welke CD-TRANSACTION-waarden en metadata aanvaarden ze bij publicatie door ziekenhuizen? - Komt er een officiële FHIR-interhubspecificatie (eHealth-platform, RIZIV, HL7 Belgium)? - Bestaat er een Recip-e-specificatie na 02/06/2023 met een andere KMEHR-versie dan 1.28, of blijft 1.28 gelden tot de FHIR-overgang? ## Bronnen [^1]: [eHealth Platform Standards - Home (KMEHR)](https://www.ehealth.fgov.be/standards/kmehr/en). eHealth-platform. Opgehaald 2026-09-25, sha256 31d7759c5f189a49… (SRC-bd069bf1c8) [^2]: [KMEHR XSchema - versions](https://www.ehealth.fgov.be/standards/kmehr/en/page/xschema). eHealth-platform. Opgehaald 2026-09-25, sha256 ba83c8e181e53f88… (SRC-d0dfbfa787) [^3]: [KMEHR Web Services (hub-metahub intrahub/interhub)](https://www.ehealth.fgov.be/standards/kmehr/en/web-services). eHealth-platform. Opgehaald 2026-09-25, sha256 9d48154d8ac7c1d7… (SRC-48cdc8b063) [^4]: [Hub service putTransaction: functional description (v1.1)](https://ehealth.fgov.be/standards/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/6e524d88f6f723615d4d10d58d9f5bb83bfc5e57/20150417-intrahub-puttransaction-1-1-specificat.pdf). eHealth-platform (KMEHR), 2015-03-26. Opgehaald 2026-09-25, sha256 4e858fcfe362adb4… (SRC-463e514ada) [^5]: [XSD : migration vers le KMEHR Version 1.40.2](https://conf.reseausantewallon.be/display/DOCPUB/XSD+%3A+migration+vers+le+KMEHR+Version+1.40.2). Réseau Santé Wallon (FRATEM), 2025-02-14. Opgehaald 2026-09-30, sha256 93673afbee1d0b1f… (SRC-c99a273059) [^6]: [Koninklijk besluit van 10 april 2025 tot wijziging van het koninklijk besluit van 25 april 2002 betreffende de vaststelling en de vereffening van het budget van financiële middelen van de ziekenhuizen (Justel)](https://www.ejustice.just.fgov.be/eli/besluit/2025/04/10/2025003147/justel). FOD Justitie – Belgisch Staatsblad (FOD Volksgezondheid als dossierbeheerder), 2025-04-23. Opgehaald 2026-09-26, sha256 d3467e9c39b54d31… (SRC-64895c2195) [^7]: [Transaction: Procedure result](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/procedure-result). eHealth-platform, 2002-10-15. Opgehaald 2026-09-30, sha256 495b3f3a2329f75b… (SRC-0c0f2431fb) [^8]: [Recip-e dematerialization specifications (20230224)](https://recip-e.be/wp-content/uploads/2022/11/Recip-e_general_dematerialisation_specifications_20230602.pdf). Recip-e vzw, 2023-02-24. Opgehaald 2026-09-30, sha256 0174cbc7424fd072… (SRC-387bd994e0) [^9]: [BIHR: A general introduction](https://www.riziv.fgov.be/SiteCollectionDocuments/BIHR%20-%20A%20general%20introduction.pdf). RIZIV/INAMI, 2026-03-01. Opgehaald 2026-09-26, sha256 e810eccdcae4fcf7… (SRC-c1669f1de8) [^10]: [Test Atelier BE FHIR-A-THON June 2026 — Federated FHIR exchange](https://drive.usercontent.google.com/download?id=1LFvBX_iw3qimvO-f6IWvbtUwlodRGvr1&export=download). CoZo (in partnerschap met Amaron). Opgehaald 2026-09-30, sha256 25c32f9c0ce7c6cb… (SRC-6290028533) [^11]: [Transaction: Summarised Electronic Healthcare Record v2.0](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/summarised-electronic-healthcare-record-v2.0). eHealth-platform, 2016-12-01. Opgehaald 2026-09-25, sha256 bcd907db9dd378c8… (SRC-5abd7569a4) [^12]: [Transaction: Medication Scheme](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/medication-scheme). eHealth-platform, 2021-08-23. Opgehaald 2026-09-25, sha256 7e15091dd8043cc6… (SRC-06c1cc40d4) [^13]: [KMEHR transaction: Contact report](https://ehealth.fgov.be/standards/kmehr/en/transactions/contact-report). eHealth-platform (KMEHR). Opgehaald 2026-09-25, sha256 02dd160d498e2c16… (SRC-efb08efe93) [^14]: [getTransactionList (intrahub)](https://www.ehealth.fgov.be/standards/kmehr/en/web-services/intrahubgettransactionlist). eHealth-platform (KMEHR). Opgehaald 2026-09-25, sha256 a70355d88c9ed2e8… (SRC-ce283ca193) [^15]: [KMEHR News](https://www.ehealth.fgov.be/standards/kmehr/en/news). eHealth-platform, 2026-02-10. Opgehaald 2026-09-25, sha256 d6b1b2501121dd3f… (SRC-141d7b01bc) [^16]: [Reference Tables: Transaction (CD-TRANSACTION)](https://www.ehealth.fgov.be/standards/kmehr/en/tables/transaction). eHealth-platform, 2024-03-21. Opgehaald 2026-09-30, sha256 6f5af4c439f4ff48… (SRC-2a653e7548) [^17]: [Reference Tables: Standard version (CD-STANDARD)](https://ehealth.fgov.be/standards/kmehr/en/tables/standard-version). eHealth-platform. Opgehaald 2026-10-08, sha256 663a9b95e4de3de6… (SRC-6ce68206b9) [^18]: [Transaction: Incapacity notification 2.2.1 (Production - Iteration 1)](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/incapacity-notification-2.2.1-production-iteration-1). eHealth-platform. Opgehaald 2026-10-08, sha256 fd4af56ddca1d9a3… (SRC-457de089b3) [^19]: [Webservice: getTransactionList (Interhub)](https://www.ehealth.fgov.be/standards/kmehr/en/web-services/interhubgettransactionlist). eHealth-platform, 2018-12-06. Opgehaald 2026-09-30, sha256 2ff16b1fe98cffb9… (SRC-c14d973cdf) [^20]: [Interhub getTransactionList: functional description](https://www.ehealth.fgov.be/standards/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/71fef178d070c6e2499578ad50a57b039b7e2b37/20181206-interhub-gettransactionlist-1-1-specification.pdf). eHealth-platform, 2018-12-06. Opgehaald 2026-09-27, sha256 d4f561484182f391… (SRC-4e7752a34e) [^21]: [Webservice: getTransaction (Interhub)](https://www.ehealth.fgov.be/standards/kmehr/en/web-services/interhubgettransaction). eHealth-platform, 2019-07-24. Opgehaald 2026-09-30, sha256 0d8b56b1b05b1421… (SRC-2f44b24632) [^22]: [Hub service 'getTransaction' – functional description (interhub)](https://www.ehealth.fgov.be/standards/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/29e95c6eb85949fe023da854c8c77701ec915818/20181004-interhub-gettransaction-1-1-specification.pdf). eHealth-platform (G19 report), 2018-10-04. Opgehaald 2026-09-30, sha256 91ebb31145674f62… (SRC-58ce0083af) [^23]: [ehValidator](https://www.ehealth.fgov.be/standards/kmehr/en/page/ehvalidator). eHealth-platform. Opgehaald 2026-10-08, sha256 9806801ebd9b2d8b… (SRC-c07e4bcd21) [^24]: [Recip-e electronic prescriptions message content requirements for Kmehr version 1.28](https://recip-e.be/wp-content/uploads/2022/11/Recip-e_contents-guidelines_Kmehr-1.28-1-VMN.pdf). Recip-e vzw, 2019-10-04. Opgehaald 2026-09-25, sha256 9af2df3227e3d877… (SRC-3bb09e5840) [^25]: [Recip-e — Change overview of package for software houses](https://recip-e.be/wp-content/uploads/2022/11/Recip-e-Overview-changes-of-documentation_20230602.pdf). Recip-e vzw, 2023-06-02. Opgehaald 2026-09-30, sha256 fb7701010866aac4… (SRC-47191f855c) [^26]: [Evoluties (HL7 FHIR)](https://www.vitalink.be/hl7-fhir). Vitalink (Departement Zorg). Opgehaald 2026-09-25, sha256 36e1414cda0b19bf… (SRC-e8d2c7c6db) [^27]: [Als zorgorganisatie connecteren met Vitalink?](https://vitalink.be/als-zorgorganisatie-connecteren-met-vitalink). Vitalink (Departement Zorg). Opgehaald 2026-09-25, sha256 44e0897fbc85548f… (SRC-9cd73706d9) [^28]: [Reglement betreffende de uitwisseling van gezondheidsgegevens tussen gezondheidssystemen verbonden via het verwijzingsrepertorium van het eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/224752516d4aeb87b0800b448cd4b0645f74c2a9/reglement-hub-metahub.pdf). eHealth-platform / Informatieveiligheidscomité, 2014-02-18. Opgehaald 2026-09-25, sha256 f5e242162df00247… (SRC-f4d7f1af3a) [^29]: [Notre mission](https://brusselshealthnetwork.be/a-propos-d-abrumet/notre-mission/). Abrumet asbl. Opgehaald 2026-09-26, sha256 30bb32069089b65d… (SRC-02ef82d3e2) [^30]: [Annexe 1 : Table des règles d'accès](https://conf.reseausantewallon.be/pages/viewpage.action?pageId=51315796). Réseau Santé Wallon (FRATEM). Opgehaald 2026-09-30, sha256 d58f46b7ab97bdec… (SRC-1191040c19) [^31]: [Omzendbrief aan de beheerders van ziekenhuizen — BMUC Acceleratorprogramma 2024](https://www.health.belgium.be/sites/default/files/media/files/2025-11/omzendbrief_bmuc_20240311_nl.pdf). FOD Volksgezondheid, DG Gezondheidszorg, 2024-03-11. Opgehaald 2026-09-30, sha256 73019dfff5de0d1a… (SRC-f61161acce) [^32]: [Transaction: Referral letter](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/referral-letter). eHealth-platform, 2002-10-15. Opgehaald 2026-09-30, sha256 894f64e1a9545963… (SRC-e065e3591b) [^33]: [Report](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/report). eHealth-platform, 2013-07-10. Opgehaald 2026-09-27, sha256 679de619829f5585… (SRC-df3a3774bc) [^34]: [CD-TRANSACTION-TYPE](https://www.ehealth.fgov.be/standards/kmehr/en/tables/transaction-type). eHealth-platform, 2023-08-01. Opgehaald 2026-09-27, sha256 b9e9dc6c5d2a089d… (SRC-e000bd4d35) [^35]: [Vision statement HL7 FHIR (v1.0)](https://www.ehealth.fgov.be/standards/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/9bc394df52bbcd7e78f7bb8bba70a6aac50e088f/visionstatementhl7fhir-1-0.pdf). eHealth-platform, 2019-05-28. Opgehaald 2026-09-25, sha256 568b53e85055d810… (SRC-e58cf74e18) [^36]: [Het BIHR (Belgian Integrated Health Record)](https://www.riziv.fgov.be/nl/thema-s/egezondheid/het-bihr-belgian-integrated-health-record). RIZIV. Opgehaald 2026-09-25, sha256 83a6a51e19a53fff… (SRC-bedb8ce40f) [^37]: [Overzicht van gepubliceerde CareSets | RIZIV](https://www.riziv.fgov.be/nl/thema-s/egezondheid/besafeshare-multidisciplinaire-elektronische-gegevensuitwisseling-tussen-zorgverleners-en-patienten/overzicht-van-gepubliceerde-caresets). RIZIV. Opgehaald 2026-09-26, sha256 f8681c3bff934b22… (SRC-b4f8ecf2f8) [^38]: [FHIR IG-portaal: projectenlijst (projects.js)](https://www.ehealth.fgov.be/standards/fhir/assets/js/projects.js). eHealth-platform. Opgehaald 2026-09-25, sha256 738465c00e04599e… (SRC-85fbc850b0) [^39]: [FHIR-documentatie](https://www.vitalink.be/gebruikers/ik-ben-softwareleverancier/fhir-documentatie). Vitalink (Departement Zorg). Opgehaald 2026-09-25, sha256 09ea373755dd8126… (SRC-6e9d5d427a) [^40]: [Nieuwe FHIR-omgeving van Vitalink in productie!](https://www.vitalink.be/nieuwe-fhir-omgeving-van-vitalink-in-productie). Vitalink (Departement Zorg), 2024-03-22. Opgehaald 2026-09-25, sha256 0628be4db12957f3… (SRC-a7e3a494e9) [^41]: [Nieuws | Vitalink](https://www.vitalink.be/nieuws). Vitalink (Departement Zorg). Opgehaald 2026-09-25, sha256 f6a0093244991845… (SRC-e85b9ba17a) [^42]: [Belgian eHealth Interhub FHIR Simulator](https://github.com/nhermab/fhir-ehealth-hub-simulator). GitHub (nhermab). Opgehaald 2026-09-25, sha256 35eab545eb57a665… (SRC-1abe55e4ec) [^43]: [HubsOnFHIR - How will the Belgian HUB/METAHUB system embrace FHIR](https://github.com/ehealthplatformstandards/HubsOnFHIR). eHealth-platform (GitHub ehealthplatformstandards), 2023-06-20. Opgehaald 2026-10-01, sha256 1b283e8ddfb85595… (SRC-1b19ae6fc4) [^44]: [FHIR Strategy in Belgian eHealth Ecosystem (transversale GitHub)](https://github.com/ehealthplatformstandards/KmehrFhirTransitionVersioning). eHealth-platform (GitHub-organisatie ehealthplatformstandards). Opgehaald 2026-10-08, sha256 4c1174b86c7efaa1… (SRC-203619df0c) [^45]: [IHE XDS Components (Brusafe+)](https://doc.abrumet.be/spaces/MQE/pages/543555512/IHE+XDS+Components). Abrumet. Opgehaald 2026-09-30, sha256 9dcff1a3cd549753… (SRC-d81b432dd2) [^46]: [Recip-e veut devenir l'interlocuteur des prestataires dans la e-santé](https://www.lespecialiste.be/fr/actualites/e-health/recip-e-veut-devenir-l-interlocuteur-des-prestataires-dans-la-e-sante.html). Le Spécialiste, 2026-06-24. Opgehaald 2026-10-08, sha256 c83c48742fe91617… (SRC-1b802d4881) [^47]: [Koninklijk besluit van 10 april 2025 tot wijziging van het koninklijk besluit van 25 april 2002 betreffende de vaststelling en de vereffening van het budget van financiële middelen van de ziekenhuizen](https://etaamb.openjustice.be/nl/koninklijk-besluit-van-10-april-2025_n2025003147.html). Belgisch Staatsblad (spiegel etaamb.openjustice.be), 2025-04-23. Opgehaald 2026-09-25, sha256 f2ad9e0cc7157f7d… (SRC-c2bc38d00b) [^48]: [Belgian Meaningful Use Criteria (BMUC) voor algemene ziekenhuizen (versie 0.1, 22/08/2016) - Wayback-kopie](https://web.archive.org/web/20240528012743id_/https://www.health.belgium.be/sites/default/files/uploads/fields/fpshealth_theme_file/belgian_meaningful_use_criteria_voor_algemene_ziekenhuizen_nl_20160824.pdf). FOD Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu, 2016-08-22. Opgehaald 2026-09-25, sha256 97586adfe90a753e… (SRC-7254da6e19) [^49]: [Schriftelijke vraag nr. 327 van 5 februari 2025 (een Vlaams volksvertegenwoordiger) en antwoord van de Vlaamse minister van Welzijn - Zorgvoorzieningen: optimalisatie digitale gegevensverzameling](https://docs.vlaamsparlement.be/files/pfile?id=2130188). Vlaams Parlement, 2025-02-05. Opgehaald 2026-09-25, sha256 cbdb1c075e81aa04… (SRC-a3b502aed4) [^50]: [About FHIR](https://www.ehealth.fgov.be/standards/fhir/about-fhir.html). eHealth-platform. Opgehaald 2026-10-01, sha256 30d90714b5180400… (SRC-ff53eb8437) [^51]: [About Brusafe+](https://doc.abrumet.be/spaces/MQE/pages/543555568/About+Brusafe). Abrumet. Opgehaald 2026-09-30, sha256 cb59e20b92a85aea… (SRC-32c4c82d84) [^52]: [De kluis Brusafe+](https://brusselshealthnetwork.be/nl/over-abrumet/it-projecten/de-kluis-brusafe/). Abrumet vzw. Opgehaald 2026-09-26, sha256 26b4d3315f45b704… (SRC-42b7c220d9) [^53]: [Wet van 21 augustus 2008 houdende oprichting en organisatie van het eHealth-platform (geconsolideerde tekst)](https://www.ehealth.fgov.be/ehealthplatform/nl/wet-van-21-augustus-2008-houdende-oprichting-en-organisatie-van-het-ehealth-platform). eHealth-platform, 2008-10-13. Opgehaald 2026-09-25, sha256 944fd221fc906070… (SRC-4a2ff3f425) [^54]: [Standaarden](https://www.ehealth.fgov.be/ehealthplatform/nl/standaarden). eHealth-platform. Opgehaald 2026-10-08, sha256 741f53972e49e607… (SRC-1100bcc41d) [^55]: [UCUM | KMEHR standards (referentietabel)](https://www.ehealth.fgov.be/standards/kmehr/en/tables/ucum). eHealth-platform, 2015-03-01. Opgehaald 2026-09-26, sha256 263aa1f22001a3ca… (SRC-34aaa1e566) [^56]: [ICPC-2 | KMEHR standards (referentietabel)](https://www.ehealth.fgov.be/standards/kmehr/en/tables/icpc-2). eHealth-platform, 2009-11-05. Opgehaald 2026-09-26, sha256 7de988cf73291186… (SRC-728aeb7e4f) [^57]: [Mult-eMediAtt – Cookbook v2](https://www.ehealth.fgov.be/ehealthplatform/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/88f97494156b965e4764921dfb3a190775adb4c9/mult-emediatt-v2-dd-20250702.pdf). eHealth-platform, 2025-05-15. Opgehaald 2026-09-30, sha256 84f430a15624e0ed… (SRC-6d48901a8d) [^58]: [Mult-eMediatt – Samenvatting van het project – Iteratie 1](https://ehealth.fgov.be/ehealthplatform/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/c2b1467974d3c77b4be364b32533e69cf197e06d/mult-emediatt---project-overview-sessie-10-maart-2021.pdf). eHealth-platform, 2021-03-10. Opgehaald 2026-09-30, sha256 acb7d856a904aa99… (SRC-ddd51ff8c1) [^59]: [Contact report](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/contact-report). eHealth-platform, 2002-10-15. Opgehaald 2026-09-27, sha256 02dd160d498e2c16… (SRC-ebae814f05) [^60]: [Privacyverklaring Collaboratief Zorgplatform Vlaanderen – CoZo VZW](https://www.cozo.be/cozo-privacypolicy). CoZo vzw. Opgehaald 2026-09-25, sha256 6313bf62998d06c6… (SRC-fca17c9054) [^61]: [eBirth notification - mother part (KMEHR transaction)](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/ebirth-notification-mother-part). eHealth-platform (standards). Opgehaald 2026-09-26, sha256 eaee0f0f8ca0b34f… (SRC-6d77e5d7a4) [^62]: [Emergency Medical Service Registry (EMSR) - Ambureg | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-emergency-medical-service-registry-emsr-ambureg). eHealth-platform. Opgehaald 2026-09-28, sha256 72c80fa8e3d2600e… (SRC-67c9886526) [^63]: [Pharmaceutical Care Data Hub](https://www.farmaflux.be/nl-BE/TechnicalWebsite/PCDH/pharmaceutical-care-data-hub~179NL). FarmaFlux vzw, 2022-10-25. Opgehaald 2026-09-26, sha256 a65767cd4c44c7cd… (SRC-4276457a7b) [^64]: [CTR - Centraal Traceerbaarheidsregister | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-ctr-centraal-traceerbaarheidsregister). eHealth-platform. Opgehaald 2026-09-28, sha256 3f29a72419097b93… (SRC-dfb54b9e7d) [^65]: [KMEHR transaction: Laboratory result](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/laboratory-result). eHealth-platform, 2022-07-01. Opgehaald 2026-09-26, sha256 5f8e5d24750a73a2… (SRC-af1784d473) [^66]: [KMEHR transaction: Laboratory request](https://www.ehealth.fgov.be/standards/kmehr/en/transactions/laboratory-request). eHealth-platform, 2002-10-15. Opgehaald 2026-09-26, sha256 bf993864deb32f32… (SRC-982f4b0ed1) [^67]: [Softwareleveranciers: Interoperabiliteit van het gedeeld medicatieschema (VIDIS)](https://www.riziv.fgov.be/nl/thema-s/egezondheid/technische-informatie-en-registratie-voor-softwareleveranciers-van-softwarepakketten-voor-zorgverleners/softwareleveranciers-interoperabiliteit-van-het-gedeeld-medicatieschema-vidis). RIZIV. Opgehaald 2026-09-25, sha256 d1fba33f00a26a19… (SRC-d7e7511c16) [^68]: [Mult-eMediatt – FAQ bestemd voor de software-ontwikkelaars](https://www.in.ehealth.fgov.be/ehealthplatform/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/d6f65b5f681f71b2f0af98b702ad8c0c14432341/faq_dev_mult-emediatt-v1.3-dd-23082022_nl.pdf). eHealth-platform, 2022-08-23. Opgehaald 2026-09-30, sha256 9eb2aeb345411b8a… (SRC-4076a5cb50) [^69]: [BIHR zet in op co-creatie, toegankelijkheid en hergebruik van gegevens - Amaron](https://amaron.be/bihr-zet-in-op-co-creatie-toegankelijkheid-en-hergebruik-van-gegevens/). Amaron, 2026-09-23. Opgehaald 2026-10-01, sha256 fa3a143265e7a1ab… (SRC-66386423aa) [^70]: [Règlement relatif à la protection de la vie privée du Réseau Santé Wallon](https://conf.reseausantewallon.be/pages/viewpage.action?pageId=51315792). FRATEM asbl. Opgehaald 2026-09-26, sha256 9b4e70d11c24f020… (SRC-e5602f28a8) [^71]: [Vaccinnet integreren in uw softwarepakket](https://www.zorg-en-gezondheid.be/per-domein/infectieziekten-en-vaccinaties/vaccinaties/vaccinnet/vaccinnet-integreren-in-uw-softwarepakket). Departement Zorg. Opgehaald 2026-09-25, sha256 525b5ff0a676a57e… (SRC-401473d268) [^72]: [KMEHR-documentatie](https://www.vitalink.be/doelgroepen/ik-ben-softwareleverancier/kmehr-documentatie). Vitalink (Departement Zorg). Opgehaald 2026-10-27, sha256 4f518b6c889347f1… (SRC-52c9ce7e39) [^73]: [Releaseplanning en release notes](https://www.vitalink.be/doelgroepen/ik-ben-softwareleverancier/releaseplanning-en-release-notes). Vitalink. Opgehaald 2026-09-27, sha256 790fb6efc6dacd02… (SRC-af34ac895a) [^74]: [UZ Leuven / eHealth Hub VZN KUL - Bug Bounty Program (Intigriti)](https://app.intigriti.com/programs/uz%20leuven/ehealthhub&meta-hubvznkul/detail). Intigriti (programma gepubliceerd door de hubbeheerder). Opgehaald 2026-09-28, sha256 d43963411d25da6f… (SRC-9986f1f1ed)