RFC0019 Abonneren en Notificeren: Subscription Interface revisited
Samenvatting
Waarom is deze RFC nodig? | Correcties en verbeteringen van de Subscription-interface naar aanleiding van vragen uit Acceptatie. |
---|---|
Oplossingsrichting | Verantwoordelijkheden rond Abonnement aanpassen én meerdere Abonnementen per ZA-GD-DVP-P toestaan. Subscription interface restful uitwerken: aparte calls voor aanmaken (POST), bijwerken (PUT) en opvragen (GET) uitwekren. |
Aanpassing van | AS: met name Subscription interface |
Impact op rollen | DVP, DVZA |
Impact op beheer | geen |
Impact op RnA | geen |
Impact op Acceptatie | Scripts voor calls/uitzonderingen |
Gerelateerd aan (Andere RFCs, PIM issues) | |
Eigenaar | |
Implementatietermijn | 1.2.0 of 1.2.1 |
Motivatie verkorte RFC procedure (patch) | Toepassen voordat eerste partijen dit gaan uitrollen. |
Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |
Compliance aan principes van MedMij
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | NvT | 11 Stelselfuncties worden vanaf de start ingevuld | Neutraal |
2 Dienstverleners zijn transparant over de gegevensdiensten | Positief | 12 Het afsprakenstelsel is een groeimodel | Positief |
3 Dienstverleners concurreren op de functionaliteiten | Positief | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Neutraal |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | Neutraal | 14 Uitwisseling is een keuze | Positief |
5 De persoon wisselt gegevens uit met de zorgaanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Neutraal |
6 MedMij spreekt alleen af wat nodig is | Positief | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Positief |
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Neutraal | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Neutraal |
9 De dienstverleners zijn deelnemers van het afsprakenstelsel | Neutraal | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | Neutraal |
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | Neutraal | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Neutraal |
Uitwerking
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135104999 aanpassen:
Toestemmingsverklaring
U geeft hierbij
NaamZorgaanbieder
toestemming om (voortaan) niet langer dan, gedurende ten hoogsteDuur
dagen, meldingen overNaamGegevensdienst
te doen bijNaamLeverancierPGO
om de betreffende persoons- en gezondheidsgegevens desgewenst te kunnen verzamelen in uw persoonlijke gezondheidsomgeving.De looptijd is mogelijk beperkt door
NaamZorgaanbieder
.Toelichting op de toestemmingsverklaring
Het doel van het MedMij Afsprakenstelsel is dat eenieder die dat wil, kan beschikken over een Persoonlijke Gezondheidsomgeving (PGO) waarin - onder uw eigen regie - (persoons)gegevens en/of informatie over uw gezondheid wordt opgenomen. Om de PGO te voorzien van de door u gewenste (persoons)gegevens en/of gezondheidsinformatie zijn in het MedMij Afsprakenstelsel afspraken gemaakt over de uitwisseling van deze gegevens. Het uitwisselen van gegevens tussen de zorgaanbieder en uw PGO verloopt zodoende via partijen die voldoen aan deze MedMij-afspraken.
Op grond van de Wet geneeskundige behandelingsovereenkomst (WGBO) is de zorgaanbieder verplicht ervoor te zorgen dat ‘anderen’ dan de patiënt (lees: u) geen inlichtingen hebben over, inzage hebben in of een afschrift hebben van uw medisch dossier, tenzij u hiervoor toestemming heeft verleend.
Aangezien uw PGO (en eventuele achterliggende partij die werkt volgens de MedMij-afspraken) een zogenaamde ‘andere’ is (in de zin van de WGBO) dient u de zorgaanbieder voor deze gegevensuitwisseling toestemming te verlenen. Deze toestemming heeft specifiek betrekking op de set van (persoons) gegevens en gezondheidsinformatie die, op uw verzoek, door de zorgaanbieder - overeenkomstig de afspraken in het MedMij Afsprakenstelsel - worden uitgewisseld met uw PGO.
Op basis van uw toestemming moet uw PGO een verzoek doen bij de Zorgaanbieder voor het doen van meldingen over de betreffende gegevensdienst voor de gevraagde duur; de Zorgaanbieder mag dit verzoek afwijzen of het honorerende met de gevraagde of een afwijkende kortere duur.
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103418 toevoegen aan de tabel uitzonderingen:
nr.uitzonderingactievervolgUC Abonneren 7Bron stelt vast dat verzoek niet past binnen gevoerd beleid ten aanzien van ter beschikking stellen van de gezondheids- of Abonnements-informatie.Bron informeert Uitgever over het niet ter beschikking stellen.Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135105537 aanpassen:
16. Deze bewaart het vastgestelde Abonnement in het persoonlijke Dossier.16. De Subscription Server legt het Abonnement vast zodanig dat bij een optredende wijziging in de Gegevensdienst voor deze Persoon een Notificatie verstuurd kan worden (zie /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103575).
17. De PGO Server legt het Abonnementvast het persoonlijkeDossier.
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103656 aanpassen:
3b. Bij elke combinatie van Zorggebruiker, Uitgever, Zorgaanbieder en Gegevensdienst mag op elk moment maximaal één
kunnen meerdereAbonnementenactief zijn. De Zorgaanbieder bepaalthet beleid omtrent het maximale aantal Abonnementen dat een Zorggebruiker kan aangaan.de duur van het Abonnement.Abonnementen
Nieuwe verzoeken tot Abonnementen vervangen eventueel bestaande.
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103656 toevoegen onder 3i:
Duur en einddatum
Bij het aangaan, verlengen, verkorten en beëindigen van Abonnementen wordt bij de betrokken interfaces gebruik gemaakt van twee verschillende parameters voor het aanduiden van de duur van het Abonnement: duration en end_date.
- Abonnementsduur wordt toegepast in de Authorization Interface en de Token Interface en geeft de duur aan in het gewenste aantal dagen. Hierdoor is de controle door de Authorization Interface op een geldige waarde voor deze parameter eenduidig en ongecompliceerd.
End_date
wordt toegepast in de Subscription Interface. In de transactie die daar plaats vindt, wordt de definitieve en precieze waarde van de datum tot waar een Abonnement loopt vastgesteld. Het door de Zorgaanbieder gevoerde beleid omtrent de maximale duur van een Abonnement, de gewenste duur zoals ingebracht door de Persoon en een zekere vrijheidsgraad rond het hanteren van datumgrenzen en systeemtijden maken het noodzakelijk dat een eenduidige einddatum wordt vastgesteld.
Op pagina Processen en informatie wijzigen onder 3d:
Beëindiging van Abonnementen
Er worden geen eisen gesteld omtrent het beëindigen van een Abonnement ingeval (gezondheids)informatie van een Zorggebruiker niet langer beschikbaar is bij een Zorgaanbieder, bijvoorbeeld na een dossieroverdracht, of na vernietiging van het dossier. Wanneer deze situatie zich voordoet, zullen simpelweg tot de einddatum van het Abonnement geen inhoudelijke Notificaties meer worden gegenereerd.
Het zou kunnen gebeuren dat een Notification Client een Notificatie wenst te sturen, in het kader van een lopend Abonnement, maar de OAuth Client List aangeeft dat de betreffende Notification Server hetzij geen Notificaties meer kan ontvangen of de betreffende Gegevensdienst niet (meer) ondersteunt. In die gevallen wordt de Notificatie niet verzonden, maar blijft het Abonnement in beginsel wel intact. Omdat er geen Notificaties worden verstuurd, bestaan er geen risico's om het Abonnement aan te houden. Mocht de OAuth Client List een administratieve fout bevatten, is dat nog geen reden voor ontbinding van het Abonnement tussen Persoon en Zorgaanbieder; als zo'n fout hersteld zou worden, kunnen er daarna weer Notificaties onder hetzelfde Abonnement verstuurd gaan worden. Mocht een Notification Client een dergelijke situatie aantreffen, is er wel aanleiding voor de betreffende Dienstverlener zorgaanbieder om contact op te nemen met de betreffende Dienstverlener persoon en, waar dan nog nodig, met de MedMij-beheerorganisatie. Zie ook verantwoordelijkheid 3e.
Het vierde punt gaat ervan uit dat de Dienstverlener zorgaanbieder een eigen administratie bijhoudt van welke Gegevensdiensten hij voor welke Zorgaanbieders ontsluit, en daarvoor niet leunt op de Zorgaanbiederslijst of andere lijsten. Zijn verwerkersrelaties met Zorgaanbieders zijn immers de bron van die lijsten, niet andersom. Het kan zijn dat de Dienstverlener zorgaanbieder een fout in die eigen administratie maakt en dan, vanwege het vierde punt, de betreffende Abonnementen beëindigd. Het MedMij Afsprakenstelsel voorkomt dat niet, omdat die fout moet worden gezien als een fout van de Dienstverlener zorgaanbieder als verwerker voor de Zorgaanbieder, met andere woorden, in het kader van de Dienstverleningsovereenkomst tussen die twee, en niet op het MedMij-koppelvlak.
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103425 toevoegen in de tabel met uitzonderingen:
- in geval van UCI Abonneren: Zorgaanbieder geen Notificaties beschikbaar maakt voor Persoon op die Gegevensdienst. (Er wordt geen Abonnement aangemaakt.)
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103637 aanpassen:
Hier is niet, zoals in de subscription notification, een
end_date opgenomen, omdat dat bij de hoofdfunctie Regie hoort. Communicatie over de Abonnementen-administratie vindt geheel plaats op het subscription notification interface. Het resource notification interface is alleen voor inhoudelijke notificaties. Mogelijk zal in toekomstige releases van het MedMij Afsprakenstelsel in de resource notification ook een nadere indicatie worden opgenomen van het onderdeel van de Gegevensdienst waarop er nieuwe informatie beschikbaar is.duration
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103425 aanpassen:
1a. De parameters in de authorization request worden als volgt gevuld: (in kolom 'toelichting' bij scope:
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
maximaleduur(duration)van het Abonnement0
is, betekent dat het verzoek om het beëindigen van het eventuele Abonnement op die Gegevensdienst bij die Zorgaanbieder.
en:
2. Na ontvangst van een authorization request met een zekere
client_id
en met een zekere Zorgaanbieder en GegevensdienstId in descope
, 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 deZorgaanbiederslijst;- indien in de scope ook
subscribe
voorkomt:
- 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 Zorgaanbieder ook Abonnementen op deze Gegevensdienst ontsluit;
- de waarde van de duur parameter in het request of de waarde heeft van 0 of een waarde groter dan 0 die kleiner of gelijk is aan de maximale duur van het Abonnement zoals de betreffende Zorgaanbieder deze aanbiedt.
Op pagina Token interface aanpassen:
Conform sectie 5.1 van de OAuth 2.0-specificatie. In toevoeging daarop: verplicht indien het authorization request verzocht om een Abonnement. In dat geval is de
scope
-parameter gelijk aan die in de betreffende authorization request, maar met deAbonnements-duurAbonnements-einddatum gesteld op de door de Authorization Server toegekende, en dus mogelijk beperkte, waarde, in hele dagen vanaf vandaag.De toegekende duur van het Abonnement is:
- niet hoger dan de in de authorization request gevraagde duur van het Abonnement;
- niet hoger dan de maximale abonnementsduur die de Zorgaanbieder in de Zorgaanbiederslijst had opgenomen bij die Gegevensdienst en die Interfaceversie;
- bij een gevraagde beëindiging de waarde 0.
Op dezelfde pagina verwijderen:
Maximale duur
Omdat een Zorgaanbieder in de Zorgaanbiederslijst geen maximale abonnementsduur mag opnemen die de maximale abonnementsduur bij de betreffende Gegevensdienst in de Catalogus overschrijdt, kan in de scope dus ook geen feitelijke abonnementsduur verschijnen die de maximale abonnementsduur bij de betreffende Gegevensdienst in de Catalogus overschrijdt.
Op pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103647 aanpassen:
duration
De resterende duur van het Abonnement, gerekend in hele dagen.
Als deze waarde0
is, is het Abonnement beëindigd door de Zorgaanbieder. In alle andere gevallen is deze waarde niet groter dan de resterende duur, op basis van de Abonnementen-administratie van de Subscription Server. De waarde kan wel kleiner zijn dan deze resterende duur, als het beleid van de Zorgaanbieder inzake de beschikbaarheidsvoorwaarde inkorting van het abonnement met zich meebrengt.
Abonnementen kunnen zowel door Zorgaanbieder als door Uitgever worden beëindigd. Beëindiging door Uitgever verloopt via de subscription interface. Beëindiging door Zorgaanbieder verloopt via de subscription notification interface.
Met de mogelijkheid tot inkorting wordt de Zorgaanbieder in gelegenheid gesteld beschikbaarheidsbeleid voortdurend te kunnen uitvoeren.end_date De datum waarop het Abonnement afloopt en wordt beëindigd door de Zorgaanbieder. Als deze waarde gelijk of kleiner is als de huidige (systeem)datum, dan is het Abonnement al beëindigd. In alle andere gevallen is deze waarde niet groter dan de huidige datum plus de maximale duur op basis van de Abonnementen-administratie van de Subscription Server. Abonnementen kunnen zowel door Zorgaanbieder als door Uitgever worden beëindigd. Beëindiging door Uitgever verloopt via de subscription interface. Beëindiging door Zorgaanbieder verloopt via de subscription notification interface.
Met de mogelijkheid tot inkorting wordt de Zorgaanbieder in gelegenheid gesteld beschikbaarheidsbeleid voortdurend te kunnen uitvoeren.
Op pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629189 aanpassen:
1c. De subscription notification hanteert de structuur: <base uri>\Notification\Subscription\{id} (zonder andere parameters in de URL).
1c1d
Op pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135629505 aanpassen:
1c. De resource notification hanteert de structuur: <base uri>\Resource\Subscription\{id} (zonder andere parameters in de URL).
1c1d
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
---|---|---|---|---|
Partijen hebben vorige variant van Subscription Interface al ingebouwd of zijn hiermee gestart. | L | M | Publiceren en aankondigen dat deze wijziging heeft plaats gevonden. Aanpassingen zijn lokaal (1 interface) en verwachting is dat nog niet veel partijen hiermee zijn gestart. |
Bijlagen