1. Inhoudsopgave

2. Probleembeschrijving

In het vooronderzoek zijn verschillende knelpunten benoemd op het gebied van signaleren, melden, analyseren en oplossen van verstoringen. Er is dus onvoldoende inzicht in 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 centrale monitoring van de gegevensuitwisseling tussen schakels in de MedMij keten benoemd als de gewenste oplossingsrichting. 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?

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 onderstaand 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 ping-functie
Checken intern met juristen (Geranne, Jacqueline) en andere intern betrokkenen of voorstel voldoet aan eerder gestelde randvoorwaarden rondom dataproportionaliteit, niet delen van concurrentie-gevoelige data en aan wetgeving, zie ook hfst 6.
Voorstel voorleggen aan deelnemers in een volgende 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. De uitbreiding van de managementrapportages op basis van de loggegevens, wordt pas na oktober gedaan.

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 Personenen of voor Abonneren/notificeren zijn niet opgenomen in dit document. Het voorstel is om deze in een latere fase uit te werken.
Log-gegevens die aanvullend gedeeld moet worden door deelnemers bij gebruikmaking van Langdurige Toestemming zijn ook niet opgenomen. Want Langdurige Toestemming wordt op dit moment nog uitgewerkt.
Definitie van de ketennorm met betrekking tot beschikbaarheid, kwaliteit van gegevensuitwisseling, etc. is ook buiten scope. Ketennormen worden in een volgende fase uitgewerkt.

4. Openstaande vragen

Omdat MedMij berichten over het openbare internet gaan is het ontwerp van MedMij erop gericht zo min mogelijk informatie toe te voegen over een FHIR code aan een bericht. Hoe hiermee om te gaan?

5. Uitgangspunten

De loggegevens worden vastgelegd volgens JSON-specificaties. Dit moet nog wel uitgewerkt worden door solution architect. FHIR is de andere optie. Echter FHIR wordt alleen in het Zorgdomein gebruikt en niet in andere domeinen. Daarom is niet voor FHIR gekozen maar voor JSON.

6. Uitwerking loggegevens

6.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. Het adres van het authorization endpoint komt uit de ZAL. Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten.
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.
	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. ~~Wanneer het inloggen is afgebroken geeft de~~ ~~Authorization Server~~ de ~~Persoon~~ ~~alsnog de mogelijkheid via zijn~~ ~~User Agent~~ ~~in te loggen.~~	Klopt het dat de redirection van DigiD naar de DVA verloopt via de User Agent?
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.
9	Vroege beschikbaarheidstoets antwoord	DVA naar DVA	De ontvangst van het antwoord wordt ook gelogd.
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 (SAML-artifact)	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
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.
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.

6.2. Te loggen variabelen

Variabele	Toelichting	Waarom belangrijk	Voor welke transacties (zie tabel paragraaf 4.1)	Voor welke meetpunten /indicatoren (NOG IN TE VULLEN)	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
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
Authorization request ID	Identifer van de authorization request. Dt is het huidige MedMij-request-ID, zie link naar betreffend onderdeel in Afsprakenstelsel. 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 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.
Deelnemer ID	De gebruikte identifier van de deelnemer (DVP of DVA) binnen het MedMij afsprakenstelsel. Dit is een string van minimaal één en maximaal 30 tekens, zie /wiki/spaces/MMVerplicht/pages/132023555	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		Dit is het koppelvlak richting CMS systeem van allsolutions. Zorgen dat we daar hetzelfde ID hebben
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?		Dit is een belangrijk koppelvlak richting de R&A bron
Zorgaanbieder FQDN	De fully-qualified domain name van een Zorgaanbieder	Zie boven.	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.	Met name om te zien of het gebruikers terugkeren of eenmalig het PGO gebruiken. Inzicht in of het de gebruiker uiteindelijk lukt om gegevens op te halen (ondanks mogelijk meerdere verschillende verzoeken)		Aantal unieke gebruikers over tijd	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. He 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?
Resource ID	Identifier van de verstuurde of ontvangen resources. De identifier geeft het type resource aan.		18 t/m 25?
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.3. Indicatoren voor dashboard gebaseerd op ruwe data

