Page tree
Skip to end of metadata
Go to start of metadata

Begrippenlijst (uitbreiding ten behoeve van machtigen)

Ten behoeve van machtigen zijn de volgende begrippen toegevoegd:

Term

Definitie

Toelichting

 

Synoniem

Vertegenwoordiging

De rechtsfiguur die inhoudt dat van een door een bepaalde partij (de vertegenwoordiger of gemachtigde) in naam van een andere partij (vertegenwoordigde of machtigingsverlener) met een derde een verrichte Rechtshandeling aan de vertegenwoordigde wordt toegerekend.


De bevoegdheid tot het verrichten van Vertegenwoordiging vloeit voort uit volmacht (privaatrecht Boek 3, Titel 3 Burgerlijk Wetboek (BW) of een Machtiging (bestuursrecht Hoofdstuk 2, afdeling 2.1 Algemene Wet Bestuursrecht).   

Machtiging kan worden gezien als een synoniem aan volmacht zij het dat de term machtiging voornamelijk in bestuursrechtelijke context wordt gebruikt. 

Een Rechtshandeling is een op rechtsgevolg gerichte wil die zich door een verklaring heeft geopenbaard (3:33 BW).  


Machtiging

De vertegenwoordigingsbevoegdheid die de Machtigingsverlener (lees: Gebruiker) verleent aan een ander de Gemachtigde  om namens/ in naam van de Machtigingsverlener (lees: Gebruiker), bepaalde Rechtshandelingen te verrichten.

Met de term Machtiging wordt de juridische vertegenwoordigingsbevoegdheid bedoeld zoals deze tussen partijen wordt afgesproken en niet de registratie daarvan die daarna in een Machtigingsregister wordt vastgelegd.

De term kan zowel betrekking hebben op één machtigingsrelatie als op een geheel dat bestaat uit een keten van machtigingsrelaties waarbij de ene gemachtigde optreedt als machtigingsverlener van de volgende. Dit volgt uit het recht op substitutie (art. 3:64 BW)

Substitutie is het recht van een gemachtigde om de aan hem verleende volmacht door te geven aan een ander. Dit recht moet door de machtigingsverlener worden verleend. Vervolgens kan de hoofdgemachtigde. Op grond van dit recht op substitutie, de machtiging doorgeven aan de substituut gemachtigde. We hebben het hier dan over Ketenmachtiging.         

Volmacht

Volmacht


De bevoegdheid die een volmachtgever (lees: Gebruiker)) verleent aan een ander, de gevolmachtigde, om namens hem / in zijn naam rechtshandelingen te verrichten.  


Machtiging

Gemachtigde

Een partij die op grond van een Machtiging de bevoegd verkrijgt om in naam van de Machtigingsverlener (lees: Gebruiker) bepaalde handelingen te verrichten waarvan de rechtsgevolgen worden toegerekend aan de Machtigingsverlener (lees: Gebruiker).


Vertegenwoordiger, Gebruiker

Machtigingsverlener

Een partij (lees: Gebruiker) die een (specifieke) machtiging verleent aan een andere partij (de gemachtigde).


Vertegenwoordigde, Gebruiker, Betroffene, Belanghebbende

Opgever

De handelend natuurlijke persoon die opgave doet aan een Machtigingsregister van een verleende machtiging zodat deze gebruikt kan worden en de voor deze registratie vereiste bewijzen aanlevert.



Machtigingsregister


Een partij die de verantwoordelijkheid heeft voor het registreren, beheren, controleren van  machtigingen en andere bevoegdheden en het afleggen van verklaringen over bevoegdheden (c.q. het op verzoek van de handelende natuurlijk persoon verstrekken van machtigingsverklaringen??? ).








Uitgangpunten volmacht:

1.Volmacht

De volmacht zelf is een eenzijdige gerichte rechtshandeling van de machtigingsverlener (3:60 BW) waarbij aan de gemachtigde de bevoegdheid wordt verleend om binnen de gestelde grenzen namens hem rechtshandelingen te verrichten. Is een volmacht aan twee op meer personen tezamen verleend, dan is ieder van hen bevoegd zelfstandig te handelen, tenzij anders bepaald.   (zie ook 3:60, 3:65 en 3:66 BW).  Het rechtsgevolg is gelegen in het verrichten van een rechtshandeling.   

2.Vormvereiste

De wijze waarop een volmacht wordt verleend is niet aan vormvereisten gebonden. Een volmacht kan uitdrukkelijk of stilzwijgend worden verleend (artikel 3:61 BW). De volmacht kan bijvoorbeeld blijken uit een verklaring van de machtigingsverlener, een geschrift of de onderlinge rechtsverhouding zoals een arbeidsovereenkomst.

3.Rechtsgevolg

De machtigingsverlening heeft rechtsgevolg op het moment dat zij ter kennis komt van de gemachtigde. De gemachtigde hoeft de machtiging niet te aanvaarden. Wel geldt dat als de gemachtigde de volmacht beëindigt, de volmacht eindigt. Zie ook 3:37 lid 3 en 3:73 BW.

4.Einde

De volmacht eindigt tevens door herroeping van de machtigingsverlener, de dood, curatele, faillissement of schuldsanering van de machtigingsverlener of de gemachtigde. Zie voor beëindiging van de volmacht ook artikel 3:72 BW

5.Kenbaarheid

Artikel 3:60 en 3:61 BW bepalen niet hoe de gemachtigde kenbaar moet maken dat hij namens de machtigingsverlener handelt.   

6.Handelingsbevoegdheid machtigingsverlener

De machtigingsverlener blijft naast de gemachtigde te allen tijde bevoegd om zelf te handelen.

7.Bewijs

Artikel 3:71 BW behelst aanwijzingen voor bewijsvoering van een machtiging. Het betreft de verklaring van de gemachtigde, een geschrift of een bevestiging van de machtigingsverlener. Deze verklaring kan door de wederpartij van de hand worden gewezen als niet bij verzoek om bewijs van de volmacht een geschrift wordt overlegd waaruit de volmacht volgt, dan wel een bevestiging van de machtigingsverlener volgt.      

8.Handelingsbevoegd

Voor de beantwoording van de vraag of de gemachtigde in de hoedanigheid van gemachtigde namens de machtigingsverlener binnen de grenzen van de bevoegdheid is opgetreden, is bepalend wat partijen over en weer hebben verklaard en redelijkerwijs uit deze verklaring hebben afgeleid en mochten afleiden.

9.Bekrachtiging

Wanneer iemand zonder daartoe gemachtigd te zijn namens een ander heeft gehandeld, kan laatstgenoemde de rechtshandeling bekrachtigen waardoor deze toch tot stand komt. Zie ook artikel 3:69 BW.   


Ketenmachtiging

De situatie waarin meer dan één machtigingsrelatie gebruikt moet worden om aan te tonen dat degene die een bepaalde dienst wil afnemen daartoe bevoegd is namens een eerste Machtigingsverlener. De ene zijde van deze keten wordt gevormd door de eerste Machtigingsverlener. De andere zijde van de keten wordt gevormd door de (laatste) Gemachtigde die degene is die de handeling uitvoert.



 Substitutie

Het door de Gemachtigde doorgeven van zijn machtiging aan een ander.  




Het uitgangspunt van het recht op substitutie is dat dit recht door de machtigingsverlener aan de gemachtigde moet worden verleend. Vervolgens kan de hoofdgemachtigde, op grond van dit recht op substitutie, de machtiging doorgeven aan de substituut gemachtigde. De substituut machtiging kan zowel aan een natuurlijk persoon als aan een onderneming of rechtspersoon worden verleend.

Evenals bij een volmacht blijft bij een substitutie, de machtigingsverlener bevoegd de rechtshandelingen te verrichten waarvoor de volmacht is verleend. De bevoegdheid om zelf te handelen blijft ook voor de hoofdgemachtigde bestaan. Dit is slechts anders als tussen partijen is overeengekomen dat de machtigingsverlener voor de duur van die overeenkomst zelf niet meer bevoegd is de betreffende rechtshandelingen te verrichten.


Opzet (met uitbreiding ten behoeve van machtigen)

Doel

De opzet van het afsprakenstelsel geeft op het hoogst mogelijke niveau een overzicht van de rollen in de gegevensuitwisseling via het MedMij-netwerk, hun onderlinge relaties, de interacties tussen deze rollen en de belangrijkste begrippen die geassocieerd zijn met rollen en partijen.

Rollen en relaties

We onderscheiden het Persoonsdomein en het Zorgaanbiedersdomein. Deze begrippen helpen om een onderscheid te kunnen maken tussen datgene dat zich afspeelt in de controlesfeer van de Persoon (door hemzelf of namens hem door zijn Dienstverlener persoon) en datgene dat zich afspeelt in de controlesfeer van de Zorgaanbieder (door hemzelf of namens hem door zijn Dienstverlener zorgaanbieder). Op beide domeinen is verschillende wetgeving van toepassing, en in beide domeinen kan de onderlinge verhouding tussen de Dienstverlener en de Gebruiker verschillend zijn.

De Persoon en de door hem of haar gekozen Dienstverleners persoon vormen het Persoonsdomein. Een Persoon kan gebruikmaken van een of meer Dienstverleners persoon. Een Dienstverlener persoon kan actief zijn voor een of meer Personen. In de afbeelding is dit weergegeven als een n-op-m-relatie.

De Zorgaanbieder en de door hem gekozen Dienstverlener zorgaanbieder vormen het Zorgaanbiedersdomein. De Zorgaanbieder kiest een of meer Dienstverleners zorgaanbieder. Een Dienstverlener zorgaanbieder kan actief zijn voor een of meer Zorgaanbieders. In de afbeelding is dit weergegeven als een n-op-m-relatie.

