Document toolboxDocument toolbox

Afsprakenset release 1.4.0 > Architectuur en technische specificaties > Processen en informatie > Beschikbaarheids- en ontvankelijkheidsvoorwaarde

Owned by Casper van der Harst
Last updated: Apr 14, 2021
10 min read

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 van, zekere Personen op zekere Gegevensdiensten.

1b. De Dienstverlener zorgaanbieder voert, als verwerker voor elke verwerkingsverantwoordelijke Zorgaanbieder, diens in verantwoordelijkheid 1a bedoelde beleid uit in UC/UCI Verzamelen, UC/UCI Abonneren, UC/UCI Delen en UC/UCI Notificeren. De Dienstverlener zorgaanbieder voert in aanvulling op dat van de Zorgaanbieders geen eigen beleid dienaangaande.

1c. Het in verantwoordelijkheid 1a bedoelde beleid discrimineert op geen andere aspecten dan de Persoon en de Gegevensdienst. In het bijzonder is discriminatie op Dienstverlener persoon uitgesloten, tenzij dat door het MedMij Afsprakenstelsel wordt vereist.

Toelichting

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

De bedoeling daarvan is tweeledig.

  1. Het wil veilig stellen dat er zo snel mogelijk na de authenticatie van de Persoon, 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 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.

De Dienstverlener zorgaanbieder staat er bij het laten voortgaan van de procesgang dus voor in dat de behandelrelatie aanwezig is en dat de leeftijd voldoende is. Hoe de Dienstverlener zorgaanbieder dat (met de Zorgaanbieder) geborgd heeft is vrij. Aan die borging kunnen bijvoorbeeld bijdragen:

  • juridische middelen, zoals bepalingen in de dienstverleningsovereenkomst tussen Zorg­aanbieder en Dienstverlener Zorgaanbieder;
  • organisatorische maatregelen in de wijze waarop Zorgaanbieders het dossier beheren, zodat aan de dossierinformatie, aan de ordening ervan, of zelfs aan de loutere aanwezigheid er­van, gezien kan worden of er een behandelrela­tie aan ten grondslag ligt;
  • geautomatiseerde logica, die voor een zekere Persoon en een zekere Gegevensdienst de ontvankelijkheid/beschikbaarheid bij een zekere Zorgaanbieder bepaalt, voortbouwend op organisatorische maatregelen. 

Het MedMij Afsprakenstelsel verplicht er niet toe om leeftijdsgegevens en behandelrelatiegegevens expliciet te administreren. Waar het bestaan van een behandelrelatie of een toereikende leeftijd, op juridische en/of organisatorische gronden, geïmpliceerd wordt door andere gegevens, mogen laatstgenoemde gegevens ook met die implicatie gebruikt worden. Het MedMij Afsprakenstelsel speci­ficeert daarom geen logica voor de voorwaarden; het bepaalt slechts twee noodzakelijke onderdelen van hun post­conditie: een toereikende leeftijd van de Persoon en het (hebben) bestaan van een toepasselijke behandelrelatie.

Het niet-beschikbaar blijken zegt niets over de precieze reden. Daaruit kan zelfs niet worden geconcludeerd dat het­zij de behandelrelatie ontbreekt of de leeftijd ontoereikend is. De Zorgaanbieder kan ook an­dere redenen gehad hebben te weigeren.

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, 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).

Hieronder worden de vroege en de late variant vergeleken vanuit de perspectieven van dataminimalisatie en gebruiksvriendelijkheid. Beide aspecten moeten vanuit het perspectief van de gehele use case en alle betrokken rollen beschouwd worden: een keuze tussen de vroege en de late variant heeft effecten op meerdere plaatsen tegelijk. De afweging onderscheidt vier situaties, afhankelijk van twee vragen:

  • Acht de Zorgaanbieder (zich voor) de informatie (uitein­delijk) beschikbaar/ontvankelijk?
  • Geeft de Persoon (uiteinde­lijk) toestemming?

