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. |
...
| |||||
1d. | Het instaan voor de beschikbaarheids- en de ontvankelijkheidsvoorwaarde is van kracht:
|
...
|
...
|
...
| |
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 specificeert daarom geen logica voor de voorwaarden; het bepaalt slechts twee noodzakelijke onderdelen van hun postconditie: een toereikende leeftijd van de Persoon |
...
en het (hebben) bestaan van een toepasselijke behandelrelatie. |
...
3. | Om redenen van dataminimalisatie en gebruiksvriendelijkheid zijn de beschikbaarheids- en ontvankelijkheidsvoorwaarden bij voorkeur zo snel mogelijk van kracht, dat wil zeggen, onmiddellijk 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 (uiteindelijk) beschikbaar/ontvankelijk?
- Geeft de Persoon (uiteindelijk) 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 |
|
|
(uiteindelijk) geen toestemming | In de late variant vindt, in tegenstelling tot in de vroege, een overbodige toestemmingsvraag 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:
|
(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/ontvankelijk 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 zover 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
...
.