De Persoon en de Zorgaanbieder zijn Gebruiker van MedMij. De Dienstverlener persoon en de Dienstverlener zorgaanbieder zijn Deelnemer in het afsprakenstelsel. Alle Dienstverleners persoon en alle Dienstverleners zorgaanbieder vormen samen het MedMij-netwerk. Elke Dienstverlener persoon moet elke Dienstverlener zorgaanbieder kunnen bereiken, en vice versa. Daarom is een 'all-to-all'-relatie opgenomen in de afbeelding.

De Dienstverleners zijn voor de interactie via het MedMij-netwerk gehouden aan een set afspraken over het gewenste en toegestane gedrag op het netwerk. Het afsprakenstelsel bevat afspraken over de interacties via het netwerk, en een aantal aanvullende afspraken waaraan de Dienstverlener zich dient te houden vanuit het oogpunt van bescherming van de Gebruiker. De Dienstverleners leveren de Gebruiker daarnaast diensten waarover geen afspraken worden gemaakt via het afsprakenstelsel.

Interacties tussen de rollen

In onderstaande tabel zijn op het hoogste niveau de gegevensuitwisselingen tussen de gebruikers van het MedMij-netwerk beschreven. Hierbij is aangegeven wat de kernverantwoordelijkheid is van de verschillende rollen in het afsprakenstelsel. Het interactie-overzicht gaat niet in op de wijze waarop dit wordt gerealiseerd (dat volgt uit onder andere de technische en juridische uitwerking), en ook niet op randvoorwaardelijke interacties of gegevensuitwisselingen tussen de partijen (zoals het aansluiten op het MedMij-netwerk).

Nr.

Beoogd resultaat

Interacties

1

De Persoon heeft de door hem of haar gevraagde gezondheidsgegevens verkregen, die de Zorgaanbieder digitaal beschikbaar heeft.

De Persoon verzoekt de Dienstverlener persoon om namens hem of haar de Dienstverlener zorgaanbieder te verzoeken de gevraagde gegevens zoals die bij de Zorgaanbieder bekend zijn te verzenden naar de Dienstverlener persoon.

2

De Persoon heeft de Zorgaanbieder gezondheidsgegevens verstrekt.

De Persoon verzoekt de Dienstverlener persoon om namens hem of haar aan de Dienstverlener zorgaanbieder een door de Persoon aan de Dienstverlener persoon beschikbaar gestelde gegevensset te verzenden.

De Dienstverlener zorgaanbieder informeert de Zorgaanbieder over de nieuwe gegevens.


Toelichting:

De Persoon kan twee rollen vervullen: die van Vertegenwoordiger en die van Vertegenwoordigde. De Vertegenwoordiger heeft de interactie met de Dienstverlener persoon. De gezondheidsinformatie heeft betrekking op de Vertegenwoordigde. Dit kan dezelfde Persoon zijn maar de ene Persoon als Vertegenwoordiger kan ook een andere Persoon als Vertegenwoordigde vertegenwoordigen op basis van een machtiging. De naamgeving van de rollen kan verschillen per context. In de beschrijvingen die volgen is in de inleiding aangegeven welke term voor welke rol is toegepast.


Coördinatie, regie en uitwisseling (uitbreiding ten behoeve van machtigen)


Centraal staat de Regie; hiermee voert de Persoon regie, in interactie met de Zorgaanbieder, over (de uitwisseling van) zijn gezondheidsinformatie. Dat doet hij als uitgever, conform principe 16. Onder deze hoofdfunctie vallen bijvoorbeeld het geven van toestemming van de Persoon aan de Zorgaanbieder, het authenticeren van de Persoon door de Zorgaanbieder, het machtigen van een Vertegenwoordiger, het autoriseren van de PGO door de Zorgaanbieder en het aangaan, beëindigen en onderhouden van abonnementen.


 

Processen en informatie (uitbreiding ten behoeve van machtigen)

...

Rollen


  1. Dienstverlener persoon neemt de functionele rol van Uitgever op zich. Eén Dienstverlener Persoon speelt één of meerdere Uitgevers en elke Uitgever wordt gespeeld door één Dienstverlener Persoon.
  2. Dienstverlener zorgaanbieder neemt de functionele rol van Bron en/of Lezer op zich. Eén Dienstverlener zorgaanbieder speelt één of meerdere Bronnen en/of Lezers en elke Bron en/of Lezer wordt gespeeld door één Dienstverlener zorgaanbieder;
  3. Stichting MedMij neemt de functionele rol van MedMij Beheer op zich. Er is één Stichting MedMij die één MedMij Beheer speelt.
  4. Persoon kan twee rollen hebben:
    1. Vertegenwoordiger, die informatie uitwisselt via een PGO, en/of
    2. Vertegenwoordigde, waarop de informatie betrekking heeft.

