Lors du partage de rapports hospitaliers via le hub, l'hôpital conserve lui-même le document et publie une référence qui permet à d'autres prestataires de soins de le retrouver. Le métahub oriente la requête vers le hub régional compétent ; la consultation exige généralement un consentement, une relation thérapeutique et des droits d'accès. L'échange est en production et utilise des services web KMEHR, une transition vers FHIR étant prévue pour les flux nouveaux ou modifiés. Pour les hôpitaux généraux, une publication en temps utile avec des métadonnées correctes est une condition de financement BMUC.
", "last_verified": "2026-10-05", "verification_outdated": false, "sections": [ { "id": "qu-est-ce-que-c-est", "title": "Qu'est-ce que c'est ?", "kind": "tekst", "html": "Un hôpital général flamand souhaite que le médecin généraliste, d'autres hôpitaux et le patient lui-même puissent\nconsulter les rapports et les résultats d'une hospitalisation ou d'une consultation. Acteurs : l'hôpital (service\ndes admissions, médecin traitant, DPI), le hub (en Flandre, entre autres CoZo (Collaboratief Zorgplatform) ou le VZN-hub), la\nPlate-forme eHealth avec le métahub, le médecin généraliste avec son dossier médical électronique, et le patient.\nLe schéma est décrit sur Hubs & Metahub (répertoire des références).
" }, { "id": "qui-echange-quoi-et-via-quel-canal", "title": "Qui échange quoi et via quel canal ?", "kind": "tekst", "html": "Étape 1 — Consentement lors de l'admission. Le consentement éclairé vaut au niveau national et peut notamment\nêtre enregistré par le service des admissions de l'hôpital, généralement avec l'eID[1]. Dans un\ncontexte hospitalier, un hub peut autoriser un enregistrement sur la seule base du numéro d'identification de la\nsécurité sociale, à condition que la présence du patient et une information effective soient garanties\n[2]. Du personnel administratif peut également, sous la responsabilité d'un médecin, gérer le\nconsentement via eHealthConsent[3]. Depuis la modification législative du 23 novembre 2023, des\nréférences peuvent être enregistrées sauf si le patient s'y oppose, mais la consultation par d'autres que le\npatient requiert toujours son consentement[4]. Voir Consentement éclairé au partage de données.
\nÉtape 2 — Relation thérapeutique. L'inscription dans un hôpital vaut comme preuve d'une relation thérapeutique\navec les prestataires de soins traitants ; la note formule cela comme une possibilité (« peut être considérée »)\n[5]. La durée de validité de ces droits d'accès peut être fixée à trois mois après une hospitalisation\nou un traitement ambulatoire, renouvelable lors d'un nouveau contact[5], et à un mois après un\ncontact aux urgences ou MUG sans hospitalisation[5]. Si une hospitalisation suit le contact aux\nurgences, c'est le délai d'hospitalisation qui s'applique[5]. Les médecins non concernés ne peuvent\npas s'en prévaloir[5]. Voir Relation thérapeutique.
\nÉtape 3 — Établir et valider le document. Un « contactreport » KMEHR n'exige qu'un niveau de normalisation 1 ;\nle contenu peut être du texte libre ou un document encapsulé[6]. Dans son avis CFEH/D/577-2 du\n9 mars 2023, portant sur un projet antérieur de la réglementation BMUC, le CFEH a souligné que les documents\ndoivent être validés au préalable par le médecin traitant[7]. Le prestataire de soins et le patient\npeuvent toujours décider de ne pas publier une donnée[2].
\nÉtape 4 — Signaler la référence au hub. L'hôpital se raccorde via un hub, et non directement au métahub\n[8]. Le hub doit permettre de signaler un document avec des métadonnées minimales, de rechercher des\nréférences, de révoquer un signalement et de récupérer un document[2]. L'hôpital reste lui-même\nresponsable de la conservation et de la disponibilité[2] ; CoZo, par exemple, ne conserve pas\nlui-même de résultats[1]. Le répertoire des références comporte deux couches : le métahub sait dans\nquel hub se trouve l'information, le hub sait auprès de quelle institution[2] ; le patient est\nidentifié par son numéro d'identification de la sécurité sociale[2].
\nÉtape 5 — Consultation par le médecin généraliste. Les médecins généralistes consultent les documents du hub\ndepuis leur propre logiciel[9] via des services hub KMEHR comme getTransactionList, localement ou\nsur l'ensemble du système de hubs[10]. Lors d'une consultation interhub, le hub demandeur contrôle le\nconsentement et la relation thérapeutique, le hub conservateur les droits spécifiques au document, et chaque accès\nest journalisé[2]. Le partage se fait uniquement selon la matrice d'accès\n[11]. Une exclusion bloque tout accès, même en cas de relation thérapeutique[11]. En cas\nd'urgence (breaking the glass), le contrôle préalable du consentement, de la relation thérapeutique ou de la\nrelation de soins tombe[2] ; il faut toutefois enregistrer dans les données de journalisation que le\nprestataire de soins a invoqué une situation d'urgence[2].
\nÉtape 6 — Push parallèle via eHealthBox. Selon Domus Medica, les hôpitaux envoient certains rapports également\nvia l'eHealthBox vers le dossier médical électronique du médecin généraliste[9] ; ils y sont\nretrouvables dans la liste des documents du patient[9].
\nÉtape 7 — Accès pour le patient. L'institution raccordée décide de manière autonome de ce qu'elle partage avec\nle patient via le hub[1] ; les hôpitaux appliquent à cet égard des règles différentes, par exemple\nune libération différée[9].
\nSelon le fournisseur nexuzhealth (2022), il existe deux hubs en Flandre : VZN KU Leuven et CoZo\n[12]. Le règlement (version du 2 septembre 2025) cite toutefois Abrumet, RSW, Antwerpse Regionale Hub,\nCoZo et ZOrgDAtaPlatform (ZODAP), mais pas le hub VZN[2]. Pour les autres comptages contradictoires :\nvoir les incertitudes sur Hubs & Metahub (répertoire des références). Grâce au système interhub, un médecin généraliste peut aussi consulter\ndes documents d'un hôpital en dehors de sa région[9].
" }, { "id": "statut-et-obligation", "title": "Statut et obligation", "kind": "tekst", "html": "Un hôpital se raccorde via un hub, et non directement au métahub[8]. Selon un entretien avec\nZorgnet-Icuro, le hub louvaniste (VZN-hub) fonctionne différemment de CoZo, une différence qui s'est\ndéveloppée historiquement à partir du DPI partagé auquel 35 à 40 hôpitaux sont raccordés et qui est « en fait\ndéjà un hub en soi »[17]. Qui exécute techniquement l'étape 4 du processus ci-dessus (signaler la\nréférence et les métadonnées à son propre hub), la partie DPI ou l'hôpital lui-même, n'est pas établi par des\nsources publiques (voir nexuzhealth (fournisseur du DPI CWS)).\n- Recommandation : un hôpital dont la publication passe par la partie DPI inscrit de préférence aussi le\n respect des conditions de publication BMUC (délai, métadonnées, types de documents) dans les accords et le\n reporting avec cette partie.
\nRecommandation (interprétation propre, pas un fait de source) : l'arrêté royal ne mentionne aucun point de\ndépart pour le délai de 0-7 jours, et la proposition du CFEH de compter à partir de la validation (2023) ne figure\npas dans le texte de 2025. Ne partez donc pas, par prudence, du principe que le délai ne commence qu'à la\nvalidation. Mesurez par type de document à la fois le temps entre le contact ou la sortie et la publication et\ncelui entre la validation et la publication, demandez au SPF quel horodatage (métadonnées) le monitoring utilise,\nvérifiez si les métadonnées suffisent pour le monitoring BMUC, et rendez explicite et documentée la politique\nd'accès pour le patient (libération différée). Suivez la révision BMUC pour les années après 2026.
\nLes interfaces du hub et du métahub sont des services web KMEHR[2] ; les définitions de services web\npubliées portent le statut « draft », bien que les opérations soient listées comme « Published »\n[18]. Une implémentation de référence non officielle modernise les transactions interhub vers IHE MHD\nsur FHIR R4[19] et renvoie à une « Belgian Federated eHealth Interhub FHIR Specification » avec un\nguide d'implémentation qui spécifie trois transactions normatives[19] ; le statut et le propriétaire\nde cette spécification n'ont pas été vérifiés (lacune, pas une preuve d'absence). Selon le INAMI\n(BIHR), les flux KMEHR existants restent pris en charge en lecture seule et les échanges nouveaux et modifiés\npassent, à partir de 2028, par FHIR[20]. Interprétation : cela détermine la durée de vie de la\npublication KMEHR via le hub ; aucune date concrète de suppression progressive des services hub n'a été trouvée.
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "