Conceptrecord · Overzicht of dossier
Beweringen: Technische integratie met de eHealth-infrastructuur
- Overzicht of dossier
- niet van toepassing
- België (federaal/interfederaal)
- Architectuur en infrastructuur
- Identiteit, toegang en audit
Atlas-ID technische-integratie-ehealth · 79 beweringen · 30 bronnen
· Laatst geverifieerd 28-09-2026
· Release 2026.10.01-7
Overzicht per doeldienst (eHealthBox, MyCareNet, hubs-metahub en Consent/Therlink, Vitalink, Recip-e/UHMEP, pseudonimisering, Addressbook/CoBRHA) van wat een softwarepakket nodig heeft om met de Belgische eHealth-infrastructuur te koppelen. Gemeenschappelijke bouwstenen zijn een eHealth-certificaat voor system-to-systemtoegang, I.AM (STS/SAML voor SOAP, I.AM Connect/OIDC voor REST), ETEE-versleuteling, de acceptatieomgeving en de eHealth-connectoren, gevolgd door een registratietest of erkenning per dienst.
Hieronder staan de beweringen waarop de pagina over Technische integratie met de eHealth-infrastructuur steunt: korte, eigen geformuleerde feiten, elk met de bron en de vindplaats waar je ze kan nagaan. Lees het artikel · Zo werkt de Atlas.
Beweringen 78 beweringen
| Bewering | Soort | Bron | Vindplaats | Peildatum |
|---|---|---|---|---|
| Een eHealth-certificaat laat een zorgverlener of organisatie toe zich te authentiseren als zorgverlener of erkende instelling; het is vereist zodra een softwarepakket via een system-to-systemverbinding (geen webtoepassing) toegang wil tot eHealth-basisdiensten. ↩ Toon in de tekst Klopt niet? | feit | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Wat is een eHealth-certificaat?' | 26-09-2026 |
| I.AM Connect is een identiteits- en toegangsbeheeroplossing voor webapplicaties en RESTful webservices, gebaseerd op de OIDC-standaard (OpenID Connect); voor REST-diensten worden klant en autorisatie via I.AM Connect afgehandeld op basis van OIDC, niet op basis van SAML. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| Voor SOAP-integraties met eHealthBox volstaat een basiscertificaat (eHealth-certificaat), zonder de bijkomende I.AM Connect-onboardingstap die voor de REST-diensten vereist is. ↩ Toon in de tekst Klopt niet? | feit | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 1 | 26-09-2026 |
| Voor de REST-varianten van eHealthBox en Addressbook is een aparte onboarding via I.AM Connect vereist, met een keuze uit client-registratieformulieren voor 'Healthcare' (individuele zorgverlener of applicatie) of 'M2M' (organisatie). ↩ Toon in de tekst Klopt niet? | feit | Procedure: Onboarding IAM Connect eHealthBox - Addressbook v2.0 — eHealth-platform; 29-05-2024 SRC-771a066b18 | p. 1 | 26-09-2026 |
| Voor beveiliging van SOAP-webservices authenticeert de service consumer zich bij I.AM STS (Secure Token Service) met een eHealth-certificaat of eID, waarna de STS een SAML-token aflevert dat binnen zijn geldigheidsperiode meerdere webservices toegang geeft. ↩ Toon in de tekst Klopt niet? | feit | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | sectie 'Veiligheid - WS-Security SAML Token Profile / Holder-of-Key' | 26-09-2026 |
| Het eHealth-platform vereist dat medische gegevens minstens op berichtniveau beveiligd worden (niet enkel op transportniveau), zodat gegevens niet onbeschermd circuleren tussen de punten van het netwerk waarlangs ze passeren. ↩ Toon in de tekst Klopt niet? | feit | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Vertrouwelijkheid' | 26-09-2026 |
| De ETEE-dienst (End to End Encryption) van het eHealth-platform laat toe berichten aan zorgverleners of instellingen te versleutelen en wordt gebruikt door onder meer eHealthBox en de elektronische voorschriften (Recip-e). (ETK is de publieke versleutelingssleutel die daarbij gebruikt wordt, geen andere naam voor de dienst.) ↩ Toon in de tekst Klopt niet? | feit | 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 |
| De ETEE-versleuteling wordt onder meer toegepast binnen eHealthBox en Recip-e; de ETK-webservice levert de publieke sleutel op die aan het eHealth-certificaat van een gekende zorgverlener of instelling gekoppeld is. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| De dienst KGSS wordt gebruikt wanneer de identiteit van de bestemmeling van een versleuteld bericht niet op voorhand gekend is, maar bepaalde voorwaarden vervuld moeten zijn om de encryptiesleutel te verkrijgen. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| 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. ↩ Toon in de tekst Klopt niet? | feit | Testomgevingen | eHealth-platform — eHealth-platform SRC-91df64378c | algemene informatie testomgevingenpagina | 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. ↩ Toon in de tekst Klopt niet? | feit | Technische informatie en registratie voor softwareleveranciers van software voor zorgverleners | RIZIV — RIZIV SRC-db58d23cca | sectie 'Wat is registratie?' | 26-09-2026 |
| Pas na een geslaagd 'Approval Assessment', afgenomen door het testteam van het Intermutualistisch College (NIC), krijgt een softwarepakket erkenning om met MyCareNet in productie te gaan. ↩ Toon in de tekst Klopt niet? | feit | MyCareNet | eHealth-platform — eHealth-platform SRC-27a21c533f | sectie 'Belangrijk' | 26-09-2026 |
| De Metahub-webservice zelf (aanmaak/opzoeking van patiëntlinks) is exclusief voor hubs bestemd, niet voor individuele softwarepakketten van ziekenhuizen of andere zorgaanbieders. ↩ Toon in de tekst Klopt niet? | feit | Verwijzingsrepertorium (Metahub) — eHealth-platform SRC-008bee8c2b | sectie 'Wat zijn de functionaliteiten van de diensten verbonden aan de dienst Metahub?' | 26-09-2026 |
| De Metahub-webservice zelf is enkel toegankelijk voor erkende hubs, maar de bijhorende diensten voor toestemming, therapeutische relaties/zorgrelaties en uitsluitingen zijn ook als REST-diensten beschikbaar, wat integratie in mobiele of webapplicaties van derden toelaat. ↩ Toon in de tekst Klopt niet? | feit | Verwijzingsrepertorium (Metahub) — eHealth-platform SRC-008bee8c2b | sectie 'In de praktijk' | 26-09-2026 |
| 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. ↩ Toon in de tekst Klopt niet? | feit | Technische informatie en registratie voor softwareleveranciers van software voor zorgverleners | RIZIV — RIZIV SRC-db58d23cca | sectie 'Registratie voor een specifieke digitale toepassing' | 26-09-2026 |
| Het eHealth-platform biedt hoofdzakelijk twee architectuurtypes aan: SOAP voor toepassingen die op één toestel draaien, en REST voor toepassingen die tegelijk op meerdere toestellen (pc, smartphone, tablet) moeten functioneren; voor nieuwe mobiele projecten krijgt REST de voorkeur. ↩ Toon in de tekst Klopt niet? | feit | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie 'Inleiding' | 26-09-2026 |
| Het certificaat identificeert en authenticeert de 'systeem'-partner (de software/organisatie), terwijl de eID of een token de individuele gebruiker identificeert en authenticeert. ↩ Toon in de tekst Klopt niet? | feit | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Wat is een eHealth-certificaat?' | 26-09-2026 |
| Een productiecertificaat is 36 maanden geldig en hernieuwbaar vanaf 90 dagen voor het verstrijken van die termijn; de aanvraag verloopt via de webapplicatie eHealth Certificate Manager. ↩ Toon in de tekst Klopt niet? | feit | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Aanvraag van een certificaat - Werkwijze' | 26-09-2026 |
| Het eHealth-platform kondigt aan dat ECC 384 'binnenkort' RSA-2048 vervangt. Beide certificaattypes blijven parallel bruikbaar, maar de eHealth Certificate Manager zal enkel nog ECC-certificaten genereren; de ETK's blijven RSA. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| Voor een overgangsperiode in de acceptatieomgeving is een parallelle versie van de eHealth Certificate Manager beschikbaar waarmee nog RSA-certificaten besteld kunnen worden. ↩ Toon in de tekst Klopt niet? | feit | 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 integreert toegangsbeheer, gebruikersbeheer en gegevenstoegangsbeheer in één systeem dat onderscheid maakt tussen vier technische contexten: beveiliging van webapplicaties, van SOAP- webservices, van REST-webservices, en gegevenstoegang (Data Access). ↩ Toon in de tekst Klopt niet? | feit | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Identity & Access management - Technische organisatie' | 26-09-2026 |
| Voor klassieke server-side webapplicaties wordt authenticatie via I.AM IDP aanbevolen (met Shibboleth SP), terwijl mobiele/native applicaties en REST-toepassingen via I.AM Connect verlopen. ↩ Toon in de tekst Klopt niet? | feit | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'Afhankelijkheden, aanbevelingen en waarschuwingen' | 26-09-2026 |
| Voor een organisatie (machine-to-machine) client-ID in I.AM Connect gebruikt een zorginstelling het formaat nihdi-\<type\>-XXXXXXXX, waarbij XXXXXXXX het RIZIV-nummer (NIHII) van de instelling is. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | Inleiding | 26-09-2026 |
| Volledige end-to-endversleuteling tussen oorspronkelijke verzender en eindbestemmeling is niet in elk project strikt noodzakelijk, maar de communicatie moet minstens point-to-point beveiligd zijn zodat medische gegevens nooit onbeveiligd tussen partijen worden uitgewisseld. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | sectie 'Algemene informatie' | 26-09-2026 |
| De connectoren worden uitsluitend in Java ontwikkeld; de.NET-variant is geen native code maar wordt via de (aangepaste) IKVM-tool uit de Java-broncode gegenereerd. ↩ Toon in de tekst Klopt niet? | feit | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | sectie 'Algemene informatie' | 26-09-2026 |
| Sinds oktober 2023 is het gebruik van SHA256 verplicht voor de connectoren en is versie 4.1.2 de minimaal ondersteunde connectorversie, al wordt sterk aangeraden steeds de laatste versie te gebruiken. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| Het eHealth-platform verspreidt zijn lijst van vertrouwde certificaten (trust store-update) volgens de ETSI-specificatie voor vertrouwde lijsten (Trusted Lists), zodat softwarepakketten hun trust store veilig en automatiseerbaar kunnen bijwerken. ↩ Toon in de tekst Klopt niet? | feit | eHealth-certificaten | eHealth-platform — eHealth-platform SRC-9bfcb37059 | sectie 'Cookbook' - eHealth PlatformTrusted Certificates List | 26-09-2026 |
| Op 7 juli 2026 kondigde het eHealth-platform een verplichte hernieuwing aan van de certificaten/ sleutels die gebruikt worden voor bestaande SAML-integraties (IDP/STS/AA) en voor de JWT-validatie in I.AM Connect; klanten met handmatig metadata- of truststorebeheer moesten dit vóór 22/07/2026 aanpassen. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| Voor de I.AM Connect JWT signing key rollover golden aparte sleutelmomenten voor de acceptatie- omgeving (nieuwe sleutel actief vanaf 07/07/2026, oude sleutel verwijderd op 04/08/2026) en de productieomgeving (nieuwe sleutel actief vanaf 28/07/2026, oude sleutel verwijderd op 26/08/2026). ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | Softwareleveranciers: Algemene voorwaarden voor softwareregistratie — RIZIV SRC-4c54e62075 | Verantwoordelijkheid en context | 26-09-2026 |
| In de RIZIV-registratievoorwaarden verschilt de inschrijfwijze per project. ↩ Toon in de tekst Klopt niet? | feit | Softwareleveranciers: Algemene voorwaarden voor softwareregistratie — RIZIV SRC-4c54e62075 | Inleiding | 26-09-2026 |
| Een geregistreerd softwarepakket verbindt zich ertoe de geteste versie binnen drie maanden na het geslaagde minilab bij alle gebruikers te publiceren en te installeren. ↩ Toon in de tekst Klopt niet? | feit | Registratie van de softwarepakketten — eHealth-platform SRC-9b3cdfdf5e | BELANGRIJK | 26-09-2026 |
| Integratie van de eHealthBox-webservice vereist een eHealth-certificaat en de integratie van een versleutelingsdienst. ↩ Toon in de tekst Klopt niet? | feit | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie 'Wat zijn de voorwaarden voor de integratie' | 26-09-2026 |
| CareConnect GP heeft een certificering 'Minilab eHBox'. De organisator is 'ehBox-Publication' van het eHealth-platform. ↩ Toon in de tekst Klopt niet? | feit | Software Register API – certificeringen CareConnect General Practitioner (JSON) — eHealth-platform SRC-5d419bb730 | JSON-item certificering 'Minilab eHBox' | 26-09-2026 |
| Zorgverleners gebruiken MyCareNet via hun bedrijfssoftware, die de leverancier aanpast om de MyCareNet-diensten van de sector aan te roepen. ↩ Toon in de tekst Klopt niet? | feit | MyCareNet - algemene beschrijving — Nationaal Intermutualistisch College (NIC) SRC-50f3730800 | sectie 'Architectuur' | 26-09-2026 |
| Naast het gebruik via bedrijfssoftware bestaat een MyCareNet-portaal, opgericht en beheerd door het NIC, met functies voor complexe bewerkingen en een verbinding tussen zorgverlener en verzekeringsinstelling. ↩ Toon in de tekst Klopt niet? | feit | MyCareNet - algemene beschrijving — Nationaal Intermutualistisch College (NIC) SRC-50f3730800 | sectie 'Architectuur' | 26-09-2026 |
| Een softwareleverancier die toegang wil tot de MyCareNet-testomgeving moet zich eerst inschrijven bij de diensten van MyCareNet (Intermutualistisch College/NIC), waarna hij toegang krijgt tot de SharePoint-omgeving met de volledige technische documentatie. ↩ Toon in de tekst Klopt niet? | feit | MyCareNet | eHealth-platform — eHealth-platform SRC-27a21c533f | stap 1-2 | 26-09-2026 |
| Naast de MyCareNet-inschrijving zelf moet de softwareleverancier bij het eHealth-platform ook een testcertificaat aanvragen voor de betrokken sector, vooraleer met testen te starten. ↩ Toon in de tekst Klopt niet? | feit | MyCareNet | eHealth-platform — eHealth-platform SRC-27a21c533f | stap 3 | 26-09-2026 |
| Software kan met Vitalink integreren via twee parallelle documentatiesporen: een KMEHR-omgeving en een FHIR-omgeving, elk met eigen technische documentatie. ↩ Toon in de tekst Klopt niet? | feit | Ik ben softwareleverancier | Vitalink — Vitalink / Vlaamse overheid SRC-a2ac63e929 | secties 'KMEHR-documentatie' en 'FHIR-documentatie' | 26-09-2026 |
| Vitalink is een beveiligd platform zonder eigen interface voor zorgverleners; zij gebruiken Vitalink altijd via hun eigen professionele software, die daarvoor een toegangsprocedure moet doorlopen. ↩ Toon in de tekst Klopt niet? | feit | Ik ben softwareleverancier | Vitalink — Vitalink / Vlaamse overheid SRC-a2ac63e929 | inleidende alinea | 26-09-2026 |
| De Vitalink FHIR-omgeving werd in productie genomen (bericht van 22 maart 2024) en staat naast de bestaande KMEHR-omgeving. ↩ Toon in de tekst Klopt niet? | feit | Nieuwe FHIR-omgeving van Vitalink in productie! — Vitalink (Departement Zorg); 22-03-2024 SRC-a7e3a494e9 | nieuwsbericht | 25-09-2026 |
| Vitalink volgt een releaseritme van één major release per kwartaal, met tussentijdse minor releases, waarvoor een release-kalender en releasenotes beschikbaar zijn. ↩ Toon in de tekst Klopt niet? | feit | Ik ben softwareleverancier | Vitalink — Vitalink / Vlaamse overheid SRC-a2ac63e929 | sectie 'Release notes en releaseplanning' | 26-09-2026 |
| Voor de UHMEP FHIR API is een IAM-token-exchange verplicht (I.AM Connect), zodat de technische uitbater geen pseudonimiseringsrechten krijgt. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| In de Recip-e FHIR-API (cookbook v1.0, 04/06/2026) gebruiken apothekers de M2M-realm met de pharmacy client. Ziekenhuisapotheken gebruiken een eigen M2M-client en mogen de client van het ziekenhuis niet hergebruiken. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | Pseudonymisation & Anonymisation — Plate-forme eHealth SRC-ac484b97eb | sectie 'Conditions' | 26-09-2026 |
| Het eHealth Addressbook (Consultation Webservice) laat zorgactoren toe actuele contactgegevens van andere zorgactoren op te vragen; die informatie bevindt zich in CoBRHA. ↩ Toon in de tekst Klopt niet? | feit | eHealth Addressbook Consultation Webservice — eHealth-platform SRC-87a6ea79ec | inleiding | 26-09-2026 |
| I.AM AA (Attribute Authority) laat partners toe de authentieke eHealth-bronnen te raadplegen, waaronder CoBRHA (gegevensbank van erkende zorgactoren) en mandaten, los van de toegang tot de toepassingen zelf. ↩ Toon in de tekst Klopt niet? | feit | I.AM (Identity & Access Management) | eHealth-platform — eHealth-platform SRC-81723a4a0f | sectie 'I.AM AA (AttributeAuthority)' | 26-09-2026 |
| Wie de eHealthBox als webservice wil gebruiken, heeft medische software nodig die de dienst integreert; volgens het eHealth-platform is dat het geval voor alle door eHealth geregistreerde softwarepakketten. ↩ Toon in de tekst Klopt niet? | feit | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie 'Afhankelijkheden' | 26-09-2026 |
| Berichten in de eHealthBox kunnen bijlagen bevatten, met een maximaal berichtvolume van 10 MB. ↩ Toon in de tekst Klopt niet? | feit | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie 'Welke functionaliteiten' | 26-09-2026 |
| Het NIC geeft softwareleveranciers een implementation guide, voorbeeldberichten en referentie-implementaties (.Net en Java), en vraagt hen de eerstelijnshelpdesk op te nemen. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| De FHIR-versie van Recip-e gebruikt pseudoniemen voor patiëntidentificatoren, via de pseudodienst van het eHealth-platform als vertrouwde partij. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | Pseudonymisation & Anonymisation — Plate-forme eHealth SRC-ac484b97eb | sectie 'Blinded pseudo' | 26-09-2026 |
| In de HD4DP-datastroom worden registervariabelen rechtstreeks naar healthdata.be gestuurd, terwijl patiëntidentificatoren via de eHealthBox-berichtenclient van het ziekenhuis naar de TTP-dienst van eHealth gaan en gepseudonimiseerd bij healthdata.be aankomen. ↩ Toon in de tekst Klopt niet? | feit | Dataflow description HD4DP v2 — healthdata.be (HDA) SRC-ae6b9db626 | stappen 3-6 | 26-09-2026 |
| De Smals-bibliotheek voor pseudonimisering zet een patiëntidentificatienummer (SSIN) om in een elliptic-curve-punt en verblindt dit vóór elke aanroep van de eHealth-pseudonimiseringsdienst, zodat die dienst zelf nooit een patiëntidentificator te zien krijgt. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| De Smals-bibliotheek zet een identificatienummer eerst om in een punt op de elliptic curve en verblindt dit punt vóór het de 'pseudonymize'-operatie van de eHealth-pseudonimiseringsdienst aanroept. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| Het Addressbook geeft voor zorgverleners en zorginstellingen ook de eHealthBox-identificatie terug (box-ID en type INSZ/NIHII/CBE). ↩ Toon in de tekst Klopt niet? | feit | eHealthBox — eHealth-platform SRC-71c7c4bb9f | sectie Addressbook-functionaliteit | 26-09-2026 |
| I.AM (Identity & Access Management) is de geïntegreerde eHealth-dienst voor identificatie, authenticatie en machtiging van zorgactoren die toegang vragen tot diensten van het eHealth-platform en zijn partners. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| Elektronische facturatie via MyCareNet in derdebetalersregeling is verplicht voor onder meer ziekenhuizen, klinische laboratoria, artsen, tandartsen en thuisverpleegkundigen. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | 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. ↩ Toon in de tekst Klopt niet? | feit | Registratie van de softwarepakketten — eHealth-platform SRC-9b3cdfdf5e | Algemene informatie | 26-09-2026 |
| Naast een productiecertificaat bestaan aparte acceptatiecertificaten voor software-integratoren; een acceptatiecertificaat is 3 jaar geldig maar geeft geen toegang tot de productieomgeving. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| De oudere STS-service Saml11TokenService (met het endpoint iamsaml11tokenservice) wordt sinds oktober 2023 niet meer gebruikt; connectoren moeten sindsdien de nieuwe SecurityTokenService- endpoint (iamsecuritytokenservice) gebruiken, wat sommige integraties nog met de foutmelding 'SOA-03005 WSDL compliance failure' confronteert als dit niet is aangepast. ↩ Toon in de tekst Klopt niet? | feit | eHealth platform services connectors | eHealth-platform — eHealth-platform SRC-ef6afc402c | FAQ 'Hoe pas ik de connector aan naar de nieuwe SecurityTokenService?' | 26-09-2026 |
| Volgens de FAQ is een mogelijke oorzaak van de fout 'SOA-03005 WSDL compliance failure' een verouderde waarde van de configuratie-eigenschap endpoint.sts, die nog naar de oude Saml11TokenService verwijst. ↩ Toon in de tekst Klopt niet? | feit | 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 |
| Volgens een publiek gepubliceerde presentatie van het eHealth-platform (30 januari 2026) moet Recip-e (SOAP-webservices) overstappen van SAML v1 naar SAML v2, omdat het eHealth-platform dit in 2026 vereist voor alle toepassingen die de eHealth-basisdiensten gebruiken. ↩ Toon in de tekst Klopt niet? | feit | Réalisations 2025 – Perspectives 2026 (Plate-forme eHealth) — Frank Robben / eHealth-platform (publieke presentatie op frankrobben.be); 30-01-2026 SRC-88e226b672 | dia 55 ('Elektronisch voorschrift van geneesmiddelen', SAMLv2-migratie, 2026) | 26-09-2026 |
| Volgens de actuele cookbook "Beveiliging van webservices" vraagt de service consumer bij stap 1 van het STS-authenticatieproces expliciet een SAML 1.1-token op, ondertekend volgens de X.509 SHA256-beveiligingspolicy. ↩ Toon in de tekst Klopt niet? | feit | Beveiliging van webservices | eHealth-platform — eHealth-platform SRC-8846f43048 | sectie 'Stap voor stap' - Stap 1 | 26-09-2026 |
| Het is met de gevonden bronnen niet primair bevestigd of UHMEP een volledige opvolger is van Recip-e voor geneesmiddelenvoorschriften, dan wel een apart technisch kader specifiek voor het digitaal verwijsvoorschrift (eReferral) dat naast Recip-e bestaat; de eHealth-projectpagina's behandelen UHMEP uitsluitend in de context van eReferral. ↩ Toon in de tekst Klopt niet? | interpretatie | 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. Klopt niet? | feit | Architecturen | eHealth-platform — eHealth-platform SRC-0eb97991a9 | sectie '1. Inleiding' | 28-09-2026 |
Niet in de tekst verwerkt 1 beweringen
Deze beweringen komen uit dezelfde bronnen en zijn nagekeken, maar het artikel over Technische integratie met de eHealth-infrastructuur gebruikt ze (nog) niet.
| Bewering | Soort | Bron | Vindplaats | Peildatum |
|---|---|---|---|---|
| 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. Klopt niet? | feit | Bericht aan gebruikers van SOAP (SHA-256 en nieuwe SecurityTokenService) — eHealth-platform; 19-06-2023 SRC-8f47b20551 | p. 1 | 26-09-2026 |