[Req 22]: Als betrokkene [die Mitz/VZVZ/VWS niet vertrouwt] wil ik niet dat Mitz mijn toestemmingen kan verwerken

[MLHoekstra]

Volledige omschrijving

Als burger [die Mitz/VZVZ/VWS niet vertrouwt] wil ik niet dat Mitz mijn toestemmingen kan verwerken

Achtergrond

Omdat deze nogal afwijkt van andere ('Mitz interne') requirements, vermoed ik dat dit niet de handigste is om vandaag te bespreken / op te pakken. Daarbij denk ik zelf dat het handig is als Ron er bij is bij bespreking van deze requirement, omdat de discussie hierover ook speelt met de NEN schrijversgroep waar hij bij betrokken is. Daarom lijkt het me niet handig als Ron de discussie hierover mist, dus ook om die reden is vandaag niet handig.

[Guidonoord]

Als betrokkene wil ik kunnen aangeven dat Mitz mijn persoonsgegevens niet mag verwerken.

(Ongeacht verwerkersovereenkomst of niet: absolute opt-out dus).

Overwegingen:

1. Als Mitz geen persoonsgegevens mag verwerken (= ook niet als verwerker) dan kan uitwisseling o.b.v. toestemming in Mitz ook niet plaatsvinden

2. De opt-out moet lokaal bij brondsystemen geregisteerd worden, om zeker te zijn dat ondanks mijn wens, er toch een registratie in het OTV plaatsvindt die uitwisseling van gegevens tot gevolg heeft.

Suboverwegingen Ad 2 (nog te verplaatsen naar een adnere plek):

• is de achterliggende gedachte dat de uitwisseling van gegevens geblokkeerd kan worden (blokkeren PDP functie). Doordat het OTV/Mitz een centrale component in de uitwisseling is, is blokkering van het "pad" via Mitz belangrijk om de uitwisseling te kunnen blokkeren.

• Waarom kan dit niet via het vastleggen van een "opt-out" in Mitz? (a) dit zou een contradictie zijn, want dan moeten alsnog mijn persoonsgegevens in Mitz gerigstreerd worden en dat wilde ik niet (dus Mitz mag mijn BSN niet verwerken). (b) als de opt-out in Mitz staat, kan de opt-out eenvoudig worden omgezet ("geflipt") in een opt-in/toestemming, bijv. door een arts op het point of care; of (c) een hacker die inbreekt in Mitz kan de bitflip ook realiseren (d) een beleidswijziging (policy creep) kan ook een "bitflip" van opt-out naar opt-in realiseren, bijv. een spoed-override. Denk aan EHDS, ... (e) opt-out register/registratie systeem mag niet hetzelfde register/systeem zijn als het opt-in register/registratie systeem (vanwege d).

Opm: Als Mitz mijn persoonsgegevens niet mag verwerken dan mag/kan een ander ook geen gegevens namens mij registeren???

[woutslakhorst]

Vanuit architectuur werkgroep: huidige denklijn richt zich op een OTV voor de burger en een DTV voor de zorgorganisatie. Die laatste is dus onderdeel van het dossier. Mijn mening is dat er vanuit de DTV nooit aanpassingen gedaan kunnen worden in de OTV (patient vs burger domein). Alleen wellicht via een machtiging (bestaat nog niet). Daarnaast mag een OTV alleen BSN registreren indien burger ooit iets heeft geregistreerd in de OTV. Betekent: nooit inloggen == geen registratie == geen noodzaak voor opt-out. Zou dat deze requirement dekken? De requirement zorgverlener registreert obv mondelinge ja gebeurt alleen in de DTV (dossier).

[JohanLHV]

Dit impliceert dat niet onboarden in OTV door burger op geen enkele wijze kan leiden tot toestemming. Dat betekent ook dat aan mensen geen ondersteuning gegeven kan worden én dat de op handen zijnde opt-out niet zou kunnen bestaan. Bezwaar dus tegen deze lijn.

[Guidonoord]

@woutslakhorst : je schrijft "nooit inloggen == geen registratie == geen noodzaak voor opt-out". Ik heb het hier niet mee eens omdat je aanname dat er vanuit de DTV (ik neem aan dat je bedoelt 'vanuit het zorgaanbiederdomein') geen aanpassingen in de OTV gedaan kunnen worden, niet klopt: in het huidige OTV/Mitz model (o.b.v. de dominante requirements vanuit de zorgkoepels) kunnen artsen namens patiënt een toestemming registreren. Dit betekent dat (zeker als je ook nog gemandateerde medewerkers meeneemt) een behoorlijk grote groep mensen (zorgverleners) een toestemming in het OTV kunnen registreren die -- ook weer in het huidige Mitz model -- kunnen leiden tot een onmiddelijke gegevensuitwisseling o.b.v. die geregistreerde toestemming.

