eHealthBox

De eHealthBox is een beveiligde elektronische brievenbus van het eHealth-platform voor zorgverleners en zorginstellingen, bedoeld voor de uitwisseling van vertrouwelijke en medische gegevens tussen Belgische zorgactoren^[1]. Het Welcome Pack van het platform rekent ze tot de basisdiensten (lijst op p. 3)^[10] en is ontwikkeld voor zorginstellingen en voor zorgverleners met een RIZIV-nummer^[1].

In de architectuurbeschrijving van het eHealth-platform is de eHealthBox de use case voor versleutelde, asynchrone communicatie naar een gekende bestemmeling^[2]. Ze is daarmee een geadresseerd kanaal, naast het delen via de hubs en kluizen (Hubs-metahubsysteem), waar de raadpleger zelf de documenten opzoekt (interpretatie). Volgens Domus Medica sturen ziekenhuizen of specialisten sommige verslagen of verwijsbrieven via de eHealthBox naar het elektronisch medisch dossier van de huisarts, waar ze eenvoudig terug te vinden zijn in de documentenlijst van de patiënt^[11]. Domus Medica beveelt als goede praktijk aan belangrijke resultaten via de eHealthBox te versturen, omdat specifieke documenten via de hubconnectie moeilijk terug te vinden zijn^[11]. Zie Use case: verslagen en resultaten delen via de hub.

Status: productie, beheerd door het eHealth-platform^[1]. Gebruik buiten de klassieke brief:

• Laboresultaten in FHIR (zie DIGIRELAB (digitalisering van laboresultaten) en Uitwisseling van laboresultaten): volgens de Belgische FHIR Lab-IG wordt een laboresultaat als payload van een eHealthBox-bericht verstuurd, met custom metadata HC-FunctionalType 'fhir-lab'^[12]. Een RIZIV-document van 24/01/2023 kondigde een centraal register aan om na te gaan wie zulke berichten kan ontvangen; midden 2023 was dat nog in functionele analyse^[13].
• Meldingsplicht infectieziekten: de elektronische labomelding (XML, XSD 2.0) gaat via de eHealthBox, met één melding per bericht en transporttype MELDINGINFECTIEZIEKTEN^[14]; een labo start pas na een gezamenlijke testfase met het Departement Zorg^[14].
• Registers (HD4DP): patiëntidentificatoren gaan via de eHealthBox-berichtenclient van het ziekenhuis naar de TTP-dienst van eHealth en komen gepseudonimiseerd bij healthdata.be aan^[15].
• MZG en Technische Cel (zie FOD Volksgezondheid): de Minimale Ziekenhuisgegevens (MZG) zelf worden via het Portahealth-portaal geregistreerd^[8]. De eHealthBox dient enkel voor de gegevens voor de Technische Cel^[16], die MZG koppelt aan facturatiegegevens van het RIZIV^[16]. Het KB van 1 juli 2013 verplicht algemene niet-psychiatrische ziekenhuizen om voor alle MZG-verblijven onder meer het MZG-verblijfsnummer en het INSZ van de rechthebbende aan de Technische Cel mee te delen^[17], binnen vijf maanden na het registratiejaar of tegelijk met de MZG^[17]. Het ziekenhuis versleutelt het bestand met de publieke sleutel van het eHealth-platform, dat het ontsleutelt, het INSZ codeert met een specifieke sleutel voor de Technische Cel en de bestanden doorgeeft^[17]. Praktisch gaat de versleutelde correspondentietabel via de eHealthBox in de productieomgeving, met FLOWTCT als verzender en TTP als bestemmeling^[7]; daarvoor is een eHealth-certificaat met applicatie-ID FLOWTCT nodig, aangevraagd met het RIZIV-nummer van de instelling^[7]. Het TXT-bestand bevat het INSZ en de versleutelde MZG-index van het verblijf^[18] en is beperkt tot 10 MB of 65.000 records per bestand^[18]. Na een geslaagde zending volgt een melding in de eHealthBox; zonder (positieve) melding is de zending mislukt^[7].
• Bevolkingsonderzoeken: toen resultaten van bevolkingsonderzoeken begin 2026 door een technische overstap bij Vitalink tijdelijk niet via CoZo/Vitalink beschikbaar waren, bleven zorgverleners ze volgens CoZo (bericht gewijzigd op 12/01/2026) via de eHealthBox ontvangen^[19]. Het CvKO stuurt huisartsen resultaten en jaarrapporten over niet-deelnemers via de eHealthBox; zie Bevolkingsonderzoek en preventie: digitale systemen en uitwisselingen^[20][21].
• Telemonitoring: Bijlage V van de nationale overeenkomst tussen verpleeginrichtingen en verzekeringsinstellingen (forfaits monitoring op afstand oncologie) bepaalt dat bij een noodzakelijke interventie de huisarts of thuisverpleegkundige binnen twee werkdagen via de eHealthBox of telefonisch wordt ingelicht^[22].
• Overlijden (eLys): wordt in het Vlaams Gewest een vaststelling van overlijden geregistreerd die gekoppeld is aan het RIZIV-nummer van een ziekenhuis, dan stuurt eLys automatisch een bericht naar de eHealthBox van die instelling; zie Elektronische overlijdensaangifte (eDeath)^[23].
• Leveranciersclaim: volgens HealthConnect worden ingevulde eForms verstuurd via de eHealthBox of geïntegreerd in het ziekenhuisdossier^[24].

