Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Rollenmodel

Excerpt

Het onderstaande diagram toont de rollen die vanuit de MedMij Core in de verschillende onderwerpen gebruikt worden. De rollen staan uitgewerkt in drie lagen van een Enterprise Architectuur, namelijk Business, Application en Technologie. De rollen in het MedMij Afsprakenstelsel zijn bij elkaar horende setjes verantwoordelijkheden. De rollen kunnen, over de lagen heen, aan elkaar gekoppeld zijn. Een rol gaat gepaard met één of meerdere onderliggende rollen. 

Dat wil zeggen dat een rol in het algemeen wordt ingevuld met één of meer verbonden onderliggende rollen, al-dan-niet op een onderliggende laag. De rolbindingen vormen zo de ruggengraat van de architectuur van het MedMij Afsprakenstelsel.

Drawio
borderfalse
diagramNameMedMij Core, Basis
simpleViewertrue
width600
linksauto
tbstyletop
lboxtrue
diagramWidth1221
revision1

Expand
titleToelichting

In de bovenstaande plaat is allereerst de huisstijl van MedMij aangehouden, zodat

  • oranje staat voor het Persoonsdomein;
  • blauw staat voor het aanbiedersdomein en
  • groen staat voor het MedMij-domein en de MedMij algemene elementen.

De grijze kleur staat voor externe rollen waarvan het MedMij Afsprakenstelsel gebruik maakt.

De verticale lijnen in de architectuur leggen de relatie tussen rollen. De relaties leggen de eindverantwoordelijkheid voor de uitvoering van verantwoordelijkheden bij de hogere rol.


Gegevensuitwisseling

Voor gegevensuitwisseling wordt het eerder getoonde rollenmodel uitgebreid met rollen die voor gegevensuitwisseling van toepassing zijn.

Drawio
borderfalse
diagramNameMedMij Core, Gegevensuitwisseling
simpleViewertrue
width600
linksauto
tbstyletop
lboxtrue
diagramWidth1221
revision1

Roldefinities

Business

  • Anchor
    Eigenaar MedMij
    Eigenaar MedMij
    Eigenaar MedMij

    De rechtspersoon die (eind)verantwoordelijk is voor de ontwikkeling en het beheer van het afsprakenstelsel en de informatiestandaarden die nodig zijn om gegevens in dezelfde taal te kunnen uitwisselen.
  • Anchor
    MedMij Beheer
    MedMij Beheer
    MedMij Beheer

    De rechtspersoon die invulling geeft aan de operationele verantwoordelijkheden in het afsprakenstelsel, zoals het beheren en publiceren van een aanbiederslijst en gegevensdienstnamenlijst.
  • Anchor
    Persoon
    Persoon
    Persoon

    Multiexcerpt include
    MultiExcerptNameb_Persoon
    PageWithExcerpt.Begrippenlijst v1.6.0_202305

  • Anchor
    Deelnemer
    Deelnemer
    Deelnemer

    Multiexcerpt
    MultiExcerptNameDeelnemer

    Een partij die dienstverlening aanbiedt binnen het MedMij Afsprakenstelsel. De Dienstverlener persoon en de Dienstverlener aanbieder zijn Deelnemer in het afsprakenstelsel en daarmee gehouden aan de afspraken, bekrachtigd door het tekenen van een deelnemersovereenkomst.


  • Anchor
    Dienstverlener persoon
    Dienstverlener persoon
    Dienstverlener persoon (DVP)

    Multiexcerpt
    MultiExcerptNameDienstverlener persoon

    Dit betreft een rol in het MedMij Afsprakenstelsel. Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Aanbieder mogelijk maakt via het MedMij Afsprakenstelsel.


  • Anchor
    Dienstverlener aanbieder
    Dienstverlener aanbieder
    Dienstverlener aanbieder (DVA)

    Multiexcerpt
    MultiExcerptNameDienstverlener aanbieder

    Dit betreft een rol in het MedMij Afsprakenstelsel. Levert Diensten aan de Aanbieder gerelateerd aan de uitwisseling tussen Persoon en Aanbieder en committeert zich hiervoor aan de naleving van de afspraken in het MedMij Afsprakenstelsel.


  • Anchor
    Dienstverlener authenticatie
    Dienstverlener authenticatie
    Dienstverlener authenticatie (DVAuthN)

    De Aanbieder is verplicht bij het verstrekken van gegevens vanuit een gezondheidsdossier de identiteit van de persoon te verifiëren, al dan niet aan de hand van het BSN. MedMij gebruikt hiervoor de door het ministerie van Binnenlandse Zaken en Koninkrijksrelaties toegelaten authenticatiemiddelen. Vooralsnog is DigiD het enige toegelaten middel voor dit doel.
  • Anchor
    Aanbieder
    Aanbieder
    Aanbieder

    Aanbieder is de term waarmee een grote diversiteit aan dienstverleners wordt bedoeld, die vanuit hun diensten gezondheidsinformatie kunnen aanbieden en ontvangen.

  • Anchor
    OAuth Resource Owner
    OAuth Resource Owner
    OAuth Resource Owner

    Een OAuth Resource Owner is een Persoon die een OAuth Client autoriseert voor toegang tot een OAuth Resource Server. De toegang is beperkt tot het bereik van de verleende autorisatie.

