Page Comparison

Samenvatting

...

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 'Transactielijstrequestlijst' die gedeeld kan worden tussen PGO's waarmee PGO #2 de MedMij inhoud van het dossier opnieuw op kan opbouwen. (Meta-data/ queries).

...

In tabel onder Verantwoordelijkheden:

Use case	Stroomdiagram	/wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136154564
UC Verzamelen	/wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136155521	Regie en Uitwisseling
UC Delen	/wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136153111	Regie en Uitwisseling
Raadplegen dossier	zonder	Regie
Exporteren transactielijstrequestlijst	zonder	Regie?

Op pagina Processen en informatie toevoegen/aanpassen:

Onder Dossier Use Cases; na 3.:

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

Info
title 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 'Transactielijstrequestlijst' die gedeeld kan worden en waarmee de MedMij inhoud van het dossier opnieuw opgebouwd kan worden is een eerste stap.

Op nieuwe pagina 'Transactielijstrequestlijst' onder Informatiemodellen toevoegen:

Transactielijstrequestlijst

Inhoud, schema van TransactieLijstrequestLijst.

Veld	Type	Beschrijving
Transactielijstrequestlijst
PGOnaam	String	Naam zoals DVP bekend staat binnen MedMij
CreatieDatum	dateTime	Datum waarop Lijst is aangemaakt.
StartDatum	dateTime	Beginmoment van periode waarop Lijst betrekking heeft.
EindDatum	dateTime	Eindmoment van periode waarop Lijst betrekking heeft
VerzamelTransactieVerzamelrequest
Tijdstip	dateTime	Moment waarop de Transactie request werd uitgevoerd.
Gegevensdienst
GegevensdienstId	string	GegevensdienstId zoals gebruikt in de ZAL.
Zorgaanbiedernaam	string	Zorgaanbiedersnaam zoals gebruikt in de ZAL.
Request
Request	string	Request zoals uitgevoerd op Resource Server.
Tijdstip	dateTime	Moment waarop het Request werd uitgevoerd.

Schema:  TransactieLijst.1.2.0.xsdDe RequestLijst volgt het schema van het Portabiliteitsrapport (zie XML-schema's)

...

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 Transactielijst het requestlijst het correcte schema <LINK NAAR SCHEMA> hanteert.
• De PGO Server loopt de items in de Transactielijst 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.

...

.16 Deze bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere Transacties requests bestaan (zie hiervoor de Catalogus), of mocht één Transactie request volgens de betreffende Informatiestandaard uit meerdere requests bestaan, bevraagt de PGO Server de Resource Server daarna mogelijk opnieuw voor de nog resterende Transactiesrequests, 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 Transactielijstrequestlijst.

Risico's

De Use Case Lijst bevat privacy gevoelige gegevens van een gebruiker. De lijst zal combinaties van zorgaanbiedernaam, gegevensdienst_id, datum bevatten, soort_transactierequest. 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