Deze rollen kunnen vervuld worden door dezelfde persoon, die dus informatie uitwisselt die betrekking heeft op zichzelf, of door twee personen waarbij de ene persoon informatie uitwisselt die betrekking heeft op een andere persoon.  Eén Persoon is één Vertegenwoordiger en kan zichzelf en/of één of meerdere Vertegenwoordigden vertegenwoordigen.

Dossier

Use cases 

1a. Uitgever biedt Vertegenwoordiger de use case UC Verzamelen om bij Bron gezondheidsinformatie te verzamelen bij Zorgaanbieder, indien deze die informatie beschikbaar stelt, die op Vertegenwoordigde betrekking heeft en laat deze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Vertegenwoordigde bewaren. Elke Vertegenwoordigde heeft een eigen Dossier. Bij deze use case betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

Abonnementen

Abonnementen horen bij de hoofdfunctie Regie.

3b. Bij elke combinatie van Vertegenwoordiger, Vertegenwoordigde, Uitgever, Zorgaanbieder en Gegevensdienst hoort op elk moment maximaal één Abonnement.

Autorisatie

8a. Bron vergewist zich ervan of er sprake is van vertegenwoordiging en dat Vertegenwoordiger gemachtigd is om Vertegenwoordigde te vertegenwoordigen.

Toelichting

Er zijn 2 situaties te onderscheiden:

  • geen vertegenwoordiging: de Persoon heeft zowel de rol van Vertegenwoordiger van de PGO als de rol van degene waarover de informatie in het persoonlijke dossier gaat (Vertegenwoordigde), en
  • wel vertegenwoordiging: de ene Persoon laat zich door een andere Persoon vertegenwoordigen, door middel van een machtiging. Met een machtiging laat de Vertegenwoordigde gegevens betreffende zichzelf Verzamelen of Delen door een Vertegenwoordiger. Daarvoor moet Vertegenwoordiger rechtshandelingen uitvoeren namens de Vertegenwoordigde waaronder het verlenen van toestemming. De machtiging omvat het mandaat van de vertegenwoordiging, de betreffende gegevensdienst(en), zorgaanbieder(s) en de periode.

Authenticatie

9. Bron en Lezer dragen ervoor zorg dat de onder 7 bedoelde opvolging, en de onder 8a, 8b en 8c bedoelde vraag om Toestemming, respectievelijk bevestiging, slechts plaatsvinden wanneer hij de identiteit van de Vertegenwoordiger met passende zekerheid heeft vastgesteld. In het geval van vertegenwoordiging dient ook de machtiging vastgesteld te worden.

Logging en portabiliteit

19a. Uitgever zal het Dossier zo inrichten dat deze ook dienst kan doen als logbestand, zoals bedoeld in de AVG en NEN 7513:2018, van de door enige Vertegenwoordiger bij enige Bron verzamelde persoonsgege­vens van Vertegenwoordigde.

Toelichting

Met de logging wordt beoogd een betrouwbaar overzicht te kunnen leveren van de gebeurtenissen waarbij gezondheidsinformatie over een persoon zijn verwerkt. Waarbij Vertegenwoordiger en Vertegenwoordigde dezelfde Persoonkunnen zijn of waarbij Persoon als Vertegenwoordiger een andere Persoon als Vertegenwoordigde vertegenwoordigd. Die gebeurtenissen kunnen zich over verschillende plaatsen en tijden uitstrekken. Het beoogde overzicht is dus alleen mogelijk als de loggegevens uit verschillende bronnen kunnen worden gecombineerd. Ook zonder direct een virtueel wereldwijd en levenslang patiëntdossier als doel te stellen is duidelijk dat gestandaardiseerde logging een voorwaarde is om het overzicht voor de betreffende Persoon mogelijk te maken.


Applicatie (uitbreidingen ten behoeve van machtigen)

Rollen

  1. Uitgever:
    1. biedt aan Gebruiker, in het kader van de toepasselijke Dienstverleningsovereenkomst, een geautomatiseerde rol ter gebruik, hier genoemd: PGO Server. Eén Uitgever biedt één of meerdere PGO Servers en elke PGO Server wordt door één Uitgever geboden.
    2. stelt, indien deze UC Notificeren aanbiedt, aan Zorgaanbieder een geautomatiseerde rol Notification Server ter beschikking, waarop de Zorgaanbieder Notificaties kan aanbieden. Eén zulke Uitgever één of meerdere Notification Servers en elke Notification Server wordt door één Uitgever geboden.
  2. ...
  3. Gebruiker gebruikt twee geautomatiseerde rollen voor toegang tot de functionaliteit van PGO Server en Authorization ServerPGO Presenter voor de presentatie van de functionaliteit aan Gebruiker en PGO User Agent voor het aanspreken van PGO Server en Authorization Server.
  4. MedMij Beheer ontsluit ten behoeve van alle betrokkenen een geautomatiseerde dienst, hier genoemd: MedMij Registratie.
  5. Ten behoeve van het authenticeren van Gebruiker, zal de betrokken Authorization Server, in de rol van Authentication Client, gebruikmaken van de Authentication Service van een Authenticatie Provider ZA.
  6. In het geval van vertegenwoordiging: ten behoeve van het vaststellen van de machtiging van Persoon in de rol van Gebruiker (als Vertegenwoordiger) van Persoon in de rol van Betroffene (als Vertegenwoordigde), ontvangt de Authorization Server in de rol van Authentication Client een authenticatieverklaring van de machtigingsvoorziening van Authenticatie Provider ZA
  7. .....