De onderstaande tabel logt de volgende variabelen standaard bij elke indicator: ID, FQDN Deelnemers en Zorgaanbieder Event DateTime, Trace-ID. De inhoud van deze tabel moet nog verder uitgewerkt worden. Ntb wie dit gaat doen Wouter, Jennifer en/of Kailesh, Marlotte, Floor.

Indicator	Definitie	Interfaces	Benodigde loggegevens	Bepalen per	Doelen
Aantal succesvolle en niet succesvolle opvragingen	Aantal succesvolle en niet succesvolle opvragingen binnen een bepaald tijdsbestek, die leiden tot: een volledig succesvolle ophaling (alle gevraagde resources/gegevens zijn succesvol in de PGO verzameld) deels succesvolle ophaling (een deel van de gevraagde resources/gegevens zijn succesvol in de PGO verzameld) of onsuccesvol (geen van de resources/gegevens zijn succesvol in de PGO verzameld)	1 - Authorization request 25-Resource response	ID gegevensdiensten Type (ID) opgevraagde resources Type (ID) ontvangen resources Resultaat (succes, of foutcode)	Succesvol en onsuccesvol in percentages en absolute aantallen: per DVP per DVA per Zorgaanbieder per gegevensdienst per type resource (gegeven) DVP & DVA combinatie DVA & Zorgaanbieder combinatie Daarnaast per combinatie van variabelen. Bijvoorbeeld aantal succesvolle opvragingen voor alle gegevensdiensten voor deze combinatie van DVP en DVA	Er is nu onvoldoende inzicht in de kwaliteit van de gegevensuitwisseling in de gehele MedMij keten, zie knelpunt A hfdst 2 uit het Vooronderzoek Voor inzicht in de kwaliteit van de keten is inzicht in het resultaat van de totale aantal opvragingen in de gehele MedMij keten gewenst.
Aantal succesvolle en onsuccesvolle Authorization requests van DVP naar DVA	Aantal succesvolle en niet succesvolle authorization requests binnen een bepaald tijdsbestek van DVP naar DVA	1 - Authorization request 13 - Authorization response	Sessie ID Resultaat (succes, of foutcode)	Succesvol en onsuccesvol in percentages en absolute aantallen: per DVP per DVA en combinaties hiervan Daarnaast is voor de onsuccesvolle authorization requests waarschijnlijk een onderverdeling naar foutcode gewenst (verder te bepalen) zoals: afgebroken door gebruiker foutmelding x DVA foutmelding y DVA ...	Voor inzicht in de kwaliteit van de keten is inzicht in de gegevensuitwisseling per interface zoals de Authorization interface gewenst, zie ook doel bij Geslaagde aantal opvragingen Daarnaast voor inzage in eventuele verstoringen bij deelnemers bij de Authorization interface, zie ook knelpunt C in hfdst 2 uit het Vooronderzoek. En voor het sneller kunnen achterhalen van de bron en oorzaak van een verstoring, zie ook knelpunt D in hfdst 2 uit het Vooronderzoek.
Aantal succesvolle en onsuccesvolle DigiD authenticatie	Aantal succesvolle en onsuccesvolle DigiD authenticaties binnen een bepaald tijdsbestek	4,5,6,7?	Sessie ID Resultaat (succes, of foutcode). Bijvoorbeeld SAML-Assertion: Succes, Authnfailed, NoAuthncontext, RequestDenied, evt. Abandoned	Resultaten SAML Per DVA DVA overall Daarnaast is voor de onsuccesvolle authenticaties waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals: afgebroken door gebruiker gebruiker heeft verkeerd ww ingevuld DVA ontvangt technische foutmelding DigiD ...	Zie doelen 'Geslaagde Authorization requests DVP naar DVA' Inzicht krijgen in de authenticatie per DVA en overall om te achterhalen of alleen een specifieke DVA een verstoring ervaart bij de DigiD-authenticatie. Of dat de verstoring ligt bij DigiD en alle DVA's een verstoring ervaren.
Aantal succesvolle en onsuccesvolle Token requests	Aantal succesvolle en onsuccesvolle DigiD token requests binnen een bepaald tijdsbestek	14 t/m 17	Gegevensdienst ID Sessie ID Resultaat (succes, of foutcode).	Succesvol en onsuccesvol in percentages en absolute aantallen: per DVP per DVA per gegevensdienst En combinaties hiervan Daarnaast is voor de onsuccesvolle Token requests waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals: afgebroken door gebruiker foutmelding x foutmelding y ...	Zie doelen 'Geslaagde Authorization requests DVP naar DVA'
Aantal succesvolle en onsuccesvolle Resource requests DVA-DVP	Aantal succesvolle en onsuccesvolle Resource requests van DVA-DVP binnen een bepaald tijdsbestek	13 - 14, 17-18	Gegevensdienst ID Resource ID Sessie ID Resultaat (succes, of foutcode).	Succesvol en onsuccesvol in percentages en absolute aantallen: per DVP per DVA per Zorgaanbieder per gegevensdienst per resource DVP & DVA combinatie DVA & Zorgaanbieder En combinaties hiervan Daarnaast is voor de onsuccesvolle Resource requests waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals: afgebroken door gebruiker foutmelding x foutmelding y ...	Zie doelen 'Geslaagde Authorization requests DVP naar DVA'
Aantal succesvolle en onsuccesvolle Resource requests XIS-DVA	Aantal succesvolle en onsuccesvolle Resource requests van XIS-DVA binnen een bepaald tijdsbestek	15, 16	Gegevensdienst ID Resource ID Sessie ID Resultaat (succes, of foutcode).	Zie 'Aantal succesvolle en onsuccesvolle Resource requests DVA-DVP'	Zie doelen 'Geslaagde Authorization requests DVP naar DVA'
Doorlooptijden van de start van een opvraging in een PGO en ontvangst van het antwoord in de PGO		1 en 14		Gemiddeld, minimum en maximum doorlooptijd voor alle DVP's per DVP's per gegevensdienst, voor alle gegevensdiensten per type resource voor alle typen resources per DVA voor alle DVA's per Zorgaanbieder voor alle Zorgaanbieders voor DVA's en Zorgaanbieder combinaties voor combinaties van DVA's met gegevensdiensten voor combinaties van DVA's met type resources	Er is nu geen inzage in reactietijden van de schakels in de MedMij keten, zie knelpunt E hfdst 2 uit het Vooronderzoek. Dit is wel gewenst.
Doorlooptijden per interface
Aantal verstoringen per interface en de duur van de verstoring	Nog verder te bepalen
Na constatering verstoring: prioritering van de verstoring
Oplostijden per verstoring	Nog verder te bepalen				Exacte tijdstip van de start van de verstoring. Welke schakel(s) in de keten de bron zijn van de verstoring. Voor prioritering van de verstoring: Aantal transacties die mis gaan door verstoring Aantal schakels in de keten die last hebben van de verstoring
Welke schakel(s) in de keten de bron zijn van de verstoring
Signaleren van veiligheids-risico's
Toename/afname gegevensuitwisselingen in de gehele MedMij Keten
Toename/afname gegevensuitwisselingen per interface

6.4. Aandachtspunten

Logging van synchrone en asynchrone gegevensuitwisseling
Wanneer een transactie wordt afgebroken, krijgt een Persoon in sommige gevallen een nieuwe mogelijkheid om alsnog de transactie te vervolgen. Bijvoorbeeld Wanneer de Persoon de authenticatie heeft afgebroken geeft de Dienstverlener aanbieder de mogelijkheid alsnog te authenticeren of de flow af te breken, zie MedMij afsprakenstelsel /wiki/spaces/MMVerplicht/pages/132023131
1:N relatie tussen verzoek van DVP voor verzamelen van gegevens en transacties. De scope bij één Zorgaanbieder kan zijn één of meerdere gegevensdiensten. Daarnaast kunnen voor één gegevensdienst één of meerdere resources worden opgehaald.
Wanneer in de toekomst gebruik gemaakt wordt van Langdurige Toestemming bij een Zorgaanbieder wordt niet langer via DigiD ingelogd voor het verzamelen van gegevens.

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

7.1. OAuth 2.0 foutcodes

Onderstaand 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)

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`

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

8. 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).

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

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

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

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

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

9. 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 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?

10. Referenties

A.12.4.4 Kloksynchronisatie

Browser not supported