• Twee toegangswegen: webservice (geïntegreerd in medische software) en webtoepassing (aanmelding met eID, itsme of TOTP)^[1]. Voor de webservice moet het softwarepakket de dienst geïntegreerd hebben; volgens het eHealth-platform is dat zo voor alle door eHealth geregistreerde pakketten^[1].
• SOAP en REST: naast de SOAP-webservices (eHealthBox v3) bestaat eHealthBox REST v1 (voorheen v4) om al dan niet versleutelde berichten met bijlagen en metagegevens te publiceren en te raadplegen; de cookbook is versie 1.2 van 24/03/2026^[1]. Beide varianten hebben een gekoppelde AddressBook-dienst^[25].
• Adressering: het Addressbook geeft voor zorgverleners en instellingen de eHealthBox-identificatie terug (box-ID en type INSZ/NIHII/CBE)^[1]; de gegevens komen uit CoBRHA^[26].
• Berichten: bijlagen zijn mogelijk; de servicepagina noemt een maximaal berichtvolume van 10 MB^[1], terwijl de REST-cookbook v1.2 30 MB per bericht, een standaardboxgrootte van 10 MB en maximaal 25 bijlagen noemt^[9] (zie Onzekerheden). CustomMeta-velden geven grotere organisaties zoals ziekenhuizen extra, optionele routeringsmogelijkheden^[1].
• Meerdere boxen: een zorgverlener kan tegelijk meerdere eHealthBoxen raadplegen, bijvoorbeeld zijn persoonlijke box en zijn box als zorgverlener binnen een ziekenhuis^[1].
• Versleuteling: de ETEE-dienst wordt gebruikt binnen eHealthBox en Recip-e; de ETK-webservice levert de publieke sleutel van de gekende bestemmeling^[27].
• Inhoudsformaat (interpretatie): de geciteerde toepassingen gebruiken verschillende inhoudsformaten, zoals een FHIR-laboresultaat als payload^[12] en XML-meldingen voor infectieziekten^[14]. Een bron die bevestigt dat de eHealthBox zelf geen inhoudsformaat oplegt, of die KMEHR-berichten via de eHealthBox beschrijft, is niet gevonden (gap).

SOAP v3 en REST v1 naast elkaar. Aanleiding voor de nieuwe versie (toen 'V4', nu REST v1) waren volgens het eHealth-platform een oud monolithisch systeem dat moeilijk te onderhouden was, beperkte uitbreidbaarheid, een database die het volume moeilijk bijhield en trage bijlagenverwerking^[3]. De V4-architectuur werkt met RESTful webservices via een authenticatieserver, waarbij elke oproep een OAuth-token vereist^[3]. Bij het ontwerp werd rekening gehouden met een potentiële groei van 80.000 naar 850.000 mailboxen^[28]. Bij de invoering stelde het platform dat de V3-functionaliteiten niet wijzigen en dat V3 parallel met V4 blijft bestaan, met ingebruikname gepland op 24/1/2021^[3]. Versie 1.0 van de REST-service (24/01/2021) bood dezelfde functionaliteiten als de SOAP-service eHealthBox 3.1^[9]; de huidige cookbook is versie 1.2 van 24/03/2026^[1]. Een aangekondigde uitfaseringsdatum voor SOAP is in het nieuwsarchief, de cookbooks en de richtlijnen niet gevonden; dat is een gap, geen bewijs dat er geen plannen zijn.

