Voor een overzicht over alle lagen van de architectuur, en voor een toelichting van de betekenis van de symbolen en lijntjes, zie de overzichtspagina.

In deze figuur zijn de rollen, functies en gegevens-elementen uit de proces- en informatie-architectuur weergegeven, inclusief de binding (verticale lijnen) van deze rollen aan de juridische (zie Juridica). 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.

Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.

Met de rollen Uitgever, Bron en Lezer staat hier de principiële keus die het afsprakenstelsel maakt voor de aard van de Regie die zij aan Personen wil geven over de gezondheidsinformatie waarvan zijzelf het onderwerp zijn. Er zijn andere regiemodellen mogelijk, zwakkere en sterkere. In dit model is de Dienstverlener persoon, namens de Persoon, Uitgever van zijn/haar gezondheidsinformatie, betrekt die informatie daartoe van Bronnen en stelt die informatie beschikbaar aan Lezers. Zo krijgt de Persoon de Regie die MedMij hem wil bieden. In deze release van het MedMij Afsprakenstelsel verzamelt Uitgever gezondheidsinformatie bij Bronnen en deelt hij gezondheidsinformatie met Lezers.

In het Persoonsdomein is er naast de rol Uitgever ook de rol Zorggebruiker. Hoewel Uitgever namens Zorggebruiker handelt, kan Zorggebruiker niet ongenoemd blijven (verborgen achter de rol Uitgever) in de afspraken op deze en onderliggende lagen. Dat komt doordat Zorggebruiker niet enkel de gebruiker van Uitgever, maar allereerst het onderwerp van de gezondheidsinformatie die Bron ter beschikking moet stellen en Lezer ter beschikking gesteld wordt; daarvoor is authenticatie nodig. In het Zorgaanbiedersdomein ligt dat anders. In deze release van het afsprakenstelsel volstaat het om de Bron en Lezer te zien als de rollen die samen volledig verantwoordelijk zijn voor wat een Zorgaanbieder operationeel zou moeten doen. De implementatie van die verantwoordelijkheid is aan de Bron,respectievelijk Lezer. Dat werkt door in de Applicatielaag en de Netwerklaag.

Omdat ook de Stichting MedMij operationele verantwoordelijkheden heeft, staat hier de functionele rol van MedMij Beheer.

De verantwoordelijkheden op deze laag zijn geordend in hoofdstukken en secties als volgt:

• Dossier
  • Use cases
  • Gegevensdiensten
  • Authenticatie
  • Autorisatie
• Lijsten
  • Zorgaanbiederslijst
  • OAuth Client List
  • Gegevensdienstnamenlijst
  • Whitelist
• Logging en portabiliteit

Op meerdere plaatsen komen daarbij use cases (op deze laag) en use case-implementaties (op de Applicatie-laag) aan de orde. Een use case-implementatie is de implementatie van de use case met dezelfde naam. In deze release van het MedMij Afsprakenstelsel zijn er negen use cases, waarvan er zich zeven afspelen tussen het Persoons- en het Zorgaanbiedersdomein. Van deze zeven maken, om de interoperabiliteit in het MedMij-netwerk te borgen, stroomdiagrammen deel uit van het MedMij Afsprakenstelsel. De andere twee spelen zich helemaal binnen het Persoonsdomein af. Hiervan eist het MedMij Afsprakenstelsel wel dat erin moet worden voorzien, maar niet of slechts deels hoe; dat wordt aan de vrijheid van de MedMij-deelnemers gelaten.

Het gaat om de volgende use cases:

Voor registratie van Deelnemers en de vanwege hun deelname belangrijke gegevens zijn vooralsnog geen separate use cases geïdentificeerd, omdat registratie als een secundair proces wordt gezien. Zie hiervoor de pagina Operationele processen.

De interpretatie door een Zorggebruiker van zorg- en gezondheidsinformatie die hij heeft verzameld bij een Zorgaanbieder, en de interpretatie door een Zorgaanbieder van zulke informatie die met hem/haar gedeeld is door een Zorggebruiker, hangt niet alleen af van de inhoud van die informatie, maar ook van de partij die de betreffende informatie oorspronkelijk heeft geregistreerd. We gebruiken hiervoor niet zomaar de term Bron, omdat deze term in de zin van het MedMij Afsprakenstelsel niet per se de oorspronkelijke herkomst (de auteur) betekent, maar alleen de onmiddellijke herkomst, gezien vanuit de Uitgever. In het MedMij Afsprakenstelsel is de auteursrol geen juridische rol. Dat betekent niet alleen dat er binnen de grenzen van het MedMij Afsprakenstelsel momenteel geen basis is om auteursauthenticiteit (met bijvoorbeeld certificaten) te arrangeren, maar het brengt ook met zich mee dat informatie over de auteur, hoe wezenlijk ook, voor het MedMij Afsprakenstelsel een gegevens-inhoudelijke aangelegenheid is. Die informatie wordt immers ook gebruikt voor de interpretatie van de gedeelde zorg- en gezondheidsinformatie. Omdat, conform principe 1, het MedMij Afsprakenstelsel gegevensneutraal wil zijn, wordt de auteursinformatie een onderdeel geacht van de inhoud van een Gegevensdienst.

