[Req 78]: Als zorginstelling wil ik de voor mij relevante toestemmingskeuzes real-time kunnen repliceren, zodat ik lokaal de toestemming van een patient kan verifiëren

[stevenvegt]

Uit de mail van Marc aan Steven:

Alternatieve formulering:

[Req XX] Als zorgaanbieder wil ik een toestemming kunnen uitvragen, zonder dat de centrale OTV daarvan op de hoogte is.

Beschrijving: Als zorgaanbieder wil ik het beroepsgeheim voor de patient kunnen waarborgen. Bevragen alle zorgaanbieders het gecentraliseerde OTV, dan wordt er voor al hun patiënten (ook de patiënten die niet in het OTV zitten) medische informatie gelogd in het gecentraliseerde OTV.

Dat kunnen we voorkomen door relevante toestemmingskeuzes van de patient op voorhand naar de instelling te sturen. Dan kan de bevraging en logging lokaal in de instelling plaats vinden.

[woutslakhorst]

Vanuit architectuur werkgroep: dit lijkt op een architecturele uitwerking van een systeem requirement. Wat is de onderliggende requirement? Gaat het om voorkomen van downtime of gaat het over privacy concerns (BSN's rond strooien waar dit niet mag)?

[LexPater]

Uit de mail van Marc aan Steven:

Alternatieve formulering:

[Req XX] Als zorgaanbieder wil ik een toestemming kunnen uitvragen, zonder dat de centrale OTV daarvan op de hoogte is.

Beschrijving: Als zorgaanbieder wil ik het beroepsgeheim voor de patient kunnen waarborgen. Bevragen alle zorgaanbieders het gecentraliseerde OTV, dan wordt er voor al hun patiënten (ook de patiënten die niet in het OTV zitten) medische informatie gelogd in het gecentraliseerde OTV.

Dat kunnen we voorkomen door relevante toestemmingskeuzes van de patient op voorhand naar de instelling te sturen. Dan kan de bevraging en logging lokaal in de instelling plaats vinden.

Bezwaar tegen de alternatieve formulering. De real-time replicatie in de titel heeft niets te maken met een requirement dat er decentrale registraties moeten zonder dat de centrale OTV daar van de hoogte is.

[Guidonoord]

Vraag is of het echt om replicatie gaat. Wie is de master, wie is de slave? Je kunt replicatie van OTV naar DTV hebben, maar ook mogelijk is een beslissing om alleen in de DTV een toestemming re registreren, dan is de DTV een 'master' die niet gerepliceerd wordt.

Hoe dan ook is de wens om een lokale DTV (PEP/PDP) te hebben natuurlijk uitstekend.

[Guidonoord]

N.a.v. de discussie over requirement 5 heb ik een kandidaat requirement (nieuw) ingeschoten die als volgt luidt:

"Voorstel n.a.v. discussie over Req 105: m.i. moet er nog een requirement bijkomen die articuleert "ik wil [als leverancier/zorgaanbieder] de toestemmingen bij Mitz geregistreerd zijn kunnen ophalen". Dit is iets anders dan abonneren! Ook een one-stop abonnement + opvraag.; "pollen" is in principe stateless aan de kant van Mitz,, een abonnement is dat niet"

Toevoeging: bij abonneren moet Mitz gegevens over de patient onthouden, i.c.m. de abonnerende zorgaanbieder(s). Dit geeft in beginsel informatie vrij over behandelaren van de patiënt, wat (dus) medische gegevens zijn. Allereerst kan dit (dus) niet zonder toestemming, maar bovendien voldoet het ook niet aan proportionaliteit/subsidiariteitsvereisten: er zijn minder privacy-schadende oplossingen voor dit probleem. Of het leidt tot een écht privacy-technisch goede oplossing is een andere vraag, maar in ieder geval voldoet pollen (stateless checken/ophalen van toestemmingen*) aan het criterium 'minder privacy schadend', in vergelijking met (long-term) subscriptions/abonnementen.

*) Dit checken/pollen kan ook gebeuren door een arts als die fysiek met patient in de spreekkamer zit en daarbij even mondeling toestemming vraagt om de toestemmingen te controleren ("ik check nu of je toestemmingen hebt"), bijvoorbeeld. Kan mogelijk zelfs onder veronderstelde toestemming.

[Guidonoord]

@VincentvandenBerg @albert.vlug@prosophia.nl @woutslakhorst : zie opmerking hierboven n.a.v. de discussie in de requirements wg zojuist. Mogelijk offline over verder praten.