1. Inhoudsopgave

2. Probleembeschrijving

In het vooronderzoek zijn verschillende knelpunten benoemd op het gebied van signaleren, melden, analyseren en oplossen van verstoringen. Er blijkt onvoldoende inzicht te zijn in de verstoringen, zie hoofdstuk 2 Probleembeschrijving van het Vooronderzoek (die gedeeld is met de RFI) voor een uitgebreide analyse van het probleem.

Om verstoringen sneller te kunnen signaleren en melden is als de gewenste oplossingsrichting centrale monitoring van de gegevensuitwisseling tussen schakels in de MedMij keten benoemd. Dit document bevat het voorstel van de loggegevens die nodig zijn van de verschillende schakels in de MedMij keten, om deze centrale monitoring goed te kunnen doen. Concreet wordt in dit document de vraag beantwoord:

Welke loggegevens zijn nodig bij welke gegevensuitwisseling van welke deelnemer voor centrale monitoring van verstoringen in de MedMij keten?

2.1. Buiten scope

In dit document zijn de loggegevens uitgewerkt die deelnemers gaan delen wanneer zij Lijsten ophalen bij de MedMij Stelselnode en wanneer Personen gegevens gaan Verzamelen. De loggegevens voor het Delen van gegevens door Personen of voor Abonneren/notificeren zijn niet opgenomen in dit document. Het voorstel is om deze in een latere fase uit te werken.
Loggegevens die aanvullend nog gedeeld moet worden door deelnemers bij gebruikmaking van Langdurige Toestemming zijn ook niet opgenomen, omdat Langdurige Toestemming op dit moment nog wordt uitgewerkt.
Het definiëren van de ketennorm met betrekking tot beschikbaarheid, kwaliteit van gegevensuitwisseling, etc. is ook buiten scope. Ketennormen worden in een volgende fase uitgewerkt.
De uitbreiding van de managementrapportages. Een wens is om de indicatoren van de managementrapportages in de toekomst te berekenen op basis van de loggegevens.
De uitwerking van loggegevens in specificaties. En de afweging welke standaard wordt gebruikt (JSON of FHIR). FHIR wordt alleen in het Zorgdomein gebruikt en niet in andere domeinen, JSON wel.

3. Aanpak

Na het vooronderzoek en de expertsessie met deelnemers afgelopen 15 februari wordt de oplossing verder uitgewerkt in 2 delen:

Specificatie van loggegevens die door deelnemers gedeeld gaan worden voor centrale monitoring (uitvoering door Kailesh, Marlotte, Floor).
Opstellen van business requirements en selectie van ICT-oplossing voor het uitvoeren van de ketenmonitoring. Nog te bepalen

In dit document wordt gewerkt aan deel 1 volgens het onderstaande stappenplan (afgestemd met Jeroen 21/2)

Voorstel maken van de loggegevens die door deelnemers moeten worden gedeeld. Daarnaast hoe de beschikbaarheid van deelnemers gecontroleerd wordt middels een ping-functie.
Checken intern met juristen (Geranne, Jacqueline) en andere intern betrokkenen of het voorstel voldoet aan eerder gestelde randvoorwaarden rondom data proportionaliteit, het niet delen van concurrentie-gevoelige data en aan wetgeving, zie ook hfst 6.
Voorstel voorleggen aan deelnemers in een expertsessie.

De planning is om de benodigde aanpassingen in het afsprakenstelsel in de release van mei mee te nemen en in oktober verplicht te stellen.

4. Openstaande vragen

Hoe gaat MedMij om met het principe zo min mogelijk informatie toe te voegen over een FHIR code aan een bericht?

5. Uitwerking loggegevens

5.1. Overzicht van de transacties

De grijze bolletjes worden gelogd door de DVP, de blauwe bolletjes door de DVA en de groene bolletjes door MedMij zelf.
Afhankelijk van of de beschikbaarheidstoets laat of vroeg plaatsvindt worden de bolletjes 8 & 9 of 20 & 22 overgeslagen.
De groene bolletjes hebben letters in plaats van nummers, omdat deze het ophalen van de lijsten betreft. Deze lijsten dienen als voorbereiding worden opgehaald.

