Met een groep experts vanuit de deelnemers en de beheerorganisatie is gekeken naar verbetermogelijkheden rond de Managementrapportage van MedMij. Hieronder zijn de uitkomsten beschreven.

De informatieboxen geven uitkomsten die niet direct tot actie behoeven
De waarschuwingsboxen geen uitkomsten aan waar een vervolgactie op zijn plaats is (actiehouder is de Beheerorganisatie)

Wat willen/kunnen we weten/meten?

Vragen die aan MedMij gesteld worden vanuit diverse stakeholders blijken in praktijk lastig/niet beantwoordbaar door Managementrapportage. Dit zijn vragen als:

Hoeveel mensen gebruiken MedMij?
Hoeveel gebruikers van MedMij lukt het om hun gegevens op te halen?
Zijn gebruikers tevreden over MedMij?

Uit de discussie komt naar voren dat de naam 'Managementrapportage' een verraderlijke term is die soms valse verwachtingen wekt. Sowieso wordt de huidige rapportage op verschillende manieren aangeduid:

Managementinformatie: titel pagina in Afsprakenstelsel, doel 'het gebruik van MedMij inzichtelijk te maken'
Beheerrapport: rapport dat deelnemers maandelijks aanleveren, basis voor ManagementInformatie. Formaat wordt voorgeschreven in Afsprakenstelsel.
Managementinformatieproces: Operationeel proces beschreven in Afsprakenstelsel dat aanlevering van Managementinformatie voorschrijft aan deelnemers, en verwerking hiervan tot een 'geaggregeerde rapportage' voorschrijft aan beheerorganisatie.
Managementrapportage: Aanduiding van deze 'geaggregeerde rapportage'.

In de Managementrapportage wordt nu data verzameld die enerzijds technisch van aard is: (netwerk)aanroepen worden geteld. Daarnaast leveren PGO's informatie over welk deel van hun populatie accounts MedMij toepast. Dit gegevens in deze categorie liggen dichtbij de 'hoeveel mensen' vragen, maar doordat:

mensen meerdere accounts in hetzelfde PGO kunnen aanmaken
én mensen meerdere PGO's naast elkaar kunnen gebruiken
én het lastig is vast te stellen of een verzamelsessie voor een gebruiker tot een bevredigend resultaat leidt (en dit niet gemeten/gerapporteerd wordt)

is ook met deze gegevens deze vragen lastig te beantwoorden.

Suggestie: Naam managementinformatie aanpassen naar Netwerkmanagementinformatie. Verwachtingen worden daarmee zuiverder.

Aanbeveling

Aanbeveling: Onderzoek doen naar mogelijkheden om de 'hoog over' vragen zinnig te beantwoorden met behulp van andere bronnen.

Aan de hand van de stappen in een MedMij uitwisseling is gekeken naar welke zaken meetbaar zijn en welke vragen wel/niet beantwoordbaar zijn op basis van deze gegevens (zie tabel op deze pagina). Punten die uit de discussie naar voren kwamen:

Suggestie: Het is mogelijk voor DVZA's om extra meetpunten toe te voegen voor meer inzicht in DigiD-inlog en toestemming stappen. De afweging moet daarvoor gemaakt worden of dit zoveel meer inzicht geeft dat dit de inspanning van het inbouwen, rapporteren en verwerken rechtvaardigt.

Mogelijk te meten stappen zijn:

of gebruiker (vanaf MedMij landingspagina) naar het DigiD inlogscherm is toegestuurd
of (enkel na succesvolle authenticatie/inlog) de beschikbaarheidstoets wel/niet is geslaagd (waarna toestemmingsscherm of redirect naar PGO volgt)
of de gebruiker heeft gekozen voor “annuleren” bij DigiD inlog en annuleringspagina krijgt

Aanbeveling

Aanbeveling: Meer nauwkeurige specificatie van met name 'fouttellingen' in Afsprakenstelsel, zodat rapportages over deelnemers heen eenduidiger worden. Met name fijnmaziger de meetmomenten aanduiden zodat data gebruikt kan worden voor analyse. Daarbij dient rekening te worden gehouden dat niet alle gebeurtenissen vastgesteld kunnen wordn op applicatieniveau t.b.v. rapportage (denk aan TLS foutmeldingen op netwerkniveau, bijvoorbeeld van partijen niet op de OCL).

Aanbeveling

