Page tree
Skip to end of metadata
Go to start of metadata

Toelichting

In de platen hieronder staat het stroomdiagram van de use case-implementatie Verzamelen, in vier perspectieven:

  • het totaalperspectief, met zowel de happy flow als de uitzonderingen;
  • het perspectief van de PGO Server (= OAuth Client), die onder de hoede van de Dienstverlener Persoon valt. Voor zover laatstgenoemde deelnemer is in het MedMij Afsprakenstelsel, kan deze dus deze plaat lezen als zijn verplichte aandeel in de use case-implementatie Verzamelen;
  • het perspectief van de (OAuth) Authorization Server/(OAuth) Resource Server/ SAML Service Provider, die onder de hoede van de Dienstverlener Zorgaanbieder valt. Voor zover laatstgenoemde deelnemer is in het MedMij Afsprakenstelsel, kan deze dus deze plaat lezen als zijn verplichte aandeel in de use case-implementatie Verzamelen;
  • het perspectief van de Zorggebruiker (= OAuth Resource Owner).

De stroomdiagrammen tonen alleen de situatie waarin alle acties slagen tot en met het uiteindelijke verzamelen van de gezondheidsinformatie (de zogenaamde happy flow). De drie oranje banen horen, conform de MedMij-huisstijl tot het Persoonsdomein, de twee blauwe tot het Zorgaanbiedersdomein. Menige actie in de stroomdiagrammen is gekleurd weergegeven. De lichtgrijs gekleurde acties vormen samen de autorisatieflow volgens OAuth 2; de zachtgeel gekleurde acties vormen samen de authenticatieflow volgens DigiD/SAML. Deze kleuren verwijzen dus alleen maar naar de gebruikte standaarden en zeggen niets over welke component de stap zou moeten uitvoeren. Authenticatie is dus ingebed in autorisatie. In de stroomdiagrammen voor de specifieke perspectieven hebben alleen de acties in de bij dat perspectief horende baan namen. De acties in de andere banen zijn gecomprimeerd en anoniem weergegeven.

Verantwoordelijkheden inzake de gegevens die omgaan in deze use case-implementatie zijn, samen met die van UCI Delen, opgenomen in een aparte pagina.

Totaalperspectief

Happy flow

Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. In release 1.1.1 staat het MedMij Afsprakenstelsel toe die voorwaarde op een later moment van kracht te laten zijn, maar niet later dan het laatste in het figuur aangegeven moment.

Toelichting

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.

De flow kent de volgende stappen:

  1. De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om een bepaalde Gegevensdienst bij een zekere Zorgaanbieder te verzamelen. Het gaat altijd om precies één Gegevensdienst (één scope, in OAuth-termen). Uit de Zorgaanbiederslijst weet de PGO Server welke Gegevensdiensten door een Zorgaanbieder aangeboden worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
  2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een verzamel-verzoek sturen naar de Authorization Server . Het adres van het authorization endpoint komt uit de ZAL. De redirect URI geeft aan waarnaartoe de Authorization Server de OAuth User Agent verderop moet redirecten (met de authorization code).
  3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  4. Dan start de Authorization Server (nu in de rol van SAML Service Provider) de SAML-flow door de browser naar DigiD te redirecten, onder meegeven van een redirect URI, die aangeeft waarnaartoe DigiD straks de OAuth User Agent moet terugsturen, na het inloggen van de Zorggebruiker.
  5. DigiD vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.
  6. Wanneer deze juist zijn, redirect DigiD de OAuth User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs: het SAML-artefact.
  7. Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij DigiD het BSN op.
  8. Dan breekt het vroegste moment aan waarop de Authorization Server ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn. Zie een aparte pagina voor een uitgebreide toelichting.
  9. Zo ja, dan presenteert de Authorization Server via de PGO Presenter aan Zorggebruiker de vraag of laatstgenoemde hem toestaat de gevraagde persoonlijke gezondheidsinformatie aan de PGO Server (als OAuth Client) te sturen. Onder het flow-diagram staat gespecificeerd welke informatie, waarvandaan, de OAuth Authorization Server verwerkt in de aan Zorggebruiker voor te leggen autorisatievraag.
  10. Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een browser redirect met de in stap 1 ontvangen redirect URI, naar de PGO Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in de eerste stap van de PGO Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren.
  11. De PGO Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de toestemming is gegeven en logt het verkrijgen van het ophaalbewijs.
  12. Met dit ophaalbewijs wendt de PGO Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de OAuth User Agent, voor een access token.
  13. Daarop genereert de Authorization Server een access token en stuurt deze naar de PGO Server.
  14. Nu is de PGO Server gereed om het verzoek om de gezondheidsinformatie naar de Resource Server te sturen. Het adres van het resource endpoint haalt hij uit de ZAL. Hij plaatst het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
  15. De Resource Server controleert of het ontvangen token recht geeft op de gevraagde resources, haalt deze (al dan niet) bij achterliggende bronnen op. Dan breekt het uiterste moment aan waarop de Resource Server ervoor moet instaan dat voor de betreffende Gegevensdienst de Zorgaanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze ze in een FHIR-response naar de PGO Server. Is dat niet zo, dan breekt de Resource Server de happy flow af.
  16. Deze bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere Transacties bestaan, bevraagt de PGO Server de Resource Server daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe gebruikersinteractie. Zolang het access token geldig is, kan dat.

