Businesslaag

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

De totale procesgang van de UC 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 ontvangt de Persoon.
• De Dienstverlener aanbieder vraagt de Persoon om autorisatie.
• Dan breekt het moment aan waarop de Dienstverlener aanbieder op zijn vroegst ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, of anders de happy flow afbreekt. 
• De Dienstverlener aanbieder vraagt aan de Persoon of hij de wens bevestigt de informatie te laten verstrekken aan de Aanbieder. De vraag die hiervoor aan de Persoon gesteld moet worden staat op de pagina Bevestigingsverklaring.
• De Dienstverlener aanbieder logt die bevestiging en laat de Dienstverlener persoon weten of die geslaagd is.
• Voordat de flow dan wordt overgegeven aan de Dienstverlener persoon zal de Dienstverlener aanbieder ervoor instaan dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, of anders de happy flow afbreken.
• 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 tekent bij de informatie ook de meta-informatie aan die wordt bedoeld in verantwoordelijkheid 19 van de Processen- en Informatielaag.

Applicatielaag

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 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.
2. De Persoon maakt expliciet zijn selectie en laat de User Agent een deel-verzoek 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).
3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
4. De Authorization Server vraagt de Persoon via zijn User Agent in te loggen.
5. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow
6. Dan breekt het moment aan waarop de Authorization Server ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst überhaupt ontvankelijk is voor de gezondheidsinformatie van die Persoon, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
7. Na de autorisatie 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.
8. 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.
9. 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.

Het MedMij Afsprakenstelsel adviseert de ontvankelijkheidsvoorwaarde 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.

Bij de implementatie van de toets op ontvankelijkheid van de Aanbieder voor de te delen gezondheidsgegevens is het zaak rekening te houden met privacy-vereisten. Wanneer de Dienstverlener aanbieder ten behoeve van de ontvankelijkheidstoets 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.

Businesslaag

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

De totale procesgang van de UC 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 ontvangt de Persoon.
• De Dienstverlener aanbieder laat de Persoon zich authenticeren.
• Wanneer de Persoon de authenticatie heeft afgebroken geeft de Dienstverlener aanbieder de mogelijkheid alsnog te authenticeren of de flow af te breken.
• Dan breekt het moment aan waarop de Dienstverlener aanbieder op zijn vroegst ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de ontvankelijkheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. Vooralsnog staat het MedMij Afsprakenstelsel het toe die voorwaarde op een later moment van kracht te laten zijn, maar niet later dan het laatste in het figuur aangegeven moment.
• De Dienstverlener aanbieder vraagt aan de Persoon of hij de wens bevestigt de informatie te laten verstrekken aan de Aanbieder. De vraag die hiervoor aan de Persoon gesteld moet worden staat op de pagina Bevestigingsverklaring.
• De Dienstverlener aanbieder logt die bevestiging en laat de Dienstverlener persoon weten of die geslaagd is.
• Voordat de flow dan wordt overgegeven aan de Dienstverlener persoon zal de Dienstverlener aanbieder ervoor instaan dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, of anders de happy flow afbreken.
• 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 tekent bij de informatie ook de meta-informatie aan die wordt bedoeld in verantwoordelijkheid 19 van de Processen- en Informatielaag.

De ontvankelijkheidsvoorwaarde is een aspect van de regie, niet van de uitwisseling. De voorwaarde geeft de Aanbieder ruimte om deel te nemen in aan de Persoon gegeven regie. Omdat echter bestaande implementatie-architecturen veelal uitwisseling centraal zetten, en niet regie, hebben zij moeite de beschikbaarheidsvoorwaarde in de regiefase te implementeren. Daarom biedt het MedMij Afsprakenstelsel vooralsnog de gelegenheid om deze in de uitwisselingsfase te implementeren. Deelnemers wordt echter aangeraden om, met het oog op de toekomst, in hun implementatie-architecturen een passend onderscheid tussen regie en uitwisseling te maken en de eerste geleding de tweede te laten sturen.

Applicatielaag

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 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.
2. De Persoon maakt expliciet zijn selectie en laat de User Agent een deel-verzoek 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).
3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
4. De Authorization Server vraagt de Persoon via zijn User Agent in te loggen.
5. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow
6. Dan breekt het moment aan waarop de Authorization Server ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst überhaupt ontvankelijk is voor de gezondheidsinformatie van die Persoon, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
7. Na de autorisatie 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.
8. 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.
9. 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.

Het MedMij Afsprakenstelsel adviseert de ontvankelijkheidsvoorwaarde 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.

Bij de implementatie van de toets op ontvankelijkheid van de Aanbieder voor de te delen gezondheidsgegevens is het zaak rekening te houden met privacy-vereisten. Wanneer de Dienstverlener aanbieder ten behoeve van de ontvankelijkheidstoets 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.