Backend. Volgens Smals werd de eHealthBox HC opgesplitst in microservices en worden zware bijlagen apart opgeslagen, zodat capaciteit gericht kan worden bijgeplaatst; de oplossing is operationeel in productie^[29].

REST-specifiek gedrag. De REST-service verwerkt publicaties asynchroon: een geslaagd antwoord garandeert enkel dat het bericht verwerkt zal worden, en bij een latere mislukking krijgt de verzender een gestructureerd eHealthBox-bericht terug^[9].

Strengere validatie (2023-2025).

• Sinds release 2023.2 (productie 15/10/2023) aanvaarden de SOAP-webservices van het eHealth-platform enkel nog SHA-256^[30].
• De REST-service werd technisch gemigreerd naar Spring Boot 3 en OpenAPI, met strikte controle van media-types^[31]; de tweede fase werd verschoven naar release 2025.1.1, met productie-uitrol tussen 17/06/2025 en 24/06/2025^[32].
• Vanaf release 2025.2 (productie 14-17/10/2025) weigeren de eHealthBox-diensten bijlagen met een ongeldig mimetype^[6].

Logdatabank. Het eHealth-platform bouwt een eHealthBox Tracing WebApp met een logdatabank met een bewaartermijn van 10 jaar, onder meer voor juridische doeleinden zoals discussies over Mult-eMediatt-berichten; productie was gepland in Q1 2026^[4]. Of die planning gehaald is, is niet gevonden (gap).

Het eHealth-platform publiceerde verplichte gebruiksrichtlijnen voor eHealthBox (SOAP en REST), versie 1.0 op 9/10/2025 en versie 1.1 op 11/02/2026, die vooral het toegelaten aantal oproepen per methode vastleggen^[5]. Ze sluiten aan op een eerdere rationalisatie met de softwareintegratoren in 2022, met voor 2023 minder automatische oproepen tijdens de daluren^[33].

• Oproeplimieten: per methode een maximum aantal oproepen, verschillend voor individuele professionals en organisaties; een organisatie mag GetMailbox bijvoorbeeld maximaal 60 keer per uur oproepen^[5].
• Ontvangstbewijzen: via de push-methode (aanvraag bij verzending); het beheer baseren op de pull-methode is verboden, en voor individuele professionals is die methode helemaal verboden^[5].
• Eén client: de richtlijnen raden af de box van een individuele zorgverlener via verschillende toepassingen te bevragen en bevelen aan alle functionaliteiten in één client te integreren^[5].
• Geen archief: de eHealthBox is geen gegevensopslag; berichten horen na het opvragen van de lijst en het succesvol downloaden onmiddellijk verwijderd te worden^[5].
• Quota: sinds 1/01/2022 is het standaardquotum 10 MB voor individuele personen (zoals artsen) en 100 MB voor instellingen, ziekenhuizen, labo's en medische huizen^[5]. Het quotum is een virtuele limiet: bij het bereiken ervan komen berichten wel toe, maar wordt de weergave van de berichtenlijst beperkt^[5]. Een verhoging gebeurt in principe per doelgroep na goedkeuring door de service manager; voor een individuele klant (zoals een arts of ziekenhuis) is ze steeds tijdelijk^[5].
• Automatische verwijdering: ongebruikte mailboxen (met berichten) na 90 dagen, ontvangen berichten (inbox en standby) na 182 dagen, berichten in de prullenmand na 30 dagen en verzonden berichten na 7 dagen^[5]. Aanleiding is onder meer dat veel boxen niet gebruikt worden, bijvoorbeeld omdat ze automatisch aangemaakt werden door een verzending^[5].

Een aparte statistiekpagina of jaarverslag met eHealthBox-cijfers is niet gevonden (gap); de cijfers hieronder komen uit de jaarlijkse presentaties van Frank Robben aan het personeel, die publiek op frankrobben.be staan. Peildatum is de datum van de presentatie.

Interpretatie: in 2025 ging ongeveer 0,8% van de verzonden berichten via REST^[4]. De daling van het aantal consultatie-oproepen in 2022 valt samen met de rationalisatie met de integratoren^[33]; een oorzakelijk verband wordt in de bron niet expliciet gelegd.