Deze verantwoordelijkheid introduceert ook de notie van een persoonlijk gezondheidsdossier. Voor het voldoen aan deze regel is het dus niet voldoende aan de Zorggebruiker alleen inkijk in gezondheidsinformatie te bieden. Hij/zij moet het ook kunnen opslaan en beheren. Omdat deze functie zich over verschillende functionele rollen uitstrekt, is om interoperabiliteitsredenen de specificatie van het stroomdiagram aangehaald.

Voor een beschrijving van overeenkomsten en verschillen tussen UC Verzamelen en UC Delen, zie de pagina over UC Delen.

Hiermee wordt geborgd dat bij de uitgewisselde zorg- en gezondheidsinformatie altijd duidelijk is bij welke Bron en in welke context (Gegevensdienst) deze is verzameld. Een Lezer van deze informatie kan deze meta-informatie gebruiken voor een betere interpretatie van de betreffende informatie. Mochten hieruit alsnog interpretatievragen komen, kan de Lezer zich vervoegen bij betreffende Bron.

Zie onder 1. Omdat deze functie zich niet over meerdere domeinen uitstrekt, is zij niet nader gespecificeerd in een stroomdiagram. Het is aan de vrijheid van de Deelnemer om deze naar behoefte van haar klanten in te richten. Maar zij mag niet ontbreken, omdat dan de Zorggebruiker geen Regie over het dossier zou kunnen voeren.

Hiermee is het voor de Zorggebruiker duidelijk op welk deel van de inhoud van zijn dossier hij de aan het MedMij Afsprakenstelsel verbonden vertrouwen kan verbinden. Het is immers goed mogelijk dat een PGO alleen op bepaalde onderdelen deelneemt, en dus voldoet, aan het MedMij Afsprakenstelsel.

Abonnementen horen bij de hoofdfunctie Regie.

Deze verantwoordelijkheid introduceert de notie van een Notificatie. Een Notificatie hoort altijd bij slechts één Abonnement. Er zijn twee soorten Notificaties:

• inhoudelijke Notificaties brengen Uitgever (en mogelijk Zorggebruiker) op de hoogte van de beschikbaarheid van nieuwe (gezondheids)informatie van Zorgaanbieder bij Bron, betreffende een Gegevensdienst waarop Zorggebruiker bij die Zorgaanbieder geabonneerd is;
• abonnements-Notificaties brengen Uitgever (en mogelijk Zorggebruiker) op de hoogte van het door de Zorgaanbieder, via Bron, beëindigen van een Abonnement (zie verantwoordelijkheid 3d).

Er worden geen eisen gesteld omtrent het beëindigen van een Abonnement ingeval (gezondheids)informatie van een Zorggebruiker niet langer beschikbaar is bij een Zorgaanbieder, bijvoorbeeld na een dossieroverdracht, of na vernietiging van het dossier. Wanneer deze situatie zich voordoet, zullen simpelweg tot de einddatum van het Abonnement geen inhoudelijke Notificaties meer worden gegenereerd.

Het zou kunnen gebeuren dat een Notification Client een Notificatie wenst te sturen, in het kader van een lopend Abonnement, maar de OAuth Client List aangeeft dat de betreffende Notification Server hetzij geen Notificaties meer kan ontvangen of de betreffende Gegevensdienst niet (meer) ondersteunt. In die gevallen wordt de Notificatie niet verzonden, maar blijft het Abonnement in beginsel wel intact. Omdat er geen Notificaties worden verstuurd, bestaan er geen risico's om het Abonnement aan te houden. Mocht de OAuth Client List een administratieve fout bevatten, is dat nog geen reden voor ontbinding van het Abonnement tussen Persoon en Zorgaanbieder; als zo'n fout hersteld zou worden, kunnen er daarna weer Notificaties onder hetzelfde Abonnement verstuurd gaan worden. Mocht een Notification Client een dergelijke situatie aantreffen, is er wel aanleiding voor de betreffende Dienstverlener zorgaanbieder om contact op te nemen met de betreffende Dienstverlener persoon en, waar dan nog nodig, met de MedMij-beheerorganisatie. Zie ook verantwoordelijkheid 3e.