Applicatie

  • Anchor
    MedMij Registratie
    MedMij Registratie
    MedMij Registratie

    MedMij Registratie is de applicatie voor de administratie van Deelnemers, de gegevensdiensten die worden aangeboden en de endpoints die hierbij horen. Deze informatie wordt uitgegeven in de verschillende lijsten.
  • Anchor
    User Agent
    User Agent
    User Agent

    De applicatie die de Persoon gebruikt om de MedMij functies uit te voeren.
  • Anchor
    DVP Server
    DVP Server
    DVP Server

    De DVP Server verzamelt en deelt gezondheidsgegevens op verzoek van de Persoon en stelt hiermee het Dossier van de Persoon samen.
  • Anchor
    Authorization Server
    Authorization Server
    Authorization Server

    De Authorization Server controleert of de Persoon voor de applicatie toegangsrechten heeft. Als de Persoon toestemming geeft om gegevens uit te wisselen met de DVP Server, dan wordt deze toestemming vastgelegd en voor uitwisseling gecontroleerd.
  • Anchor
    Authentication Server
    Authentication Server
    Authentication Server

    De Authentication Server controleert de identiteit van de Persoon.

  • Anchor
    Resource Client
    Resource Client
    Resource Client

    De Resource Client is de applicatie die toegang nodig heeft tot een Resource Server
  • Anchor
    OAuth Client
    OAuth Client
    OAuth Client

    Een OAuth Client is een Resource Client die gebruik maakt van het OAuth 2.0 raamwerk.
  • Anchor
    Authentication Client
    Authentication Client
    Authentication Client

    Een Authentication Client is een applicatie die gebruik maakt van een Authentication Server om de identiteit van een OAuth Resource Owner vast te stellen.
  • Anchor
    Resource Server
    Resource Server
    Resource Server

    De Resource Server is de applicatie waar gegevens kunnen worden verzameld, of waarmee gegevens gedeeld kunnen worden.
  • Anchor
    OAuth Resource Server
    OAuth Resource Server
    OAuth Resource Server

    Een OAuth Resource Server is een Resource Server die gebruik maakt van het OAuth 2.0 raamwerk.

Technologie

  • Anchor
    Frontchannel Node
    Frontchannel Node
    Frontchannel Node
    Een Frontchannel Node communiceert met de User Agent van de Persoon, waarbij de communicatie internet facing is. De rol van User Agent wordt hierbij ingevuld door een webbrowser.
  • Anchor
    Backchannel Node
    Backchannel Node
    Backchannel Node

    Een Backchannel Node communiceert met andere backchannel nodes, waarbij identificatie geschied door gebruik te maken van de verschillende lijsten die door MedMij Registratie worden geboden.
     

Persoonsdomein

Business

In het Persoonsdomein is er naast de rol Dienstverlener persoon ook de rol Persoon. Hoewel Dienstverlener persoonnamens Persoonhandelt, kan Persoon niet ongenoemd blijven in de afspraken op deze en onderliggende lagen. Dat komt doordat Persoon niet enkel de gebruiker van Dienstverlener persoonis, maar allereerst het onderwerp van de gezondheidsinformatie die Deelnemers ter beschikking moet stellen; daarvoor is authenticatie en autorisatie nodig. In de architectuur van het afsprakenstelsel heeft Persoon een operationele rol bij authenticatie en autorisatie van het gegevensverkeer.

Application

