--- id: technische-integratie-ehealth type: Topic type_label: Aperçu ou dossier title: Intégration technique avec l'infrastructure eHealth aliases: - integratie eHealth-basisdiensten - softwareintegratie eHealth - eHealth-integratie voor softwareleveranciers names: nl: Technische integratie met de eHealth-infrastructuur fr: Intégration technique avec l'infrastructure eHealth en: Technical integration with the Belgian eHealth infrastructure jurisdiction: - belgie themes: - architectuur-en-infrastructuur - identiteit-en-toegang lifecycle: nvt lifecycle_note: Aperçu sans phase de cycle de vie propre; le statut de production diffère selon le service cible. Les sources techniques et les statuts de service repris ont été vérifiés le 05/10/2026. summary: Cet aperçu décrit comment un logiciel se connecte aux services de l'infrastructure eHealth belge. Les briques communes sont un certificat eHealth, I.AM pour l'authentification et l'autorisation, le chiffrement des messages, des connecteurs et un environnement d'acceptation. Ensuite, la procédure d'accès, les tests et l'agrément diffèrent pour l'eHealthBox, MyCareNet, les hubs, Vitalink, Recip-e, UHMEP, la pseudonymisation et CoBRHA. Pour les hôpitaux, cela aide à déterminer par application quel protocole, quel client, quelles clés et quelle approbation sont nécessaires. last_verified: '2026-10-05' relations: - type: about direction: uit target: healthdata-hd4dp target_url: https://ehealth-atlas.be/fr/hd4dp-v2/ status: established - type: about direction: uit target: ehealth-certificaten target_url: https://ehealth-atlas.be/fr/certificats-ehealth/ status: established - type: about direction: uit target: i-am-connect target_url: https://ehealth-atlas.be/fr/i-am-identity-access-management/ status: established - type: about direction: uit target: ehealth-connector target_url: https://ehealth-atlas.be/fr/connecteurs-ehealth/ status: established - type: about direction: uit target: ehealthbox target_url: https://ehealth-atlas.be/fr/ehealthbox-boite-aux-lettres-electronique-securisee/ status: established - type: about direction: uit target: mycarenet target_url: https://ehealth-atlas.be/fr/mycarenet/ status: established - type: about direction: uit target: hubs-metahub target_url: https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/ status: established - type: about direction: uit target: vitalink target_url: https://ehealth-atlas.be/fr/vitalink/ status: established - type: about direction: uit target: uhmep target_url: https://ehealth-atlas.be/fr/uhmep-prescription-de-renvoi-electronique/ status: established - type: about direction: uit target: recip-e target_url: https://ehealth-atlas.be/fr/recip-e/ status: established - type: about direction: uit target: cobrha target_url: https://ehealth-atlas.be/fr/cobrha/ status: established - type: about direction: uit target: ehealth-platform target_url: https://ehealth-atlas.be/fr/plate-forme-ehealth/ status: established - type: about direction: uit target: informatieveiligheidscomite target_url: https://ehealth-atlas.be/fr/comite-de-securite-de-l-information/ status: established - type: about direction: in target: ehealth-basisdiensten target_url: https://ehealth-atlas.be/fr/services-de-base-de-la-plate-forme-ehealth/ status: established release: 2026.11.12-3 url: https://ehealth-atlas.be/fr/integration-technique-avec-l-infrastructure-ehealth/ license: CC BY 4.0 --- # Intégration technique avec l'infrastructure eHealth Cet aperçu décrit comment un logiciel se connecte aux services de l'infrastructure eHealth belge. Les briques communes sont un certificat eHealth, I.AM pour l'authentification et l'autorisation, le chiffrement des messages, des connecteurs et un environnement d'acceptation. Ensuite, la procédure d'accès, les tests et l'agrément diffèrent pour l'eHealthBox, MyCareNet, les hubs, Vitalink, Recip-e, UHMEP, la pseudonymisation et CoBRHA. Pour les hôpitaux, cela aide à déterminer par application quel protocole, quel client, quelles clés et quelle approbation sont nécessaires. ## En bref - **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]. ## Qu'est-ce que c'est ? 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](https://ehealth-atlas.be/fr/i-am-identity-access-management/), 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]. ## Composants - **Choix d'architecture** : la [Plate-forme eHealth](https://ehealth-atlas.be/fr/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)](https://ehealth-atlas.be/fr/certificats-ehealth/). - **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)](https://ehealth-atlas.be/fr/connecteurs-ehealth/). - **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 | Service cible | Voie d'accès pour un logiciel | Ce qui est nécessaire | Test/agrément | |---|---|---|---| | [eHealthBox](https://ehealth-atlas.be/fr/ehealthbox-boite-aux-lettres-electronique-securisee/) | SOAP v3 ou REST v1 | certificat + chiffrement ; pour REST également I.AM Connect[^16][^11] | minilab pour le logiciel de médecine générale[^17] | | [MyCareNet](https://ehealth-atlas.be/fr/mycarenet/) | via un logiciel d'entreprise[^18] ; en outre un portail du Collège Intermutualiste National[^18] | inscription auprès du Collège Intermutualiste National + certificat de test eHealth[^9] | « Approval Assessment » du Collège Intermutualiste National[^9] | | [Hubs & Metahub (répertoire des références)](https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/) | uniquement via un hub agréé[^10] | Consent/Therlink/Exclusions également en REST[^10] | via le hub | | [Vitalink](https://ehealth-atlas.be/fr/vitalink/) | environnement [KMEHR](https://ehealth-atlas.be/fr/kmehr/) ou [FHIR](https://ehealth-atlas.be/fr/hl7-fhir/)[^19] | procédure d'accès ; FHIR via I.AM Connect[^19][^20] ; calendrier de releases par trimestre[^19] | procédure d'accès (détails de test non trouvés)[^19] | | [Recip-e (prescription électronique dans le secteur ambulatoire)](https://ehealth-atlas.be/fr/recip-e/) (FHIR) et [UHMEP et la prescription de renvoi électronique (eReferral)](https://ehealth-atlas.be/fr/uhmep-prescription-de-renvoi-electronique/) | API FHIR, composants web ou application web[^1] | token exchange I.AM Connect, client M2M propre[^21] | test d'enregistrement (session live)[^1] ; pour la prescription de renvoi électronique ([UHMEP](https://ehealth-atlas.be/fr/uhmep-prescription-de-renvoi-electronique/)) d'abord un test de pré-enregistrement obligatoire sur le serveur de test FHIR de la plate-forme eHealth[^22] | | Pseudonymisation | service eHealth (TTP) | délibération du Comité de sécurité de l'information obligatoire[^23] | sans objet | | [CoBRHA](https://ehealth-atlas.be/fr/cobrha/) / Addressbook | Consultation Webservice, I.AM AA[^24][^5] | la variante REST demande I.AM Connect[^11] | non trouvé | ### 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)](https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/), [Consentement éclairé au partage de données](https://ehealth-atlas.be/fr/consentement-eclaire-au-partage-de-donnees/) et [Relation thérapeutique](https://ehealth-atlas.be/fr/relation-therapeutique/). ### 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](https://ehealth-atlas.be/fr/kmehr/) et [FHIR](https://ehealth-atlas.be/fr/hl7-fhir/)[^19] (voir aussi [Guides d'implémentation FHIR belges](https://ehealth-atlas.be/fr/guides-d-implementation-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](https://ehealth-atlas.be/fr/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é](https://ehealth-atlas.be/fr/pharmacien-hospitalier/)) 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)](https://ehealth-atlas.be/fr/uhmep-prescription-de-renvoi-electronique/) et [Recip-e (prescription électronique dans le secteur ambulatoire)](https://ehealth-atlas.be/fr/recip-e/). ### 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](https://ehealth-atlas.be/fr/comite-de-securite-de-l-information/) est obligatoire[^23]. La pseudonymisation des données de registre dans le flux de données [HD4DP](https://ehealth-atlas.be/fr/hd4dp-v2/) 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)](https://ehealth-atlas.be/fr/connecteurs-ehealth/)) 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](https://ehealth-atlas.be/fr/cobrha/). ## Phase **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. ## Qu'est-ce que cela signifie pour un hôpital ? - **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). ## Incertitudes et informations contradictoires - 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)](https://ehealth-atlas.be/fr/i-am-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]. ## Relaties - porte sur: [HD4DP v2 (healthdata.be)](https://ehealth-atlas.be/fr/hd4dp-v2/) (établi)[^26]. Pseudonimisering van de HD4DP-datastroom via eHBox en de TTP-dienst van eHealth is een behandeld integratiegeval. - porte sur: [Certificats eHealth et chiffrement (ETEE)](https://ehealth-atlas.be/fr/certificats-ehealth/) (établi)[^3] - porte sur: [I.AM et I.AM Connect (Identity & Access Management)](https://ehealth-atlas.be/fr/i-am-identity-access-management/) (établi)[^5] - porte sur: [Connecteurs eHealth (eHealth platform services connectors)](https://ehealth-atlas.be/fr/connecteurs-ehealth/) (établi)[^12] - porte sur: [eHealthBox](https://ehealth-atlas.be/fr/ehealthbox-boite-aux-lettres-electronique-securisee/) (établi)[^16][^11] - porte sur: [MyCareNet](https://ehealth-atlas.be/fr/mycarenet/) (établi)[^9] - porte sur: [Hubs & Metahub (répertoire des références)](https://ehealth-atlas.be/fr/hubs-metahub-repertoire-des-references/) (établi)[^10] - porte sur: [Vitalink](https://ehealth-atlas.be/fr/vitalink/) (établi)[^19] - porte sur: [UHMEP et la prescription de renvoi électronique (eReferral)](https://ehealth-atlas.be/fr/uhmep-prescription-de-renvoi-electronique/) (établi)[^1][^22] - porte sur: [Recip-e (prescription électronique dans le secteur ambulatoire)](https://ehealth-atlas.be/fr/recip-e/) (établi)[^21] - porte sur: [CoBRHA](https://ehealth-atlas.be/fr/cobrha/) (établi)[^24] - porte sur: [Plate-forme eHealth](https://ehealth-atlas.be/fr/plate-forme-ehealth/) (établi)[^8][^1][^14]. Acceptatieomgeving en softwareregistratie onder verantwoordelijkheid van het eHealth-platform. - porte sur: [Comité de sécurité de l'information (chambre sécurité sociale et santé)](https://ehealth-atlas.be/fr/comite-de-securite-de-l-information/) (établi)[^23] - porte sur (entrant): [Services de base de la plate-forme eHealth](https://ehealth-atlas.be/fr/services-de-base-de-la-plate-forme-ehealth/) (établi)[^6] ## Open vragen - Is er een officieel, dienstoverschrijdend overzicht van welke dienst SOAP, REST of FHIR vereist, met uitfaseringsdata voor SOAP? - Welke business-connectoren dekken welke doeldiensten en versies? - Hoe verhouden de registratietests van het eHealth-platform (Software Register) zich tot de NIC-erkenning voor MyCareNet en de minilabs? - Welk registratietraject (en welke criteria per versie) geldt voor welke dienst in ziekenhuissoftware? De RIZIV-voorwaarden zeggen enkel dat de inschrijfwijze per project verschilt; een universele homologatieplicht voor elk ziekenhuis-EPD werd niet vastgesteld (gap). - Onderzoeksnotitie (codex-1, 26/09/2026; nog geen claim): de STS WS Trust-cookbook 1.2 zou bij TokenType zowel SAMLV1.1 als SAMLV2.0 vermelden (p. 11). Na opname als claim is de tegenstelling SAML 1.1 versus SAML v2 hieronder te herzien. ## Bronnen [^1]: [Technische informatie en registratie voor softwareleveranciers van software voor zorgverleners | RIZIV](https://www.riziv.fgov.be/nl/thema-s/egezondheid/technische-informatie-en-registratie-voor-softwareleveranciers-van-softwarepakketten-voor-zorgverleners). RIZIV. Opgehaald 2026-09-26, sha256 98adeb693a97d2a3… (SRC-db58d23cca) [^2]: [Testomgevingen | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-testomgevingen). eHealth-platform. Opgehaald 2026-09-26, sha256 7a0c7f541a159639… (SRC-91df64378c) [^3]: [eHealth-certificaten | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealth-certificaten). eHealth-platform. Opgehaald 2026-09-26, sha256 8354aeb9558fdadc… (SRC-9bfcb37059) [^4]: [Beveiliging van webservices | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/beveiliging-van-webservices). eHealth-platform. Opgehaald 2026-09-26, sha256 09330e2c0719bfa8… (SRC-8846f43048) [^5]: [I.AM (Identity & Access Management) | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-i.am-identity-access-management). eHealth-platform. Opgehaald 2026-09-26, sha256 7bd6ead93abd8dbd… (SRC-81723a4a0f) [^6]: [Architecturen | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-architecturen). eHealth-platform. Opgehaald 2026-09-26, sha256 0dab3b09a4a3129f… (SRC-0eb97991a9) [^7]: [Systeem voor end-to-endversleuteling | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-systeem-voor-end-to-endversleuteling). eHealth-platform. Opgehaald 2026-09-26, sha256 c214ae028f4340bf… (SRC-f1bf6746ab) [^8]: [Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/de-acceptatieomgeving-van-het-ehealth-platform). eHealth-platform. Opgehaald 2026-09-26, sha256 d507a85f590e7840… (SRC-5e41adfb50) [^9]: [MyCareNet | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/mycarenet). eHealth-platform. Opgehaald 2026-09-26, sha256 3500c5d724ecc306… (SRC-27a21c533f) [^10]: [Verwijzingsrepertorium (Metahub)](https://www.ehealth.fgov.be/ehealthplatform/nl/service-verwijzingsrepertorium-metahub). eHealth-platform. Opgehaald 2026-09-25, sha256 9bca4ecae94c3991… (SRC-008bee8c2b) [^11]: [Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0](https://www.ehealth.fgov.be/ehealthplatform/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/c519e44be8f41c3a3534de725dc9b2e7e906bce7/onboarding-iam-connect-ehbox-addressbook-v2-0-dd-29052024.pdf). eHealth-platform, 2024-05-29. Opgehaald 2026-09-26, sha256 cf046c0e6e61e6b2… (SRC-771a066b18) [^12]: [eHealth platform services connectors | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealth-platform-services-connectors). eHealth-platform. Opgehaald 2026-09-26, sha256 7e296c8a3bb3c976… (SRC-ef6afc402c) [^13]: [eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (07/07/2026)](https://www.ehealth.fgov.be/ehealthplatform/file/cc73d96153bbd5448a56f19d925d05b1379c7f21/495de6aa05b964876ee1d65cf26e3c521522b1a2/ehealth-communication-renewal-of-i-am-certificat-required-actions-for-saml-and-i-am-connect-integrations.pdf). eHealth-platform, 2026-07-07. Opgehaald 2026-09-26, sha256 605787754dfd140e… (SRC-2e3ed33307) [^14]: [Softwareleveranciers: Algemene voorwaarden voor softwareregistratie](https://www.riziv.fgov.be/nl/thema-s/egezondheid/technische-informatie-en-registratie-voor-softwareleveranciers-van-softwarepakketten-voor-zorgverleners/softwareleveranciers-algemene-voorwaarden-voor-softwareregistratie). RIZIV. Opgehaald 2026-09-26, sha256 f1a9f2c133aa2edb… (SRC-4c54e62075) [^15]: [Registratie van de softwarepakketten](https://www.ehealth.fgov.be/ehealthplatform/nl/service-registratie-van-de-softwarepakketten). eHealth-platform. Opgehaald 2026-09-26, sha256 bed1435d28433d11… (SRC-9b3cdfdf5e) [^16]: [eHealthBox](https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealthbox). eHealth-platform. Opgehaald 2026-09-26, sha256 5cfa6cfb5085560b… (SRC-71c7c4bb9f) [^17]: [Software Register API – certificeringen CareConnect General Practitioner (JSON)](https://api.ehealth.fgov.be/softwareRegister/v1/softwares/ILJ62R2VEFZP/versions/v._/certifications?pageSize=100). eHealth-platform. Opgehaald 2026-09-26, sha256 b4183bc818432377… (SRC-5d419bb730) [^18]: [MyCareNet - algemene beschrijving](https://ned.mycarenet.be/algemene-beschrijving). Nationaal Intermutualistisch College (NIC). Opgehaald 2026-09-26, sha256 b6d1070e440d5a1f… (SRC-50f3730800) [^19]: [Ik ben softwareleverancier | Vitalink](https://www.vitalink.be/gebruikers/ik-ben-softwareleverancier). Vitalink / Vlaamse overheid. Opgehaald 2026-09-26, sha256 3b076e49b9bd9496… (SRC-a2ac63e929) [^20]: [Nieuwe FHIR-omgeving van Vitalink in productie!](https://www.vitalink.be/nieuwe-fhir-omgeving-van-vitalink-in-productie). Vitalink (Departement Zorg), 2024-03-22. Opgehaald 2026-09-25, sha256 0628be4db12957f3… (SRC-a7e3a494e9) [^21]: [Recip-e FHIR Cookbook (UHMEP-MedicationPrescription-Cookbook.pdf)](https://raw.githubusercontent.com/smals-belgium/shared-digital-medication-prescription/master/UHMEP-MedicationPrescription-Cookbook.pdf). Smals / Recip-e, 2026-06-04. Opgehaald 2026-09-26, sha256 1c1be4db40fc4904… (SRC-b4bdb9101a) [^22]: [Softwareleveranciers: Digitaal verwijsvoorschrift voor thuisverpleegkundigen (eReferral)](https://www.riziv.fgov.be/nl/thema-s/egezondheid/technische-informatie-en-registratie-voor-softwareleveranciers-van-softwarepakketten-voor-zorgverleners/softwareleveranciers-digitaal-verwijsvoorschrift-voor-thuisverpleegkundigen-ereferral). RIZIV. Opgehaald 2026-09-26, sha256 0282b00c44970111… (SRC-6f22ff7069) [^23]: [Pseudonymisation & Anonymisation](https://www.ehealth.fgov.be/ehealthplatform/fr/service-pseudonymisation-anonymisation). Plate-forme eHealth. Opgehaald 2026-09-26, sha256 3827c83aa39c5fa3… (SRC-ac484b97eb) [^24]: [eHealth Addressbook Consultation Webservice](https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealth-addressbook-consultation-webservice). eHealth-platform. Opgehaald 2026-09-26, sha256 ea0c8c20c9a70ef4… (SRC-87a6ea79ec) [^25]: [Informatiebrochure voor de apothekers - Gebruik van MyCareNet in de voor het publiek toegankelijke officina's](https://www.riziv.fgov.be/SiteCollectionDocuments/brochure_mycarenet_apothekers.pdf). RIZIV, 2012-01-10. Opgehaald 2026-09-26, sha256 5b0baf41afe43c08… (SRC-c153772f65) [^26]: [Dataflow description HD4DP v2](https://docs.healthdata.be/documentation/hd4dp-v2-health-data-data-providers/dataflow-description-hd4dp-v2). healthdata.be (HDA). Opgehaald 2026-09-26, sha256 947c2ab446abc47e… (SRC-ae6b9db626) [^27]: [GitHub - smals-belgium/shared-pseudo-helper-java: Library that helps eHealth Pseudonymisation integration in Java applications · GitHub](https://github.com/smals-belgium/shared-pseudo-helper-java). Smals. Opgehaald 2026-09-26, sha256 00186947ff0cb7bb… (SRC-62e7d58b4b) [^28]: [Instructions de facturation électronique en tiers payant](https://www.inami.fgov.be/fr/professionnels/info-pour-tous/facturer-electroniquement). INAMI. Opgehaald 2026-09-26, sha256 dfcab4e73e8ff44b… (SRC-f9c49eb375) [^29]: [Réalisations 2025 – Perspectives 2026 (Plate-forme eHealth)](https://www.frankrobben.be/wp-content/uploads/2026/01/20260130a.pptx). eHealth-platform (publieke presentatie op de persoonlijke website van de administrateur-generaal), 2026-01-30. Opgehaald 2026-09-26, sha256 b58fc6b2201308cb… (SRC-88e226b672) [^30]: [eReferral-Digitaal Verwijsvoorschrift | eHealth-platform](https://www.ehealth.fgov.be/ehealthplatform/nl/service-ereferral). eHealth-platform. Opgehaald 2026-09-26, sha256 80e74f95d3a3b514… (SRC-972e1a8c71)