Het vierde punt gaat ervan uit dat de Dienstverlener zorgaanbieder een eigen administratie bijhoudt van welke Gegevensdiensten hij voor welke Zorgaanbieders ontsluit, en daarvoor niet leunt op de Zorgaanbiederslijst of andere lijsten. Zijn verwerkersrelaties met Zorgaanbieders zijn immers de bron van die lijsten, niet andersom. Het kan zijn dat de Dienstverlener zorgaanbieder een fout in die eigen administratie maakt en dan, vanwege het vierde punt, de betreffende Abonnementen beëindigd. Het MedMij Afsprakenstelsel voorkomt dat niet, omdat die fout moet worden gezien als een fout van de Dienstverlener zorgaanbieder als verwerker voor de Zorgaanbieder, met andere woorden, in het kader van de Dienstverleningsovereenkomst tussen die twee, en niet op het MedMij-koppelvlak.

Bij het aangaan, verlengen, verkorten en beëindigen van Abonnementen wordt bij de betrokken interfaces gebruik gemaakt van twee verschillende parameters voor het aanduiden van de duur van het Abonnement: duration en end_date. 

• Abonnementsduur wordt toegepast in de Authorization Interface en de Token Interface en geeft de duur aan in het gewenste aantal dagen. Hierdoor is de controle door de Authorization Interface op een geldige waarde voor deze parameter eenduidig en ongecompliceerd.
• End_date wordt toegepast in de Subscription Interface. In de transactie die daar plaats vindt, wordt de definitieve en precieze waarde van de datum tot waar een Abonnement loopt vastgesteld. Het door de Zorgaanbieder gevoerde beleid omtrent de maximale duur van een Abonnement, de gewenste duur zoals ingebracht door de Persoon en een zekere vrijheidsgraad rond het hanteren van datumgrenzen en systeemtijden maken het noodzakelijk dat een eenduidige einddatum wordt vastgesteld.

Een Gegevensdienst is een op een specifieke en gestandaardiseerde set gezondheidsinformatie gerichte dienst waarmee Bron zulke informatie ontsluit naar Uitgever in het kader van de UC Verzamelen of Lezer zulke informatie geplaatst krijgt ten behoeve van een Zorgaanbieder. In de Gegevensdienstnamenlijst zijn de Gegevensdiensten opgenomen die op enig moment worden aangeboden, maar de Catalogus is de autoriteit daarvoor.

Het ontsluiten van een Gegevensdienst is, in deze versie van het MedMij Afsprakenstelsel, hetzij het door een Bron bij zich laten verzamelen of het door een Lezer met zich laten delen van zekere gezondheidsinformatie. De term 'ontsluiten' wordt hier gebruikt in plaats van de term 'aanbieden', omdat als aanbieder van een Gegevensdienst de Zorgaanbieder wordt gezien, niet de Deelnemer (Bron of Lezer). De Deelnemer ontsluit de Gegevensdienst dus namens de Zorgaanbieder die die Gegevensdienst aanbiedt.

De termen 'aanbieden' en 'ontsluiten' vertegenwoordigen een tweedeling in de verantwoordelijkheid voor een geleverde Gegevensdienst. De Zorgaanbieder is, ook als verwerkingsverantwoordelijke in de zin der AVG, verantwoordelijk voor het aanbieden van een Gegevensdienst aan de Uitgever; de Dienstverlener zorgaanbieder is, ook als verwerker in de zin der AVG, verantwoordelijk voor het ontsluiten van diezelfde Gegevensdienst aan diezelfde Uitgever. Aanbieden en ontsluiten zijn dus niet achter elkaar geschakeld: de Zorgaanbieder biedt de Gegevensdienst niet zozeer aan de Bron/Lezer aan, maar aan de Uitgever. Aanbieden en ontsluiten zijn aspecten van eenzelfde geleverde Gegevensdienst: het eerste het verwerkingsverantwoordelijke, het tweede het verwerkende.

Omdat er een indirectie speelt, via de Dienstverlener zorgaanbieder naar de Zorgaanbieder, moet gezegd worden dat één Zorgaanbieder genoeg is (die een bepaalde Gegevensdienst ontsluit) om ervoor te zorgen dat de Dienstverlener zorgaanbieder zich voor die Informatiestandaard moet kwalificeren in het MedMij Afsprakenstelsel.

