Inleiding

De verantwoordelijkheden die in de MedMij Core staan beschreven, zijn ook van toepassing op deze extensie. Daarnaast gelden de hieronder (vervangende) verantwoordelijkheden. Net als in de MedMij Core zijn de volgende kleuren voor de verantwoordelijkheden op de verschillende lagen gebruikt:

Geel voor de businesslaag;
Blauw voor de applicatielaag;
Groen voor de technologielaag.

Rollen

1	Dienstverlener persoon stelt, indien deze de functie Notificeren* aanbiedt, aan Aanbieder* een geautomatiseerde rol Notification Server ter beschikking, waarop de Aanbieder Notificaties kan aanbieden. Eén zulke Dienstverlener persoon biedt één of meerdere Notification Servers en elke Notification Server wordt door één Dienstverlener persoon geboden.	ext.abo.rollen.200
2.	Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd in combinatie met een Resource Server en/of Subscription Server. Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.rollen.201	ext.abo.rollen.201
3.	Dienstverlener aanbieder biedt, indien deze de functie (v3.0.1) Abonneren aanbiedt, een geautomatiseerde rol Subscription Server voor het namens Aanbieders aangaan van Abonnementen. Elke zulke Dienstverlener aanbieder biedt één of meer combinaties van één Authorization Server en één Subscription Server en elke combinatie van één Authorization Server en één Subscription Server wordt door één Dienstverlener aanbieder geboden.	ext.abo.rollen.202
4.	Dienstverlener aanbieder biedt, indien deze de functie (v3.0.1) Notificeren aanbiedt, een geautomatiseerde rol Notification Client voor het namens Aanbieders plaatsen van Notificaties, genaamd Notification Client. Elke zulke Dienstverlener aanbieder biedt één of meer Notification Clients en elke Notification Client wordt door één Dienstverlener aanbieder geboden.	ext.abo.rollen.203
5.	Ten behoeve van het autoriseren van DVP Server voor toegang tot Subscription Server, in het kader van de functie (v3.0.1) Abonneren, zullen de betrokken User Agent, DVP Server, Authorization Server en Subscription Server gebruik maken van OAuth 2.0, waarbij als grant type gebruik wordt gemaakt van Authorization Code en waarbij: de rol van OAuth Resource Owner wordt verzorgd door de Persoon; de rol van OAuth Client wordt verzorgd door de DVP Server; de rol van OAuth Resource Server wordt verzorgd door de Subscription Server; de rol van OAuth Authorization Server wordt verzorgd door de Authorization Server. Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.rollen.206.	ext.abo.rollen.204
6.	Toelichting De keuze, in OAuth, voor de grant type Authorization Code past bij de typische software-architectuur die in MedMij in het Persoonsdomein wordt aangetroffen: toegang tot een PGO-dienst via componenten die niet onder controle van de OAuth Client vallen en als betrekkelijk onveilig moeten worden gezien. Als MedMij-verkeer is gedefinieerd: al het gegevensverkeer in het kader van enige usecase-implementatie, onmiddellijk tussen twee verschillende van de vier volgende soorten rollen, namelijk: ten eerste DVP Server of Notification Server, ten tweede User Agent, ten derde Authorization Server, Resource Server, Subscription Server of Notification Client, en ten vierde MedMij Registratie, met dien verstande dat: in deze rollen telkens begrepen zijn de door hen eventueel verzorgde respectievelijke Autorisatie-rollen, van deze rollen telkens uitgesloten zijn de door hen eventueel verzorgde Authenticatie-rollen, en in deze rollen, met betrekking tot de usecase-implementaties, telkens inbegrepen zijn de Nodes waarop zij functioneren. Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.rollen.207.	ext.abo.rollen.205
7.	Op één: Node functioneert hetzij één DVP Server, hetzij één Notification Server, hetzij de combinatie van één DVP Server en één Notification Server. Node functioneert hetzij één Authorization Server, hetzij één Resource Server, hetzij één Subscription Server, hetzij één Notification Client, hetzij een combinatie van voorgaande rollen. Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.rollen.301	ext.abo.rollen.300

Functies & gegevens

Abonneren

