RFC0030 Voorbereiding op machtigen

Samenvatting

Waarom is deze RFC nodig?	In het MedMij Afsprakenstelsel speelt de Persoon-rol nu tegelijk de rol van gebruiker van de PGO als die van degene waarover de informatie in het persoonlijke dossier gaat. Dat staat situaties in de weg waarin die twee rollen door verschillende individuen worden gespeeld, met name waarbij de ene Persoon zich door een andere laat vertegenwoordigen, door middel van een machtiging. Met een machtiging laat de één (de Betroffene) gegevens betreffende zichzelf Verzamelen of Delen door een ander (de Gebruiker). Daarvoor moet de Gebruiker rechtshandelingen uitvoeren namens de Betroffene, met name het verlenen van toestemming. Iemand kan op basis van een wettelijke grondslag zijn gemachtigd, zoals gezaghebbende ouder(s) of voogd voor kinderen onder de 12 jaar of op basis van een vrijwillig afgegeven machtig. Het gebruik van machtigingen is bijvoorbeeld noodzakelijk om mantelzorgers hun taak goed uit te kunnen laten voeren in de langdurige zorg. Deze RFC wil door het differentiëren van de Persoon-rol ruimte maken voor zulke machtigingen. Dat maakt het vooralsnog mogelijk om eenzijdig, in het Zorgaanbiedersdomein, machtigingsfunctionaliteit te gaan gebruiken. Op termijn wil MedMij dat ook, en gekoppeld daarmee, in het Persoonsdomein ondersteunen, maar dat kan nog niet met deze RFC. Hoewel deze wijziging ruimte biedt aan Deelnemers voor het gebruiken van machtigingsfunctionaliteit of anderszins ontkoppelen van Gebruikers en Betroffenen, neemt het MedMij Afsprakenstelsel hierover geen expliciete verantwoordelijkheden op, behalve waar deze nieuwe ruimte risico’s inzake vertrouwen en gegevensintegriteit met zich mee kunnen brengen.
Oplossingsrichting	Het splitsen van de juridische Persoon-rol op de Juridica-laag in een Gebruiker-rol en een Betroffene-rol. Het verbinden van deze twee rollen met de passende rollen op de lagen eronder, door het hele MedMij Afsprakenstelsel. Het toevoegen van de afspraak dat een Dossier (in een PGO) slechts informatie over één Betroffene bevat. In een PGO mogen verschillende dossiers worden onderhouden, maar die moeten dus wel gescheiden zijn. Een PGO heeft één Gebruiker, die meerdere Dossiers in zijn PGO kan onderhouden. De Zorgaanbieder is ervoor verantwoordelijk dat de Gebruiker niet meer autorisaties krijgt dan waarvoor hij gemachtigd is. Waar nieuwe vertrouwensrisico’s voortvloeien uit deze rol-differentiatie: het toevoegen van maatregelen voor beheersing van deze risico’s aan het MedMij Afsprakenstelsel. Om te voorkomen dat informatie van verschillende personen in een dossier vermengd raken worden maatregelen getroffen. Het voorstel is om de geboortedatum van de betroffene als identificerend kenmerk in de autorisatierequest op te nemen in de scope parameter. De DVZA voert een check uit of de geboortedatum overeenkomt met die van de Betroffenne. Deze controle kan ook ingevoerd worden wanneer de Gebruiker en Betroffene dezelfde persoon zijn. Op deze wijze kan data integriteit beter geborgd worden. De beschikbaarheids- en ontvankelijkheidsvoorwaarde moeten inzake leeftijd worden aangepast. Deze RFC wordt doorgevoerd als een uitbreiding op het afsprakenstelsel: Optioneel, dus dienstverleners kunnen er voor kiezen om vertegenwoordigen (op basis van een machtiging) niet te ondersteunen. Het koppelvlak zal ongewijzigd blijven met als uitgangspunt dat de indicatie voor vertegenwoordiging daar al wel in opgenomen is maar dat het verwerken van die indicatie, inclusief de bijbehorende taken, een vrije keuze is voor de dienstverlener. gericht op Vrijwillig Machtigen en (nog) niet op Wettelijke Vertegenwoordiging. in eerste opzet gebruik maken van de voorziening voor Vrijwillig Machtigen van DigiD via TVS. Dit koppelvlak bevat al de indicator voor vertegenwoordiging. Met de opgedane ervaringen kunnen in volgende iteraties de afspraken meer generiek en verder aangescherpt worden Wel een voorziening in het Zorgaanbiedersdomein, geen voorziening in het Persoonsdomein.
Aanpassing van	Zie Uitwerking en subpagina's
Impact op rollen	Persoon, Zorgaanbieder, Dienstverlener zorgaanbieder, Dienstverlener persoon
Impact op beheer	verwerken van de indicatie voor vertegenwoordig in het koppelvlak
Impact op RnA	uitbreiding van het koppelvlak
Impact op Acceptatie	wel, n.t.b.
Gerelateerd aan (Andere RFCs, PIM issues)	n.v.t.
Eigenaar	Johan Hobelman (Unlicensed) Casper van der Harst
Implementatietermijn	1.4.0 (voorbereiding op)
Motivatie verkorte RFC procedure (patch)	n.v.t.

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad

Principe's

Principe		Principe
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal	Neutraal	11 Stelselfuncties worden vanaf de start ingevuld	Neutraal
2 Dienstverleners zijn transparant over de gegevensdiensten	Neutraal	12 Het afsprakenstelsel is een groeimodel	Positief
3 Dienstverleners concurreren op de functionaliteiten	Neutraal	13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders	Positief
4 Dienstverleners zijn aanspreekbaar door de gebruiker	Neutraal	14 Uitwisseling is een keuze	Neutraal
5 De persoon wisselt gegevens uit met de zorgaanbieder	Positief	15 Het MedMij-netwerk is gebruiksrechten-neutraal	Neutraal
6 MedMij spreekt alleen af wat nodig is	Positief	16 De burger regisseert zijn gezondheidsinformatie als uitgever	Positief
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener	Neutraal	17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld	Positief
9 De dienstverleners zijn deelnemers van het afsprakenstelsel	Neutraal	18 Afspraken worden aantoonbaar nageleefd en gehandhaafd	Neutraal
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling	Positief	19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat	Neutraal

Uitwerking:

Juridica

UC Verzamelen

UC Delen

UC Abonneren

UC Notificeren

UC Opvragen GNL

UC Opvragen OCL

UC Opvragen ZAL

Beschikbaarheids- en ontvankelijkheidsvoorwaarde

Applicatie

Interfaces

Use case-implementaties

Netwerk

Informatiemodellen

Metamodel

Logische modellen

XML-schema's

XML-bestanden voor lijsten

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen
n.t.b.

Bijlagen