Toegang tot patiëntgegevens

Maatregel Beschrijving

YipYip bouwt role-based access control (RBAC) in zorgapplicaties die gezondheidsinformatie verwerken. YipYip levert de toegangstechniek; de klant (zorginstelling) richt als verwerkingsverantwoordelijke de rollen en rechten in en wijst ze toe aan medewerkers.

Verantwoordelijkheidsverdeling

• YipYip is verwerker: wij bouwen de toegangstechniek conform de instructies van de klant.
• Klant bepaalt het rollenmodel: welke rollen bestaan (arts, verpleging, administratie) en welke data zij mogen inzien.
• YipYip documenteert het technische toegangsmodel in de projectdocumentatie (PRD en technische specificatie).

Wat we bouwen

RBAC-framework

Component	Implementatie
Rollenmodel	Per project geconfigureerd, in overleg met de klant
Permissions	Lezen, schrijven, exporteren per datacategorie apart instelbaar
Least privilege	Standaard geen toegang; toegang wordt expliciet verleend
Roltoewijzing	Via de beheerinterface van de klant
MFA	Standaard in het ontwerp van zorgapplicaties; of dit in elk lopend zorgproject feitelijk aanstaat is nog niet geïnventariseerd (zie Gaps)

Technische implementatie

• Backend (Elixir/Phoenix): Guardian en Bodyguard voor JWT-gebaseerde authenticatie en autorisatie; API-endpoints beveiligd met role-checks.
• Frontend en mobiel (Flutter): toegang per route of scherm op basis van rol; geen gevoelige data zonder actieve sessie.
• Sessiebeheer: tokenlevensduur wordt per project vastgelegd.

Toegangsmodel per project

Per zorgproject wordt een toegangsmatrix opgesteld en vastgelegd in de projectdocumentatie. Voorbeeld:

Rol (voorbeeld)	Toegangsniveau	Verantwoordelijkheid
Beheerder	Volledig (eigen domein)	Klant configureert rechten
Zorgverlener	Zorgdossier eigen cliënten	Klant definieert behandelrelatie
Rapportage	Aggregaat of geanonimiseerd	YipYip implementeert data-filtering
YipYip support	Technisch, geen inhoud	Toegang via GCP IAM en kubectl, gelogd in Cloud Audit Logs

De toegangsmatrix wordt onderdeel van de kick-off-checklist (zie Z4); die checklist is nog niet geïmplementeerd.

Opname in ontwikkelproces

1. Kick-off: toegangsmatrix opstellen met de klant, vastleggen in de IB-paragraaf van de PRD.
2. Sprint planning: access control als acceptatiecriterium bij user stories met gezondheidsdata.
3. Code review: reviewers controleren role-checks op relevante endpoints (PR-review, zie 8.28).
4. Testen: autorisatietests (kan rol X data van rol Y zien?).

Contractueel kader

• In de verwerkersovereenkomst met de klant staat dat YipYip RBAC-functionaliteit levert en de klant verantwoordelijk is voor de roleninrichting. Overzicht per klant: Sheet OUD 02.03.c Overzicht van contractuele verplichtingen.
• YipYip documenteert de beschikbare rollen en rechten in de technische specificatie (API-documentatie).
• Wijzigingen in het rollenmodel lopen als wijziging via Git en Jira (zie 8.32).

Gaps

• Per zorgproject is nog niet geïnventariseerd of MFA feitelijk aanstaat; uitkomst komt in het assetregister (ISMS-383).
• Toegangsmatrices zijn niet voor alle actieve projecten gedocumenteerd; de kick-off-checklist die dit afdwingt bestaat nog niet (ISMS-378, owner Project Manager).
• Er is geen opleverchecklist waarmee wordt afgetekend dat zonder juiste rol geen data toegankelijk is (ISMS-243).
• Periodieke review van toegangsrechten in de applicatie is een klantproces; YipYip signaleert niet buiten de applicatie.

Bewijs

Type	Beschrijving	Locatie
Code	Role-checks en PR-review	GitHub repository per project
Contractueel	Verwerkersovereenkomst per klant	Sheet OUD 02.03.c (link hierboven)
Toegangsmatrix	Per project	Nog geen bewijs; zie Gaps

Opmerkingen

YipYip is geen zorginstelling en heeft geen behandelaren, verpleging of administratie in de zin van de WGBO. Deze maatregel gaat over de technische borging van RBAC in de door YipYip geleverde software, zodat klant-zorginstellingen hun eigen toegangsbeleid conform NEN 7510 kunnen inrichten.

---

Laatst gereviewed: 2026-03-26