In het persoonsdomein zijn twee rollen onderscheiden: de User Agent en de DVP Server. Dat is nodig om de verbinding te kunnen leggen met de rollen volgens OAuth. User Agent is de front-end-rol voor de DVP Server, en kan bijvoorbeeld in een browser zijn geïmplementeerd. Zoals ook elders in het MedMij Afsprakenstelsel gaat het hier om rollen, om setjes verantwoordelijkheden dus, niet om implementatiecomponenten.

Aanbiedersdomein

Business

In het Aanbiedersdomein is er naast de rol Dienstverlener aanbieder ook de rol Aanbieder. Deze rol wordt operationeel geheel vertegenwoordigd door de Dienstverlener aanbieder.

Application

Waar een Persoon zelf operationeel betrokken wordt in het informatieverkeer — namelijk om zich te laten authenticeren, en het verkeer te laten autoriseren — laat de Aanbieder zich operationeel geheel vertegenwoordigen door zijn Dienstverlener en diens Authorization Serveren Resource Server. Ook al zal in veel gevallen de gezondheidsinformatie uiteindelijk uit een achterliggend systeem worden betrokken, voor het MedMij Afsprakenstelsel is dat geen kwestie. Het is voldoende om bij de Authorization Server en Resource Server de eindverantwoordelijkheid neer te leggen (black box).

De genoemde servers treden op namens alle eventuele achterliggende systemen in het Aanbiedersdomein, zoals xIS'en. Die achterliggende complexiteit is een black box. Het is mogelijk dat een individuele xIS optreedt voor beide servers, maar dan moeten ook alle met deze rollen verbonden verantwoordelijkheden zijn ingevuld, zowel de direct verbonden verantwoordelijkheden (op de Applicatielaag) als de indirect verbonden verantwoordelijkheden (op de lagen erboven en eronder).

Hoezeer ook alle eindverantwoordelijkheden gedragen worden door de Dienstverleners die deelnemer zijn aan het MedMij Afsprakenstelsel, zij kunnen ervoor kiezen de uitvoering van die verantwoordelijkheden deels of zelfs geheel uit te besteden. In een mogelijke systeemarchitectuur maken meerdere Resource Server-systemen gebruik van een­zelf­de (al dan niet uitbesteed) Authorization Server-systeem. Het is mogelijk dat die Resource Server-systemen samen onder de eindverantwoordelijkheid van één Dienstverlener aanbieder vallen, met de uitvoering al dan niet uitbesteed. Het is ook mogelijk dat twee verschillende Dienstverlener aanbieders voor de Authorization Servergebruik maken van eenzelfde onderaannemer. 

De architectuur heeft zo maximale ruimte aan de eigen businessmodellen en architecturen van Dienstverlener aanbieder willen geven zonder daarbij de interoperabiliteit en strakke eindverantwoordelijkheden geweld aan te doen.

Note

Een rol is nadrukkelijk geen component of systeem. Menige rol wordt weliswaar door componenten en systemen gerealiseerd, maar hoe dat precies gebeurt, en hoeveel en welke componenten- of systeemarchitectuur daarvoor wordt gebruikt is aan de Dienstverlener, zolang deze zijn rollen, op alle lagen, naar behoren speelt, dat wil zeggen, de verantwoordelijkheden van die rollen draagt. Zo wordt aan Dienstverleners, in beide domeinen, volop ruimte geboden een businessmodel naar eigen inzicht te kiezen, waarin volop ruimte is voor onderaannemers, zolang de eindverantwoordelijkheid jegens het MedMij Afsprakenstelsel maar onvervreemdbaar bij de Dienstverlener blijft liggen.

MedMij-Verkeer

Al het MedMij-verkeer is over domeingrenzen. Verkeer binnen het Persoonsdomein of het Aanbiedersdomein maakt geen deel uit van MedMij-verkeer. Ook authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt over welke (externe) Authentication Server wordt gebruikt. Het MedMij Afsprakenstelsel vereist dát er een passende authenticatie door Aanbieder moet plaatsvinden, maar het verkeer dat daarvoor nodig is — tussen Authorization Server, Authentication Server en User Agent — is geen MedMij-verkeer. Het is de Aanbieder die niettemin als verwerkingsverantwoordelijke verantwoordelijk blijft voor een passende keuze van een Authentication Server en voor het laten inrichten van het authenticatieverkeer.