/
.Functies en gegevens, Core v1.6.0_202303

In ontwikkeling

.Functies en gegevens, Core v1.6.0_202303

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.

 Toelichting

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.

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 is, 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

afkortingwordt opgehaald en gebruikt doorinformatie-inhoud
Dienstverlener Persoon
Dienstverlener Aanbieder
AanbiederslijstZALX
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 ListOCL
Xde 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
GegevensdienstnamenlijstGNLXXde gebruiksvriendelijke namen van Gegevensdiensten
WhitelistWHLXXwelke 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
  • Voor zover er aparte geautoma­ti­seerde logica worden ge­bruikt voor een toets op beschikbaarheid of ontvankelijkheid vraagt de vroege variant ex­tra ver­keer ten opzichte van de late variant, namelijk tussen Autho­ri­zation Ser­ver en de com­ponent-(en) die zij voor het uitvoe­ren van die toets aan­spreekt. Dat ver­keer 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 behandel­relatie en leef­tijd 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 au­thenti­catie (de toe­stem­mingsvraag, het uit­de­len van authoriza­tion code en ac­cess to­ken en het aan­spreken van de Resour­ce Ser­ver) 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