Dit document dient als input voor de technische specificaties die nodig zijn voor de nieuwe afspraken over centrale logging in het MedMij Afsprakenstelsel (in dit document aangeduid als: 'afsprakenstelsel'). Dit document bestaat uit de Business Requirements, de logvelden en de indicatoren ter monitoring.

De Business Requirements beschrijven de wensen achter de nieuwe afspraken over centrale logging. De logvelden beschrijven vervolgens welke velden centraal gelogd moeten worden door de deelnemers om aan deze Business Requirements te kunnen voldoen. Tot slot laten de indicatoren zien welke monitoring plaats kan vinden als de centrale logging is geïmplementeerd.

1. Scope

Op 9 mei 2023 moeten de afspraken over centrale logging in de nieuwe release van het afsprakenstelsel geschreven worden. Dit betekent dat deze afspraken daarvoor uitgewerkt moeten zijn. Vanwege de beperkte tijd is er daarom gekozen om bepaalde onderwerpen binnen (MVP) en buiten (na MVP) de scope van de release op 9 mei te plaatsen. De wensen die voor de release van 9 mei moment buiten de scope liggen worden op een later moment toegevoegd aan het afsprakenstelsel. Deze fasering zorgt ervoor dat we de centrale logging wel op 9 mei kunnen doorvoeren en het werk behapbaar maken voor de deelnemers.

1.1. MVP in de release van 9 mei

In de MVP gaat het om het opzetten van de basisstructuur voor de centrale logging waar de eerste inzichten uitgehaald kunnen worden. Zie Plan van Aanpak van dit project voor de scope.

1.2. Fase 2

Voor fase 2 staat in ieder geval op de planning:

Definitie van wat OK en NOK is
- Een uitbreiding van de lijst van statussen om meer inzicht te krijgen in de reden achter verstoringen
PING berichten om de bereikbaarheid van zorgaanbieders en PGO's te testen

1.3. Fase 3

2. Randvoorwaarden

Er zijn enkele randvoorwaarden nodig om succesvol te loggen:

DVA's en DVP's loggen dit beiden zodat er inzicht komt in waar de berichten fout gaan
Decentraal wordt er real-time gelogd (door de DVA's en DVP's) en centraal wordt er dagelijks gelogd (het versturen van de gegevens naar MedMij)

3. Business Requirements

Deze Business Requirements beschrijven de wensen voor de centrale logging. De wensen zijn onderverdeeld in 3 thema's; het verkeer (de business-as-usual), verstoringen en trends. Om prioritering aan te brengen in deze requirements is de MoSCoW methode gebruikt. De prioriteringscategorieën zijn als volgt:

Must have: dit is een vereiste om het project te laten slagen.
Should have: dit is geen kritische eis, maar nog steeds erg belangrijk.
Could have: dit is geen eis, maar wel een wens.
Would have: dit is een wens die in de toekomst vervuld kan worden.

3.1. Verkeer

Nr.	Business Requirement	Prioriteit	Bijbehorende Logvelden
1.	Inzicht in het verkeer tussen de schakels in het afsprakenstelsel.	Must have	Trace_ID
2.	Inzicht in het verkeer per gegevensdienst tussen de schakels in het afsprakenstelsel.	Must have	Service_ID
3.	Inzicht in het verkeer per processtap (autorization, token, resource) tussen de schakels in het afsprakenstelsel.	Must have	Event_type
4.	Inzicht in de specifieke deelnemers waar het verkeer tussen plaatsvindt.	Should have	Client_ID, Server_ID en Provider_ID
5.	Inzicht in de responstijd van de schakels in het afsprakenstelsel.	Should have	Datetime
6.	Inzicht in de beschikbaarheid van de schakels in het afsprakenstelsel.	Could have	NTB
7.	Inzicht in of de schakels in het afsprakenstelsel voldoen aan de ketennorm.	Would have	NTB (ketennorm moet eerst bepaald worden)
8.	Inzicht in het verkeer per ZIBs tussen de schakels in het afsprakenstelsel