1.	Desgewenst biedt Dienstverlener persoon aan Persoon de functie (v3.0.1) Abonneren. Daarmee kan Persoon een Abonnement op Notificaties aangaan, verlengen, verkorten of beëindigen bij een Aanbieder, via Dienstverlener aanbieder. Deze Notificaties hebben betrekking op een Gegevensdienst. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.	ext.abo.abonneren.100
2.	Bij elke combinatie van Persoon, Dienstverlener persoon, Aanbieder en Gegevensdienst mag op elk moment maximaal één Abonnement actief zijn. De Aanbieder bepaalt de duur van het Abonnement.	ext.abo.abonneren.101
3.	Een Dienstverlener persoon of Dienstverlener aanbieder die de functie (v3.0.1) Abonneren aanbiedt, biedt ook de functie (v3.0.1) Notificeren aan.	ext.abo.abonneren.102
4.	Een Dienstverlener aanbieder die de functie (v3.0.1) Abonneren ondersteunt, beëindigt een Abonnement wanneer: het daartoe een verzoek van de Dienstverlener persoon ontvangt; de Dienstverlener aanbieder na het sturen van een Notificatie ontdekt dat Dienstverlener persoon het betreffende Abonnement niet kent. de looptijd van het Abonnement is verlopen; de Aanbieder de betreffende Gegevensdienst niet langer aanbiedt, of wanneer de Dienstverlener aanbieder de betreffende Gegevensdienst niet langer ontsluit. In deze situatie beëindigt de Dienstverlener aanbieder onverwijld alle betreffende Abonnementen. Toelichting Er worden geen eisen gesteld omtrent het beëindigen van een Abonnement ingeval (gezondheids)informatie van een Persoon niet langer beschikbaar is bij een Aanbieder, 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 Aanbieder; 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 aanbieder 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 aanbieder een eigen administratie bijhoudt van welke Gegevensdiensten hij voor welke Aanbieders ontsluit, en daarvoor niet leunt op de Zorgaanbiederslijst of andere lijsten. Zijn verwerkersrelaties met Personen zijn immers de bron van die lijsten, niet andersom. Het kan zijn dat de Dienstverlener aanbieder 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 aanbieder als verwerker voor de Aanbieder, met andere woorden, in het kader van de Dienstverleningsovereenkomst tussen die twee, en niet op het MedMij-koppelvlak.	ext.abo.abonneren.103
5.	Een Dienstverlener persoon die voornemens is het voeren van een zekere Gegevensdienst te beëindigen, of het voeren van Abonnementen te beëindigen, informeert daarover zijn gebruikers en laat, voor zover mogelijk, alle hierdoor getroffen lopende Abonnementen beëindigen.	ext.abo.abonneren.104
6.	Een Abonnement heeft een duur, gerekend in hele dagen vanaf het moment van aangaan, verlengen of verkorten. De Catalogus geeft bij elke Gegevensdienst de maximale duur aan van een Abonnement op die Gegevensdienst; is die maximale duur `0`, dan kunnen er op die Gegevensdienst geen Abonnementen worden aangegaan. De Aanbieder heeft, binnen de door de Catalogus aangegeven grenzen, ruimte voor eigen beleid aangaande de (maximale) duur van een Abonnement, gegeven de Gegevensdienst in kwestie. Dit wordt aangegeven in de Zorgaanbiederslijst. De Aanbieder heeft, binnen de in de Aanbiederslijst aangegeven grenzen, ruimte voor eigen beleid aangaande de (maximale) duur van een Abonnement, gegeven de Persoon in kwestie. Dit beleid maakt deel uit van de beschikbaarheidsvoorwaarde. De door een Persoon via zijn Dienstverlener persoon gevraagde duur van een Abonnement wordt gemaximeerd op de in de vorige drie punten bedoelde maximale duren. Toelichting 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 Aanbieder 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.	ext.abo.abonneren.105

Notificeren

1.	Een Dienstverlener persoon of Dienstverlener aanbieder mag de functie (v3.0.1) Notificeren aanbieden, als deze ook de functie (v3.0.1) Abonneren aanbiedt. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.	ext.abo.notificeren.100
2.	Een Notificatie hoort altijd bij slechts één Abonnement.	ext.abo.notificeren.101
3.	Er zijn twee soorten Notificaties: inhoudelijke Notificaties brengen Dienstverlener persoon (en mogelijk Persoon) op de hoogte van de beschikbaarheid van nieuwe (gezondheids)informatie van Aanbieder bij Dienstverlener aanbieder, betreffende een Gegevensdienst waarop Persoon bij die Aanbieder geabonneerd is; abonnements-Notificaties brengen Dienstverlener persoon (en mogelijk Persoon) op de hoogte van het door de Aanbieder, via Dienstverlener aanbieder, beëindigen van een Abonnement (zie verantwoordelijkheid 4 bij Abonneren).	ext.abo.notificeren.102
4.	Indien een Dienstverlener aanbieder bij een Aanbieder een wijziging detecteert in gezondheidsinformatie die hoort bij een Gegevensdienst waarop een Persoon bij die Aanbieder een op dat moment geldig Abonnement heeft, via een Dienstverlener persoon, voorziet die Dienstverlener aanbieder die Dienstverlener persoon van een zogenoemde inhoudelijke Notificatie, door middel van de functie (v3.0.1) Notificeren.	ext.abo.notificeren.103
5.	Indien een Dienstverlener aanbieder bij een Aanbieder een wijziging detecteert in een op dat moment geldig Abonnement dat een Persoon, via een Dienstverlener persoon, bij die Aanbieder is aangegaan, voorziet die Dienstverlener aanbieder die Dienstverlener persoon van een zogenoemde abonnements-Notificatie, door middel van de functie (v3.0.1) Notificeren.	ext.abo.notificeren.104
6.	De in verantwoordelijkheid 4 bij Abonneren bedoelde beëindiging leidt: niet tot een abonnements-notificatie in het eerste en tweede geval; wel tot een abonnements-notificatie in het derde en vierde geval.	ext.abo.notificeren.105

