Patiëntidentificatie
Maatregel Beschrijving
Section titled “Maatregel Beschrijving”YipYip bouwt patiëntidentificatie in zorgapplicaties zodat gezondheidsinformatie niet aan de verkeerde persoon wordt getoond of gekoppeld: BSN-validatie, een unieke interne patiënt-ID en deduplicatie. De checklist OUD 09.04.a (zie Z4) bevat dit als punten 8, 9 en 10; die checklist is nog niet geactualiseerd en geïmplementeerd.
Risico’s
Section titled “Risico’s”- Verkeerde patiëntdata getoond door naamconflict of dubbele registratie.
- Privacy-inbreuk doordat een medewerker het dossier van de verkeerde persoon opent.
- Medische fouten door onjuiste identificatie (patiëntveiligheid).
Wat we bouwen
Section titled “Wat we bouwen”Identificatie-attributen
Section titled “Identificatie-attributen”| Attribuut | Gebruik | Validatie |
|---|---|---|
| BSN | Unieke nationale identificatie | 11-proef bij invoer |
| Geboortedatum | Verificatie-attribuut | Datumvalidatie, verplicht |
| Achternaam | Verificatie-attribuut | Niet als unieke sleutel |
| Interne patiënt-ID | Primaire sleutel in de applicatie | UUID, systeemgegenereerd |
De interne patiënt-ID wordt in alle databasetabellen als foreign key gebruikt, zodat identificatie altijd via één record loopt.
- Validatie via de 11-proef bij invoer.
- Opslag versleuteld (niet als platte tekst in de database); of dit in elk lopend zorgproject zo is ingericht is nog niet geïnventariseerd (zie Gaps).
- Toegang conform het RBAC-model (alleen rollen die BSN mogen inzien); in de UI gemaskeerd waar mogelijk.
- Niet in logregels of URL’s.
Visuele verificatie door de zorgverlener
Section titled “Visuele verificatie door de zorgverlener”Elk scherm met patiëntdata toont een identificatieblok met naam, geboortedatum en patiënt-ID, zodat de zorgverlener kan bevestigen dat de juiste persoon wordt getoond.
Deduplicatie
Section titled “Deduplicatie”- Detectie: bij een nieuw record wordt gecheckt op achternaam plus geboortedatum (en BSN indien beschikbaar).
- Signalering: mogelijke duplicaten worden getoond aan de gebruiker of beheerder.
- Fusie: de beheerder voegt twee records samen via een expliciete merge-flow.
- Audit trail: merge-acties worden gelogd (wie, wanneer, welke records).
De matching-drempel (fuzzy of exact) wordt per project afgestemd met de klant.
Opname in ontwikkelproces
Section titled “Opname in ontwikkelproces”- Kick-off: vastleggen welke identificatieattributen worden gebruikt en hoe BSN wordt opgeslagen (onderdeel van de kick-off-checklist, zie Z4).
- Datamodel: review op een consistente interne patiënt-ID door het hele datamodel.
- Code review: controle op 11-proef, BSN-encryptie en identificatieblok in de UI (PR-review, zie 8.28).
- Testen: verkeerde BSN afgewezen, duplicaatdetectie werkt, merge-flow werkt.
- Per zorgproject is nog niet geïnventariseerd of BSN versleuteld is opgeslagen; uitkomst komt in het assetregister (ISMS-383).
- De kick-off-checklist die de identificatiekeuzes vastlegt bestaat nog niet (ISMS-378); geen opleverchecklist (ISMS-243).
- BSN-verificatie via de Sectorale Berichten Voorziening is niet geïmplementeerd; validatie is alleen de lokale 11-proef.
- Deduplicatie is projectspecifiek; geen standaard YipYip-bibliotheek.
Bewijs
Section titled “Bewijs”| Type | Beschrijving | Locatie |
|---|---|---|
| Code | BSN-validatie, encryptie en deduplicatie, PR-review | GitHub repository per project |
| Checklist en inventarisatie | Per project | Nog geen bewijs; zie Gaps |
Opmerkingen
Section titled “Opmerkingen”YipYip identificeert geen patiënten als zorgverlener. Wij bouwen de software waarmee klant-zorginstellingen hun patiënten identificeren.
Laatst gereviewed: 2026-03-26