Basisdiensten van het eHealth-platform

Welke gemeenschappelijke diensten stelt het eHealth-platform ter beschikking van softwarepakketten in de zorg, en hoe evolueren ze van SOAP naar REST? Het eHealth-platform biedt die diensten gratis aan voor integratie in de software van zorgactoren^[1]. Deze pagina geeft het overzicht en beschrijft de diensten zonder eigen pagina: de basisdienst Timestamping en de verwante technische diensten Id Support, Directory en DAAS, die niet op de lijst van het Welcome Pack staan. Voor wat een softwarepakket per dienst nodig heeft om te koppelen, zie Technische integratie met de eHealth-infrastructuur; voor het volledige overzicht van de API-catalogus, per functie gegroepeerd, zie Diensten en API's van het eHealth-platform.

Overzicht van de basisdiensten en verwante diensten. Het Welcome Pack (versie 08/09/2026) somt in zijn inhoudstafel tien basisdiensten op: coördinatie van elektronische deelprocessen, portal, RR Consult, eHealth-certificaten, I.AM, het verwijzingsrepertorium (Metahub), timestamping, end-to-endversleuteling, eHealthBox en pseudonimisering en anonimisering^[2]. De SLA van CoBRHA noemt CoBRHA een 'Base Service'^[10]. De kolom 'Officieel' geeft aan of een dienst op de lijst van het Welcome Pack staat; 'nee' betekent enkel dat hij daar niet op staat.

De kolom 'interfaces' volgt het API-register van de Atlas (stand van de catalogus op 28/09/2026); waar een claim bestaat, staat die in de kolom 'functie'. De kolom 'Officieel' volgt de lijst van het Welcome Pack^[2]. Of de dienstpagina 'Basisdiensten' een afwijkende lijst geeft, is nog niet verwerkt (zie de open vragen).

Timestamping

Timestamping van het eHealth-platform bewaart een bewijs van het bestaan en de inhoud van een document op een bepaalde datum^[3]. De dienst bestaat uit de webservice TimeStampAuthority (certificering en facultatieve archivering) en de webservice TimeStampConsult (raadpleging en controle van gedateerde documenten)^[3].

Timestamping wordt vooral gebruikt voor het elektronisch voorschrift in ziekenhuizen, en daarnaast voor het ambulant elektronisch voorschrift (Recip-e), MyCareNet en RCT^[3][2]. Voor ziekenhuisvoorschriften worden de hashcodes elke 5 minuten gebundeld in een pakket, de 'TimeStampBag'^[3]. Het eHealth-platform bewijst zo het tijdstip van aanmaak zonder kennis van de inhoud, omdat die gehasht is^[3]. Het gebruik van timestamping voor ziekenhuisvoorschriften is wettelijk geregeld (verordening van 5 december 2016 betreffende het elektronisch voorschrift binnen het ziekenhuis)^[3]. Het platform levert de TimeStamping Client als referentie-implementatie; een ziekenhuis mag ook een eigen oplossing of die van een softwareleverancier gebruiken als die aan dezelfde specificaties voldoet^[3].

Volgens de release notes van R2024.1.2 (gedateerd 23/07/2024) zou het endpoint /TimestampAuthority/v1 in die release uit dienst gaan en moesten gebruikers naar /TimestampAuthority/v2 migreren^[22]. De release notes zijn vooraf opgesteld ('will be undeploy'); een aparte bevestiging van de uitvoering is niet gevonden.

Id Support (verwante dienst)

Id Support staat niet op de lijst van basisdiensten in het Welcome Pack^[2]. Via eHealth Id Support kan een zorgverlener de geldigheid van het identiteitsbewijs van een patiënt controleren bij de betrokken authentieke bron^[4]. Het eHealth-platform is geen authentieke bron voor identiteitsgegevens: Id Support is een relaisdienst naar de dienst van de Kruispuntbank van de Sociale Zekerheid^[23]. De dienst bestaat enkel als webservice voor integratie in zorgverlenerssoftware en vereist een token van de STS-dienst van het eHealth-platform^[4][4]. Id Support is op dit ogenblik alleen beschikbaar voor individuele zorgverleners die erkend zijn in het KB nr. 78^[4]. Volgens beraadslaging nr. 07/2014 van het Sectoraal Comité van het Rijksregister mogen zorgverleners en zorginstellingen Id Support via het eHealth-platform gebruiken^[4].