3.2. Verstoringen

Nr.	Business Requirement	Prioriteit	Bijbehorende logvelden
1.	Inzicht in het percentage berichten dat onsuccesvol uitgewisseld wordt tussen de schakels in het afsprakenstelsel.	Must have	Status
2.	Inzicht in het percentage succesvolle verzoeken die uitgewisseld worden tussen de schakels in het afsprakenstelsel (de verzoeken die het einde van de keten succesvol bereiken).	Must have	Status en Trace_ID
3.	Inzicht in bij welke DVA's en DVP's verstoringen plaatsvinden tussen de schakels in het afsprakenstelsel.	Must have	Status, Client_ID en Server_ID
4.	Inzicht in bij welke stap in het proces verstoringen plaatsvinden tussen de schakels in het afsprakenstelsel.	Must have	Status en Event_type
5.	Inzicht in bij welke PGO's en zorgaanbieders verstoringen plaatsvinden tussen de schakels in het afsprakenstelsel.	Should have	Status, Provider_ID en Client_ID
6.	Tijdig inzicht in verstoringen in het verkeer tussen de schakels in het afsprakenstelsel.	Should have	Status, Client_ID, Server_ID en Provider_ID
7.	~~Inzicht in de inhoudelijke kwaliteit van het verkeer tussen de schakels in het afsprakenstelsel.~~	Could have	NTB
8.	Inzicht in het percentage berichten dat onsuccesvol uitgewisseld wordt per gegevensdienst tussen de schakels in het afsprakenstelsel.	Must have	Status en Service_ID
9.	Tijdig actie kunnen ondernemen bij verstoringen in het verkeer tussen de schakels in het afsprakenstelsel.	Could have	Status, Client_ID, Server_ID en Provider_ID
10.	Inzicht in de oorzaken van verstoringen in het verkeer tussen de schakels in het afsprakenstelsel.	Could have	Status
11.	Inzicht in de niet-geslaagde ophalingen van de schakels in het afsprakenstelsel.	Would have	Status

3.3. Trends over tijd

Nr.	Business Requirement	Prioriteit	Bijbehorende logvelden
1.	Inzicht in de trends in het verkeer tussen de schakels in het afsprakenstelsel.	Must have	Client_ID, Server_ID
2.	Inzicht in de trends van het aantal verstoringen tussen de schakels in het afsprakenstelsel.	Must have	Status
3.	Inzicht in bij welke stap in het proces structureel verstoringen plaatsvinden tussen de schakels in het afsprakenstelsel.	Must have	Event_type en Status
4.	Inzicht in bij welke gegevensdiensten structureel verstoringen plaatsvinden tussen de schakels in het afsprakenstelsel.	Must have	Status en Service_ID
5.	Inzicht in bij welke deelnemers structureel verstoringen plaatsvinden tussen de schakels in het afsprakenstelsel.	Should have	Status, Client_ID, Server_ID en Provider_ID
6.	Inzicht in de structurele oorzaken van verstoringen in het verkeer tussen de schakels in het afsprakenstelsel	Could have	Status

Waar mogelijk filtering op:

Per gegevensdienst,
Totaal aantal gegevensdiensten
Per DVP,
Totaal alle DVP's
Per DVA,
Totaal alle DVA's
Per Zorgaanbieder,
Totaal alle Zorgaanbieders
Per combinaties van DVA x en DVP x,
Per combinatie DVA x en Zorgaanbieder x
Type resource

4. Logvelden (attributen)

Dit hoofdstuk beschrijft de logvelden die door de deelnemers naar MedMij gestuurd moeten worden. Per logveld is beschreven;

De naam van het logveld
Voor welke processtap het logveld verstuurd moet worden
Een toelichting van wat er in het logveld staat
De prioriteitscategorie (zie vorige hoofdstuk voor uitleg methode)
Uit welke business requirement dit logveld voortkomt

