Intégration technique avec l'infrastructure eHealth

• Quoi : un logiciel se connecte, par service cible, via SOAP, REST ou FHIR et parcourt pour cela un trajet d'accès et de test spécifique au service^[1][2].

• Identité : chaque connexion system-to-system avec les services de base eHealth exige un certificat eHealth, tandis que SOAP utilise SAML via I.AM STS et REST OpenID Connect via I.AM Connect^[3][4][5].

• Sécurité : les données médicales doivent être sécurisées au moins au niveau du message ; ETEE et KGSS assurent le chiffrement pour des destinataires connus et pour des destinataires accessibles sous condition^[6][7].

• Tests : l'environnement d'acceptation utilise un certificat et un connecteur d'acceptation, tandis que les services partenaires peuvent aussi avoir leurs propres environnements de test^[8][2].

• Agrément : l'enregistrement du logiciel contrôle l'intégration, mais pour MyCareNet c'est le Collège Intermutualiste National qui décide via un Approval Assessment^[1][9].

• Hôpital : un logiciel hospitalier atteint le métahub via un hub, mais peut appeler directement le consentement, les relations de soins et les exclusions via REST^[10].

Quelles étapes techniques et administratives un logiciel (DPI, système d'information de laboratoire, logiciel de pharmacie ou de médecine générale, middleware) doit-il parcourir pour utiliser un service déterminé de l'infrastructure eHealth belge ? (Synthèse) Le modèle revient le plus souvent à : identifier le système (certificat), authentifier l'utilisateur ou l'organisation via I.AM, chiffrer le contenu, tester en acceptation et faire enregistrer ou agréer l'intégration. Les détails diffèrent selon le service cible, et toutes les étapes ne s'appliquent pas partout : une application web sans intégration propre n'exige par exemple pas de test d'enregistrement^[1].

• Choix d'architecture : la Plate-forme eHealth propose SOAP pour les applications sur un seul appareil et REST pour les applications sur plusieurs appareils ; pour les nouveaux projets mobiles, REST est privilégié^[6].
• Certificat : le certificat identifie le système, l'eID ou un jeton identifie l'utilisateur^[3]. Les certificats de production sont valables 36 mois^[3]. La plate-forme eHealth annonce un passage à ECC 384 : le Certificate Manager ne générera plus que des certificats ECC (les ETK restent en RSA)^[8] ; en acceptation, des certificats RSA peuvent encore être commandés^[8]. Voir Certificats eHealth et chiffrement (ETEE).
• I.AM : quatre contextes techniques (applications web, SOAP, REST, Data Access)^[5]. Les applications web classiques utilisent I.AM IDP, les applications mobiles et REST I.AM Connect^[5]. Les organisations enregistrent un client M2M avec leur numéro INAMI dans le client-ID^[11].
• Sécurisation du transport et des messages : pour les services web sur la plate-forme SOA, une connexion SSL/TLS est toujours exigée au niveau du transport^[4], et au niveau du message, le consommateur du service s'authentifie avec des certificats X.509^[4].
• Sécurisation du contenu : au moins au niveau du message^[6] ; un chiffrement end-to-end complet n'est pas toujours nécessaire, une sécurisation point-to-point l'est^[6].
• Connecteurs : bibliothèques Java libres (avec une variante .NET générée) pour l'authentification et le chiffrement^[12] ; au minimum la version 4.1.2 et SHA256 depuis octobre 2023^[12]. Voir Connecteurs eHealth (eHealth platform services connectors).
• Environnement d'acceptation : disponible pour les institutions et les fournisseurs de logiciels afin de tester par rapport aux spécifications d'interopérabilité et de sécurité^[8]. Fonctionnellement identique à la production, mais les données ne sont normalement pas fiables, sauf pendant les trois semaines qui précèdent une major release^[8]. L'accès demande un certificat d'acceptation, le connecteur, un ordinateur/navigateur testé et le plus souvent un profil de test médical^[8].
• Trust store et renouvellement des clés : les certificats de confiance sont diffusés sous la forme d'une ETSI Trusted List^[3] ; en juillet-août 2026, la plate-forme a renouvelé les certificats et les clés de ses propres services I.AM (intégrations SAML, validation JWT d'I.AM Connect)^[13].
• Enregistrement : l'enregistrement des logiciels se fait sous la responsabilité de la plate-forme eHealth, avec des gestionnaires tels que l'INAMI^[1][14]. La manière de s'inscrire diffère par projet selon les conditions d'enregistrement de l'INAMI^[14]. La modalité de test dépend de la forme d'intégration : pas de test pour une application web sans intégration, une vidéo de démonstration pour les composants web, une session de test live pour une API FHIR^[1]. Un logiciel enregistré doit installer chez tous les utilisateurs la version testée dans les trois mois qui suivent la réussite du minilab^[15].