Aanbeveling: Het MedMij-request-id kan gebruikt worden om nauwkeuriger te meten, doordat hiermee alle aanroepen binnen een (verzamel)sessie bij elkaar te groeperen zijn. In de sessie wordt een voorkeur uitgesproken om dit als een aparte indicator toe te voegen (aantal unieke request-id's per deelnemer en per deelnemer-gegevensdienst) en NIET als 'drilldown optie' .

Uitkomst: DVZA's kunnen unieke BSN's tellen en zo indicatie geven van aantal mensen dat gebruik heeft gemaakt van MedMij. Omdat mensen meerdere zorgaanbieders bevragen én zorgaanbieders via meerdere DVZA's aangesloten kunnen zijn, zal ook deze telling sowieso tot 'dubbeling' en een zeker niveau van afwijking leiden. Daarbij speelt de vraag of deze telling juridisch toegestaan is op basis van doelbinding moet dan wel onderzocht. Enkele deelnemers gaven ook aan vanuit een privacy-by-design uitgangspunt dit niet te willen inbouwen.

Uitkomst op dit moment is daarom dat deze telling niet toegevoegd moet gaan worden aan het Afsprakenstelsel.

Uitbreiding meetgegevens naar Zorgaanbieder-niveau

Vanuit diverse stakeholders is een behoefte naar voren te komen voor inzage in de uitwisselingen per Zorgaanbieder. In de discussie kwam naar voren dat dit technisch mogelijk is, de interface aanroepen bevatten deze informatie. Anderzijds is ook hier de discussie wat de meerwaarde is versus inspanning. Deelnemers zouden in plaats van op gegevensdienst-niveau op zorgaanbieder-gegevensdienst-niveau hun tellingen kunnen inrichten. Specificatie in het Afsprakenstelsel moet dan aangepast en ook de verdere verwerking bij de Beheerorganisatie.

Aanbeveling

Aanbeveling: Onderzoek hoe groot de impact van het toevoegen van het Zorgaanbieder-niveau aan rapportages is en voer een PoC uit om dit te beproeven.

stap	meetmogelijkheden	vragen	opmerkingen
gebruiker zoekt zorgaanbieder	Lastig te meten activiteit; PGO is vrij om user interface in te richten en hoe de gebruiker te helpen bij het vinden van haar zorgaanbieder. PGO kan aanvullende informatie over zorgaanbieders extern verwerven (denk aan Zorg-AB) om zoektocht te vergemakkelijken. Het zou kunnen zijn dat deze stap gebruikers al afschrikt voordat (meetbare) interactie start(!)	kunnen eindgebruikers hun zorgaanbieder vinden? is het (niet) kunnen vinden van een zorgaanbieder een reden tot afhaken?	vindbaarheid Zorgaanbieder blijft aandachtspunt voor Medmij
gebruiker start aanvraag	Geregistreerd met authorization request. Tussen authorization request en authorization response vinden bij DVZA groot aantal stappen plaats die (nog) niet gemeten worden: vaststellen of request van MedMij dvp afkomstig is die gekwalificeerd is voor gegevensdienst vaststellen of request een via deze DVZA aangesloten zorgaanbieder betreft vaststellen of scope correct is landingsscherm tonen; gebruiker kiest 'inloggen' 'uitstapje' gebruiker naar DigiD/TVS (interactie buiten zicht DVZA) DVZA stelt vast dat response DigiD correct is én BSN bevat DVZA voert beschikbaarheidstoets uit (optioneel, mag ook op later moment) Gebruiker geeft toestemming voor uitwisseling; DVZA logt toestemming DVZA voert redirect uit naar PGO. Voor elk van deze stappen zou een DVZA een 'teller' kunnen laten lopen. De huidige telling is gebaseerd op het combineren van stappen 1, 2 en 3, waarna een DVZA correcte en incorrecte verzoeken telt.	hoeveel gebruikers stoppen bij/loggen in via DigiD? hoeveel gebruikers geven wel/geen toestemming?	In rapportages van laatste twee maanden is te zien dat uitval tussen authorization request en token request zo'n 5% is. Digid (b)lijkt daarmee niet de grootste hobbel?
gebruiker start aanvraag	10. PGO vraagt token aan 11. DVZA ontvangt token request 12. DVZA valideert token request 13. DVZA geeft token uit 14. PGO ontvangt token		Is indicator verhouding aantal authorization requests succesvol én token requests succesvol zinnig instrument?
overstap van aanvragen aan Authorization Server naar aanvragen aan Resource Server (daadwerkelijke uitwisseling gegevens)
	DVP vraag 'blokje informatie' (FHIR request) DVZA ontvangt FHIR request DVZA valideert request DVZA vraag informatie op uit xIS DVZA stuurt FHIR response PGO ontvangt 'blokje informatie' (of fout) Proces wordt herhaald (stap 1) of beëindigt door DVP wanneer alle 'blokjes informatie' zijn opgevraagd	Hoeveel mensen halen succesvol gegevens op? BPM vraag	Doordat veel gegevensdiensten/informatiestandaarden uit meerdere 'blokjes informatie' bestaan, is het lastig vast te stellen wanneer een uitwisseling voor een gebruiker succesvol is. Het kan zijn dat een verzamelsessie leidt tot meerdere succesvolle en onsuccesvolle uitwisselingen van 'blokjes'; het is dan niet vast te stellen of dit op UX niveau als succesvol/niet succesvol telt.

Presentatie Expertsessie: Expertsessie.Rapportage ontwikkelingen en behoeften.pdf

Browser not supported