A t/m I

Ophalen lijsten

DVP- MedMij Stelselnode en andersom

DVA- MedMij Stelselnode en andersom

De DVP vraagt de ZAL (Aanbiederslijst), GNL (Gegevensdienstnamenlijst) of WHL (Whitelist) op, en de MedMij Stelselnode stuurt deze terug

De DVA vraag de GNL, WHL of OCL (OAuth Client List) op en de MedMij Stelselnode stuurt deze terug.

1

Authorization Request verstuurd

User Agent naar DVA

De User Agent verstuurt een authorization request naar de Authorization Server van de DVA. Het adres van het authorization endpoint komt uit de ZAL.  Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten.

2

Authorization Request ontvangen

User Agent naar DVA

De Authorization server van de DVA ontvangt het Authorization request.

3

Tonen MedMij Landingspagina 

DVA naar User agent

De Authorization server van de DVA heeft het Authorization request ontvangen. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren en presenteert de landingspagina.

• Betekent dit dat de DVA Authorization server een Sessie ID creëert per gebruiker?

4

Redirection naar Authentication server

User Agent naar DigiD

Dan start de Authorization Server van de DVA (nu in de rol van Authentication Client) de authenticatieflow door de User Agent naar de Authentication Server te redirecten. Dit gebeurt onder meegeven van een redirect_uri, die aangeeft waarnaartoe de Authentication Server straks de User Agent moet terugsturen, na het inloggen van de Persoon.

Redirection naar Inlogpagina

DigiD naar User Agent

Inloggen

User Agent naar DigiD

De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.

Redirection naar Authorization server (SAML artifact)

DigiD naar User Agent 

Wanneer de inloggegevens juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs.

Wanneer het inloggen is afgebroken geeft de Authorization Server de Persoon alsnog de mogelijkheid via zijn User Agent in te loggen.

Klopt het dat de redirection van DigiD naar de DVA verloopt via de User Agent?

5

Ga naar redirect_uri DVA (SAML artifact)

User Agent naar DVA

Gebeurt een eventuele nieuwe inlogpoging onder dezelfde Sessie ID van de DVA Authorization server?

6

Artifact resolution (SAML artifact)

DVA naar DigiD

Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.

7

Artifact response (SAML assertion)

DigiD naar DVA

Verzonden Authorization response van DigiD naar DVA

8

Vroege beschikbaarheidstoets opgevraagd

DVA naar DVA

Bij een vroege beschikbaarheidstoets wordt voorafgaand aan het resource request gecontroleerd of er Gegevensdienst voor uitwisseling beschikbaar is. Hierbij wordt het opvragen van de beschikbaarheid gelogd.

9

Vroege beschikbaarheidstoets antwoord

DVA naar DVA

De ontvangst van het antwoord wordt ook gelogd.

10

Tonen Toestemmingspagina

DVA naar User Agent

Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst, of wanneer géén gebruik wordt gemaakt van dit vroegste moment van de beschikbaarheidstoets, dan presenteert de Authorization Server via de User Agent aan Persoon in een Toestemmingsverklaring, de vraag of Persoon de Aanbieder toestaat de gevraagde persoonlijke gezondheidsinformatie aan de DVP Server (als OAuth Client) te sturen.

Indien op dit moment al bekend is dat een bepaalde Gegevensdienst niet beschikbaar is voor de Persoon, dan mag deze niet worden opgenomen in de Toestemmingsverklaring.

11

Toestemming geven

User Agent naar DVA

Toestemming wel/niet ontvangen.

12

Redirection naar DVP server (Authorization response, OAuth authorization code)

DVA naar User agent

Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een User Agent redirect met de in het authorization request ontvangen redirect_uri, naar de DVP Server.

De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de DVP Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren.

De DVP Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de toestemming is gegeven en logt het verkrijgen van het ophaalbewijs.

13

Ga naar redirect URI DVA (SAML-artifact)

User agent naar DVP

14

Token request sent

DVP naar DVA

Met dit ophaalbewijs wendt de DVP Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de User Agent, voor een access token.

15

Token request received

DVP naar DVA

Acces token request ontvangen.

16

Token response sent

DVA naar DVP

Daarop genereert de Authorization Server een access token en stuurt deze naar de DVP Server.

17

Token response received

DVA naar DVP

DVA token response ontvangen.

18

Resource request sent

DVP naar DVA

Nu is de DVP Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen, nadat hij de Persoon eventueel nog nadere keuzes heeft laten maken.