Beschikbaarheids- en ontvankelijkheidsvoorwaarde (uitbreiding ten behoeve van machtigen)

Verantwoordelijkheden

1a. De Zorgaanbieder voert beleid ten aanzien van het beschikbaar houden van gezondheidsinformatie (en Abonnementen op Notificaties daarover) voor, en ontvankelijk zijn voor gezondheidsinformatie met betrekking op zekere Personen op zekere Gegevensdiensten.

Toelichting

Het instaan voor de beschikbaarheids- en de ontvankelijkheidsvoorwaarde is van kracht:

  • ergens tussen de gebruikersauthenticatie en de uitwisseling van gezondheidsinformatie in UC/UCI Verzamelen en UC/UCI Abonneren, respectievelijk UC/UCI Delen;
  • onmiddellijk bij het begin van UC/UCI Notificeren;

De bedoeling daarvan is tweeledig.

  1. Het wil veilig stellen dat er zo snel mogelijk na de authenticatie van de Persoon in de rol van Vertegenwoordiger en in het geval er sprake is van vertegenwoordiging het vaststellen van de machtiging, en in elk geval voordat er gezondheidsinformatie wordt uitgewisseld tussen PGO Server en Resource Server, uitgegaan mag worden van het vervuld zijn van twee voorwaarden voor het ver­zamelen of delen van de betreffende informatie: het bestaan van een (eventueel voorbije) behan­del­relatie met Persoon in de rol van Vertegenwoordigde als grond­slag daarvoor en van een leeftijd van de persoon van minimaal zes­tien jaar. Het is de juri­dische eindverantwoordelijkheid van de Zorgaanbieder deze voorwaar­den te (laten) verifiëren. Zie voor het leeftijdsaspect verder het Juridisch kader.
  2. Zij geven de Zorgaanbieder de kans naar eigen bevinden extra beperkingen, structu­reel of incidenteel, op te leggen aan het laten verzamelen, laten abonneren op notificaties, of laten delen van informatie, bijvoorbeeld om technische redenen of vanwege bijzondere situaties, bijzondere patiënten of aangrij­pende inhoud.

.........

Om redenen van dataminimali­satie en gebrui­ksvriendelijkheid zijn de beschikbaarheids- en ontvankelijkheidsvoorwaarden bij voorkeur zo snel mogelijk van kracht, dat wil zeggen, onmid­dellijk na de authenticatie van de Persoon en het vaststellen van een eventuele machtiging, nog voor de autorisatievraag (de vroege variant). De beschikbaarheids- en ontvankelijkheidsvoorwaarde behoren uit hun aard bij de hoofdfunctie Regie, niet bij Uitwisseling. Daartegenover wordt de implementatie van de voorwaarden voor sommige Deelnemers eenvoudiger als zij pas van kracht zouden hoeven te zijn wanneer de procesgang bij de Resource Server is aangekomen (de late variant).

.........

Resource interface (uitbreiding ten behoeve van machtigen)

Inleiding

Het resource interface hoort bij de hoofdfunctie Uitwisseling.

Op deze pagina staan alleen de verantwoordelijkheden inzake het resource interface die nog niet genoemd staan in:

  • de OAuth 2-specificatie;
  • de informatiestandaard van de Gegevensdienst die op het resource interface wordt aangesproken.


  1. De OAuth Client gebruikt voor het sturen van het acces token, in de resource request, de methode Authorization Request Header Field, zoals beschreven in sectie 2.1 van RFC6750.

Toelichting

De methode Authorization Request Header Field biedt de beste beveiliging.


  1. Na ontvangst van een resource request, in UCI Verzamelenof UCI Delen, zal de Resource Server, indien in antwoord daarop een resource response dient te worden gedaan, na maximaal zestig (60) seconden dit resource response ter beschikking stellen aan de PGO Server. Dit gedrag van de Resource Server is gedurende minimaal 98,5% van de tijd beschikbaar.


  1. Voor zover er in het verkeer tussenPGO Serveren Resource Server in de use case-implementaties UCI Verzamelen en UCI Delen sprake is, in de stuurgegevens, van een gegevenselement dat tot de identiteit van de Gebruiker herleid kan worden, gebruiken zij daarvoor niets anders dan de OAuth-gegevens die zij in hun respectievelijke OAuth Client en OAuth Resource Server moeten uitwisselen. PGO Server, Authorization Server en Resource Server treffen goed beveiligde voorzieningen waarmee zij hieruit waar nodig zelf de identiteit van de Gebruiker kunnen vaststellen.

