Ga naar inhoud

Data Protection Impact Assessment (DPIA)

Versie 1.0.0 - juni 2026

Een DPIA is verplicht op grond van Art. 35 AVG wanneer een verwerking waarschijnlijk een hoog risico inhoudt voor de rechten en vrijheden van betrokkenen. Gezien de grootschalige verwerking van gezondheidsgegevens is een DPIA voor Remedice noodzakelijk.

1. Systematische beschrijving van de verwerkingen

1.1 Overzicht

Remedice verwerkt persoonsgegevens in de volgende modules:

Module Type gegevens Bijzondere categorie Volume
Medicatiebeoordeling Patientnaam, geboortedatum, medicatie, CI, allergieen, labwaarden Ja (gezondheid) Honderden patienten per apotheek
Atlas Chat (zonder patientcontext) Chatberichten, bronverwijzingen Nee Duizenden berichten per maand
Atlas Chat (met patientcontext, sinds 2026) Gepseudonimiseerde patientcontext: leeftijdsbucket (5-jaars + 90+ cap), geslacht, medicatie, contra-indicaties, labwaarden Ja, gepseudonimiseerd (geen direct identificerende velden, geen analyses) Duizenden berichten per maand
Gebruikersbeheer Naam, e-mail, authenticatiegegevens Nee Tientallen per apotheek
OIDC-koppelingen (optioneel) Subject-identifier en e-mailadres per gekoppelde provider (ZORG-ID, Google, Apple) Nee Tientallen per apotheek
Audit logging Acties, IP-adressen, tijdstempels Nee Continue logging

1.2 Gegevensstromen

Medicatiebeoordeling: 

AIS-export (Medimo/Pharmacom/Sanday) -> Parser -> ATC-verrijking (G-Standaard)
-> Patientprofiel-matching -> 6 analyses -> Opslag (versleuteld) -> Weergave

Atlas Chat: 

Gebruikersvraag -> Remedice backend -> Bedrock Knowledge Base retrieve (Aurora pgvector)
   [optioneel: NCBI/PubMed literatuur-lookup met gesanitiseerde zoektermen, geen patientdata]
-> Amazon Bedrock Claude (EU, eu-central-1) -> Antwoord + bronnen
-> Opslag (30d DB -> 60d warm S3 -> 10j compliance S3)

Anamnese-gesprek: 

Patient-audio (browser/RN-mic) -> Remedice backend (proxy) -> AWS Transcribe (EU, eu-central-1, nl-NL streaming)
-> Transcript -> PII-redaction (uitsluitend regex) -> Opslag op AWS RDS
-> Amazon Bedrock Claude Haiku 4.5 voor klinische samenvatting -> Opslag in patient-dossier
Originele audio wordt niet persistent gemaakt.

1.3 Verwerkingsverantwoordelijke en verwerker

  • Verwerkingsverantwoordelijke: de apotheek
  • Verwerker: Remedice B.V.
  • Subverwerkers: AWS (hosting EU eu-central-1 en alle patientdata-AI: Amazon Bedrock LLM, Bedrock Knowledge Bases RAG, AWS Transcribe STT), Google Cloud EMEA (uitsluitend tekst-naar-spraak voor de werkafspraken-podcast: Cloud Text-to-Speech Chirp 3 HD in europe-west4, geen patientdata), Stripe (betaling VS/EU)

2. Noodzaak en evenredigheid

2.1 Noodzaak

De verwerking van gezondheidsgegevens is noodzakelijk voor het doel: ondersteuning van de apotheker bij medicatiebeoordelingen. Zonder toegang tot medicatiehistorie, contra-indicaties en labwaarden kunnen de geautomatiseerde analyses niet worden uitgevoerd.

2.2 Evenredigheid en dataminimalisatie

