Changelog

Datum	Wijziging	Door wie
13-4-23	In het scenario overleg zijn de alternative flows doorgenomen en is bepaald welke regels weg kunnen of aangepast moeten worden. Deze regels zijn doorgestreept of staat er een opmerking achter. Op basis van de uitkomsten van dit overleg is dit document aangepast. Voor overzicht van verwijderde regels zie versie 23 in pagina historie.	Marlotte Pannekoek

Aanleiding

MedMij is een keten van verschillende schakels die met elkaar verbonden zijn om de uitwisseling van gezondheidsgegevens tussen verschillende partijen mogelijk te maken. De hoofdschakels in de MedMij keten zijn DVP, DVA, Stelselnode, DigiD, TVS en Zorgaanbieder. Elke hoofdschakel bestaat op zijn beurt uit subschakels die verantwoordelijk zijn voor specifieke taken en functies. In de huidige situatie hebben wij onvoldoende inzicht in de uitwisseling en dit leidt tot problemen. Bijvoorbeeld, het gebrek aan inzicht maakt het identificeren van verstoringen en bijbehorende oorzaken erg lastig, hierdoor heeft MedMij Regie moeite met het oplossen van problemen en het herkennen van trends. Ook het gebrek aan informatie op management niveau maakt bijsturen lastig. Om beter uitwisselingsproblemen te kunnen oplossen, bij te kunnen sturen en veiligheidsrisico's beter te kunnen identificeren hebben wij meer inzicht nodig.

Door loggegevens op te vragen en vanuit MedMij zelf analyses uit te voeren kunnen wij de kwaliteit van de uitwisseling binnen het MedMij stelsel verbeteren.

In eerdere fases van dit project is onderzoek gedaan naar onder andere de wensen en behoefte van de verschillende stakeholders en is input opgehaald bij deelnemers. Verder is de flow van de uitwisseling in kaart gebracht en gekeken op welke punten binnen de flow wij kunnen en willen loggen. Al deze informatie is gecombineerd met usecases om te bepalen welke informatie wij willen loggen. Een overzicht van de te loggen events en objecten staat in paragraaf 4 van Logging afspraken.

Vervolgens is de happy flow in JSON uitgewerkt. Echter, het verzamelen of delen van data gaat niet altijd goed en juist in deze gevallen willen we weten wat er is gebeurt, wanneer het plaatsvond en wat het veroorzaakte zodat we op tijd en gericht kunnen ingrijpen om problemen op te lossen of te voorkomen in de toekomst. Als de uitwisseling niet goed verloopt dan is dit niet een happy flow maar een alternative flow. Deze alternative flows moeten ook in kaart gebracht worden en daarna worden uitgewerkt in JSON. Op deze pagina zijn de verschillende alternative flows in kaart gebracht, zodat deze in een later stadium uitgewerkt kunnen.

Alternative flow

'Alternative flow' is een term die vaak wordt gebruikt in softwareontwikkeling en verwijst naar het pad dat een programma of systeem volgt wanneer er een fout of probleem optreedt. In tegenstelling tot de 'happy flow', die de gebruikelijke en verwachte stappen in een proces beschrijft, beschrijft de 'alternative flow' de ongewenste situaties die kunnen optreden, zoals verkeerde invoer, systeemstoringen, netwerkproblemen, enz. maar ook het afhaken van een gebruiker.

Door de 'alternative flows' te identificeren en deze in kaart te brengen kan bepaalt worden waar en wat gelogd gaat worden om zo beter inzicht te krijgen als er problemen voordoen. Bijvoorbeeld, het geeft inzicht in:

dat een flow alternative is,
wie de betrokken ketenpartijen zijn,
wat de impact is,
om hoeveel foutberichten gaat het,
hoeveel gebruikers het betreft
en indien er vertraging optreedt hoe groot de vertraging is

Deze informatie kan gebruikt worden om het systeem robuuster en gebruiksvriendelijker te maken voor als er problemen optreden.

Logbare alternative flows

