Open stevenvegt opened 7 months ago
Ik denk dat 'aanpassen' registreren moet zijn. Dat woord maakt duidelijker dat het moment van registratie/vastlegging en het moment van doorvoeren van een aanpassing cq de enforcement van de aangepaste toestemming kunnen verschillen.
Dan wordt het: "als betrokkene kan ik zelf [op elk moment en op elke plaats] toestemmingen en wijzigingen in toestemmingen kunnen registreren en deze inzien"
Zo staat de registratie dus los van hoe of wanneer deze toestemmings(wijzigings)registratie wordt gedistribueerd of inzichtelijk is. Separation of concerns.
Bezwaar omdat suggestie wordt nu gewekt, door het woord 'aanpassen', dat de aanpassing van de toestemming direct in de uitwisseling wordt geëffectueerd.
Minder ambigu/interpretabel en daarom zuiverder is : "als betrokkene wil ik zelf online toestemmingen kunnen inzien en registreren "
Scope: OTV, bij de BTV is het geen probleem.
Verduidelijking: Startpunt voor splitsing discussie, in meerdere requirements:
Aangaande de term aanpassen: vanuit gebruikers is juist de wens dat aanpassing ook meteen tot effectuering leidt
@JohanLHV : er is niet één gebruiker, en zeker niet één patiënt.
We moeten toe naar een set van requirements die in samenhang verschillende groepen burgers kunnen bedienen. Dat betekent dus ook dat je soms tegenstrijdige reqiurements moet kunnen implementeren.
Directe effectuering is in feite alleen nodig voor SPOT, waarbij onmiddelijk gegevenuitwisseling nodig is. Andere situaties kunnen via een trager proces lopen (bijv., eerst validatie van het verzoek door de bronhouder(s) op wie de toestemming betrekking heeft, bijv. om te controleren of de ontsluiting van gegevens de privacy van derden niet doorbreekt [Wgbo eis]).
We hebben geconstateerd/besloten dat SPOT waarschijnlijk overbodig wordt met Wogs/Wogaz en EHDS, waarbij (andere) waarborgen mbt opt-out voor spoed-toegang worden gecreeerd. Gegeven deze ontwikkeling, is het niet verantwoord veiligheid van het systeem als geheel te ondermijnen met een optimalisatie voor spoed.
Andere argumenten voor directe effectuering die doorslaggevend zouden zijn voor deze afweging zie/ken ik niet.
NB: ik denk ook echt niet dat de burger directe effectuering verwacht. Een systeem dat een bericht naar relevante bronhouders stuurt waarbij de bronhouder vervolgens conform de toestemming gegevens ontsluit, lijkt mij veel dichter bij de verwachting van burgers te liggen; dit is in ieder geval juridisch een logische(r) route, mijns inziens.
@JohanLHV Met directe effectuering implementeer je dezelfde risico's als bij het L-EPD aanwezig waren.
Met deze insteek kom je direct uit bij de mythe 'Privacy vs functionaliteit'.
De opdracht aan de architecten moet zijn: de juiste gegevens, op het juiste moment op de juiste beschikbaar (zonder dat ze toestemming direct kunnen effectueren).
23/10 architectuur werkgroep Als Mitz (brondeel en burgerdeel) wordt gebruikt dan wordt het gedekt Als Mitz niet wordt gebruikt door zorgaanbieder en je hebt een online DHTV (patiëntenportaal) dan wordt de requirement ook gedekt Als je als patiënt een zorgaanbieder hebt die geen Mitz heeft en geen online DHTV (patiëntenportaal) dan voldoet de requirement niet
Volledige omschrijving
Als ik als betrokkene dat wil moet ik op elk moment en op elke plaats, dus online, mijn eigen toestemmingskeuzes kunnen inzien, vastleggen en aanpassen;
Achtergrond:
Relatie met
Nummer #6 , maar dan is deze uitgebreider, nl inzien en aanpassen. Stelt eis aan moment: "op elk moment" en ook eis aan locatie: "op elke plaats".