Opvragen Aanbiederslijst

1.

MedMij Beheer beheert en publiceert een Aanbiederslijst, namens de deelnemende Dienstverlener aanbieder. De gepubliceerde Aanbiederslijst bevat steeds en slechts alle actuele entries, en beschrijft van elke Aanbieder:

welke Gegevensdiensten deze momenteel aanbiedt, en welke technische adressen daarvoor moeten worden aangesproken bij de Dienstverlener aanbieder, gegeven een zekere Interfaceversie;
voor welke Gegevensdiensten het mogelijk is om Abonnementen aan te gaan en via welke technische adressen dit kan worden gedaan, gegeven een zekere Interfaceversie.

In deze release van het MedMij Afsprakenstelsel staat de Catalogus alleen Abonnementen toe op Gegevensdiensten die zijn gebaseerd op de functie (v3.0.1) Verzamelen.

Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.alst.100.

ext.abo.alst.100

Opvragen Whitelist

1.

De Node die

de TLS-server is, voert de in verantwoordelijkheid core.whl.306 bedoelde controle tegen de Whitelist geheel uit voordat enige volgende stap wordt gezet door de OAuth Authorization Server of OAuth Resource Server, volgens de specificaties van de functies (v3.0.1) Abonneren en (v3.0.1) Notificeren. Deze vereiste wordt volgordelijkheid genoemd. Indien de controle tegen de Whitelist niet kan worden uitgevoerd, of een negatief resultaat oplevert, wordt de procesgang onmiddellijk afgebroken en komt het niet tot een start van de uitvoering van die eerstvolgende stap. De controle tegen de Whitelist slaagt in dit geval dan en slechts dan als op de Whitelist tenminste een van de volgende namen uit het de door de TLS-client aangeboden certificaat voorkomen: de Common Name of een van de eventuele Subject Alternative Names.

Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.whl.307.

ext.abo.whl.300

Opvragen OAuth Client List

1.	MedMij Beheer beheert en publiceert een actuele OAuth Client List, namens de deelnemende Dienstverleners persoon. De gepubliceerde OAuth Client List bevat steeds en slechts alle actuele entries, en beschrijft van elke OAuth Client: wat de gebruikersvriendelijke namen zijn die voor de Dienstverleners persoon worden gebruikt in de Toestemmingsverklaring , de Bevestigingsverklaring en de Notificatie van Persoon; op welke Gegevensdiensten de Dienstverlener persoon het ontvangen van Notificaties, in het kader van een Abonnement, ondersteunt en op welke technische adressen deze Notificaties moeten worden afgeleverd, gegeven een zekere Interfaceversie. In deze release van het MedMij Afsprakenstelsel kunnen slechts Abonnementen worden aangegaan op Gegevensdiensten die zijn gebaseerd op de functie Verzamelen. Toelichting De OAuth Client List bevat dus geen namen voor Dienstverleners aanbieder. Dat is niet nodig, omdat deze niet voorkomen in de Toestemmingsverklaring. Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.ocl.100	ext.abo.ocl.100
2.	Notification Client implementeert de functie (v3.0.1) Opvragen OAuth Client List, door middel van het bepaalde inzake het interface voor OAuth Client List op (v3.0.1) Interfaces lijsten.. Hiervoor wordt het betreffende stroomdiagram gebruikt.	ext.abo.ocl.200
2.	Notification Client betrekt minstens elke vijftien minuten (900 seconden) de meest recente OAuth Client List (OCL) van MedMij Registratie.	ext.abo.ocl.201
2.	Notification Client valideert elke nieuwe verkregen OAuth Client List (OCL) tegen het XML-schema van de OAuth Client List. Dit XML-schema is een technische implementatie van het MedMij-metamodel.	ext.abo.ocl.202

Autorisatie

