Waarom je geen medische data in de cloud moet gooien (en wat dan wel)

We hangen sensoren aan ouderen, sturen data naar de cloud, en hopen dat het goed gaat. Dat is geen architectuur, dat is wensdenken. En de Autoriteit Persoonsgegevens kijkt mee.

Laatst bij een zorginstelling in de regio Utrecht zag ik het van dichtbij. Een projectleider toonde trots hun nieuwe ‘slimme zorgvloer’, bewegingssensoren, valdetectie, hartslag via een polsband. Alles realtime naar een dashboard in Azure. Mijn eerste vraag: “Welke data gaat er precies naar de cloud, en in welke vorm?” Stilte. “Nou, gewoon… de meetwaarden.” Geen pseudonimisering, geen edge-filtering, geen DPIA. De leverancier had ‘AVG-compliant’ op de offerte gezet, en daarmee was de kous af.

Wat hier interessant is: een paper dat deze week op arXiv verscheen, laat zien dat het wél kan. Een volledige privacy-by-design security-architectuur voor IoMT-gebaseerde ouderenzorg, specifiek gericht op GDPR-compliance. Geen theoretisch raamwerk, maar een concrete blauwdruk met edge-layer pseudonymisatie en een DPIA-aanpak die naadloos aansluit op NEN 7510. [1]

Het probleem is niet de sensor, maar de datastroom

Remote elderly care systemen verzamelen continu hoog-risico data: hartritme, slaappatronen, locatie, valincidenten. Onder de AVG valt dat onder bijzondere persoonsgegevens (art. 9), verwerking verboden, tenzij je een uitzondering hebt én passende maatregelen neemt. In Nederland voegt NEN 7510 daar nog een schepje bovenop: informatiebeveiliging in de zorg moet aantoonbaar op orde zijn, met een risicogebaseerde aanpak.

De meeste implementaties die ik zie, sturen ruwe sensordata direct naar een cloudplatform. Daar draait dan een algoritme dat ‘anomalieën’ detecteert. Juridisch is dat vragen om problemen. Je verwerkt medische data op een plek waar je geen end-to-end controle hebt, vaak bij een Amerikaanse hyperscaler. Zelfs met een verwerkersovereenkomst blijf je als zorginstelling verwerkingsverantwoordelijke. En de AP heeft in 2025 nog boetes uitgedeeld voor onvoldoende dataminimalisatie bij zorg-iot. [2]

De kernvraag is dus: hoe scheid je de medische data van de functionele data, zo vroeg mogelijk in de keten?

Edge-layer pseudonimisatie als juridische firewall

Het paper stelt een architectuur voor die de datastroom in drie lagen opknipt: edge, fog, cloud. De truc zit in de edge-laag, een gateway in de woning van de oudere die ruwe sensordata direct pseudonimiseert voordat die het lokale netwerk verlaat.

Concreet: de gateway draait een light-weight pseudonimisatiemodule die persoonsidentificerende velden (device ID, timestamp, locatie) vervangt door een salted hash. De medische payload (hartslag, valdetectie) wordt versleuteld met een sleutel die alleen de zorgverlener bezit. De cloud ziet alleen gehashte identifiers en encrypted blobs. De fog-laag (een server in het zorgcentrum) kan met de sleutel de data ontsleutelen voor realtime alerts, maar slaat niets op. De cloud doet trendanalyse op de gepseudonimiseerde data, wat voor GDPR geen persoonsgegevens meer zijn, mits de sleutel strikt gescheiden blijft.

Dit is geen rocket science. Een minimale implementatie op een Raspberry Pi 4 edge gateway ziet er ongeveer zo uit:

import hashlib
import os
from cryptography.fernet import Fernet

# Salt uit hardware security module of TPM
salt = os.environ['DEVICE_SALT']
key = os.environ['FOG_PUBKEY']  # publieke sleutel van fog-laag

def pseudonymize(device_id, timestamp):
    return hashlib.sha256(f"{device_id}{timestamp}{salt}".encode()).hexdigest()

def encrypt_payload(payload, key):
    f = Fernet(key)
    return f.encrypt(payload.encode())

# Voor elke meting
pseudo_id = pseudonymize(device_id, timestamp)
encrypted_data = encrypt_payload(raw_measurement, key)
send_to_cloud(pseudo_id, encrypted_data)

De cloud ontvangt een SHA-256 hash en een versleutelde blob. Zonder salt en zonder decryptiesleutel is dat voor de cloudprovider onomkeerbaar. De zorgverlener kan via de fog-laag wél bij de ruwe data, maar alleen voor het specifieke doel: acute alarmering. Voor analysedoeleinden gebruikt men de gepseudonimiseerde dataset. Dat is dataminimalisatie in de praktijk.

DPIA die aansluit op NEN 7510

