Inleiding

Een onmisbaar deel van het MedMij Afsprakenstelsel betreft de verantwoordelijkheden die de deelnemers in het afsprakenstelsel hebben, elk in zijn eigen rol, tijdens het feitelijk verzorgen van het informatieverkeer tussen het Persoonsdomein en het Zorgaanbiedersdomein. Deze verantwoordelijkheden zijn opgenomen in de architectuur en de technische specificaties van het MedMij Afsprakenstelsel, die in deze pagina's uiteen worden gezet. Deze verantwoordelijkheden zijn geordend in een aantal abstractieniveaus, geïnspireerd op het interoperabiliteitsmodel van Nictiz.

Vaak wordt er in de verantwoordelijkheden verwezen naar een specificatie. Dit kan een specifiek voor MedMij gespecificeerde use case zijn, maar is vaak ook een standaard, vooral voor informatie. De specificatie zal niet in de verantwoordelijkheid zelf staan uitgeschreven; er zal naar verwezen worden.

De rollen en verantwoordelijkheden zijn om te beginnen bondig en stellig als regel geformuleerd. Pas in tweede instantie zijn ze voorzien van toelichting. De opzet is dus niet die van een verhalende uiteenzetting van het stelsel, maar die van een setje afspraken, artikelsgewijs. Dat maakt de architectuur geschikt om als verlengstuk van de deelnemersovereenkomst te worden gebruikt. De allereerste vraag is: Wat is de afspraak? In tweede instantie spelen vragen als: Waarom is hiervoor gekozen? en Wat betekent die afspraak?

Waar in de beschrijving van de architectuur, de daarin bevatte rollen en verantwoordelijkheden en de toelichtingen daarop, met een naam wordt gerefereerd aan architectuurcomponenten, zoals die voorkomen in het diagram 'Overzicht van de architectuur', wordt de naam italiek en met Beginkapitaal geschreven. Dat geldt ook voor de pad-expressies in de invarianten bij de Informatiemodellen. Variabelen in die pad-expressies staan ook italiek, maar beginnen met een kleine letter.

Sommige architectuurcomponenten worden ook vertegenwoordigd door een klasse, attribuut, element of type in de Informatiemodellen. Omdat de spelling van de namen in de Informatiemodellen formeler is, kan de naamgeving daar iets afwijken van die in de rest van de architectuur, in het gebruik van spaties en hoofdletters. In de Informatiemodellen beginnen alle namen met een hoofdletter. Midden in de namen verschijnen bovendien hoofdletters wanneer, en alleen wanneer, het daar resterende deel van de naam ook als aparte naam voorkomt.

Technische code-fragmenten worden in monospace geciteerd.

Abstractniveaus

Voor elke niveau staan de afspraken uitgewerkt op een aparte pagina. Elke pagina kan subpagina's hebben voor deelaspecten. Die afspraken bestaan steeds uit:

de identificatie van de rollen op deze (deel)laag en de binding van die rollen aan de rollen op de laag erboven;
de verantwoordelijkheden die de rollen op deze (deel)laag hebben in het uitvoeren van zekere functies met zekere gegevens.

Een aparte pagina Informatiemodellen, met drie subpagina's, specificeert de conceptuele structuur van (een deel van) het begrippenapparaat van de architectuur van het MedMij Afsprakenstelsel en vertaalt die via logische modellen naar technische modellen van enkele componenten. Zo wordt tot op technisch niveau de interoperabiliteit op het MedMij-netwerk geborgd.

Juridica

De bovenste laag in de architectuur is Juridica. Deze laag kent alleen de rollen-kolom, niet de andere drie. Die laatste staan namelijk behandeld op de pagina Overeenkomsten en rechtsrelaties. Deze laag is alleen bedoeld voor de koppeling, rollen-gewijs, van de architectuur met het juridische deel van het MedMij Afsprakenstelsel, zodat duidelijk wordt welke architecturale en technische verantwoordelijkheden verbonden zijn aan welke juridische rollen.

Processen en informatie

Om te beginnen moeten deelnemers er samen voor zorgen dat zich zekere bedrijfsprocessen voltrekken tussen het Persoonsdomein en het Zorgaanbiedersdomein. Deze bedrijfsprocessen gaan over het verzamelen en delen van gezondheidsinformatie. Op dit abstractieniveau is nog geen sprake van geautomatiseerde afhandeling van deze processen, maar zijn de verantwoordelijkheden enkel nog geformuleerd in termen van de inhoud van die processen en van de gezondheidsinformatie die daarin omgaat. De proceslaag en de informatielaag uit het interoperabiliteitsmodel van Nictiz zijn gecombineerd in één laag: Processen en Informatie.