Net als verantwoordelijkheid 6, moet verantwoordelijkheid 7a rekening houden met de indirectie via Dienstverlener zorgaanbieder naar de Zorgaanbieder zelf. Deze regel legt het bij de Dienstverlener zorgaanbieder om ervoor zorg te dragen dat de Zorgaanbieder met wie hij een dienstverleningsovereenkomst heeft, ook de Gegevensdienst levert die hij toegezegd heeft.

Zo wordt ervoor ruimte geboden dat na-ijlende sessies, die nog gebruik maken van de verstrijkende versie van de Zorgaanbiederslijst, nog kunnen worden afgemaakt.

Het is dus de Bron die de Toestemming ophaalt bij de Zorggebruiker. De tweede zin van deze verantwoordelijkheid maakt de toestemming functioneel zo eenvoudig mogelijk, omdat in deze release van het MedMij Afsprakenstelsel alleen met een eenmalige vraag gezondheidsinformatie verzameld kan worden. De toestemming, hoe expliciet ook, heeft precies dezelfde reikwijdte als die eenmalige vraag.

Deze verantwoordelijkheid is welbewust niet geïntegreerd met verantwoordelijkheid 8a omdat de hier bedoelde bevestiging niet de juridische status heeft van de in verantwoordelijkheid 8a bedoelde Toestemming.

Bron handelt dus ook bij het beschikbaar kunnen stellen van Notificaties conform een Toestemming van de Zorggebruiker. Deze Toestemming wordt gegeven bij het aangaan van het Abonnement en blijft geldig voor de duur van het Abonnement.

Op de Applicatie-laag wordt beschreven dat de identiteit van de Zorggebruiker uitgedrukt wordt door een BSN.

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 Zorgaanbiedersdomein. 

Deze afspraak wijst MedMij Beheer de verantwoordelijkheid toe om ten behoeve van alle Dienstverleners persoon een lijst te verspreiden van Zorgaanbieders en de door hen aangeboden Gegevensdiensten en Abonnementen. Zonder deze functie zou het stelsel niet functioneren.

In de Catalogus staat bij elke Gegevensdienst de maximale duur van een Abonnement op (Notificaties van) die Gegevensdienst. Bij een Gegevensdienst gebaseerd op UC Delen zal hier vooralsnog altijd 0 als maximale duur staan, hetgeen betekent dat er geen Abonnementen mogelijk zijn op deze Gegevensdienst.

Zorgaanbieders kunnen in hun directe of indirecte contact met Zorggebruikers deze naam meegeven als hun "MedMij-naam". MedMij Beheer zorgt voor uniciteit en heeft het laatste woord bij het vaststellen ervan.

De OAuth Client List bevat dus geen namen voor Dienstverleners zorgaanbieder. Dat is niet nodig, omdat deze niet voorkomen in de Toestemmingsverklaring.

Er bestaat op deze laag geen use case voor het opvragen van de Whitelist. De Whitelist wordt alleen gebruikt op de Netwerk-laag. Op die laag is er wel een use case-implementatie voor dit doel.

Met de logging wordt beoogd een betrouwbaar overzicht te kunnen leveren van de gebeurtenissen waarbij gezondheidsinformatie over een persoon zijn verwerkt. Die gebeurtenissen kunnen zich over verschillende plaatsen en tijden uitstrekken. Het beoogde overzicht is dus alleen mogelijk als de loggegevens uit verschillende bronnen kunnen worden gecombineerd. Ook zonder direct een virtueel wereldwijd en levenslang patiëntdossier als doel te stellen is duidelijk dat gestandaardiseerde logging een voorwaarde is om het overzicht voor de betreffende Persoon mogelijk te maken.

Op 18 mei 2018 is een revisie verschenen van de 2010-versie van NEN 7513. Deze norm, met het nummer NEN 7513:2018, is onderdeel van het Normenkader informatiebeveiliging van het MedMij Afsprakenstelsel. In hoofdstuk 5 van de gereviseerde norm staan de informatiebehoeften, zowel de algemene als die vanuit het specifieke perspectief van cliënten, zorginstellingen en toezichthouders. Hoofdstuk 6 vertaalt deze behoeften naar een overzicht van te loggen gebeurtenissen en hoofdstuk 7 biedt een model van de te loggen gegevens. De voorgaande versie (NEN 7513:2010) is ingetrokken. De term NEN 7513 in het Besluit elektronische gegevensverwerking door zorgaanbieders wordt daarom geacht naar de 2018-versie te verwijzen.

