Skip to end of metadata
Go to start of metadata

Samenvatting

Waarom is deze RFC nodig?

Deze RFC is nodig om na een resource notificatie van de DVA:

  1. Een DVP de mogelijkheid te geven om zelfstandig, automatisch, zonder dat Persoon is ingelogd in haar PGO, gegevens te verzamelen bij, of te delen met een Aanbieder.
  2. Een DVP de mogelijkheid te geven om exact de juiste (workflow) gegevens te kunnen verzamelen of delen. In de huidige situatie moet een Persoon alle gegevens binnen een gegevensdienst (opnieuw) verzamelen of delen.

Omdat bovenstaande punten beiden betrekking hebben op de inhoud van een resource notification, is ervoor gekozen om ze te combineren in één RFC. Daarnaast vereist doelstelling 1 eigenlijk ook dat direct doelstelling 2 wordt gerealiseerd, omdat een DVP anders onnodig veel gegevens automatisch verzamelt of deelt (dataminimalisatie).

In deze RFC worden de volgende situaties meegenomen:

  1. Resource notificatie m.b.t. het verzamelen van nieuwe/gewijzigde gegevens via een bepaalde gegevensdienst.
  2. Resource notificatie m.b.t. het delen van bepaalde gegevens via een bepaalde gegevensdienst.
  3. Resource notificatie m.b.t. het ophalen van een specifieke taak i.h.k.v. een workflow.


Oplossingsrichting

Huidige inhoud van een Subscription:

  • aanbiedernaam
  • gegevensdienst-id
  • client_id (DVP)
  • persoon (iets als "gebruikersnaam" of "PGO-id" voor DVP, BSN voor DVA) - niet voorgeschreven in het afsprakenstelsel, is implementatiekeuze van de DV

Huidige inhoud van een Resource Notification:

  • subscription-id
  • notification-type (vaste waarde: "resource")

Wanneer een DVP een Resource Notification ontvangt, dan kan ze dus, in haar eigen Subscription registratie, terugvinden op welke aanbieder, gegevensdienst en persoon de notification betrekking heeft.


