| Table of Contents | ||
|---|---|---|
|
Inleiding
| Excerpt | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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.
MedMij Beheer is verantwoordelijk voor de levering van de functies rondom de te gebruiken lijsten en het register. Hierbij gaat het om:
Omdat een Persoon de regie voert over de eigen gezondheidsgegevens, moet een Dienstverlener persoon de gegevens beschikbaar stellen. Dit gebeurt vanuit de functie Raadplegen Dossier. Om de regie van de Persoon verder te ondersteunen, moet een Dienstverlener persoon de functie Verwijderen Gegevens beschikbaar stellen. Dit betreft minimaal het verwijderen van gezondheidsgegevens die via de MedMij functie Verzamelen zijn toegevoegd. Omdat deze functie functies door de Dienstverlener persoon zelf zijn in te vullen is, staat zijn deze niet verder uitgewerkt in het afsprakenstelsel. Hierbij moet wel voldaan worden aan de verantwoordelijkheden core.dossier.103, core.dossier.104, core.dossier.105 en core.dossier.104106. Dienstverlener aanbieder biedt aan Dienstverlener persoon twee functies, namelijk: Dienstverlener aanbieder biedt aan de Persoon een functie welke alleen via Dienstverleners persoon gestart kan worden: Om deze drie 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. . Daarnaast levert MedMij een publiek toegankelijk Aanbiedersregister.
...
lijst | afkorting | wordt opgehaald en gebruikt door | informatie-inhoud | |
|---|---|---|---|---|
| Dienstverlener Persoon | Dienstverlener Aanbieder | |||
| Aanbiederslijst | ZAL | X | welke Aanbieders welke Gegevensdiensten aanbieden, en eventueel ook Abonnementen daarop, en op welke adressen zij die laten laten ontsluiten, gegeven een zekere Interfaceversie | |
| OAuth Client List | OCL | X | de namen van Dienstverlener persoon, welke Gegevensdiensten zij mogen gebruiken en naar welke adressen mogelijk Notificaties in het kader van Abonnementen op die Gegevensdiensten kunnen worden gestuurd, gegeven een zekere Interfaceversie | |
| Gegevensdienstnamenlijst | GNL | X | X | de gebruiksvriendelijke namen van Gegevensdiensten |
| Whitelist | WHL | X | X | welke Nodes actief mogen zijn op het MedMij-netwerk |
Aanbiedersregister
| ||||
...
| REG | Een publiek toegankelijk register van Aanbieders, de door hen geleverde gegevensdiensten en extra informatie zoals uitwisselingsstatus. Dit register is voor mensen eenvoudig leesbaar. Het register is gebaseerd op technische broninformatie uit achterliggende systemen. |
Beschikbaarheids- en ontvankelijkheidsvoorwaarde
Beschikbaarheids- en ontvankelijkheidsvoorwaarde
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 usecase 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:
...
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.
...
- Voor zover er aparte geautomatiseerde logica worden gebruikt voor een toets op beschikbaarheid of ontvankelijkheid vraagt de vroege variant extra verkeer ten opzichte van de late variant, namelijk tussen Authorization Server en de component-(en) die zij voor het uitvoeren van die toets aanspreekt. Dat verkeer speelt zich wel geheel binnen de verantwoordelijkheid van een enkele verwerkingsverantwoordelijke af; er vindt geen verstrekking plaats.
- De Authorization Server komt alleen in de vroege variant extra te weten dat behandelrelatie en leeftijd in orde zijn. In de late variant komt alleen de Resource Server dat te weten. Dat laat onverlet dat beide onder dezelfde eindverantwoordelijke Dienstverlener aanbieder vallen.
...
- In de late variant vindt, in tegenstelling tot in de vroege, al het verkeer na de authenticatie (de toestemmingsvraag, het uitdelen van authorization code en access token en het aanspreken van de Resource Server) onnodig plaats. Dit verkeer strekt zich uit over verantwoordelijkheidsgrenzen.
- In de late variant krijgt de DVP Server, onnodig, meer over de beschikbaarheid/ontvankelijkheid, en dus over de Persoon, te weten van de Resource Server dan in de vroege variant van de Authorization Server. In de vroege variant kan de betreffende uitzondering immers, vanuit de DVP Server bezien, ook door falende authenticatie of weigering van toestemming veroorzaakt zijn. In de late variant komt de DVP Server echter wel te weten, door het ontvangen van de onnodige authorization code, dat er sprake is van zowel een behandelrelatie als een toereikende leeftijd.
...
In de late variant vindt, in tegenstelling tot in de vroege, een overbodige toestemmingsvraag plaats. Dit verkeer vindt plaats over het relatief onveilige frontchannel.
De twee varianten laten zich als volgt vergelijken inzake gebruiksvriendelijkheid.
...
geen verschil
...
In de vroege variant is de Persoon onmiddellijk op de hoogte, zodat deze:
- geen onnodige en verwarrende handeling (betekenisloze toestemming) met rechtsgevolgen hoeft uit te voeren, zoals in de late variant;
- preciezer dan in de late variant op de hoogte raakt van waarom een uitwisseling faalt. In de late variant kan dat falen andere redenen hebben, zodat de Persoon voor opheldering op ondersteuningsvragen aangewezen zou zijn, die wellicht zelfs aan de Aanbieder gericht worden. In de vroege variant zijn Uitzonderingen 2, 3 en 4 in Verzamelen en Delen weliswaar samengenomen in één melding naar de DVP Server, zodat deze het onderscheid tussen falende authenticatie, falende autorisatie en falende beschikbaarheid/ontvankelijkheid niet kan maken. De Persoon zelf echter kent vanwege zijn/haar voorafgaande rechtstreekse interactie met de Authorization Server het resultaat van de authenticatie en de autorisatie wel, en kan dus alsnog uit deze gecombineerde melding, buiten medeweten van de DVP Server, afleiden of er sprake was van falende beschikbaarheid/toegankelijkheid.
...
In de vroege variant is de Persoon onmiddellijk op de hoogte en hoeft deze geen onnodige en verwarrende handeling (holle afwijzing) uit te voeren, zoals in de late variant.
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.
...
Beschikbaarheid
Binnen de functies Verzamelen en Abonneren (extensie) moet de beschikbaarheidstoets worden uitgevoerd, omdat:
- 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 op een later moment worden uitgevoerd. De voorkeur is dit bij de Token interface te doen. 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 controleert:
- of er een behandelrelatie is;
- leeftijd persoon
Er wordt niet getoetst of de aanbieder gegevens beschikbaar heeft, maar of de Aanbieder openstaat gegevens te ontvangen. Er zijn twee varianten. De vroege variant is hetzelfde als de vroege variant van de beschikbaarheidstoets. 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 gegevens uitgewisseld worden. Vanuit data-minimalisatie is dit een ongewenste situatie, waardoor het uitvoeren van de ontvankelijkheidstoets al op de Authorization of token interface verplicht is.