Kanttekening bij de cijfers. De cijfers verschillen tussen edities van de presentaties. Een presentatie van 23/04/2026 vermeldt naast de eHealthBox-cijfers voor 2025 12.301.272 berichten 'eHealthBox > eBox', het cijfer dat de presentatie van 31/01/2025 voor 2024 gaf^[34]; de presentatie van 30/01/2026 geeft voor 2025 15.050.514^[4]. Oudere edities (26/01/2024, 31/01/2025) gaven voor 2020-2023 andere totalen voor 'verzonden berichten', vermoedelijk omdat ze een andere methode telden; die cijfers zijn nog niet tekstueel geverifieerd en staan daarom niet in de tabel (zie de pagina Tegenstrijdigheden). Cijfers per sector, zoals voor ziekenhuizen, zijn niet gevonden (gap).

• Financieringsvoorwaarde (historisch): kernfunctionaliteit 15 van de BMUC 2016 vereiste onder meer het gebruik van de eHealthBox^[35]; zie BMUC: financiering van het geïntegreerd EPD.
• Technische voorwaarde: integratie van de webservice vereist een eHealth-certificaat en de integratie van een versleutelingsdienst^[1]; zie eHealth-certificaten en versleuteling (ETEE).
• Routering: CustomMeta-velden bieden grotere organisaties zoals ziekenhuizen optionele routeringsmogelijkheden^[1].
• Aanbeveling (eigen): gebruik die CustomMeta-velden om binnenkomende berichten intern naar de juiste dienst te routeren.
• Aanbeveling (eigen): documenteer per berichtstroom (verslagen naar huisartsen, infectieziektemeldingen, HD4DP) welke box (instellings- of persoonsbox) en welke metadata gebruikt worden, en bewaak de berichtgrootte (10 of 30 MB, zie Onzekerheden) bij beeld- of PDF-bijlagen.
• Aanbeveling (eigen): toets de eigen client (en die van leveranciers) aan de gebruiksrichtlijnen v1.1: pollingfrequentie, push-ontvangstbewijzen, onmiddellijk verwijderen na download en tijdige verwerking vóór de automatische verwijdering.

Voor SOAP-integraties volstaat een basiscertificaat (eHealth-certificaat), zonder de I.AM Connect-onboarding die voor REST vereist is^[25]. Voor de REST-varianten van eHealthBox en Addressbook is een aparte onboarding via I.AM Connect nodig, met een keuze tussen 'Healthcare' (zorgverlener of applicatie) en 'M2M' (organisatie)^[25]. Een zorginstelling gebruikt voor een M2M-client-ID het formaat nihdi-<type>-XXXXXXXX met haar RIZIV-nummer^[25]. In het Software Register heeft bijvoorbeeld CareConnect GP een certificering 'Minilab eHBox'^[36]; of alle huisartsensoftware zo'n minilab doorloopt, is niet uit die bron af te leiden. Zie ook Technische integratie met de eHealth-infrastructuur en eHealth-connectoren (eHealth platform services connectors).

• Berichtgrootte (tegenstrijdig): de servicepagina noemt maximaal 10 MB per bericht^[1]; de REST-cookbook v1.2 (24/03/2026) noemt 30 MB per bericht en 10 MB standaard per box^[9]. De richtlijnen v1.1 geven als quotum 10 MB voor personen en 100 MB voor instellingen^[5]. Of de 30 MB ook voor SOAP geldt, is niet gevonden.
• Volle box (tegenstrijdig): volgens de richtlijnen komen berichten wel toe en wordt enkel de lijstweergave beperkt^[5]; volgens de REST-cookbook komen volgende berichten in een standby-wachtrij^[9].
• Gebruikscijfers: de totalen verschillen tussen edities van de jaarpresentaties (zie Gebruikscijfers en de pagina Tegenstrijdigheden)^[34].
• Of het in 2023 aangekondigde ontvangersregister voor FHIR-labresultaten operationeel is, is niet gevonden^[13].
• De rechtsgrond van de eHealthBox als dienst is niet in een citeerbare bron gevonden (gap, geen bewijs van afwezigheid); de bewaartermijnen van berichten zijn nu wel in de richtlijnen vastgelegd^[5].