Om automatisch verzamelen of delen door DVP mogelijk te maken (doelstelling #1), is het nodig dat een DVP zelfstandig, middels een token request, een access_token kan verkrijgen bij de DVA. Het JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants biedt hiervoor de mogelijkheid, waarbij, in plaats van de authorization code uit de reguliere MedMij OAuth-flow, een JWT-based assertion wordt gebruikt als een Authorization Grant. DVP verkrijgt deze assertion dan als onderdeel van een Resource Notification.

Inhoud van een assertion:

  • jti (MAY in RFC 7523, gebruikt voor replay-detectie)
  • iss (MUST in RFC 7523) - gevuld met URL van het token endpoint van de DVA
  • sub (MUST in RFC 7523) - the subject typically identifies an authorized accessor for which the access token is being requested - gevuld met het subscription-id, zowel DVP als DVA kunnen deze herleiden naar de Persoon
  • aud (MUST in RFC 7523) - gevuld met URL van het token endpoint van de DVA
  • exp (MUST in RFC 7523) - <tijd van uitgeven assertion + 15 minuten>
  • digital signature (MUST in RFC 7523) - het token endpoint moet deze valideren, vraag: moet DVP deze ook valideren? Bijv. om te voorkomen dat een hacker ervoor zorgt dat gegevens van persoon-1 terecht komen in het PGO van persoon-2.

O.b.v. een assertion kan DVP zelfstandig een access_token verkrijgen van DVA, waarmee alle interacties kunnen worden uitgevoerd die binnen de scope van de bijbehorende subscription vallen.


Om een DVP de mogelijkheid te geven, om exact die gegevens te verzamelen of delen, zoals beoogd door DVA/Aanbieder (doelstelling #2), worden twee oplossingsrichtingen onderkend:

  1. Specifieke, fijnmazige subscription & generieke resource notification
    1. Bijv. subscription op één specifiek resource type, of zelfs op één specifieke resource instance
    2. Een resource notification heeft dan altijd betrekking op dát resource type of op die specifieke resource instance
  2. Globale subscription zonder specifieke criteria & specifieke resource notification
    1. Bijv. subscription op een gegevensdienst of op een workflowtype
    2. In de resource notification wordt het specifieke resource type of de specifieke resource instance opgenomen
  3. Globale subscription met specifieke criteria & specifieke resource notification
    1. Bijv. subscription op een gegevensdienst of op een workflowtype
    2. In criteria worden optioneel één of meerdere specifieke resource types en/of resource instances benoemd
    3. In de resource notification wordt
      1. het specifieke resource type of de specifieke resource instance opgenomen, EN/OF
      2. het criterium of de criteria opgenomen die hebben geleid tot een notificatie
OplossingsrichtingVoordelenNadelen
Specifieke, fijnmazige subscription & generieke resource notification (1)DVP/Persoon kan fijnmazig criteria voor notificatie instellen, alle notificaties zijn dus gewenst (dataminimalisatie).

Persoon dient subscriptions fijnmazig te beheren, gebruiksvriendelijkheid is daarom een issue.

Erg veel subscriptions nodig, daardoor niet schaalbaar.

Globale subscription zonder specifieke criteria & specifieke resource notification (2)Beperkt aantal subscriptions nodig, schaalbaar.

DVP/Persoon kan slechts grofmazig criteria voor notificatie instellen, daardoor ook notificaties waarmee DVP/Persoon niets kan of wil.

Globale subscription met specifieke criteria & specifieke resource notification (3)

Beperkt aantal subscriptions nodig, schaalbaar.

DVP/Persoon kan fijnmazig criteria voor notificatie instellen, alle notificaties zijn dus gewenst (dataminimalisatie).

Persoon dient subscriptions fijnmazig te beheren, gebruiksvriendelijkheid is daarom een issue.

Meest complexe oplossing.

Aan oplossingsrichting 1 kleven ongewenste nadelen. Deze oplossingsrichting valt daarmee af.

Oplossingsrichting 3 is mogelijk functioneel de beste, maar ook hieraan kleven een aantal nadelen. Gekozen is daarom, om te starten met oplossingsrichting 2. Deze oplossingsrichting kan, indien gewenst, in de toekomst worden uitgebreid richting oplossingsrichting 3.


Nieuwe inhoud van een Resource Notification:

  • subscription-id - 1..1
  • notification-type (vaste waarde: "resource") - 1..1
  • assertion - 0..1
  • trigger - 1..n
    • resource - 1..1 (bijv. "Observation" of "Observation/1348238" of "Observation?category=http://snomed.info/sct|118228005")

Bij ontvangst van een Resource Notification, die een assertion bevat, dient DVP te toetsen of het subscription-id in de Resource Notification en in de assertion met elkaar overeenkomen.


RACI
  • Responsible:
  • Accountable:
    • $RFC_RACI_Accountable
  • Consulted
    • Ontwikkelteam (ontwikkeling@medmij.nl)
    • Security Management (secmgt@medmij.nl)
    • Acceptatie (acceptatie@medmij.nl)
    • Stelselregie
    • Deelnemers (Expertgroepsessie)
  • Informed
    • Communicatie
    • Loket (info@medmij.nl)
    • Leveranciersmanagement


Aanpassing van

TODO

Impact op rollen


Impact op beheer


Impact op RnA


Impact op Acceptatie


PIA noodzakelijk
Gerelateerd aan (Andere RFCs, PIM issues)


Implementatietermijn


Motivatie verkorte RFC procedure (patch)


Uitwerking


Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )


Principe's

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


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.

Wanneer de beschreven oplossingsrichting dreigingen introduceert van risicoklasse A, B of C, dan zijn hiervoor aanvullende maatregelen vereist en benoemd.


DreigingKansImpactRisicoklasseDreigingsID (intern)Maatregelen
DVA wordt ongemerkt overgenomen door hackers, waardoor voor alle bestaande subscripties, geldige notificaties worden verzonden, inclusief een assertion. 

Bescheiden (een kans van 10 % dat het binnen 1 jaar optreedt)

Klein

Er wordt een groot aantal interacties (inclusief token requests) gegenereerd, waardoor Autorisatie Servers, Resource Servers en mogelijk ook xIS'en van zorgaanbieders voor wie de betreffende DVA optreedt, onbereikbaar worden.

D

Onopzettelijke fout bij DVA, waardoor per abuis, voor alle bestaande subscripties, geldige notificaties worden verzonden, inclusief een assertion. Laag (een kans van 5 % dat het binnen 1 jaar optreedt)

Klein

Er wordt een groot aantal interacties (inclusief token requests) gegenereerd, waardoor Autorisatie Servers, Resource Servers en mogelijk ook xIS'en onbereikbaar worden.

D

DVA wordt ongemerkt overgenomen door hackers, waardoor voor bestaande subscripties op delen-gegevensdiensten, geldige notificaties worden verzonden, inclusief een assertion. Bescheiden (een kans van 10 % dat het binnen 1 jaar optreedt)

Matig

Datalek: hackers verkrijgen patiëntgegevens van diverse Personen en van diverse DVP's.

C

Mogelijke maatregelen:

  • Automatisch delen van gegevens door DVP niet toestaan.
  • ??
Onopzettelijke fout bij DVA, waardoor per abuis, voor bestaande subscripties op delen-gegevensdiensten, geldige notificaties worden verzonden, inclusief een assertion.Laag (een kans van 5 % dat het binnen 1 jaar optreedt)

Matig

Datalek: DVA verkrijgt, zonder geldige grondslag,  patiëntgegevens van diverse Personen en van diverse DVP's.

D

Bijlagen

No files shared here yet.

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

  • No labels