Document toolboxDocument toolbox

RFC0002 Dataportabiliteit PGO obv UC-lijst

Samenvatting

Waarom is deze RFC nodig?

Dataportabiliteit tussen DVP's (of eigenlijk: Het kunnen switchen van PGO #1 naar PGO #2) is deel van de regiedoelstelling van MedMij. Zonder de mogelijkheid om naar een ander PGO te kunnen overstappen, wordt de regie van de gebruiker beperkt.

Oplossingsrichting

Ten eerste kan gesteld worden dat een PGO op zichzelf (oftewel ten aanzien van de Persoon) beschouwd kan worden als een invulling van het verlengde van het recht op (electronische) inzage: het recht op dataportabiliteit.
Daarnaast kan worden gesteld dat dataportabiliteit ook inhoudt dat de Persoon de gegevens van PGO#1 moet kunnen overzetten naar PGO#2. Hiervoor kan de Dienstverlener Persoon een (export-)mogelijkheid creëren.
Tenslotte zal het voor de Persoon ook mogelijk moeten kunnen zijn om niet alleen de inhoud maar ook de Afspraken te kunnen overzetten. Deze laatste lijkt de meest complexe en impactvolle vorm van uitwisseling, oftewel 'via het Afsprakenstelsel' tussen PGO's. Een eerste stap gebaseerd op een 'requestlijst' die gedeeld kan worden tussen PGO's waarmee PGO #2 de MedMij inhoud van het dossier opnieuw op kan opbouwen. (Meta-data/ queries) De requestlijst export is hiervoor een haalbare eerste stap.

In het Afsprakenstelsel wordt de eis opgenomen dat een PGO bij moet houden welke gegevensdiensten wanneer zijn geraadpleegd. Deze 'use case' Lijst kan een gebruiker opslaan in een voorgeschreven formaat. De nieuwe PGO kan deze lijst inlezen en op basis van de items in de lijst een nieuw dossier opbouwen, door de Verzamel acties opnieuw uit te voeren (van die gegevensdiensten die door de nieuwe PGO worden ondersteund).

De export als de import van de requestlijst (beiden op initiatief van de gebruiker van het PGO) wordt een verplichte functies voor een PGO, import wordt optioneel.

Aanpassing van

Afsprakenstelsel

Impact op rollen

DVP

Impact op beheer

NvT

Gerelateerd aan (Jira issues)

https://vzvz.atlassian.net/browse/AF-319

Eigenaar

Arjan van Krimpen

Implementatietermijn

1.2.0

Motivatie verkorte RFC procedure (patch)

Goedkeuring

BeoordelaarDatumReactieToelichting
Productmanager


Ontwerpteam


?


Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Positief

11 Stelselfuncties worden vanaf de start ingevuld

Positief

2 Dienstverleners zijn transparant over de gegevensdiensten 

Positief

12 Het afsprakenstelsel is een groeimodel

Positief

Dienstverleners concurreren op de functionaliteiten

Positief

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Positief

Dienstverleners zijn aanspreekbaar door de gebruiker

Positief

14 Uitwisseling is een keuze

Positief

De persoon wisselt gegevens uit met de zorgaanbieder

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Positief

MedMij spreekt alleen af wat nodig is

Neutraal

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Positief

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Positief

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Positief

De dienstverleners zijn deelnemers van het afsprakenstelsel

Positief

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Positief

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Positief

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Positief

Uitwerking

Op pagina Toelichting AVG-normen toevoegen na 'Algemeen' in de tabel op rij 17, kolom 'Opmerking en/of aandachtspunt'  Marie-José (Unlicensed)