De late varianten verschillen overigens subtiel tussen zowel UC/UCI Verzamelen en UC/UCI Delen. In UC/UCI Delen is de late variant in vergelijking nog een stap vroeger dan in UC/UCI Verzamelen. Dat komt omdat anders een verwerking (namelijk: plaatsing) van gezondheidsinformatie zou gebeuren door de Resource Server nog voordat zou blijken dat de Zorgaanbieder hiervoor niet ontvankelijk is. In UC/UCI Verzamelen kan het een stapje later, omdat de te voorkomen actie pas de uitwisseling met de PGO Server is.

De twee varianten laten zich als volgt vergelijken inzake dataminimalisatie.


(uiteindelijk) wel beschikbaar/ontvankelijk(uiteindelijk) niet beschikbaar/ontvankelijk
(uiteindelijk)
wel 
toestemming
  • Voor zover er aparte geautoma­ti­seerde logica worden ge­bruikt voor een toets op beschikbaarheid of ontvankelijkheid vraagt de vroege variant ex­tra ver­keer ten opzichte van de late variant, namelijk tussen Autho­ri­zation Ser­ver en de com­ponent-(en) die zij voor het uitvoe­ren van die toets aan­spreekt. Dat ver­keer speelt zich wel geheel binnen de verantwoordelijkheid van een enkele verwerkingsverantwoordelijke af; er vindt geen verstrekking plaats.
  • De Authorization Server komt alleen in de vroege variant extra te weten dat behandel­relatie en leef­tijd in orde zijn. In de late variant komt alleen de Resource Server dat te weten. Dat laat onverlet dat beide onder dezelfde eindverantwoordelijke Dienstverlener Zorgaanbieder vallen.
  • In de late variant vindt, in tegenstelling tot in de vroege, al het verkeer na de au­thenti­catie (de toe­stem­mingsvraag, het uit­de­len van authoriza­tion code en ac­cess to­ken en het aan­spreken van de Resour­ce Ser­ver) onnodig plaats. Dit verkeer strekt zich uit over verantwoordelijkheidsgrenzen.
  • In de late variant krijgt de PGO Server, onnodig, meer over de beschikbaarheid/ontvankelijkheid, en dus over de Persoon, te weten van de Resource Server dan in de vroege variant van de Authorization Server. In de vroege variant kan de betreffende uitzondering immers, vanuit de PGO Server bezien, ook door falende authenticatie of weigering van toestemming veroorzaakt zijn. In de late variant komt de PGO Server echter wel te weten, door het ontvangen van de onnodige authorization code, dat er sprake is van zowel een behandelrelatie als een toereikende leeftijd.
(uiteinde­lijk) geen toestemming

In de late variant vindt, in tegenstelling tot in de vroege, een overbodige toe­stemmingsvraag plaats. Dit verkeer vindt plaats over het relatief onveilige frontchannel.

De twee varianten laten zich als volgt vergelijken inzake gebruiksvriendelijkheid. 


(uiteindelijk) wel beschikbaar/ontvankelijk(uiteindelijk) niet beschikbaar/ontvankelijk
(uiteindelijk) wel toestemming

geen verschil

In de vroege variant is de Persoon onmiddellijk op de hoogte, zodat deze:

  • geen onnodige en verwarrende handeling (betekenisloze toestemming) met rechtsgevolgen hoeft uit te voeren, zoals in de late variant;
  • preciezer dan in de late variant op de hoogte raakt van waarom een uitwisseling faalt. In de late variant kan dat falen andere redenen hebben, zodat de Persoon voor opheldering op ondersteuningsvragen aangewezen zou zijn, die wellicht zelfs aan de Zorgaanbieder gericht worden. In de vroege variant zijn Uitzonderingen 2, 3 en 4 in UC/UCI Verzamelen, UC/UCI Abonneren en UC/UCI Delen weliswaar samengenomen in één melding naar de PGO Server, zodat deze het onderscheid tussen falende authenticatie, falende autorisatie en falende beschikbaarheid/ontvankelijkheid niet kan maken. De Persoon zelf echter kent vanwege zijn/haar voorafgaande rechtstreekse interactie met de Authorization Server het resultaat van de authenticatie en de autorisatie wel, en kan dus alsnog uit deze gecombineerde melding, buiten medeweten van de PGO Server, afleiden of er sprake was van falende beschikbaarheid/toegankelijkheid.