Het adres van de juiste resource endpoints haalt hij uit de Aanbiederslijst. Hij plaatst telkens het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.

19

Resource request received

DVP naar DVA

DVA heeft het resource request van DVP ontvangen. De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op.

20

Late beschikbaarheidstoets verstuurd

DVA naar DVA

DVA beschikbaarheidsverzoek verstuurd

21

Late beschikbaarheidstoets ontvangen

DVA naar DVA

DVA beschikbaarheidsverzoek antwoord is ontvangen.

De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op. Dan breekt het uiterste moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft.

22

Verzamelen gegevens verzonden

DVA naar DVA

23

Verzamelen gegevens ontvangen

DVA naar DVA

Is de Gegevensdienst beschikbaar, dan verstuurt de Resource Server deze ze in een resource response naar de DVP Server.

24

Resource response sent

DVA naar DVP

25

Resource response received

DVA naar DVP

DVP Resource Response ontvangen. De DVP Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. De DVP Server bevraagt de Resource Server daarna mogelijk opnieuw, eventueel na nieuwe interactie met de Persoon. Zolang het access token geldig is, kan dat.

InterfaceversieID

De identifier van de interfaceversie. String van minimaal één en maximaal 30 tekens.

Interfaces zijn geversioneerd: verschillende versies van interfaces kunnen tegelijkertijd op het MedMij-netwerk worden aangeboden. Daarom is er de klasse Interfaceversie in het modelgebied Changes. Alle endpoints in de Zorgaanbiederslijst en Oauth Client List (zie onder) horen bij één Interfaceversie.

Zie Metamodel

Dit is belangrijk voor foutopsporing. Want een versie verschil kan verstoringen in de gegevensuitwisseling tussen deelnemers veroorzaken.

Alle

Versie van de opgehaalde lijsten (ZAL, OCL, WHL, GNL) 

De versie van de lijsten die een deelnemer ophaalt bij de MedMij Stelselnode

Zie boven

A t/m I

Type en versie PGO 

Webapp of app en het OS gelogd te worden

Foutopsporing. Fouten komen soms alleen in de webinterface voor. Of niet in de app van Apple, maar wel in de app van Android

Voorstel: Alle logmomenten van de DVP of User Agent. Dit zijn:

1,4, 13,14,17,18,25?

Moet ook de gebruikte browser gelogd worden door de PGO-gebruiker bij Webapp?

Naam en gebruikte versie van de DVA 

Naam van de DVA applicatie en de gebruikte versie

Foutopsporing

Voorstel: Alle logmomenten van de DVA Agent. Dit zijn:

2,3, 5 t/m 7, 10 t/m 12, 15, 16, 19 t/m 24

Naam en gebruikte versie van bronsysteem van de Zorgaanbieder

Naam van bronsysteem die de Zorgaanbieder gebruikt en de gebruikte versie

Foutopsporing

Voorstel: Alle mogelijke momenten van gegevensuitwisseling tussen DVA en bronsysteem Zorgaanbieder.

Dit zijn: 8,9 20 t/m 23

Kan dit? Of moet eerst de Zorgaanbieder deelnemer zijn in het afsprakenstelsel?

Trace ID

voor gegevensuitwisseling in de MedMij-keten voor Verzamelen of Delen

Een Trace-ID is een uniek ID om de gegevensuitwisselingen over alle schakels in de MedMij keten te kunnen volgen, van Authorization Request (1) naar de uiteindelijke Resource response(s) (19)

De DVP stuurt een Trace-ID mee bij het versturen van het verzoek voor het verzamelen of delen van gegevens naar een DVA. Dit Trace-ID wordt door alle schakels in de MedMij-keten vervolgens opgenomen in de logging van de gegevensuitwisselingen die volgen op het verzoek van de DVP.

Een Trace ID in de logging is belangrijk om de kwaliteit van de gegevensuitwisseling in de gehele MedMij keten te kunnen bepalen. Zoals het aantal succesvolle en niet succesvolle opvragingen in de gehele MedMij keten.

Daarnaast voor foutopsporing wanneer melding wordt gedaan van verstoringen.

1 t/m 25

Trace ID

voor het ophalen van lijsten door deelnemers bij de MedMij Stelselnode

Er wordt ook een Trace-ID meegestuurd vanuit de DVP en DVA naar de MedMij StelselNode bij het ophalen van de lijsten (ZAL, WHL, etc). Dit Trace-ID wordt door de MedMij-Stelselnode vervolgens ook opgenomen in de logging, in de opvolgende transacties.