Recht op overdraagbaarheid van gegevens Ten eerste kan gesteld worden dat een PGO op zichzelf (oftewel ten aanzien van de Persoon) beschouwd kan worden als een invulling van het verlengde van het recht op (electronische) inzage: het recht op dataportabiliteit.  Daarnaast kan worden gesteld dat dataportabiliteit ook inhoudt dat de Persoon de gegevens van PGO#1 moet kunnen overzetten naar PGO#2. Hiervoor kan de Dienstverlener Persoon een (export-)mogelijkheid creëren. Tenslotte zal het voor de Persoon ook mogelijk moeten kunnen zijn om niet alleen de inhoud maar ook de Afspraken te kunnen overzetten. Deze laatste lijkt de meest complexe en impactvolle vorm van uitwisseling, oftewel 'via het Afsprakenstelsel' tussen PGO's. Een eerste stap gebaseerd op een 'requestlijst' die gedeeld kan worden tussen PGO's waarmee PGO #2 de MedMij inhoud van het dossier opnieuw op kan opbouwen. (Meta-data/ queries).


Op pagina Processen en informatie toevoegen/aanpassen:

In tabel onder Verantwoordelijkheden:

Use caseStroomdiagram/wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136154564
UC Verzamelen/wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136155521Regie en Uitwisseling
UC Delen/wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136153111Regie en Uitwisseling
Raadplegen dossierzonderRegie
Exporteren requestlijstzonderRegie?

Op pagina Processen en informatie toevoegen/aanpassen:

Onder Dossier Use Cases; na 3.:

3.5: Uitgever biedt Zorggebruiker de use case Exporteren requestlijst om de requestlijst op een eigen medium (buiten de Applicatie) kan opslaan. 

Toelichting

De eis van dataportabiliteit die de AVG steldt houdt ook in dat de Zorggebruiker de gezondheidsgegevens van Bron#1 moet kunnen overzetten naar Bron#2. Hiervoor moet de Bron een (export-)mogelijkheid creëren. Deze 'requestlijst' die gedeeld kan worden en waarmee de MedMij inhoud van het dossier opnieuw opgebouwd kan worden is een eerste stap.

Op nieuwe pagina 'requestlijst' onder Informatiemodellen toevoegen:


requestlijst


Inhoud, schema van requestLijst.


VeldTypeBeschrijving
requestlijst

PGOnaamStringNaam zoals DVP bekend staat binnen MedMij
CreatieDatumdateTimeDatum waarop Lijst is aangemaakt.
StartDatumdateTimeBeginmoment van periode waarop Lijst betrekking heeft.
EindDatumdateTimeEindmoment van periode waarop Lijst betrekking heeft
Verzamelrequest
TijdstipdateTimeMoment waarop de request werd uitgevoerd.
Gegevensdienst

GegevensdienstIdstringGegevensdienstId zoals gebruikt in de ZAL.
ZorgaanbiedernaamstringZorgaanbiedersnaam zoals gebruikt in de ZAL.
Request
RequeststringRequest zoals uitgevoerd op Resource Server.
TijdstipdateTimeMoment waarop het Request werd uitgevoerd.