Het voorstel is dat van alle genummerde bolletjes de loggegevens gedeeld worden door deelnemers. Een toelichting van de bolletjes en lijntjes staat in onderstaande tabel:

Nummers	Naam	Van- Naar	Toelichting (bron MedMij afsprakenstelsel Verzamelen)	Nog openstaande vragen
A t/m I	Ophalen lijsten	DVP- MedMij Stelselnode en andersom DVA- MedMij Stelselnode en andersom	De DVP vraagt de ZAL (Aanbiederslijst), GNL (Gegevensdienstnamenlijst) of WHL (Whitelist) op, en de MedMij Stelselnode stuurt deze terug De DVA vraag de GNL, WHL of OCL (OAuth Client List) op en de MedMij Stelselnode stuurt deze terug.
1	Authorization Request verstuurd	User Agent naar DVA	De User Agent verstuurt een authorization request naar de Authorization Server van de DVA.	Geinitieerd vanuit useragent en dus ontbetrouwbaar. De stap voor 1 is belangrijker omdat we juist de 'betrouwbare' DVP en DVA willen gebruiken. Dit geldt ook voor stap 4
2	Authorization Request ontvangen	User Agent naar DVA	De Authorization server van de DVA ontvangt het Authorization request.
3	Tonen MedMij Landingspagina	DVA naar User agent	De Authorization server van de DVA heeft het Authorization request ontvangen. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren en presenteert de landingspagina.	Betekent dit dat de DVA Authorization server een Sessie ID creëert per gebruiker?
4	Redirection naar Authentication server	User Agent naar DigiD	Dan start de Authorization Server van de DVA (nu in de rol van Authentication Client) de authenticatieflow door de User Agent naar de Authentication Server te redirecten. Dit gebeurt onder meegeven van een `redirect_uri`, die aangeeft waarnaartoe de Authentication Server straks de User Agent moet terugsturen, na het inloggen van de Persoon.	Geinitieerd vanuit useragent en dus ontbetrouwbaar. De stap voor 1 is belangrijker omdat we juist de 'betrouwbare' DVP en DVA willen gebruiken. Dit geldt ook voor stap 4
	Redirection naar Inlogpagina	DigiD naar User Agent
	Inloggen	User Agent naar DigiD	De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
	Redirection naar Authorization server (SAML artifact)	DigiD naar User Agent	Wanneer de inloggegevens juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs.	Klopt het dat de redirection van DigiD naar de DVA verloopt via de User Agent? Wanneer het inloggen is afgebroken geeft de Authorization Server de Persoon alsnog de mogelijkheid via zijn User Agent in te loggen. Wijzig hier dan de Sessie ID of het Trace ID?
