MO-45 Logging-monitoring en rapporteren
- Kailesh Bansi (Deactivated)
- Susanne Groot
- Floor Klijn | MedMij
Leeswijzer
Belangrijkste pagina's binnen Ketenmonitoring en logging (MO-45 Logging-monitoring en rapporteren):
Opzet voor afsprakenstelsel: MO-123 Logging-monitoring en rapporteren
Overzicht van de transacties, zie onder 5.1: Voorstel logvelden (Work in Progress)
De business requirements, zie vanaf 3: Logging afspraken
De Happy flow, zie: Happy flow
De randvoorwaarden, zie: Voorwaarden voor bewaren en gebruiken loggegevens van events
Daarbij:
De alternatieve flows onder: Alternative flows
En use cases: Usecases
---
Vooronderzoek Praktijkmonitoring en Managementrapportages
Datum | Wie | Wat |
Stefan, Kailesh, Jeroen | Opgesteld door Jeroen, aangevuld door Stefan en Kailesh | |
1-12 | Floor | Indeling vooronderzoeken in document opgenomen, leesbaarheid van document aangepast en aanvullende inzichten van stakeholders opgenomen |
6-12 | Floor | Vragen en opmerkingen Kailesh en Jeroen verwerkt. Hoofdstukken Impact, risico's en randvoorwaarden toegevoegd. |
14-12 | Floor | Aanvullende input Marc en Bouke verwerkt. |
15-12 | Floor | Feedback Kailesh verwerkt |
19-12 | Floor | Managementrapportages in bijlage 7 toegevoegd. Input Stefan uit overleg verwerkt |
29-12 | Kailesh | Verplaatst naar Confluence, toevoeging security en opmerkingen verwerkt. |
9-1 | Floor | Opmerkingen Jeroen, Bouke, Tijmen, Pascale verwerkt. |
10-1 | Kailesh | Review & resterende opmerkingen verwerkt. |
11-1 | Floor | Opmerkingen verwerkt |
1. Huidige situatie
Elke deelnemer van het MedMij afsprakenstelsel is zelf verantwoordelijk voor de logging en monitoring van de eigen applicatie(s). Deelnemers rapporteren hun verstoringen in Supportal. Wanneer deelnemers verstoringen escaleren naar MedMij Regie en MedMij Regie het eigenaarschap van het probleem overneemt, wordt de documentatie in JIRA gedaan. MedMij Regie ondersteunt deelnemers bij het signaleren, melden, analyseren en oplossen van verstoringen. In de MedMijDAP [3] staan de beheerafspraken voor de MedMij keten beschreven.
De Dienstverleners persoon (DVP) en Dienstverleners aanbieder (DVA) leveren daarnaast maandelijks een beheerrapport aan bij Stichting MedMij. De informatie uit deze rapporten wordt geaggregeerd tot een managementrapportage voor de Stichting MedMij en de Deelnemers [1]. Deze managementrapportage geeft inzicht in het gebruik van MedMij en eventuele knelpunten. Landelijke programma’s zoals de VIPP-programma’s die betrokken zijn bij de ontwikkeling en implementatie van gegevensdiensten bij Zorgaanbieders, hebben geen toegang tot deze managementrapportages. En gebruiken andere gegevens voor inzicht in de gegevensuitwisseling met PGO’s. Bij VIPP OPEN leveren de HIS-leveranciers bijvoorbeeld op vrijwillige basis informatie aan bij het VIP Programma [2].
Deelnemers, betrokkenen bij landelijke programma's zoals de VIP-programma's, programma PGO On Air, en medewerkers van Stichting MedMij, en VZVZ geven aan dat de informatie die op het moment met elkaar gedeeld wordt onvoldoende is voor (1) het tijdig signaleren, melden, analyseren en oplossen van verstoringen en ook voor (2) het sturen op oplossingen van structurele problemen of trends in PGO-gebruik. Dit wordt in hoofdstuk 2 verder toegelicht.
2. Probleembeschrijving
2.1. Signaleren, melden, analyseren en oplossen van verstoringen
Momenteel wordt verwacht van deelnemers dat zij zicht hebben op verstoringen in hun eigen applicatie middels hun eigen logging en monitoring. Daarnaast dienen zij ook zicht te hebben op de verstoringen van de deelnemers waarmee ze communiceren. Daarentegen worden verstoringen van schakels in de keten echter niet altijd of soms laat gesignaleerd en/of gemeld. Zo was een van de PGO's een maand niet beschikbaar voordat dit bij MedMij bekend was.
Sommige verstoringen kunnen niet worden opgelost, doordat niet kan worden achterhaald waar precies de oorzaak van de verstoring ligt in de keten van schakels van DVP, DVA, MedMij Stelselnode, DigiD en XIS (informatiesysteem van de Zorgaanbieder).
Voorbeelden zijn:
Een DVP gaf aan dat na 2 jaar slechts 60% van de opvragingen via een MedMij PGO leidt tot een succesvolle ophaling. Op basis van het percentage succesvolle (authorization, token en resource) requests in de Managementrapportage wordt het beeld van deze DVP bevestigd. (Met een opvraging wordt bedoeld dat een PGO-gebruiker een actie start voor het ophalen van gegevens bij een Zorgaanbieder met een gegevensdienst. Met een ophaling wordt bedoeld dat de opgehaalde resources bij de Zorgaanbieder getoond worden in de PGO.)
Een deelnemer maakte een herhaalde melding van een verstoring bij een andere deelnemer. Wanneer de andere deelnemer teruggeeft dat hij geen verstoring vindt in de eigen applicatie en zij niet de oorzaak van de verstoring zijn, belandde de melding tussen wal en schip.
Daarnaast kan niet worden achterhaald of een verstoring veroorzaakt wordt doordat een gebruiker een fout maakt (verkeerd wachtwoord ingevoerd bij DigiD) of halverwege het proces stopt. Of dat een verstoring bij een deelnemer of Zorgaanbieder de oorzaak is.
MedMij Regie geeft aan onvoldoende informatie te krijgen van de gegevensuitwisseling in de keten om deelnemers altijd goed te kunnen ondersteunen bij het vinden van de oorzaak en een passende oplossing. Zie voor verdere toelichting ProbleemNr's C en D in onderstaande tabel.
PGO-gebruikers
Uiteindelijk heeft dit gevolgen voor de PGO-gebruiker. Ervaren verstoringen in de PGO kunnen niet altijd worden opgelost. Uit het Kantar -onderzoek [5] blijkt bijvoorbeeld dat van de respondenten meer dan één op de drie probeerde de huisartsengegevens op te halen (37%). Iets meer dan de helft (55%) slaagde daarin. De 17% van de gebruikers waarbij het niet lukte de huisartsgegevens op te halen, geven aan dat het niet lukte de huisarts te vinden of koppelen of dat zij een foutmelding kregen. Daarnaast worden PGO-gebruikers nu niet geïnformeerd over bekende verstoringen in het MedMij netwerk. Op dit vlak wordt aan verbeteringen gewerkt, zie MO-34 Duiding van errors.
Bij een melding van een probleem door de PGO-gebruiker bij een helpdesk komt het nu soms voor dat de gebruiker van het kastje naar de muur wordt gestuurd. Wanneer de helpdesk van de DVP de PGO-gebruiker niet kan helpen met een probleem, wordt hij soms doorverwezen naar de DVA of Zorgaanbieder. Lang niet altijd komt de PGO-gebruiker bij de juiste persoon bij deze organisatie terecht.
Overzicht ervaren problemen
Een overzicht van de problemen op het gebied van signaleren, melden, analyseren en oplossen van verstoringen is in onderstaande tabel weergegeven.
Nr | Probleem Naam | Toelichting |
|---|---|---|
A | Onvoldoende inzicht in de kwaliteit van de gegevensuitwisseling in de gehele MedMij keten. | Het aantal en percentage van de opvragingen in een PGO dat leidt tot een volledig succesvolle ophaling van gegevens in een PGO is niet inzichtelijk. Daarnaast is niet inzichtelijk of slechts een deel van de gevraagde gegevens succesvol opgehaald wordt in de PGO (bijvoorbeeld één van de vijf gevraagde resources) of alle gegevens. Met een opvraging wordt bedoeld dat een PGO-gebruiker een actie start voor het ophalen van gegevens bij een Zorgaanbieder met een gegevensdienst. Met een ophaling wordt bedoeld dat de opgehaalde resources bij de Zorgaanbieder getoond worden in de PGO. Het is daarnaast onvoldoende inzichtelijk wat de grootste problemen zijn in de gegevensuitwisseling in de keten, die opgelost moeten worden door het ontbreken van cijfers van de gegevensuitwisseling in de gehele keten. In de huidige situatie wordt alleen informatie over de succesvolle en onsuccesvolle gegevensuitwisseling bij de DVP en DVA gedeeld. Knelpunten in de gegevensuitwisseling tussen bijvoorbeeld de DVA en DigiD, of tussen DVA en XIS van de Zorgaanbieder zijn niet inzichtelijk (XIS niet beschikbaar of er kunnen geen gegevens opgehaald worden). Inzicht in welke verstoringen er zijn en de omvang is afhankelijk van meldingen door de deelnemers. Zie ook toelichting bij Probleemnr C. Tenslotte verschillen de aantallen succesvolle en onsuccesvolle authorization, token en resource requests die de DVA's en DVP's rapporteren in de beheerrapporten. |
B | Er kunnen geen garanties aan de PGO-gebruiker gegeven worden over de kwaliteit van gegevensuitwisseling die hij/zij mag verwachten. | Zoals hierboven is toegelicht is er onvoldoende inzage in de kwaliteit van de gegevensuitwisseling. Er is verder ook geen afspraak tussen deelnemers wat voldoende kwaliteit van gegevensuitwisseling is in de keten (ketennorm). Dat wil zeggen welk minimaal percentage van de gegevens moet foutloos (succesvol) uitgewisseld worden in de gehele MedMij keten van opvraging tot ophaling van gegevens in de PGO. PGO-gebruikers kunnen hierdoor geen garanties gegeven worden voor de kwaliteit van de gegevensuitwisseling. |
C | Niet alle verstoringen in de MedMij keten worden tijdig gesignaleerd en juist geprioriteerd. | Verstoringen in de keten zijn alleen inzichtelijk voor de deelnemers, wanneer andere deelnemers dit gemeld hebben in Supportal. Dit gebeurt niet altijd of pas achteraf. Daarnaast nemen niet alle PGO-gebruikers altijd contact op met de servicedesk wanneer zij verstoringen ervaren. En is een verstoring dus ook niet altijd bekend bij een deelnemer. Er kan verder verschil van inzicht zijn over de gemelde prioriteit van de verstoring tussen deelnemers. De prioriteit van de verstoring wordt ingeschat door de deelnemer die deze meldt. Andere deelnemers kunnen hierop reageren, wanneer zij het niet eens zijn met de ingeschatte prioriteit, zie MedMij DAP (3). Voor de deelnemers en MedMij regie is de tijdige signalering en juiste prioritering van verstoringen belangrijk om hier juist op te reageren. En om te streven naar het behalen van de afgesproken oplostijden voor een verstoring. Daarnaast kunnen deze tijdige signaleringen ervoor zorgen dat de gevonden verstoringen bij de deelnemers in de toekomst worden voorkomen. Op die manier wordt de kwaliteit van het afsprakenstelsel verbeterd. |
D | Het achterhalen van de bron en oorzaak van een verstoring in de MedMij keten kost de servicedesks van deelnemers veel tijd. | Nu wordt er achtereenvolgens door verschillende schakels in de keten gezocht naar de bron van een verstoring, wanneer er een verstoring wordt gemeld. Bijvoorbeeld: Wanneer een DVP nu een verstoring ervaart, neemt deze contact op met de servicedesk van de volgende schakel in de keten, de DVA. De DVA gaat nu op zoek of zijn applicatie de bron is van de verstoring. Wanneer deze niet verantwoordelijk blijkt voor de verstoring neemt deze weer contact op met de volgende schakels in de keten om de oorzaak van de verstoring te zoeken: zoals de DigiD-voorziening en de Zorgaanbieder. Uiteindelijk kan blijken dat de oorzaak van de verstoring bij de Zorgaanbieder ligt en niet bij de DVA. Gewenst is dat dit zoekwerk naar de oorzaak van de verstoring door tussenliggende schakels niet nodig is wanneer zij niet verantwoordelijk zijn voor de verstoring. Idealiter is direct inzichtelijk is welke schakel in de keten de bron van de verstoring is. Dit versnelt naar verwachting de oplostijd van een verstoring, doordat de bron sneller gevonden wordt. Daarnaast zijn de foutomschrijvingen in het MedMij stelsel niet duidelijk gedefinieerd. Hierdoor is het soms lastig om de oorzaak van een fout in de gegevensuitwisseling te achterhalen. |
E | Er is geen inzage in reactietijden van de schakels in de MedMij keten. | Wanneer een PGO-gebruiker erg lang moet wachten op antwoord van een schakel in de keten, is dit een reden om te stoppen in het proces. Er is nu geen inzage in bijvoorbeeld de tijd tussen opvraging door de PGO-gebruiker en antwoord op de opvraging. |
F | Het is niet bekend of een technisch probleem, of een gebruikershandeling, of een restrictie van de Zorgaanbieder (bijvoorbeeld niet-succesvolle ontvankelijkheidstoets) de oorzaak is van een niet-succesvolle opvraging. | Een PGO-gebruiker kan zelf stoppen met de opvraging of zelf een fout maken (bijvoorbeeld verkeerde wachtwoord invullen). Of een PGO-gebruiker komt niet door de ontvankelijkheidstoets van de Zorgaanbieder heen, omdat er geen behandelrelatie is. Of er kan een technisch probleem zijn. |
G | Het is niet bekend of doorgevoerde oplossingen het gewenste resultaat hebben in de MedMij keten. | Het is bijvoorbeeld niet inzichtelijk of een nieuwe versie van een gegevensdienst of een update van een deelnemer leidt tot minder verstoringen. |
H | Er is geen inzage in trends in gegevensuitwisseling in de keten | Wanneer bijvoorbeeld de opvragingen bij een deelnemer ineens rap toenemen, kan dit een indicatie zijn voor een poging tot hacking. Of voor een verstoring. Als een deelnemer dit zelf niet signaleert, moet een deelnemer op een potentieel risico gewezen kunnen worden door MedMij Regie. |
I | Geen inzage in de beschikbaarheid van de schakels in de keten | Het is niet bekend of alle schakels in de keten ook beschikbaar zijn. Er is een voorbeeld van een DVP die bijna een maand niet beschikbaar was. Dit was echter niet gemeld en dus bekend bij VZVZ en Stichting MedMij. |
Aanvullingen? |
2.2. Sturen op oplossingen van structurele problemen en trends
Inzicht in structurele knelpunten, die worden ervaren, is nodig om op structurele oplossingen voor verbetering te kunnen sturen. (Project-) managers en (implementatie-)adviseurs van Stichting MedMij, VZVZ, VIPP-programma's en programma PGO On Air geven aan dat de managementrapportages onvoldoende inzicht geven over: waar in de keten veel verstoringen voorkomen, hoeveel verstoringen dit dan zijn, wat de oplostijd is. Tevens of de impact van doorgevoerde aanpassing ook de gewenste oplossing brengt.
Daarnaast is andere informatie belangrijk om het gebruik van PGO’s te vergroten middels gerichte projecten. Bijvoorbeeld of er een toename of afname is in het aantal unieke gebruikers dat een PGO’s gebruikt. Welke gegevensdiensten zij het meest en het minst gebruiken. In welke regio en bij welk (type) zorgaanbieder het gebruik juist toeneemt of afneemt.
3. Gewenste situatie
In dit hoofdstuk is een schets gemaakt van de gewenste situatie. De mogelijke oplossingsrichtingen om tot deze gewenste situatie te komen, staan in het volgende hoofdstuk van dit document beschreven.
3.1. PGO-gebruikers
PGO-gebruikers hebben bij het gebruik van hun PGO zo min mogelijk last van verstoringen. Wanneer er toch verstoringen zijn, worden die gesignaleerd en opgelost door deelnemers voordat een grote groep van PGO-gebruikers hier last van heeft.
Wanneer verstoringen een grote impact hebben en niet snel opgelost kunnen worden, wordt een PGO-gebruiker hierover geïnformeerd (bijvoorbeeld bij het openen of bij gebruik van zijn PGO middels een melding). Zie ook MO-34 Duiding van errors
Wanneer een PGO-gebruiker last heeft van een verstoring, die ook nog niet landelijk bekend is, en deze meldt bij een PGO-helpdesk wordt zijn melding altijd opgepakt door de PGO-helpdesk waarmee hij contact heeft gehad. Wanneer de PGO-helpdesk constateert dat de verstoring door een derde partij verholpen moet worden, wordt de PGO-gebruiker geen probleemeigenaar. Maar is er een beheerproces ingericht, waarbij de melding door de deelnemers eventueel met ondersteuning van MedMij Regie wordt opgelost, zonder dat de PGO-gebruiker hier last van heeft. De PGO-gebruiker wordt niet doorgestuurd naar andere helpdesks van bijvoorbeeld de DVA of Zorgaanbieder. De PGO-gebruiker die de melding heeft gedaan, wordt verder geïnformeerd wanneer het probleem is opgelost. Evenals de PGO-helpdesk van de deelnemer die de melding heeft doorgestuurd.
3.2. Deelnemers
Inzicht in alle verstoringen die relevant zijn voor functioneren van de applicatie van de deelnemer binnen het MedMij netwerk. Om dit inzicht te hebben moeten verstoringen altijd zo snel mogelijk worden gesignaleerd en gemeld bij Supportal met de juiste prioritering (calamiteit, prio1, prio2, zie ook MedMij DAP en Bijlage 4). En elke deelnemer zo snel mogelijk geïnformeerd worden over de verstoringen die relevant zijn voor zijn applicatie. Zodat elke deelnemer ook zijn klanten (Zorgaanbieders voor DVA, en PGO-gebruikers voor DVP) hierover kan informeren.
Analyse en oplossing van de gemelde verstoringen worden daadwerkelijk uitgevoerd binnen de afgesproken tijden in de DAP door de betrokken deelnemers. De afspraken over analyse-tijden en oplostijden voor calamiteiten, prio1 en prio1 verstoringen in de MedMij DAP zijn opgenomen in bijlage 4. Binnen deze prio’s zijn alle geclassificeerde verstoringen opgenomen behalve een lokale verstoring.
De analyse van gemelde verstoringen wordt makkelijker.
MedMij Regie krijgt de beschikking over de benodigde gegevens van de uitwisseling in de keten om zijn centrale beheerrol goed uit te kunnen voeren. Dit betekent de juiste informatie om ook verstoringen te signaleren en melden, wanneer deelnemers zelf dit niet signaleren. Tevens beter te kunnen ondersteunen bij geëscaleerde verstoringen.
3.3. (Programma-) managers en (implementatie-)adviseurs van VIPP-programma’s, PGO on AIR, Stichting MedMij, VZVZ
Inzicht in structurele knelpunten, die worden ervaren, om op structurele oplossingen voor verbetering te kunnen sturen.
Inzicht of doorgevoerde oplossingen ook de knelpunten oplossen. En welke knelpunten niet opgelost worden en geëscaleerd zijn.
Inzicht in de toename/afname (trends)van PGO-gebruikers en gegevensdiensten gecategoriseerd naar deelnemer, (type) Zorgaanbieder en regio.
Inzicht in structurele barrières die PGO-gebruikers ervaren bij het PGO-gebruik. Een voorbeeld van een barrière die in het verleden genoemd is, is het niet kunnen vinden van een Zorgaanbieder.
Er worden nu ook al managementrapportage gemaakt op basis van de ontvangen beheerrapporten van deelnemers. Maar aanvullende informatie is gewenst van deelnemers. Welke gegevens precies aanvullend gewenst zijn is toegelicht in hoofdstuk 4.
5. Gewenst maar out of scope in dit vooronderzoek: Maandelijks overzicht welke Zorgaanbieders nieuw zijn op de ZAL, dreigen verwijderd te worden van de ZAL, of recent verwijderd zijn van de ZAL. Zodat met de betreffende Zorgaanbieders in overleg kan worden gegaan voor behoud op de ZAL.
3.4. Overig
Ook externe melders van verstoringen (PGO-gebruikers, Zorgaanbieder, etc) worden geïnformeerd over de status van de oplossing en wanneer het probleem is opgelost. Als knelpunt is aangegeven dat partijen die geen deelnemer zijn in het MedMij afsprakenstelsel lang niet altijd geïnformeerd worden over de status van een melding.
4. Informatiebehoefte
In dit hoofdstuk wordt de informatiebehoefte toegelicht voor '2.1. Signaleren, melden, analyseren en oplossen van verstoringen'. Daarna volgt de informatiebehoefte voor aanvullende managementinformatie toegelicht om '2.2 Beter te kunnen sturen op oplossingen van structurele problemen en trends'.
4.1. Signaleren, melden, analyseren en oplossen van verstoringen
In hoofdstuk 2 is in een tabel aangegeven welke problemen er nu worden ervaren bij het signaleren, melden, analyseren en oplossen van verstoringen. In deze paragraaf is aangegeven welke indicatoren en aanvullende afspraken gewenst zijn om deze problemen op te lossen.
4.1.1. Informatiebehoefte
ProbleemNr | ProbleemNaam | Benodigde indicatoren (in blauw lettertype staan de indicatoren, die nu nog niet beschikbaar zijn) | Aanvullend gewenste afspraken | Wie heeft dit nodig & Waarom | Nog te beantwoorden vragen bij verdere uitwerking |
|---|---|---|---|---|---|
A | Onvoldoende inzicht in de kwaliteit van de gegevensuitwisseling in de keten. | Gewenst is:
Het percentage of aantal succesvolle gegevensuitwisselingen wordt ook wel aangeduid met TOK. Het percentage of aantal onsuccesvolle gegevensuitwisselingen wordt ook wel aangeduid met TNOK. Hieronder is een voorstel gedaan voor de gewenste indicatoren om de kwaliteit van de gegevensuitwisseling in de gehele keten, en in delen van de keten te kunnen meten.
Doorsnedes moeten mogelijk zijn op basis van verschillende kenmerken. Zie voor voorbeelden hieronder:
| Om de kwaliteit van de gegevensuitwisseling betrouwbaar te kunnen bepalen is inzicht nodig in zowel de uitkomsten van de verzendende als de ontvangende schakel. Er kunnen verschillen zijn in het aantal gemeten requests en aantal succesvolle responses tussen de verzendende en ontvangende schakel. Om een voorbeeld te geven: De totale aantallen succesvolle en onsuccesvolle authorization en token requests uit de beheerrapporten verschillen nu per deelnemer. | Deelnemers, VZVZ, Stichting MedMij, financiers. Voor verantwoording en voor het signaleren en prioriteren van verstoring in de keten bij deelnemers. |
2. De DigiD-voorziening levert nu geen gegevens aan bij MedMij. Wil en kan Logius dergelijke gegevens delen? 3. Wat is de definitie van TOK en TNOK die gebruikt gaat worden van de gegevensuitwisseling in de gehele MedMij keten?
4. Welke gegevens van de schakels zijn precies nodig om het aantal en percentage TOK van de gegevensuitwisseling in de gehele keten te bepalen?
5. Wat is de frequentie waarmee deze indicatoren berekend moeten worden? Per uur/half uur/near real-time? De frequentie bepaalt hoe snel een verstoring op basis van deze indicatoren gesignaleerd kan worden. En schakels geïnformeerd kunnen worden over het bestaan van een verstoring. Het snel (near real-time) kunnen signaleren van een verstoring heeft verschillende voordelen:
|
B | Er kunnen geen garanties aan de PGO-gebruiker gegeven worden over de kwaliteit van gegevensuitwisseling die hij/zij mag verwachten. | Verschil tussen afgesproken ketennorm en %TOK alle opvragingen per schakel in de MedMij keten. | Afspraken over de gewenste invulling van de ketennorm. Zie ook bijlage 2. | Deelnemers, VZVZ, Stichting MedMij, om PGO-gebruikers een bepaalde garantie te kunnen geven voor kwaliteit van gegevensuitwisseling. | |
C | Niet alle verstoringen in de MedMij keten worden tijdig gesignaleerd en juist geprioriteerd. |
Daarnaast:
Voor prioritering van de verstoring:
| Deelnemers, VZVZ, om verstoring te signaleren en te prioriteren en de bron vast te stellen. Zodat deze verstoring gemeld kan worden met de juiste kenmerken op Supportal. | ||
D | Het achterhalen van de bron en oorzaak van een verstoring in de MedMij keten kost de servicedesks van deelnemers veel tijd. |
| Een wens van een aantal deelnemers is om fout-afhandeling te standaardiseren. En aanvullende afspraken over de gebruikte fout-terminologie in het MedMij afsprakenstelsel vast te leggen. En verplicht te stellen de fout volgens de afgesproken terminologie te registreren bij de verstoringsmelding in Supportal. Dit is ingebracht door deelnemers, wordt nog verder uitgevraagd door Kailesh & Floor | Deelnemers en MedMij Regie voor het signaleren, melden, analyseren en oplossen van de verstoring in de keten. Door het toevoegen van foutinformatie in een melding kunnen deelnemers, en via de de deelnemers ook de PGO-gebruiker, beter geïnformeerd worden over de bron en oorzaak van de verstoring. | 6. Welke aanvullende afspraken over de fout-terminologie zijn gewenst in het MedMij-afsprakenstelsel? |
E | Er is geen inzage in reactietijden van de schakels in de MedMij keten. | Gemiddeld, minimum en maximum verschil in tijd tussen de start van een opvraging in een PGO en ontvangst van het antwoord in de PGO voor alle DVP's en per DVP, en per gegevensdienst. Gemiddeld, minimum en maximum verschil in tijd tussen het verzenden, respectievelijk ontvangen van een (a) authorization requests en authorisation response en (b) token requests en token response
Gemiddeld, minimum en maximum verschil in tijd tussen het verzenden, respectievelijk ontvangen van een resource request en response
| Deelnemers en MedMij Regie voor signaleren van een vertraging in de keten bij deelnemers en kunnen informeren van andere deelnemers en PGO-gebruikers. | ||
F | Het is niet bekend of een technisch probleem, of een gebruikershandeling, of een restrictie van de Zorgaanbieder (bijvoorbeeld niet-succesvolle ontvankelijkheidstoets) de oorzaak is van een niet-succesvolle opvraging. |
Doorsnedes moeten mogelijk zijn op basis van verschillende kenmerken. Zie hieronder:
Voor huidige foutcodes, zie Autorisatie interface, Token Interface Resource interface | Deelnemers, MedMij Regie, VZVZ en Stichting MedMij voor het vinden van de oorzaken van verstoringen. | 7. Te bespreken: is dit noodzakelijk of wenselijk om dit inzichtelijk te hebben in de vorm van indicatoren? 8. Bepalen in overleg: Hoe gaan deze verschillende typen fouten worden onderscheiden, gelogd en gedeeld door deelnemers? Verder goed om mee te nemen: In het verleden is besloten om geen uitgebreide foutinformatie mee te sturen uit het oogpunt van beperken van veiligheidsrisico's. | |
G | Het is niet bekend of doorgevoerde oplossingen het gewenste resultaat hebben in de MedMij keten. | Toename/afname in % en aantal TOK gegevensuitwisselingen bij de schakels van de MedMij keten, waarbij de oplossing is doorgevoerd. Vanaf het moment van het doorvoeren van de oplossing. | Deelnemers, MedMij Regie, VZVZ en Stichting MedMij om te bepalen of uitgevoerde oplossingen het gewenste resultaat hebben. | ||
H | Er is geen inzage in trends in gegevensuitwisseling in de keten |
| VZVZ Security. Om pogingen tot hacking te signaleren is inzicht in trends belangrijk, die niet verklaard kunnen worden met de normale toename/afname in gegevensuitwisseling door bijvoorbeeld dag-nachtritme of door een verstoring. | ||
I | Geen inzage in de beschikbaarheid van de schakels in de keten | Beschikbaarheid van elke schakel in de keten. | Deelnemers en MedMij Regie voor signaleren van onbeschikbaarheid van schakels in de keten. Om deelnemers te kunnen informeren n PGO-gebruikers. | 9. Is hiervoor een pingfunctie gewenst om de 5 minuten bijvoorbeeld van de verschillende schakels?
| |
Aanvullingen? |
4.1.2. Gewenste functionaliteiten
Naast invulling van de informatiebehoefte is aangegeven dat onderstaande functionaliteiten voor het eenvoudiger signaleren en melden van verstoringen wenselijk (nice to have) zijn:
Mogelijkheid tot inrichten van automatische detectie van verstoringen (middels zogenaamde watchdogs)
Automatisch aanmaken van meldingen van verstoringen in Supportal. Dit verkleint de inspanning voor het melden van verstoringen. Daarnaast maakt het mogelijk om daadwerkelijke oplostijden per verstoringen vast te leggen, omdat de verstoring meteen gemeld wordt bij signalering.
Het automatisch informeren van de betrokken deelnemers over een verstoring waarbij zij betrokken zijn.
Supportal beschikt niet binnen MedMij niet over de bronsysteem ID’s (MedMij naam of een AppID) binnen MedMij. Dit ervaren de beheerders als een knelpunt omdat ze een storingsmelding nu niet feitelijk correct kunnen aanmaken. De wens is dat dit wel mogelijk is.
Mogelijkheid tot inrichten van dashboards voor snel overzicht van de relevante gegevens
4.1.3. Overige punten
Tenslotte is aangegeven dat aanvullende afspraken wenselijk over het gewenste proces voor afhandeling van meldingen door de helpdesks van deelnemer:
Zoals de afhandeling van meldingen van PGO-gebruikers door de PGO-helpdesk, waarbij de gemelde verstoring in zijn/haar PGO niet verholpen kan worden door de helpdesk van de DVP. Zodat de PGO-gebruiker niet langer van de ene schakel (DVP) naar andere schakels in de keten (DVA, Zorgaanbieder) gestuurd wordt bij een probleem in de PGO. En het gevoel heeft van het kastje naar de muur te worden gestuurd.
Ook externe melders van verstoringen (PGO-gebruikers, Zorgaanbieder, etc) worden geïnformeerd over verstoringen. Maar ook de status van een melding wanneer zij deze gedaan hebben, en wanneer zij een oplossing kunnen verwachten.
4.2. Sturen op oplossingen van structurele problemen en trends
4.2.1. Scenario's /oplossingsrichtingen
De wens van (Programma-) managers en (implementatie-)adviseurs van VIPP-programma’s, PGO on AIR, Stichting MedMij, VZVZ is om meer informatie te ontvangen in de maandelijkse managementrapportages, zie ook hoofdstuk 2. Er zijn verschillende mogelijkheden om deze aanvullende informatie te verzamelen:
Voor aanvullende informatie in managementrapportages over toename PGO-gebruik, aantal succesvolle resource requests per Zorgaanbieder, etc:
Kunnen deelnemers gevraagd worden middels uitbreiding van hun beheerrapporten.
Maar het is ook mogelijk om deze managementrapportages te maken op basis van de gegevens die deelnemers gaan delen voor monitoring van verstoringen.
Informatie over structurele knelpunten en of doorgevoerde oplossingen ook de knelpunten oplossen kan in de toekomst mogelijk gedeeld worden via managementrapportages van Supportal en de geëscaleerde meldingen in JIRA. Er worden nu managementrapportages gemaakt van de meldingen op Supportal en van de escalaties in JIRA en gedeeld met de verantwoordelijken binnen VZVZ. Deze zijn (voor zover bekend) echter niet inzichtelijk voor managers buiten VZVZ. Daarnaast is het overzicht van de meldingen en oplostijden op Supportal nu niet erg accuraat. Want lang niet alle verstoringen worden nu gemeld, of meteen gemeld na signalering. Wanneer verstoringen in de toekomst echter automatisch gemeld worden op Supportal is de informatie over aantallen verstoringen, bij welke deelnemer, oplostijden etc. wel accuraat.
4.2.2. Informatiebehoefte
In onderstaande tabel staan de gegevens die aanvullend gewenst zijn van deelnemers in beheerrapporten. In bijlage 7 is aangegeven welke gegevens van Deelnemers nu gevraag wordt in de beheerrapporten.
Nr | Vraag | Wat wordt precies gemeten door Deelnemer? (in blauw lettertype staan de gegevens, die nu nog niet beschikbaar zijn, maar wel gewenst zijn) | Nog te beantwoorden vragen bij verdere uitwerking |
1. | Zijn er specifieke DVP’s of DVA’s met problemen op het gebied van autorisatie voor specifieke gegevensdiensten en bij specifieke Zorgaanbieders? | · Het aantal onsuccesvolle autorisatie requests wordt al aangeleverd door de DVA per gegevensdienst met de indicator AuthorizationRequestNumbers.AantalOnSuccesvol, maar niet per gegevensdienst in de combinatie met Zorgaanbieder. En niet per DVP. Dit is een gewenste uitbreiding · De DVP levert alleen de succesvolle autorisatie requests per gegevensdienst op met de indicator AuthorizationRequestNumbers.AantalSuccesvol, maar niet de onsuccesvolle autorisatie requests. En ook niet per Zorgaanbieder en per DVA. Dit is een gewenste uitbreiding. · Het aantal niet succesvolle autorisatie requests per reden per gegevensdienst (identificatie afgebroken door gebruiker, toestemming niet gegeven door gebruiker, technische fout) wordt ook nog niet aangeleverd door de DVP en DVA. Opmerkingen: · in een autorisatie request mogen meerdere gegevensdiensten van eenzelfde Zorgaanbieder worden gecombineerd. De opgetelde totalen van de autorisatie requests per gegevensdienst zijn hierdoor groter dan het totaal aantal autorisatie requests. · Er zijn verschillen in de aantallen (authorization, token en resource) requests die gerapporteerd worden door de deelnemers. De aantallen Authorization Requests, Token Requests, en Resource Requests die de DVA's rapporteren komen niet overeen met de aantallen die de DVP's rapporteren. De verwachting is dat dit komt doordat zij een verschillende definitie hanteren. |
|
2. | Zijn er specifieke DVP’s of DVA’s met problemen op het gebied van token request voor specifieke gegevensdiensten en bij specifieke Zorgaanbieders? | · Het aantal onsuccesvolle token requests per gegevensdienst wordt al aangeleverd door DVP en DVA met de indicator TokenRequestNumbers.AantalOnsuccesvol · Het aantal onsuccesvolle token requests per gegevensdienst in de combinatie met Zorgaanbieder is een gewenste uitbreiding, Daarnaast per gegevensdienst en DVA (voor de DVP). En per gegevensdienst en DVP (voor de DVA) · Het aantal onsuccesvolle token requests per reden per gegevensdienst geweigerd, time-out, anders) is een gewenste uitbreiding. Zie ook opmerking hierboven. Opmerking: Net als in een autorisatie request kunnen in een token request meerdere gegevensdiensten van eenzelfde Zorgaanbieder worden gecombineerd. De opgetelde totalen van de token requests per gegevensdienst zijn hierdoor groter dan het totaal aantal token requests. | |
3. | Zijn er specifieke gegevensdiensten met problemen (en bij welke resources dan specifiek)? Bestaan deze problemen specifiek voor bepaalde DVA's of DVP's? | · Het aantal onsuccesvolle resource requests per gegevensdienst wordt gemeten door DVP's en DVA's met de indicator ResourceRequestNumbers.AantalOnsuccesvol. Dit wordt echter niet per DVA gemeten door DVP's. En per DVP (door DVA's). Dit is een gewenste uitbreiding. · Het aantal onsuccesvolle Resource requests per resource en reden (Succesvol met inhoud, geen informatie beschikbaar en mislukt) wordt nog niet aangeleverd en is een gewenste uitbreiding. | |
4. | Zijn er specifieke Zorgaanbieders met problemen bij specifieke gegevensdiensten (en bij welke resources dan specifiek)? | · Het aantal onsuccesvolle resource requests per gegevensdienst en Zorgaanbieder wordt niet gemeten en is een gewenste uitbreiding. · Daarnaast het aantal niet succesvolle Resource requests per resource en reden (Succesvol met inhoud, geen informatie beschikbaar en mislukt) per Zorgaanbieder. | |
5. | Trend (afname/toename) in aantal unieke PGO- gebruikers per regio en/of (type) Zorgaanbieder | MedMijRapport.Beheerrapport.Personen.AantalActiefSuccesvol. Dit wordt niet vastgelegd door een DVA, is dit een wens? Nog checken. · Het aantal unieke en succesvolle PGO-gebruikers dat gegevens verzamelt of deelt via een gegevensdienst per Zorgaanbieder, wordt nu niet aangeleverd door een DVP of DVA. Opmerkingen hierbij: - De trend per regio en type Zorgaanbieders kan vervolgens berekend worden door een BI-analist door de individuele Zorgaanbieders te categoriseren naar type (GGZ, huisarts, ziekenhuis, etc) en naar regio. - Het precieze aantal unieke PGO-gebruikers per Zorgaanbieder in Nederland kan met deze aangeleverde indicator door DVP's en DVA's niet berekend worden. Dit heeft de volgende redenen: Een DVA kan een overzicht aanleveren hoeveel unieke PGO-gebruikers er zijn per Zorgaanbieder. Een Zorgaanbieder kan echter meerdere DVA’s gebruiken voor verschillende gegevensdiensten. En de tellingen van verschillende DVA’s kan niet simpelweg worden gecombineerd, want dezelfde PGO-gebruiker kan gebruik maken van allebei de DVA’s. Daarnaast kan een PGO-gebruiker meerdere DVP’s gebruiken. Opmerking: Trendinformatie is voldoende om inzicht te hebben in verslechtering of verbetering en te kunnen sturen. Het exacte aantal PGO-gebruikers in Nederland is niet nodig. | |
6. | Welke gegevensdienst(en) een unieke PGO-gebruiker gebruikt per (type) Zorgaanbieder en/of regio ? | Dit wordt nu niet gedeeld. Hiervoor moet een DVP of DVA het aantal succesvolle PGO-gebruikers per gegevensdienst en per Zorgaanbieder aanvullend delen. Zie verder ook opmerkingen hierboven. | |
7. | Hoeveel PGO-gebruikers gegevens van meerdere Zorgaanbieders ophalen? | Dit wordt nu niet gedeeld. De indicator in de regel hierboven kan deze indicator berekend worden. Zie ook opmerkingen hierboven. | |
8. | Hoe vaak gebruikt iemand zijn PGO? | Dit wordt nu niet gedeeld. Hiervoor met een DVP het aantal keren dat dezelfde gebruiker inlogt op zijn PGO binnen een bepaalde periode aanvullend delen. | |
9. | Verdeling van PGO-gebruikers over doelpopulaties. | Deze wens komt vanuit een slide uit een breder onderzoek van Gupta. De wens is om inzicht te krijgen of mensen met een chronische ziekte of intensief zorggebruik meer gebruik maken van PGO's dan mensen die geen ziekte hebben. De hypothese is dat bij deze doelgroepen meer baten zijn bij het gebruik van een PGO. Deze informatie kan niet verzameld worden door de deelnemers. Hiervoor is een gericht gebruikersonderzoek onder deze doelgroepen beter geschikt. | |
10. | Nice to have: Aantal PGO's dat een unieke PGO-gebruiker gebruikt |
4.2.3. Gewenste functionaliteiten
Naast de wens voor aanvullende informatie in managementrapportages, bestaan er de volgende wensen over aanvullende functionaliteiten, zoals:
Gegevens worden grafisch weergegeven en begrijpelijke termen worden gebruikt. Bijvoorbeeld geen gegevensdienst (3,4), maar de naam van de gegevensdienst. En geen termen zoals OAuth maar een algemeen begrijpelijke term. En wordt bijvoorbeeld een plaatje van de MedMij keten toegevoegd in de managementrapportage, om uit te leggen bij welke gegevensuitwisseling tussen schakels in de keten een autorisatie request hoort, bij welke een token request, etc.
Management-overzichten kunnen per manager en/of organisatie ingericht kunnen worden. De managementinformatiebehoefte is immers verschillend per partij of programma. Dit komt dat deze elk een eigen opdracht en rol hebben.
Specifieke vragen beantwoord kunnen worden met behulp aanvullend onderzoek van de gegevens door een BI-analist.
Er kunnen benchmarks gemaakt worden van de gegevens. Bijvoorbeeld voor een deelnemer kan inzichtelijk gemaakt worden hoeveel verstoringen deze deelnemer heeft ten opzichte van het totaal.
In de managementrapportages wordt de toe- en afname van aantal actieve PGO-gebruikers in 1 jaar bijgehouden. Gewenst is ook een historisch overzicht van het aantal actieve PGO-gebruikers vanaf de start van het MedMij-afsprakenstelsel tot nu.
4.2.4. Overige punten
De mensen die toegang hebben tot de managementrapportages wordt uitgebreid. Ook programma-managers van programma’s buiten VZVZ en MedMij die zich bezighouden met de implementatie van gegevensdiensten hebben inzicht tot de voor hen relevante gegevens. En in de toekomst zijn dit mogelijk ook instanties zoals ICTU, projectleiders bij Zorgaanbieders, koepel- en branche-organisaties. Dit nu niet het geval.
5. Stakeholders en draagvlak
Het draagvlak bij de deelnemers voor verbetering van de monitoring en managementrapportages is nog niet uitgevraagd in dit vooronderzoek.
Het draagvlak van de al bevraagde stakeholders ((Project-) Managers van Stichting MedMij, VZVZ, VIPP-programma's en programma PGO On Air, MedMij Regie, Stichting MedMij, VZVZ) is groot.
6. Beperkingen (scope) en uitsluitingen
Een oplossingsrichting voor het signaleren, melden, analyseren en oplossen van inhoudelijke fouten is niet meegenomen in dit vooronderzoek. Een inhoudelijke fout is dat de gegevens zoals ze getoond worden in de PGO niet overeenkomen met de gegevens zoals in het XIS. Hiervoor zijn verschillende oorzaken zoals : de waardenlijsten van een attribuut uit een zib van de PGO, verschilt van het XIS. Er worden verschillende codestelsels gebruikt door het XIS en PGO. Inhoudelijke fouten zijn kritisch, want hierdoor kan een PGO-gebruiker verkeerde gegevens ontvangen, zoals bijvoorbeeld een verkeerd doseringsadvies bij een medicijn. Inhoudelijke fouten zijn echter niet te signaleren op basis van loggegevens van deelnemers. De gegevensuitwisseling tussen de verschillende schakels in de keten zijn meestal succesvol. Het advies is daarom om hiervoor een apart vooronderzoek op te starten. Eerder onderzoek na het signaleren van inhoudelijke fouten is gedaan door Nictiz [4].
Gewenst maar out of scope in dit vooronderzoek: Maandelijks overzicht welke Zorgaanbieders nieuw zijn op de ZAL, dreigen verwijderd te worden van de ZAL, of recent verwijderd zijn van de ZAL. Zodat met de betreffende Zorgaanbieders in overleg kan worden gegaan voor behoud op de ZAL. Voorstel is om deze wens op te pakken in apart project of vooronderzoek.
7. Relaties met andere projecten en RFC's
Wat | Datum |
Pascale Buesink een voorstel geschreven voor RFC ketenlog voor verbetering kwaliteit van zorgcommunicatie op ketenniveau Er is toen ook een RFC [AF-1104] Ketenlog - PIM (vzvz.nl) aangemaakt | 17 maart 2019 |
[AF-425] Welke eisen stelt ketentracing aan identifiers, logging en bewaartermijnen? - PIM (vzvz.nl) | 6-12-2017 |
3-12-2019 | |
24-2-2020 | |
[AF-1193] ManagementInformatie uitbreiden met 'aanwas' (personen.aantal.nieuw) - PIM (vzvz.nl) | 25-05-2020 |
24-01-2021 | |
Advies Realtime decentrale berichtcontrole, Nictiz | 19-08-2021 |
[AF-1293] Best practice inzicht logging bij problemen in productie - PIM (vzvz.nl) | 16-09-2021 |
[AF-1371] Verbeteren MedMij Managementrapportage - PIM (vzvz.nl) | 26-01-2022 |
Start Project Validatieloket | Juli 2022 |
13-09-2022 | |
Oktober 2022 | |
Overgang van R&A Node van POC naar definitief product | Hierover worden nu gesprekken gevoerd met de betrokken leverancier |
Duiding van fouten en foutcodes in FHIR | Hierover wordt nu overleg gevoerd met betrokkenen door VZVZ oa voor AORTA. |
Aanvullingen? |
8. Randvoorwaarden
Nr | Randvoorwaarde | Toelichting | (Evt) Status voortgang invulling randvoorwaarde |
1. | Gegevens die deelnemers delen met MedMij en VZVZ voor het signaleren, melden, analyseren en oplossen van verstoringen en voor managementrapportages is proportioneel met de informatiebehoefte | Er wordt duidelijk beschreven welke gegevens nodig zijn voor welk doeleinde en welke informatiebehoefte. Er worden niet meer loggegevens gedeeld van deelnemers dan nodig is voor de informatiebehoefte | |
2. | Er wordt voldaan aan vigerende wetgeving zoals de AVG | · Er mogen geen persoonsgegevens gedeeld worden of medisch inhoudelijke gegevens alleen transactie gegevens. · Geen gebruik van BSN’s of andere privacygevoelige informatie Opmerking: Wanneer de scope toch mocht veranderen, en het wel persoonsgegevens gewenst wordt om persoonsgegevens te delen, verandert de doorlooptijd van het project aanzienlijk. Omdat er dan aanvullende contracten nodig zijn tussen de betrokkenen voor afspraken over het gebruik van de persoonsgegevens. Een rechtmatige grondslag voor de verwerking is vereist. | |
3. | Er wordt zorgvuldig omgegaan met concurrentie-gevoelige informatie | Deelnemers hebben geen inzage in de activiteiten van andere deelnemers tenzij dit noodzakelijk is voor het oplossen van verstoringen. | |
4. | Bereidwilligheid van alle betrokkenen om een oplossing te ontwikkelen voor het verbeteren van het signaleren, melden, analyseren en oplossen van verstoringen. En het uitbreiden van de managementrapportages. | ||
5. | Vanuit de NEN7513:2018- Voor een persoonlijke gezondheidsomgeving (PGO) ligt de verantwoordelijkheid voor de logging bij de aanbieder van de PGO | ||
5. | Aanvullingen? |
9. Risico's
Nr | Risico | Kans (1-10) | Impact (1-10) | Maatregelen |
1. | Er wordt geen overeenstemming bereikt over de informatiebehoefte en/of benodigde oplossing | Ntb | Ntb | Deelnemers geven aan dat het belangrijk is om te beginnen in plaats van over en over-analyses te doen van de exacte informatiebehoefte. Voorstel: starten met een minimale set en deze vervolgens gefaseerd uitbreiden |
2. | Het duurt erg lang om instemming van ZorgAanbieders te verkrijgen om deel te nemen aan het MedMij afsprakenstelsel. En bijvoorbeeld de relevante loggevens te delen van het XIS. | Ntb | Ntb | |
3. | Het is niet mogelijk om van Logius aanvullende gegevens te krijgen over de gegevensuitwisseling van de DigiD-voorziening in de MedMij keten. | Ntb | Ntb | |
4. | Benodigde resources (capaciteit/geld/kennis) zijn afwezig | Ntb | Ntb | |
5. | Aanvullingen? |
10. Advies voor vervolgstappen
De volgende vervolgstappen worden geadviseerd voor:
10.1. Signaleren, melden, analyseren en oplossen van verstoringen
In kaart brengen van de informatiebehoefte in vooronderzoek van intern betrokkenen (MedMij, VZVZ)
Toetsen of beschreven problemen, informatiebehoefte in het vooronderzoek juist zijn met intern betrokken op 23 januari. Daarnaast gewenste oplossingsrichtingen bespreken
Toetsen van informatiebehoefte met deelnemers op expertsessie (planning is op expertsessie 8 of 15 februari) en uitvragen van gewenste oplossingsrichting
Bepalen (officieel besluit door MT) van de gewenste oplossingsrichting.
Start project voor het inrichten van de oplossing. Onderdelen van het projectplan zijn bijvoorbeeld:
Onderzoek naar naar welke tooling het meest geschikt is voor de oplossing
Aankoop en inrichting van de tool
Indien nodig, uitbreiding van de beheerorganisatie van MedMij Regie.
Uitbreiden van MedMij DAP en afsprakenstelsel waar nodig. Onder andere gebied op het gebied van governance.
Parallel hieraan:
Onderzoeken welke deelnemers al willen starten met een pilot op korte termijn voor het verbeteren van het signaleren, melden, analyseren en oplossen van verstoringen. Om ideeën in de praktijk te toetsen.
Ook parallel hieraan:
Nog openstaande vragen beantwoorden in het vooronderzoek. Openstaande vragen zijn bijvoorbeeld:
Of en op welke termijn Zorgaanbieders de relevante gegevens van de gegevensuitwisseling van het XIS in de MedMij keten kunnen delen
Wat de mogelijkheden zijn van Logius om relevante gegevens van de gegevensuitwisseling van de DigiD-voorziening in de MedMij keten te delen
Welke mogelijkheden er zijn voor deelnemers om PGO-gebruikers en externe partijen zoals Zorgaanbieders beter te ondersteunen en informeren over de status van hun melding.
Afstemmen, wie welke activiteit gaat uitvoeren.
Bepalen of er een en projectleider verantwoordelijk gemaakt wordt voor de coördinatie en timemanagement?
10.2. Sturen op oplossingen van structurele problemen en trends
Bepalen welke oplossingsrichting het meest geschikt zijn voor managementrapportages met de aanvullend gewenste informatie:
Worden deelnemers om meer gegevens in de beheerrapporten gevraagd?
Of kunnen de managementrapportages worden gemaakt op basis van aanvullende gegevens die deelnemers gaan delen voor het monitoren van verstoringen. Of dit mogelijk is, is afhankelijk van de uiteindelijke oplossing die hiervoor gekozen wordt.
Daarnaast antwoord op de vraag: Kunnen in de toekomst ook managementrapportages gemaakt worden van Supportal en JIRA met de benodigde informatie over structurele knelpunten en verstoringen? Onze inschatting is dat dit een goede oplossing kan zijn.
Parallel hieraan
Nog openstaande vragen beantwoorden
Voorstel maken van de benodigde aanpassingen in MedMij afsprakenstelsel
Bepalen welke tool gebruikt kan worden voor de verbeterde weergave van de managementrapportages (visueel, met toelichting van afkortingen) . En of er extra capaciteit nodig is van BI-analist voor het vormgeven van deze managementrapportages.
10.3. Overig
Voorleggen aan kernteam of de issues die in het vooronderzoek naar voren zijn gekomen, maar buiten scope zijn geplaatst, in een apart project of vooronderzoek opgepakt moeten worden. Dit betreft de issues:
Een oplossingsrichting voor het signaleren, melden, analyseren en oplossen van inhoudelijke fouten
Daarnaast de wens voor een maandelijks overzicht welke Zorgaanbieders nieuw zijn op de ZAL, dreigen verwijderd te worden van de ZAL, of recent verwijderd zijn van de ZAL. Zodat met de betreffende Zorgaanbieders in overleg kan worden gegaan voor behoud op de ZAL.
11. Bijlage 1 Wie is er gesproken
Wie | Functie |
|
Bart Brandenburg | Programmamanager Vipp OPEN | |
Bastiaan Martens | Adviseur Markt & Klant VZVZ | |
Bouke de Boer | Productowner MedMij | |
Carlos Villabaars | Werkgroepleider Praktijkmonitoring | |
Cevin Krooneman | Projectleider Validatieloket | |
Floris Dierick | Functioneel beheerder MedMij | |
Maarten Schmidt | Risk and Security manager VZVZ | |
Marc van Dijk | Directeur Stichting MedMij | |
Margo Brands | Teamleider Relatiebheer en Projecten | |
Paul Hoogland | Programmamanager van Vipp5 voor de NFU | |
Pascale Klop | Teamleider MedMij Beheer | |
Stefan Thie | ICT-Ketencoördinator at VZVZ | |
Tijmen de Boer | Teamleider Ketenregie VZVZ | |
Wouter Roorda | Datascientist bij VIPP OPEN | |
MITZ/Albert Vlug? | ||
Gregory Scholten (Nictiz) | ||
Arnold van Beuzekom | Itzos (LSP+ DVZA) |
12. Bijlage 2: Toelichting ketennorm
De beschikbaarheid in de AORTA-keten wordt berekend aan de hand van het aantal Technisch OK (TOK) berichten, zie de DAP van AORTA van 19-11-2021. Technisch OK betekent dat elke applicatie in de AORTA keten werkt volgens eisen uit ontwerp, kwalificatie en acceptatie. Dit is het verkeer dat, op berichtniveau, het verwachte resultaat voor de GBZ oplevert. In de LSP-dagrapportage is uitleg te vinden over de betekenis van de resultaatcodes en of deze Technisch OK zijn of niet.
AORTA-regie hanteert de volgende berekening en norm:
Norm Ketenbeschikbaarheid = (Aantal TOK berichten / Totaal aantal berichten) x 100% ≥ 99,5%
Het voorstel is om ook voor MedMij een ketennorm te definieren, zie toelichting hieronder. De MedMij keten bestaat uit een aaneenschakeling van diverse technische componenten.
Definitie van een technische hoofdcomponent: Een technische hoofdcomponent zoals een PGO, de Stelselnode, DVA, DigID of een bronsysteem, bestaat uit een aantal servers welke gezamenlijk een onderdeel van de totale MedMij dienstverlenging leveren. De PGO is zo’n technische hoofd omponent en vormt binnen MedMij het startpunt en het eindpunt van de MedMij- keten.
Definitie van de MedMij ketennorm: Het percentage burgers dat in een PGO geklikt heeft op een knop om gegevens op te halen via MedMij en uiteindelijk in zijn PGO deze gegevens technisch OK te zien moet
Definitie van Technisch OK: Onder Technisch OK wordt verstaan dat de afwikkeling van een verzoek een Technisch OK resultaat teruggeeft.Onder Technisch NOK wordt verstaan dat de afwikkeling van een verzoek door de technische omponent een Technisch Niet OK resultaat teruggeeft.TOK is dus niet hetzelfde is als uptime. Immers, een hoofd omponent kan best de gehele nacht eruit liggen (66% uptime/onderhoud) en 99,9% TOK reageren omdat er alleen tijdens kantooruren een beroep om hem wordt gedaan.
13. Bijlage 3 Oplostijden
Bron MedMij DAP 22-09-2021
14. Bijlage 4: Mogelijke loggegevens per deelnemer
Eerste voorzet voor welke loggegevens van een schakel nodig zijn van een individuele transactie:
de gebruikte versie van het afsprakenstelsel (Omdat soms dingen het wel in de ene dakpan doen, maar niet in de andere dakpan).
timestamp
Trace ID. Opmerking hierbij: Er is een al een MedMij-request-ID beschikbaar, zie link naar betreffend onderdeel in Afsprakenstelsel. Indien wenselijk, moet verder onderzocht worden of dit geschikt is als Trace-ID. Deze informatie is nu opgehaald over de het MedMij-request-ID. Moet nog verder nagevraagd worden bij Casper: Het MedMij-request-ID is (na een RFC ingediend door Maarten Schmidt in 2019-2020) geïmplementeerd door een DVA in geval van een resource request richting een Zorgaanbieder. (De aanleiding voor deze RFC was een security incident). De keten kent echter veel meer schakels.Een ID om berichten over al die schakels te kunnen Tracen is nog niet geimplementeerd.
Type request (authorization, token, resource)
ID, FQDN van Verzendende en Ontvangende schakel
Scope (Identifiers gegevensdiensten)
Resultaat (OK of een exception), en evt toelichting op de exception.
Door elke DVP dient in de logregel aanvullend
het type en versie PGO : webapp of app en het OS gelogd te worden (Omdat soms dingen het bijvoorbeeld wel in de webinterface doen, maar niet in de app van Apple, en wel in de app van Android.).
Door elke DVA dient in de logregel aanvullend
de naam en versie van de DVA meegestuurd te worden.
Door elke Zorgaanbieder dient in de logregel aanvullend
Naam en versie van de XIS meegestuurd te worden.
Foutcodes die onderscheiden kunnen worden (dit overzicht is nog niet compleet)
Nr | Naam stap | Tussen welke schakels | Toelichting | Mogelijke foutcodes | ||
3 | Authenticatie | DVA- DigiD | Afhankelijk of gebruik wordt gemaakt van CGI of SAML codes. Navraag gedaan bij Ron v Holland betreft de foutcodes bij LSP+: SAML-statuscodes “Authnfailed” en “Succes” |  Reden van de fout die terugkomt van DigiD inclusief fouten die de PGO-gebruiker maakt (BSN onbekend, wachtwoord vergeten, wachtwoord verkeerd etc) | ||
4 | Authorization response | o <succesvol, code aanwezig> o <Error> onsuccesvol, redenen § identificatie afgebroken door gebruiker, § toestemming niet gegeven door gebruiker) § technische fout | ||||
6 | Token Request | Uitwisselingsproblemen kunnen ook veroorzaakt worden door moeilijkheden bij het token request. De logging van de onderstaande gegevens kan bijdragen aan het sneller identificeren van de bron van het probleem met uitwisseling.
| · o Inhoud · HTTP 200, ZAL is geleverd · HTTP 40X, Niet gespecificeerd in het afsprakenstelsel · HTTP 50X, Niet gespecificeerd in het afsprakenstelsel · TimeOut · Unreachable URL |
Mogelijke loggegevens per schakel in de keten (op basis van informatie van Jeroen)
Schakel | Mogelijke loggegevens | Opmerkingen |
DVP | · Identificatie DVP · Eindpunt (waar we de vraag stellen) · Welk bronsysteem bevragen we · Status langdurige toestemming (of in foutreden) · Transactie ID (OID?) · Timestamp start transactie · Timestamp start verzamelen DVP (moment ) · Timestamp gereed verzamelen DVP (moment antwoord terug) · Timestamp gereed transactie | (let op, geen DigID bij eenmalige toestemmingen) |
DVP 1:N per Gegevensdienst (Endpoint of ID?)
| Resultaat (code + omschrijving) 1. Success 2. DigID : a. Succes b. Hergebruik token c. Token verlopen (wellicht niet) d. Gebruik van een verkeerde gebruikersnaam of wachtwoord bij DigiD tov PGO e. Gebruik van een verkeerde gebruikersnaam of wachtwoord bij DigiD f. DigiD is geblokkeerd g. DigiD mobiele app werkt niet h. Time-out: Sessie verlopen door 15 minuten geen activiteit i. Browser accepteert geen cookies j. Browser in privé, incognito- of geheimmodus k. Tijdsinstelling ongelijk op 2 apparaten l. IP-adres is tijdens het inloggen veranderd: switch van zendmast of wifi m. Storing bij DigiD of onderhoud: check bij logius (https://www.logius.nl/storing-en-onderhoud) n. Niet goed geautoriseerd: DigiD o. Persoon stopt de flow: Pgo krijgt geen response bericht. PGO leveranciers kunnen dit peilen door de verhouding requests en succesvolle ophalingen bij DVA te bekijken. p. @@@ 3. DVP q. DVA is niet bereikbaar r. DVA antwoordt niet binnen termijn s. Antwoord nonconform t. @@@ | |
DVA | · Identificatie DVP · Transactie ID (van DVP) · Timestamp start transactie · @@@ DIGID? | |
DVA: 1:N Per ZA/gegevensdienst
| 1. ZA (ID) 2. Gegevensdienst (ID) 3. Timestamp start verzamelen ZA 4. Timestamp gereed verzamelen ZA 5. Resultaat ZA (code + omschrijving) a. Succes b. Persoon komt niet voor in het XIS van de Aanbieder. c. Aanbieder weigert gegevens te delen van personen d. Aanbieder weigert gegevens te delen van de Persoon e. Aanbieder is niet beschikbaar voor het delen van gegevens f. Aanbieder antwoordt niet binnen termijn. Nvt de redirect kan lang duren waardoor informatie na bevestiging een dag later kan worden opgehaald (asynchroon) g. ZA is niet bereikbaar h. ZA antwoordt niet binnen termijn i. Technisch fout: (waar ligt de fout→ bel de juiste persoon → systeembeheerder benadert log) 6. Resultaat DVP 7. Timestamp eind transactie 8. Succes 9. Foutsituatie @@@ a. Technische fouten @@@ | |
Overig | · Welke onderdelen van het bericht zijn gevuld (tegengaan information blocking) · De omvang van het bericht · Soort bericht |
15. Bijlage 5 Referenties
https://afsprakenstelsel.medmij.nl/display/medmijafsprakenstelsel150/Managementinformatie
MedMij DAP
Advies Realtime decentrale berichtcontrole, Nictiz, 19-08-2021
Vooronderzoek Praktijkmonitoring en Manangementrapportageoplossing, Cevin Krooneman 02-11-2022
16. Bijlage 6 Huidige managementinformatie
Bron [1]
| naam in het logische model | definitie voor de Dienstverlener persoon | definitie voor de Dienstverlener zorgaanbieder |
algemeen | MedMijRapport.Deelnemer | de identificatie van de Dienstverlener persoon | de identificatie van de Dienstverlener zorgaaanbieder |
MedMijRapport.Vanaf | begindatum en -tijdstip van de periode die de rapportage beslaat: altijd 00h00m00s van de eerste van een kalendermaand | begindatum en -tijdstip van de periode die de rapportage beslaat: altijd 00h00m00s van de eerste van een kalendermaand | |
MedMijRapport.Tot | einddatum en -tijdstip van de periode die de rapportage beslaat: altijd 00h00m00s van de eerste van de kalendermaand die volgt op MedMijRapport.Vanaf | einddatum en -tijdstip van de periode die de rapportage beslaat: altijd 00h00m00s van de eerste van de kalendermaand die volgt op MedMijRapport.Vanaf | |
MedMijRapport.Tijdstempel | datum en tijdstip van het moment waarop het rapport is aangemaakt | datum en tijdstip van het moment waarop het rapport is aangemaakt | |
personen | MedMijRapport.Beheerrapport.Personen.Aantal | het aantal unieke gebruikers (accounts) van de PGO van die Dienstverlener persoon, gedurende de rapportageperiode | Dit element dient niet te worden aangeleverd. |
MedMijRapport.Beheerrapport.Personen.AantalActiefSuccesvol | Aantal unieke gebruikers (Accounts) die in deze periode minimaal één request op een resource interface hebben verstuurd waarop een succesvolle resource respons werd ontvangen | Dit element dient niet te worden aangeleverd. | |
MedMijRapport.Beheerrapport.Personen.AantalActiefOnsuccesvol | Aantal unieke gebruikers (Accounts) die in deze periode minimaal één request op een resource interface hebben verstuurd waarop een niet-succesvolle resource respons werd ontvangen | Dit element dient niet te worden aangeleverd. | |
MedMijRapport.Beheerrapport.Personen.AantalActiefSuccesvolNieuw | Aantal unieke gebruikers (Accounts) die in deze periode minimaal één request op een resource interface hebben verstuurd waarop een succesvolle resource respons werd ontvangen EN die die in voorafgaande periodes binnen dit kalenderjaar NIET voor deze indicator zijn geregistreerd (zie toelichting onder tabel). | Dit element dient niet te worden aangeleverd. | |
per Gegevensdienst: | AuthorizationRequestNumbers.AantalSuccesvol | het aantal keren dat de DVP Server voor deze Gegevensdienst een authorization code heeft ontvangen. | |
AuthorizationRequestNumbers.AantalOnsuccesvol | Dit element dient niet te worden aangeleverd. | ||
TokenRequestNumbers.AantalSuccesvol | |||
TokenRequestNumbers.AantalOnsuccesvol | |||
ResourceRequestNumbers.AantalSuccesvol | |||
ResourceRequestNumbers.AantalOnsuccesvol | |||
SubscriptionRequestNumbers.AantalSuccesvol | |||
SubscriptionRequestNumbers.AantalOnsuccesvol | |||
SubscriptionNotificationNumbers.AantalSuccesvol | |||
SubscriptionNotificationNumbers.AantalOnsuccesvol | |||
ResourceNotificationNumbers.AantalSuccesvol | |||
ResourceNotificationNumbers.AantalOnsuccesvol |