Skip to end of metadata Go to start of metadata

Inleiding

Op deze pagina staan de diagrammen behorende bij de functie Verzamelen. De oranje banen horen (conform de MedMij-huisstijl) tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein.

Businesslaag

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

De totale procesgang van de functie Verzamelen kent de volgende stappen:

De Persoon kiest expliciet de Aanbieder, waarbij hij de informatie wenst te verzamelen, en de specifieke Gegevensdienst(en) uit de lijst die door Dienstverlener persoon wordt aangeboden. Het verzoek gaat naar de passende Dienstverlener aanbieder. Indien de Aanbieder gebruik maakt van meerdere Dienstverlener Aanbieders, moet dit kenbaar genaakt worden aan de Persoon en zal de flow per Dienstverlener Aanbieder doorlopen moeten worden .
De Dienstverlener aanbieder ontvangt een verzoek van de Persoon.
De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.
Uiterlijk na de ontvangst van het verzoek zal de Dienstverlener aanbieder ervoor instaan dat de Aanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
Bij ontvangst slaat de Dienstverlener persoon die informatie op in het persoonlijke dossier.
Mocht een Gegevensdienst waartoe de Dienstverlener persoon is geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), dan bevraagt de Dienstverlener persoon de Dienstverlener aanbieder daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe interactie met de Persoon. Hetzelfde geldt wanneer de Dienstverlener persoon is geautoriseerd voor meerdere Gegevensdiensten van de betreffende Aanbieder.
Bij de informatie wordt ook de meta-informatie opgeslagen die wordt bedoeld in verantwoordelijkheid core.logging.100 en core.logging.101.

Uitzonderingen op de Happy flow van de functie Verzamelen

In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt. Ten alle tijden moet voorkomen worden dat de Dienstverlener persoon informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven.

Op de Applicatielaag zullen, bij de implementatie van Verzamelen, deze uitzonderingen opnieuw ter sprake komen, maar nu ook met hun precieze implementatie en formaat van de foutmeldingen.

nr.

uitzondering

actie

vervolg

Verzamelen 1

Dienstverlener aanbieder vindt een ontvangen verzoek ongeldig.

Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover.

Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

Verzamelen 2

Dienstverlener aanbieder stelt op enig moment vast dat van Persoon bij Aanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is. Hiervan is in elk geval sprake indien hetzij:

er geen behandelrelatie is aan te wijzen als grondslag voor het verzamelen;
Persoon nog geen zestien jaar oud is.

Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Dienstverlener aanbieder informeert Dienstverlener persoon dat verzoek niet wordt ingewilligd.

Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

Verzamelen 3

Dienstverlener aanbieder kan, zelfs na autorisatie, de gezondheidsinformatie alsnog niet ter beschikking stellen aan de Dienstverlener persoon.

Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover, met opgave van oorzaak.

Mocht de gezondheidsinformatie deels wel (geautoriseerd) ter beschikking staan, dan kan de flow dat nog verzorgen.

Applicatielaag

Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.

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:

De DVP Server start de flow door in de User Agent van de Persoon de mogelijkheid te presenteren om één of meerdere Gegevensdiensten gegevens bij een zekere Aanbieder te verzamelen. Uit de Aanbiederslijst weet de DVP Server welke Gegevensdiensten door een Aanbieder aangeboden worden en of de Aanbieder gebruik maakt van één of meerdere DVA's. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
De Persoon maakt expliciet zijn selectie van Aanbieder en laat de User Agent een authorization request sturen naar de Authorization Server. Het adres van het authorization endpoint komt uit de Aanbiederslijst. De redirect_uri geeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization-code). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten. Binnen het autorisatieproces valt ook het eerst mogelijke moment waarop de Dienstverlener aanbieder moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft.
Nadat de Dienstverlener aanbieder een autorisatie heeft afgegeven aan de Dienstverlener persoon is de DVP Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen, ~~nadat hij de Persoon eventueel nog nadere keuzes heeft laten maken~~. Het adres van de juiste resource endpoints haalt hij uit de Aanbiederslijst. Hij plaatst telkens het access-token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en verleent autorisatie aan de Resource Server. ~~haalt deze (al dan niet) bij achterliggende bronnen op~~. Dan breekt het tweede en laatst mogelijke verplichte moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze in een resource response naar de DVP Server.
De DVP Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. De DVP Server bevraagt de Resource Server daarna mogelijk opnieuw, eventueel na nieuwe interactie met de Persoon. Zolang het access-token geldig is, kan dat.

In de regel worden bij een eenmalig gebruik van Verzamelen het authorization interface, het token interface en het resource interface allemaal aangesproken, in die volgorde. Mocht de DVP Server echter nog beschikken over een nog niet verlopen access-token voor de betreffende Aanbieder-Gegevensdienst-combinatie, dan kan het onmiddellijk het resource interface aanspreken. Bij het aanwezig zijn van een geldig refresh-token kan de DVP Server deze direct inruilen voor een access-token en hoeft de authorization interface niet aangeroepen te worden.

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

Browser not supported