KMEHR

• 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].

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^[11] et les transactions qui forment ensemble le schéma de médication partagé^[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].

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 : 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].

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 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).

KMEHR est en production auprès de Vitalink, des progiciels intégrés, de la plate-forme eHealth, des réseaux hospitaliers 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) :

Au RSW, la migration a été motivée par le projet 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é.

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 ; 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), 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). - 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). - 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)) ; - 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)). - 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) et, pour Vitalink, sur Migration de Vitalink vers FHIR (de KMEHR vers Vitalink 2.0).

• 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é.
• 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)), 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.

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). 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].

• 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.
• 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).
• 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é.