Fiche de concept · Norme ou spécification
Affirmations : KMEHR
- Norme ou spécification
- normatif
- Belgique (fédéral/interfédéral)
- Architecture et infrastructure
- Médication et prescription
Identifiant Atlas kmehr · 129 affirmations · 74 sources · Dernière vérification08-10-2026
· Version 2026.11.12-3
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 »).
Voici les affirmations sur lesquelles repose la page consacrée à KMEHR : des faits courts, formulés par nous, chacun avec sa source et son emplacement vérifiable. Lire l'article · Comment fonctionne l'Atlas.
Affirmations 92 affirmations
| Affirmation | Type | Source | Emplacement | Date de référence |
|---|---|---|---|---|
| KMEHR a été introduit en 2002 comme implémentation de la quatrième recommandation de la Belgische Commissie voor Gezondheidstelematica et permet l'échange d'informations cliniques structurées. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'concerning KMEHR' | 25-09-2026 |
| Selon le site des standards, KMEHR se compose principalement d'un schéma XML comportant une grammaire de messages générale et simple, d'un ensemble de transactions médicales reconnues conformes à cette grammaire et d'un ensemble de tables de référence dont les valeurs peuvent être utilisées dans des messages KMEHR. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'concerning KMEHR' | 08-10-2026 |
| Ces éléments centraux de KMEHR sont complétés par des webservices qui sont mis en œuvre dans des initiatives concrètes en vue de l'échange standardisé de données entre systèmes. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'concerning KMEHR' | 08-10-2026 |
| Selon le tableau des versions du schéma XML KMEHR, la release v1.43.1 date du 2026-02-10. ↩ Montrer dans le texte Une erreur ? | fait | KMEHR XSchema - versions — eHealth-platform SRC-d0dfbfa787 | sectie Versions, tabel Kmehr releases | 25-09-2026 |
| L'architecture hub-métahub définit, comme partie de KMEHR, deux ensembles d'opérations de webservices: intrahub (du hub vers ses propres clients) et interhub (de hub à hub). ↩ Montrer dans le texte Une erreur ? | fait | KMEHR Web Services (hub-metahub intrahub/interhub) — eHealth-platform SRC-48cdc8b063 | inleiding Web Services | 25-09-2026 |
| Les services hub font partie de la spécification KMEHR; le stockage de dossiers médicaux (putTransaction) n'est pas une fonctionnalité standard d'un hub dans le projet hub-métahub. ↩ Montrer dans le texte Une erreur ? | fait | Hub service putTransaction: functional description (v1.1) — eHealth-platform (KMEHR); 26-03-2015 SRC-463e514ada | p. 2, Important remark | 25-09-2026 |
| Le RSW a mis à jour la définition KMEHR de ses webservices internes et externes (intrahub, interhub) et des cosites, du KMEHR-XSD 1.26 vers le 1.40.2; la modification est entrée en production le 25/03/2025. ↩ Montrer dans le texte Une erreur ? | fait | XSD : migration vers le KMEHR Version 1.40.2 — Réseau Santé Wallon (FRATEM); 14-02-2025 SRC-c99a273059 | kopregels (Impacts, Mise en production) en sectie 'Contexte' | 30-09-2026 |
| L'arrêté royal du 10/04/2025 (annexe 19, fonctionnalité de base 9 « Communication automatisée avec les hub's ») associe les rapports des opérations et le rapport d'anesthésie au profil de transaction KMEHR Report, et les rapports de consultations à Contact report. ↩ Montrer dans le texte Une erreur ? | fait | 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) — FOD Justitie – Belgisch Staatsblad (FOD Volksgezondheid als dossierbeheerder); 23-04-2025 SRC-64895c2195 | bijlage 19, tabel onder 3, regel 9, lijst van documenten (type) | 30-09-2026 |
| La même liste de l'arrêté royal associe les rapports des examens médico-techniques et les rapports d'imagerie médicale (radiologie, médecine nucléaire) au profil de transaction KMEHR Procedure result. ↩ Montrer dans le texte Une erreur ? | fait | 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) — FOD Justitie – Belgisch Staatsblad (FOD Volksgezondheid als dossierbeheerder); 23-04-2025 SRC-64895c2195 | bijlage 19, tabel onder 3, regel 9, lijst van documenten (type) | 30-09-2026 |
| Procedure result exige CD-TRANSACTION=result; des codes locaux peuvent être ajoutés en complément. ↩ Montrer dans le texte Une erreur ? | fait | Transaction: Procedure result — eHealth-platform; 15-10-2002 SRC-0c0f2431fb | Guidelines — Transaction elements, cd | 30-09-2026 |
| Les spécifications générales de dématérialisation Recip-e les plus récentes (version de document 20230224, publiée dans le paquet du 02/06/2023) citent KMEHR 1.28 comme la version actuelle pour le champ PrescriptionVersion. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e dematerialization specifications (20230224) — Recip-e vzw; 24-02-2023 SRC-387bd994e0 | p. 4, sectie 2 'General principles' | 30-09-2026 |
| Dans le cadre du plan d'action e-Santé 2019-2021 (cluster 0.5), HL7 FHIR est la norme préférentielle en Belgique: les nouveaux flux de données utilisent de préférence FHIR, les nouvelles interfaces de préférence FHIR REST. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'concerning FHIR' | 25-09-2026 |
| La transition de KMEHR vers FHIR se déroule en trois étapes: la publication des CareSets, une période pendant laquelle les coffres-forts santé, les fournisseurs de logiciels et les connecteurs se préparent et testent, et enfin une bascule coordonnée par laquelle FHIR devient opérationnel et KMEHR passe en lecture seule. ↩ Montrer dans le texte Une erreur ? | fait | BIHR: A general introduction — RIZIV/INAMI; 01-03-2026 SRC-c1669f1de8 | p. 9, sectie 'KMEHR → FHIR' | 26-09-2026 |
| La présentation BIHR définit « Point T » comme 12 mois après la publication du dernier CareSet patient summary. Que Point T soit le moment de la bascule coordonnée (FHIR opérationnel, KMEHR en lecture seule) découle vraisemblablement de la mise en page de la slide et n'y figure pas littéralement. ↩ Montrer dans le texte Une erreur ? | fait | BIHR: A general introduction — RIZIV/INAMI; 01-03-2026 SRC-c1669f1de8 | p. 9, sectie 'KMEHR → FHIR' | 26-09-2026 |
| Lors du BE FHIR-A-THON de juin 2026, CoZo a organisé, avec Amaron, un testatelier « Federated FHIR exchange » dans le cadre du projet SHIFT et de DIGIRELAB phase 3 (statut: test, pas de production). ↩ Montrer dans le texte Une erreur ? | fait | Test Atelier BE FHIR-A-THON June 2026 — Federated FHIR exchange — CoZo (in partnerschap met Amaron) SRC-6290028533 | p. 1, sectie 1 'Objective' | 30-09-2026 |
| Pour le testatelier, l'environnement hub de CoZo a été simulé par Amaron; les participants n'avaient pas besoin d'une connexion hub en direct. ↩ Montrer dans le texte Une erreur ? | fait | Test Atelier BE FHIR-A-THON June 2026 — Federated FHIR exchange — CoZo (in partnerschap met Amaron) SRC-6290028533 | p. 1, sectie 2 'Scope' | 30-09-2026 |
| Le Sumehr est une transaction KMEHR; la version 2.0 (date 2016-12-01, statut Published, propriétaire Plate-forme eHealth) exige KMEHR 20161201 ou plus récent; les logiciels devaient implémenter le Sumehr v2 pour fin 2019. ↩ Montrer dans le texte Une erreur ? | fait | Transaction: Summarised Electronic Healthcare Record v2.0 — eHealth-platform; 01-12-2016 SRC-5abd7569a4 | General information - Definition | 25-09-2026 |
| Le schéma de médication partagé est aujourd'hui une spécification KMEHR: les transactions « medicationscheme », « medicationschemeelement » et « treatmentsuspension » forment ensemble le schéma dans les coffres-forts santé régionaux (Vitalink, RSW, RSB-BGN), dans le cadre de VIDIS. ↩ Montrer dans le texte Une erreur ? | fait | Transaction: Medication Scheme — eHealth-platform; 23-08-2021 SRC-06c1cc40d4 | General information - Definition | 25-09-2026 |
| Une transaction KMEHR « contactreport » n'exige que le niveau de normalisation KMEHR 1; le contenu peut être transmis en texte libre ou comme objet multimédia encapsulé (p. ex. un document Word). ↩ Montrer dans le texte Une erreur ? | fait | KMEHR transaction: Contact report — eHealth-platform (KMEHR) SRC-efb08efe93 | Contact report - structuur | 25-09-2026 |
| Le service hub getTransactionList permet de rechercher au sein du hub local ou dans l'ensemble du système de hubs; il en existe aussi une variante interhub. ↩ Montrer dans le texte Une erreur ? | fait | getTransactionList (intrahub) — eHealth-platform (KMEHR) SRC-ce283ca193 | beschrijving | 25-09-2026 |
| Tous les échanges interhub reposent exclusivement sur le numéro d'identification de la sécurité sociale du patient. ↩ Montrer dans le texte Une erreur ? | fait | Hub service putTransaction: functional description (v1.1) — eHealth-platform (KMEHR); 26-03-2015 SRC-463e514ada | p. 3, Comments | 25-09-2026 |
| La description fonctionnelle de l'opération intrahub putTransaction date du 26/03/2015. ↩ Montrer dans le texte Une erreur ? | fait | Hub service putTransaction: functional description (v1.1) — eHealth-platform (KMEHR); 26-03-2015 SRC-463e514ada | p. 2, hoofding | 25-09-2026 |
| La plate-forme eHealth gère la norme KMEHR et le site des standards (section Standards, message-structure@ehealth.fgov.be). ↩ Montrer dans le texte Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'Standards News flash' | 25-09-2026 |
| Le site des standards de la plate-forme eHealth propose notamment le dernier XSD KMEHR, le validateur KMEHR et la liste OID/URI de la plate-forme eHealth. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'Also on this website' | 25-09-2026 |
| La version de schéma KMEHR la plus récente est la 1.43.1, publiée le 10/02/2026 (précédentes: 1.42.1 le 01/06/2025, 1.41 le 01/08/2024). KMEHR est donc encore activement maintenu. ↩ Montrer dans le texte Une erreur ? | fait | KMEHR News — eHealth-platform; 10-02-2026 SRC-141d7b01bc | nieuwsbericht 10/02/2026 'KMEHR 1.43.1 released' | 25-09-2026 |
| Selon le tableau des versions du schéma XML KMEHR, la release v1.42.1 date du 2025-06-01. ↩ Montrer dans le texte Une erreur ? | fait | KMEHR XSchema - versions — eHealth-platform SRC-d0dfbfa787 | sectie Versions, tabel Kmehr releases | 25-09-2026 |
| Selon le tableau des versions du schéma XML KMEHR, la release v1.41.0 date du 2024-08-01. ↩ Montrer dans le texte Une erreur ? | fait | KMEHR XSchema - versions — eHealth-platform SRC-d0dfbfa787 | sectie Versions, tabel Kmehr releases | 25-09-2026 |
| La release KMEHR 1.40.2 (2024-03-20) a ajouté les mediatypes « application/fhir+json » et « application/fhir+xml » à CD-MEDIATYPE, de sorte que du contenu FHIR peut être signalé dans des messages KMEHR. ↩ Montrer dans le texte Une erreur ? | fait | KMEHR XSchema - versions — eHealth-platform SRC-d0dfbfa787 | sectie 'Versions', release 2024-03-20 (v1.40.2), Request ESI-492 | 25-09-2026 |
| Le site des standards eHealth mentionne que les définitions de webservices hub-métahub publiées ont le statut « draft », bien que les opérations individuelles soient répertoriées comme « Published » (xsd-hubservices 3.6.0, 2024-03-27). ↩ Montrer dans le texte Une erreur ? | fait | KMEHR Web Services (hub-metahub intrahub/interhub) — eHealth-platform SRC-48cdc8b063 | inleiding Web Services | 25-09-2026 |
| La table de référence KMEHR CD-TRANSACTION (les types de transaction reconnus) est à la version 1.17 du 21/03/2024; certaines valeurs peuvent être obsolètes (deprecated) et la table renvoie au transactions cookbook. ↩ Montrer dans le texte Une erreur ? | fait | Reference Tables: Transaction (CD-TRANSACTION) — eHealth-platform; 21-03-2024 SRC-2a653e7548 | General information | 30-09-2026 |
| Volgens de standaardensite is de referentietabel CD-STANDARD (de laatste versie van de Belgische Healthcare Telematics Standard waaraan het bericht voldoet, gebruikt in het standard-element van de header) versie 1.45 van 2026-02-13; dat is een tabelversie, niet het versienummer van het XML-schema. ↩ Montrer dans le texte Une erreur ? | fait | Reference Tables: Standard version (CD-STANDARD) — eHealth-platform SRC-6ce68206b9 | General information | 08-10-2026 |
| La release de schéma KMEHR 1.43.1 (2026-02-10) a ajouté la valeur « ixchiq » à CD-VACCINEINDICATION (demande ESI-1114). ↩ Montrer dans le texte Une erreur ? | fait | KMEHR XSchema - versions — eHealth-platform SRC-d0dfbfa787 | versietabel, release v1.43.1 | 08-10-2026 |
| La transaction KMEHR Incapacity notification 2.2.1 (Production, iteration 1) figure sur le site des standards avec le statut Published; elle a été créée pour tenir compte d'une nouvelle mesure de janvier 2026. ↩ Montrer dans le texte Une erreur ? | fait | Transaction: Incapacity notification 2.2.1 (Production - Iteration 1) — eHealth-platform SRC-457de089b3 | Definition | 08-10-2026 |
| Le site des standards eHealth mentionne, pour le service interhub getTransactionList, le statut Published, la version 1.1 et la date 06/12/2018 (état au 30/09/2026). ↩ Montrer dans le texte Une erreur ? | fait | Webservice: getTransactionList (Interhub) — eHealth-platform; 06-12-2018 SRC-c14d973cdf | General information | 30-09-2026 |
| L'historique du document de la spécification getTransactionList ne mentionne que la version 1.0 (30/07/2010) et la version 1.1 (06/12/2018, adaptation pour l'accès du patient); une version 1.2 n'y figure pas. ↩ Montrer dans le texte Une erreur ? | fait | Interhub getTransactionList: functional description — eHealth-platform; 06-12-2018 SRC-4e7752a34e | p. 3, 1.1 Document history | 30-09-2026 |
| Déduction: le pied de page « v1.2 dd XXXX » dans le même PDF est probablement une ligne de modèle non complétée; la version publiée actuelle de l'interhub getTransactionList est la 1.1 (06/12/2018). Aucune version 1.2 n'a été trouvée sur le site des standards (30/09/2026). ↩ Montrer dans le texte Une erreur ? | interprétation | Interhub getTransactionList: functional description — eHealth-platform; 06-12-2018 SRC-4e7752a34e | voetregel p. 2-10 vs documenthistoriek p. 3 | 30-09-2026 |
| Le site des standards eHealth date la version 1.1 du service interhub getTransaction au 24/07/2019. ↩ Montrer dans le texte Une erreur ? | fait | Webservice: getTransaction (Interhub) — eHealth-platform; 24-07-2019 SRC-2f44b24632 | General information | 30-09-2026 |
| La spécification PDF liée de l'interhub getTransaction date toutefois la version 1.1 du 04/10/2018 (proposition BCP: ajouter l'ETK via ID-ENCRYPTION-KEY). ↩ Montrer dans le texte Une erreur ? | fait | Hub service 'getTransaction' – functional description (interhub) — eHealth-platform (G19 report); 04-10-2018 SRC-58ce0083af | p. 1, versietabel | 30-09-2026 |
| Chaque version de l'ehValidator est liée à une seule version de la norme KMEHR et à une seule version des spécifications du Sumehr et des formats de migration. ↩ Montrer dans le texte Une erreur ? | fait | ehValidator — eHealth-platform SRC-c07e4bcd21 | inleiding | 08-10-2026 |
| L'ehValidator le plus récent sur le site des standards (en haut du tableau des versions, 3.4.5, 2022-09-21) est lié à la version KMEHR 1.36.0, donc pas au schéma le plus récent 1.43.1. ↩ Montrer dans le texte Une erreur ? | fait | ehValidator — eHealth-platform SRC-c07e4bcd21 | Versions | 08-10-2026 |
| L'ehValidator valide les transactions KMEHR Sumehr et GP Software Migration Format sur le plan syntaxique et n'est pas adapté à la validation de la qualité du contenu médical. ↩ Montrer dans le texte Une erreur ? | fait | ehValidator — eHealth-platform SRC-c07e4bcd21 | inleiding | 08-10-2026 |
| Recip-e (prescription électronique) utilise KMEHR XML comme format de message entre prescripteurs et dispensateurs; les directives de contenu valent pour KMEHR 1.28 (valable à partir du 01/05/2020). ↩ Montrer dans le texte Une erreur ? | fait | Recip-e electronic prescriptions message content requirements for Kmehr version 1.28 — Recip-e vzw; 04-10-2019 SRC-3bb09e5840 | p. 3 | 25-09-2026 |
| Selon les directives de contenu de Recip-e (2019/2020), les prescriptions électroniques pouvaient s'appuyer sur KMEHR 1.28 à partir du 01/05/2020, et KMEHR 1.28 était obligatoire à partir du 01/06/2020. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e electronic prescriptions message content requirements for Kmehr version 1.28 — Recip-e vzw; 04-10-2019 SRC-3bb09e5840 | p. met versie-overgang (r. 260-261 van de extractie) | 25-09-2026 |
| Depuis la mise à jour du 23/03/2021, les directives de production Recip-e 2019-2020 sont obsolètes; elles ont été intégrées dans les spécifications générales de dématérialisation. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e — Change overview of package for software houses — Recip-e vzw; 02-06-2023 SRC-47191f855c | p. 2, update 23/03/2021 | 30-09-2026 |
| Le SDK Recip-e pour prescripteurs valide le KMEHR d'une nouvelle prescription contre kmehr-1.28.xsd et kmehr_elements-1.28.xsd, livrés avec la release du SDK. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e dematerialization specifications (20230224) — Recip-e vzw; 24-02-2023 SRC-387bd994e0 | p. 16, sectie 4.3 'Format and content verification' | 30-09-2026 |
| Vitalink utilise aujourd'hui la norme KMEHR, tout comme les progiciels intégrés, la plate-forme eHealth, les réseaux hospitaliers et les autres coffres-forts santé. ↩ Montrer dans le texte Une erreur ? | fait | Evoluties (HL7 FHIR) — Vitalink (Departement Zorg) SRC-e8d2c7c6db | pagina 'Evoluties' | 25-09-2026 |
| Vitalink fonctionne (en 2026) avec deux environnements: FHIR comme norme actuelle et un environnement KMEHR legacy encore utilisé notamment pour le schéma de médication partagé, le Sumehr, le Kindrapport et les éléments de journal (accès via liste blanche). ↩ Montrer dans le texte Une erreur ? | fait | Als zorgorganisatie connecteren met Vitalink? — Vitalink (Departement Zorg) SRC-9cd73706d9 | sectie 'Legacy KMEHR-omgeving' | 25-09-2026 |
| Les interfaces techniques entre les hubs et avec le métahub sont des « webservices standard » (appelés « webservices KMEHR ») dont la spécification est publiée par la Plate-forme eHealth. ↩ Montrer dans le texte Une erreur ? | fait | Reglement betreffende de uitwisseling van gezondheidsgegevens tussen gezondheidssystemen verbonden via het verwijzingsrepertorium van het eHealth-platform — eHealth-platform / Informatieveiligheidscomité; 18-02-2014 SRC-f4d7f1af3a | p. 17 | 25-09-2026 |
| Avec la migration vers KMEHR 1.40.2, les webservices du RSW acceptent entre autres les nouvelles valeurs CD-TRANSACTION belrai-report, nursingsummaryreport, pharmaceuticalmedicationscheme et geriatrictransferreport. ↩ Montrer dans le texte Une erreur ? | fait | XSD : migration vers le KMEHR Version 1.40.2 — Réseau Santé Wallon (FRATEM); 14-02-2025 SRC-c99a273059 | sectie 'Ajouts dans la nouvelle version du XSD' — CD-TRANSACTION values | 30-09-2026 |
| Selon le RSW, la migration vers KMEHR 1.40.2 a eu un impact sur l'interhub, l'intrahub et les cosites, avec une mise en production le 25/03/25. ↩ Montrer dans le texte Une erreur ? | fait | XSD : migration vers le KMEHR Version 1.40.2 — Réseau Santé Wallon (FRATEM); 14-02-2025 SRC-c99a273059 | kopregels van de pagina | 30-09-2026 |
| Les échanges via le RSB se font selon le standard belge KMEHR; les documents accessibles sont des pdf. ↩ Montrer dans le texte Une erreur ? | fait | Notre mission — Abrumet asbl SRC-02ef82d3e2 | sectie missies | 26-09-2026 |
| Avant cette migration, les webservices du RSW (intra/interhub) utilisaient un XSD KMEHR fédéral qui n'avait plus été mis à jour depuis très longtemps; le déclencheur de la mise à jour a été le projet DIGIRELAB et les media types FHIR. ↩ Montrer dans le texte Une erreur ? | fait | XSD : migration vers le KMEHR Version 1.40.2 — Réseau Santé Wallon (FRATEM); 14-02-2025 SRC-c99a273059 | sectie 'Contexte' | 30-09-2026 |
| Pour les services hub, le RSW renvoie à Hub Services version 3.5.3, le XSD KMEHR 1.22 fourni dans le package devant être remplacé par le XSD 1.40. ↩ Montrer dans le texte Une erreur ? | fait | XSD : migration vers le KMEHR Version 1.40.2 — Réseau Santé Wallon (FRATEM); 14-02-2025 SRC-c99a273059 | sectie 'Références' | 30-09-2026 |
| Au RSW, les définitions des webservices des cosites sont permissives: les valeurs qui constituent des énumérations strictes dans les webservices fédéraux intra-/interhub sont le plus souvent des valeurs libres au niveau du cosite. ↩ Montrer dans le texte Une erreur ? | fait | XSD : migration vers le KMEHR Version 1.40.2 — Réseau Santé Wallon (FRATEM); 14-02-2025 SRC-c99a273059 | sectie 'Points d'attention — Pour les cosites' | 30-09-2026 |
| Le RSW gère les droits d'accès par défaut par type de document; pour les données décentralisées externes, les règles d'accès au niveau documentaire sont du ressort du système partenaire qui publie ces données. ↩ Montrer dans le texte Une erreur ? | fait | Annexe 1 : Table des règles d'accès — Réseau Santé Wallon (FRATEM) SRC-1191040c19 | sectie 'Droits d’accès par catégorie de données de santé pour les prestataires de soins' | 30-09-2026 |
| Au RSW, la classification d'un document détermine en partie l'accès: un accès « limité » ne donne à un prestataire de soins accès qu'aux documents de son groupe professionnel ou aux documents classés explicitement comme relevant de cette spécialité (typiquement des documents des services hospitaliers correspondants). ↩ Montrer dans le texte Une erreur ? | fait | Annexe 1 : Table des règles d'accès — Réseau Santé Wallon (FRATEM) SRC-1191040c19 | sectie 'Remarques et précisions' | 30-09-2026 |
| La liste de l'arrêté royal mentionne aussi les lettres de sortie (Discharge letter), les lettres de transfert (Referral letter), les résultats de laboratoire (Laboratory result), les rapports liés aux activités postérieures à une prescription électronique (Medication scheme (element), Pharmaceutical prescription) et les attestations médico-administratives. ↩ Montrer dans le texte Une erreur ? | fait | 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) — FOD Justitie – Belgisch Staatsblad (FOD Volksgezondheid als dossierbeheerder); 23-04-2025 SRC-64895c2195 | bijlage 19, tabel onder 3, regel 9, lijst van documenten (type) | 30-09-2026 |
| La circulaire BMUC du 11/03/2024 utilisait la même liste, intitulée « Lijst van type documenten en hun metadata », pour l'indicateur « Geautomatiseerde communicatie met HUB's ». ↩ Montrer dans le texte Une erreur ? | fait | Omzendbrief aan de beheerders van ziekenhuizen — BMUC Acceleratorprogramma 2024 — FOD Volksgezondheid, DG Gezondheidszorg; 11-03-2024 SRC-f61161acce | p. 10, bijlage indicatoren, rij 9 'Geautomatiseerde communicatie met HUB's' | 30-09-2026 |
| Le profil KMEHR Procedure result (1.0, 2002) sert aux résultats d'un examen technique qui est typiquement identifié comme prestation dans la nomenclature de l'INAMI; les examens cliniques relèvent de Contact report et les résultats de laboratoire de Laboratory result. ↩ Montrer dans le texte Une erreur ? | fait | Transaction: Procedure result — eHealth-platform; 15-10-2002 SRC-0c0f2431fb | General information — DEFINITION | 30-09-2026 |
| Procedure result n'exige que le niveau de normalisation KMEHR 1; le résultat peut être transmis en texte libre, comme objet multimédia encapsulé ou au moyen d'items. ↩ Montrer dans le texte Une erreur ? | fait | Transaction: Procedure result — eHealth-platform; 15-10-2002 SRC-0c0f2431fb | Guidelines — Generalities | 30-09-2026 |
| Le profil KMEHR Referral letter exige CD-TRANSACTION=referral; des codes locaux peuvent être ajoutés en complément. ↩ Montrer dans le texte Une erreur ? | fait | Transaction: Referral letter — eHealth-platform; 15-10-2002 SRC-e065e3591b | Guidelines — Transaction elements, cd | 30-09-2026 |
| Le profil Report 1.0 exige la valeur « report » de CD-TRANSACTION; des codes locaux propres peuvent toujours être ajoutés. ↩ Montrer dans le texte Une erreur ? | fait | Report — eHealth-platform; 10-07-2013 SRC-df3a3774bc | Guidelines, element cd | 08-10-2026 |
| La table de référence CD-TRANSACTION-TYPE contient les spécialisations des transactions; certaines valeurs peuvent être obsolètes et toutes les valeurs ne peuvent pas être combinées avec toutes les valeurs de CD-TRANSACTION (voir le transactions cookbook). ↩ Montrer dans le texte Une erreur ? | fait | CD-TRANSACTION-TYPE — eHealth-platform; 01-08-2023 SRC-e000bd4d35 | Description | 08-10-2026 |
| Bestaande gegevensstromen worden aangemoedigd om in toekomstige iteraties naar FHIR te migreren of uit te breiden; migratie van eHealth-basisdiensten naar FHIR is iteratief, geleidelijk en 'best effort'. ↩ Montrer dans le texte Une erreur ? | fait | Vision statement HL7 FHIR (v1.0) — eHealth-platform; 28-05-2019 SRC-e58cf74e18 | p. 6, secties 5.4-5.5 | 25-09-2026 |
| Het eHealth-platform stelt dat een omzetting van KMEHR-stromen naar FHIR zonder extra inspanning op codering en structurering weinig meerwaarde biedt, en dat een 'big bang'-scenario niet mogelijk is. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'concerning FHIR' | 25-09-2026 |
| FHIR devient le standard pour l'échange de données dans le BIHR, conformément aux profils belges; les flux KMEHR existants restent pris en charge en lecture seule, les échanges nouveaux et modifiés passent par FHIR à partir de 2028. ↩ Montrer dans le texte Une erreur ? | fait | Het BIHR (Belgian Integrated Health Record) — RIZIV SRC-bedb8ce40f | sectie 'FHIR wordt de standaard voor data-uitwisseling' | 25-09-2026 |
| Au sein du BIHR, la transition de KMEHR vers FHIR se déroule progressivement; les échanges nouveaux et modifiés passent par FHIR à partir de 2028. ↩ Montrer dans le texte Une erreur ? | fait | Het BIHR (Belgian Integrated Health Record) — RIZIV SRC-bedb8ce40f | sectie FHIR wordt de standaard voor data-uitwisseling | 25-09-2026 |
| Het digitaal verwijsvoorschrift heeft een gepubliceerde CareSet, "Digital Referral Prescription (DRP)". De bron vermeldt KMEHR niet; dat de stroom rechtstreeks naar FHIR gaat zonder KMEHR-tussenstap, is een eigen afleiding. ↩ Montrer dans le texte Une erreur ? | interprétation | Overzicht van gepubliceerde CareSets | RIZIV — RIZIV SRC-b4f8ecf2f8 | sectie 'CareSet "Digital Referral Prescription (DRP)"' | 26-09-2026 |
| Le portail des IG de la plate-forme eHealth énumère 18 IG (core, vaccination, allergy, medication, core-clinical, mycarenet, lab, public-health, infsec, patientwill, nihdi-terminology, patient-care, pss, drp, referral, patient-dossier, childreport, pregnancy-status); DRP y est marqué comme deprecated et remplacé par Referral. ↩ Montrer dans le texte Une erreur ? | fait | FHIR IG-portaal: projectenlijst (projects.js) — eHealth-platform SRC-85fbc850b0 | projects-array, order 14 | 25-09-2026 |
| Overheden, zorgverleners en industrie hebben samen beslist de huidige KMEHR-datatypes (in Vitalink) geleidelijk te vervangen door FHIR CareSets. ↩ Montrer dans le texte Une erreur ? | fait | FHIR-documentatie — Vitalink (Departement Zorg) SRC-6e9d5d427a | inleiding FHIR-documentatie | 25-09-2026 |
| L'environnement Vitalink FHIR a été mis en production (message du 22 mars 2024) et se trouve à côté de l'environnement KMEHR existant. ↩ Montrer dans le texte Une erreur ? | fait | Nieuwe FHIR-omgeving van Vitalink in productie! — Vitalink (Departement Zorg); 22-03-2024 SRC-a7e3a494e9 | nieuwsbericht | 25-09-2026 |
| Depuis le 1er juillet 2025, les données des dépistages organisés du cancer (CVKO) ne sont plus disponibles que via Vitalink FHIR; la consultation via KMEHR a été arrêtée. ↩ Montrer dans le texte Une erreur ? | fait | Nieuws | Vitalink — Vitalink (Departement Zorg) SRC-e85b9ba17a | nieuwsbericht 01/07/2025 | 25-09-2026 |
| La README du dépôt GitHub « fhir-ehealth-hub-simulator » (compte personnel, non officiel) décrit une implémentation de référence côté serveur qui modernise des transactions legacy KMEHR/SOAP. ↩ Montrer dans le texte Une erreur ? | fait | Belgian eHealth Interhub FHIR Simulator — GitHub (nhermab) SRC-1abe55e4ec | README, eerste alinea | 08-10-2026 |
| Cette même README indique que cette modernisation se fait vers IHE MHD (Mobile access to Health Documents) sur HL7 FHIR R4. ↩ Montrer dans le texte Une erreur ? | fait | Belgian eHealth Interhub FHIR Simulator — GitHub (nhermab) SRC-1abe55e4ec | README, eerste alinea | 08-10-2026 |
| Un projet GitHub HubsOnFHIR (organisation ehealthplatformstandards) porte sur la manière dont le système belge des hubs et du métahub adoptera FHIR. ↩ Montrer dans le texte Une erreur ? | fait | HubsOnFHIR - How will the Belgian HUB/METAHUB system embrace FHIR — eHealth-platform (GitHub ehealthplatformstandards); 20-06-2023 SRC-1b19ae6fc4 | README; repository-metadata (aangemaakt en laatste push 2023-06-20) | 01-10-2026 |
| Interprétation des métadonnées du dépôt (métadonnées du dépôt consultées le 2026-10-08): le projet HubsOnFHIR a été créé le 2023-06-20 et n'a plus reçu de nouveaux commits depuis; les issues datent de juin-juillet 2023, de sorte qu'aucun développement public actuel d'un rôle FHIR ou de courtier pour les hubs n'y a été trouvé. ↩ Montrer dans le texte Une erreur ? | interprétation | HubsOnFHIR - How will the Belgian HUB/METAHUB system embrace FHIR — eHealth-platform (GitHub ehealthplatformstandards); 20-06-2023 SRC-1b19ae6fc4 | repository-metadata (aangemaakt en laatste push 2023-06-20); README | 08-10-2026 |
| Le GitHub transversal « FHIR Strategy in Belgian eHealth Ecosystem » mentionne HubsOnFHIR (comment le système hubs-métahub adopte FHIR). ↩ Montrer dans le texte Une erreur ? | fait | FHIR Strategy in Belgian eHealth Ecosystem (transversale GitHub) — eHealth-platform (GitHub-organisatie ehealthplatformstandards) SRC-203619df0c | README | 08-10-2026 |
| Le testatelier utilisait une configuration simplifiée (patients synthétiques, pas de sécurité eHealth formelle, VPN) et se présente comme une étape vers un échange FHIR fédéré. ↩ Montrer dans le texte Une erreur ? | fait | Test Atelier BE FHIR-A-THON June 2026 — Federated FHIR exchange — CoZo (in partnerschap met Amaron) SRC-6290028533 | p. 1, sectie 1 'Objective' | 30-09-2026 |
| Selon la documentation d'Abrumet destinée aux développeurs (dernière modification le 14/03/2017), l'environnement Brusafe+ utilise des composants conformes à IHE XDS. ↩ Montrer dans le texte Une erreur ? | fait | IHE XDS Components (Brusafe+) — Abrumet SRC-d81b432dd2 | inleiding | 30-09-2026 |
| Dans la même documentation (2017), l'échange entre environnements XDS passe par une passerelle XCA, tandis que la communication entre Brusafe+ et le Réseau Santé Bruxellois repose sur le standard KMEHR. ↩ Montrer dans le texte Une erreur ? | fait | IHE XDS Components (Brusafe+) — Abrumet SRC-d81b432dd2 | secties 'Initiating- and Responding Gateway' en 'Integration module' | 30-09-2026 |
| 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; c'est une affirmation de la source, et non une date ni une décision. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e veut devenir l'interlocuteur des prestataires dans la e-santé — Le Spécialiste; 24-06-2026 SRC-1b802d4881 | artikel over het jaarrapport 2025 van Recip-e | 08-10-2026 |
| Condition c): la consultation, par les prestataires de soins de l'institution et par l'intermédiaire des hubs et des coffres-forts sanitaires, des informations de santé d'autres institutions, du SumEHR et du schéma de médication. ↩ Montrer dans le texte Une erreur ? | fait | 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 — Belgisch Staatsblad (spiegel etaamb.openjustice.be); 23-04-2025 SRC-c2bc38d00b | art. 17 (art. 61 § 2, 2°, c) | 25-09-2026 |
| La fonctionnalité core 15 des BMUC 2016 (« communication automatisée avec les hubs et interaction avec e-Health ») exige notamment l'utilisation de l'eHealthBox et la consultation, par les prestataires de soins de l'institution et via les hubs, des dossiers de santé (autres institutions, SUMEHR, schéma de médication). ↩ Montrer dans le texte Une erreur ? | fait | Belgian Meaningful Use Criteria (BMUC) voor algemene ziekenhuizen (versie 0.1, 22/08/2016) - Wayback-kopie — FOD Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu; 22-08-2016 SRC-7254da6e19 | p. 18, functionaliteit 15 | 25-09-2026 |
| Selon la ministre (réponse de 2025), tous les hôpitaux ont accès à Vitalink KMEHR (schémas de médication partagés, Sumehr, vaccinations), mais ce flux ne se déroule pas toujours de manière optimale, parfois par un détour via la métahub. ↩ Montrer dans le texte Une erreur ? | fait | Schriftelijke vraag nr. 327 van 5 februari 2025 (een Vlaams volksvertegenwoordiger) en antwoord van de Vlaamse minister van Welzijn - Zorgvoorzieningen: optimalisatie digitale gegevensverzameling — Vlaams Parlement; 05-02-2025 SRC-a3b502aed4 | p. 2, antwoord vraag 1, 'Huidige situatie' | 25-09-2026 |
| Les hôpitaux doivent annoter toutes les données partagées par l'intermédiaire du système hubs-metahub avec les métadonnées appropriées (définies par les règlements de la plate-forme eHealth), afin que le délai de publication et les statistiques puissent être contrôlés. ↩ Montrer dans le texte Une erreur ? | fait | 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 — Belgisch Staatsblad (spiegel etaamb.openjustice.be); 23-04-2025 SRC-c2bc38d00b | art. 17 (art. 61 § 2, 2°, na punt f) | 25-09-2026 |
| Le RSW avertit que les partenaires peuvent avoir établi leurs règles métier sur la base d'anciennes versions des XSD et que l'arrivée des nouvelles métadonnées (valeurs) doit dès lors leur être signalée. ↩ Montrer dans le texte Une erreur ? | fait | XSD : migration vers le KMEHR Version 1.40.2 — Réseau Santé Wallon (FRATEM); 14-02-2025 SRC-c99a273059 | sectie 'Points d'attention — Pour les cosites' | 30-09-2026 |
| La plate-forme eHealth formule FHIR comme norme préférentielle: les nouveaux flux de données utilisent « de préférence » FHIR; il s'agit d'une préférence politique, pas d'une obligation réglementaire. ↩ Montrer dans le texte Une erreur ? | fait | About FHIR — eHealth-platform SRC-ff53eb8437 | pagina 'About FHIR' | 01-10-2026 |
| Abrumet indiquait (page du 07/01/2020) que l'eHealth belge n'utilise que KMEHR et que Brusafe+ fait le pont, via XDS/CDA et un mapping, vers les standards internationaux; les données du métahub sont à cette occasion mappées de KMEHR vers CDA. ↩ Montrer dans le texte Une erreur ? | fait | About Brusafe+ — Abrumet SRC-32c4c82d84 | kader bovenaan de pagina | 30-09-2026 |
| Techniquement, le coffre-fort BruSafe du RSB est un référentiel KMEHR qui héberge des documents au format pdf, destiné aux prestataires de soins de première ligne ne disposant pas d'un serveur propre. ↩ Montrer dans le texte Une erreur ? | fait | De kluis Brusafe+ — Abrumet vzw SRC-42b7c220d9 | sectie 'De Brusafe-kluis van het Brussels Gezondheidsnetwerk' | 26-09-2026 |
| L'aperçu des modifications Recip-e pour les maisons de logiciels a comme dernière mise à jour le 02/06/2023 (documentation relative au partage des prescriptions avec le patient); aucune mise à jour de paquet ultérieure n'y est mentionnée. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e — Change overview of package for software houses — Recip-e vzw; 02-06-2023 SRC-47191f855c | p. 1 | 30-09-2026 |
| La loi charge également la Plate-forme eHealth de fixer les normes, standards, spécifications et l'architecture de base fonctionnels et techniques liés aux TIC. ↩ Montrer dans le texte Une erreur ? | fait | Wet van 21 augustus 2008 houdende oprichting en organisatie van het eHealth-platform (geconsolideerde tekst) — eHealth-platform; 13-10-2008 SRC-4a2ff3f425 | art. 5, 2° | 25-09-2026 |
| Selon la page des standards de la plate-forme eHealth, les standards que la plate-forme fixe ne portent que sur les aspects TIC et non sur les aspects de contenu des soins de santé. ↩ Montrer dans le texte Une erreur ? | fait | Standaarden — eHealth-platform SRC-1100bcc41d | inleiding | 08-10-2026 |
Non reprises dans le texte 37 affirmations
Ces affirmations proviennent des mêmes sources et ont été vérifiées, mais l'article consacré à KMEHR ne les utilise pas (encore).
| Affirmation | Type | Source | Emplacement | Date de référence |
|---|---|---|---|---|
| Pour declareTransaction, la spécification recommande fortement le numéro d'identification de la sécurité sociale, mais un hub peut autoriser en intrahub un système local d'identification du patient. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 3, Comments | 27-09-2026 |
| La liste des auteurs de la réponse interhub doit comporter comme premier hcparty le hub qui répond. Une erreur ? | fait | Interhub getTransactionList: functional description — eHealth-platform; 06-12-2018 SRC-4e7752a34e | p. 9, author | 27-09-2026 |
| Laboratory result 1.1 recommande zéro, un ou plusieurs codes CD-LABORESULT-TYPE pour décrire les sujets du rapport de laboratoire. Une erreur ? | fait | KMEHR transaction: Laboratory result — eHealth-platform; 01-07-2022 SRC-af1784d473 | Guidelines, cd | 27-09-2026 |
| L'interhub getTransactionList décrit l'accès du patient aux transactions au moyen de codes locaux optionnels. Une erreur ? | fait | Interhub getTransactionList: functional description — eHealth-platform; 06-12-2018 SRC-4e7752a34e | p. 9, Patient access | 27-09-2026 |
| declareTransaction 1.0 exige le champ iscomplete avec la cardinalité [1], pour indiquer si le document est complet. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 4, iscomplete | 27-09-2026 |
| Déduction: si l'on combine la liste de l'arrêté royal (annexe 19, ligne 9) avec les profils figurant sur le site des standards eHealth, les rapports des opérations et le rapport d'anesthésie sont publiés comme CD-TRANSACTION « report », et les rapports d'imagerie médicale et les rapports des examens médico-techniques comme « result ». L'arrêté royal ne cite que des noms de profils, pas des codes; il ne fixe ni les codes de spécialisation (CD-TRANSACTION-TYPE) ni les champs de monitoring. Une erreur ? | interprétation | 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) — FOD Justitie – Belgisch Staatsblad (FOD Volksgezondheid als dossierbeheerder); 23-04-2025 SRC-64895c2195 | combinatie van bmuc-epd-criteria-01/02 met kmehr-03 en bestaande claim Report 1.0 (CLM-8ae5e5d2) | 30-09-2026 |
| Le profil KMEHR Contact report documente les consultations, les visites aux urgences et les visites à domicile. Une erreur ? | fait | Contact report — eHealth-platform; 15-10-2002 SRC-ebae814f05 | Definition | 27-09-2026 |
| Domus Medica (source secondaire) écrit KMEHR en entier comme « Kind Messages for Electronic Healthcare Record » (au singulier). Une erreur ? | fait | Eénheid van taal & standaardisatie | Domus Medica — Domus Medica SRC-f193564291 | pagina 'Eénheid van taal & standaardisatie', alinea over KMEHR en FHIR | 25-09-2026 |
| Le profil Discharge letter 1.0 exige la valeur « dischargereport » de CD-TRANSACTION; des codes locaux propres peuvent toujours être ajoutés. Une erreur ? | fait | Discharge letter — eHealth-platform; 15-10-2002 SRC-3785eaa704 | Guidelines, element cd | 08-10-2026 |
| Dans Discharge letter, isvalidated=false signifie que l'information n'a pas été validée médicalement; la définition du champ elle-même n'impose donc pas toujours la valeur true. Une erreur ? | fait | Discharge letter — eHealth-platform; 15-10-2002 SRC-3785eaa704 | Guidelines, isvalidated | 27-09-2026 |
| Discharge letter 1.0 exige CD-TRANSACTION=dischargereport; des codes locaux peuvent être ajoutés en complément. Une erreur ? | fait | Discharge letter — eHealth-platform; 15-10-2002 SRC-3785eaa704 | Guidelines, cd | 27-09-2026 |
| La date générique de transaction KMEHR renvoie généralement à l'événement médical, mais sa signification peut varier selon le type de transaction. Une erreur ? | fait | Transaction — general structure — eHealth-platform SRC-6e9b27b727 | date/time | 27-09-2026 |
| Contact report 1.0 exige CD-TRANSACTION=contactreport; des codes locaux peuvent être ajoutés en complément. Une erreur ? | fait | Contact report — eHealth-platform; 15-10-2002 SRC-ebae814f05 | Guidelines, cd | 27-09-2026 |
| Selon la version 1.1, la transaction KMEHR Laboratory result exige au minimum le niveau de normalisation 1. Une erreur ? | fait | KMEHR transaction: Laboratory result — eHealth-platform; 01-07-2022 SRC-af1784d473 | Guidelines / Generalities | 27-09-2026 |
| Dans declareTransaction 1.0, recorddatetime est obligatoire ([1]) et signifie la date et l'heure d'enregistrement dans le système appelant. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 5, recorddatetime [1] | 27-09-2026 |
| declareTransaction demande une description minimale de la transaction comportant l'identification du patient et au moins un type de transaction reconnu. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 2, Input parameters | 27-09-2026 |
| La même spécification KMEHR annonce une évolution vers une spécification HL7 FHIR pour les résultats de laboratoire. Une erreur ? | fait | KMEHR transaction: Laboratory result — eHealth-platform; 01-07-2022 SRC-af1784d473 | IMPORTANT | 27-09-2026 |
| Une implémentation de référence qui modernise les transactions interhub KMEHR/SOAP getTransactionList et getTransaction vers IHE MHD sur HL7 FHIR R4 existe dans un dépôt non officiel. Une erreur ? | affirmation du fournisseur | Belgian eHealth Interhub FHIR Simulator — GitHub (nhermab) SRC-1abe55e4ec | README | 25-09-2026 |
| Le profil Report 1.0 exige CD-TRANSACTION=report; des codes locaux peuvent être ajoutés en complément. Une erreur ? | fait | Report — eHealth-platform; 10-07-2013 SRC-df3a3774bc | Guidelines, cd | 27-09-2026 |
| Le profil Contact report 1.0 exige la valeur « contactreport » de CD-TRANSACTION; des codes locaux propres peuvent toujours être ajoutés. Une erreur ? | fait | Contact report — eHealth-platform; 15-10-2002 SRC-ebae814f05 | Guidelines, element cd | 08-10-2026 |
| Dans Laboratory result, date est la date de rapportage; si la date d'exécution en diffère, elle doit, selon le profil, figurer au niveau de l'item. Une erreur ? | fait | KMEHR transaction: Laboratory result — eHealth-platform; 01-07-2022 SRC-af1784d473 | Guidelines, date | 27-09-2026 |
| Laboratory result 1.1 exige CD-TRANSACTION=labresult; des codes locaux peuvent être ajoutés en complément. Une erreur ? | fait | KMEHR transaction: Laboratory result — eHealth-platform; 01-07-2022 SRC-af1784d473 | Guidelines, cd | 27-09-2026 |
| Le paramètre request de declareTransaction regroupe le request-id, la date, l'heure et l'expéditeur. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 3, Input data | 27-09-2026 |
| Le profil Laboratory result 1.1 exige la valeur « labresult » de CD-TRANSACTION; des codes locaux propres peuvent toujours être ajoutés. Une erreur ? | fait | KMEHR transaction: Laboratory result — eHealth-platform; 01-07-2022 SRC-af1784d473 | Guidelines, element cd | 08-10-2026 |
| La spécification de declareTransaction indique que tous les échanges interhub reposent exclusivement sur le numéro d'identification de la sécurité sociale. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 3, Comments | 27-09-2026 |
| KMEHR se compose d'un schéma XML (grammaire de messages), d'un ensemble de transactions médicales reconnues et de tables de référence, le tout complété par des webservices. Une erreur ? | fait | eHealth Platform Standards - Home (KMEHR) — eHealth-platform SRC-bd069bf1c8 | sectie 'concerning KMEHR' | 25-09-2026 |
| CD-TRANSACTION-TYPE contient des spécialisations et toutes les valeurs ne peuvent pas être combinées avec tous les codes CD-TRANSACTION. Une erreur ? | fait | CD-TRANSACTION-TYPE — eHealth-platform; 01-08-2023 SRC-e000bd4d35 | Description | 27-09-2026 |
| L'auteur porte la responsabilité médicale et doit identifier au moins une personne physique; la spécialité et l'organisation peuvent être mentionnées en complément. Une erreur ? | fait | Transaction — general structure — eHealth-platform SRC-6e9b27b727 | author | 27-09-2026 |
| declareTransaction 1.0 exige le champ isvalidated avec la cardinalité [1]. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 4, isvalidated; toelichting loopt verder op p. 5 | 27-09-2026 |
| Lors d'une mise à jour via declareTransaction, le patient et le ou les auteurs ne peuvent pas changer. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 2, Post-condition | 27-09-2026 |
| La liste des auteurs de declareTransaction doit contenir au moins une personne physique et va de l'acteur le plus global à l'acteur le plus spécifique. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 4, author, toelichtende prozatekst | 27-09-2026 |
| Le profil Discharge letter est destiné à résumer un séjour hospitalier et s'adresse généralement au médecin de première ligne. Une erreur ? | fait | Discharge letter — eHealth-platform; 15-10-2002 SRC-3785eaa704 | Definition | 27-09-2026 |
| Selon getTransactionList 1.1, en l'absence d'information sur l'accès du patient, la transaction n'est pas accessible au patient. Une erreur ? | fait | Interhub getTransactionList: functional description — eHealth-platform; 06-12-2018 SRC-4e7752a34e | p. 9, cd patient access | 27-09-2026 |
| L'expéditeur de declareTransaction doit au moins identifier l'organisation responsable du système appelant. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 3, Comments | 27-09-2026 |
| La description minimale de la transaction pour declareTransaction contient l'identification dans le système appelant, le ou les auteurs médicalement responsables, la date et l'heure médicales ainsi que la date et l'heure d'enregistrement dans ce système. Une erreur ? | fait | Hub service declareTransaction: functional description — eHealth-platform; 30-07-2010 SRC-88b3c750f4 | p. 2, Input parameters | 27-09-2026 |
| Dans Contact report, au moins un hcparty doit identifier une personne, avec un ID-HCPARTY obligatoire; son numéro d'identification de la sécurité sociale est recommandé. Une erreur ? | fait | Contact report — eHealth-platform; 15-10-2002 SRC-ebae814f05 | Guidelines, author | 27-09-2026 |
| Le profil générique Report porte sur les résultats intermédiaires ou définitifs d'une action. Une erreur ? | fait | Report — eHealth-platform; 10-07-2013 SRC-df3a3774bc | Definition | 27-09-2026 |