Pseudonimiseringsdiensten van het eHealth-platform

Het eHealth-platform stelt partners diensten ter beschikking die persoonsgegevens over de gezondheid omzetten naar gecodeerde of anonieme gegevens, waaruit de identiteit van de patiënt of de zorgverlener niet rechtstreeks of onrechtstreeks af te leiden is^[1][2]. Het Welcome Pack rekent 'pseudonimisering & anonimisering' tot de basisdiensten (zie Basisdiensten van het eHealth-platform)^[3].

De familie omvat:

• Seals (SOAP): de webservice Seals (vroeger Codage v2) is de opvolger van Codage v1 en codeert en decodeert gegevens in een medische context (cookbook v2.2 van 06/07/2022)^[4]. Volgens de productiecatalogus codeert en decodeert Seals willekeurige strings, waarbij de sleutel bij eHealth en de versleutelde gegevens bij de oproeper blijven^[5].
• Batch codage: het eHealth-platform treedt op als trusted third party (TTP) voor het coderen en decoderen van gezondheidsgegevens voor rekening van een partner^[2].
• Anonimisering: onomkeerbaar, met tussenkomst van een TTP^[2].
• Blinded pseudo (REST, 'Pseudonymisation'): de productiecatalogus vermeldt de Pseudonymisation REST-dienst om een identificator te pseudonimiseren, te identificeren of te converteren^[5]. Blinded pseudo is strikt genomen geen basisdienst maar een afgeleide dienst die aan dezelfde kwaliteits- en veiligheidsstandaarden voldoet als de basisdiensten uit de eHealth-wet^[1].

De diensten maken het mogelijk gezondheidsgegevens te verwerken of te delen zonder dat de ontvanger de identiteit van de patiënt kent^[1]. Blinded pseudo past pseudoniemen aan per verwerkende partij zonder de gegevens te depseudonimiseren^[2]: de dienst genereert per businessdomein een verschillend pseudoniem^[6] en ondersteunt de omzetting van een geblindeerd pseudoniem naar een doeldomein^[6]. De domeineigenaar ziet enkel het pseudoniem voor zijn domein en niet de identiteit van de patiënt^[6].

Status: productie. Het eHealth-platform levert de diensten^[1]. Toepassingen in de verwerkte bronnen:

• UHMEP: sinds release R20251 (15/04/2025) pseudonimiseert UHMEP naast het INSZ ook de tekstinformatie van en voor de patiënt in een medisch voorschrift via de Pseudo REST-dienst^[7]. Voor de status van UHMEP (test- en pilotfasen), zie UHMEP en het digitaal verwijsvoorschrift (eReferral).
• Recip-e: de FHIR-cookbook beschrijft het gebruik van de pseudonimiseringsdienst om gegevens te pseudonimiseren, converteren en identificeren^[8].
• Vitalink: in de Vitalink FHIR-omgeving worden persoonsgegevens gepseudonimiseerd via de pseudonimisatieservice van het eHealth-platform^[9]. Voor Vitalink 2.0 beschrijft de minister een model waarin het rijksregisternummer door een pseudoniem vervangen wordt en de gezondheidsgegevens leesbaar blijven^[10].
• RR Consult: voor PseudoPersonService moet het INSZ- of BIS-nummer vooraf via de pseudonimiseringsdienst gepseudonimiseerd zijn^[11].
• Epidemiologische laboratoriumrapportering: volgens de stroombeschrijving in een beraadslaging wordt de patiëntidentificatie (INSZ) via het eHealth-platform gepseudonimiseerd ('codage eHBox') voordat de gegevens in het datawarehouse van healthdata.be terechtkomen^[12] (zie HD4DP v2 (healthdata.be)). Hypothese: het gaat om een dienst van deze familie; welke, staat niet in de bron.

Ook de Data Attribute Service (DAAS) is pseudo-compatibel gemaakt^[11] (zie Basisdiensten van het eHealth-platform).

• Pseudonymisation REST: om de dienst aan te roepen is een I.AM Connect-client nodig die een access token (JWT) verkrijgt^[6].
• Verblinding aan de kant van de client: volgens de documentatie van een aparte open-sourcehelperbibliotheek van Smals wisselt de pseudonimiseringsdienst enkel elliptic-curve-punten uit; de client zet een patiëntidentificatienummer (SSIN) om in zo'n punt en verblindt het vóór de aanroep, zodat de dienst zelf geen patiëntidentificator ziet^[13][13].
• Seals: de sleutel blijft bij eHealth, de versleutelde gegevens bij de oproeper^[5].

API's in de catalogus van het eHealth-platform

Stand van de catalogus op 28/09/2026 (register van de Atlas). De productiecatalogus beschrijft beide diensten^[5][5].

• Seals (vroeger Codage v2) volgt Codage v1 op^[4]; een uitfaseringsdatum voor Codage v1 is niet gevonden.
• Release R20251 (15/04/2025): uitbreiding van het gebruik door UHMEP naar tekstinformatie in voorschriften^[7].
• Een roadmap voor de diensten zelf is niet gevonden.

• Verplichting: voor de pseudonimiseringsdiensten (WS Seals, Batch codage, Blinded pseudo) en anonimisering is een akkoord van het Informatieveiligheidscomité verplicht^[1][3][3].
• Indirect gebruik: UHMEP, Recip-e FHIR en de Vitalink FHIR-omgeving steunen op pseudoniemen^[7][8][9]. Interpretatie: ziekenhuissoftware komt dus ook via die diensten met pseudonimisering in aanraking.
• Aanbeveling (eigen): ga bij elk nieuw project voor registratie of secundair gebruik na of de ontvanger een gepseudonimiseerd INSZ verwacht, welke dienst (Seals of Blinded pseudo) daarvoor voorzien is en of er een IVC-beraadslaging bestaat.

Na een akkoord van het IVC zijn voor de pseudonimiseringsdiensten een eHealth-certificaat en de implementatie van een versleutelingsdienst nodig^[1]. Voor de REST-dienst is daarnaast een I.AM Connect-client vereist^[6].

• Basisdienst of afgeleide dienst: het Welcome Pack noemt pseudonimisering een basisdienst^[3], terwijl Blinded pseudo volgens dezelfde bronfamilie strikt genomen een afgeleide dienst is^[1]. Interpretatie: geen echte tegenspraak; Blinded pseudo is een afgeleide dienst die dezelfde standaarden volgt als de basisdiensten.
• Naamgeving: 'Seals', 'Codage v2', 'Pseudo REST', 'Pseudonymisation' en 'Blinded pseudo' worden door elkaar gebruikt; in de catalogus heten de API's 'Seals' en 'Pseudonymisation'.
• Codage v1: status niet gevonden (hiaat).