De hiermee gepaard gaande risico's kun je als burger BINNEN het Mitz raamwerk niet mitigeren, aangezien Mitz (langs de band van toestemming) in feite alle uitwisselingen van gegevens via elektronische uitwisselingssystemen regisseert.

Daarom vind ik het dat je als burger, als je het OTV/Mitz inclusief het bijbehorende 'vertrouwensmodel' niet vertrouwt, de verwerking van je gegevens in Mitz volledig moet kunnen blokkeren.

Dit moet je m.i. aan de bron doen, dus niet in Mitz, omdat je anders toch vertrouwen in Mitz en het beleid rondom Mitz moet vertrouwen. (NB: dit is bepaald geen 'zero trust').

Merk op dat er een samenhang is met requirement 86:

• 86 gaat uit van een basaal vertrouwen in Mitz, dat als je daarin instelt dat zorgverleners niet NAMENS jou toestemming mogen registreren, ook niet in spoedsituaties, dit gehonoreerd blijft.
• Requirement 22 is absoluter: aangezien er vanuit een bron voor deze patiënt nooit informatie over de patiënt naar Mitz vrijgegeven mag worden, op welke manier ook (want volledige, absolute opt-out van verwerking), dan hoef je op geen enkele manier op het Mitz raamwerk inclusief de daarop aangesloten uitwisselingssystemen te vertrouwen. Je opt-out volledig, en absoluut.

Volgens mij zijn beide opties essentieel, met requirement 86 als de meest 'radicale' mitigerende maatregelstegen risico's die met het vertrouwensstelsel van Mitz samenhangen, vanuit het perspectief van de patiënt: een volledige opt-out aan de bronkant die de Mitz route volledig uitsluit.*

Beide opties zijn essentieel en randvoorwaardelijk voor volledig vertrouwen in het stelsel waar Mitz deel van uitmaakt.

*) In dit geval kan het noodzakelijk zijn om terug te kunnen vallen op alternatieve methodes om gegevens uit te wisselen met specifieke elektronissche uitwisselingssystemen of andere communicatiemethodes - anders heeft pt in de praktijk waarschijnlijk weinig andere keuze dan Mitz toch te accepteren. Maar dat is een ander verhaal.

[Guidonoord]

@JohanLHV : je aanname dat 'de op handen zijnde opt-out niet zou kunnen bestaan' begrijp ik niet. Wellicht redenatie toelichten.

[Guidonoord]

M.b.t. het controversieel verklaren van deze requirement: er zijn verschillende soorten burgers. Door een opt-out uit Mitz te kunnen honoreren blokkeer je op geen enkele wijze functionaliteit voor andere groepen burgers. Het is essentieel juist ook ogenschijnlijk strijdige requirements te ondersteunen in het stelsel als geheel.

Voorkom paternalisme en verkeerde aannames over 'de patiënt'. De afspraak tussen arts en patient heeft altijd voorrang, ook (juist ook) als die hard het pad van toegang blokkeert.

[woutslakhorst]

@Guidonoord mijn uitgangspunt is dat de gehele set aan requirements die goedgekeurd worden het bestaande OTV/Mitz model vervangen.

in het huidige OTV/Mitz model (o.b.v. de dominante requirements vanuit de zorgkoepels) kunnen artsen namens patiënt een toestemming registreren.

En als dat nu eens niet kan? Zou niets registreren dan niet meteen de opt-out vervangen? Blijft er nog DTV <> DTV interactie over om mitigerende maatregelen voor te bedenken, maar dat zit op exact hetzelfde niveau als een arts <> arts email/fax/telefoontje over jou voorkomen.

[Guidonoord]

@woutslakhorst : Ron Obbens heeft net bij de werkgroep Toestemming Requirements procesvoorstel gedaan om eventjes niet individueel te reageren/discussiëren maar eerst tussenstap van "consolideren van vragen" vanuit de architectuur werkgroep af te wachten. Ik voel ook een beetje dat we een rabbit hole ingaan. Ik stel dus voor even de volgende stap af te wachten (prive mailen of bellen kan natuurlijk altijd).