Nr	Alternative flow	Interface	Wie logt?	Van naar	Categorie
1a	Authorization request wordt verstuurd, maar er wordt niets ontvangen.	Authorization	DVP	DVP → DVA	Verstuurd → niet ontvangen
1b	Authorization request wordt verstuurd, maar mag niet verwerkt worden door DVA (door client ID/redirect uri klopt beveiliging niet, resulteert in foutpagina bij de DVA, en bij DVA foutcode in de logging))	Authorization	DVA & DVP	DVP → DVA	Niet verwerkbaar
1c	Authorization request wordt verstuurd, maar kan niet goed verwerkt worden door DVA (kan resulteren in een diversiteit aan HTTP status codes (inclusief foute parameters, en niet alle parameters zijn er))	Authorization	DVA (& DVP)	DVP → DVA	Niet verwerkbaar
1d	Authorization request wordt kort achter elkaar door dezelfde gebruiker meermaals verstuurd, maar de DVA verwerkt niet alle verzoeken	Authorization	DVA	DVP → DVA	Niet verwerkbaar
1e	De eerste landingspagina DVA wordt getoond, maar de Persoon klikt op annuleren	Authorization	DVP & DVA	DVP → DVA	Annuleren
1f	De eerste landingspagina DVA wordt getoond maar persoon sluit de browser of tabblad	Authorization		DVP → DVA	Browser/tabblad/app gesloten
2a	De DVA ontvangt een negatief resultaat op het authentificatie proces (400).	Authorization → DigiD	DVA	DVA→ DigiD (=DVAuthN)	Negatief resultaat Authenticatie
2b	Persoon is geauthenticeerd door DigiD, maar krijgt melding 500 (afgewezen) of 1005 melding	Authorization → DigiD	DVA	DVA→ DigiD (=DVAuthN)	?
3a	Persoon is geauthenticeerd, maar resultaat beschikbaarheidstoets is negatief (1 t/m 9 → 12,13; 20, 21 → 24) PGO krijgt 403 als er geen behandelrelatie is met de ZA	Authorization → Vroege beschikbaarheidstoets		DVA	Negatief resultaat beschikbaarheid
4a	Toestemmingsverklaring wordt getoond, maar Persoon geeft geen toestemming door op annuleren te klikken (10 t/m 13, NB: bij 11 specifiek loggen "geen toestemming")	Authorization → Toestemmingsverklaring		DVA→ User Agent	Annuleren
4b	Een andere technische storing bij de Authorization server (authorization server kan zelf een technische fout hebben). Dit moet en kan gelogd.	Authorization → Toestemmingsverklaring	DVP	DVA → User Agent	Technische storing
5a	Toestemming is gegeven en de DVP stuurt token request, maar krijgt time-out (14, 15) (Moet gelogd door DVP, DVA kan zo lang wachten op verwerken op gegevens dat er timeout wordt verzonden. dit is iets anders dan onbeschikbaar zijn van resource interface)	Token	DVP		Time-out
5b	Token request is verstuurd, maar parameters kloppen niet (13 t/m 17)	Token	DVP & DVA (vooral DVA)		Niet verwerkbaar
5c	PGO verstuurt meerdere token requests en krijgt meerdere tokenresponses terug van DVA. (kan alleen als er 1 positief is, en de rest negatief)	Token	DVP & DVA		Niet verwerkbaar
5d	De authorization code of het refresh token is verlopen of anderszins foutief (14, 15)	Token	DVP & DVA		Token problemen
5e	Refresh token is tussentijds ingetrokken (14 t/m 17) (beide partijen loggen)	Token	DVP & DVA		Token problemen
5f	DVP gebruikt de verkeerde (verkeerd, verlopen, ingetrokken) server certificaten (15?) (voordat request wordt verzonden wordt er een TLS tunnel aangemaakt, en die mislukt. dus loggen in technologie laag, op dezelfde bol → json?)	Token			Beveiliging
5g	DVA gebruikt de verkeerde (verkeerd, verlopen, ingetrokken) server certificaten	Token			Beveiliging
5h	Token server is niet beschikbaar	Token			Token problemen
6a	Access token is verkregen, resource request is verstuurd, maar krijgt time-out (15 minuten) 403	Resource	DVP		Time-out
6b	Access token is niet meegestuurd	Resource	DVP & DVA		Niet verwerkbaar
6c	Access token is verlopen	Resource	DVP & DVA		Token problemen
6d	Resource komt niet voor in de scope van het access token	Resource	DVP & DVA		Token problemen
6e	Het resultaat beschikbaarheidstoets is negatief	Resource	DVP & DVA		Negatief resultaat beschikbaarheid
6f	Resource (bron) is niet beschikbaar (op dit moment)	Resource	DVP & DVA		Resource problematiek
6g	Resource server is niet beschikbaar (404)	Resource			Resource problematiek
6h	PGO krijgt 403 als patient of PGO niet geauthorizeerd is om zib te leveren (400-derds is fout van de aanroepen.)	Resource	DVP & DVA		?