Schema: De RequestLijst volgt het schema van het Portabiliteitsrapport (zie XML-schema's)

Importeren gaat uit RFC

Importeren van de requestlijst gaat niet beschreven worden. Wellicht in latere versie wel als optionele functionaliteit?

Op nieuwe pagina UC Dossier opbouwen (onder Processen en Informatie) toevoegen:

De totale procesgang van de UC Dossier opbouwen kent de volgende stappen:

  • De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om een Dossier op te bouwen aan de hand van een Use Case Log.
  • De Zorggebruiker kiest expliciet een Use Case Log die de Zorggebruiker eerder heeft opgeslagen. De Use Case Log bevat een lijst met succesvol uitgevoerde Use Cases.
  • De Uitgever loopt de lijst af, als de lijst een Use Case bevat met een Gegevensdienst die door de Uitgever verzameld kan worden, start de bron een Use Case verzamelen.
    • Use Case Verzamelen wordt uitgevoerd.
  • De Uitgever verwerkt zo alle punten van de lijst:
    • Als een Gegevensdienst Zorgaanbieder al eerder op de betreffende lijst voorkomt, kan deze worden overgeslagen.
    • Als een Bron een Gegevensdienst niet ondersteunt, kan deze worden overgeslagen.
  • Na het aflopen van alle items in de Use Case Log, presenteert de Uitgever aan de Zorggebruiker een overzicht van:
    • Succesvol verzamelde items van de lijst
    • Niet succesvol verzamelde items van de lijst
    • Overgeslagen items van de lijst (met reden).

Op nieuwe pagina UCI Dossier opbouwen (onder Use Case implementaties) toevoegen:

De flow kent de volgende stappen:

  • De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om een bepaalde Transactielijst die de Zorggebruiker eerder heeft aangemaakt, te importeren.
  • De PGO Server controleert bij het importeren of de requestlijst het correcte schema <LINK NAAR SCHEMA> hanteert.
  • De PGO Server loopt de items in de requestlijst af:
    • Als een item een Gegevensdienst betreft die wordt ondersteund, dan start de PGO server de UCI Verzamelen <link toevoegen>.
    • Als een item een Gegevensdienst betreft die niet wordt ondersteund, dan wordt dit item overgeslagen.
    • Als een item een Gegevendienst Zorgaanbieder combinatie betreft die al eerder in de lijst voor kwam, dan mag dit item worden overgeslagen.
  • Als de lijst is afgelopen, maakt PGO Server een overzicht van items met daarbij:
    • Succesvol  uitgevoerde UCI Verzamelen verzameld
    • Niet succesvol uitgevoerde UCI Verzamelen
    • Overgeslagen items (met reden).
  • PGO Presenter toont dit overzicht aan de Zorggebruiker.

Op pagina UCI Verzamelen toevoegen:

.16 Deze bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere requests bestaan (zie hiervoor de Catalogus), of mocht één request volgens de betreffende Informatiestandaard uit meerdere requests bestaan, bevraagt de PGO Server de Resource Server daarna mogelijk opnieuw voor de nog resterende requests, eventueel na nieuwe interactie met de Zorggebruiker. Zolang het access token geldig is, kan dat. Voor ieder request dat leidt tot ontvangen gezondheidsinformatie, maakt de PGO server een corresponderend item aan voor gebruik in een requestlijst.

Risico's

De Use Case Lijst bevat privacy gevoelige gegevens van een gebruiker. De lijst zal combinaties van zorgaanbiedernaam, gegevensdienst_id, datum bevatten, soort_request. De gegevensdienst_id is voor deelnemers aan MedMij via de GNL te herleiden tot de soort gegevens die opgevraagd zijn, de zorgaanbiedersnaam is per definitie zonder extra informatie te herleiden tot de betreffende zorgaanbieder. De lijst geeft dus aan dat een gebruiker van een PGO een bepaalde soort gegevens opgevraagd of gedeeld heeft met een overduidelijke zorgaanbieder. De vraag is of de lijst versleuteld moet worden en hoe dan. Privacy wetgeving en GPRS (b)lijken hier elkaar te bijten.

MSC: Authenticiteit, de export moet alleen en veilig gedaan kunnen worden door de geauthenticeerde gebruiker. Het inrichten van dataportabiliteit betekent dat nog steeds alle waarborgen van identificatie, authenticatie en vertrouwelijkheid geregeld moeten zijn. Ik zie daar geen placeholder in de de uitwerking hiervan.



Bijlagen

  File Modified

GIF File UCLijst.schema.1.1.2.gif

Nov 19, 2019 by Arjan van Krimpen

File UCLijst.1.1.2.xsd

Dec 12, 2019 by Arjan van Krimpen

GIF File TransactieLijst.gif

Jan 14, 2020 by Arjan van Krimpen

File TransactieLijst.1.2.0.xsd

Jan 14, 2020 by Arjan van Krimpen