Vervallen op 14 mei 2022
Architectuur en technische specificaties
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 toelichÂting. 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.
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 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 Zorgaanbieder vallen, met de uitvoering al dan niet uitbesteed. Het is ook mogelijk dat twee verschillende Dienstverleners ZorgaanbieÂder voor de Authorization Server gebruik maken van eenzelfde onderaannemer. De hostÂnames in de adressen van de Authorization Endpoints/Token Endpoints zullen dan evengoed verÂschillen tussen die twee eindverantwoordelijke Dienstverleners Zorgaanbieders, zelfs al zou er het zelfde Authorization Server-systeem  achter zitten. Voor de Zorgaanbiedergegevensdiensten waarÂvoor Dienstverlener Zorgaanbieder A verantÂwoordelijk is, moet dat de hostname van een Node van A zijn; voor de ZorgaanbiederÂGegeÂvensdiensten waarvoor Dienstverlener ZorgaanÂbieder 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.