Alternative flows die niet te loggen zijn

Nr	Alternative flow	Toelichting waarom deze niet te loggen is	Interface	Te verkrijgen via analyse?
1a	De gebruiker klikt op DigiD app, maar heeft deze nog niet geïnstalleerd en haakt af bij het installeren en activeren van de app (opent in nieuw venster)	We kunnen alleen loggen dat de DigiD flow wordt gestart. De reden van afhaken is niet te achterhalen.	Authorization → DigiD	Nee
1b	De gebruiker gebruikt mobiel. De gebruiker klikt op DigiD app op dit apparaat	We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.	Authorization → DigiD	Nee
1c	De gebruiker gebruikt desktop of laptop en klikt op DigiD app staat op mobiel apparaat	We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.	Authorization → DigiD	Nee
1d	DigiD app wordt getoond, persoon kiest voor inloggen bij DigiD, maar krijgt een 404	We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.	Authorization → DigiD	Nee
1e	DigiD app wordt getoond, maar persoon kiest voor annuleren door DigiD-app te sluiten	We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.	Authorization → DigiD	Nee
1f	DigiD app wordt getoond, maar persoon kiest voor annuleren door wegklikken van het venster (Bijvoorbeeld omdat ze er achter komen geen app op substantieel te hebben en de gebruiker gevraagd wordt om met identiteitskaart (paspoort rijbewijs) de digid-app te upgraden naar substantieel.)	We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.	Authorization → DigiD	Nee
1g	DigiD app wordt getoond, maar persoon voert verkeerde pincode in. (Op moment dat de gebruiker dit te vaak doet wordt digid geblokkeerd en moet je weer helemaal opnieuw enrollen.)	We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.	Authorization → DigiD	Nee
1h	Persoon is geauthenticeerd door DigiD en kan gaan inloggen maar annuleert (pagina van DVA) (4a (annuleringspagina: nieuw) → 4 of 12, 13)	We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.	Authorization → DigiD	Nee
1j	Persoon is geauthenticeerd door DigiD, maar krijgt melding dat de DVA niet beschikbaar is (5,6,7, optioneel: 8,9)	Dit is niet te meten	Authorization → DigiD
1k	Persoon is geauthenticeerd door DigiD, maar NoAuthnContext (Niet voldaan aan betrouwbaarheidsniveau) (is een variant op E)		Authorization → DigiD
1l	Persoon is geauthenticeerd door DigiD, maar RequestDenied (Verzoek geweigerd door DigiD bijvoorbeeld door TimeOut) (is een variant op E)		Authorization → DigiD
1m	Toestemmingspagina wordt niet getoond (DVA niet beschikbaar, pagina niet beschikbaar)	Dit is niet meten	Authorization → Toestemmingsverklaring	Ja
2a	Toestemmingsverklaring wordt getoond, maar Persoon verleent geen toestemming door de browser te sluiten.		Authorization → Toestemmingsverklaring	Nee
2b	Toestemmingsverklaring wordt getoond, maar Persoon verleent geen toestemming door de tab te sluiten.		Authorization → Toestemmingsverklaring	Nee
2c	Toestemming wordt gegeven, maar Persoon krijgt een 404 bij de DVP (1 t/m 12)	404 is een browser fout, dus niet te loggen.	Authorization → Toestemmingsverklaring	Ja

?

In de tekst hieronder vind je allereerst een opsomming van alternative flows en vervolgens of deze flow met analyse van het ketenlog als volgt kan worden geïdentificeerd:

TOK = Happy flow

TNOK = alternative flow met foutmelding (Risico: het is onduidelijk bij resource bevragingen wat TNOK is.)