Toelichting

Met het oog op het borgen van de privacy en het zo eenvoudig mogelijk houden van de architectuur van het MedMij Afsprakenstelsel, wordt ervoor gekozen de identifier voor de Gebruiker onderweg zo betekenisloos mogelijk te houden. Alle betekenis wordt er ter weerszijden aan verbonden door raadpleging van interne registraties. Omdat de PGO Server, Authorization Server en Resource Server samen een OAuth-flow afhandelen, beschikken zij (na authenticatie van de Gebruiker) over tokens die de identiteit van de Gebruiker vertegenwoordigen, namelijk (eerst) de authorization code en (later) het access token. Buiten deze hoeft en zal er geen identificerende gegevenselementen in het verkeer worden opgenomen. Het FHIR-gegevenselement PatientID wordt niet gebruikt.

  1. OAuth Resource Server en OAuth Clientbehandelen uitzonderingssituaties inzake het resource interface af volgens onderstaande tabel.

Nummer

Implementeert uitzondering

Uitzondering

Actie

Melding

Vervolg

Resource interface 1

UC Verzamelen 6, UC Delen 6

De validatie van het access token door Resource Server faalt.

Resource Server informeert PGO Serverover deze uitzondering. PGO Server informeert daarop Gebruiker hierover.

als OperationOutcome conform FHIR-specificatie, analoog aan uitzondering Resource interface 2, maar met issue type "security" of "suppressed".

Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

Resource interface 2

UC Verzamelen 5, UC Delen 5

Resource Server kan in de request niet, niet geheel of niet tijdig voorzien, om redenen anders dan uitzondering Resource interface 1.

Zie ook de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Resource Server informeert PGO Serverover deze uitzondering. PGO Server informeert daarop Gebruiker hierover.

conform de specificatie van de gebruikte Informatiestandaard

De flow mag worden voortgezet.

Authorization interface (met uitbreiding ten behoeve van machtigen)

Toelichting

Het authorization interface hoort bij de hoofdfunctie Regie. Voor de voorbereiding op machtigen is een placeholder voor de benodigde parameter opgenomen in de authorization request. In volgende versies van het afsprakenstelsel zal deze verder uitgewerkt worden. Het alternatief is om deze parameter niet in de interface op te nemen maar pas bij authenticeren aan te geven dat er sprake is van vertegenwoordiging. Het nadeel daarvan is dat de PGO er geen weet van heeft dat er sprake is van vertegenwoordiging, het voordeel is dat de interface ongewijzigd kan blijven en dat alles afgehandeld wordt door de combinatie van authenticatiemiddel en machtigingsvoorziening. 

Op deze pagina staan alleen de verantwoordelijkheden inzake het authorization interface die nog niet genoemd staan in de OAuth 2-specificatie.

1a. De parameters in de authorization request worden als volgt gevuld:

parameter

vulling

toelichting

response_type

letterlijke waarde code

Dit is het gevolg van verantwoordelijkheid 4 op de Applicatielaag.

client_id

de hostname, die in de OAuth Client List is opgenomen, van de Node van de OAuth Client die de authorization request doet


redirect_uri

  1. zodanig dat de erin opgenomen hostname gelijk is aan de client_id en er geen poortnummer is opgenomen
  2. de redirect_uri moet volledig zijn en verwijzen naar een https-beschermd endpoint

Zie verantwoordelijkheden 1 en 2a op de pagina Interfaces.

De tweede eis is een maatregel tegen beveiligingsrisico's 4.1.5, 4.2.4, 4.4.1.1, 4.4.1.5 en 4.4.1.6 in RFC 6819. Zie bovendien Token interface, de toelichting onder verantwoordelijkheid 4.

scope

optioneel:

  • de letterlijke waarde subscribe
  • gevolgd door een tilde ~
  • gevolgd door een niet-negatief geheel getal, aangevende de gevraagde maximale duur van het Abonnement
  • gevolgd door een forward slash /

gevolgd door, verplicht:

  • de betreffende (één) Zorgaanbiedernaam, ontdaan van de suffix @medmij, gevolgd door
  • een tilde (~), gevolgd door
  • het GegevensdienstId van de betreffende (één) Gegevensdienst uit de Gegevensdienstnamenlijst.

De scope bestaat dus uit een optioneel deel gevolgd door twee verplichte onderdelen.

Het optionele deel wordt gebruikt voor het aangaan, verlengen of beëindigen van een Abonnement. Als de gevraagde maximale duur van het Abonnement 0 is, betekent dat het verzoek om het  beëindigen van het eventuele Abonnement op die Gegevensdienst bij die Zorgaanbieder.

De twee verplichte delen volgen op het eventuele optionele deel en bestaat zelf uit twee, gescheiden door een tilde. Er mag in deze versie van het MedMij Afsprakenstelsel slechts sprake zijn van één van elk. Bij interpretatie van de Zorgaanbiedernaam door de ontvanger zal deze de suffix @medmij weer moeten toevoegen.

