Om te bepalen welke informatie gelogd moet worden zijn een aantal usecases geïdentificeerd. Hieronder worden deze usecases weergegeven.

1. Unhappy flows bij Authorization interface DVP → DVA

Bij verschillende DVA's wordt na het tonen van de eerste voorgeschreven landingspagina een tweede landingspagina getoond . Ook rondom het tonen van deze tweede landingspagina kunnen er zich fouten voor doen. Echter wordt deze tweede pagina niet genoemd in het afsprakenstelsel.

Omdat deze pagina niet voorkomt in het MedMij Afsprakenstelsel voor komt zou deze niet moeten bestaan, daarom is er geen alternative flow voor gemaakt.

2. Alternative flows bij Authorization interface DVA → DigiD (DVAuthN)

1. De 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)
  → dit kunnen wij niet weten, alleen dat de digiD flow wordt gestart
2. De gebruiker gebruikt desktop of laptop en klikt op digid app staat op mobiel apparaat (die kunnen wij niet weten, alleen dat de digiD flow wordt gestart)
3. DigiD app wordt getoond, persoon kiest voor inloggen bij DigiD, maar krijgt een 404 (die kunnen wij niet weten, alleen dat de digiD flow wordt gestart)
4. De DVA onvangt een negatief resultaat op het authentificatie proces (400). DigiD app wordt getoond, maar persoon kiest voor annuleren door op ‘annuleren’ te klikken (die kunnen wij niet weten, alleen dat de digiD flow wordt gestart)
5. DigiD 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 digi-app te upgraden naar substantieel.)
6. DigiD 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.)
7. Persoon is geauthenticeerd door DigiD en kan gaan inloggen maar annuleert (pagina van DVA) (4a (annuleringspagina: nieuw) → 4 of 12, 13) (bijvoorbeeld omdat de gebruiker de organisatie die de digid aansluiting heeft (DVA) wordt getoond die de gebruiker niet herkent.
8. Persoon is geauthenticeerd door DigiD, maar krijgt melding dat de DVA niet beschikbaar is (5,6,7, optioneel: 8,9)(kunnen we niet meten)
9. Persoon is geauthenticeerd door DigiD, maar NoAuthnContext (Niet voldaan aan betrouwbaarheidsniveau) (is een variant op E)
10. Persoon is geauthenticeerd door DigiD, maar RequestDenied (Verzoek geweigerd door DigiD bijvoorbeeld door TimeOut) (is een variant op E)
11. Persoon is geauthenticeerd door DigiD, maar krijgt melding 500 (afgewezen) of 1005 melding

3. Alternative flows bij Authorization interface DVA → Vroege beschikbaarheidstoets

Gebruiker heeft gisteren zijn gegevens opgehaald, maar de GGZ instelling heeft na het behalen van VIPP doelstelling, vinkje 'uitgezet' en de gegevens zijn opeens niet meer ophaalbaar.(moet uit de analyse volgen)

4. Alternative flows bij Authorization interface DVA → Toestemmingsverklaring

1. Toestemmingspagina is in algemeen een rare pagina, voor de gebruiker. De gebruiker denkt: Ik heb toch al toestemming gegeven?
2. Toestemmingsverklaring wordt getoond, persoon is geauthenticeerd door DigiD, maar wacht langer dan 1 minuut met inloggen. (Dit staat nergens in AS?)
3. Toestemmingsverklaring wordt getoond, maar Persoon verleent geen toestemming door de browser te sluiten.
4. Toestemmingsverklaring wordt getoond, maar Persoon verleent geen toestemming door de tab te sluiten.
5. Toestemmingsverklaring wordt gegeven maar Persoon navigeert terug naar de MedXpert App (en dan stopt op de achtergrond de authorisatie flow. ) (is analyse)
6. Gebruiker krijgt een whatsappje, en de gebruiker doet even wat anders door daar op te klikken, dan kan hij niet verder. Dat is vooral vervelend bij het ophalen van gegevens, omdat vooral dat lang kan duren, dan ben je de hele sessie kwijt. (kunnen we niet loggen

5. Alternative flows Token interface

PGO verstuurt meerdere token requests en krijgt meerdere tokenresponses terug van DVA. (kan alleen als er 1 positief is, en de rest negatief. loggen aan beide kanten)

6. Alternative flows Resource request

PGO krijgt 403 als patient of PGO niet geauthorizeerd is om zib te leveren (400-derds is fout van de aanroepen.) (beide partijen loggen)

7. Oorspronkelijke tekst

Unhappy flows bij Authorization interface DVP → DVA
1. ~~De tweede landingspagina DVA wordt getoond, maar de Persoon klikt op annuleren~~ (want staat niet in het afsprakenstelsel dus schrijven we niets over op)
2. ~~De tweede landingspagina DVA wordt getoond maar persoon sluit de browser of tabblad~~ (want staat niet in het afsprakenstelsel dus schrijven we niets over op)
Unhappy flows bij Authorization interface DVA→ DigiD (=DVAuthN)
1. ~~De gebruiker klikt op digid app, maar heeft deze nog niet geinstalleerd en haakt af bij het installeren en activeren van de app (opent in nieuw venster)~~ (die kunnen wij niet weten, alleen dat de digiD flow wordt gestart)
2. ~~De gebruiker gebruikt desktop of laptop en klikt op digid app staat op mobiel apparaat~~ (die kunnen wij niet weten, alleen dat de digiD flow wordt gestart)
3. ~~DigiD app wordt getoond, persoon kiest voor inloggen bij DigiD, maar krijgt een 404~~ (die kunnen wij niet weten, alleen dat de digiD flow wordt gestart)
4. De DVA onvangt een negatief resultaat op het authentificatie proces (400). ~~DigiD app wordt getoond, maar persoon kiest voor annuleren door op ‘annuleren’ te klikken (die kunnen wij niet weten, alleen dat de digiD flow wordt gestart)~~
5. DigiD 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 digi-app te upgraden naar substantieel.)
6. ~~DigiD 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.)~~
7. Persoon is geauthenticeerd door DigiD en kan gaan inloggen maar annuleert (pagina van DVA) (4a (annuleringspagina: nieuw) → 4 of 12, 13) (bijvoorbeeld omdat de gebruiker de organisatie die de digid aansluiting heeft (DVA) wordt getoond die de gebruiker niet herkent.
8. ~~Persoon is geauthenticeerd door DigiD, maar krijgt melding dat de DVA niet beschikbaar is (5,6,7, optioneel: 8,9)~~(kunnen we niet meten)
9. ~~Persoon is geauthenticeerd door DigiD, maar NoAuthnContext (Niet voldaan aan betrouwbaarheidsniveau)~~ (is een variant op E)
10. ~~Persoon is geauthenticeerd door DigiD, maar RequestDenied (Verzoek geweigerd door DigiD bijvoorbeeld door TimeOut)~~ (is een variant op E)
11. Persoon is geauthenticeerd door DigiD, maar krijgt melding 500 (afgewezen) of 1005 melding
Unhappy flows bij Authorization interface DVA → Vroege beschikbaarheidstoets (NB het is onduidelijk hoe te bepalen of we bij deelnemer de beschikbaarheidstoets missen of dat die de late variant gebruikt.)
1. ~~Gebruiker heeft gisteren zijn gegevens opgehaald, maar de GGZ instelling heeft na het behalen van VIPP doelstelling, vinkje 'uitgezet' en de gegevens zijn opeens niet meer ophaalbaar.~~(moet uit de analyse volgen)
Unhappy flows bij Authorization interface DVA → Toestemmingsverklaring
1. ~~Toestemmingspagina is in algemeen een rare pagina, voor de gebruiker. De gebruiker denkt: Ik heb toch al toestemming gegeven?~~
2. ~~Toestemmingsverklaring wordt getoond, persoon is geauthenticeerd door DigiD, maar wacht langer dan 1 minuut met inloggen.~~ (Dit staat nergens in AS?)
3. ~~Toestemmingsverklaring wordt getoond, maar Persoon verleent geen toestemming door de browser te sluiten.~~
4. ~~Toestemmingsverklaring wordt getoond, maar Persoon verleent geen toestemming door de tab te sluiten.~~
5. ~~Toestemmingsverklaring wordt gegeven maar Persoon navigeert terug naar de MedXpert App (en dan stopt op de achtergrond de authorisatie flow. ) (~~is analyse)
6. Gebruiker krijgt een whatsappje, en de gebruiker doet even wat anders door daar op te klikken, dan kan hij niet verder. Dat is vooral vervelend bij het ophalen van gegevens, omdat vooral dat lang kan duren, dan ben je de hele sessie kwijt. (kunnen we niet loggen)
Unhappy flows Token interface
1. PGO verstuurt meerdere token requests en krijgt meerdere tokenresponses terug van DVA. (kan alleen als er 1 positief is, en de rest negatief. loggen aan beide kanten)
Unhappy flows Resource request
1. PGO krijgt 403 als patient of PGO niet geauthorizeerd is om zib te leveren (400-derds is fout van de aanroepen.) (beide partijen loggen)

Je kunt met 1 telefoon, via sms (midden) voor meerdere digids gegevens opvragen.

Identifiers zouden helpen dat je niet opnieuw weer alle pdfs hoeft op te halen.

Bij DELEN is ontvankelijkheidstoets (Beschikbaarheidstoets) vroeg verplicht.

Waarom krijg ik bij een epic ziekenhuis wel labwaarden en bij hix ziekenhuis? Waarom krijgen we soms sommige zibs wel en soms niet?

Browser not supported