Zie boven

A t/m I

Authorization request ID

Identifer van de authorization request. Dt is het huidige MedMij-request-ID, zie link naar betreffend onderdeel in Afsprakenstelsel. Met dit ID kan de gegevensuitwisseling na de authorization request tot de authorization response gevolgd worden over de schakels.

• Dit is belangrijk voor het bepalen van het aantal succesvolle en onsuccesvolle authorization responses op een authorization request (kwaliteit van gegevensuitwisseling)

• En voor foutopsporing bij deze gegevensuitwisseling

1 t/m 13?

Token request ID

Identifer van de token request. Met dit ID kan de gegevensuitwisseling na de token request tot de token response gevolgd worden over de schakels.

• Dit is belangrijk voor het bepalen van het aantal succesvolle en onsuccesvolle token responses op een token request (kwaliteit van gegevensuitwisseling)

• En voor foutopsporing bij deze gegevensuitwisseling

14 t/m 16

Zie boven

Resource request ID

Identifer van de resource request. Met dit ID kan de gegevensuitwisseling na de resource request tot de resource response gevolgd worden over de schakels.

• Dit is belangrijk voor het bepalen van het aantal succesvolle en onsuccesvolle resource responses op een  resource request (kwaliteit van gegevensuitwisseling)

• En voor foutopsporing bij deze gegevensuitwisseling

18 t/m 25?

Er is een al een MedMij-request-ID beschikbaar, die gelogd wordt door een DVA bij het verzenden en ontvangen van resource requests zie link naar betreffend onderdeel in Afsprakenstelsel.

Deze informatie is nu opgehaald over de het MedMij-request-ID. 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). 

Event DateTime

Datum en tijdstip van het verzenden of ontvangen van het bericht. Gewenst is dat deelnemers een datum en tijdstip vast leggen tot op de milliseconde. 

Het afsprakenstelsel schrijft het volgende voor over synchronisatie van de gebruikte klok, zie [1]

"De klokken van IT componenten die communiceren via MedMij en logging in het kader van MedMij bijhouden, MOETEN worden gesynchroniseerd met pool.ntp.org. Het is toegestaan te synchroniseren met een alternatieve NTP-server, wanneer maatregelen zijn getroffen om de afwijking met pool.ntp.org niet groter dan plus of min 500 ms te laten zijn."

Event_DateTime van de gegevensuitwisselingen zijn nodig om de doorlooptijden van een transactie te meten. 

Een grote doorlooptijd kan wijzen op een verstoring of een (poging tot) hacking.

Alle

Niet alle deelnemers leggen de timestamp vast volgens dezelfde klok.

Deelnemer ID

De gebruikte identifier van de deelnemer (DVP of DVA) binnen het MedMij afsprakenstelsel.

Dit is een string van minimaal één en maximaal 30 tekens, zie Metamodel

Het deelnemer ID is nodig om de kwaliteit en trends in gegevensuitwisseling per deelnemer of per combinatie van deelnemers te kunnen bepalen.

Daarnaast voor foutopsporing. Tenslotte voor het testen van de bereikbaarheid per deelnemer

Alle

Dit is het koppelvlak richting CMS systeem van allsolutions. Zorgen dat we daar hetzelfde ID hebben

Deelnemer FQDN

De fully-qualified domain name van een deelnemer  conform RFC3696, sectie 2. Zie ook Logische modellen

Zie boven

Alle

Zorgaanbieder ID

De gebruikte identifier van een Zorgaanbieder binnen het MedMij afsprakenstelsel.

Zie deelnemer ID

1 t/m 25?

Dit is een belangrijk koppelvlak richting de R&A bron

Zorgaanbieder FQDN

De fully-qualified domain name van een Zorgaanbieder

Zie boven.

1 t/m 25?

Lijst ID

Identifier van een lijst (ZAL, WHL, OCL, GNL)

Het lijst ID is nodig om de kwaliteit en trends in gegevensuitwisseling per lijst te kunnen bepalen. Daarnaast voor foutopsporing

A t/m I

Lijst FQDN

De fully-qualified domain name van de lijsten   (ZAL, WHL, OCL, GNL)

 Zie boven

A t/m I

Is Lijst FQDN de juiste term?

Sessie ID

Een Sessie ID knoopt meerdere handelingen van één persoon bij dezelfde applicatie aan elkaar. Bijvoorbeeld meerdere resource requests bij de DVP. Of meerdere pogingen tot inloggen bij de Authorization Server van de DVA