(uiteindelijk) geen toestemming

In de vroege variant is de persoon onmiddellijk op de hoogte en hoeft deze geen onnodige en verwarrende handeling (holle afwijzing) uit te voeren, zoals in de late variant.

De gevallen waarin de Zorgaanbieder (zich voor) de informatie beschikbaar/ontvan­kelijk acht zijn, uitgaande van redelijk gedrag van de PGO Server, waarschijnlijk talrijker dan die waarin dat niet het geval is. Anderzijds wegen de nadelen van de vroege variant voor eerstgenoemde gevallen licht, omdat het zorgaanbiedersdomein en de Authorization Server om andere redenen al afdoende beveiligd moeten zijn, al is het maar vanwege het gebruik van het BSN. Bovendien is er alleen sprake van extra verkeer voor zo­ver geautomatiseerde logica wordt ingezet en daarvoor rollen anders dan de Authorization Server, en dus buiten het MedMij Afsprakenstelsel, worden aangesproken.

In deze release adviseert het MedMij Afsprakenstelsel daarom de vroege variant, vanwege bovengenoemde analyse. Het MedMij Afsprakenstelsel staat echter ook de late variant toe, om Dienstverleners Zorgaanbieder zowel de gelegenheid te geven snel aan te sluiten als de tijd om te overwegen hoe de vroege variant op termijn geïmplementeerd zou kunnen worden.

Verantwoordelijkheid 1c borgt het all-to-all-principe (principe 7) door te verbieden dat Dienstverleners zorgaanbieder bepaalde Dienstverleners persoon uitsluiten van (Abonnementen op) Gegevensdiensten die zij van enige Zorgaanbieder ontsluiten.

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 van, zekere Personen op zekere Gegevensdiensten.
1b.

De Dienstverlener zorgaanbieder voert, als verwerker voor elke verwerkingsverantwoordelijke Zorgaanbieder, diens in verantwoordelijkheid 1a bedoelde beleid uit in UC/UCI Verzamelen, UC/UCI Abonneren, UC/UCI Delen en UC/UCI Notificeren. De Dienstverlener zorgaanbieder voert in aanvulling op dat van de Zorgaanbieders geen eigen beleid dienaangaande.

1c.

Het in verantwoordelijkheid 1a bedoelde beleid discrimineert op geen andere aspecten dan de Persoon en de Gegevensdienst. In het bijzonder is discriminatie op Dienstverlener persoon uitgesloten, tenzij dat door het MedMij Afsprakenstelsel wordt vereist.

 Toelichting

Verantwoordelijkheid 1c borgt het all-to-all-principe (principe 7) door te verbieden dat Dienstverleners zorgaanbieder bepaalde Dienstverleners persoon uitsluiten van (Abonnementen op) Gegevensdiensten die zij van enige Zorgaanbieder ontsluiten.

1d.

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

 Toelichting

De bedoeling daarvan is tweeledig.

  1. Het wil veilig stellen dat er zo snel mogelijk na de authenticatie van de Persoon, 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 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.

