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 deze wijziging 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(!) |
|
|
| 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:
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. |
|
|
10. PGO vraagt token aan 11. DVZA ontvangt token request 12. DVZA valideert token request 13. DVZA geeft token uit 14. PGO ontvangt token |
| ||
| overstap van aanvragen aan Authorization Server naar aanvragen aan Resource Server (daadwerkelijke uitwisseling gegevens) | |||
|
|
| |
Presentatie Expertsessie: Expertsessie.Rapportage ontwikkelingen en behoeften.pdf-