Applicatie

Op het volgende abstractieniveau, de Applicatielaag, komt ter sprake dat, en hoe, deze bedrijfsprocessen met de erin omgaande gezondheidsinformatie, geautomatiseerd moeten worden uitgevoerd, in samenwerking tussen de rollen. Het is de meest complexe laag, die twee bijzondere deel-lagen heeft: één voor authenticatie van de Persoon en één voor diens autorisatie van het informatieverkeer.

De Applicatielaag heeft twee deellagen: een autorisatielaag en een authenticatielaag. Dat komt doordat voor deze twee kwesties standaarden worden gebruikt die hun eigen rollenstructuur hebben, waarmee dus een expliciete binding moet worden aangebracht. Bovendien is het op deze manier mogelijk om de afspraken die specifiek voortvloeien uit het ontwerp van die standaarden een herkenbare en beheersbare plaats te geven.

Op de authenticatielaag is het niet nodig nadere afspraken te maken over gegevens. Daarvoor kan geheel teruggevallen worden op de specificaties van het de koppelvlakken die door de Authentication Provider ZA worden geboden. Daarom ontbreekt die kolom in de architectuur.

Netwerk

Op het onderste abstractieniveau, de Netwerk-laag, zijn de verantwoordelijkheden opgenomen op het gebied van de netwerkinfrastructuur.

Overzicht van de architectuur

In onderstaand diagram zijn deze abstractieniveaus herkenbaar. Op elke laag worden de architectuurelementen aangegeven die nodig zijn op de betreffende laag, met hun onderlinge verbanden binnen en tussen de lagen. Het diagram op deze pagina is niet bedoeld om ineens de samenhang tussen alle details te specificeren. Dat gebeurt stap voor stap op de pagina's die bij de specificatielagen horen; op de pagina voor elke laag wordt de bij die laag passende uitsnede van het diagram herhaald en behandeld. Op deze pagina wil het diagram slechts twee rollen vervullen:

een overzicht over de lagen (en kolommen) van de architectuur van het MedMij Afsprakenstelsel
een index waarmee men bij een architectuurdetail snel de laag kan vinden waarop er op dat detail wordt ingegaan.

Uitleg diagram 'Overzicht van de architectuur'

In de architectuur is ook een vierdeling in kolommen aangebracht: rollen, functies, interfaces en gegevens. Interfaces zijn alleen aan de orde op de Applicatie-laag, waarvan zij de spil vormen. Op elke laag spelen voor die laag specifieke rollen, die voor die laag specifieke functies uitvoeren met behulp van voor die laag specifieke gegevens. Om precies die reden zijn de proceslaag en de informatielaag uit het interoperabiliteitsmodel van Nictiz gecombineerd in één laag, waaraan dus bovendien een rollenkolom is toegevoegd. Omdat het om een architectuur van een afsprakenstelsel gaat -- en nog niet om een architectuur van systemen en oplossingen -- speelt de rollenkolom een sleutelrol in de samenhang van de gehele architectuur. Rollen zijn bundels van verantwoordelijkheden. Die verantwoordelijkheden gaan over uit te voeren functies (tweede kolom), die op hun beurt gebruik maken van gegevens (vierde kolom). Een rol is dus geen individuele partij en geen systeem of component. Pas als individuele partijen de rol gaan vervullen, hebben zijn daarvoor systemen en componenten nodig, als implementatie van de rollen.

De kleuren van de grote vlakken komen overeen met de kleuren die Nictiz aan de betreffende architectuuraspecten geeft in haar interoperabiliteitsmodel. De kleuren van de architectuurelementen (de kleine rechthoeken) geven aan in welk domein het betreffende architectuurelement geplaatst is. Daarbij is allereerst de huisstijl van MedMij aangehouden, zodat:

oranje staat voor het Persoonsdomein;
blauw staat voor het Zorgaanbiedersdomein en
groen staat voor het MedMij-domein.

De grijze kleur staat voor externe rollen waarvan het MedMij Afsprakenstelsel gebruik maakt. Waar meerdere kleuren zijn gecombineerd, geeft dat aan dat in het betreffende architectuurelement de domeinen samenwerken.

