Overzicht rollen, functies en gegevens
Onderstaand diagram toont de centrale functies die vanuit de MedMij Core worden aangeboden, welke rollen verantwoordelijk zijn voor het leveren van deze functies en welke gegevens door de functie geleverd worden.
| Expand |
|---|
Dit diagram toont alleen de verantwoordelijke rol, behorende bij een aangeboden functie. De rollen die de functie gebruiken worden benoemd in de uitwerking van de functie, bijvoorbeeld in de diagrammen. |
...
Om deze twee functies mogelijk te maken biedt Dienstverlener aanbieder ook de volgende twee functies aan de Persoon:
Lijsten
In het MedMij Afsprakenstelsel worden, ten behoeven van de hoofdfunctie Coördinatie, vier lijsten gebruikt voor de interoperabiliteit en het vertrouwen tussen het Persoonsdomein en het Aanbiedersdomein.
...
Beschikbaarheids- en ontvankelijkheidsvoorwaarde
Beschikbaarheid
Binnen de functies Verzamelen en Abonneren (extensie) wordt een beschikbaarheidstoets uitgevoerd. Deze redenen dat de toets uitgevoerd moet worden zijn:
- Dataminimalisatie
Er worden geen gegevens uitgewisseld indien de beschikbaarheidstoets een negatief resultaat heeft. - Gebruiksvriendelijkheid
Het resultaat van de beschikbaarheidstoets wordt met de Persoon gedeeld, indien deze negatief is. Hierdoor weet de Persoon wat er gaande is.
De beschikbaarheidstoets omvat de controle op de aanwezigheid van een behandelrelatie (kent de Aanbieder de Persoon). Daarnaast wordt de leeftijd van de Persoon gecontroleerd en wordt getoetst of de Aanbieder de gewenste gegevens beschikbaar heeft.
De vroege beschikbaarheidstoets (optioneel)
De beschikbaarheidstoets kan optioneel worden uitgevoerd op de authorization interface. Bij de uitvoering van dit proces wordt de Persoon geauthenticeerd, waarna direct de beschikbaarheidstoets kan worden uitgevoerd. Zie voor verdere uitwerking de functie Authenticeren.
De late beschikbaarheidstoets (verplicht)
In de basis wordt in de uitvoering van de functies Verzamelen en Abonneren drie interfaces gebruik:
- Authorization interface;
- Token interface;
- Resource interface.
Bij langdurige toestemming wordt de authorization interface alleen bij het eerste gebruik aangeroepen. Zodra de langdurige toestemming (her)gebruikt wordt, vervalt deze stap. Daarom moet de beschikbaarheidstoets sowieso op een later moment worden uitgevoerd. Dit kan op beide andere interfaces, maar de voorkeur ligt bij de Token interface. De reden hiertoe is dat het aantal aanroepen van de resource interface exponentieel groter kan zijn dan het aantal aanroepen van de token interface. Dit kan de performance van de resource interface schaden.
Ontvankelijkheid
De ontvankelijkheidstoets lijkt voor een groot deel op die van de beschikbaarheidstoets. Net als bij de beschikbaarheidstoets wordt de aanwezigheid van een behandelrelatie gecontroleerd en wat de leeftijd van de Persoon is. Er wordt echter niet getoetst of de Aanbieder gegevens beschikbaar heeft, maar of de Aanbieder openstaat gegevens te ontvangen. Ook hierbij kunnen twee varianten uitgevoerd worden, namelijk een vroege en een late variant. De vroege variant is hetzelfde als de vroege variant van de beschikbaarheidstoets. De late variant wijkt echter af.
De late variant van de ontvankelijkheidstoets kan alleen op de token interface uitgevoerd worden, omdat bij het gebruik van de resource interface binnen de functie delen direct worden gegevens uitgewisseld. Vanuit dataminimalisatie is dit een ongewenste situatie, waardoor het uitvoeren van de ontvankelijkheidstoets al op de Authorization of token interface verplicht is.
| Note |
|---|
Let op: In versie 2.0.0 wijken de moment voor het uitvoeren van de ontvankelijkheidstoets of van de momenten voor het uitvoeren van de beschikbaarheidstoets. In een volgende versie wordt dit gelijk getrokken, waardoor het uitvoeren van de ontvankelijkheidstoets op het token endpoint verplicht wordt. Het uitvoeren van beide toetsen op het Authorization endpoint is deprecated. |
Hieronder worden de vroege en de late variant vergeleken vanuit de perspectieven van dataminimalisatie en gebruiksvriendelijkheid. Beide aspecten moeten vanuit het perspectief van de gehele functie en alle betrokken rollen beschouwd worden: een keuze tussen de vroege en de late variant heeft effecten op meerdere plaatsen tegelijk. De afweging onderscheidt vier situaties, afhankelijk van twee vragen:
Acht de Aanbieder(zich voor) de informatie (uiteindelijk) beschikbaar/ontvankelijk?Geeft de Persoon (uiteindelijk) toestemming?
De late varianten verschillen overigens subtiel tussen zowel de functies Verzamelen en Delen. In Delen is de late variant in vergelijking nog een stap vroeger dan in de functie Verzamelen. Dat komt omdat anders een verwerking (namelijk: plaatsing) van gezondheidsinformatie zou gebeuren door de Resource Server nog voordat zou blijken dat de Aanbieder hiervoor niet ontvankelijk is. In de functie Verzamelen kan het een stapje later, omdat de te voorkomen actie pas de uitwisseling met de DVP Server is.
De twee varianten laten zich als volgt vergelijken inzake dataminimalisatie.
|
| |
|
De twee varianten laten zich als volgt vergelijken inzake gebruiksvriendelijkheid.
|
| |
|
De gevallen waarin de Aanbieder (zich voor) de informatie beschikbaar/ontvankelijk acht zijn, uitgaande van redelijk gedrag van de DVP Server, waarschijnlijk talrijker dan die waarin dat niet het geval is. Anderzijds wegen de nadelen van de vroege variant voor eerstgenoemde gevallen licht, omdat het zorgaanbiedersdomein en de Authorization Server om andere redenen al afdoende beveiligd moeten zijn, al is het maar vanwege het gebruik van het BSN. Bovendien is er alleen sprake van extra verkeer voor zover geautomatiseerde logica wordt ingezet en daarvoor rollen anders dan de Authorization Server, en dus buiten het MedMij Afsprakenstelsel, worden aangesproken.
...
In deze release adviseert het MedMij Afsprakenstelsel daarom de vroege variant, vanwege bovengenoemde analyse. Het MedMij Afsprakenstelsel staat echter ook de late variant toe, om Dienstverleners aanbieder zowel de gelegenheid te geven snel aan te sluiten als de tijd om te overwegen hoe de vroege variant op termijn geïmplementeerd zou kunnen worden.
In geval van langdurige toestemming zal de beschikbaarheidsoets altijd op het late moment (Resource Server) plaatsvinden
Ontvankelijkheid
...
.