Technische integratie met de eHealth-infrastructuur

Welke technische en administratieve stappen moet een softwarepakket (EPD, LIS, apotheek- of huisartsensoftware, middleware) doorlopen om een bepaalde dienst van de Belgische eHealth-infrastructuur te gebruiken? (Synthese) Het patroon komt meestal neer op: identificeer het systeem (certificaat), authenticeer de gebruiker of organisatie via I.AM, versleutel de inhoud, test in acceptatie en laat de integratie registreren of erkennen. De details verschillen per doeldienst, en niet elke stap geldt overal: een webapplicatie zonder eigen integratie vraagt bijvoorbeeld geen registratietest^[9].

• Architectuurkeuze: het eHealth-platform biedt SOAP aan voor toepassingen op één toestel en REST voor toepassingen op meerdere toestellen; voor nieuwe mobiele projecten krijgt REST de voorkeur^[5].
• Certificaat: het certificaat identificeert het systeem, de eID of een token de gebruiker^[1]. Productiecertificaten zijn 36 maanden geldig^[1]. Het eHealth-platform kondigt een overstap naar ECC 384 aan: de Certificate Manager zal enkel nog ECC-certificaten genereren (ETK's blijven RSA)^[7]; in acceptatie kunnen nog RSA-certificaten besteld worden^[7]. Zie eHealth-certificaten en versleuteling (ETEE).
• I.AM: vier technische contexten (webapplicaties, SOAP, REST, Data Access)^[2]. Klassieke webapplicaties gebruiken I.AM IDP, mobiele en REST-toepassingen I.AM Connect^[2]. Organisaties registreren een M2M-client met hun RIZIV-nummer in de client-ID^[3].
• Transport- en berichtbeveiliging: voor webservices op het SOA-platform is op transportniveau steeds een SSL/TLS-verbinding vereist^[4], en op berichtniveau authenticeert de service consumer zich met X.509-certificaten^[4].
• Beveiliging van de inhoud: minstens berichtniveau^[5]; volledige end-to-endversleuteling is niet altijd nodig, point-to-pointbeveiliging wel^[5].
• Connectoren: vrije Java-bibliotheken (met gegenereerde .NET-variant) voor authenticatie en versleuteling^[12]; minimaal versie 4.1.2 en SHA256 sinds oktober 2023^[12]. Zie eHealth-connectoren (eHealth platform services connectors).
• Acceptatieomgeving: beschikbaar voor instellingen en softwareleveranciers om tegen de interoperabiliteits- en veiligheidsspecificaties te testen^[7]. Functioneel identiek aan productie, maar de gegevens zijn normaal niet betrouwbaar, behalve de drie weken voor een major release^[7]. Toegang vraagt een acceptatiecertificaat, de connector, een uitgeteste computer/browser en meestal een medisch testprofiel^[7].
• Trust store en sleutelvernieuwing: vertrouwde certificaten worden verspreid als ETSI Trusted List^[1]; in juli-augustus 2026 vernieuwde het platform de certificaten en sleutels van zijn eigen I.AM-diensten (SAML-integraties, JWT-validatie van I.AM Connect)^[13].
• Registratie: softwareregistratie gebeurt onder verantwoordelijkheid van het eHealth-platform samen met beheerders zoals het RIZIV^[9][14]. De manier van inschrijven verschilt volgens de RIZIV-registratievoorwaarden per project^[14]. De testmodaliteit hangt af van de integratievorm: geen test voor een webapplicatie zonder integratie, een demonstratievideo voor webcomponenten, een live testsessie voor een FHIR-API^[9]. Een geregistreerd pakket moet de geteste versie binnen drie maanden na het geslaagde minilab bij alle gebruikers installeren^[15].

eHealthBox

Voor de webservice moet de software de dienst geïntegreerd hebben; volgens het eHealth-platform is dat zo voor alle door eHealth geregistreerde pakketten^[16]. Integratie vereist een eHealth-certificaat en een versleutelingsdienst^[16]. SOAP volstaat met een basiscertificaat; de REST-variant vraagt een I.AM Connect-onboarding (Healthcare of M2M)^[3]. Berichten zijn beperkt tot 10 MB^[16].

MyCareNet

De leverancier schrijft zich in bij de MyCareNet-diensten (NIC) en krijgt toegang tot de technische documentatie op SharePoint^[10]. Daarnaast vraagt hij bij het eHealth-platform een testcertificaat voor de sector^[10]. Het NIC levert een implementation guide, voorbeeldberichten en referentie-implementaties in .Net en Java^[25]. Pas na een geslaagd Approval Assessment mag het pakket in productie^[10].

Hubs-metahub, toestemming en therapeutische relatie

De Metahub-webservice (aanmaak en opzoeking van patiëntlinks) is exclusief voor hubs, niet voor individuele softwarepakketten van ziekenhuizen^[11]. De diensten voor toestemming, therapeutische relaties/zorgrelaties en uitsluitingen zijn wel als REST-diensten beschikbaar voor toepassingen van derden^[11]. Zie Hubs-metahubsysteem, Geïnformeerde toestemming voor gegevensdeling en Therapeutische relatie.

Vitalink

Vitalink heeft geen eigen interface voor zorgverleners; zij gebruiken het via hun professionele software, die een toegangsprocedure doorloopt^[19]. Er zijn twee documentatiesporen, KMEHR en FHIR^[19] (zie ook Belgische FHIR-implementatiegidsen); de FHIR-omgeving gebruikt REST en I.AM Connect^[20]. Vitalink brengt per kwartaal een major release uit, met tussentijdse minor releases^[19]. Zie Vitalink.

Recip-e en UHMEP (FHIR)

In de Recip-e FHIR-API gebruiken ziekenhuisapotheken (Ziekenhuisapotheker en het gedeeld medicatieschema) een eigen M2M-client en mogen ze de client van het ziekenhuis niet hergebruiken^[21]. Patiëntidentificatoren worden gepseudonimiseerd via de pseudodienst van het eHealth-platform^[21]. Voor de UHMEP FHIR-API is de IAM-token-exchange-flow een veiligheidsvoorwaarde^[21]. Voor het digitaal verwijsvoorschrift (eReferral) is een geslaagde pre-registratietest op de FHIR Test Server verplicht vóór de officiële registratietest^[22]. Het RIZIV vereist zo'n pre-registratietest enkel 'voor sommige digitale toepassingen'^[9]; dat dit ook voor de Recip-e FHIR-API geldt, is niet aangetoond (gap). Zie UHMEP en het digitaal verwijsvoorschrift (eReferral) en Recip-e (elektronisch voorschrift in de ambulante sector).

Pseudonimisering

Het eHealth-platform biedt pseudonimiseringsdiensten om persoonsgebonden gezondheidsgegevens om te zetten in gecodeerde of anonieme gegevens^[23]. Bij "Batch codage" treedt het platform op als trusted third party^[23]; "Blinded pseudo" past pseudoniemen per verwerkende partij aan zonder depseudonimisering^[23]. Een beraadslaging van het Informatieveiligheidscomité is verplicht^[23]. De pseudonimisering van registergegevens in de HD4DP-datastroom loopt via de TTP-dienst van eHealth^[26]. De open-sourcebibliotheek in de GitHub-organisatie smals-belgium (zie eHealth-connectoren (eHealth platform services connectors)) verblindt de identificator vóór de aanroep, zodat de dienst hem nooit ziet^[27][27].

Addressbook en CoBRHA

Het Addressbook ontsluit contactgegevens uit CoBRHA^[24], inclusief eHealthBox-ID's^[16]. Zie CoBRHA.

Bevindingen: de gemeenschappelijke basis is overal een eHealth-certificaat en I.AM^[1][2]. Voor mobiele projecten geeft het eHealth-platform voorrang aan REST^[5]. De recentere diensten in deze vergelijking (Vitalink FHIR, eHealthBox REST, UHMEP) gebruiken REST/OIDC^[20][3][21], terwijl SOAP met een basiscertificaat blijft bestaan^[3]; dat REST de algemene richting voor nieuwe diensten is, is een interpretatie. Test en erkenning zijn per dienst georganiseerd, door verschillende actoren^[10][9][8].

Aanbeveling (eigen): houd per toepassing een integratiematrix bij (doeldienst, SOAP/REST, certificaat, I.AM-client, connectorversie, erkenningsstatus, vervaldata) en vraag leveranciers expliciet naar hun migratiepad van SOAP naar REST/FHIR.

• Verplichting: elektronische facturatie via MyCareNet is voor ziekenhuizen verplicht^[28], dus ook de bijbehorende erkende integratie^[10]. Pseudonimisering vereist een IVC-beraadslaging^[23].
• Financieringsvoorwaarde: vergoedingsmechanismen steunen op de gegevens in het Software Register, maar registratie geeft niet automatisch recht op een vergoeding^[9]. Het eHealth-platform voerde een evaluatiesysteem voor softwarepakketten in waarop het RIZIV zich baseert om eventuele telematicapremies toe te kennen^[15]; dat is een financieringscontext, geen algemene technische toelatingsvoorwaarde (interpretatie).
• Goede praktijk: vertrouwde certificaten automatisch bijwerken via de ETSI Trusted List^[1].
• (Interpretatie) Een ziekenhuis bouwt zelden zelf; meestal integreert de EPD- of middlewareleverancier.
• Een zorginstelling gebruikt haar RIZIV-nummer in de client-ID van een M2M-client^[3].

• De acceptatieomgeving bevat normaal geen betrouwbare gegevens^[7].
• Een acceptatiecertificaat geeft geen toegang tot productie^[7].
• Een connectorconfiguratie die nog naar het oude STS-endpoint (Saml11TokenService, niet meer gebruikt sinds oktober 2023) verwijst, is een mogelijke oorzaak van de fout 'SOA-03005'^[12].
• Voor diensten van ziekenhuisnetwerken, gezondheidskluizen, ziekenfondsen of Recip-e bestaan testomgevingen bij het eHealth-platform of bij die actoren^[8]; één geslaagde test bij het eHealth-platform dekt dus niet alle doeldiensten (afleiding).

• Een publiek gepubliceerde presentatie van het eHealth-platform ('Réalisations 2025 – Perspectives 2026', 30/01/2026) noemt een verplichte overstap van SAML v1 naar v2 in 2026^[29], terwijl de webpagina 'Beveiliging van webservices' nog een SAML 1.1-token beschrijft^[4]; zie I.AM en I.AM Connect (Identity & Access Management) (en de open vraag over de STS-cookbook 1.2).
• Een dienstoverschrijdend overzicht met SOAP-uitfaseringsdata is niet gevonden (gap).
• Of UHMEP op termijn de Recip-e-integratie voor geneesmiddelen vervangt, is niet bevestigd^[30].