Een sessie ID kan helpen bij foutopsporing. Bijvoorbeeld om te bepalen of een hoge frequentie van foutmeldingen veroorzaakt wordt door dezelfde gebruiker of verschillende gebruikers

1,4, 18,19?

Gepseudonimiseerd user- ID?

Dit betreft een random nummer wat toegekend wordt door een deelnemer aan een gebruiker. Dit nummer heeft geen correlatie met het BSN en betreft een niet-traceerbaar-ID. Maar met dit nummer is wel te achterhalen of dezelfde gebruiker een actie uitvoert bij een deelnemer of een andere gebruiker

Momenteel maken DVP's gebruik van een User-ID. Dit zorgt ervoor dat zij meerdere gestarte sessies van gebruikers binnen een paar milliseconden van elkaar kunnen onderscheiden.

Met name om te zien of het gebruikers terugkeren of eenmalig het PGO gebruiken. Inzicht in of het de gebruiker uiteindelijk lukt om gegevens op te halen (ondanks mogelijk meerdere verschillende verzoeken)

Aantal unieke gebruikers over tijd

Is dit nodig, als er ook een sessie-ID wordt vastgelegd?

Nog te bespreken of dit wel wenselijk is vanuit privacy oogpunt

Gegevensdienst ID

Identifier van de gegevensdienst(en) die onderdeel zijn van de gegevensuitwisseling. He ID geeft aan welke gegevensdienst het is en welke versie.

• Dit is belangrijk voor het bepalen van de kwaliteit van de gegevensuitwisseling per gegevensdienst.

• Daarnaast voor foutopsporing: Komen bepaalde verstoringen alleen voor bij specifieke gegevensdiensten?

• Verder voor managementrapportages: inzicht in toe- of afname van de gebruikte gegevensdiensten.

1 t/m 25?

Resource ID

Identifier van de verstuurde of ontvangen resources. De identifier geeft het type resource aan.

18 t/m 25?

De omvang van het bericht

Grootte van het bericht (aantal bits)

• Voor foutopsporing: de grootte van het bericht kan een oorzaak zijn van een verstoring.

• Opsporing van mogelijke hacking-poging: extreme grote of kleine berichten kunnen duiden op een poging tot hacking.

Alle?

Soort bericht

Twee soorten berichten van deelnemers worden onderscheiden. Berichten waarin de logging van events staan en berichten met het resultaat van een ping op bereikbaarheid, zie hoofdstuk 6.

Alle?

Resultaat (Succes of Foutcodes)

Bij de verschillende gegevensuitwisselingen in de MedMij keten (de authorization request en response, token request en response en resource requests en response) kunnen er fouten optreden Gewenst is om foutcodes voor een aantal veelvoorkomende fouten te delen in de logging van de deelnemers. 

Foutopsporing

Alle, de mogelijke foutcodes verschillen echter per gegevensuitwisseling

