Changelog

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

Alternative flows die niet te loggen zijn

?

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

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