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. 

Geinitieerd vanuit useragent en dus ontbetrouwbaar. De stap voor 1 is belangrijker omdat we juist de 'betrouwbare' DVP en DVA willen gebruiken. Dit geldt ook voor stap 4

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.

Geinitieerd vanuit useragent en dus ontbetrouwbaar. De stap voor 1 is belangrijker omdat we juist de 'betrouwbare' DVP en DVA willen gebruiken. Dit geldt ook voor stap 4

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.

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

Wanneer het inloggen is afgebroken geeft de Authorization Server de Persoon alsnog de mogelijkheid via zijn User Agent in te loggen. Wijzig hier dan de Sessie ID of het Trace ID?

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.

Is deze beschrijving zo correct?

9

Vroege beschikbaarheidstoets antwoord

DVA naar DVA

De ontvangst van het antwoord wordt ook gelogd.

Is deze beschrijving zo correct?

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 (OAuth authorization code)

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

Is deze beschrijving zo correct?

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.

Is deze beschrijving zo correct?

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

Nog uitgewerkt moet worden hoe de Trace-id oplossing precies gaat werken.

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

Zie boven.

Authorization request ID

Identifer van de authorization request. 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 in het huidige MedMij-request-ID, zie link naar betreffend onderdeel in Afsprakenstelsel.

• 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.

Endpoint van elk request en response

• Authorization Endpoint van de Authorization Server

• OAuth Client (redirect_uri)

• Token Endpoint van de Authorization Server

• Resource Endpoint van de Resource Server

Hieruit kan bepaald worden tussen welke schakels in de keten de gegevensuitwisseling heeft plaatsgevonden.

Is het lijstje met endpoints van requests en responses compleet?

Deelnemer ID

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

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

Is dit nodig?

Of is het voldoende om het endpoint te loggen?

wat is de gebruikte identifier voor DVA?

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?

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.

Om te achterhalen of dezelfde fout in de gegevensuitwisseling voorkomt bij dezelfde gebruiker die meerdere keren dezelfde actie uitvoert. Of dat dezelfde fout in de gegevensuitwisseling bij verschillende gebruikers voorkomt.

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. Het 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?

Opmerking Bouke: Als er verschillende versies van een standaard actief zijn (door middel van verschillende gegevensdiensten) lijkt het me een taak van regie? om dat samen te brengen in een rapportage

Resource ID

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

18 t/m 25?

Ook de versie van de resource is voor rapportages zeer relevant. Zij er problemen bij de gegevensuitwisseling bij een specifieke versie van de resource? De versie van de resource hoeft niet gelogd te worden. Maar moet op een andere manier verkregen worden dan uit aangeleverde logging. Bekend is immers per gegevensdienst welke versie van de resources daar gebruikt worden.

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?

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 404 (Not Found) 

HTTP 400 (Bad Request)

^{invalid_request}

HTTP 401 

invalid_token

HTTP 403

insufficient_scope

access_denied

HTTP 404 (Not Found) 

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 in de gedeelde loggegevens 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?

De ping functionaliteit test en verifieert bij voorkeur dat de 'applicatie' werkt. Vergelijkbaar met een HL7 ping versus TCP/IP ping (OSI-3). De laatste test alleen netwerkconnectivitiet de eerste de applicatieconnectiviteit op HL7 niveau (OSI-7)

De ping functie zorgt niet voor extra gat in de beveiliging! Het MedMij netwerk backchannel is besloten en alleen partijen die onderdeel van het MedMij netwerk zijn mogen daar toegang toe krijgen obv van de whitelist. Dit zou voor de ping fucntionalitiet ook moeten gelden.

Zowel de DVP als DVA hebben publieke ingang die naar mijn idde te gebruiken zijn voor een connectiviteitstest.