5	Ga naar redirect_uri DVA (SAML artifact)	User Agent naar DVA		Gebeurt een eventuele nieuwe inlogpoging onder dezelfde Sessie ID van de DVA Authorization server?
6	Artifact resolution (SAML artifact)	DVA naar DigiD	Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.
7	Artifact response (SAML assertion)	DigiD naar DVA	Verzonden Authorization response van DigiD naar DVA
8	Vroege beschikbaarheidstoets opgevraagd	DVA naar DVA	Bij een vroege beschikbaarheidstoets wordt voorafgaand aan het resource request gecontroleerd of er Gegevensdienst voor uitwisseling beschikbaar is. Hierbij wordt het opvragen van de beschikbaarheid gelogd.	Is deze beschrijving zo correct?
9	Vroege beschikbaarheidstoets antwoord	DVA naar DVA	De ontvangst van het antwoord wordt ook gelogd.	Is deze beschrijving zo correct?
10	Tonen Toestemmingspagina	DVA naar User Agent	Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst, of wanneer géén gebruik wordt gemaakt van dit vroegste moment van de beschikbaarheidstoets, dan presenteert de Authorization Server via de User Agent aan Persoon in een Toestemmingsverklaring, de vraag of Persoon de Aanbieder toestaat de gevraagde persoonlijke gezondheidsinformatie aan de DVP Server (als OAuth Client) te sturen. Indien op dit moment al bekend is dat een bepaalde Gegevensdienst niet beschikbaar is voor de Persoon, dan mag deze niet worden opgenomen in de Toestemmingsverklaring.
11	Toestemming geven	User Agent naar DVA	Toestemming wel/niet ontvangen.
12	Redirection naar DVP server (Authorization response, OAuth authorization code)	DVA naar User agent	Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een User Agent redirect met de in het authorization request ontvangen `redirect_uri`, naar de DVP Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de DVP Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren. De DVP Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de toestemming is gegeven en logt het verkrijgen van het ophaalbewijs.
13	Ga naar redirect URI DVA (OAuth authorization code)	User agent naar DVP
14	Token request sent	DVP naar DVA	Met dit ophaalbewijs wendt de DVP Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de User Agent, voor een access token.
15	Token request received	DVP naar DVA	Acces token request ontvangen.
16	Token response sent	DVA naar DVP	Daarop genereert de Authorization Server een access token en stuurt deze naar de DVP Server.
17	Token response received	DVA naar DVP	DVA token response ontvangen.
18	Resource request sent	DVP naar DVA	Nu is de DVP Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen, nadat hij de Persoon eventueel nog nadere keuzes heeft laten maken. Het adres van de juiste resource endpoints haalt hij uit de Aanbiederslijst. Hij plaatst telkens het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
19	Resource request received	DVP naar DVA	DVA heeft het resource request van DVP ontvangen. De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op.
20	Late beschikbaarheidstoets verstuurd	DVA naar DVA	DVA beschikbaarheidsverzoek verstuurd	Is deze beschrijving zo correct?
21	Late beschikbaarheidstoets ontvangen	DVA naar DVA	DVA beschikbaarheidsverzoek antwoord is ontvangen. De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op. Dan breekt het uiterste moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft.	Is deze beschrijving zo correct?
22	Verzamelen gegevens verzonden	DVA naar DVA
23	Verzamelen gegevens ontvangen	DVA naar DVA	Is de Gegevensdienst beschikbaar, dan verstuurt de Resource Server deze ze in een resource response naar de DVP Server.
24	Resource response sent	DVA naar DVP
25	Resource response received	DVA naar DVP	DVP Resource Response ontvangen. De DVP Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. De DVP Server bevraagt de Resource Server daarna mogelijk opnieuw, eventueel na nieuwe interactie met de Persoon. Zolang het access token geldig is, kan dat.

5.2. Te loggen variabelen

