Medische hulpmiddelen en zorgapplicaties
Maatregel Beschrijving
Section titled “Maatregel Beschrijving”YipYip beheert geen fysieke medische apparatuur. Deze maatregel gaat over twee dingen: de beoordeling bij de kick-off of een te bouwen product een medisch hulpmiddel is in de zin van de MDR, en de borging van patiëntveiligheid in de ontwikkeling van zorgapplicaties die gezondheidsinformatie verwerken.
Medisch hulpmiddel (MDR)
Section titled “Medisch hulpmiddel (MDR)”Bij de kick-off van elk zorgproject wordt beoordeeld of het product een medisch hulpmiddel is (MDR, regel 11 voor software). Tot nu toe is dat bij geen enkel YipYip-product het geval geweest; er valt geen YipYip-product onder de MDR. Zou dat in een project wel zo zijn, dan worden de certificeringseisen van de MDR met de klant opgenomen in de PRD voordat de bouw start.
De vraag “is dit een medisch hulpmiddel?” wordt onderdeel van de kick-off-checklist (zie hieronder).
Checklist development zorgapplicaties
Section titled “Checklist development zorgapplicaties”De checklist OUD 09.04.a is het hulpmiddel voor de kick-off-beoordeling van zorgprojecten. De checklist wordt nu niet ingevuld; hij moet eerst worden geactualiseerd (met de MDR-vraag en de toegangsmatrix uit Z1) en daarna worden geïmplementeerd als onderdeel van of bijlage bij de IB-paragraaf in de PRD. Ticket ISMS-389, owner Project Manager (zie ook ISMS-378).
| # | Onderwerp | Vereiste |
|---|---|---|
| 1 | Patiëntveiligheid | Als projectrisico opnemen in de PRD bij ieder project met gezondheidsinformatie |
| 2 | Labelen | Vertrouwelijkheidsmelding bij inloggen; prints en exports gelabeld (zie 5.13) |
| 3 | Logging | Gebruikersacties op gezondheidsinformatie gelogd en beschermd tegen manipulatie (zie Z2) |
| 4 | Testgegevens | Alleen synthetische of geanonimiseerde testdata |
| 5 | MFA | Twee-factor authenticatie voor gebruikers met toegang tot gezondheidsinformatie |
| 6 | Encryptie | Back-ups versleuteld opgeslagen; data in transit via TLS 1.2+ |
| 7 | Registratieproces | Formeel registratieproces met identiteitsvaststelling voor toegang |
| 8 | Zorgontvangers identificeren | Unieke identificatie via achternaam, geboortedatum en BSN (zie Z6) |
| 9 | Koppelen registraties | Dubbele registraties samen te voegen, met audittrail (zie Z6) |
| 10 | Validatie output | Identificerende gegevens op elk scherm met patiëntdata (zie Z6) |
Zolang de checklist niet is geïmplementeerd, komen de punten in de praktijk aan bod via de kick-off (5.08), acceptatiecriteria bij user stories en PR-review (8.28), zonder dat daar per project een afgetekend document van is.
Beveiliging van zorgapplicaties
Section titled “Beveiliging van zorgapplicaties”De technische maatregelen zijn geen aparte Z4-set, maar de reguliere controls: hosting op GCP met de netwerkinrichting uit 8.20, toegang via IAM en RBAC (Z1), logging (Z2, 8.15), encryptie (8.24), Dependabot voor dependencies (8.08) en wijzigingen via PR-review (8.32).
Pentest: pentesten is de verantwoordelijkheid van de klant. Bij oplevering wordt de klant gewezen op het laten uitvoeren van een pentest; YipYip faciliteert (toegang, testomgeving, opvolging van bevindingen). Uitgevoerde pentests en de opvolging worden per project vastgelegd.
Inventarisatie zorgapplicaties
Section titled “Inventarisatie zorgapplicaties”Welke projecten gezondheidsinformatie verwerken, en per project de uitkomst van de MDR-beoordeling, MFA, logretentie, break-the-glass, BSN-encryptie en RTO/RPO, wordt vastgelegd in het assetregister (registers/assets.yaml, migratie loopt onder ISMS-376). Die inventarisatie is nog niet gedaan (ISMS-383).
Incidenten met zorgapplicaties
Section titled “Incidenten met zorgapplicaties”Bij een incident met een zorgapplicatie geldt het reguliere proces (5.24–5.28, Jira IMS) met twee extra stappen: eerst beoordelen of er risico is voor zorgontvangers (zo nodig de applicatie offline halen), en de klant direct informeren bij mogelijke impact op gezondheidsinformatie. De klant is als verwerkingsverantwoordelijke verantwoordelijk voor meldingen aan toezichthouders; YipYip ondersteunt (zie 5.34).
- De kick-off-checklist (OUD 09.04.a) is niet geactualiseerd en wordt niet ingevuld; implementeren in de PRD (ISMS-389, owner Project Manager; zie ook ISMS-378).
- De MDR-beoordeling per project wordt nog niet vastgelegd; na implementatie van de checklist is de ingevulde checklist het bewijs.
- Inventarisatie van zorgprojecten en de zes maatregelen per project ontbreekt (ISMS-383); het assetregister bevat die informatie nog niet (ISMS-376).
- Uitgevoerde pentests en opvolging zijn niet per project vastgelegd.
- Geen opleverchecklist (ISMS-243).
Bewijs
Section titled “Bewijs”| Type | Beschrijving | Locatie |
|---|---|---|
| Checklist | Bronversie OUD 09.04.a | Google Doc |
| Code | PR-review en Dependabot | GitHub repository per project |
| Ingevulde checklists, MDR-beoordeling, pentests | Per project | Nog geen bewijs; zie Gaps |
Opmerkingen
Section titled “Opmerkingen”YipYip is een digital product agency (~10 medewerkers, Rotterdam) die software ontwikkelt voor zorginstellingen. De focus van deze maatregel ligt op de door YipYip ontwikkelde zorgapplicaties, niet op fysieke medische apparatuur.
Laatst gereviewed: 2026-01-28