De Dienstverlener zorgaanbieder staat er bij het laten voortgaan van de procesgang dus voor in dat de behandelrelatie aanwezig is en dat de leeftijd voldoende is. Hoe de Dienstverlener zorgaanbieder dat (met de Zorgaanbieder) geborgd heeft is vrij. Aan die borging kunnen bijvoorbeeld bijdragen:

  • juridische middelen, zoals bepalingen in de dienstverleningsovereenkomst tussen Zorg­aanbieder en Dienstverlener Zorgaanbieder;
  • organisatorische maatregelen in de wijze waarop Zorgaanbieders het dossier beheren, zodat aan de dossierinformatie, aan de ordening ervan, of zelfs aan de loutere aanwezigheid er­van, gezien kan worden of er een behandelrela­tie aan ten grondslag ligt;
  • geautomatiseerde logica, die voor een zekere Persoon en een zekere Gegevensdienst de ontvankelijkheid/beschikbaarheid bij een zekere Zorgaanbieder bepaalt, voortbouwend op organisatorische maatregelen.

Het niet-beschikbaar blijken zegt niets over de precieze reden. Daaruit kan zelfs niet worden geconcludeerd dat het­zij de behandelrelatie ontbreekt of de leeftijd ontoereikend is. De Zorgaanbieder kan ook an­dere redenen gehad hebben te weigeren.

2.

Het MedMij Afsprakenstelsel verplicht er niet toe om leeftijdsgegevens en behandelrelatiegegevens expliciet te administreren. Waar het bestaan van een behandelrelatie of een toereikende leeftijd, op juridische en/of organisatorische gronden, geïmpliceerd wordt door andere gegevens, mogen laatstgenoemde gegevens ook met die implicatie gebruikt worden. Het MedMij Afsprakenstelsel speci­ficeert daarom geen logica voor de voorwaarden; het bepaalt slechts twee noodzakelijke onderdelen van hun post­conditie: een toereikende leeftijd van de Persoon en het (hebben) bestaan van een toepasselijke behandelrelatie.

3.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, 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).

Varianten

Hieronder worden de vroege en de late variant vergeleken vanuit de perspectieven van dataminimalisatie en gebruiksvriendelijkheid. Beide aspecten moeten vanuit het perspectief van de gehele use case en alle betrokken rollen beschouwd worden: een keuze tussen de vroege en de late variant heeft effecten op meerdere plaatsen tegelijk. De afweging onderscheidt vier situaties, afhankelijk van twee vragen:

  • Acht de Zorgaanbieder (zich voor) de informatie (uitein­delijk) beschikbaar/ontvankelijk?
  • Geeft de Persoon (uiteinde­lijk) toestemming?

De late varianten verschillen overigens subtiel tussen zowel UC/UCI Verzamelen en UC/UCI Delen. In UC/UCI Delen is de late variant in vergelijking nog een stap vroeger dan in UC/UCI Verzamelen. Dat komt omdat anders een verwerking (namelijk: plaatsing) van gezondheidsinformatie zou gebeuren door de Resource Server nog voordat zou blijken dat de Zorgaanbieder hiervoor niet ontvankelijk is. In UC/UCI Verzamelen kan het een stapje later, omdat de te voorkomen actie pas de uitwisseling met de PGO Server is.

De twee varianten laten zich als volgt vergelijken inzake dataminimalisatie.


(uiteindelijk) wel beschikbaar/ontvankelijk(uiteindelijk) niet beschikbaar/ontvankelijk
(uiteindelijk)
wel 
toestemming
  • Voor zover er aparte geautoma­ti­seerde logica worden ge­bruikt voor een toets op beschikbaarheid of ontvankelijkheid vraagt de vroege variant ex­tra ver­keer ten opzichte van de late variant, namelijk tussen Autho­ri­zation Ser­ver en de com­ponent-(en) die zij voor het uitvoe­ren van die toets aan­spreekt. Dat ver­keer speelt zich wel geheel binnen de verantwoordelijkheid van een enkele verwerkingsverantwoordelijke af; er vindt geen verstrekking plaats.
  • De Authorization Server komt alleen in de vroege variant extra te weten dat behandel­relatie en leef­tijd in orde zijn. In de late variant komt alleen de Resource Server dat te weten. Dat laat onverlet dat beide onder dezelfde eindverantwoordelijke Dienstverlener Zorgaanbieder vallen.
  • In de late variant vindt, in tegenstelling tot in de vroege, al het verkeer na de au­thenti­catie (de toe­stem­mingsvraag, het uit­de­len van authoriza­tion code en ac­cess to­ken en het aan­spreken van de Resour­ce Ser­ver) onnodig plaats. Dit verkeer strekt zich uit over verantwoordelijkheidsgrenzen.
  • In de late variant krijgt de PGO Server, onnodig, meer over de beschikbaarheid/ontvankelijkheid, en dus over de Persoon, te weten van de Resource Server dan in de vroege variant van de Authorization Server. In de vroege variant kan de betreffende uitzondering immers, vanuit de PGO Server bezien, ook door falende authenticatie of weigering van toestemming veroorzaakt zijn. In de late variant komt de PGO Server echter wel te weten, door het ontvangen van de onnodige authorization code, dat er sprake is van zowel een behandelrelatie als een toereikende leeftijd.