Directory en DAAS (verwante diensten)

De Directory en DAAS staan evenmin op de lijst van basisdiensten in het Welcome Pack^[2]. De Directory is een register van actoren die gedurende een periode aan elkaar gekoppeld zijn, raadpleegbaar via de DAta Attribute Service (DAAS); via de Directory WS voegen bevoorrechte partners er gegevens aan toe^[5]. DAAS is een generieke dienst van het eHealth-platform om de bestemmeling(en) van een bericht in de gezondheidssector te identificeren, bijvoorbeeld een preventiedienst, een controlearts of een werkgever^[6]. DAAS volgt het voorbeeld van de Attribute Authority (AA) van I.AM en raadpleegt de authentieke bronnen of de residuaire routeringsgids; het resultaat gaat naar de softwareprovider van de zorgverlener^[6]. DAAS wordt onder meer gebruikt in Mult-eMediatt, het project voor de informatisering van de arbeidsongeschiktheidsattesten, en in het TRIO-platform^[6]. DAAS is ook pseudo-compatibel gemaakt^[24] (zie Pseudonimiseringsdiensten van het eHealth-platform). In release R20252.1 werd de Directory voor Mult-eMediatt aangepast om de gegevensset van het attest per type bestemmeling fijner te maken^[25].

API's in de catalogus van het eHealth-platform

Stand van de catalogus op 28/09/2026 (register van de Atlas). De API's van de andere basisdiensten staan op hun eigen pagina's.

Beleid. Volgens de dienstpagina 'Architecturen' (zonder publicatiedatum) blijft het eHealth-platform de SOAP-architectuur onderhouden en ondersteunen, maar raadt het ze af voor projecten voor mobiele apparaten en geeft het daar prioriteit aan REST^[7]. Het platform omschrijft SOAP als architectuur voor toepassingen op één toestel en REST voor toepassingen op meerdere toestellen; voor nieuwe mobiele projecten krijgt REST de voorkeur^[7]. De voorrang voor REST is in die bron dus beperkt tot mobiele projecten; een algemeen beleid dat REST boven SOAP verkiest, is in de verwerkte bronnen niet gevonden (hiaat). Of de pagina het huidige beleid weergeeft, is niet vastgesteld.

Geen algemene kalender. Een dienstoverschrijdend beleid of een kalender om SOAP-diensten uit te faseren is in de verwerkte bronnen niet gevonden (hiaat). De release notes verschijnen op de dag dat een release in acceptatie komt en vermelden onder meer diensten die het einde van hun levenscyclus bereiken^[8][8]. Voorbeelden van zulke aankondigingen:

• Timestamping: de release notes van R2024.1.2 (23/07/2024) kondigden de uitdienstname van /TimestampAuthority/v1 aan, met migratie naar v2^[22].
• Implantatenregister (geen basisdienst): de release notes van R20262 kondigen de uitdienstname van Sadmi v2 aan, met overstap naar /Sadmi/v3 of /Sadmi/v4^[9]; die major release is gepland van 13 tot 20 oktober 2026^[9].

Niet elke wijziging staat in release notes: de functionele bevriezing van Addressbook SOAP staat in de REST-cookbook v1.3^[26].

Stand per dienst (voorbeelden):

• Addressbook: SOAP en REST gebruiken dezelfde backend, maar enkel REST krijgt nog functionele verbeteringen; SOAP blijft voor compatibiliteit^[26].
• Toestemming: er bestaan drie versies van de consent-dienst^[17]; het beheer van de opt-out wordt enkel door Patient Data Access Consent WS REST ondersteund en het platform raadt REST-gebruikers aan naar die dienst te migreren^[17].
• Therapeutische relatie: in het kader van release R20252.1 kondigde het platform een volledige technische herschrijving (refactoring) van de Therapeutic Link-diensten aan, zowel SOAP als REST^[18]; dat die in productie ging, is niet apart bevestigd. Interpretatie: SOAP wordt dus nog onderhouden.
• Toegangsmatrix: de WS Matrix (PADAC) is een REST-dienst^[20].
• ETEE: ETKDepot en KGSS bestaan in SOAP en REST, KeyDepot enkel in REST^[14].
• eHealthBox: SOAP en REST bestaan naast elkaar^[27] (in de catalogus van 28/09/2026: SOAP v3.0 en REST v1.2). In 2025 liep het overgrote deel van het verkeer via SOAP (112.876.714 berichten) tegenover 917.260 via REST^[28]; in 2022 waren dat 171.044.364 berichten via SOAP en 13.005 via REST^[28]. REST groeit dus, maar blijft een klein aandeel.
• Kleinere diensten: Timestamping, Id Support, Directory en DAAS staan in de catalogus enkel als SOAP (zie de tabel hierboven).