Bij de implementatie van de voorwaarde op beschikbaarheid bij de Zorgaanbieder voor de te verzamelen gezondheidsgegevens is het zaak rekening te houden met privacy-vereisten. Wanneer de Dienstverlener Zorgaanbieder ten behoeve van de beschikbaarheidsvoorwaarde nieuwe gegevensverzamelingen zou aanleggen, vindt een verwerking altijd onder de verantwoordelijkheid van één Zorgaanbieder plaats. Het combineren van verwerkingen of het onvoldoende segregeren moet worden vermeden. Afwijking hiervan is alleen mogelijk onder expliciete instructie van de Zorgaanbieder(s) en vereist een zorgvuldige voorafgaande afweging, vanwege de daaraan verbonden privacyrisico's.

Uitzonderingen

Toelichting

In onderstaande tabel staan de uitzonderingssituaties beschreven. Zij kunnen gezien worden als de implementatie-tegenhangers van de uitzonderingen van de use case Verzamelen. Alle uitzonderingen worden door de Authorization Server of de Resource Server ontdekt. In deze versie van het MedMij Afsprakenstelsel is bepaald dat zij altijd leiden tot het zo snel mogelijk afbreken van de flow door alle betrokken rollen. Daartoe moeten echter eerst nog de andere rollen geïnformeerd worden. Om te voorkomen dat de PGO Server informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven, moet het onderscheid tussen de uitzonderingen 2, 3 en 4 niet te maken zijn door de PGO Server.

Deze tabel bevat alleen die uitzonderingssituaties ten aanzien waarvan het MedMij afsprakenstelsel eigen eisen stelt aan de implementatie. In de specificatie van OAuth 2.0 staan daarnaast nog generiekere uitzonderingssituaties, zoals de situatie waarin de redirect URI ongeldig blijkt. Ook deze uitzonderingssituaties moeten geïmplementeerd worden.

NummerImplementeert uitzonderingUitzonderingActieMeldingVervolg
UCI Verzamelen 1UC Verzamelen 1Authorization Server vindt het ontvangen verzoek ongeldig.Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Zorggebruiker daarover.

conform OAuth 2.0-specificatie, par. 4.1.2.1, error code invalid_request, met in de error description de oorzaak

Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
UCI Verzamelen 2UC Verzamelen 2Authorization Server kan de identiteit van de Zorggebruiker niet vaststellen. Authorization Server  informeert  PGO Server  over deze uitzondering. PGO Server informeert Zorggebruiker dat diens verzoek geen voortgang kan vinden, maar laat de oorzaak daarvan helemaal in het midden.conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Access denied."Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
UCI Verzamelen 3UC Verzamelen 3

Authorization Server stelt op enig moment vast dat van Persoon bij Zorgaanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is.

Zie een aparte pagina voor een uitgebreide toelichting.

UCI Verzamelen 4UC Verzamelen 4De autorisatievraag wordt ontkennend beantwoord.
UCI Verzamelen 5UC Verzamelen 5Authorization Server kan de autorisatie niet vaststellen.Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover.conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Authorization failed."Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
UCI Verzamelen 6UC Verzamelen 6De validatie van de authorization code door Authorization Server faalt.Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover.conform OAuth 2.0-specificatie, par. 5.2, error code invalid_grantAllen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
UCI Verzamelen 7UC Verzamelen 6De validatie van het access token door Resource Server faalt.Resource Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover.conform FHIR-specificatie, in de FHIR-response, issue type security/suppressedAllen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
UCI Verzamelen 8UC Verzamelen 5Resource Server kan de gevraagde informatie niet of niet tijdig ophalen bij achterliggende systemen.Resource Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover.conform FHIR-specificatie, in de FHIR-response, issue type processing/incompleteAllen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

Specifieke perspectieven

Perspectief PGO Server (happy flow)

Toelichting

Hieronder staat hetzelfde stroomdiagram, maar vanuit het perspectief van de PGO Server. Dat wil zeggen dat alle tussenliggende stappen die niet zichtbaar zijn voor de PGO Server, kortgesloten zijn. Zorggebruiker is "verborgen achter de browser" en DigiD "achter de Authorization Server".

Perspectief Authorization Server/Resource Server (happy flow)

Toelichting

Hieronder staat hetzelfde stroomdiagram, maar vanuit het perspectief van de Authorization/Resource Server. Dat wil zeggen dat alle tussenliggende stappen die niet zichtbaar zijn voor de PGO Server, kortgesloten zijn. Zorggebruiker is "verborgen achter de browser".

Perspectief Zorggebruiker (happy flow)

Toelichting

Hieronder staat hetzelfde stroomdiagram, maar vanuit het perspectief van de Zorggebruiker. Dat wil zeggen dat alle tussenliggende stappen die niet zichtbaar zijn voor de Zorggebruiker, kortgesloten zijn. Vrijwel alles is "verborgen achter de browser". We hebben alleen de laatste stap van PGO Server zichtbaar gehouden, omdat het bewaren van de verzamelde gezondheidsinformatie betekenis heeft voor de Zorggebruiker. Waarschijnlijk zal de PGO Server de Zorggebruiker laten weten dat het verzamelen geslaagd is, maar dat is niet verplicht.

Frontchannel en backchannel

Toelichting

In onderstaand stroomschema van UCI Verzamelen geven de dikke pijlen het MedMij-verkeer weer en zijn daarbinnen de vijf gevallen van frontchannel-verkeer (open pijlpunt) en vier gevallen van backchannel-verkeer (gesloten pijlpunt) aangegeven.

  • No labels