TNOK Overige uitval = Aantal berichten voorgaande stap - (Aantal berichten volgende stap TNOK + Aantal berichten in daaropvolgende stap)

Definitie TNOK Overige uitval (ook wel abandoned, cancelled of afhakers genoemd):

Verlies van berichten door:
- gebruikers die afhaken door sluiten browser, tab of app
- berichten die 'over de lijn' verdwijnen.

De uitval zoals die nu in het stelsel lijkt te zitten bevindt zich in de optiek van PGO MedXpert vooral in de categorie: overige uitval.

NB: Overige uitval genereert geen TNOK foutmelding.

NB: TVS en Stelselnode zijn geen onderdeel van deze plaat maar wel onderdeel van het ketenlog, dwz. we willen iig weten is:

Stelselnode
Hoeveel verzoeken verstuurt de DVA naar Stelselnode op basis van de ontvangen verzoeken van de DVP?
Hoeveel van de door de DVA verstuurde verzoeken komen terug met een positief antwoord?
Hoeveel van de door de DVA verstuurde verzoeken komen terug met een negatief antwoord?(En wat is de reden/foutmelding?)
Hoeveel van de door de DVA verstuurde verzoeken komen niet terug van de Stelselnode?

TVS
Hoeveel verzoeken verstuurt de DVA naar TVS op basis van de ontvangen verzoeken van de DVP?
Hoeveel van de door de DVA verstuurde verzoeken komen terug met een positief antwoord?
Hoeveel van de door de DVA verstuurde verzoeken komen terug met een negatief antwoord? (En wat is de reden/foutmelding?)
Hoeveel van de door de DVA verstuurde verzoeken komen niet terug van TVS?

Onderstaande plaat wordt als volgt gebruikt bij uitvalanalyses. Bron: PlantText UML Editor

Bron: https://vzvz.atlassian.net/wiki/display/MACM/MO-52+Logvelden+Bijlage+4

Gedacht: Met het TraceID kunnen we na analyse in het ketenlog per bericht vaststellen waar een bericht / waar de meeste berichten stopt / stoppen.

Scenario's

Happy Flow: Alles gaat goed, data staat in PGO; zie subpagina happy flow. Afgevraagd waarom scheiden de happy flow en de alternative flow? Beide zijn namelijk nodig om met behulp van het ketenlog te komen tot analyses die inzicht geven in de de 'Overige uitval'.

Situatie		Bol	Wie		Bol	Wie	Overige uitval
1a	Authorization request wordt verstuurd door PGO (100x)	1	DVP	Maar er wordt niets ontvangen Wanneer het verzoek dat door DVP is verstuurd niet terugkomt van DVA, kan dit een groot probleem in de MedMij-keten betekenen. Vraag je telkens af: kun je met de logging in de bollen plaat vaststellen hoeveel de 'overige uitval' is?	Niet direct logbaar, maar berekening obv wel gelogde stappen in ketenlog 1 Start aantal (100x) 2 TNOK = alternativeflow met foutmelding (30x) 3 Tonen van de landingspagina (50x)	DVA	Overige uitval = 1 - (3 + 2 TNOK) dus 100 - (50+30) = 20
1b	Authorization request wordt verstuurd	1	DVP	maar kan niet goed verwerkt worden door DVA TNOK = Foutmelding (teveel , te weinig, verkeerde parameters, fout in waarde parameters.)	2 TNOK	DVA
1c	Authorization request wordt kort achter elkaar door dezelfde gebruiker meermaals verstuurd	1	DVP	maar de DVA kan niet elk verzoek verwerken	Berekening 1a	DVA
1d	De eerste landingspagina DVA wordt getoond,	3	DVA	maar de Persoon klikt op annuleren	4 TNOK	DVA
1e	De eerste landingspagina DVA wordt getoond,	3	DVA	maar persoon sluit de browser of tabblad	Berekening	DVA	Overige uitval = 3 - (5 + 4 TNOK)
1f	De tweede landingspagina DVA wordt getoond	5	DVA	maar de Persoon klikt op annuleren	6 TNOK	DVA
1g	De tweede landingspagina DVA wordt getoond	5	DVA	maar persoon sluit de browser of tabblad	Berekening		Overige uitval = 5 - (7 + 6 TNOK)

Browser not supported