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 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 onvangt 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | |
| 1k | Persoon is geauthenticeerd door DigiD, maar NoAuthnContext (Niet voldaan aan betrouwbaarheidsniveau) (is een variant op E) | Authorization | ||
| 1l | Persoon is geauthenticeerd door DigiD, maar RequestDenied (Verzoek geweigerd door DigiD bijvoorbeeld door TimeOut) (is een variant op E) | Authorization | ||
| 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 | ||
| 2b | Toestemmingsverklaring wordt getoond, maar Persoon verleent geen toestemming door de tab te sluiten. | Authorization → Toestemmingsverklaring | ||
| 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://afsprakenstelsel.medmij.nl/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) |