(uiteinde­lijk) geen toestemming

In de late variant vindt, in tegenstelling tot in de vroege, een overbodige toe­stemmingsvraag plaats. Dit verkeer vindt plaats over het relatief onveilige frontchannel.

De twee varianten laten zich als volgt vergelijken inzake gebruiksvriendelijkheid.


(uiteindelijk) wel beschikbaar/ontvankelijk(uiteindelijk) niet beschikbaar/ontvankelijk
(uiteindelijk) wel toestemming

geen verschil

In de vroege variant is de Persoon onmiddellijk op de hoogte, zodat deze:

  • geen onnodige en verwarrende handeling (betekenisloze toestemming) met rechtsgevolgen hoeft uit te voeren, zoals in de late variant;
  • preciezer dan in de late variant op de hoogte raakt van waarom een uitwisseling faalt. In de late variant kan dat falen andere redenen hebben, zodat de Persoon voor opheldering op ondersteuningsvragen aangewezen zou zijn, die wellicht zelfs aan de Zorgaanbieder gericht worden. In de vroege variant zijn Uitzonderingen 2, 3 en 4 in UC/UCI Verzamelen, UC/UCI Abonneren en UC/UCI Delen weliswaar samengenomen in één melding naar de PGO Server, zodat deze het onderscheid tussen falende authenticatie, falende autorisatie en falende beschikbaarheid/ontvankelijkheid niet kan maken. De Persoon zelf echter kent vanwege zijn/haar voorafgaande rechtstreekse interactie met de Authorization Server het resultaat van de authenticatie en de autorisatie wel, en kan dus alsnog uit deze gecombineerde melding, buiten medeweten van de PGO Server, afleiden of er sprake was van falende beschikbaarheid/toegankelijkheid.
(uiteindelijk) geen toestemming

In de vroege variant is de persoon onmiddellijk op de hoogte en hoeft deze geen onnodige en verwarrende handeling (holle afwijzing) uit te voeren, zoals in de late variant.

De gevallen waarin de Zorgaanbieder (zich voor) de informatie beschikbaar/ontvan­kelijk acht zijn, uitgaande van redelijk gedrag van de PGO Server, waarschijnlijk talrijker dan die waarin dat niet het geval is. Anderzijds wegen de nadelen van de vroege variant voor eerstgenoemde gevallen licht, omdat het zorgaanbiedersdomein en de Authorization Server om andere redenen al afdoende beveiligd moeten zijn, al is het maar vanwege het gebruik van het BSN. Bovendien is er alleen sprake van extra verkeer voor zo­ver geautomatiseerde logica wordt ingezet en daarvoor rollen anders dan de Authorization Server, en dus buiten het MedMij Afsprakenstelsel, worden aangesproken.

In deze release adviseert het MedMij Afsprakenstelsel daarom de vroege variant, vanwege bovengenoemde analyse. Het MedMij Afsprakenstelsel staat echter ook de late variant toe, om Dienstverleners Zorgaanbieder zowel de gelegenheid te geven snel aan te sluiten als de tijd om te overwegen hoe de vroege variant op termijn geïmplementeerd zou kunnen worden.