Uitwerking Epic AF-1374, Bevindingen POC machtigen
1. Inleiding
Tijdens de POC machtigen is een aantal zaken naar voren gekomen die behandeld moeten worden. Deze uitwerking bevat een diepere beschrijving van de gevonden issues en een beschrijving van de mogelijk te nemen stappen.
2. Koppelingen
3. Probleemstelling
Het bestaande probleem van vermenging van gegevens betreffende verschillende zorggebruikers in één dossier is groter geworden met de introductie van vertegenwoordiging. Een persoon logt in bij de PGO van de Vertegenwoordigde en is zelf door meerdere personen aangewezen als vertegenwoordiger. Hierdoor kan in het autorisatieproces voor meerdere Personen gekozen worden en kan een Vertegenwoordiger de verkeerde Vertegenwoordigde kiezen. Hierdoor is de Vertegenwoordigde in het zorgdomein verschillend van de Vertegenwoordigde in het persoonsdomein en kunnen gegevens van twee verschillende personen vermengd worden. Dit kan ook nog eens gebeuren in een PGO waar de Vertegenwoordigde uit het zorgdomein geen gebruiker van is.
3.1. Combineren van dossiers
Bij vertegenwoordiging maakt de Vertegenwoordiger gebruik van de PGO van de Vertegenwoordigde. Hierbij krijgt de Vertegenwoordiger een account bij de PGO, waarmee hij/zij gebruik kan maken van het Dossier van de Vertegenwoordigde. Bij de DVP is dus bekend om wie het gaat, maar er is geen BSN bekend. Bij de DVA is dit echter niet persé het geval.
Om bij de DVA te kunnen autoriseren, moet de Vertegenwoordiger geauthenticeerd worden. Tijdens het authenticatieproces wordt gevraagd of de Vertegenwoordiger namens iemand anders gebruik gaat maken van de diensten en namens wie dat is. Indien een Vertegenwoordiger door meerdere Personen gemachtigd is hen te vertegenwoordigen, krijgt de Vertegenwoordiger een lijst te zien van de Personen die hij/zij vertegenwoordigt. De Vertegenwoordiger kiest de Vertegenwoordigde namens wij hij gegevens wil verzamelen/delen. Gedurende dit proces kan een Vertegenwoordiger een andere Vertegenwoordigde kiezen (per ongeluk of met opzet) dan voor wie hij op dat moment gebruikmaakt van de PGO. Zonder verdere controles vermengt de Vertegenwoordiger verschillende dossiers met elkaar, bewust of onbewust.
4. Oplossingsrichtingen
De volgende onderstaande opties zijn goed genoeg om te onderzoeken:
4.4. Gegevensdienst voor identificerende gegevens.
4.3.1. Scherm voordat gegevens worden opgehaald.
4.3.2. Gegevens in tijdelijke box, scherm om gegevens naar dossier te verplaatsen
4.2.4. Identificerende gegevens meegestuurd met token response.
Daarnaast moet gestreefd worden naar een situatie waarin beide domeinen gebruik kunnen maken van dezelfde geauthenticeerde identiteit, waarbij onderzocht moet worden of het gebruik van BSN dan noodzakelijk is.
4.1. Ideale situatie
Het probleem van vermenging van dossiers wordt opgelost als in beide domeinen gebruikgemaakt kan worden van dezelfde identifier voor een persoon, bijvoorbeeld het BSN (of polymorfe pseudoniemen). Het BSN kan gedeeld worden, waardoor op meerdere momenten in het proces gecontroleerd kan worden of in beide domeinen dezelfde Vertegenwoordiger en dezelfde Vertegenwoordigde worden gebruikt. Hierdoor kunnen de systemen controleren of de identifiers gelijk zijn. Zo niet, kan een foutmelding worden getoond en kan de flow worden afgebroken.
4.2. Autorisatie server gekoppeld met resource server of xIS
Zolang de autorisatie server gekoppeld is met de resource server, of directe toegang heeft tot het xIS, kan de autorisatie server identificerende gegevens ophalen. Hiermee kan een controle op de Vertegenwoordigde worden uitgevoerd.
4.2.1. Identificerende gegevens meegestuurd met authorization request
Als de DVP in het Authorization request vooraf gedefinieerde identificerende gegevens van de vertegenwoordigde meestuurt en de Authorization server dezelfde gegevens kan ophalen bij de Resource server (of direct bij het xIS), kan de Authorization server een controle doen op deze gegevens. Door de gegevens van de DVP te vergelijken met de gegevens uit de Resource server kan met enige zekerheid worden bepaald of de gegevens gaan over dezelfde Vertegenwoordigde. Indien de vergelijking een negatief resultaat heeft, toont de Authorization server een scherm waarop het resultaat van de vergelijking getoond wordt en de vraag of de Vertegenwoordiger wilt stoppen of doorgaan.
Voordeel: De controle wordt vroeg in het proces uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
Nadeel: Identificerende gegevens worden op een onveilige manier gedeeld, namelijk in een redirect van de browser. (mogelijke oplossing is gebruikmaken van Pushed Authorization Request)
Nadeel: Door het scherm te tonen kan iemand nog steeds bewust gegevens van verschillende personen vermengen in één dossier.
4.2.2. Identificerende gegevens meegestuurd met authorization response
Als de Authorization server gedefinieerde identificerende gegevens van de Vertegenwoordigde kan ophalen bij de Resource Server of het xIS, kunnen deze gegevens worden teruggestuurd naar de DVP. De DVP kan dan een controle doen van deze identificerende gegevens tegen de eigen gegevens. Indien de vergelijking een negatief resultaat heeft, toont de DVP een scherm waarop het resultaat van de vergelijking getoond wordt en de vraag of de Vertegenwoordiger wilt stoppen of doorgaan.
Voordeel: De controle wordt vroeg in het proces uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
Nadeel: Identificerende gegevens worden op een onveilige manier gedeeld.
4.2.3. Identificerende gegevens meegestuurd met token request
In vergelijking met optie 4.2.1 worden de gegevens nu niet meegestuurd met het authorization request, maar met het token request.
Voordeel: De controle wordt nog steeds voor een resource request uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
Nadeel: Het gaat hier om backchannelverkeer, waardoor de Authorization server geen scherm kan tonen. Bij een negatief resultaat moet dit worden teruggegeven aan de DVP. Indien gewenst moet deze de gegevens tonen en de vraag stellen of de Vertegenwoordiger toch wilt doorgaan. Het request moet dan opnieuw worden gestuurd, met extra informatie betreffende het antwoord op de vraag.
Nadeel: Door het scherm te tonen kan iemand nog steeds bewust gegevens van verschillende personen vermengen in één dossier.
4.2.4. Identificerende gegevens meegestuurd met token response
Vergelijkbaar met optie 4.2.2 worden de gegevens nu niet meegestuurd met het authorization request, maar met het token response.
Voordeel: De controle wordt nog steeds voor een resource request uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
4.3. Controlescherm DVP, zonder technische controle
Zodra de DVP gegevens gaat ophalen (of heeft opgehaald), wordt een scherm getoond waarin gevraagd wordt of de Persoon de nieuwe informatie wil toevoegen aan het actieve dossier. Bij vertegenwoordiging betekent dit dat gevraagd wordt of de opgehaalde gegevens toegevoegd mogen worden aan het dossier van de Vertegenwoordigde. Hierbij wordt nergens een technische controle gedaan op de gegevens, het gaat hierbij echt om een (re)actie van de Persoon. Dit kan op twee momenten in het proces. In beide gevallen zou het goed zijn om gegevens te kunnen tonen die de Vertegenwoordiger kan gebruiken om te vergelijken of de op te halen / opgehaalde gegevens ook echt bij Vertegenwoordigde horen. Echter bevatten niet alle gegevensdiensten gegevens betreffende de Persoon en daarmee dus geen identificerende gegevens.
4.3.1. Scherm voordat gegevens worden opgehaald of gedeeld.
Zodra de Persoon middels een redirect teruggaat naar de PGO, voordat een access-token opgehaald zal worden, toont de PGO een scherm met een tekst als: "U heeft zojuist aangegeven dat de gegevens (<lijst van geautoriseerde gegevensdiensten>) kunnen worden opgeslagen in het dossier van <Vertegenwoordigde>. Weet u dit zeker?"
Voordeel: De Vertegenwoordiger geeft nog voor het ophalen van de gegevens aan of hij/zij zeker weet dat de gegevens geplaatst moeten worden in het dossier van de Vertegenwoordigde.
Nadeel: Er kan niet altijd een goede vergelijking worden gedaan van identificerende gegevens, omdat deze niet beschikbaar zijn.
4.3.2. Gegevens in tijdelijke box, scherm om gegevens naar dossier te verplaatsen
Zodra de gegevens daadwerkelijk zijn opgehaald worden deze in een aparte tijdelijke map gezet. De PGO vraagt over deze gegevens aan de Vertegenwoordiger of de gegevens in het dossier geplaatst kunnen worden. In dit geval kan de tekst zijn: "De gegevens (lijst van opgehaalde gegevens) staan klaar om in het dossier van <Vertegenwoordigde> te plaatsen. Klik op opslaan om de gegevens naar het dossier te verplaatsen."
Voordeel: Gegevens worden nooit direct aan een dossier toegevoegd, maar staan in een tijdelijke box en worden pas verplaatst na goedkeuring.
Nadeel: Er kan niet altijd een goede vergelijking worden gedaan van identificerende gegevens, omdat deze niet beschikbaar zijn.
Nadeel: Gegevens zijn opgehaald voordat zeker is dat de gegevens daadwerkelijk over de Vertegenwoordigde gaan.
Nadeel: Gegevens worden gedeeld met een PGO waar de Vertegenwoordigde (Aanbiedersdomein) geen account heeft.
4.4. Endpoint voor identificerende gegevens
Om er zeker van te zijn dat een goede vergelijking kan worden uitgevoerd, worden door de DVP identificerende gegevens opgehaald via een daarvoor ingericht endpoint. Voordat de daadwerkelijk gewenste gegevensdienst wordt opgehaald, worden eerst de identificerende gegevens opgehaald en vergelijkt de DVP deze met de eigen gegevens. Indien deze niet voldoende overeenkomen, toont de DVP een scherm. Dit scherm kan een foutmelding bevatten en/of de vraag of de gegevens daadwerkelijk in het dossier geplaatst moeten worden.
Voordeel: De controle wordt uitgevoerd voordat daadwerkelijk gegevensuitwisseling plaatsvindt, maar wordt buiten de autorisatie getrokken (waar het al niet thuishoort).
Voordeel: Ditzelfde endpoint kan gebruikt worden voor de beschikbaarheids- en ontvankelijkheidstoets.
Nadeel: Alle deelnemers krijgen te maken met een nieuwe functionaliteit die geïmplementeerd dient te worden. DVA's moeten dit endpoint beschikbaar stellen, DVP's moeten het endpoint aanroepen.
Nadeel: Deelnemers moeten allemaal de identificerende gegevens in hun bezit hebben, zodat de controle kan worden uitgevoerd.
Nadeel: De controle wordt pas na autorisatie uitgevoerd, waardoor meerdere requests nodig zijn voordat duidelijk is dat er geen gegevensuitwisseling kan plaatsvinden.
5. Risico's
5.1. Geen identificerende gegevens aanwezig bij de Aanbieder
Het kan gebeuren dat de Aanbieder niet de identificerende gegevens heeft die nodig zijn voor de vergelijking. In dit geval kan bij geen van de opties de controle op uitgevoerd worden met een positief resultaat. In deze gevallen zal uitwisseling daarom niet tot stand kunnen komen bij vertegenwoordiging. De vraag is hiermee dan ook of de controle een verplichting moet zijn, of dat deze optioneel wordt.
5.2. Geen identificerende gegevens aanwezig bij de DVP
Niet alle DVP's bezitten de identificerende gegevens van een zorggebruiker. Wij verplichten hen dat op dit moment ook niet. Als een DVP de identificerende gegevens niet bezit, kan de controle niet worden uitgevoerd.
6. Vragen
6.1. Verplicht of optioneel
Moet de controle van de identificerende gegevens verplicht worden uitgevoerd of mag dit optionele implementatie zijn? Indien verplicht, dan verplichten we alle deelnemers ook de identificerende gegevens van de zorggebruiker te bezitten.
6.2. Alleen bij vertegenwoordiging of altijd
In de situatie dat we niet over vertegenwoordiging spreken, maar de zorggebruiker in het eigen dossier werkt, kunnen ook gegevens van een andere zorggebruiker vermengd worden met de eigen gegevens. De gekozen oplossing kan ook hiervoor een oplossing zijn, maar dan verplichten we de controle altijd uit te voeren.
7. Conclusie
De mooiste oplossing zou zijn dat in beide MedMij-domeinen gebruikgemaakt kan worden van dezelfde identifier, bijvoorbeeld het BSN of een polymorfe pseudoniem. Op lange termijn is denkbaar dat deze oplossing mogelijk zal zijn, echter op korte termijn zien we dit niet direct gebeuren. Daarom moet de next best solution worden gekozen. Voor de controle moet wel gebruikgemaakt worden van identificerende gegevens. Hiermee is het probleem van vermenging van gegevens in een dossier niet 100% op te lossen, maar de vraag is of er een oplossing is dit in de buurt komt.
Bij het opstellen van deze conclusie wordt rekening gehouden met andere onderwerpen. Zo kunnen we concluderen dat vanuit het onderwerp Gebruiksvriendelijke autorisatie de harde koppeling tussen Authorization server en Resource server wordt weggenomen, zodat een Authorization server door meerdere Resource servers gebruikt kan worden. Er is geen één-op-één koppeling meer tussen de twee. Dit zorgt ervoor dat een Resource server nog wel moet weten waar hij de toestemmingen kan nagaan, maar andersom werkt dit niet. De Authorization server hoeft niet te weten hoe de Resource server te bereiken en staat al helemaal niet meer in direct contact met een xIS. Vanuit het onderwerp Gebruiksvriendelijke autorisatie moet om deze reden gezocht worden naar een oplossing voor een nieuw probleem: De beschikbaarheidstoets (verzamelen & abonneren) en ontvankelijkheidstoets (delen) kunnen niet meer gedurende het autorisatieproces worden uitgevoerd. Gedacht wordt aan de introductie van een nieuw endpoint voor deze toetsen, zoals ook in Aorta wordt beschreven. Tussen het autorisatieproces en de daadwerkelijke uitwisseling wordt dit nieuwe endpoint aangeroepen. Hierdoor wordt de verantwoordelijkheid uit het autorisatieproces gehaald, maar wordt de controle nog wel uitgevoerd voordat er daadwerkelijk gegevens worden uitgewisseld.
Dit nieuwe endpoint biedt mogelijkheden voor het onderwerp dat in deze uitwerking wordt beschreven. Hetzelfde endpoint kan bij vertegenwoordiging gebruikt worden voor de extra controle op de juiste persoon. Door identificerende gegevens mee te sturen in het request kan de Resource server de controle uitvoeren en het resultaat teruggeven.
Om dit endpoint zo generiek mogelijk te kunnen beschrijven zal gebruikgemaakt worden van een UserInfo endpoint. Aan het request naar dit endpoint moeten voor vertegenwoordiging de identificerende gegevens van de vertegenwoordigde worden toegevoegd.
7.1. Waarom niet de andere opties?
Zoals hierboven beschreven wordt de wordt de koppeling tussen de Authorization server en de Resource server in de toekomst mogelijk verkleind. De Authorization server hoeft niet meer te weten hoe deze de Resource servers (en achterliggende xIS) kan benaderen en heeft daarmee geen toegang meer tot identificerende gegevens. Om dit niet op voorhand al in de weg te staan, moeten we de extra controle van identificerende gegevens uitvoeren op de Resource server. Alle opties die verwijzen naar het Authorization endpoint en Token endpoint komen hierdoor te vervallen.
Oplossingsrichtingen waarbij gegevens al uitgewisseld worden alvorens zeker te weten dat het om de juiste persoon gaat zijn geen optie. Vanuit privacy mogen de gegevens pas uitgewisseld als alle controles zijn uitgevoerd. Hiermee komen oplossingsrichtingen die geen extra controle bevatten ook te vervallen.