1.	Dienstverlener aanbieder vergewist zich ervan, elke keer opnieuw voordat hij Persoon een Abonnement met Aanbieder laat aangaan, dat deze Persoon uitdrukkelijk Toestemming heeft gegeven aan Aanbieder om Notificaties, betreffende de in de Gegevensdienst betrokken (gezondheids)informatie, aan Dienstverlener persoon ter beschikking te laten stellen. De vraag om Toestemming heeft een vaste formulering, die is opgenomen in de functie (v3.0.1) Abonneren. Toelichting Dienstverlener aanbieder handelt dus ook bij het beschikbaar kunnen stellen van Notificaties conform een Toestemming van de Persoon. Deze Toestemming wordt gegeven bij het aangaan van het Abonnement en blijft geldig voor de duur van het Abonnement.	ext.abo.autorisatie.100
2.	In de implementatie van de functie (v3.0.1) Abonneren handelen DVP Server enerzijds en Authorization Server en Subscription Server anderzijds, hun onderlinge verkeer af conform de standaard OAuth 2.0. Toelichting Conform wettelijke verplichting geeft Persoon, in de functie (v3.0.1) Abonneren, actief toestemming aan de Aanbieder. De User Agent presenteert een venster waarin de Persoon deze toestemming, respectievelijk bevestiging, kan geven. Aangezien in het persoonsdomein niet met BSN gewerkt mag worden, moet er een vervangende identificatie van de Persoon gebruikt worden.	ext.abo.autorisatie.200

Authenticatie

1.

Dienstverlener aanbieder draagt ervoor zorg dat de onder core.gegevensdiensten.103, core.gegevensdiensten.104, core.autorisatie.100, core.autorisatie.101 en ext.geguit.autorisatie.100 bedoelde vraag om Toestemming, respectievelijk bevestiging, slechts plaatsvinden wanneer hij de identiteit van de Persoon met passende zekerheid heeft vastgesteld.

Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.authenticatie.100

ext.abo.authenticatie.100

Adressering

1.	De OAuth Client stelt conform RFC 3986 de URI samen waarmee hij zichzelf, de Authorization Server en de Subscription Server adresseert. De Notification Client stelt conform RFC 3986 de URI samen waarmee hij de Notification Server adresseert. Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.adressering.200	ext.abo.adressering.200
2.	In alle adressering op de (v3.0.1) Subscription interface, de (v3.0.1) Subscription notification interface en de resource notification interface is het gebruik van het voor `https` bedoelde poortnummer, zoals opgenomen in de Service Name and Transport Protocol Port Number Registry van IANA, verplicht.	ext.abo.adressering.201
3.	Voor het samenstellen van alle adressen van het subscription request, betrekt de OAuth Client de eerste onderdelen van de URI, namelijk `host` en `path`, uit de Aanbiederslijst, op basis van de van toepassing zijnde Aanbieder, Interfaceversie en Gegevensdienst. Andere elementen van de algemene URI-syntax, zoals `user`, `password`, `query` en `fragment`, zijn afwezig in de adressen.	ext.abo.adressering.202
4.	De adressen voor de subscription notification en de resource notification betrekt de Notification Client uit de OAuth Client List, op basis van de van toepassing zijnde OAuth Client en Gegevensdienst.	ext.abo.adressering.203

Toelichting

De Aanbiederslijst wordt dus gebruikt door de OAuth Client om, gegeven een zekere Interfaceversie, het endpoint te kennen dat past bij de van toepassing zijnde Aanbieder, Gegevensdienst en, voor het resource endpoint, Systeemrol. Net zo gebruikt de Notification Client de OAuth Client List om, gegeven een zekere Interfaceversie, het endpoint te kennen dat past bij de van toepassing zijnde OAuth Client en Gegevensdienst. Daarom moet er uit één zo'n setje één endpoint-adres volgen. Andersom echter is dat geen eis. Het is mogelijk om, in elke door de Dienstverlener aanbieder gewenste combinatie, endpointadressen te hergebruiken voor meerdere van zulke setjes in de Aanbiederslijst, respectievelijk door de Dienstverlener persoon in de OAuth Client List.

Logging

1.	Dienstverlener persoon zal het Dossier zo inrichten dat deze ook dienst kan doen als logbestand van ontvangen Notificaties en aangegane Abonnementen.	ext.abo.logging.100
2.	Dienstverlener aanbieder zal een logbestand bijhouden van verzonden Notificaties en aangegane Abonnementen.	ext.abo.logging.101

Beveiliging

1.

In het gegevensverkeer voor de functies (v3.0.1) Abonneren en (v3.0.1) Notificeren, maken betrokken rollen gebruik van de functies Versleuteling, Server Authentication en Server Authorization.

ext.abo.beveiliging.200

Browser not supported