Institution publique fédérale dotée de la personnalité juridique (loi du 21 août 2008) qui organise l'échange électronique de données entre acteurs de soins, propose des services de base gratuits (I.AM, eHealthBox, timestamping, chiffrement, pseudonymisation, le répertoire des références/métahub) et fixe des normes et standards TIC, dont KMEHR et les profils FHIR belges. Les logiciels se raccordent via des certificats eHealth, I.AM (SAML/STS pour SOAP, I.AM Connect/OIDC pour REST) et les connecteurs. Le Software Register est en ligne ; le déploiement de SNOMED CT avec un serveur de terminologie, PADAC et les projets du plan d'action 2026-2029 sont planifiés.
", "last_verified": "2026-10-30", "verification_outdated": false, "sections": [ { "id": "en-bref", "title": "En bref", "kind": "tekst", "html": "La Plate-forme eHealth (NL : eHealth-platform) a été créée par la loi du 21 août 2008 en tant qu'institution publique dotée de la personnalité juridique[1]. Il s'agit d'une organisation fédérale qui fournit des services de base[1] et fixe des normes et standards pour un échange sécurisé[1] ; dans le système Hubs & Metahub, la métahub indique uniquement où se trouvent des données relatives à un patient[12].
" }, { "id": "a-quel-probleme-repond-elle", "title": "À quel problème répond-elle ?", "kind": "tekst", "html": "Sa mission légale consiste à optimiser, au moyen de services électroniques et d'échanges d'informations sécurisés entre tous les acteurs des soins de santé, la qualité et la continuité des soins ainsi que la sécurité du patient, à promouvoir la simplification administrative et à soutenir la politique de santé[1]. Concrètement, la loi charge la Plate-forme de mettre gratuitement à disposition des services électroniques de base, dont un système de cryptage des données entre l'expéditeur et le destinataire, un système de gestion des accès et des utilisateurs, une boîte aux lettres électronique sécurisée, un système de datage électronique et un système de pseudonymisation et d'anonymisation[1]. Elle doit en outre fixer les normes, standards, spécifications et l'architecture de base fonctionnels et techniques liés aux TIC[1].
" }, { "id": "qui-la-gere-et-ou-est-elle-active", "title": "Qui la gère et où est-elle active ?", "kind": "tekst", "html": "La Plate-forme est fédérale et organise l'échange entre tous les acteurs des soins de santé[1]. La mise en œuvre du répertoire des références ne peut intervenir qu'après délibération de la chambre sécurité sociale et santé du Comité de sécurité de l'information (CSI)[1]. La consultation du répertoire des références par des personnes autres que la personne concernée ou ses représentants légaux n'est possible que dans la mesure où la personne concernée a donné son consentement à cet effet[1] ; ce texte de l'art. 5, 4° a été remplacé par la loi du 23 novembre 2023[1]. Le fait que le CSI ait repris, depuis la loi du 5 septembre 2018, le rôle de la section santé du Comité sectoriel figure dans le texte du claim, mais pas dans la citation (pas de vérification littérale).
\nLa Plate-forme partage sa direction avec la Banque Carrefour de la Sécurité Sociale (BCSS) : le même administrateur général dirige les deux institutions et est en outre membre de plein droit, sans rémunération supplémentaire, du conseil d'administration de l'agence flamande chargée du partage des données dans les soins[13]. Le 13 mars 2024, une présentation consacrée à l'architecture des services eHealth a eu lieu à la Chambre[14].
\nSécurité de l'information et NIS2 : selon une présentation du personnel (30 janvier 2026), la réglementation NIS2 est en vigueur depuis octobre 2024 pour la BCSS et la Plate-forme eHealth, qui élaborent des politiques communes avec le groupe de travail de la BCSS sur la sécurité de l'information[9]. Le parcours de conformité prévoit un premier point de mesure le 18 avril 2026[9] ; les DPIA suivent un cycle de 36 mois par traitement[9]. La loi belge NIS2 est entrée en vigueur le 18 octobre 2024[15] ; voir NIS2 et cybersécurité dans les soins de santé. Des représentants de la Plate-forme eHealth ont établi, avec des hôpitaux psychiatriques et Zorgnet-Icuro, une estimation des risques NIS2 à l'aide du CyFun Selection Tool du CCB[16], et le domaine politique flamand WVG utilise des composants de sécurité de Digitaal Vlaanderen et de la Plate-forme eHealth[17].
\nChaque règlement suit sa propre procédure d'approbation :
\nrèglement Hubs & Metahub : Comité de gestion 11/02/2025 et CSI 02/09/2025[18] ;
\nmoyens de preuve électroniques d'une relation thérapeutique et d'une relation de soins : Comité de gestion 13/11/2018 et CSI 03/03/2020[18] ;
\nMatrice d'accès : Comité de gestion 13/11/2018 et CSI 04/12/2018, modifiée le 06/07/2021[18] ;
\nconsentement éclairé : pas de règlement du CSI, mais une note informative, approuvée par le Comité de gestion (12/09/2017) et le Comité sectoriel (03/07/2018)[18].
\nSelon le Welcome Pack (version 08/09/2026), les services de base sont la coordination de processus électroniques partiels, le portail, I.AM, RN Consult, les certificats eHealth, le timestamping, le chiffrement de bout en bout, le répertoire des références (Metahub), eHealthBox et la pseudonymisation & l'anonymisation[2].
\nI.AM (Identity & Access Management, voir I.AM et I.AM Connect (Identity & Access Management)) assure l'identification, l'authentification et l'autorisation ; l'utilisateur choisit un profil en fonction de sa qualité telle qu'elle est enregistrée dans la base de données CoBRHA[2]. CoBRHA (Common Base Registry for HealthCare Actors) est la base de données commune des institutions qui reconnaissent les acteurs des soins de santé[19]. I.AM AA permet aux partenaires de consulter des sources authentiques eHealth telles que CoBRHA et les mandats[2]. L'environnement FHIR de Vitalink utilise par exemple les services I.AM Connect[20].
\nCertificats eHealth et chiffrement (voir Certificats eHealth et chiffrement (ETEE)) : un certificat est requis dès qu'un logiciel veut accéder aux services de base en system-to-system[4] ; le service ETEE chiffre les messages destinés notamment à eHealthBox et Recip-e[21]. Pour un acteur individuel des soins de santé, un certificat eHealth signifie que le groupe cible est enregistré dans une source authentique validée et que l'acteur dispose d'un moyen d'authentification fort (eID) ; une solution hybride existe pour les prestataires non belges sans eID[4]. Les nouveaux certificats utilisent ECC 384 au lieu de RSA-2048[22] ; le 13/08/2026, la Plate-forme a envoyé aux intégrateurs utilisant la CryptoLIB un message relatif au passage aux certificats ECC dans l'environnement d'acceptation lors de la release R20262[23].
\neHealthBox (voir eHealthBox) est une boîte aux lettres électronique sécurisée destinée aux prestataires et aux institutions de soins, disponible comme service web et comme application web[24] ; l'article 5, 4°, b) de la loi eHealth mentionne, parmi les services de base mis gratuitement à disposition par la Plate-forme, une boîte aux lettres électronique sécurisée pour chaque acteur des soins de santé[1] ; eHealthBox REST v1 existe à côté de SOAP v3[25].
\nTimestamping est principalement utilisé pour la prescription électronique dans les hôpitaux : l'hôpital envoie toutes les 5 minutes un paquet de hachages (TimeStampBag)[2]. Parmi les autres utilisateurs figurent Recip-e, MyCareNet et RCT[2]. Cet usage est régi par le règlement du 5 décembre 2016 relatif à la prescription électronique au sein de l'hôpital[2].
\nRépertoire des références (Metahub) : un index de données de santé et la pierre angulaire d'un système d'échange décentralisé[26]. La métahub sait uniquement dans quel hub ou coffre-fort santé des informations concernant un patient sont disponibles ; chaque hub conserve lui-même l'indication de l'institution qui détient la donnée[12]. Seuls les hubs reconnus ont accès au service web Metahub[2]. En revanche, les services web relatifs au consentement, aux relations thérapeutiques/relations de soins et aux exclusions sont aussi disponibles sous forme de services REST pour les applications de tiers[2]. Metahub et les services Consent, Therlink et Exclusions fonctionnent sur une infrastructure à haute disponibilité répartie sur deux zones[27]. Voir Hubs & Metahub (répertoire des références).
\nPseudonymisation (notamment WS Seals, batch codage, Blinded pseudo ; pour le batch codage, la Plate-forme assure un rôle de tiers de confiance[28]) : selon la Plate-forme eHealth, une autorisation préalable du Comité de sécurité de l'information est absolument nécessaire[2][2][2][2][2]. L'accord du CSI est obligatoire pour WS SEALS, Batch codage, Blinded pseudo et l'anonymisation[2].
\nStandards : la Plate-forme gère KMEHR et le site des standards[29] et publie, lorsque nécessaire, des profils FHIR et des guides d'implémentation pour les initiatives fédérales[30] (voir Guides d'implémentation FHIR belges). Les artefacts FHIR sont validés par l'équipe de validation FHIR de HL7 Belgium, avec un secrétariat partagé[31]. La documentation KMEHR du schéma de médication partagé est elle aussi mise à disposition de manière centralisée pour les trois coffres-forts santé par la Plate-forme eHealth[32].
\nConnecteurs : la Plate-forme diffuse gratuitement, sous licence libre, des bibliothèques qui facilitent l'intégration des services de base[11] ; voir Connecteurs eHealth (eHealth platform services connectors). Il existe deux versions des connecteurs : 5.1.x (Java uniquement, au minimum Java 21) et 4.9.5 (Java et .NET)[11] ; depuis les modifications de mai 2026, le connecteur technique prend en charge SAML2[11].
\nEnvironnement d'acceptation et enregistrement : un environnement d'acceptation permet aux institutions et aux fournisseurs de logiciels d'effectuer des tests par rapport aux spécifications d'interopérabilité et de sécurité[22]. L'enregistrement des logiciels relève de la responsabilité de la Plate-forme eHealth, en collaboration avec des gestionnaires tels que l'INAMI[33] ; le Software Register est un cadastre officiel et partagé des logiciels de santé en ligne[34][34]. La Plate-forme eHealth a introduit un système d'évaluation des logiciels sur lequel l'INAMI s'appuie pour octroyer d'éventuelles primes télématiques[35] ; la page d'enregistrement publie des critères pour la médecine générale, les soins infirmiers, la physiothérapie et la dentisterie[35]. Voir Software Register (plate-forme eHealth). La vue d'ensemble par service cible figure sur Intégration technique avec l'infrastructure eHealth.
\nCatalogue des API : tous les services et toutes les API de la Plate-forme, regroupés par fonction avec leurs interfaces et leurs versions, figurent sur Services et API de la plate-forme eHealth. Les release notes paraissent le jour où une release arrive dans l'environnement d'acceptation et mentionnent notamment les nouveaux développements et les services qui atteignent la fin de leur cycle de vie[36][36]. Une major release comprend la mise en production d'une nouvelle version des connecteurs, de nouveaux services de base et des modifications structurelles ou architecturales[36].
\nPage de statut : selon le ministre, une vue d'ensemble des incidents connus (notamment la facturation MyCareNet) est disponible sur status.ehealth.fgov.be[37].
\nSelon la présentation eHealth de l'administrateur général, les services de base ont été utilisés plus de 19,02 milliards de fois en 2025[3], le portail MyHealth a été consulté 245,7 millions de fois (sans datation explicite)[3] et plus de 11,6 millions de Belges (97,8%) avaient donné leur consentement éclairé[3] ; voir Consentement éclairé au partage de données. Ces chiffres proviennent de l'administrateur général sur son site personnel, et non d'un rapport statistique distinct.
\nLe plan d'action interfédéral porte comme date de publication le 1 octobre 2026[10]. Les services de base de la Plate-forme eHealth y constituent l'un des trois axes, aux côtés de l'opérationnalisation du BIHR (Belgian Integrated Health Record) et de l'alignement sur les programmes de fond[38]. L'axe 1 poursuit le développement des services de base, de MyCareNet, des hubs/de la métahub et des coffres-forts santé[10] ; il est subdivisé en gestion des accès, interopérabilité et enregistrement[10]. Sont notamment prévus CoBRHA+, un registre central des acteurs des soins de santé[10] (CoBRHA), une transition de KMEHR vers des CareSet fondés sur FHIR[10] et un Blinded pseudonymisation service comme extension de la pseudonymisation de niveau 1[10]. Il s'agit de projets, pas de services réalisés.
\nSNOMED CT dans le DPI (présentation pour Agoria, 5 novembre 2025) : étape 1 « Fundering » (BE SNOMED CT dans le DPI au moyen d'un serveur de terminologie), avec pour objectif de mise en œuvre 2026 Q3 et l'enregistrement/homologation 2026 Q4[8] ; étape 2 (liste des problèmes) 2026 Q4 et 2027 Q1[8] ; étape 3 (patient summary, prescription électronique, délivrance électronique) 2027 Q4 et 2028 Q1[8]. Le DPI ne peut pas avoir plus de deux versions de retard sur la plus récente édition belge de SNOMED CT[8]. La Plate-forme développe à cet effet un serveur de terminologie sous la forme d'un conteneur Docker facile à installer, un projet du SPF Santé publique[9]. Voir SNOMED CT et Serveur national de terminologie (FHIR).
\nVolet interopérabilité du plan d'action 2026-2029 : jeux de références SNOMED CT trilingues, CoBRHA+ (orthographié « CoBHRA+ » dans la présentation ; probablement identique au projet CoBRHA+ du plan d'action), hubs-métahub et coffres-forts santé[9].
\nSoftware Register : une base de données centrale et officielle des logiciels de santé, dont la Plate-forme est maître d'ouvrage et hébergeur[9][34][9] ; la Plate-forme a lancé l'application le 11 mars 2026[7] ; lors du lancement, elle n'offrait qu'un accès en lecture, les fonctions de modification destinées aux partenaires étant prévues lors d'itérations ultérieures (planification)[7]. La présentation du personnel prévoyait qu'à partir de Q2 2026, les producteurs encoderaient eux-mêmes leurs données[9] ; cela n'est pas confirmé. Le nombre d'utilisateurs par logiciel n'est visible que par les partenaires (INAMI, SPF, Collège Intermutualiste National)[34].
\nPADAC (PAtientDataACcess), qui permet aux patients d'enregistrer et de consulter leurs décisions relatives à la Matrice d'accès, est entré en production en mai 2025 (production)[9] ; l'intégration dans les hubs et les coffres-forts ainsi que dans le portail MaSanté est prévue pour 2026[9].
\nApplication de médication : selon la présentation du 30 janvier 2026, le démarrage en production de l'application de médication MaSanté au sein de VIDIS était prévu pour mars 2026, avec une évolution vers une application native ; cette source ne confirme pas une mise en ligne effective[9].
\nDIGIRELAB : tous les logiciels de médecine générale ont intégré DIGIRELAB (résultats de laboratoire en FHIR/LOINC) et 75% des labos ont prouvé leur capacité à envoyer les rapports structurés aux médecins ; un projet visant à rendre son utilisation obligatoire est prévu pour 2026[9]. Voir LOINC et le sous-ensemble belge (ReTaM).
\neBirth v2 : pour la nouvelle déclaration de naissance, la Plate-forme prévoit en Q1 2026 une preuve de concept avec deux hôpitaux[9].
\nSAML v2 : Recip-e doit passer de SAML v1 à v2, parce que la Plate-forme l'exige en 2026 pour toutes les applications qui utilisent les services de base eHealth[9] (voir les incertitudes).
\nMyGov.be : en 2023-2024, l'administrateur général était codirecteur du développement de MyGov.be, le portefeuille d'identité belge conforme à eIDAS-2, destiné aux secteurs social et des soins[39]. MyGov.be offre une authentification fondée sur le Registre national, un accès à l'eBox et la conservation de documents signés numériquement[40]. En soutien à l'EHDS, l'objectif est de pouvoir y charger la carte européenne d'assurance maladie et des prescriptions électroniques via Recip-e, puis de les transmettre à la pharmacie au moyen d'un code QR (proposition)[40].
\nVision politique : la présentation plaide pour un financement de l'e-santé fondé sur les résultats plutôt que sur les moyens ; il s'agit d'une vision, pas d'une réglementation[3].
\nObligation légale / réglementation : l'utilisation du timestamping pour la prescription électronique au sein de l'hôpital relève du règlement du 5 décembre 2016[2]. Selon la Plate-forme eHealth, la pseudonymisation au moyen des services eHealth requiert un accord préalable du CSI[2].
\nCondition de connexion : le service web Metahub n'est accessible qu'aux hubs reconnus[2]. Un hôpital publie donc par l'intermédiaire de son hub ; il s'agit d'une déduction, et non d'une disposition littérale. Des services REST existent toutefois pour Consent, Therlink et Exclusions à l'intention des applications de tiers[2]. Un nouveau projet partenaire qui souhaite utiliser les services de base doit d'abord prendre contact ; la Plate-forme examine alors sur le plan juridique si une délibération ou un avis du CSI est nécessaire[41]. Le règlement relatif au Cercle de confiance prévoit qu'une organisation organise et surveille elle-même les mesures de sécurité de l'information pour ses utilisateurs[19].
\nBonne pratique : il existe pour les hôpitaux des Normes minimales de sécurité de l'information, inspirées d'ISO 27000, accompagnées d'un outil de maturité[2].
\nLes standards ne sont pas automatiquement obligatoires : la publication comme standard fédéral n'entraîne pas automatiquement une obligation légale de mise en œuvre[31].
\nCondition technique : les connexions system-to-system nécessitent un certificat eHealth[4], et les services REST également un client I.AM Connect[42]. Les renouvellements de clés sont assortis de dates fermes, comme en juillet-août 2026[43].
\nPlanification SNOMED CT : l'enregistrement/homologation de SNOMED CT dans le DPI est prévu à partir de 2026 Q4[8] ; cela concerne les fournisseurs de DPI et leurs clients (planification, aucune obligation établie dans cette source).
\nRecommandation (propre) : tenez à jour un relevé des services de base eHealth (I.AM, certificats, eHealthBox, timestamping) utilisés par chaque application, afin de pouvoir évaluer à temps les modifications relevant de l'axe 1 du plan d'action.
\nDepuis le plan d'action 2019-2021, HL7 HL7 FHIR est le standard privilégié pour les nouveaux flux de données et les nouvelles interfaces[29]. Selon le document de vision de mai 2019, la migration des services de base eHealth vers FHIR devait se dérouler de manière itérative, progressive et selon le principe du « best effort »[44] ; la question de savoir si cela reste valable après le plan d'action 2026-2029 et le BIHR (Belgian Integrated Health Record) reste ouverte. La Plate-forme avertit qu'une conversion de KMEHR vers FHIR sans codage et structuration supplémentaires offre peu de valeur ajoutée et qu'un « big bang » n'est pas possible[29]. En cas de défaillance complète de la métahub, certains hubs continuent de fonctionner selon la Plate-forme eHealth, « op basis van de informatie waarover wij beschikken »[27]. Vitalink et le hub Vlaams Ziekenhuisnetwerk KU Leuven n'ont pas intégré la procédure d'urgence et ne fonctionnent alors pas[27]. La page de statut mentionne le hub VZN[27], tandis que le règlement Hubs & Metahub de 2025 mentionne ZODAP[12] ; voir la question ouverte sur Hubs & Metahub (répertoire des références).
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "SAML v2 : la présentation du personnel du 30 janvier 2026 mentionne une migration obligatoire de SAML v1 vers v2 en 2026[9], tandis que le cookbook actuel décrit encore un jeton SAML 1.1[5]. La FAQ des connecteurs indique que le Saml11TokenService n'est plus utilisé depuis octobre 2023[45], et la communication de juin 2026 relative à I.AM porte sur le renouvellement des certificats et des clés ; elle ne mentionne pas de changement de protocole[43]. La même communication indiquait d'abord le 6/10/2026 comme échéance pour la gestion manuelle des métadonnées[46] ; l'erratum du 7 juillet 2026 la remplace par le 22/07/2026[43]. Voir I.AM et I.AM Connect (Identity & Access Management).
\nPlanifications issues de présentations du personnel (Software Register, intégration PADAC, obligation DIGIRELAB, étapes SNOMED CT) : il s'agit d'intentions ; leur réalisation n'est pas confirmée par une source ultérieure[9].
\nNom du plan d'action : une présentation de mars 2025 porte le titre « actieplan 2025-2027 »[14], tandis que des sources ultérieures parlent du « Plan d'action eSanté 2026-2029 »[9].
\nAucun calendrier de migration des services de base vers FHIR n'a été trouvé dans le plan d'action ; il s'agit d'une lacune, pas d'une preuve de son absence.
\nL'INAMI mentionne « eHealth (het gezondheidsportaal van de Belgische overheid) » comme co-initiateur de MyCareNet[47] ; il demeure incertain si cela désigne l'institution Plate-forme eHealth ou le portail.
\nDans les sources, le nom « eHealth » désigne aussi bien l'institution que le portail ; dans cette base de connaissances, « Plate-forme eHealth » désigne l'institution[47][1].
\n