Het maximum van de bewaartermijn is bepaald voor logging binnen de scope van MedMij-verkeer ter voorkoming van onnodige opslag van gegevens en ter bescherming van de privacy van de gebruiker. Deze minimale en maximale bewaartermijnen van logbestanden passen binnen de uitersten die daartoe door NEN7513 (paragraaf 8.5) zijn bepaald.

Met het Portabiliteitsrapport krijgt Zorggebruiker een middel in handen om een belangrijk deel van de gezondheidsinformatie die hij in het Dossier in zijn PGO heeft verzameld, naar believen ook in andere PGO's onder te brengen (portabiliteit, overdraagbaarheid). Ook dat draagt bij aan de Regie van de Zorggebruiker over zijn gezondheidsinformatie, aan zijn voortdurend vrije keuze tussen Dienstverlener persoon (principe 7) en aan het beperken van het nadeel dat hij zou ondervinden wanneer zijn Dienstverlener persoon haar activiteiten zou staken. 

Er is geen garantie dat een Portabiliteitsrapport geautomatiseerd door een andere PGO dan die het rapport heeft gemaakt zou kunnen worden 'afgespeeld', al is het maar doordat niet alle gebruikte Gegevensdiensten nog als geldig in de Catalogus hoeven te staan. Het Portabiliteitsrapport geeft in dat soort gevallen nog steeds precieze en menselijkerwijs enigszins leesbare informatie waarmee de nieuwe PGO alsnog, desnoods, handmatig gevuld kan worden.

Dienstverleners persoon kunnen  hun dienstverlening aan Zorggebruikers kracht bij zetten door een importfunctie voor Portabiliteitsrapporten aan te bieden. Dit is echter niet verplicht en moet gezien worden in het licht van principe 3.

Een zwaarder middel voor portabiliteit zou een uitwisselstandaard tussen PGO's zijn. Dit zou echter een flinke complexiteit en kosten met zich meebrengen, niet in het minst doordat het rekening zou moeten houden met alle voormalige versies van het MedMij Afsprakenstelsel en met Gegevensdiensten die ondertussen niet meer als geldig in de Catalogus staan.

Voor een overzicht over alle lagen van de architectuur, en voor een toelichting van de betekenis van de symbolen en lijntjes, zie de overzichtspagina.

In deze figuur zijn de rollen, functies en gegevens-elementen uit de proces- en informatie-architectuur weergegeven, inclusief de binding (verticale lijnen) van deze rollen aan de juridische (zie Juridica). 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.

Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.

Met de rollen Uitgever, Bron en Lezer staat hier de principiële keus die het afsprakenstelsel maakt voor de aard van de Regie die zij aan Personen wil geven over de gezondheidsinformatie waarvan zijzelf het onderwerp zijn. Er zijn andere regiemodellen mogelijk, zwakkere en sterkere. In dit model is de Dienstverlener persoon, namens de Persoon, Uitgever van zijn/haar gezondheidsinformatie, betrekt die informatie daartoe van Bronnen en stelt die informatie beschikbaar aan Lezers. Zo krijgt de Persoon de Regie die MedMij hem wil bieden. In deze release van het MedMij Afsprakenstelsel verzamelt Uitgever gezondheidsinformatie bij Bronnen en deelt hij gezondheidsinformatie met Lezers.

In het Persoonsdomein is er naast de rol Uitgever ook de rol Zorggebruiker. Hoewel Uitgever namens Zorggebruiker handelt, kan Zorggebruiker niet ongenoemd blijven (verborgen achter de rol Uitgever) in de afspraken op deze en onderliggende lagen. Dat komt doordat Zorggebruiker niet enkel de gebruiker van Uitgever, maar allereerst het onderwerp van de gezondheidsinformatie die Bron ter beschikking moet stellen en Lezer ter beschikking gesteld wordt; daarvoor is authenticatie nodig. In het Zorgaanbiedersdomein ligt dat anders. In deze release van het afsprakenstelsel volstaat het om de Bron en Lezer te zien als de rollen die samen volledig verantwoordelijk zijn voor wat een Zorgaanbieder operationeel zou moeten doen. De implementatie van die verantwoordelijkheid is aan de Bron,respectievelijk Lezer. Dat werkt door in de Applicatielaag en de Netwerklaag.

Omdat ook de Stichting MedMij operationele verantwoordelijkheden heeft, staat hier de functionele rol van MedMij Beheer.