Maatregel Toelichting
Veldversleuteling Patient- en medewerkergegevens worden versleuteld opgeslagen (Fernet/AES-128-CBC + HMAC-SHA256)
Beperkte bewaring Maximaal 3 reviews per patient; oudere worden gearchiveerd
Strikte allowlist voor patientcontext Atlas Chat ontvangt geen direct identificerende velden, geen analyses. Allowlist enforced in features/atlas/patient_context.py. Deep review (gegenereerde analyse over de patient) blijft verwijderd; patientcontext naar Atlas dient uitsluitend voor RAG-retrieval.
Tenant-isolatie Elke apotheek heeft een eigen database-schema
RBAC Alleen geautoriseerde medewerkers zien patientdata
Step-up herauthenticatie Toegang tot patientgegevens en onomkeerbare acties vereist een verse step-up (TOTP of biometrie op een trusted device) bovenop de bestaande sessie
Dataminimalisatie OIDC-koppeling Een optionele ZORG-ID-, Google- of Apple-koppeling bewaart alleen de subject-identifier en het e-mailadres. Geen BIG en geen RIBIZ/BIG-register lookup.
Geen directe patientinteractie Patienten gebruiken het systeem niet zelf

2.3 Rechtsgrond

Art. 6 lid 1 sub b (uitvoering overeenkomst) in combinatie met Art. 9 lid 2 sub h (noodzakelijk voor gezondheidszorg, onder verantwoordelijkheid van beroepsbeoefenaar met geheimhoudingsplicht).

2.4 PII-redaction en de subverwerker-grens

Directe identifiers (BSN, telefoonnummer, e-mailadres, postcode, geboortedatum) worden met een regex-pass uit transcripten en invoer verwijderd voordat opslag of een werkafspraken-podcast-TTS-call plaatsvindt. Een aanvullende LLM-redactiepas is bewust niet toegepast, omdat die de PII-tekst eerst naar een model zou sturen en daarmee precies de blootstelling zou creeren die de redactie moet voorkomen.

Regex vangt geen vrije-tekst namen. In de patientdata-paden, met name de anamnese-samenvatting, kan een naam het model daarom bereiken. Een anamnese-samenvatting kan per definitie niet zonder patientcontext. De waarborg in deze paden is daarom de subverwerker-grens zelf: Amazon Bedrock verwerkt in de EU (eu-central-1), onder de AWS DPA, zonder gebruik voor modeltraining en zonder retentie na de call. De werkafspraken-podcast gaat naar Google Cloud maar verwerkt geen patientdata. Die tekst is afgedekt door de regex-rejectie en een UI-waarschuwing. Verbetering van de naam-detectie staat als compliance-follow-up gepland.

3. Risicoanalyse

3.1 Risicomatrix

Kans: 1 = Zeer onwaarschijnlijk, 2 = Onwaarschijnlijk, 3 = Mogelijk, 4 = Waarschijnlijk, 5 = Zeer waarschijnlijk

Impact: 1 = Verwaarloosbaar, 2 = Beperkt, 3 = Significant, 4 = Ernstig, 5 = Zeer ernstig

Risicoscore: Kans x Impact. Acceptabel: <= 6, Aandacht: 7-12, Onacceptabel: >= 13

3.2 Geidentificeerde risico's

Medicatiebeoordeling-module

# Risico Kans Impact Score Maatregelen Restscore
R1 Ongeautoriseerde toegang tot patientgegevens door extern datalek 2 5 10 Veldversleuteling, 2FA, tenant-isolatie, audit logging, rate limiting 4
R2 Ongeautoriseerde toegang door insider (medewerker apotheek) 2 4 8 RBAC, audit logging, principle of least privilege, soft delete 4
R3 Foutieve analyseresultaten leiden tot onjuist medicatieadvies 2 4 8 Validatiestudies, disclaimers, apotheker als eindverantwoordelijke, post-market surveillance 4
R4 Verlies van patientdata door technisch falen 2 4 8 Dagelijkse backups, S3-replicatie, disaster recovery 3
R5 Verouderde klinische data (STOPP-criteria, ACB-scores) 3 3 9 Periodieke data-updates, literatuurmonitoring, versiebeheer databronnen 4
R6 Foutieve ATC-lookup door fuzzy matching 3 3 9 Validatiestudie G-Standaard, fallback-indicatie in UI, handmatige correctiemogelijkheid 4

Atlas Chat

