Epic AF-1219, Verzamelen

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 usecase Verzamelen kent de volgende stappen:

De Dienstverlener persoon presenteert aan de Persoon de mogelijkheid om te verzamelen.
De Persoon kiest expliciet de Aanbieder, waarbij hij de informatie wenst te verzamelen, en de specifieke Gegevensdienst(en). 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 tenminste één van de gevraagde Gegevensdiensten überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. In deze release 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 om een autorisatie.
Nu kan de Dienstverlener persoon de Dienstverlener aanbieder vragen om de gezondheidsinformatie.
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

De beschikbaarheidsvoorwaarde hoort bij Regie, niet bij 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.

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:

De DVP Server start de flow door in de User Agent van de Persoon de mogelijkheid te presenteren om één of meerdere Gegevensdiensten bij een zekere Aanbieder te verzamelen. 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 authorization request sturen naar de Authorization Server.
Na de authentication breekt het vroegste moment aan waarop de Authorization Server ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst(en) ü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.
Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst, of wanneer géén gebruik wordt gemaakt van dit vroegste moment, dan vraagt de Authorization Server via de User Agent aan Persoon om autorisatie.
Indien de autorisatie geregeld is, 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 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 Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze ze 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.

Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. Vooralsnog 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 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.