Bevindingen: de basisdiensten zijn gratis en bedoeld voor integratie in de software van zorgactoren^[1]. Volgens een ongedateerde architectuurpagina blijft SOAP onderhouden en ondersteund, en krijgt REST prioriteit voor projecten voor mobiele apparaten^[7]; een algemene voorrang voor REST is niet gevonden. Bij sommige diensten evolueert enkel REST nog^[26] of zit nieuwe functionaliteit enkel in een REST-variant^[17], terwijl voor andere diensten nog een herschrijving in SOAP en REST werd aangekondigd^[18]. Interpretatie: 'SOAP uitgefaseerd' is voor de basisdiensten als geheel geen juiste samenvatting; de migratie verloopt dienst per dienst.

Aanbeveling (eigen): houd per koppeling bij welke dienst, interface en versie gebruikt wordt, volg de release notes van het eHealth-platform op aankondigingen van uitdienstname, en kies bij nieuwe integraties de REST-variant waar die bestaat.

• Wettelijk kader (timestamping): het gebruik van timestamping voor ziekenhuisvoorschriften is wettelijk geregeld^[3]; ziekenhuizen mogen daarvoor de referentie-implementatie of een conforme eigen of leveranciersoplossing gebruiken^[3].
• Versiebeheer: aangekondigde uitdienstnames zoals die van TSA v1^[22] vragen tijdige migraties in de ziekenhuissoftware; de release notes zijn daarvoor de eerste bron^[8][8].
• Id Support: de dienst is op dit ogenblik enkel beschikbaar voor individuele zorgverleners^[4], al vermeldt de beraadslaging ook zorginstellingen^[4].
• Routering: DAAS en de Directory bepalen de bestemmelingen van arbeidsongeschiktheidsattesten via Mult-eMediatt^[6][25].

Id Support vereist een token van de STS-dienst van het eHealth-platform^[4][4]. Het gebruik van DAAS vereist, afhankelijk van het project, goedkeuring door het Beheerscomité van het eHealth-platform en door het Informatieveiligheidscomité^[6]. De voorwaarden van de andere basisdiensten staan op hun eigen pagina's en op Technische integratie met de eHealth-infrastructuur.

• Addressbook SOAP: de REST-cookbook v1.3 (24/03/2026) stelt dat enkel REST nog functionele verbeteringen krijgt^[26], terwijl de release notes van R20252.1 (09/12/2025) nog nieuwe zoekopties voor zowel SOAP als REST aankondigden^[25]. Interpretatie: mogelijk gold de bevriezing pas na R20252.1.
• Id Support, ondersteunde kaarten: de dienstpagina noemt vier identiteitsbewijzen (eID, Kids-ID, Foreign ID, ISI+)^[4], de cookbook v1.5 (19/07/2022) zes: eID, KidsID, ForeignID, biometrische verblijfsvergunning, SIS- en ISI+-kaart^[23]. Welke lijst actueel is, is niet vastgesteld.
• Timestamping v1: de TSA V2-cookbook van 11/06/2024 stelde dat de eerste versie van TSA nog door veel partners gebruikt werd^[29], terwijl de release notes van R2024.1.2 (23/07/2024) de uitdienstname van endpoint v1 aankondigden^[22]. Of de uitdienstname op die datum zo gebeurde, is niet vastgesteld (zie de open vragen).
• Release van de TherLink-refactoring: het bericht over de herschrijving noemt in het Frans 'R20252.1' en in het Nederlands 'R2023.1.2' als release van 2/12/2025, terwijl de release notes R20252.1 die minor release op 09/12/2025 dateren^[18].
• Reikwijdte van de REST-voorrang: de architectuurpagina beperkt de voorrang voor REST tot projecten voor mobiele apparaten en heeft geen datum^[7]; bredere uitspraken ('REST krijgt voorrang') volgen niet uit deze bron.
• Algemene uitfaseringskalender: niet gevonden; 'niet gevonden' betekent niet dat ze niet bestaat.