(1.6.0F) Functies en gegevens, Core
Inleiding
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. 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 functies door de Dienstverlener persoon zelf zijn in te vullen, 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.106. Dienstverlener aanbieder biedt aan Dienstverlener persoon twee functies: 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.Â
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 |
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 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 (uiteinÂdelijk) beschikbaar/ontvankelijk?
- Geeft de Persoon (uiteindeÂlijk) 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.
(uiteindelijk) wel beschikbaar/ontvankelijk | (uiteindelijk) niet beschikbaar/ontvankelijk | |
---|---|---|
(uiteindelijk) wel toestemming |
|
|
(uiteindeÂlijk) geen toestemming | In de late variant vindt, in tegenstelling tot in de vroege, een overbodige toeÂstemmingsvraag plaats. Dit verkeer vindt plaats over het relatief onveilige frontchannel. |
De twee varianten laten zich als volgt vergelijken inzake gebruiksvriendelijkheid.
(uiteindelijk) wel beschikbaar/ontvankelijk | (uiteindelijk) niet beschikbaar/ontvankelijk | |
---|---|---|
(uiteindelijk) wel toestemming | geen verschil | In de vroege variant is de Persoon onmiddellijk op de hoogte, zodat deze:
|
(uiteindelijk) geen toestemming | 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/ontvanÂkelijk 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 zoÂver 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.