Het tweede sterke punt van het paper is het DPIA-raamwerk. Het is opgebouwd rond dezelfde risicocategorieën die NEN 7510-2 hanteert: beschikbaarheid, integriteit, vertrouwelijkheid, maar voegt daar expliciet ‘onkoppelbaarheid’ aan toe, een privacyprincipe uit de NORA dat in zorgarchitecturen vaak onderbelicht blijft.

De DPIA-methodiek in het paper volgt een stappenplan dat direct mapt op de Nederlandse praktijk:

1. Data flow mapping, welke data stroomt waar, in welke vorm, onder wiens verantwoordelijkheid. Dit is feitelijk een verplicht onderdeel van elke DPIA onder de AVG, maar het paper concretiseert het voor IoMT met voorbeeld-dataflowdiagrammen.
2. Bedreigingsanalyse per laag, edge, fog, cloud. Per laag worden de NEN 7510-bedreigingscategorieën gescoord op likelihood en impact. Bijvoorbeeld: ‘onderschepping van ruwe data op de edge’ scoort hoog op vertrouwelijkheid, maar door de pseudonimisatie is de impact laag.
3. Maatregelenselectie, koppelt elke bedreiging aan een set maatregelen uit NEN 7510 annex A, met concrete implementatievereisten. Geen vage ‘encryptie toepassen’, maar ‘AES-256-GCM voor data in transit, met sleutelrotatie elke 90 dagen’.
4. Restrisico-acceptatie, expliciet vastleggen welk restrisico de organisatie accepteert, met onderbouwing. Dit is cruciaal voor verantwoording richting AP en functionaris gegevensbescherming.

Wat me opviel: het paper benadrukt dat een DPIA geen eenmalig document is, maar een levend artefact dat mee-evolueert met de architectuur. Bij elke wijziging in de sensordata, cloudprovider, of verwerkingsdoeleinden moet je de DPIA herzien. In de praktijk zie ik dat bijna nergens gebeuren. De DPIA wordt ingevuld voor de eerste livegang en verdwijnt daarna in een Sharepoint-map.

BIO2 en NIS2: de stok achter de deur

Voor Nederlandse zorginstellingen is er nog een extra laag: de BIO2 (Baseline Informatiebeveiliging Overheid) wordt de komende jaren van kracht voor alle organisaties die onder de overheid vallen, inclusief zorginstellingen met een publieke taak. BIO2 eist een systematische risicomanagementaanpak en security-by-design voor alle informatiesystemen. Een IoMT-architectuur zonder edge-pseudonimisatie ga je onder BIO2 niet kunnen verantwoorden.

Daarnaast brengt NIS2 (vanaf 2026 van kracht) zorginstellingen met meer dan 50 medewerkers of een omzet boven €10 miljoen onder de reikwijdte van essentiële entiteiten. Dat betekent: verplichte incidentmelding bij NCSC, supply chain security, en aansprakelijkheid van het management. De architectuur uit het paper adresseert precies die supply chain-risico’s: door data bij de bron te pseudonimiseren, beperk je de impact van een cloudbreach tot vrijwel nul.

Wat je morgen al kunt doen

Je hoeft niet te wachten op een volledige architectuur-revisie. Drie concrete stappen die je direct kunt zetten:

1. Check je huidige datastromen. Pak een whiteboard en teken welke sensordata waar naartoe gaat, in welke vorm. Waar zit de eerste mogelijkheid om te pseudonimiseren? Als dat pas in de cloud is, heb je een probleem.
2. Draai een DPIA-gap analyse. Gebruik het DPIA-template van de Autoriteit Persoonsgegevens en leg het naast je huidige IoMT-architectuur. Waar scoor je onvoldoende op dataminimalisatie? [3]
3. Test edge-pseudonimisatie op één sensor. Pak een Raspberry Pi, installeer een simpele Python-script zoals hierboven, en kijk of je de datastroom kunt omleiden. De techniek is het probleem niet; de organisatorische wil is dat vaak wel.

De paper op arXiv biedt een compleet referentiekader, inclusief een open-source referentie-implementatie van de edge-gateway. De link staat in de voetnoot. [1]

De verschuiving is helder: we kunnen niet langer medische data behandelen als gewone telemetrie. De AVG, NEN 7510, BIO2 en NIS2 dwingen een architectuur af waarin privacy geen sluitpost is, maar het fundament. Dit paper laat zien dat het technisch haalbaar is, zonder dat de functionaliteit eronder lijdt. Nu de praktijk nog.

---

Bronnen

[1] Paper: Designing a GDPR-Compliant Security Architecture for Remote Elderly Care Systems, arXiv abstract / PDF
[2] AP-boete zorginstelling 2025 voor onvoldoende dataminimalisatie bij zorg-iot, Autoriteit Persoonsgegevens
[3] DPIA-template AVG, Autoriteit Persoonsgegevens

Verder lezen op djimit.nl: DPIA voor gezondheidsdata: wanneer ben je verplicht?