...
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.
Koppelingen
...
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.
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.
...
Daarnaast moet gestreefd worden naar een situatie waarin beide domeinen gebruik kunnen maken van dezelfde geauthentiseerde geauthenticeerde identiteit, waarbij onderzocht moet worden of het gebruik van BSN dan noodzakelijk is.
...
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.
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.
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.