Variabele	Toelichting	Waarom belangrijk	Voor welke transacties (zie tabel paragraaf 4.1)	Opmerkingen/vragen
InterfaceversieID	De identifier van de interfaceversie. String van minimaal één en maximaal 30 tekens. Interfaces zijn geversioneerd: verschillende versies van interfaces kunnen tegelijkertijd op het MedMij-netwerk worden aangeboden. Daarom is er de klasse Interfaceversie in het modelgebied Changes. Alle endpoints in de Zorgaanbiederslijst en Oauth Client List (zie onder) horen bij één Interfaceversie. Zie /wiki/spaces/MMVerplicht/pages/132023555	Dit is belangrijk voor foutopsporing. Want een versie verschil kan verstoringen in de gegevensuitwisseling tussen deelnemers veroorzaken.	Alle
Versie van de opgehaalde lijsten (ZAL, OCL, WHL, GNL)	De versie van de lijsten die een deelnemer ophaalt bij de MedMij Stelselnode	Zie boven	A t/m I
Type en versie PGO	Webapp of app en het OS gelogd te worden	Foutopsporing. Fouten komen soms alleen in de webinterface voor. Of niet in de app van Apple, maar wel in de app van Android	Voorstel: Alle logmomenten van de DVP of User Agent. Dit zijn: 1,4, 13,14,17,18,25?	Moet ook de gebruikte browser gelogd worden door de PGO-gebruiker bij Webapp?
Naam en gebruikte versie van de DVA	Naam van de DVA applicatie en de gebruikte versie	Foutopsporing	Voorstel: Alle logmomenten van de DVA Agent. Dit zijn: 2,3, 5 t/m 7, 10 t/m 12, 15, 16, 19 t/m 24
Naam en gebruikte versie van bronsysteem van de Zorgaanbieder	Naam van bronsysteem die de Zorgaanbieder gebruikt en de gebruikte versie	Foutopsporing	Voorstel: Alle mogelijke momenten van gegevensuitwisseling tussen DVA en bronsysteem Zorgaanbieder. Dit zijn: 8,9 20 t/m 23	Kan dit? Of moet eerst de Zorgaanbieder deelnemer zijn in het afsprakenstelsel?
Trace ID voor gegevensuitwisseling in de MedMij-keten voor Verzamelen of Delen	Een Trace-ID is een uniek ID om de gegevensuitwisselingen over alle schakels in de MedMij keten te kunnen volgen, van Authorization Request (1) naar de uiteindelijke Resource response(s) (19) De DVP stuurt een Trace-ID mee bij het versturen van het verzoek voor het verzamelen of delen van gegevens naar een DVA. Dit Trace-ID wordt door alle schakels in de MedMij-keten vervolgens opgenomen in de logging van de gegevensuitwisselingen die volgen op het verzoek van de DVP.	Een Trace ID in de logging is belangrijk om de kwaliteit van de gegevensuitwisseling in de gehele MedMij keten te kunnen bepalen. Zoals het aantal succesvolle en niet succesvolle opvragingen in de gehele MedMij keten. Daarnaast voor foutopsporing wanneer melding wordt gedaan van verstoringen.	1 t/m 25	Nog uitgewerkt moet worden hoe de Trace-id oplossing precies gaat werken.
Trace ID voor het ophalen van lijsten door deelnemers bij de MedMij Stelselnode	Er wordt ook een Trace-ID meegestuurd vanuit de DVP en DVA naar de MedMij StelselNode bij het ophalen van de lijsten (ZAL, WHL, etc). Dit Trace-ID wordt door de MedMij-Stelselnode vervolgens ook opgenomen in de logging, in de opvolgende transacties.	Zie boven	A t/m I	Zie boven.
Authorization request ID	Identifer van de authorization request. Met dit ID kan de gegevensuitwisseling na de authorization request tot de authorization response gevolgd worden over de schakels.	Dit is belangrijk voor het bepalen van het aantal succesvolle en onsuccesvolle authorization responses op een authorization request (kwaliteit van gegevensuitwisseling) En voor foutopsporing bij deze gegevensuitwisseling	1 t/m 13?
Token request ID	Identifer van de token request. Met dit ID kan de gegevensuitwisseling na de token request tot de token response gevolgd worden over de schakels.	Dit is belangrijk voor het bepalen van het aantal succesvolle en onsuccesvolle token responses op een token request (kwaliteit van gegevensuitwisseling) En voor foutopsporing bij deze gegevensuitwisseling	14 t/m 16	Zie boven
Resource request ID	Identifer van de resource request. Met dit ID kan de gegevensuitwisseling na de resource request tot de resource response gevolgd worden over de schakels. Dit is in het huidige MedMij-request-ID, zie link naar betreffend onderdeel in Afsprakenstelsel.	Dit is belangrijk voor het bepalen van het aantal succesvolle en onsuccesvolle resource responses op een resource request (kwaliteit van gegevensuitwisseling) En voor foutopsporing bij deze gegevensuitwisseling	18 t/m 25?	Er is een al een MedMij-request-ID beschikbaar, die gelogd wordt door een DVA bij het verzenden en ontvangen van resource requests zie link naar betreffend onderdeel in Afsprakenstelsel. Deze informatie is nu opgehaald over de het MedMij-request-ID. Het MedMij-request-ID is (na een RFC ingediend door Maarten Schmidt in 2019-2020) geïmplementeerd door een DVA in geval van een resource request richting een Zorgaanbieder. (De aanleiding voor deze RFC was een security incident).
Event DateTime	Datum en tijdstip van het verzenden of ontvangen van het bericht. Gewenst is dat deelnemers een datum en tijdstip vast leggen tot op de milliseconde. Het afsprakenstelsel schrijft het volgende voor over synchronisatie van de gebruikte klok, zie [1] "De klokken van IT componenten die communiceren via MedMij en logging in het kader van MedMij bijhouden, MOETEN worden gesynchroniseerd met pool.ntp.org. Het is toegestaan te synchroniseren met een alternatieve NTP-server, wanneer maatregelen zijn getroffen om de afwijking met pool.ntp.org niet groter dan plus of min 500 ms te laten zijn."	Event_DateTime van de gegevensuitwisselingen zijn nodig om de doorlooptijden van een transactie te meten. Een grote doorlooptijd kan wijzen op een verstoring of een (poging tot) hacking.	Alle	Niet alle deelnemers leggen de timestamp vast volgens dezelfde klok.
Endpoint van elk request en response	Authorization Endpoint van de Authorization Server OAuth Client (`redirect_uri)` Token Endpoint van de Authorization Server Resource Endpoint van de Resource Server	Hieruit kan bepaald worden tussen welke schakels in de keten de gegevensuitwisseling heeft plaatsgevonden.		Is het lijstje met endpoints van requests en responses compleet?
Deelnemer ID	De gebruikte identifier van de deelnemer (DVP of DVA) binnen het MedMij afsprakenstelsel. Dit is client_id voor de DVP.	Het deelnemer ID is nodig om de kwaliteit en trends in gegevensuitwisseling per deelnemer of per combinatie van deelnemers te kunnen bepalen. Daarnaast voor foutopsporing. Tenslotte voor het testen van de bereikbaarheid per deelnemer	Alle	Is dit nodig? Of is het voldoende om het endpoint te loggen? wat is de gebruikte identifier voor DVA?
Deelnemer FQDN	De fully-qualified domain name van een deelnemer conform RFC3696, sectie 2. Zie ook /wiki/spaces/MMVerplicht/pages/132023613	Zie boven	Alle
Zorgaanbieder ID	De gebruikte identifier van een Zorgaanbieder binnen het MedMij afsprakenstelsel.	Zie deelnemer ID	1 t/m 25?
Lijst ID	Identifier van een lijst (ZAL, WHL, OCL, GNL)	Het lijst ID is nodig om de kwaliteit en trends in gegevensuitwisseling per lijst te kunnen bepalen. Daarnaast voor foutopsporing	A t/m I
Lijst FQDN	De fully-qualified domain name van de lijsten (ZAL, WHL, OCL, GNL)	Zie boven	A t/m I	Is Lijst FQDN de juiste term?
Sessie ID	Een Sessie ID knoopt meerdere handelingen van één persoon bij dezelfde applicatie aan elkaar. Bijvoorbeeld meerdere resource requests bij de DVP. Of meerdere pogingen tot inloggen bij de Authorization Server van de DVA	Een sessie ID kan helpen bij foutopsporing. Bijvoorbeeld om te bepalen of een hoge frequentie van foutmeldingen veroorzaakt wordt door dezelfde gebruiker of verschillende gebruikers	1,4, 18,19?
Gepseudonimiseerd user- ID?	Dit betreft een random nummer wat toegekend wordt door een deelnemer aan een gebruiker. Dit nummer heeft geen correlatie met het BSN en betreft een niet-traceerbaar-ID. Maar met dit nummer is wel te achterhalen of dezelfde gebruiker een actie uitvoert bij een deelnemer of een andere gebruiker Momenteel maken DVP's gebruik van een User-ID. Dit zorgt ervoor dat zij meerdere gestarte sessies van gebruikers binnen een paar milliseconden van elkaar kunnen onderscheiden.	Om te achterhalen of dezelfde fout in de gegevensuitwisseling voorkomt bij dezelfde gebruiker die meerdere keren dezelfde actie uitvoert. Of dat dezelfde fout in de gegevensuitwisseling bij verschillende gebruikers voorkomt.		Is dit nodig, als er ook een sessie-ID wordt vastgelegd? Nog te bespreken of dit wel wenselijk is vanuit privacy oogpunt
Gegevensdienst ID	Identifier van de gegevensdienst(en) die onderdeel zijn van de gegevensuitwisseling. Het ID geeft aan welke gegevensdienst het is en welke versie.	Dit is belangrijk voor het bepalen van de kwaliteit van de gegevensuitwisseling per gegevensdienst. Daarnaast voor foutopsporing: Komen bepaalde verstoringen alleen voor bij specifieke gegevensdiensten? Verder voor managementrapportages: inzicht in toe- of afname van de gebruikte gegevensdiensten.	1 t/m 25?	Opmerking Bouke: Als er verschillende versies van een standaard actief zijn (door middel van verschillende gegevensdiensten) lijkt het me een taak van regie? om dat samen te brengen in een rapportage
Resource ID	Identifier van de verstuurde of ontvangen resources. De identifier geeft het type resource aan.		18 t/m 25?	Ook de versie van de resource is voor rapportages zeer relevant. Zij er problemen bij de gegevensuitwisseling bij een specifieke versie van de resource? De versie van de resource hoeft niet gelogd te worden. Maar moet op een andere manier verkregen worden dan uit aangeleverde logging. Bekend is immers per gegevensdienst welke versie van de resources daar gebruikt worden.
De omvang van het bericht	Grootte van het bericht (aantal bits)	Voor foutopsporing: de grootte van het bericht kan een oorzaak zijn van een verstoring. Opsporing van mogelijke hacking-poging: extreme grote of kleine berichten kunnen duiden op een poging tot hacking.	Alle?
Soort bericht	Twee soorten berichten van deelnemers worden onderscheiden. Berichten waarin de logging van events staan en berichten met het resultaat van een ping op bereikbaarheid, zie hoofdstuk 6.		Alle?
Resultaat (Succes of Foutcodes)	Bij de verschillende gegevensuitwisselingen in de MedMij keten (de authorization request en response, token request en response en resource requests en response) kunnen er fouten optreden Gewenst is om foutcodes voor een aantal veelvoorkomende fouten te delen in de logging van de deelnemers.	Foutopsporing	Alle, de mogelijke foutcodes verschillen echter per gegevensuitwisseling	Nog te bepalen welke foutcodes per type gegevensuitwisseling (de authorization request en response, token request en response en resource requests en response gedeeld moeten worden in de logging. De foutcodes volgens OAuth 2.0 staan uitgewerkt in MO-39 Duiding van errors. Zie daarnaast hoofstuk 6
Status langdurige toestemming	Dit is voor de toekomst. De status van langdurige toestemming die een PGO-gebruiker heeft gegeven per Zorgaanbieder per gegevensdienst. De status kan zijn: Geen toestemming of wel toestemming.			Te bespreken met Casper: kan hierover al iets opgenomen worden in de loggegevens?
*Aanvullingen?*

6. Foutcodes en foutomschrijvingen

Onderstaande foutcodes zijn op basis van OAuth 2.0 en DigiD (SAML-resultcodes). Dit staat ook in het afsprakenstelsel onder Authorization interface, Token interface, Resource interface, behalve het SAML deel.

6.1. OAuth 2.0 foutcodes

Hieronder staan de fouten die kunnen optreden bij de verschillende interfaces volgens OAuth 2.0.

Authorization interface:

Het verzoek vanuit de User Agent richting de AS van Deelnemer Aanbieder op het Authorization interface.

^{Error Response}	Error code
HTTP 400 (Bad Request)	^{invalid_request}
	^{invalid_client}
	^{invalid_grant}
	^{unauthorized_client}
	^{access_denied}
	^{unsupported_response_type}
	^{invalid_scope}
HTTP 404 (Not Found)

Token interface:

Het verzoek vanuit de DVP server richting de AS van Deelnemer Aanbieder voor het ophalen van de access token bij de token interface.

^{Error Response}	Error code
HTTP 400 (Bad Request)	^{invalid_request}
	^{invalid_client}
	^{invalid_grant}
	^{unauthorized_client}
HTTP 401 (Unauthorized)
HTTP 404 (Not Found)

Resource interface:

Het verzoek door de DVP server bij de resource server voor het ophalen van de resources met het verkregen access token

^{Error Response}	Error code
HTTP 400 (Bad Request)	^{invalid_request}
HTTP 401	invalid_`token`
HTTP 403	`insufficient_scope`
	`access_denied`
HTTP 404 (Not Found)

6.2. DigiD foutcodes

De authenticatie bij DigiD voor het ophalen van het SAML artifact kan leiden tot verschillende foutcodes. Deze SAML-foutcodes worden gecommuniceerd naar de DVA.

De foutcodes die kunnen voorkomen zijn:

urn:oasis:names:tc:SAML:2.0:status:AuthnFailed	Wanneer de eindgebruiker het inloggen annuleert. Wanneer de eindgebruiker niet de juiste sector heeft.
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext	Wanneer de eindgebruiker niet kan voldoen aan het gevraagde betrouwbaarheidsniveau.
urn:oasis:names:tc:SAML:2.0:status:PartialLogout	Wanneer de eindgebruiker niet uitgelogd kan worden bij alle dienstaanbieders (Bijv. als een dienstaanbieder niet reageert).
urn:oasis:names:tc:SAML:2.0:status:RequestDenied	Een SAML-responder die weigert een berichtuitwisseling met de SAML-aanvrager uit te voeren moet een reactie bericht geven met een deze foutcode.

7. Uitwerking ping-functie

De ping-functie wordt in gebruik genomen om te kunnen testen of de servers van de aangesloten partijen bereikbaar zijn. Hierbij is geen inzage in eventuele fouten, maar wel of verkeer mogelijk is richting de servers. Door het pingen kunnen evt. verstoringen/fouten voor de Persoon worden voorkomen bijvoorbeeld een HTTP404, daarnaast heeft de ping-functie ook als voordeel de bereikbaarheid te testen van partijen die niet of nauwelijks verkeer hebben. De ping-functie is nodig als MedMij Regie richting een ketennorm streeft (bereikbaarheid icm kwaliteit van opvragingen).

7.1. MedMij stelselnode

De deelnemers halen ieder kwartier de MedMij-lijsten op bij 'Registratie' van de MedMij stelselnode. De inhoud van deze lijsten is gevuld door de deelnemers bij 'Administratie' van de MedMij stelselnode. Het afsprakenstelsel geeft momenteel aan dat 'MedMij Beheer laat, na het niet beschikbaar raken van bedoelde aandeel, maximaal acht uren (480 minuten) verstrijken voordat het weer beschikbaar is.' Om tijdig de onbereikbaarheid te kunnen achterhalen is het van belang beide onderdelen te pingen.

7.2. Medmij naar DVP

Het is goed om inzage te krijgen in de bereikbaarheid van alle DVP's om daarmee het streven van de IZA te kunnen bereiken om te kunnen voorzien van een PGO voor een ieder die er behoefte aan heeft. Op basis van de DAP en de oplostijden horend bij de prioriteiten is het voorstel ieder kwartier de DVP's te pingen.

7.3. MedMij naar DVA

Een ping is nodig richting de DVA's voor de bereikbaarheid en mogelijke verklaring van verstoringen. Op basis van de DAP en de oplostijden horend bij de prioriteiten is het voorstel de DVA's ieder kwartier te pingen.

7.4. DVA naar Zorgaanbieder

Van de DVA's wordt verwacht dat zij de Zorgaanbieders gaan pingen. Dit zorgt voor inzage in de bereikbaarheid van Zorgaanbieders waarmee weinig verkeer is, als gevolg kunnen deze Zorgaanbieders op een blacklist komen. De blacklist kan gebruikt worden om de Persoon te informeren over onbeschikbaarheid van de geselecteerde Zorgaanbieder. Op basis van de DAP en de oplostijden horend bij de prioriteiten is het voorstel ieder kwartier de Zorgaanbieders te pingen.

7.5. DigiD beschikbaarheid inzichtelijk via storingsmeldingen van DigiD

Er is een app aanwezig genaamd eFlash waarmee er inzage is in de beschikbaarheid van een ToegangVerleningsservice (waaronder eHerkenning en DigiD) : https://apps.dictu.nl/eflash. Daarnaast is het niet toegestaan om DigiD te pingen.

8. Randvoorwaarden

Nr	Randvoorwaarde	Toelichting	Wordt aan deze randvoorwaarde voldaan? Dit wordt gecheckt nadat hfst 3 en 4 zijn uitgewerkt met Geranne, Jacqueline, kernteam, etc.
1.	Er worden geen persoonsgegevens gedeeld in de gedeelde loggegevens alleen transactiegegevens.	Voor ketenmonitoring zijn transactiegegevens voldoende. Vanuit de DVP's en DVA's wordt verder het aantal unieke accounts aangeleverd voor de managementrapportages. Het precieze aantal unieke PGO-gebruikers per Zorgaanbieder in Nederland kan met deze aangeleverde indicator door DVP's en DVA's niet berekend worden. Aangegeven is door management en adviseurs (zie vooronderzoek) dat trendinformatie voldoende is om inzicht te hebben in verslechtering of verbetering en te kunnen sturen. Het exacte aantal PGO-gebruikers in Nederland is niet nodig.
2.	Gegevens die deelnemers delen met MedMij en VZVZ voor het signaleren, melden, analyseren en oplossen van verstoringen en voor managementrapportages is proportioneel met de informatiebehoefte	Er wordt duidelijk beschreven welke gegevens nodig zijn voor welk doeleinde en welke informatiebehoefte. Er worden niet meer loggegevens gedeeld van deelnemers dan nodig is voor de informatiebehoefte
3.	Er wordt voldaan aan vigerende wetgeving zoals de AVG	· Er mogen geen persoonsgegevens gedeeld worden of medisch inhoudelijke gegevens alleen transactie gegevens. · Geen gebruik van BSN’s of andere privacygevoelige informatie Opmerking: Wanneer de scope toch mocht veranderen, en het wel persoonsgegevens gewenst wordt om persoonsgegevens te delen, verandert de doorlooptijd van het project aanzienlijk. Omdat er dan aanvullende contracten nodig zijn tussen de betrokkenen voor afspraken over het gebruik van de persoonsgegevens. Een rechtmatige grondslag voor de verwerking is vereist.
4.	Er wordt zorgvuldig omgegaan met concurrentie-gevoelige informatie	Deelnemers hebben geen inzage in de activiteiten van andere deelnemers tenzij dit noodzakelijk is voor het oplossen van verstoringen.
5.	Er wordt zorgvuldig omgegaan met loggevens die misbruikt kunnen worden door hackers. Vanuit het oogpunt van informatieveiligheid.
	Aanvullingen?	De ping functionaliteit test en verifieert bij voorkeur dat de 'applicatie' werkt. Vergelijkbaar met een HL7 ping versus TCP/IP ping (OSI-3). De laatste test alleen netwerkconnectivitiet de eerste de applicatieconnectiviteit op HL7 niveau (OSI-7) De ping functie zorgt niet voor extra gat in de beveiliging! Het MedMij netwerk backchannel is besloten en alleen partijen die onderdeel van het MedMij netwerk zijn mogen daar toegang toe krijgen obv van de whitelist. Dit zou voor de ping fucntionalitiet ook moeten gelden. Zowel de DVP als DVA hebben publieke ingang die naar mijn idde te gebruiken zijn voor een connectiviteitstest.

9. Referenties

A.12.4.4 Kloksynchronisatie

Browser not supported