Skip to end of metadata
Go to start of metadata


Toelichting

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.

Rollen

  1. Dienstverlener persoon neemt de functionele rol van Uitgever op zich. Eén Dienstverlener Persoon speelt één of meerdere Uitgevers en elke Uitgever wordt gespeeld door één Dienstverlener Persoon.
  2. Dienstverlener zorgaanbieder neemt de functionele rol van Bron en/of Lezer op zich. Eén Dienstverlener Zorgaanbieder speelt één of meerdere Bronnen en/of Lezers en elke Bron en/of Lezer wordt gespeeld door één Dienstverlener Zorgaanbieder;
  3. Stichting MedMij neemt de functionele rol van MedMij Beheer op zich. Eén Stichting MedMij speelt één MedMij Beheer en omgekeerd.
  4. Persoon neemt de functionele rol van Zorggebruiker op zich. Eén Persoon speelt één of meerdere Zorggebruikers en elke Zorggebruiker wordt gespeeld door één Persoon.

Toelichting

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. Alle complexiteit voor de implementatie van die verantwoordelijkheid ligt bij 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.

Verantwoordelijkheden

Toelichting

De verantwoordelijkheden op deze laag en die op de Applicatielaag hebben een vergelijkbare opbouw. Ze zijn geordend in hoofdstukken en secties als volgt:

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

