Skip to end of banner
Go to start of banner

Alternative flows

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 30 Current »

Changelog

DatumWijzigingDoor wie
13-4-23In 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

NrAlternative flowInterfaceWie logt?Van naarCategorie
1aAuthorization request wordt verstuurd, maar er wordt niets ontvangen.AuthorizationDVPDVP → DVAVerstuurd → niet ontvangen
1bAuthorization 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 & DVPDVP → DVANiet verwerkbaar
1cAuthorization 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 → DVANiet verwerkbaar
1dAuthorization request wordt kort achter elkaar door dezelfde gebruiker meermaals verstuurd, maar de DVA verwerkt niet alle verzoekenAuthorization DVADVP → DVANiet verwerkbaar
1eDe eerste landingspagina DVA wordt getoond, maar de Persoon klikt op annulerenAuthorization  DVP & DVADVP → DVAAnnuleren
1fDe eerste landingspagina DVA wordt getoond maar persoon sluit de browser of tabbladAuthorization 
DVP → DVABrowser/tabblad/app gesloten
2aDe DVA onvangt een negatief resultaat op het authentificatie proces (400).Authorization
→ DigiD
DVADVA→ DigiD (=DVAuthN)
Negatief resultaat Authenticatie
2bPersoon is geauthenticeerd door DigiD, maar krijgt melding 500 (afgewezen) of 1005 meldingAuthorization
→ DigiD
DVADVA→ DigiD (=DVAuthN)?
3aPersoon 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


DVANegatief resultaat beschikbaarheid
4aToestemmingsverklaring 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 AgentAnnuleren
4bEen andere technische storing bij de Authorization server (authorization server kan zelf een technische fout hebben). Dit moet en kan gelogd.Authorization
Toestemmingsverklaring
DVPDVA → User AgentTechnische 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)

TokenDVP
Time-out
5bToken request is verstuurd, maar parameters kloppen niet (13 t/m 17) TokenDVP & DVA (vooral DVA)
Niet verwerkbaar
5cPGO verstuurt meerdere token requests en krijgt meerdere tokenresponses terug van DVA. (kan alleen als er 1 positief is, en de rest negatief)TokenDVP & DVA
Niet verwerkbaar
5dDe authorization code of het refresh token is verlopen of anderszins foutief (14, 15)TokenDVP & DVA
Token problemen
5eRefresh token is tussentijds ingetrokken (14 t/m 17) (beide partijen loggen)TokenDVP & DVA
Token problemen
5fDVP 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
5gDVA gebruikt de verkeerde (verkeerd, verlopen, ingetrokken) server certificatenToken

Beveiliging
5hToken server is niet beschikbaarToken

Token problemen
6aAccess token is verkregen, resource request is verstuurd, maar krijgt time-out (15 minuten) 403ResourceDVP
Time-out
6bAccess token is niet meegestuurdResourceDVP & DVA
Niet verwerkbaar
6cAccess token is verlopenResourceDVP & DVA
Token problemen
6dResource komt niet voor in de scope van het access tokenResourceDVP & DVA
Token problemen
6eHet resultaat beschikbaarheidstoets is negatiefResourceDVP & DVA
Negatief resultaat beschikbaarheid
6fResource (bron) is niet beschikbaar (op dit moment)ResourceDVP & DVA
Resource problematiek
6gResource server is niet beschikbaar (404)Resource

Resource problematiek
6hPGO krijgt 403 als patient of PGO niet geauthorizeerd is om zib te leveren (400-derds is fout van de aanroepen.)ResourceDVP & DVA
?

Alternative flows die niet te loggen zijn

NrAlternative flowToelichting waarom deze niet te loggen isInterfaceTe verkrijgen via analyse?
1aDe 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
1bDe gebruiker gebruikt mobiel. De gebruiker klikt op DigiD app op dit apparaatWe 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
1dDigiD app wordt getoond, persoon kiest voor inloggen bij DigiD, maar krijgt een 404We kunnen alleen loggen dat de DigiD flow wordt gestart. DigiD is een blackbox.

Authorization
→ DigiD

Nee
1eDigiD 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
1fDigiD 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
1gDigiD 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
1hPersoon 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
1jPersoon 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


1kPersoon is geauthenticeerd door DigiD, maar NoAuthnContext (Niet voldaan aan betrouwbaarheidsniveau) (is een variant op E)

Authorization
→ DigiD


1lPersoon is geauthenticeerd door DigiD, maar RequestDenied (Verzoek geweigerd door DigiD bijvoorbeeld door TimeOut) (is een variant op E)

Authorization
→ DigiD


1mToestemmingspagina wordt niet getoond (DVA niet beschikbaar, pagina niet beschikbaar) Dit is niet metenAuthorization
Toestemmingsverklaring
Ja
2aToestemmingsverklaring 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
2cToestemming 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

  1. 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
BolWieOverige uitval 
1a

Authorization request wordt verstuurd door PGO 

(100x)

1DVP

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

1bAuthorization request wordt verstuurd1DVP

maar kan niet goed verwerkt worden door DVA 

TNOK = Foutmelding (teveel , te weinig, verkeerde parameters, fout in waarde parameters.)

2 TNOKDVA
1c

Authorization request wordt kort achter elkaar door dezelfde gebruiker meermaals verstuurd

1DVPmaar de DVA kan niet elk verzoek verwerken Berekening 1aDVA
1dDe eerste landingspagina DVA wordt getoond, 3DVAmaar de Persoon klikt op annuleren4 TNOKDVA
1eDe eerste landingspagina DVA wordt getoond, 3DVAmaar persoon sluit de browser of tabblad BerekeningDVA

Overige uitval = 

3 - (5 + 4 TNOK)


1fDe tweede landingspagina DVA wordt getoond5DVAmaar de Persoon klikt op annuleren6 TNOKDVA
1gDe tweede landingspagina DVA wordt getoond5DVAmaar persoon sluit de browser of tabblad Berekening

Overige uitval =

5 - (7 + 6 TNOK)





  • No labels