# Risico Kans Impact Score Maatregelen Restscore
R7 Gebruiker typt vrije patientdata in Atlas-composer ondanks disclaimer 3 3 9 Disclaimer in UI, server-side reject_if_pii-validatie op alle Atlas-input, gebruiksvoorwaarden, verwerking uitsluitend via AWS Bedrock (EU, zero-retention, geen modeltraining) 4
R8 Onjuiste farmaceutische informatie door AI-hallucinatie 3 3 9 Bronvermelding (citaten), disclaimer "Atlas zoekt relevantere bronnen op basis van patientcontext. Geen klinische analyse.", system-prompt verbiedt patientspecifieke conclusies, apotheker als eindgebruiker, validatieset (validatie/protocol_atlas.md) 6
R9 Chatdata onderschept bij doorgifte naar AWS Bedrock 1 3 3 TLS, AWS DPA, EU-residency (eu-central-1 plus EU-fallback-regio's), Bedrock zero-retention en geen modeltraining 2
R16 Re-identificatie van patient uit gepseudonimiseerde Atlas-context 2 3 6 Strikte allowlist (features/atlas/patient_context.py): geen naam/DOB/BSN, leeftijd in 5-jaars buckets met 90+ cap. Tenant-brede kill-switch + per-user toggle. Audit-trail (alleen velden-keys, geen inhoud). Vaste sub-processor (AWS Bedrock) onder DPA, EU-residency en zero data retention. 3
R17 Atlas geeft toch een patientspecifieke conclusie ondanks framing 2 4 8 System-prompt-discipline (ATLAS_INSTRUCTION in features/atlas/bedrock.py plus het patientcontext-framingblok in features/atlas/patient_context.py), geen analyses (STOPP/START output) in payload, periodieke validatie via eval-set, apotheker als eindverantwoordelijke. 4

Authenticatie en accountbeheer

# Risico Kans Impact Score Maatregelen Restscore
R10 Account compromise door gestolen credentials 2 4 8 Verplichte 2FA (TOTP), rate limiting, audit logging mislukte pogingen, JWT-tokens via HttpOnly cookies (web) en OS-keychain (native) 3
R11 Ongeautoriseerde toegang via verouderd trusted device 2 3 6 Device-registratie per gebruiker, intrekmogelijkheid, soft delete 3
R14 Diefstal van authenticatietokens via XSS (web) 1 4 4 JWT-tokens opgeslagen als HttpOnly cookies; nooit via JavaScript leesbaar; expliciet gewist uit localStorage/sessionStorage 2
R19 Verkeerd geadresseerde uitnodiging geeft de verkeerde echte persoon toegang tot patientdata 2 5 10 Uitnodiging gericht op een specifiek e-mailadres door een beheerder; roltoekenning via RBAC; step-up herauthenticatie (verse TOTP of biometrie) vereist voordat patientgegevens zichtbaar zijn; directe intrekroute; volledige HIGH-audit van uitnodiging, acceptatie en patientdatatoegang 4

Infrastructuur

# Risico Kans Impact Score Maatregelen Restscore
R12 Datalek bij subverwerker (AWS, Google, Stripe) 1 5 5 DPAs, SCCs, ISO 27001-certificeringen, contractuele meldplicht 3
R13 Ransomware of DDoS op Remedice-infrastructuur 2 4 8 Dagelijkse backups, AWS beveiligingsdiensten, incidentresponsplan 4
R15 Doorgifte van pushinhoud via APNs en FCM (VS) bij mobiele notificaties 2 2 4 Pushtitels en bodies zijn generiek geformuleerd; patientidentifiers (naam, BSN, geboortedatum, medicatie) worden vooraf uit de inhoud verwijderd. Push-token is pseudonimisch en alleen gekoppeld aan tenant + user. Apple APNs en Google FCM verwerken uitsluitend wat nodig is voor aflevering. Voor iOS-pushes is doorgifte naar Apple onvermijdelijk; voor Android-pushes geldt hetzelfde voor Google FCM. SCCs en EU-U.S. Data Privacy Framework dekken de transfer. 2
R18 Uitgaand verkeer vanuit publieke subnets zonder NAT Gateway 2 3 6 Geen NAT Gateway. Alle Fargate-taken draaien in publieke subnets met strikte security groups: egress beperkt en least-privilege, geen inkomend verkeer behalve via de load balancer. De uitgaande integraties (ZORG-ID OIDC via client_secret_post, Stripe, KvK, AWS- en Google-API's) eisen geen source-IP-whitelisting, zodat een vast uitgaand IP via NAT niet nodig is. SG-equivalentie ten opzichte van een private-subnet-met-NAT-opzet is gedocumenteerd in de NEN 7510-risicoanalyse. 3

3.3 Samenvatting restrisico's

Na implementatie van alle maatregelen zijn alle restrisicoscores <= 6 (acceptabel). De hoogste restrisico's (score 6) betreffen:

  • R8: AI-hallucinatie in Atlas Chat
  • R16: Re-identificatie van patient uit gepseudonimiseerde Atlas-context (combinatorisch via medicatielijst in kleine apotheek)

Beide risico's worden gemitigeerd doordat (a) de apotheker professionele eindgebruiker is en alle output beoordeelt, (b) de allowlist + 5-jaars-leeftijdsbucket de re-identificatie minimaliseren binnen wat klinisch nog bruikbaar is, en (c) de tenant kill-switch + per-user toggle de gebruiker controle geven. Re-identificatie via combinatorisch effect blijft een inherent restrisico zolang patientcontext naar een sub-processor gaat. Dit wordt aanvaardbaar geacht omdat AWS Bedrock onder de AWS DPA, EU-residency (eu-central-1) en zero data retention werkt.

4. Rechten van betrokkenen

Recht Implementatie in Remedice
Inzage (Art. 15) Apotheek kan via het platform alle opgeslagen patientgegevens inzien
Rectificatie (Art. 16) Gegevens kunnen worden gecorrigeerd door geautoriseerde medewerkers
Wissing (Art. 17) Soft delete van gebruikersaccounts; patient-erasure-flow per profiel via POST /api/medicatiebeoordeling/patient-profielen/<id>/erase-request/ + /erase-execute/. Pseudonimiseren tijdens WGBO-bewaartermijn (20 jaar art. 7:454 lid 3 BW); hard-delete pas na verstrijken
Beperking (Art. 18) Technisch mogelijk via deactivatie van accounts of archivering
Dataportabiliteit (Art. 20) Export mogelijk in JSON/CSV-formaat
Bezwaar (Art. 21) Apotheek als verwerkingsverantwoordelijke behandelt bezwaren

4.1 Erasure-flow (AVG art 17 / WGBO art 7:455 BW)

Een patient kan zijn dossier laten vernietigen. WGBO art 7:454 lid 3 BW legt op de zorgaanbieder een 20-jaars bewaarplicht vanaf laatste mutatie, behoudens verzoek tot vernietiging door de patient (art 7:455). De software ondersteunt beide situaties:

De gebruiker met review.erase_patient-rol bedient de flow via het scherm Patiëntrechten (AVG), bereikbaar via een subtiele link op het scherm Patiëntdossiers. Dat scherm toont ook dossiers waarvan alle reviews zijn verwijderd (include_orphaned), zodat achtergebleven PII alsnog wisbaar is.

  • Stap 1: registratie. De apotheek legt het verzoek vast met motivering via POST /api/medicatiebeoordeling/patient-profielen/<id>/erase-request/. De rij PatientErasureRequest houdt status, motivering, en het tijdstip van laatste activiteit op het dossier vast. Audit-event: review.patient.erasure_requested.

  • Stap 2: uitvoering. Een tweede call naar /erase-execute/ met het erasure_request_id en confirmation: "BEVESTIG" voert de wissing daadwerkelijk uit. Deze stap is een onomkeerbare actie (Tier-3) en vereist daarom op elke aanroep een verse, eenmalig bruikbare TOTP-code, ook wanneer de gebruiker al een step-up-window open heeft. De backend bepaalt de uitvoer op basis van de WGBO-cutoff:

  • Laatste activiteit < 20 jaar geleden: pseudonimiseren (alle persoonsgegevens vervangen door een onomkeerbare hash; FK-relaties blijven staan zodat de audit-trail intact blijft).

  • Laatste activiteit >= 20 jaar geleden: hard-delete van het profiel (review-rijen blijven via on_delete=SET_NULL bestaan, waarbij de PII al in dezelfde transactie is gepseudonimiseerd).

Audit-event op uitvoering: review.patient.erasure_executed met execution_mode (pseudonymized of hard_deleted).

Verhouding tot het S3 Object Lock-archief. De compliance-mode S3-objecten in het 20-jaars Object Lock-archief kunnen niet voor retention-expiry worden verwijderd; dat is per ontwerp. De erasure-flow raakt het archief niet aan. Wanneer een gepseudonimiseerd profiel later alsnog hard-deleted wordt na verstrijken van de WGBO-termijn, blijven de archief-objecten van eerdere reviews staan tot hun individuele retention-deadline; vanaf dat moment kunnen ze regulier worden weggegooid.

Rolverdeling. De pharmacy is en blijft de juridische afweger. De software registreert het verzoek, dwingt de twee-stap-bevestiging af, voert de feitelijke wissing uit en logt beide stappen. De software beslist niet zelf over toewijzen of afwijzen van een AVG art 17-verzoek; dat blijft een inhoudelijk pharmacy-oordeel.

5. Advies Functionaris Gegevensbescherming

[In te vullen door de FG van de apotheek of door een extern aangestelde FG]

Opmerking: Apotheken die Remedice gebruiken dienen zelf een FG aan te stellen of aan te wijzen indien zij voldoen aan de criteria van Art. 37 AVG (grootschalige verwerking van bijzondere persoonsgegevens). Remedice adviseert alle deelnemende apotheken om een FG te betrekken bij de beoordeling van deze DPIA.

5bis. Aanvullende verwerkingen buiten patient-data-omgeving

5bis.1 Scraper-pijplijn (features/scraper/)

De scraper haalt openbaar beschikbare richtlijnen (NHG, FK, G-Standaard) op om de RAG-corpus van Atlas te vullen. Deze pijplijn is bewust losgekoppeld van de patient-data-omgeving:

  • Bron: publieke richtlijnpagina's; geen authenticatie naar bron, geen patientgegevens.
  • Doel: opbouwen van een gedeelde, tenant-onafhankelijke kennisbank waar Atlas tegen graspt.
  • Persoonsgegevens: geen. Captions van figuren worden via Amazon Bedrock Claude (Haiku 4.5, met escalatie naar Sonnet 4.6 voor stroomschema's) gegenereerd op de richtlijn-PDF of -afbeelding zelf, niet op patientcontent.
  • Bewaartermijn cache: scraper-cache wordt bij iedere succesvolle re-run overschreven; oudere snapshots blijven niet bewaard buiten de scraper-output-bucket.
  • Risico-classificatie: geen AVG-impact (geen persoonsgegevens). Wel licentievoorwaarden bron-richtlijnen respecteren (zie open vraag in 7.4 van de audit).

5bis.2 Usage-module (features/usage/)

De usage-module houdt token- en aanroep-tellers bij voor billing en fair-use-handhaving (Stripe meter-events):

  • Persoonsgegevens: alleen user_id als FK; geen patient-identificatie, geen prompt-content.
  • Doel: facturatie, fair-use-monitoring, fraude-detectie. Rechtsgrond: art 6 lid 1 sub b (uitvoering overeenkomst).
  • Bewaartermijn: zolang de billing-relatie loopt + wettelijke bewaartermijn boekhouding (7 jaar, art 52 AWR).
  • Risico-classificatie: laag (counter-data, geen gezondheidsgegevens).

5bis.3 Cross-account Knowledge Base-retrieval

De Bedrock Knowledge Base leeft uitsluitend in het productie-account. Staging en dev lezen deze read-only via een STS assume-role (bedrock:Retrieve en RetrieveAndGenerate, geen ingest of mutatie).

  • Bron: publiek of gelicentieerd bronmateriaal (NHG, FK, richtlijnen, gescrapete referentie). Geen patientgegevens.
  • Risico-classificatie: geen AVG-impact. Cross-account toegang verandert de data-residency niet (alles blijft in eu-central-1) en raakt geen bijzondere persoonsgegevens.
  • Begrenzing: de prod-resourcepolicy staat staging alleen retrieval toe. StartIngestionJob en elke DataSource-mutatie blijven prod-only. Toegang is herleidbaar via CloudTrail AssumeRole-events.

5bis.4 Lange-staart audit-archief en CloudTrail org-trail

De audit logs (patienttoegang, authenticatie, beheer, AI-calls) leven 365 dagen direct doorzoekbaar in CloudWatch en gaan daarna naar een lange-staart S3-archief. Zie het logbeleid (NEN 7513) voor de volledige opzet.

  • Transport: een dagelijkse CreateExportTask exporteert elke afgesloten dag uit de CloudWatch audit-groepen naar het archief. Geen patientdata verlaat de EU: bron en bestemming staan beide in eu-central-1.
  • Bestemming: een S3 Object Lock-bucket in het org-account, governance-mode, uniforme bewaartermijn van 20 jaar (WGBO art. 7:454 lid 3 BW). Versleuteld met SSE-S3. Dezelfde bucket bevat de CloudTrail-organisatietrail (multi-region, log-file-validation) onder een aparte prefix.
  • Tamperbeveiliging: Object Lock blokkeert wijzigen of verwijderen door de applicatie en reguliere beheerders. De CloudTrail-trail legt elke AWS-API-actie op de log-infrastructuur zelf vast.
  • Risico-classificatie: geen extra AVG-impact. Het archief bevat dezelfde audit-inhoud die al in CloudWatch staat, alleen langer en onveranderbaar bewaard. Cross-account export raakt geen bijzondere persoonsgegevens buiten de bestaande audit-velden.

5ter. EHDS-readiness

Verordening (EU) 2025/327 (European Health Data Space) treedt gefaseerd in werking 2025-2029. Primair gebruik (zorgcontinuïteit) en secundair gebruik (onderzoek, beleid) krijgen aparte juridische regimes en interoperabiliteitseisen (FHIR/HL7).

  • Huidige scope: Remedice verwerkt alleen primair gebruik door de zorgaanbieder zelf. Geen secundair gebruik, geen geanonimiseerde data-export naar onderzoekers of overheid.
  • Roadmap: zodra LSP/AORTA-koppeling of e-receptverkeer wordt toegevoegd, valt dat verkeer onder EHDS-primary-use eisen (FHIR-conformiteit, gestandaardiseerde patient-export). Deze stappen vereisen een afzonderlijke DPIA-update.
  • Acties tot 2029: export-formaat AVG art 20 (dataportabiliteit) op FHIR-resources brengen zodra het EHDS-FHIR-profiel is gepubliceerd.

6. Toetsing consultatieplicht AP (Art. 36)

Voorafgaande raadpleging van de Autoriteit Persoonsgegevens is verplicht wanneer de DPIA uitwijst dat de verwerking een hoog risico zou opleveren indien de verwerkingsverantwoordelijke geen maatregelen neemt.

Conclusie: Na implementatie van alle beschreven maatregelen zijn de restrisico's acceptabel (alle scores <= 6). Voorafgaande raadpleging van de AP is op dit moment niet vereist. Deze beoordeling wordt jaarlijks herzien of bij wezenlijke wijzigingen in de verwerking.

7. Reviewschema

Datum Actie Verantwoordelijke
Maart 2026 Initiele DPIA Remedice
Mei 2026 Ad-hoc herziening: migratie patientdata-AI naar AWS Remedice
Juni 2026 Ad-hoc herziening: uniform multi-tenant accountmodel, UZI-bindingsgate verwijderd Remedice
Maart 2027 Jaarlijkse herziening Remedice + FG
Bij wijziging Ad-hoc herziening bij nieuwe verwerking of significant gewijzigd risicoprofiel Remedice