Fiche de concept · Aperçu ou dossier
Affirmations : Intégration technique avec l'infrastructure eHealth
- Aperçu ou dossier
- sans objet
- Belgique (fédéral/interfédéral)
- Architecture et infrastructure
- Identité, accès et audit
Identifiant Atlas technische-integratie-ehealth · 79 affirmations · 30 sources · Dernière vérification05-10-2026
· Version 2026.11.12-3
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.
Voici les affirmations sur lesquelles repose la page consacrée à Intégration technique avec l'infrastructure eHealth : des faits courts, formulés par nous, chacun avec sa source et son emplacement vérifiable. Lire l'article · Comment fonctionne l'Atlas.
Affirmations 78 affirmations
| Affirmation | Type | Source | Emplacement | Date de référence |
|---|---|---|---|---|
| De registratie- en testmodaliteiten hangen af van de integratievorm: bij een webapplicatie zonder eigen integratie is geen registratietest vereist, bij webcomponenten volstaat een demonstratievideo, en bij integratie via de FHIR-API is een live testsessie via videomeeting nodig, soms voorafgegaan door een verplichte pre-registratietest op de FHIR Test Server. ↩ Montrer dans le texte Une erreur ? | fait | Technische informatie en registratie voor softwareleveranciers van software voor zorgverleners | RIZIV — RIZIV SRC-db58d23cca | sectie 'Registratie voor een specifieke digitale toepassing' | 26-09-2026 |
| Naast het eHealth-platform beheren ook andere actoren (ziekenhuisnetwerken, gezondheidskluizen, ziekenfondsen, Recip-e) hun eigen test- of acceptatieomgevingen waarmee zelf ontwikkelde software tegen hun diensten getest kan worden. ↩ Montrer dans le texte Une erreur ? | fait | Testomgevingen | eHealth-platform — eHealth-platform SRC-91df64378c | algemene informatie testomgevingenpagina | 26-09-2026 |
| Un certificat eHealth permet à un prestataire de soins ou à une organisation de s'authentifier en tant que prestataire de soins ou institution reconnue; il est requis dès qu'une suite logicielle souhaite accéder aux services de base eHealth via une connexion de système à système et non une application web. ↩ Montrer dans le texte Une erreur ? | fait | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Wat is een eHealth-certificaat?' | 26-09-2026 |
| Pour la sécurisation des services web SOAP, le consommateur du service s'authentifie auprès d'I.AM STS (Secure Token Service) avec un certificat eHealth ou une eID, après quoi le STS délivre un token SAML qui donne accès à plusieurs services web pendant sa période de validité. ↩ Montrer dans le texte Une erreur ? | fait | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | sectie 'Veiligheid - WS-Security SAML Token Profile / Holder-of-Key' | 26-09-2026 |
| I.AM Connect est une solution de gestion de l'identité et de l'accès pour les applications web et les services web RESTful, basée sur la norme OIDC (OpenID Connect); l'authentification et l'autorisation des clients s'effectuent via ce service. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | secties 'I.AM Connect' en 'De beveiliging van REST Web Service' | 26-09-2026 |
| La plate-forme eHealth exige que les données médicales soient sécurisées au moins au niveau du message (et pas uniquement au niveau du transport), afin que les données ne circulent pas sans protection entre les points du réseau par lesquels elles passent. ↩ Montrer dans le texte Une erreur ? | fait | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Vertrouwelijkheid' | 26-09-2026 |
| Le service ETEE (End to End Encryption) de la plate-forme eHealth permet de chiffrer des messages à destination de prestataires de soins ou d'institutions et est utilisé, entre autres, dans le cadre de eHealthBox et des prescriptions électroniques (Recip-e). (L'ETK est la clé publique utilisée à cet effet, et non un autre nom du service.) ↩ Montrer dans le texte Une erreur ? | fait | Systeem voor end-to-endversleuteling | eHealth-platform — eHealth-platform SRC-f1bf6746ab | sectie 'Wat is de dienst End to End Encryption van het eHealth-platform?' | 26-09-2026 |
| Le chiffrement ETEE est appliqué, entre autres, dans le cadre de eHealthBox et de Recip-e; le service web ETK fournit la clé publique associée au certificat eHealth d'un prestataire de soins connu ou d'une institution connue. ↩ Montrer dans le texte Une erreur ? | fait | Systeem voor end-to-endversleuteling | eHealth-platform — eHealth-platform SRC-f1bf6746ab | sectie 'Wat is de dienst End to End Encryption van het eHealth-platform?' | 26-09-2026 |
| Le service KGSS est utilisé lorsque l'identité du destinataire du message chiffré n'est pas connue à l'avance, mais que certaines conditions doivent être remplies pour l'obtention de la clé de chiffrement. ↩ Montrer dans le texte Une erreur ? | fait | Systeem voor end-to-endversleuteling | eHealth-platform — eHealth-platform SRC-f1bf6746ab | sectie over KGSS | 26-09-2026 |
| Toegang tot de webservices van het eHealth-platform in de acceptatieomgeving vereist een eHealth-certificaat in acceptatie en de integratie van de connector, naast een uitgeteste computer/browser en meestal een medisch testprofiel. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | sectie 'Welke tools zijn vereist om de testen en demo's effectief uit te voeren?' | 26-09-2026 |
| Registratie van software is het proces waarbij gecontroleerd wordt of software voldoet aan vastgelegde kwaliteitsvereisten, zodat ze veilig, betrouwbaar en correct kan integreren met digitale toepassingen in de Belgische gezondheidszorg. ↩ Montrer dans le texte Une erreur ? | fait | Technische informatie en registratie voor softwareleveranciers van software voor zorgverleners | RIZIV — RIZIV SRC-db58d23cca | sectie 'Wat is registratie?' | 26-09-2026 |
| Ce n'est qu'après un « Approval Assessment » concluant, réalisé par l'équipe de test du Collège Intermutualiste (CIN), que le fournisseur de logiciels obtient l'agrément pour passer en production pour le(s) service(s) MyCareNet évalué(s). ↩ Montrer dans le texte Une erreur ? | fait | MyCareNet | eHealth-platform — eHealth-platform SRC-27a21c533f | sectie 'Belangrijk' | 26-09-2026 |
| Le service web Metahub lui-même (création/recherche de liens patient) est exclusivement destiné aux hubs, et non aux progiciels individuels des hôpitaux ou d'autres prestataires de soins. ↩ Montrer dans le texte Une erreur ? | fait | Verwijzingsrepertorium (Metahub) — eHealth-platform SRC-008bee8c2b | sectie 'Wat zijn de functionaliteiten van de diensten verbonden aan de dienst Metahub?' | 26-09-2026 |
| Le service web Metahub lui-même n'est accessible qu'aux hubs reconnus, mais les services connexes relatifs au consentement, aux relations thérapeutiques/relations de soins et aux exclusions sont également disponibles comme services REST, ce qui permet leur intégration dans des applications mobiles ou web de tiers. ↩ Montrer dans le texte Une erreur ? | fait | Verwijzingsrepertorium (Metahub) — eHealth-platform SRC-008bee8c2b | sectie 'In de praktijk' | 26-09-2026 |
| La plate-forme eHealth propose principalement deux types d'architecture: SOAP pour les applications qui tournent sur un seul appareil, et REST pour les applications qui doivent fonctionner simultanément sur plusieurs appareils (pc, smartphone, tablette); pour les nouveaux projets mobiles, REST est privilégié. ↩ Montrer dans le texte Une erreur ? | fait | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Inleiding' | 26-09-2026 |
| Le certificat permet d'identifier et d'authentifier le partenaire « système » (le logiciel/l'organisation), tandis que l'eID ou un token permet d'identifier et d'authentifier l'utilisateur individuel. ↩ Montrer dans le texte Une erreur ? | fait | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Wat is een eHealth-certificaat?' | 26-09-2026 |
| Un certificat de production est valide 36 mois et peut être renouvelé à partir de 90 jours avant la fin de cette période; la demande s'introduit via l'application web eHealth Certificate Manager. ↩ Montrer dans le texte Une erreur ? | fait | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Aanvraag van een certificaat - Werkwijze' | 26-09-2026 |
| La plate-forme eHealth annonce que l'ECC 384 remplacera « prochainement » le RSA 2048. Les deux types de certificats restent utilisables en parallèle, mais le eHealth Certificate Manager ne générera plus que des certificats ECC; les ETK resteront RSA. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | sectie 'Evolutie van de eHealth Certificate Manager (RSA - ECC)' | 26-09-2026 |
| Pour permettre une période de transition dans l'environnement d'acceptation, une version du eHealth Certificate Manager est disponible en parallèle pour continuer à commander des certificats RSA. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | sectie 'Evolutie van de eHealth Certificate Manager (RSA - ECC)' | 26-09-2026 |
| I.AM intègre la gestion des accès, la gestion des utilisateurs et la gestion de l'accès aux données dans un seul système qui distingue quatre contextes techniques: la sécurisation des applications web, des services web SOAP, des services web REST, et l'accès aux données (Data Access). ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Identity & Access management - Technische organisatie' | 26-09-2026 |
| Pour les applications web classiques côté serveur, l'authentification via I.AM IDP est recommandée (avec Shibboleth SP), tandis que les applications mobiles/natives et les applications REST passent par I.AM Connect. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Afhankelijkheden, aanbevelingen en waarschuwingen' | 26-09-2026 |
| Pour un client-ID d'organisation (machine-to-machine) dans I.AM Connect, une institution de soins utilise le format nihdi-\<type\>-XXXXXXXX, où XXXXXXXX est le numéro INAMI (NIHII) de l'institution. ↩ Montrer dans le texte Une erreur ? | fait | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 4 | 26-09-2026 |
| Voor webservices op het SOA-platform vereist eHealth op transportniveau een SSL/TLS-verbinding. ↩ Montrer dans le texte Une erreur ? | fait | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | Inleiding | 26-09-2026 |
| Voor webservices op het SOA-platform gebeurt de authenticatie op berichtniveau met X.509-certificaten. ↩ Montrer dans le texte Une erreur ? | fait | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | Inleiding | 26-09-2026 |
| Un chiffrement end-to-end complet entre l'expéditeur initial et le destinataire final n'est pas strictement nécessaire dans tous les projets, mais la communication doit au moins être sécurisée point-to-point, de sorte que des données médicales ne soient jamais échangées sans protection entre les parties. ↩ Montrer dans le texte Une erreur ? | fait | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Vertrouwelijkheid' | 26-09-2026 |
| De 'eHealth platform services connectors' zijn lichte lokale bibliotheken die softwareontwikkelaars helpen bij de integratie van de basisdiensten (vooral beveiliging: authenticatie, versleuteling) via een technische connectorlaag, aangevuld met een business-connectorlaag per zorgberoep. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | sectie 'Algemene informatie' | 26-09-2026 |
| Les connecteurs sont uniquement développés en Java; la variante.NET n'est pas un code natif mais est générée à partir du code source Java au moyen de l'outil IKVM (adapté). ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | sectie 'Algemene informatie' | 26-09-2026 |
| Depuis octobre 2023, l'utilisation de SHA256 est obligatoire pour les connecteurs et la version 4.1.2 est la version minimale prise en charge du connecteur, bien qu'il soit fortement recommandé de toujours utiliser la dernière version. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | FAQ 'Hoe pas ik de connector aan naar de nieuwe SHA256-veiligheidsstandaard?' | 26-09-2026 |
| Het eHealth-platform stelt een acceptatieomgeving ter beschikking van gebruikers en partners (instellingen en softwareleveranciers) om webtoepassingen en webservices te testen en te valideren tegen de gedefinieerde interoperabiliteits- en informatieveiligheidsspecificaties. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | sectie 'Doel?' | 26-09-2026 |
| Functioneel is de acceptatieomgeving identiek aan productie, maar de gegevens erin zijn normaal niet betrouwbaar, behalve in de drie weken voor een major release, wanneer acceptatie volledig met productie wordt gesynchroniseerd. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | sectie 'Let op het volgende' | 26-09-2026 |
| De acceptatieomgeving komt volgens eHealth functioneel overeen met productie, maar de gegevens verschillen. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | Let op het volgende, punt 1 | 26-09-2026 |
| La plate-forme eHealth diffuse sa liste de certificats de confiance (mise à jour du trust store) selon la spécification technique ETSI relative aux listes de confiance (Trusted Lists), de sorte que les logiciels puissent mettre à jour leur trust store de manière sécurisée et automatisable. ↩ Montrer dans le texte Une erreur ? | fait | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Cookbook' - eHealth PlatformTrusted Certificates List | 26-09-2026 |
| Le 7 juillet 2026, la plate-forme eHealth a publié un erratum à sa communication du 11 juin 2026 relative au renouvellement obligatoire des certificats/clés pour les intégrations SAML existantes (IDP/STS/AA) et pour la validation JWT dans I.AM Connect; les clients qui gèrent manuellement leurs métadonnées ou leurs truststores devaient adapter cela avant le 22/07/2026. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (07/07/2026) — eHealth-platform; 07-07-2026 SRC-2e3ed33307 | p. 1 | 26-09-2026 |
| Pour le rollover de la JWT signing key d'I.AM Connect, des moments clés distincts s'appliquaient à l'environnement d'acceptation (nouvelle clé active à partir du 07/07/2026, ancienne clé supprimée le 04/08/2026) et à l'environnement de production (nouvelle clé active à partir du 28/07/2026, ancienne clé supprimée le 26/08/2026). ↩ Montrer dans le texte Une erreur ? | fait | eHealth Communication: Renewal of I.AM Certificates - Required Actions for SAML and I.AM Connect Integrations (07/07/2026) — eHealth-platform; 07-07-2026 SRC-2e3ed33307 | p. 2 | 26-09-2026 |
| Softwareregistratie gebeurt onder de verantwoordelijkheid van het eHealth-platform, samen met beheerders van digitale toepassingen zoals het RIZIV. ↩ Montrer dans le texte Une erreur ? | fait | Technische informatie en registratie voor softwareleveranciers van software voor zorgverleners | RIZIV — RIZIV SRC-db58d23cca | sectie 'Wat is registratie?' | 26-09-2026 |
| Het RIZIV beschrijft softwareregistratie als een verantwoordelijkheid van het eHealth-platform. ↩ Montrer dans le texte Une erreur ? | fait | Softwareleveranciers: Algemene voorwaarden voor softwareregistratie — RIZIV SRC-4c54e62075 | Verantwoordelijkheid en context | 26-09-2026 |
| In de RIZIV-registratievoorwaarden verschilt de inschrijfwijze per project. ↩ Montrer dans le texte Une erreur ? | fait | Softwareleveranciers: Algemene voorwaarden voor softwareregistratie — RIZIV SRC-4c54e62075 | Inleiding | 26-09-2026 |
| Un logiciel enregistré s'engage à publier et à installer la version testée chez tous les utilisateurs dans les trois mois qui suivent la réussite du minilab. ↩ Montrer dans le texte Une erreur ? | fait | Registratie van de softwarepakketten — eHealth-platform SRC-9b3cdfdf5e | BELANGRIJK | 26-09-2026 |
| L'intégration du service web eHealthBox exige un certificat eHealth et l'intégration d'un service de chiffrement. ↩ Montrer dans le texte Une erreur ? | fait | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie 'Wat zijn de voorwaarden voor de integratie' | 26-09-2026 |
| Pour les intégrations SOAP avec l'eHealthBox, un certificat de base (certificat eHealth) suffit, sans l'étape d'onboarding supplémentaire I.AM Connect qui est exigée pour les services REST. ↩ Montrer dans le texte Une erreur ? | fait | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 1 | 26-09-2026 |
| CareConnect GP heeft een certificering 'Minilab eHBox'. De organisator is 'ehBox-Publication' van het eHealth-platform. ↩ Montrer dans le texte Une erreur ? | fait | Software Register API – certificeringen CareConnect General Practitioner (JSON) — eHealth-platform SRC-5d419bb730 | JSON-item certificering 'Minilab eHBox' | 26-09-2026 |
| Les prestataires de soins utilisent MyCareNet via leur logiciel professionnel, que le fournisseur adapte pour appeler les services MyCareNet du secteur. ↩ Montrer dans le texte Une erreur ? | fait | MyCareNet - algemene beschrijving — Nationaal Intermutualistisch College (NIC) SRC-50f3730800 | sectie 'Architectuur' | 26-09-2026 |
| Outre l'utilisation via un logiciel professionnel, il existe un portail MyCareNet, créé et géré par le CIN, avec des fonctions pour des opérations complexes et une connexion entre le prestataire de soins et l'organisme assureur. ↩ Montrer dans le texte Une erreur ? | fait | MyCareNet - algemene beschrijving — Nationaal Intermutualistisch College (NIC) SRC-50f3730800 | sectie 'Architectuur' | 26-09-2026 |
| Un fournisseur de logiciels qui souhaite accéder à l'environnement de test de MyCareNet doit d'abord s'inscrire auprès des services de MyCareNet (Collège Intermutualiste/CIN), après quoi il obtient l'accès à l'environnement SharePoint contenant l'ensemble de la documentation technique. ↩ Montrer dans le texte Une erreur ? | fait | MyCareNet | eHealth-platform — eHealth-platform SRC-27a21c533f | stap 1-2 | 26-09-2026 |
| Outre l'inscription MyCareNet elle-même, le fournisseur de logiciels doit aussi demander à la plate-forme eHealth un certificat de test pour le secteur concerné, avant de commencer les tests. ↩ Montrer dans le texte Une erreur ? | fait | MyCareNet | eHealth-platform — eHealth-platform SRC-27a21c533f | stap 3 | 26-09-2026 |
| Un logiciel peut s'intégrer à Vitalink via deux voies de documentation parallèles: un environnement KMEHR et un environnement FHIR, chacun avec sa propre documentation technique. ↩ Montrer dans le texte Une erreur ? | fait | Ik ben softwareleverancier | Vitalink — Vitalink / Vlaamse overheid SRC-a2ac63e929 | secties 'KMEHR-documentatie' en 'FHIR-documentatie' | 26-09-2026 |
| Vitalink est une plate-forme sécurisée sans interface propre pour les prestataires de soins; ceux-ci utilisent toujours Vitalink via leur propre logiciel professionnel, lequel doit pour cela parcourir une procédure d'accès. ↩ Montrer dans le texte Une erreur ? | fait | Ik ben softwareleverancier | Vitalink — Vitalink / Vlaamse overheid SRC-a2ac63e929 | inleidende alinea | 26-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 |
| Vitalink suit un rythme de releases d'une major release par trimestre, avec des minor releases intermédiaires; pour ce rythme de releases, un calendrier des releases et des release notes sont disponibles. ↩ Montrer dans le texte Une erreur ? | fait | Ik ben softwareleverancier | Vitalink — Vitalink / Vlaamse overheid SRC-a2ac63e929 | sectie 'Release notes en releaseplanning' | 26-09-2026 |
| Pour l'UHMEP FHIR API, un token exchange IAM est obligatoire (I.AM Connect), de sorte que l'exploitant technique n'obtient pas de droits de pseudonymisation. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e FHIR Cookbook (UHMEP-MedicationPrescription-Cookbook.pdf) — Smals / Recip-e; 04-06-2026 SRC-b4bdb9101a | p. 9 (2.3.2 Token Exchange) | 26-09-2026 |
| Dans l'API FHIR Recip-e (cookbook v1.0, 04/06/2026), les pharmaciens utilisent le realm M2M avec le client pharmacy. Les pharmacies hospitalières utilisent un client M2M propre et ne peuvent pas réutiliser le client de l'hôpital. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e FHIR Cookbook (UHMEP-MedicationPrescription-Cookbook.pdf) — Smals / Recip-e; 04-06-2026 SRC-b4bdb9101a | p. 6, 2.x Authentication (I.AM Connect) | 26-09-2026 |
| Bij gebruik van de FHIR-API (of bij hybride integratie) is een geslaagde pre-registratietest op de FHIR Test Server van het eHealth-platform verplicht vóór deelname aan de officiële registratietest voor het digitaal verwijsvoorschrift. ↩ Montrer dans le texte Une erreur ? | fait | Softwareleveranciers: Digitaal verwijsvoorschrift voor thuisverpleegkundigen (eReferral) — RIZIV SRC-6f22ff7069 | sectie 'Verplichte voorbereiding (pre-registratietest)' | 26-09-2026 |
| Voor het gebruik van de pseudonimiserings- en anonimiseringsdiensten is een beraadslaging (akkoord) van het Informatieveiligheidscomité verplicht. ↩ Montrer dans le texte Une erreur ? | fait | Pseudonymisation & Anonymisation — Plate-forme eHealth SRC-ac484b97eb | sectie 'Conditions' | 26-09-2026 |
| L'eHealth Addressbook (Consultation Webservice) permet aux acteurs de soins de santé de demander les coordonnées actuelles d'autres acteurs de soins; ces informations se trouvent dans CoBRHA. ↩ Montrer dans le texte Une erreur ? | fait | eHealth Addressbook Consultation Webservice — eHealth-platform SRC-87a6ea79ec | inleiding | 26-09-2026 |
| I.AM AA (Attribute Authority) permet aux partenaires de consulter les sources authentiques eHealth, dont CoBRHA (banque de données des acteurs de soins agréés) et les mandats, indépendamment de l'accès aux applications elles-mêmes. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'I.AM AA (AttributeAuthority)' | 26-09-2026 |
| Pour les variantes REST de l'eHealthBox et de l'Addressbook, un onboarding distinct via I.AM Connect est nécessaire, avec un choix parmi des formulaires d'enregistrement de client pour « Healthcare » (prestataire de soins individuel ou application) ou « M2M » (organisation). ↩ Montrer dans le texte Une erreur ? | fait | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 1 | 26-09-2026 |
| Celui qui veut utiliser l'eHealthBox comme service web a besoin d'un logiciel médical qui intègre le service; selon la plate-forme eHealth, c'est le cas pour tous les logiciels enregistrés par eHealth. ↩ Montrer dans le texte Une erreur ? | fait | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie 'Afhankelijkheden' | 26-09-2026 |
| Les messages dans l'eHealthBox peuvent contenir des pièces jointes, avec un volume maximal de 10 MB par message. ↩ Montrer dans le texte Une erreur ? | fait | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie 'Welke functionaliteiten' | 26-09-2026 |
| Le CIN fournit aux fournisseurs de logiciels une implementation guide, des exemples de messages et des implémentations de référence (.Net et Java), et leur demande de se charger du helpdesk de première ligne. ↩ Montrer dans le texte Une erreur ? | fait | Informatiebrochure voor de apothekers - Gebruik van MyCareNet in de voor het publiek toegankelijke officina's — RIZIV; 10-01-2012 SRC-c153772f65 | p. 22, 8.2.2.6 De rol van de softwareleverancier | 26-09-2026 |
| La version FHIR de Recip-e utilise des pseudonymes pour les identifiants de patients, via le service de pseudonymisation de la Plate-forme eHealth en tant que tiers de confiance. ↩ Montrer dans le texte Une erreur ? | fait | Recip-e FHIR Cookbook (UHMEP-MedicationPrescription-Cookbook.pdf) — Smals / Recip-e; 04-06-2026 SRC-b4bdb9101a | p. 6 (2.1 Pseudonymisation) | 26-09-2026 |
| Het eHealth-platform biedt pseudonimiseringsdiensten aan zodat persoonsgebonden gezondheidsgegevens worden omgezet in gecodeerde of anonieme gegevens. ↩ Montrer dans le texte Une erreur ? | fait | Pseudonymisation & Anonymisation — Plate-forme eHealth SRC-ac484b97eb | inleiding | 26-09-2026 |
| Bij "Batch codage" treedt het eHealth-platform op als trusted third party (TTP) voor het coderen en decoderen van gezondheidsgegevens voor rekening van een partner. ↩ Montrer dans le texte Une erreur ? | fait | Pseudonymisation & Anonymisation — Plate-forme eHealth SRC-ac484b97eb | sectie 'Pseudonymisation' | 26-09-2026 |
| De afgeleide dienst "Blinded pseudo" past pseudoniemen aan per verwerkende partij zonder de gegevens te depseudonimiseren. ↩ Montrer dans le texte Une erreur ? | fait | Pseudonymisation & Anonymisation — Plate-forme eHealth SRC-ac484b97eb | sectie 'Blinded pseudo' | 26-09-2026 |
| Dans le flux de données HD4DP, les variables de registre sont envoyées directement vers healthdata.be, tandis que les identifiants de patients passent par le client de messagerie eHealthBox de l'hôpital vers le service TTP d'eHealth et arrivent pseudonymisés chez healthdata.be. ↩ Montrer dans le texte Une erreur ? | fait | Dataflow description HD4DP v2 — healthdata.be (HDA) SRC-ae6b9db626 | stappen 3-6 | 26-09-2026 |
| La librairie Smals de pseudonymisation convertit un numéro d'identification de patient (NISS) en un point de courbe elliptique et l'aveugle avant chaque appel au service de pseudonymisation de la plate-forme eHealth, de sorte que ce service ne voit jamais lui-même d'identifiant de patient. ↩ Montrer dans le texte Une erreur ? | fait | GitHub - smals-belgium/shared-pseudo-helper-java: Library that helps eHealth Pseudonymisation integration in Java applications · GitHub — Smals SRC-62e7d58b4b | README - sectie over de eHealth Pseudonymisation service | 26-09-2026 |
| La librairie Smals convertit d'abord un numéro d'identification en un point sur la courbe elliptique et aveugle ce point avant d'appeler l'opération « pseudonymize » du service de pseudonymisation de la plate-forme eHealth. ↩ Montrer dans le texte Une erreur ? | fait | GitHub - smals-belgium/shared-pseudo-helper-java: Library that helps eHealth Pseudonymisation integration in Java applications · GitHub — Smals SRC-62e7d58b4b | README - sectie over de eHealth Pseudonymisation service | 28-09-2026 |
| Pour les prestataires de soins et les institutions de soins, l'Addressbook renvoie aussi l'identification eHealthBox (box-ID et type NISS/NIHII/CBE). ↩ Montrer dans le texte Une erreur ? | fait | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie Addressbook-functionaliteit | 26-09-2026 |
| I.AM (Identity & Access Management) est le service eHealth intégré d'identification, d'authentification et d'autorisation des acteurs de soins de santé qui demandent l'accès à des services de la plate-forme eHealth et de ses partenaires. ↩ Montrer dans le texte Une erreur ? | fait | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Wat is de dienst Geïntegreerd gebruikers- en toegangsbeheer/I.AM?' | 26-09-2026 |
| La facturation électronique via MyCareNet en cas d'application du tiers payant est obligatoire pour, entre autres, les hôpitaux, les laboratoires de biologie clinique, les médecins, les dentistes et les infirmiers à domicile. ↩ Montrer dans le texte Une erreur ? | fait | Instructions de facturation électronique en tiers payant — INAMI SRC-f9c49eb375 | inleiding | 26-09-2026 |
| Vergoedingsmechanismen voor zorgverleners steunen op de registratiegegevens in het Software Register. Registratie geeft niet automatisch recht op een vergoeding. ↩ Montrer dans le texte Une erreur ? | fait | Technische informatie en registratie voor softwareleveranciers van software voor zorgverleners | RIZIV — RIZIV SRC-db58d23cca | sectie 'Vergoedingsmechanismen' | 26-09-2026 |
| Het eHealth-platform gebruikt een evaluatiesysteem voor softwarepakketten waarop het RIZIV zich baseert voor eventuele telematicapremies; dit is een financieringscontext. ↩ Montrer dans le texte Une erreur ? | fait | Registratie van de softwarepakketten — eHealth-platform SRC-9b3cdfdf5e | Algemene informatie | 26-09-2026 |
| Outre le certificat de production, il existe des certificats d'acceptation distincts pour les intégrateurs de logiciels; un certificat d'acceptation est valide 3 ans mais ne donne aucun accès à l'environnement de production. ↩ Montrer dans le texte Une erreur ? | fait | Richtlijn betreffende de vernieuwing van de publieke sleutel van een certificaat. | eHealth-platform — eHealth-platform SRC-5e41adfb50 | sectie 'De acceptatiecertificaten van het eHealth-platform' | 26-09-2026 |
| L'ancien service STS Saml11TokenService (avec l'endpoint iamsaml11tokenservice) n'est plus utilisé depuis octobre 2023; depuis lors, les connecteurs doivent utiliser le nouvel endpoint SecurityTokenService (iamsecuritytokenservice), ce qui confronte encore certaines intégrations à l'erreur « SOA-03005 WSDL compliance failure » lorsque cette adaptation n'a pas été faite. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | FAQ 'Hoe pas ik de connector aan naar de nieuwe SecurityTokenService?' | 26-09-2026 |
| Selon la FAQ, une cause possible de l'erreur « SOA-03005 WSDL compliance failure » est une valeur obsolète de la propriété de configuration endpoint.sts, qui renvoie encore à l'ancien Saml11TokenService. ↩ Montrer dans le texte Une erreur ? | fait | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | FAQ 'Wat moet ik doen bij de foutmelding SOA-03005 WSDL compliance failure?' | 26-09-2026 |
| Selon une présentation publiée publiquement de la Plate-forme eHealth (30 janvier 2026), Recip-e (services web SOAP) doit passer de SAML v1 à SAML v2, parce que la Plate-forme eHealth l'exige en 2026 pour toutes les applications qui utilisent les services de base eHealth. ↩ Montrer dans le texte Une erreur ? | fait | Réalisations 2025 – Perspectives 2026 (Plate-forme eHealth) — eHealth-platform (publieke presentatie op de persoonlijke website van de administrateur-generaal); 30-01-2026 SRC-88e226b672 | dia 55 ('Elektronisch voorschrift van geneesmiddelen', SAMLv2-migratie, 2026) | 26-09-2026 |
| Selon le cookbook actuel « Beveiliging van webservices », le consommateur du service demande explicitement, à l'étape 1 du processus d'authentification STS, un jeton SAML 1.1 et signe à cette occasion l'appel SOAP selon la policy de sécurité X.509 SHA256. ↩ Montrer dans le texte Une erreur ? | fait | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | sectie 'Stap voor stap' - Stap 1 | 26-09-2026 |
| La question de savoir si UHMEP est un successeur complet de Recip-e pour les prescriptions de médicaments ou bien un cadre technique distinct, propre à la prescription de renvoi numérique (eReferral) et coexistant avec Recip-e, n'est pas confirmée à titre primaire par les sources trouvées; les pages de projet eHealth ne traitent d'UHMEP que dans le contexte d'eReferral. ↩ Montrer dans le texte Une erreur ? | interprétation | eReferral-Digitaal Verwijsvoorschrift | eHealth-platform — eHealth-platform SRC-972e1a8c71 | volledige pagina (afwezigheid van koppeling met Recip-e-voorschriften) | 26-09-2026 |
| Het eHealth-platform blijft de SOAP-architectuur onderhouden en ondersteunen, maar raadt ze af voor projecten voor mobiele apparaten en geeft prioriteit aan REST. Une erreur ? | fait | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie '1. Inleiding' | 28-09-2026 |
Non reprises dans le texte 1 affirmations
Ces affirmations proviennent des mêmes sources et ont été vérifiées, mais l'article consacré à Intégration technique avec l'infrastructure eHealth ne les utilise pas (encore).
| Affirmation | Type | Source | Emplacement | Date de référence |
|---|---|---|---|---|
| Sinds de eHealth-release 2023.2 (productie 15/10/2023) aanvaarden de SOAP-webservices van het eHealth-platform enkel nog SHA-256; integraties die SHA-1 bleven gebruiken, werkten daarna niet meer. Une erreur ? | fait | Bericht aan gebruikers van SOAP (SHA-256 en nieuwe SecurityTokenService) — eHealth-platform; 19-06-2023 SRC-8f47b20551 | p. 1 | 26-09-2026 |