Comparaison par service cible

Par service cible

eHealthBox

Pour le service web, le logiciel doit avoir intégré le service ; selon la plate-forme eHealth, c'est le cas pour tous les logiciels enregistrés par eHealth^[16]. L'intégration exige un certificat eHealth et un service de chiffrement^[16]. Pour SOAP, un certificat de base suffit ; la variante REST demande un onboarding I.AM Connect (Healthcare ou M2M)^[11]. Les messages sont limités à 10 MB^[16].

MyCareNet

Le fournisseur s'inscrit auprès des services MyCareNet (Collège Intermutualiste National) et obtient accès à la documentation technique sur SharePoint^[9]. Il demande en outre à la plate-forme eHealth un certificat de test pour le secteur^[9]. Le Collège Intermutualiste National fournit un guide d'implémentation, des messages d'exemple et des implémentations de référence en .Net et Java^[25]. Ce n'est qu'après la réussite d'un Approval Assessment que le logiciel peut passer en production^[9].

Hubs & Metahub, consentement et relation thérapeutique

Le service web Metahub (création et recherche de liens patient) est exclusivement réservé aux hubs, non aux logiciels individuels des hôpitaux^[10]. Les services pour le consentement, les relations thérapeutiques/relations de soins et les exclusions sont en revanche disponibles comme services REST pour des applications de tiers^[10]. Voir Hubs & Metahub (répertoire des références), Consentement éclairé au partage de données et Relation thérapeutique.

Vitalink