Op meerdere plaatsen komen daarbij use cases (op deze laag) en use case-implementatie (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 afsprakenstelsel zijn er zes use cases, waarvan er zich vijf afspelen tussen het Persoons- en het Zorgaanbiedersdomein. Van deze vijf maken, om de interoperabiliteit in het MedMij-netwerk te borgen, stroomdiagrammen deel uit van het afsprakenstelsel. De zesde speelt zich helemaal binnen het Persoonsdomein af. Hiervan eist het MedMij Afsprakenstelsel wel dat erin moet worden voorzien, maar niet hoe; dat wordt aan de vrijheid van de MedMij-deelnemers gelaten.

Het gaat om de volgende use cases:

Use caseStroomdiagram
UC Verzamelenmet
UC Delenmet
Raadplegen dossierzonder
UC Opvragen ZALmet
UC Opvragen OCLmet
UC Opvragen GNLmet

Voor registratie van MedMij-deelnemers en van hun 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 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.

Dossier

Use cases 

1a. Uitgever biedt Zorggebruiker de use case UC Verzamelen om bij Bron gezondheidsinformatie te verzamelen bij Zorgaanbieder, indien deze die informatie beschikbaar stelt, die op deze Zorggebruiker betrekking heeft en laat deze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Zorggebruiker bewaren. Bij deze use case betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

Toelichting

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.

1b. Uitgever biedt Zorggebruiker de use case UC Delen om bij Lezer ten behoeve van een Zorgaanbieder, indien deze daartoe ontvankelijk is, gezondheidsinformatie te plaatsen die op deze Zorggebruiker betrekking heeft en die afkomstig is uit het Dossier. Bij deze use case betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

Toelichting

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

1c. Uitgever draagt ervoor zorg dat in het Dossier bij alle bij Bron in het kader van een Gegevensdienst verzamelde informatie onlosmakelijk deze Bron en Gegevensdienst als bron en verzamelcontext worden aangetekend. Uitgever draagt ervoor zorg dat, in geval van het delen van informatie met een (andere) Zorgaanbieder deze bron- en context-informatie wordt meegeleverd aan de Lezer. Voor de benoeming van de Bron wordt daarbij gebruik gemaakt van de Zorgaanbiedersnaam. Voor de benoeming van de context wordt daarbij gebruik gemaakt van de betreffende Gegevensdienstnaam uit de Gegevensdienstnamenlijst.

Toelichting

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.

2. Uitgever biedt Zorggebruiker de use case Bevragen dossier om het persoonlijk gezondheidsdossier te raadplegen.

Toelichting

Zie onder 1. Omdat deze functie zich niet over meerdere rollen 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.

3. In het kader van de use case Bevragen dossier zal Zorggebruiker te allen tijde moeten kunnen nagaan:

  • welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer van Bron is betrokken van welke Zorgaanbieder, en sindsdien niet is veranderd;
  • welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer bij Lezer is geplaatst ten behoeve van welke Zorgaanbieder.

Toelichting

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.

Gegevensdiensten

4. Uitgever laat Zorggebruiker met een Gegevensdienst uit de Gegevensdienstnamenlijst gezondheidsinformatie verzamelen bij een Bron of, ten behoeve van een Zorgaanbieder, plaatsen bij een Lezer.

Toelichting

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.

5. Elke Bron ontsluit op elk moment minstens één GegevensdienstElke Lezer ontsluit op elk moment minstens één Gegevensdienst.

Toelichting

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.

6. MedMij Beheer zal alleen in de Zorgaanbiederslijst opnemen dat een zekere Gegevensdienst door een zekere Zorgaanbieder via een zekere Bron, respectievelijk Lezer, wordt aangeboden, indien zij (Stichting MedMij) heeft vastgesteld dat de Dienstverlener zorgaanbieder die daarbij de Bron, respectievelijk Lezer, is, voldoet aan de specifiek op die Gegevensdienst toepas­selij­ke eisen.

Toelichting

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

7a. Voor elke Gegevensdienst waarvan de Zorgaanbiederslijst aan­geeft dat een zekere Zorgaanbieder deze aanbiedt, zal Bron, respectievelijk Lezer, ervoor zorgdragen dat die Gegevensdienst ook geleverd wordt. Daarbij wordt geen enkel onderscheid gemaakt tussen Uitgevers, tenzij het MedMij Afsprakenstelsel daartoe uitdrukkelijk verplicht. Dit geldt ook voor de mogelijke andere Gegevensdienst(en) die in de Catalogus staan genoemd als Vereist bij eerstgenoemde Gegevensdienst.

Toelichting

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.

7b. Het is verantwoordelijkheid 7a bepaalde is ook van toepassing zolang de geldigheid van de toepasselijke vermelding in de Zorgaanbiederslijst niet langer dan één uur (3600 seconden) geleden is verstreken.

Toelichting

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

Autorisatie

8a. Bron vergewist zich ervan, elke keer opnieuw voordat hij Zorggebruiker gezondheidsinformatie van Zorgaanbieder laat verzamelen, dat deze Zorggebruiker uitdrukkelijk Toestemming heeft gegeven aan Zorgaanbieder om de in de Gegevensdienst betrokken gezondheidsinformatie aan Uitgever ter beschikking te laten stellen. De vraag om Toestemming heeft een vaste formulering, die is opgenomen in de UC Verzamelen. Deze Toestemming geldt niet buiten deze doorloping van de UC Verzamelen.

Toelichting

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 de huidige 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.

8b. Lezer vergewist zich ervan, elke keer opnieuw voordat hij Zorggebruiker gezondheidsinformatie ten behoeve van Zorgaanbieder laat plaatsen, dat deze Zorggebruiker uitdrukkelijk heeft bevestigd om de in de Gegevensdienst betrokken gezondheidsinformatie aan Zorgaanbieder ter beschikking te willen stellen. De vraag om Bevestiging heeft een vaste formulering, die is opgenomen in de UC Delen. Deze bevestiging geldt niet buiten deze doorloping van de UC Delen.

Toelichting

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.

Authenticatie

9. Bron en Lezer dragen ervoor zorg dat de onder 7 bedoelde opvolging, en de onder 8a en 8b bedoelde vraag om Toestemming, respectievelijk bevestiging, slechts plaatsvinden wanneer hij de identiteit van de Zorggebruiker met passende zekerheid heeft vastgesteld.

Toelichting

Op de Applicatie-laag wordt beschreven dat de identiteit van de Zorggebruiker uitgedrukt wordt door een BSN en die passende zekerheid wordt verkregen door middel van DigiD.

Lijsten

Vier lijsten

In het MedMij Afsprakenstelsel worden vier lijsten gebruikt voor de interoperabiliteit en het vertrouwen tussen het Persoonsdomein en het Zorgaanbiedersdomein. 

lijst

afkortingwordt opgehaald en gebruikt doorinformatie-inhoud
UitgeverBron/Lezer
ZorgaanbiederslijstZALX
welke Zorgaanbieders welke Gegevensdiensten aanbieden en op welke adressen zij die laten ontsluiten
OAuth Client ListOCL
Xde namen van PGO's en welke Gegevensdiensten zij mogen gebruiken
GegevensdienstnamenlijstGNLXXde gebruiksvriendelijke namen van Gegevensdiensten
WhitelistWHLXXwelke Nodes actief mogen zijn op het MedMij-netwerk

Zorgaanbiederslijst

10. MedMij Beheer beheert en publiceert een Zorgaanbiederslijst, namens de deelnemende Dienstverleners zorgaanbieder. De Zorgaan­bie­derslijst beschrijft van elke Zorgaanbieder welke Gegevensdiensten deze momenteel aanbiedt via welke Bron en Lezer, en welke technische adressen daarvoor moeten worden aangesproken bij de Dienstverlener zorgaanbieder. De gepubliceerde Zorgaanbiederslijst bevat steeds en slechts alle actuele entries.

Toelichting

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. Zonder deze functie zou het stelsel niet functioneren.

11. De Zorgaanbiederslijst voldoet aan wat over haar is bepaald in de Informatiemodellen.

12. MedMij Beheer beheert en publiceert, in de Zorgaanbiederslijst, unieke en gebruikersvriendelijke namen van Zorgaanbieders, van het formaat <zorgaanbieder>@medmij. Daarop is naamgevingsbeleid van toepassing.

Toelichting

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.

13. MedMij Beheer biedt aan Uitgever een use case (UC Opvragen ZAL) om de actuele versie van die Zorgaanbiederslijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

OAuth Client List

14. MedMij Beheer beheert en publiceert een actuele OAuth Client List, namens de deelnemende Dienstverleners persoon. Deze beschrijft wat de gebruikersvriendelijke namen zijn die voor de Dienstverleners persoon worden gebruikt in de toestemmingsverklaring. De OAuth Client List voldoet aan wat over haar is bepaald in de Informatiemodellen.

Toelichting

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

15. MedMij Beheer biedt aan Bron een use case (UC Opvragen OCL) om de actuele versie van die OAuth Client List op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

Gegevensdienstnamenlijst

16. MedMij Beheer beheert en publiceert de GegevensdienstnamenlijstDeze beschrijft welke gebruikersvriendelijke namen horen bij welke GegevensdienstDe Gegevensdienstnamenlijst voldoet aan wat over haar is bepaald in de Informatiemodellen..

17. MedMij Beheer biedt aan Uitgever, Bron en Lezer een use case (UC Opvragen GNL) om de actuele versie van die Gegevensdienstnamenlijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

Whitelist

18. MedMij Beheer beheert en publiceert een actuele Whitelist, namens de deelnemende Dienstverleners zorgaanbieder en Dienstverleners persoon. De Whitelist beschrijft welke Nodes in MedMij-verkeer mogen deelnemenDe Whitelist voldoet aan wat over haar is bepaald in de Informatiemodellen.

Toelichting

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.

Logging

19. Uitgever zal het Dossier zo inrichten dat deze ook dienst kan doen als logbestand, zoals bedoeld in de AVG en NEN 7513:2018, van de door enige Zorggebruiker bij enige Bron verzamelde persoonsgege­vens en door enige Zorggebruiker bij enige Lezer geplaatste persoonsgegevens.

Toelichting

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.


20. De bewaartermijn van de logbestanden is ten minste twaalf maanden en niet meer dan vijftien maanden. Na de bewaartermijn van de logbestanden moeten deze vernietigd worden.

Toelichting

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.

21. MedMij Beheer onderhoudt een archief van alle ooit ontsloten versies van de Zorgaanbiederslijst, de OAuth Client List, de Whitelist en de Gegevensdienstnamenlijst. De bewaartermijn, gerekend vanaf het einde van de geldigheid van de betreffende versie, is niet korter dan die van de logbestanden als bedoeld in verantwoordelijkheid 20.

  • No labels