Er worden geen andere scopes of onderdelen van scopes opgenomen dan de hier genoemde.

Voorbeelden van syntactisch juiste scopes zijn:

  • eenofanderezorgaanbieder~42, voor het eenmalig afnemen van Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij;
  • subscribe~180/eenofanderezorgaanbieder~42, voor het aangaan van een Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij van maximaal 180 dagen, of het aanpassen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij naar maximaal 180 dagen vanaf vandaag;
  • subscribe~0/eenofanderezorgaanbieder~42, voor het beëindigen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij.

<represents>

Moet nog uitgewerkt worden

Placeholder voor de indicator dat er sprake is van vertegenwoordiging op basis van een machtiging. Voorstel: deze parameter is optioneel. Als de parameter niet aanwezig is of niet gevuld of met een waarde "false" dan is er (nog) geen sprake van vertegenwoordiging. Eventueel kan bij authenticatie nog gekozen worden voor vertegenwoordiging.

state

  1. conform sectie 4.1.1. van RFC 6749
  2. de waarde mag geen URI bevatten

Hiermee geeft de OAuth Client informatie mee aan de OAuth Authorization Server, waaraan eerstgenoemde later, bij de redirect, kan afleiden bij welk verzoek de authorization code hoort. Deze informatie is verder betekenisloos voor de OAuth Authorization Server.

De tweede eis is een maatregel tegen beveiligingsrisico 4.1.5. De state-parameter mag niet bedoeld zijn om te worden toegevoegd aan, of anderszins verwerkt in de redirect_uri.


1b. De OAuth Client zorgt ervoor dat voor het authorization request de http-methode GET wordt gebruikt, niet POST.

Toelichting

In de OAuth-specificatie, sectie 3.1 wordt de Authorization Server verplicht gesteld GET te accepteren en wordt POST optioneel gehouden. Deze verantwoordelijkheid geldt omdat GET de verreweg meest in het MedMij Afsprakenstelsel passende http-methode is voor de authorization request en om de Authorization Server niet voor onnodige implementatiekosten te plaatsen. Hoewel deze verantwoordelijkheid een verantwoordelijkheid van de OAuth Client is, omdat deze onder de verantwoordelijkheid van een MedMij-deelnemer valt, wordt de request uiteindelijk door de OAuth User Agent uitgevoerd.

  1. Na ontvangst van een authorization request met een zekere client_id en met een zekere Zorgaanbieder en GegevensdienstId in de scope, verifieert de Authorization Server dat:
  • deze GegevensdienstId voorkomt bij de betreffende client_id op de OAuth Client List;
  • zij namens deze Zorgaanbieder deze Gegevensdienst ontsluit, blijkens de Zorgaanbiederslijst;
  • indien in de scope ook subscribevoorkomt:
    • bij de betreffende client_id en Gegevensdienst op de OAuth Client List ook een subscription notification endpoint en een resource notification endpoint voorkomen;
    • zij namens deze Zorgaanbiederook Abonnementen op deze Gegevensdienst ontsluit, blijkens de Zorgaanbiederslijst.

Slagen niet al deze verificaties, dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid 6.

Verificatie van erkenning op Gegevensdienst

Zo voorkomt de Authorization Server dat er gevolg wordt gegeven aan een verzoek dat blijkens de OAuth Client List of Zorgaanbiederslijst niet is toegestaan.

  1. Tijdens de afhandeling van een authorization request laat de Authorization Server,in zijn rol als Authentication Client, voordat hij de Gebruiker om OAuth-autorisatie vraagt, de Gebruiker authenticeren door de Authentication Service en bij vertegenwoordiging de machtiging van Gebruiker tot vertegenwoordiging van Vertegenwoordigde vaststellen door de machtigingsvoorziening


Authenticatie

Conform stroomdiagram onder 1. De zorgaanbieder in het Zorgaanbieders- en dus BSN-domein is verplicht bij het verstrekken van gegevens vanuit een gezondheidsdossier de identiteit van de persoon te verifiëren aan de hand van het BSN. Bij het starten van de flow kan de Gebruiker aangeven of er sprake is van vertegenwoordiging of hij kan dit aangeven bij authenticatie. Deze indicatie moet meegegeven worden in de request aan de Authentication Service of bij ontbreken daarvan kan desgewenst de Authentication Service de Gebruiker de mogelijkheid bieden om via een Machtigingsvoorziening de Vertegenwoordigde te selecteren.


Het MedMij Afsprakenstelsel brengt het gebruik van de Authentication Service onder in de OAuth-flow, onder operationele verantwoordelijkheid van de Authorization Server. Laatstgenoemde handelt in dezen onder verantwoordelijkheid van individuele Zorgaanbieders, want die zijn het waarvoor de Persoon zich authenticeert. In het geval van vertegenwoordiging dient de Zorgaanbieder zich te vergewissen van de machtiging van Persoon als Vertegenwoordiger (in de rol van Gebruiker) tot vertegenwoordiging van de andere Persoon als Vertegenwoordigde (in de rol van Betroffene).

