Page tree
Skip to end of metadata
Go to start of metadata
Waarom is deze RFC nodig?

Als aanvulling op RFC0030 Vertegenwoordiging worden in deze RFC afspraken voorgesteld die het mogelijk maken om voor elke Persoon in de rol van Vertegenwoordigde een eigen dossier te kunnen onderscheiden binnen een PGO. Om zo het mixen van gezondheidsinformatie van verschillende Personen binnen één PGO te voorkomen en de integriteit te waarborgen. 

Oplossingsrichting
  • Scenario 1: Opstellen van vereisten waarmee verschillende levensloopdossiers gescheiden worden binnen één account in een PGO. Het toevoegen van de afspraak dat een Dossier (in een PGO) slechts informatie over één Vertegenwoordigde 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. Zo kan een mantelzorger in één PGO ook Dossiers onderhouden van de door hem of haar verzorgden die op basis van een machtiging door hem of haar worden vertegenwoordigd.
    • Beschrijven van de processen waarmee scheiding wordt zekergesteld.
    • Om te voorkomen dat informatie van verschillende personen in een dossier vermengd raken worden maatregelen getroffen. Het voorstel is om (onder andere) de geboortedatum van de betroffene als identificerend kenmerk in de autorisatierequest op te nemen in de scope parameter.
  • Scenario 2: één PGO kent één dossier. De PGO ondersteunt meerdere Gebruikers, in ieder geval de Vertegenwoordigde en desgewenst Vertegenwoordigers die op basis van een machtiging toegang hebben eventueel met beperkingen. Het (enige) dossier heeft betrekking op de Vertegenwoordigde. 
Aanpassing van

Zie bij oplossingsrichting.

Impact op rollen

Persoon, Zorgaanbieder, Dienstverlener zorgaanbieder, Dienstverlener persoon

Impact op beheer
geen
Impact op RnA

geen

Impact op Acceptatie
wel, indicatie van vertegenwoordiging (NTB)
PIA noodzakelijk
  • Zeker stellen dat dossiers niet vermengd raken 
Gerelateerd aan (Andere RFCs, PIM issues)

RFC0030 Vertegenwoordiging

Eigenaar
Implementatietermijn

1.5.0

Motivatie verkorte RFC procedure (patch)


Goedkeuring

Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principe's

Principe
Principe
Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

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


Uitwerking

De use-case betreft het verzamelen van gezondheidsinformatie door een Persoon in de rol van Vertegenwoordiger die gemachtigd is om een andere Persoon, de Vertegenwoordigde, te vertegenwoordigen. 

Scenario 1:

In dit scenario moeten in de PGO en bij de machtigingsvoorziening de Vertegenwoordigde geselecteerd worden. Na ontvangst van de informatie selecteert de Vertegenwoordiger in zijn PGO het dossier van de Vertegenwoordigde om de informatie op te slaan.

  1. Gebruiker geeft in PGO aan dat hij informatie voor een ander wil ophalen.
  2. Gebruiker selecteert in de PGO de Vertegenwoordigde uit een lijst van alle Personen waarvan hij een machtiging tot vertegenwoordiging heeft.
  3. De PGO stuurt een authorisation request naar de Autorisatieserver.
  4. Autorisatie stuurt de gebruiker naar DigiD met de indicatie “vertegenwoordiging”.
  5. Gebruiker authenticeert bij DigiD.
  6. Gebruiker wordt door DigiD na authenticatie doorgestuurd naar de voorziening voor Vrijwillig Machtigen.
  7. Gebruiker selecteert de Vertegenwoordigde uit het machtigingsregister.
  8. DigiD levert een Authenticatieverklaring met daarin de BSN van de Vertegenwoordigde en het BSN van Vertegenwoordiger.
  9. DigiD registreert deze transactie.
  10. De autorisatieserver presenteert het toestemmingenscherm aan de PGO gebruiker
  11. ZA gebruikt de BSN van Vertegenwoordigde uit de Authenticatieverklaring voor uitwisseling van gezondheidsinformatie.
  12. ZA wisselt via DVZA de informatie uit met de DVP.
  13. DVP ontvangt de informatie en stuurt deze naar de PGO van Vertegenwoordiger.
  14. Vertegenwoordiger selecteert in PGO het dossier van de in stap 2 geselecteerde Vertegenwoordigde om de informatie in op te slaan.
    1. PGO weet om welke Vertegenwoordigde het hier gaat en zou dus automatisch het juiste dossier kunnen gebruiken

Scenario 2:

In dit scenario kan een Vertegenwoordiger toegang krijgen tot de PGO van Vertegenwoordigde en na ontvangst van informatie deze opslaan in het (enige) dossier van de Vertegenwoordigde.

  1. Gebruiker (Vertegenwoordiger) logt in bij de PGO van Vertegenwoordigde.
  2. De PGO stuurt een authorisation request naar de Autorisatieserver.
  3. Autorisatie stuurt de gebruiker naar DigiD met de indicatie “vertegenwoordiging”.
  4. Gebruiker authenticeert bij DigiD.
  5. Gebruiker wordt door DigiD na authenticatie doorgestuurd naar de voorziening voor Vrijwillig Machtigen.
  6. Gebruiker selecteert de Vertegenwoordigde uit het machtigingsregister.
  7. DigiD levert een Authenticatieverklaring met daarin de BSN van de Vertegenwoordigde en het BSN van Vertegenwoordiger.
  8. DigiD registreert deze transactie.
  9. De autorisatieserver presenteert het toestemmingenscherm aan de PGO gebruiker
  10. ZA gebruikt de BSN van Vertegenwoordigde uit de Authenticatieverklaring voor uitwisseling van gezondheidsinformatie.
  11. ZA wisselt via DVZA de informatie uit met de DVP.
  12. DVP ontvangt de informatie en stuurt deze naar de PGO van Vertegenwoordigde.
  13. Informatie wordt opgeslagen in het dossier van de Vertegenwoordigde. Hier hoeven geen extra maatregelen getroffen te worden omdat dit het enige dossier is in de PGO.

De PoC Vrijwillig Machtigen heeft scenario 2 succesvol beproefd. De verdere uitwerking in het afsprakenstelsel is beschreven als Extensie Vertegenwoordiging.

Risico's

Deze RFC is een aanvulling op RFC0030 met als doel om maatregelen te beschrijven die voorkomen dat informatie van verschillende personen in één dossier vermengd raken. In eerste instantie zijn dit handmatige acties omdat niet in alle gegevensdiensten de benodigde informatie over de betroffen personen beschikbaar is om dit in alle gevallen geautomatiseerd te laten verlopen. Het probleem doet zich niet voor als binnen de PGO alleen het dossier van Vertegenwoordigde gebruikt kan worden (scenario 2).

Dreiging

Kans

Impact

DreigingsID (intern)

Maatregelen

Informatie van een betroffen Persoon komt in het dossier van een andere Persoon (scenario 1)

M

H


De PGO Gebruiker (de Vertegenwoordiger) de mogelijkheid bieden om voor het opslaan van informatie het juiste dossier (van de Vertegenwoordigde) te selecteren


Informatie van een betroffen Persoon komt in het dossier van een andere Persoon (scenario 2)LH
Eén PGO kent maar één dossier.
  • No labels