Vitalink n'a pas d'interface propre pour les prestataires de soins ; ceux-ci l'utilisent via leur logiciel professionnel, qui parcourt une procédure d'accès^[19]. Il existe deux pistes de documentation, KMEHR et FHIR^[19] (voir aussi Guides d'implémentation FHIR belges) ; l'environnement FHIR utilise REST et I.AM Connect^[20]. Vitalink publie une major release par trimestre, avec des minor releases intermédiaires^[19]. Voir Vitalink.

Recip-e et UHMEP (FHIR)

Dans l'API FHIR de Recip-e, les pharmacies hospitalières (Le pharmacien hospitalier et le schéma de médication partagé) utilisent un client M2M propre et ne peuvent pas réutiliser le client de l'hôpital^[21]. Les identifiants des patients sont pseudonymisés via le service pseudo de la plate-forme eHealth^[21]. Pour l'API FHIR d'UHMEP, le flux IAM token exchange est une condition de sécurité^[21]. Pour la prescription de renvoi électronique (eReferral), un test de pré-enregistrement réussi sur le serveur de test FHIR de la plate-forme eHealth est obligatoire avant le test d'enregistrement officiel^[22]. L'INAMI n'exige un tel test de pré-enregistrement que « pour certaines applications numériques »^[1] ; que cela vaille aussi pour l'API FHIR de Recip-e n'est pas démontré (lacune). Voir UHMEP et la prescription de renvoi électronique (eReferral) et Recip-e (prescription électronique dans le secteur ambulatoire).

Pseudonymisation

La plate-forme eHealth propose des services de pseudonymisation pour convertir des données de santé à caractère personnel en données codées ou anonymes^[23]. Dans « Batch codage », la plate-forme agit comme trusted third party^[23] ; « Blinded pseudo » adapte les pseudonymes par partie traitante sans dépseudonymisation^[23]. Une délibération du Comité de sécurité de l'information est obligatoire^[23]. La pseudonymisation des données de registre dans le flux de données HD4DP passe par le service TTP d'eHealth^[26]. La bibliothèque open source de l'organisation GitHub smals-belgium (voir Connecteurs eHealth (eHealth platform services connectors)) aveugle l'identifiant avant l'appel, de sorte que le service ne le voit jamais^[27][27].

Addressbook et CoBRHA

L'Addressbook donne accès aux coordonnées issues de CoBRHA^[24], y compris les ID eHealthBox^[16]. Voir CoBRHA.

Constatations : la base commune est partout un certificat eHealth et I.AM^[3][5]. Pour les projets mobiles, la plate-forme eHealth donne la priorité à REST^[6]. Les services plus récents de cette comparaison (Vitalink FHIR, eHealthBox REST, UHMEP) utilisent REST/OIDC^[20][11][21], tandis que SOAP avec un certificat de base continue d'exister^[11] ; que REST soit l'orientation générale pour les nouveaux services est une interprétation. Le test et l'agrément sont organisés par service, par des acteurs différents^[9][1][2].

Recommandation (propre) : tenez par application une matrice d'intégration (service cible, SOAP/REST, certificat, client I.AM, version du connecteur, statut d'agrément, dates d'expiration) et demandez explicitement aux fournisseurs leur trajet de migration de SOAP vers REST/FHIR.

• Obligation : la facturation électronique via MyCareNet est obligatoire pour les hôpitaux^[28], et donc aussi l'intégration agréée correspondante^[9]. La pseudonymisation exige une délibération du Comité de sécurité de l'information^[23].
• Condition de financement : les mécanismes d'indemnisation s'appuient sur les données du Software Register, mais l'enregistrement ne donne pas automatiquement droit à une indemnité^[1]. La plate-forme eHealth a instauré un système d'évaluation des logiciels sur lequel l'INAMI se fonde pour octroyer d'éventuelles primes de télématique^[15] ; il s'agit d'un contexte de financement, non d'une condition technique générale d'admission (interprétation).
• Bonne pratique : mettre à jour automatiquement les certificats de confiance via l'ETSI Trusted List^[3].
• (Interprétation) Un hôpital construit rarement lui-même ; le plus souvent, c'est le fournisseur du DPI ou du middleware qui intègre.
• Une institution de soins utilise son numéro INAMI dans le client-ID d'un client M2M^[11].

Conditions de mise en œuvre et limites

• L'environnement d'acceptation ne contient normalement pas de données fiables^[8].
• Un certificat d'acceptation ne donne pas accès à la production^[8].
• Une configuration de connecteur qui renvoie encore à l'ancien endpoint STS (Saml11TokenService, plus utilisé depuis octobre 2023) est une cause possible de l'erreur « SOA-03005 »^[12].
• Pour les services des réseaux hospitaliers, des coffres-forts santé, des mutualités ou de Recip-e, il existe des environnements de test auprès de la plate-forme eHealth ou auprès de ces acteurs^[2] ; un seul test réussi auprès de la plate-forme eHealth ne couvre donc pas tous les services cibles (déduction).

• Une présentation publiée publiquement de la plate-forme eHealth (« Réalisations 2025 – Perspectives 2026 », 30/01/2026) mentionne un passage obligatoire de SAML v1 à v2 en 2026^[29], alors que la page web « Beveiliging van webservices » décrit encore un jeton SAML 1.1^[4] ; voir I.AM et I.AM Connect (Identity & Access Management) (et la question ouverte sur le cookbook STS 1.2).
• Aucun aperçu transversal aux services avec des dates de retrait de SOAP n'a été trouvé (lacune).
• Il n'est pas confirmé qu'UHMEP remplacera à terme l'intégration Recip-e pour les médicaments^[30].