Logveld	Technische uitwerking	Toelichting	Prioriteit	Business Requirements
Session_ID	Request "ID"	Unieke id voor de sessie.	Must have	Alle
Client_ID	Event "location": waar het event plaatsvindt	ID van de deelnemer die het bericht richting MedMij logt. Afhankelijk van de processtap waar het bericht over gaat is dit de verzender of ontvanger van het bericht. Voor DVP kan je dit afleiden uit client_id en voor DVA kan je dit afleiden uit de FQDN.	Must have	1.4, 2.3, 2.6, 2.5, 2.9 en 3.5
Server_ID	Event "uri": waar het event naartoe gaat	ID van de deelnemer met wie het bericht wordt uitgewisseld. Afhankelijk van de processtap waar het bericht over gaat is dit de verzender of ontvanger van het bericht.	Must have	2.3, 2.6, 2.9 en 3.5
Event_type	Event "type"	Beschrijving van het bericht (receive, respond, send)	Must have	1.3, 2.4 en 3.3
Service_ID		ID van de gegevensdienst die opgevraagd/verstuurd wordt.	Must have	1.2 en 3.4
Request_ID		MedMij_Request_ID uit het huidige afsprakenstelsel	Must have
Status	Status "code"	HTTP code van het bericht	Must have	2.1 - 2.6 en 3.2 - 3.6
Datetime	Event "date time"	Datum en tijdstip van het verzenden ofwel ontvangen van het bericht.	Must have	1.5
Provider_ID		ID van de (zorg)aanbieder achter de DVA waarmee berichten worden uitgewisseld.	Should have	1.4, 2.5, 2.6, 2.9 en 3.5
Location		Partij waar de event type plaatsvindt	Must have	Alle
Trace_ID	Trace ID	Unieke id voor het Trace dat tijdens meerdere processtap hetzelfde blijft, om aan te duiden dat de berichten bij hetzelfde Trace horen.	Should have	1.1 en 2.8
URI	URI	Check of de URI een bij MedMij bekende URI is.	Must have
Redirect URI		Terugverwijzing	Must have
State		onderdeel van Oauth2.0	Must have
Response_type		Wat wordt teruggestuurd n.a.v. succesvolle authorization.	Must have
Information		Welkel ZIB's er zijn verzameld

4.1. Logvelden per MoSCoW prioriteit

In onderstaande tabel is met groen aangegeven in welke fase van de omschreven business requirements de verschillende logvelden gebruikt worden. Gezien in de scope is bepaald dat logvelden binnen 'must have' en 'should have' onderdeel zijn van MVP binnen dit project (zie paragraaf 1.1), zullen alle logvelden in deze fase worden opgevraagd bij de deelnemers.

	Must	Should	Could	Would
Session_ID
Client_ID
Server_ID
Event_type
Service_ID
Request_ID
Status
Datetime
Provider_ID
Location
Trace_ID
URI
Redirect URI
State
Response_type
ZIBs

5. Indicatoren