Nog te bepalen welke foutcodes per type gegevensuitwisseling (de authorization request en response, token request en response en resource requests en response gedeeld moeten worden in de logging. De foutcodes volgens OAuth 2.0 staan uitgewerkt in MO-39 Duiding van errors. Zie daarnaast hoofstuk 6

Status langdurige toestemming

Dit is voor de toekomst. De status van langdurige toestemming die een PGO-gebruiker heeft gegeven per Zorgaanbieder per gegevensdienst. De status kan zijn: Geen toestemming of wel toestemming.

Te bespreken met Casper: kan hierover al iets opgenomen worden in de loggegevens?

Aanvullingen?

Aantal succesvolle en niet succesvolle opvragingen

Aantal succesvolle en niet succesvolle opvragingen binnen een bepaald tijdsbestek, die leiden tot:

• een volledig succesvolle ophaling  (alle gevraagde resources/gegevens zijn succesvol in de PGO verzameld)

• deels succesvolle ophaling (een deel van de gevraagde resources/gegevens zijn succesvol in de PGO verzameld)

• of onsuccesvol (geen van de resources/gegevens  zijn succesvol in de PGO verzameld)

1 - Authorization request

25-Resource response

ID gegevensdiensten

Type (ID) opgevraagde resources    

Type (ID) ontvangen resources  

Resultaat (succes, of foutcode)

Succesvol en onsuccesvol in percentages en absolute aantallen:

• per DVP

• per DVA

• per Zorgaanbieder

• per gegevensdienst

• per type resource (gegeven)

• DVP & DVA combinatie

• DVA & Zorgaanbieder combinatie

Daarnaast per combinatie van variabelen. Bijvoorbeeld aantal succesvolle opvragingen voor alle gegevensdiensten voor deze combinatie van DVP en DVA

Er is nu onvoldoende inzicht in de kwaliteit van de gegevensuitwisseling in de gehele MedMij keten, zie knelpunt A hfdst 2 uit het Vooronderzoek

Voor inzicht in de kwaliteit van de keten is inzicht in het resultaat van de totale aantal opvragingen in de gehele MedMij keten gewenst. 

Aantal succesvolle  en onsuccesvolle Authorization requests van DVP naar DVA

Aantal succesvolle en niet succesvolle authorization requests binnen een bepaald tijdsbestek van DVP naar DVA

1 - Authorization request

13 - Authorization response

Sessie ID

Resultaat (succes, of foutcode)

Succesvol en onsuccesvol in percentages en absolute aantallen:

• per DVP

• per DVA

en combinaties hiervan

Daarnaast is voor de onsuccesvolle authorization requests waarschijnlijk een onderverdeling naar foutcode gewenst (verder te bepalen) zoals:

• afgebroken door gebruiker

• foutmelding x DVA

• foutmelding y DVA

• ...

Voor inzicht in de kwaliteit van de keten is inzicht in de gegevensuitwisseling per interface zoals de Authorization interface gewenst, zie ook doel bij Geslaagde aantal opvragingen

Daarnaast voor inzage in eventuele verstoringen bij deelnemers bij de Authorization interface, zie ook knelpunt C in hfdst 2 uit het Vooronderzoek. En voor het sneller kunnen achterhalen van de bron en oorzaak van een verstoring, zie ook knelpunt D in hfdst 2 uit het Vooronderzoek.

Aantal succesvolle  en onsuccesvolle DigiD authenticatie

Aantal succesvolle  en onsuccesvolle DigiD authenticaties binnen een bepaald tijdsbestek 

4,5,6,7?

Sessie ID

Resultaat (succes, of foutcode). Bijvoorbeeld

SAML-Assertion: Succes, Authnfailed, NoAuthncontext, RequestDenied, evt. Abandoned

Resultaten SAML

• Per DVA

• DVA overall

Daarnaast is voor de onsuccesvolle authenticaties waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals:

• afgebroken door gebruiker

• gebruiker heeft verkeerd ww ingevuld

• DVA ontvangt technische foutmelding DigiD

• ...

Zie doelen 'Geslaagde Authorization requests DVP naar DVA' 

Inzicht krijgen in de authenticatie per DVA en overall om te achterhalen of alleen een specifieke DVA een verstoring ervaart bij de DigiD-authenticatie. Of dat de verstoring ligt bij DigiD en alle DVA's een verstoring ervaren.

Aantal succesvolle  en onsuccesvolle Token requests

Aantal succesvolle en onsuccesvolle DigiD token requests binnen een bepaald tijdsbestek 

14 t/m 17

Gegevensdienst ID

Sessie ID

Resultaat (succes, of foutcode).

Succesvol en onsuccesvol in percentages en absolute aantallen:

• per DVP

• per DVA

• per gegevensdienst

• En combinaties hiervan

Daarnaast is voor de onsuccesvolle Token requests waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals:

• afgebroken door gebruiker

• foutmelding x

• foutmelding y

• ...

Zie doelen 'Geslaagde Authorization requests DVP naar DVA' 

Aantal succesvolle en onsuccesvolle Resource requests DVA-DVP

Aantal succesvolle en onsuccesvolle Resource requests van DVA-DVP binnen een bepaald tijdsbestek 

13 - 14,

17-18

Gegevensdienst ID

Resource ID

Sessie ID

Resultaat (succes, of foutcode).

Succesvol en onsuccesvol in percentages en absolute aantallen:

• per DVP

• per DVA

• per Zorgaanbieder

• per gegevensdienst

• per resource

• DVP & DVA combinatie

• DVA & Zorgaanbieder

En combinaties hiervan

Daarnaast is voor de onsuccesvolle Resource requests waarschijnlijk een onderverdeling naar oorzaak/foutcode gewenst (verder te bepalen) zoals:

• afgebroken door gebruiker

• foutmelding x

• foutmelding y

• ...

Zie doelen 'Geslaagde Authorization requests DVP naar DVA' 

Aantal succesvolle en onsuccesvolle Resource requests XIS-DVA

Aantal succesvolle en onsuccesvolle Resource requests van XIS-DVA binnen een bepaald tijdsbestek 

15, 16

Gegevensdienst ID

Resource ID

Sessie ID

Resultaat (succes, of foutcode).

Zie 'Aantal succesvolle en onsuccesvolle Resource requests DVA-DVP'

Zie doelen 'Geslaagde Authorization requests DVP naar DVA' 

Doorlooptijden van de start van een opvraging in een PGO en ontvangst van het antwoord in de PGO

1 en 14

Gemiddeld, minimum en maximum doorlooptijd

• voor alle DVP's

• per DVP's

• per gegevensdienst,

• voor alle gegevensdiensten

• per type resource

• voor alle typen resources

• per DVA

• voor alle DVA's

• per Zorgaanbieder

• voor alle Zorgaanbieders

• voor DVA's en Zorgaanbieder combinaties

• voor combinaties van DVA's met gegevensdiensten

• voor combinaties van DVA's met type resources

Er is nu geen inzage in  reactietijden van de schakels in de MedMij keten, zie knelpunt E hfdst 2 uit het Vooronderzoek. Dit is wel gewenst.

Doorlooptijden per interface

Aantal verstoringen per interface en de duur van de verstoring

Nog verder te bepalen

Na constatering verstoring: prioritering van de verstoring

Oplostijden per verstoring

Nog verder te bepalen

• Exacte tijdstip van de start van de verstoring. 

• Welke schakel(s) in de keten de bron zijn van de verstoring.

Voor prioritering van de verstoring:

• Aantal transacties die mis gaan door verstoring 

• Aantal schakels in de keten die last hebben van de verstoring

Welke schakel(s) in de keten de bron zijn van de verstoring

Signaleren van veiligheids-risico's

Toename/afname gegevensuitwisselingen in de gehele MedMij Keten

Toename/afname gegevensuitwisselingen per interface

HTTP 400 (Bad Request)

^{invalid_request}

^{invalid_client}

^{invalid_grant}

^{unauthorized_client}

^{access_denied}

^{unsupported_response_type}

^{invalid_scope}

HTTP 404 (Not Found) 

HTTP 400 (Bad Request)

^{invalid_request}

^{invalid_client}

^{invalid_grant}

^{unauthorized_client}

HTTP 401 (Unauthorized)

HTTP 400 (Bad Request)

^{invalid_request}

HTTP 401 

invalid_token

HTTP 403

insufficient_scope

access_denied

urn:oasis:names:tc:SAML:2.0:status:AuthnFailed

Wanneer de eindgebruiker het inloggen annuleert.
Wanneer de eindgebruiker niet de juiste sector heeft.

urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext

Wanneer de eindgebruiker niet kan voldoen aan het gevraagde betrouwbaarheidsniveau.

urn:oasis:names:tc:SAML:2.0:status:PartialLogout

Wanneer de eindgebruiker niet uitgelogd kan worden bij alle dienstaanbieders (Bijv. als een dienstaanbieder niet reageert).

urn:oasis:names:tc:SAML:2.0:status:RequestDenied

Een SAML-responder die weigert een berichtuitwisseling met de SAML-aanvrager uit te voeren moet een reactie bericht geven met een deze foutcode.

Nr

Randvoorwaarde

Toelichting

Wordt aan deze randvoorwaarde voldaan?

Dit wordt gecheckt nadat hfst 3 en 4 zijn uitgewerkt met Geranne, Jacqueline, kernteam, etc.

1.

Er worden geen persoonsgegevens gedeeld alleen transactiegegevens.

Voor ketenmonitoring zijn transactiegegevens voldoende.

Vanuit de DVP's en DVA's wordt verder het aantal unieke accounts aangeleverd voor de managementrapportages. Het precieze aantal unieke PGO-gebruikers per Zorgaanbieder in Nederland kan met deze aangeleverde indicator door DVP's en DVA's niet berekend worden. Aangegeven is door management en adviseurs (zie vooronderzoek) dat trendinformatie voldoende is om inzicht te hebben in verslechtering of verbetering en te kunnen sturen. Het exacte aantal PGO-gebruikers in Nederland is niet nodig.

2.      

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

3.       

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.

4.        

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.  

5.        

Er wordt zorgvuldig omgegaan met loggevens die misbruikt kunnen worden door hackers. Vanuit het oogpunt van informatieveiligheid.

Aanvullingen?