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.

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: /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629236.

Op het volgende abstractieniveau, de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629248, 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.

Op het onderste abstractieniveau, de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629585-laag, zijn de verantwoordelijkheden opgenomen op het gebied van de netwerkinfrastructuur.

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.

De toelichting onder het diagram bespreekt nog wat de kolommen, de kleuren en de lijntjes in het diagram betekenen en bereidt voor op lezing van de detailpagina's.

In de architectuur is ook een vierdeling in kolommen aangebracht: rollen, functies, interfaces en gegevens. Interfaces zijn alleen aan de orde op de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629248-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 /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629248 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.

Boven de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629236 is een extra laag aangebracht: /wiki/spaces/MedMijAfsprakenstelsel130/pages/135630303. Deze laag kent alleen de rollen-kolom, niet de andere twee. Die laatste staan namelijk behandeld op de pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629301. 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.

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.

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.

De rollen in het MedMij Afsprakenstelsel zijn bijeen horende setjes verantwoordelijkheden. Ze komen voor op elke laag van de architectuur, van de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135630303 laag, via de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629236-laag en de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629248-laag tot en met de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629585-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. 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.

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.

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 /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629585-niveau worden geïdentificeerd met een hostname, kan zo altijd aan de logging op /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629585-niveau afgelezen worden welke deelnemer verantwoordelijk is voor welke gebeurtenis.

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.

Voor elke laag staan de afspraken uitgewerkt op een aparte pagina:

• /wiki/spaces/MedMijAfsprakenstelsel130/pages/135630303
• /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629236
• /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629248, inclusief Authenticatie en Autorisatie
• /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629585

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 /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629309, 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.

Vaak wordt er in de verantwoordelijkheden verwezen naar een specificatie. Dit kan een specifiek voor MedMij gespecificeerde use case zijn, bijvoorbeeld, maar is vaak ook een standaard, vooral voor informatie. De specificatie zal niet in de verantwoordelijkheid zelf staan uitgeschreven; er zal naar verwezen worden. Zo hoeft voor detailaanpassingen in de specificatie niet steeds de verantwoordelijkheid te worden aangepast. Dat zou, zeker bij standaardspecificaties, een ongewenste beheerlast van het afsprakenstelsel opleveren.

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 hierboven, wordt de naam italiek en met Beginkapitaal geschreven. Dat geldt ook voor de pad-expressies in de invarianten bij de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629309. 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 /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629309. Omdat de spelling van de namen in de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629309 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 /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629309 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.

De rollen in het MedMij Afsprakenstelsel zijn bijeen horende setjes verantwoordelijkheden. Ze komen voor op elke laag van de architectuur, van de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135630303 laag, via de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629236-laag en de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629248-laag tot de /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629585-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. Een rol is dus 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, maar naar behoren speelt, dat wil zeggen, de verantwoordelijkheden van die rollen draagt.

Voor een Dienstverlener moet er 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.

De Nodes op /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629585-niveau worden geïdentificeerd met een hostname. Omdat dus ook elke PGO Node en ZA Node bij één Dienstverlener hoort, is aan de hostname de Dienstverlener te herkennen.

In het persoonsdomein geldt zo dat:

• één Dienstverlener Persoon één of meerdere Uitgevers verzorgt en elke Uitgever verzorgd wordt door één Dienstverlener Persoon;
• één Uitgever door één of meerdere PGO Servers wordt gerealiseerd en elke PGO Server één Uitgever realiseert;
• één PGO Server door één of meerdere PGO Nodes wordt ondersteund en elke PGO Node één PGO Server ondersteunt.

Zo kan dus ook in de OAuth Clientlist de hostname van een PGO Node geassocieerd worden met één (gebruikersvriendelijke naam van de) PGO Server .

In het zorgaanbiedersdomein geldt zo dat:

• één Dienstverlener Zorgaanbieder één of meerdere Bronnen en/of Lezers verzorgt en elke Bron en/of Lezer verzorgd wordt door één Dienstverlener Zorgaanbieder;
• één Bron en/of Lezer door één of meer combinaties van één Authorization Server en één Resource Server  wordt gerealiseerd en elke combinatie van één Authorization Server en één Resource Server één Bron en/of Lezer realiseert;
• één Authorization Server, net als één Resource Server, door één of meerdere ZA Nodes wordt ondersteund;
• elke ZA Node hetzij één  Authorization Server  ondersteunt, hetzij één Resource Server , hetzij de combinatie van één Authorization Server en één Resource Server ondersteunt;
• elke ZA Node één of meerdere endpoints kent en elk endpoint hoort bij één ZA Node, zodanig dat de hostname in een endpoint-adres de hostname van die ZA Node is.

Het vierde punt staat het toe om een Authorization Server en een Resource Server te verdelen over verschillende ZA Nodes, maar ook te combineren op dezelfde. Het derde punt staat het zelfs toe dat Authorization Server en Resource Server elk apart op meerdere ZA Nodes worden geprojecteerd. Het kan dan voorkomen dat, bij de betreffende ZorgaanbiederGegevensdiensten in de Zorgaanbiederslijst, hostnames in de endpointadressen staan die verschillen tussen het authorization endpoint, het token endpoint en het resource endpoint, zelfs bij eenzelfde Interfaceversie. Een belangrijke eis blijft evenwel dat al deze hostnames bij ZA Nodes van eenzelfde Dienstverlener Zorgaanbieder horen. De hele flow behorend bij een zekere ZorgaanbiederGegevensdienst moet namelijk onder de eindverantwoordelijkheid van één zo'n Dienstverlener vallen, namelijk van de Dienstverlener die die ZorgaanbiederGegevensdienst ontsluit. Zo blijft die integrale eindverantwoordelijk­heid ook op net­werk-niveau toetsbaar. Zie de drie (ingewikkelde) /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629422 bij Zorgaanbie­derGegevensdienst van het soort “niet-lokale afhankelijkheid”. 

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.