De verticale lijnen in de architectuur verbinden de rollen, functies en gegevens tussen de verschillende lagen.

Met de horizontale stippellijnen staat aangegeven welke rollen welke functies uitvoeren, respectievelijk welke functies welke gegevens gebruiken. Om te voorkomen dat er een onoverzichtelijke wirwar van stippellijnen ontstaat, maakt de figuur gebruik van joins en splits. Joins en splits zijn getekend als ruitjes. Een join (samenkomst) kenmerkt zich door meerdere inkomende pijlen en één uitgaande, een split (splitsing) juist door één inkomende en meerdere uitgaande pijlen.

Er komen twee tekens voor in de ruitjes.

Een maalteken staat voor exclusief, wat wil zeggen dat slechts één van de inkomende pijlen (bij joins) of uitgaande pijlen (bij splits) tegelijk aan de orde is.
Een plusteken staat voor inclusief, wat wil zeggen dat altijd alle inkomende pijlen (bij joins) of uitgaande pijlen (bij splits) tegelijk aan de orde zijn.

Zo is bijvoorbeeld, op de laag Processen en Informatie, de rol MedMij Beheer betrokken:

in drie use cases: UC Opvragen ZAL, UC Opvragen OCL en UC Opvragen GNL maar niet tegelijk (exclusief).
in de use case UC Opvragen ZAL tegelijk (inclusief) met de rol Uitgever.

Rollen

De rollen in het MedMij Afsprakenstelsel zijn bijeen horende setjes verantwoordelijkheden. Ze komen voor op elke laag van de architectuur, van de Juridische laag, via de Processen-en-Informatie-laag en de Applicatie-laag tot en met de Netwerk-laag. Tussen twee aangrenzende architectuurlagen, zijn de rollen aan elkaar gekoppeld. Een rol op de ene laag gaat gepaard met een of meerdere rollen op de laag eronder.

Dat wil zeggen dat één rol op de hogere architectuurlaag in het algemeen wordt ingevuld met één of meer verbonden rollen op de laag eronder. Andersom echter hoort één rol op de lagere architectuurlaag bij één verbonden rol op de hogere laag. Omdat de Nodes op Netwerk-niveau worden geïdentificeerd met een hostname, kan zo altijd aan de logging op Netwerk-niveau afgelezen worden welke deelnemer verantwoordelijk is voor welke gebeurtenis.

De rolbindingen vormen zo de ruggengraat van de architectuur van het MedMij Afsprakenstelsel.

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.

Dienstverlener

Voor een Dienstverlener moet er verder maximale vrijheid zijn om één rol op het ene niveau in te richten met meerdere op de laag eronder. Het moet echter andersom wel duidelijk blijven, op alle lagen, dat er één Dienstverlener verantwoordelijk is voor elke rol. Meerdere rollen kunnen dus niet op één lagere worden afgebeeld. Het is wel mogelijk dat meerdere rollen door een gezamenlijk systeem gerealiseerd worden, zolang hun afzonderlijke eindverantwoordelijken maar intact blijven.

Hoezeer ook alle eindverantwoordelijkheden gedragen worden door de Dienstverleners die deelnemer zijn in 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 eenzelfde (al dan niet uitbesteed) Authorization Server-systeem. Het is mogelijk dat die Resource Server-systemen samen onder de eindverantwoordelijkheid van één Dienstverlener Zorgaanbieder vallen, met de uitvoering al dan niet uitbesteed. Het is ook mogelijk dat twee verschillende Dienstverleners Zorgaanbieder voor de Authorization Server gebruik maken van eenzelfde onderaannemer. De hostnames in de adressen van de Authorization Endpoints/Token Endpoints zullen dan evengoed verschillen tussen die twee eindverantwoordelijke Dienstverleners Zorgaanbieders, zelfs al zou er het zelfde Authorization Server-systeem achter zitten. Voor de Zorgaanbiedergegevensdiensten waarvoor Dienstverlener Zorgaanbieder A verantwoordelijk is, moet dat de hostname van een Node van A zijn; voor de ZorgaanbiederGegevensdiensten waarvoor Dienstverlener Zorgaanbieder B verantwoordelijk is moet dat de hostname van een Node van B zijn.

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

MedMij Afsprakenstelsel 1.4.1

Vervallen op 14 mei 2022

Architectuur en technische specificaties