Nr.	Omschrijving indicator	Vervult Business Requirement	Gebruikt de logvelden
1.	Aantal berichten die succesvol uitgewisseld zijn (over tijd)	1.1	Trace_ID, Event_Type en Datetime, Status
2.	Het succespercentage (over tijd)	1.1	Trace_ID, Event_Type en Datetime
3.	Aantal succesvolle uitwisselingen per gegevensdienst (over tijd)	1.2	Trace_ID, Event_Type, Datetime en Service_ID
4.	Het succespercentage per gegevensdienst (over tijd)	1.2	Trace_ID, Event_Type, Datetime en Service_ID
5.	Aantal berichten die succesvol verstuurd en ontvangen zijn per processtap (over tijd)	1.3	Trace_ID, Event_Type, Datetime en Processtap_ID
6.	Het succespercentage per processtap (over tijd)	1.3	Trace_ID, Event_Type, Datetime en Processtap_ID
7.	Het succespercentage per DVA en Zorgaanbieder (over tijd)	1.4	Trace_ID, Event_Type, Datetime, Client_ID en Provider_ID
8.	Het succespercentage per DVP en PGO (over tijd)	1.4	Trace_ID, Event_Type, Datetime en Client_ID
9.	Aantal berichten (marktaandeel) per DVA en Zorgaanbieder (over tijd)	1.4	Trace_ID, Event_Type, Datetime, Client_ID en Provider_ID
10.	Aantal berichten (marktaandeel) per DVP en PGO (over tijd)	1.4
10a.	Aantal berichten (marktaandeel) per combinatie van DVP en DVA (over tijd)	1.4	Trace_ID, Event_Type, Datetime en Client_ID
11.	Gemiddelde responstijd van berichten per DVA en DVP (over tijd)	1.5	Trace_ID, Event_Type, Datetime en Client_ID
12.	Aantal berichten dat binnen de norm van de responsetijd zijn aangekomen (over tijd)	1.5	Trace_ID, Event_Type en Datetime
13.	Aantal dagen zonder verstuurde berichten per DVA en DVP (over tijd)	1.6	Trace_ID, Event_Type, Datetime en Client_ID
14.	Aantal berichten per processtap die niet succesvol verstuurd zijn (over tijd)	2.1 + 2.6 + 2.9 + 3.2	Trace_ID, Event_Type, Datetime en Status
15.	Het uitvalpercentage voor berichten (over tijd)	2.1 + 2.6 + 2.9 + 3.2	Trace_ID, Event_Type, Datetime en Status
16.	Aantal berichten die niet succesvol het einde van de keten bereiken (over tijd)	2.2 + 2.6 + 2.9 + 3.2	Trace_ID, Event_Type, Datetime, Trace_ID en Status
17.	Het uitvalpercentage voor de keten (over tijd)	2.2 + 2.6 + 2.9 + 3.2	Trace_ID, Event_Type, Datetime, Trace_ID en Status
18.	Het uitvalpercentage per DVA en Zorgaanbieder (over tijd)	2.3 + 2.5 + 2.6 + 2.9 + 3.5	Trace_ID, Event_Type, Datetime, Client_ID, Provider_ID en Status
19.	Het uitvalpercentage per DVP en PGO (over tijd)	2.3 + 2.5 + 2.6 + 2.9 + 3.5	Trace_ID, Event_Type, Datetime, Client_ID en Status
19a.	Het uitvalpercentage per combinatie van DVP en DVA (over tijd)
20.	Het uitvalpercentage per processtap (over tijd)	2.4 + 2.6 + 2.9 + 3.3	Trace_ID, Event_Type, Datetime, Client_ID, Processtap_ID en Status
21.	Het aantal berichten per status (over tijd); zowel response- als error status en combinatie hiervan	2.6 + 2.9 + 2.10 + 3.6	Trace_ID, Event_Type, Datetime en Status (in de toekomst gaan statussen aangevuld worden met meer oorzaken)
22.	Het uitvalpercentage per gegevensdienst (over tijd)	2.8 + 3.4	Trace_ID, Event_Type, Datetime, Status en Service_ID

5.1. Ontwerpen

Hieronder is bovengenoemde lijst aan indicatoren uitgewerkt in een aantal visuele onderwerpen.

Wijzigingen in logvelden/veldnamen:

Naam oud	Naam nieuw	Reden
Bericht_ID	Trace_ID + Event_Type	technische mogelijkheden
Eigenaar_ID, PGO_ID	Client_ID	uniformiteit
Partner_ID	Server_ID	Uniformiteit
Processtap	Event_type
Event_DateTime	DateTime	Uniformiteit
Aanbieder_ID (ZorgProvider_ID)	Provider_ID	Engels
Gegevensdienst_ID	Service_ID	Engels
ZIBs	Information

MedMij Change Management

Logging afspraken