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. 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 Transactielijst (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://pim.vzvz.nl/browse/AF-319 |
Eigenaar | Arjan van Krimpen |
Implementatietermijn | 1.2.0 |
Motivatie verkorte RFC procedure (patch) |
Goedkeuring
Beoordelaar | Datum | Reactie | Toelichting |
---|---|---|---|
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 |
3 Dienstverleners concurreren op de functionaliteiten | Positief | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Positief |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | Positief | 14 Uitwisseling is een keuze | Positief |
5 De persoon wisselt gegevens uit met de zorgaanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Positief |
6 MedMij spreekt alleen af wat nodig is | Neutraal | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Positief |
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Positief | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Positief |
9 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 'Transactielijst' 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 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 transactielijst zonder Regie?
Op pagina Processen en informatie toevoegen/aanpassen:
Onder Dossier Use Cases; na 3.:
3.5: Uitgever biedt Zorggebruiker de use case Exporteren transactielijst om de transactielijst 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 'Transactielijst' die gedeeld kan worden en waarmee de MedMij inhoud van het dossier opnieuw opgebouwd kan worden is een eerste stap.
Op nieuwe pagina 'Transactielijst' onder Informatiemodellen toevoegen:
Transactielijst
Inhoud, schema van TransactieLijst.
Veld Type Beschrijving Transactielijst 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 VerzamelTransactie Tijdstip dateTime Moment waarop de Transactie 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.xsd
Importeren gaat uit RFC
Importeren van de Transactielijst 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 lijstNiet succesvol verzamelde items van de lijstOvergeslagen 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 Transactielijst het correcte schema <LINK NAAR SCHEMA> hanteert.De PGO Server loopt de items in de Transactielijst 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 verzameldNiet succesvol uitgevoerde UCI VerzamelenOvergeslagen 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 Transacties bestaan (zie hiervoor de Catalogus), of mocht één Transactie volgens de betreffende Informatiestandaard uit meerdere requests bestaan, bevraagt de PGO Server de Resource Server daarna mogelijk opnieuw voor de nog resterende Transacties, 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 Transactielijst.
Risico's
De Use Case Lijst bevat privacy gevoelige gegevens van een gebruiker. De lijst zal combinaties van zorgaanbiedernaam, gegevensdienst_id, datum bevatten, soort_transactie. 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.
Bijlagen