MedMij-Mitz situatie en uitgangspunten
Huidige situatie MedMij
Persoon logt in op zijn PGO. PGO controleert of de identiteit die een persoon bij interacties met haar PGO hanteert ook inderdaad hoort bij die persoon. Persoon geeft vanuit zijn PGO een opdracht aan zijn DVP om bij een DVA gegevens van Aanbieder X te verzamelen. Vanuit de DVA krijgt de persoon de eerste keer verzoek zich te authenticeren (inlog DigiD), waarna de DVA vervolgens om langdurige toestemming vraagt aan de persoon voor de gegevensuitwisseling (Dit is per aanbieder) en deze toestemming vastlegt. Het autoriseren gebeurt via OAuth 2.0. Iedere keer erna dat een persoon opdracht geeft om te vezamelen, kan gebruik gemaakt worden van de langdurige toestemming en wordt de authenticatie stap overgeslagen. Hierbij wordt gebruik gemaakt van refresh-tokens binnen de OAuth2 implementatie
Nu is de toestemming tot gegevensuitwisseling 6 maanden geldig, tenzij tussendoor gebruik gemaakt wordt van de functie verzamelen dan wordt de duur vanaf dat moment met 6 maanden verlengd. Uiteraard kan de persoon op elk moment de toestemming voor gegevensuitwisseling per aanbieder intrekken.
Gewenste situatie (toekomst)
Persoon legt in een toestemmingenregister vast aan welke aanbieders er toestemming wordt gegeven om gegevens uit te wisselen met zijn PGO’s. Het toestemmingenregister is door alle aanbieders en alle PGO’s te raadplegen.
Voordelen van een Toestemmingenregister
Eén portaal voor vastlegging en beheer toestemmingskeuzes
Regie en overzicht bij de burger
Eenvoudig en betrouwbaar voor zorgaanbieders
Dienstverlener aanbieder hoeft geen connectie te hebben met DigiD
Problemen
In het persoonsdomein mag geen gebruik gemaakt worden van het BSN.
Zolang in het persoonsdomein geen gebruik gemaakt mag worden vh BSN, kan een PGO niet als raadpleger van het toestemmingenregister optreden en dus moet het toestemmingenregister een "bewijs" naar het PGO sturen of een koppeling kunnen leggen tussen PGO-id en BSN.
Uitgangspunten
Vanuit PGO kan, zolang geen BSN gebruikt mag worden in het Persoonsdomein, alleen toestemming voor desbetreffend PGO vastgelegd worden
Toestemming moet bestaan uit de volgende componenten
De zorgaanbieder die de gegevens mag delen: per categorie of een individuele zorgaanbieder in een categorie. Bijvoorbeeld alle ziekenhuizen of een specifiek ziekenhuis
Met wie de gegevens mogen worden gedeeld: specifiek PGO van waaruit de toestemming vastgelegd wordt.
Gebruik toestemmingenregister voor Aanbieders die aangesloten zijn bij MedMij is verplicht
Oplossingen zolang er geen BSN in Persoonsdomein gebruikt mag worden:
Toestemmingenregister stuurt inschrijfbewijs naar PGO
Persoon logt in op zijn PGO. PGO controleert of de identiteit die een persoon bij interacties met haar PGO hanteert ook inderdaad hoort bij die persoon. De Persoon gaat vanuit zijn PGO naar het toestemmingenregister en logt daar via DigiD in. Het toetstemmingeregister authenticeert de Persoon. De Persoon kan in het toestemmingenregister voor alle Aanbieders toestemming vastleggen om met desbetreffend PGO gegevens uit te wisselen. Hierbij wil je kunnen vastleggen aan welke Zorgaanbieders je toestemming geeft. De toestemming(en) worden vastgelegd in het toestemmingenregister. Het toestemmingenregister stuurt een “bewijs van inschrijving” naar het PGO van waaruit het toestemmingenregister is aangeroepen. Op het moment dat een Dienstverlener persoon een gegevensverzamelverzoek stuurt naar een Dienstverlener aanbieder met daarbij het bewijs van inschrijving in het toestemmingenregister, kan de Dienstverlener aanbieder bij het toestemmingenregister nagaan of de benodigde toestemming bekend is. Het toestemmingenregister kijkt in de combinatie van toestemmingen en kan concluderen of de Persoon toestemming heeft gegeven aan de Aanbieder om gegevens te delen met de PGO. In dit geval hoeft de Persoon niet meer in te loggen bij de Dienstverlener aanbieder en is er alleen nog backchannelverkeer tussen deze partijen. De Dienstverlener aanbieder ontvangt van het toestemmingenregister het BSN, waarna het de uitwisseling met het PGO kan starten.
PGO geeft PGO id mee naar Toestemmingenregister
Persoon logt in op zijn PGO. PGO controleert of de identiteit die een persoon bij interacties met haar PGO hanteert ook inderdaad hoort bij die persoon. De Persoon gaat vanuit zijn PGO naar het toestemmingenregister en logt daar via DigiD in. Hierbij wordt een ge-encrypte variant van het PGO-id meegestuurd. Dit is een wereldwijd uniek nummer (mbv OID). Het toestemmingeregister authenticeert de Persoon. De Persoon kan in het toestemmingenregister voor alle Aanbieders toestemming vastleggen om met desbetreffend PGO gegevens uit te wisselen. Hierbij wil je kunnen vastleggen aan welke Zorgaanbieders je toestemming geeft. Tevens wordt in het toestemmingenregister het ge-encrypte PGO-id gekoppeld aan het BSN van de persoon. Op het moment dat een Dienstverlener persoon een gegevensveerzamelverzoek stuurt naar een Dienstverlener aanbieder met daarbij het gen-encrypte PGO-id, kan de Dienstverlener aanbieder bij het toestemmingenregister nagaan of de benodigde toestemming bekend is. Het toestemmingenregister kijkt in de combinatie van toestemmingen en kan concluderen of de Persoon toestemming heeft gegeven aan de Aanbieder om gegevens te delen met de PGO. In dit geval hoeft de Persoon niet meer in te loggen bij de Dienstverlener aanbieder en is er alleen nog backchannelverkeer tussen deze partijen. De Dienstverlener aanbieder ontvangt van het toestemmingenregister het BSN, waanra het de uitwisseling met het PGO kan starten.
Wat is nodig/wensen:
vanuit PGO doorsturen naar toestemmingenregister en daar inloggen met DigiD
Toestemmingen kunnen beheren door Persoon zelf
Toestemmingenregister stuurt bewijs van inschrijving naar PGO (zonder BSN)/ Toestemmingenregister legt koppeling tussen ge-encrypt PGO-id en BSN