De directe interactie van de Persoon met de Authorization Server is bedoeld om de PGO Server te autoriseren om de Resource Server aan te spreken. Die levert de uiteindelijke Gegevensdienst pas.

  1. Onmiddellijk na authenticatie van de Gebruiker en in geval van vertegenwoordiging vaststellen van de machtiging, zoals bedoeld in verantwoordelijkheid 3, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Gebruiker om een Toestemmingsverklaring (in het geval van UCI Verzamelenof UCI Abonneren) of een Bevestigingsverklaring (in het geval van UCI Delen), volgens het daaromtrent bepaalde op de pagina User interface (verklaringen), volgens de standaard OAuth 2.0, op de wijze waarop deze in het MedMij Afsprakenstelsel wordt toegepast.
  2. Voorafgaand aan uitgifte van een authorization code via de in de authorization request opgenomen redirect_uri, administreert de OAuth Authorization Server die authorization code en de daarvoor gebruikte redirect_uri.

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.3, 4.4.1.5 en 4.4.1.7 uit RFC 6819 (zie Applicatie-laag, verantwoordelijkheid 18). Zie verantwoordelijkheid 4 bij het Token interface.

  1. Authorization Server en PGO Server behandelen uitzonderingssituaties inzake het authorization interface af volgens onderstaande tabel.

Nummer

Implementeert uitzonderingen

Uitzondering

Actie

Melding

Vervolg

Authorization interface 1a

UC Verzamelen 1

UC Delen 1

UC Abonneren 1

Authorization Server ontvangt een authorization request zonder (geldige) redirect_uri en/of zonder een (geldige) client_id.

Authorization Server informeert PGO Presenter over deze uitzondering. Authorization Server voert geen redirect naar de Clientuit, ook niet met een foutmelding. 

conform OAuth 2.0-specificatie, par. 4.1.2.1

Allen stoppen de flow van de UCI Verzamelen/UCI Delen onmiddellijk na geïnformeerd te zijn over de uitzondering.

Authorization interface 1b

Authorization Server ontvangt een ongeldige authorization request, anders dan uitzondering 1.

Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Gebruiker daarover.

conform OAuth 2.0-specificatie, par. 4.1.2.1, met de daar genoemde toepasselijke error code

Authorization interface 2

UC Verzamelen 2

UC Delen 2

UC Abonneren 2

Authorization Server kan de identiteit van de Gebruiker of de machtiging tot vertegenwoordiging niet vaststellen.

Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Gebruiker dat diens verzoek geen voortgang kan vinden, maar laat de oorzaak daarvan helemaal in het midden.

conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Access denied."

Authorization interface 3

UC Verzamelen 3

UC Delen 3

UC Abonneren 3

Authorization Server stelt tijdens de afhandeling van de authorization request vast dat:

  • in geval van UCI Verzamelen: van Vertegenwoordigde bij Zorgaanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is;
  • in geval van UCI Delen: Zorgaanbieder niet ontvankelijk is voor die Gegevensdienst van Vertegenwoordigde;
  • in geval van UCI Abonneren: Zorgaanbiedergeen Notificaties beschikbaar maakt voor Persoon op die Gegevensdienst.

Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Authorization interface 4

UC Verzamelen 4

UC Delen 4

UC Abonneren 4

De autorisatievraag wordt ontkennend beantwoord.

Authorization interface 5

UC Verzamelen 5

UC Delen 5

UC Abonneren 5

Authorization Server kan de autorisatie niet vaststellen.

Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Gebruiker hierover.

conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Authorization failed."

Toelichting

De uitzonderingssituaties  kunnen gezien worden als de implementatie-tegenhangers van de uitzonderingen van de UC Verzamelen en de UC Delen. Op de Applicatielaag zijn deze echter per interface geordend. Alle uitzonderingen worden door de Authorization Server ontdekt. In deze versie van het MedMij Afsprakenstelsel is bepaald dat zij altijd leiden tot het zo snel mogelijk afbreken van de flow door alle betrokken rollen. Daartoe moeten echter eerst nog de andere rollen geïnformeerd worden. Om te voorkomen dat de PGO Server informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven, moet het onderscheid tussen de uitzonderingen 2, 3 en 4 niet te maken zijn door de PGO Server.

Deze tabel bevat alleen die uitzonderingssituaties ten aanzien waarvan het MedMij afsprakenstelsel eigen eisen stelt aan de implementatie. In de specificatie van OAuth 2.0 staan daarnaast nog generiekere uitzonderingssituaties, zoals de situatie waarin de redirect URI ongeldig blijkt. Ook deze uitzonderingssituaties moeten geïmplementeerd worden.

  • No labels