Inleiding

Op deze pagina staan de diagrammen behorende bij de functie Delen. De functie is een spiegelbeeld van de functie Verzamelen. Daarom is er een aantal wezenlijke verschillen. Op het niveau van de functie zijn dat de volgende:

Voor de start van de functie zou de Persoon moeten kunnen volstaan met het aanwijzen van die informatie in zijn Dossier die hij zou willen delen met een nader te benoemen Persoon, en er daarbij vanuit mogen gaan dat de Dienstverlener persoon daarbij weet welke Gegevensdienst daarbij aan de orde is.
In tegenstelling tot in de functie Verzamelen moet de Aanbieder in de gelegenheid worden gesteld om zich al dan niet open te stellen voor ontvangst van de betreffende informatie. De Dienstverlener aanbieder moet na authenticatie van de Persoon kunnen bepalen of de betreffende informatie welkom is bij de betreffende Aanbieder. Deze controle op de ontvankelijkheid zal geautomatiseerd plaatsvinden, met het oog op de synchrone gebruikservaring, maar de wijze van implementatie wordt vrijgelaten.
Juridisch gezien is er geen expliciete toestemming van de Persoon vereist aan de Aanbieder voor het mogen ontvangen van de gezondheidsinformatie; die volgt uit de verstrekking door de Persoon. Er zijn wel toestemmingsvereisten in de relatie Persoon-Dienstverlener persoon (inzake het mogen verstrekken van de gezondheidsinformatie), maar daarop ziet reguliere wet- en regelgeving toe. Niettemin wordt er, net als in de functie Verzamelen, om een bevestiging gevraagd van de Persoon.
Aan het eind van de functie wordt, indien de Aanbieder ervoor ontvankelijk bleek, de betreffende informatie door de Dienstverlener persoon geplaatst bij de Aanbieder, via de Dienstverlener aanbieder. Net zoals dat er in de functie Verzamelen geen nadere eisen worden gesteld aan hoe het ophalen van de informatie door de Dienstverlener aanbieder bij de Aanbieder geschiedt, geldt dat in de functie Delen ook voor de plaatsing. Van belang is slechts dat de Persoon ervan kan uitgaan dat de Aanbieder kennis kan hebben genomen van de betreffende informatie. Hoe dat wordt geborgd is niet triviaal, maar wordt gelaten aan de voorzieningen die de Dienstverlener aanbieder treft en de Dienstverleningsovereenkomst die hij dienaangaande aangaat met de Aanbieder.

In de platen hieronder staat het diagram van de functie Delen. De diagrammen tonen alleen de situatie waarin alle acties slagen tot en met het uiteindelijke delen van de gezondheidsinformatie (de zogenaamde happy flow). 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 het proces Delen kent de volgende stappen:

De Dienstverlener persoon presenteert aan de Persoon de mogelijkheid om te delen.
De Persoon kiest de Aanbieder waarmee hij de informatie wenst te delen en de Gegevensdienst. Daarvoor kunnen desgewenst de Gegevensdienstnamen worden gebruikt uit de Gegevensdienstnamenlijst. Het verzoek gaat naar de passende Dienstverlener aanbieder.
De Dienstverlener aanbieder start het autorisatieproces.
De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.
Nu kan de Dienstverlener persoon de gezondheidsinformatie plaatsen bij de Dienstverlener aanbieder.
Mocht de Gegevensdienst waartoe de Persoon heeft geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), plaatst de Dienstverlener persoon daarna mogelijk opnieuw bij de Dienstverlener aanbieder voor de nog resterende Transacties, eventueel na nieuwe interactie met de Persoon.
De Dienstverlener persoon bewaart ook de meta-informatie die wordt bedoeld in verantwoordelijkheid core.logging.100 en core.logging.101.

Uitzonderingen op de Happy flow van de functie Delen

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 (al) bevestiging is gegeven door de Dienstverlener persoon.

nr.	uitzondering	actie	vervolg
Delen 1	Dienstverlener aanbieder vindt het ontvangen verzoek ongeldig.	Dienstverlener aanbieder informeert Persoon hierover.	Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Delen 2	Dienstverlener persoon kan, zelfs na bevestiging, de gezondheidsinformatie alsnog niet plaatsen bij Dienstverlener aanbieder.	Dienstverlener persoon informeert daarop Persoon hierover, met opgave van oorzaak.	Mocht gezondheidsinformatie deels wel (geautoriseerd) geplaatst kunnen worden, 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 een bepaalde Gegevensdienst met een zekere Aanbieder te delen. Het gaat altijd om precies één Gegevensdienst (één scope, in OAuth-termen). Uit de Aanbiederslijst weet de DVP Server welke Gegevensdiensten door een Aanbieder aangeboden worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
De Persoon maakt expliciet zijn selectie en laat de User Agent een deel-verzoek sturen naar de Authorization Server.
De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon. Tijdens dit proces wordt, in deze versie van het afsprakenstelsel, ook de ontvankelijkheidstoets uitgevoerd.
Nu is de DVP Server gereed om de gezondheidsinformatie aan de Resource Server aan te bieden, nadat hij de gebruiker eventueel nog nadere keuzes heeft laten maken. 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.
De Resource Server controleert of het ontvangen token recht geeft op het aanbieden van de informatie, plaatst deze (al dan niet) bij achterliggende bestemmingen en verstuurt een antwoord in een FHIR-response naar de DVP Server.
Deze maakt hierover een aantekeningen bij de aangeboden gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Persoon heeft geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), plaatst de DVP Server daarna mogelijk opnieuw bij de Resource Server voor de nog resterende Transacties, eventueel na nieuwe interactie met de Persoon. Dat geldt ook voor de situatie waarin één Transactie, blijkens de betreffende Informatiestandaard, uit meerdere FHIR creates bestaat. Zolang het access token geldig is, kan dat.

In de regel worden bij een eenmalig gebruik van de functie Delen 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.

Browser not supported