RFC0039 Toestemming voor meerdere diensten van één aanbieder - v0.1
Samenvatting
Waarom is deze RFC nodig? | Met deze RFC wordt de gebruiksvriendelijkheid van de MedMij UC Verzamelen voor Personen vergroot. Deze RFC vormt één van de stappen in het vergroten van de gebruiksvriendelijkheid. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Oplossingsrichting | Requirements:
In een later stadium zal worden bekeken of binnen het afsprakenstelsel ook afspraken kunnen worden opgenomen om in één keer toestemming te kunnen geven voor een set van (gegevens)diensten van een aanbieder, die worden aangeboden via verschillende dienstverleners aanbieder. Dit behelst, naast een vertrouwens- en verwerkersrelatie tussen de betrokken DVA's, ook een (gestandaardiseerd) koppelvlak tussen de resourceserver van DVA-1 en de autorisatieserver van DVA-2. Voor deze RFC zijn een aantal oplossingsrichtingen overwogen:
Oplossingsrichting 1 - Toestemming voor lijst van gegevensdiensten In het huidige afsprakenstelsel worden authorization- en token endpoints van een specifieke zorgaanbieder geadministreerd op het niveau van interfaceversie (release van het afsprakenstelsel) EN gegevensdienst. Om een meervoudige toestemming mogelijk te maken zal naast de bestaande ZAL een nieuwe lijst op de MedMij stelselnode worden geïntroduceerd: de Autorisatieserverlijst (ASL). De ASL biedt een andere view op de gegevens die ook zijn opgenomen in de ZAL, en heeft de volgende logische structuur:
Voor eenzelfde aanbieder kunnen meerdere autorisatieservers zijn opgenomen in de ASL. Ook is het mogelijk dat voor eenzelfde gegevensdienst van een aanbieder meerdere autorisatieservers zijn opgenomen in de ASL. Dit is nodig wanneer een gegevensdienst wordt aangeboden o.b.v. meerdere interfaceversies, en eenzelfde autorisatieserver niet alle interfaceversies ondersteunt. Overwogen alternatief voor ASL Als nieuwe view op de ZAL is ook onderstaande structuur overwogen. Deze structuur is afgevallen omdat op basis ervan geen doorontwikkeling mogelijk is naar het geven van toestemming voor meerdere diensten van verschillende aanbieders.
DVA's moeten bij MedMij beheer aangeven voor welke interfaceversies, aanbieders en gegevensdiensten zij de mogelijkheid tot meervoudige toestemming bieden. Dit wordt gereflecteerd in de ASL. De inhoud van de ZAL en ASL worden door MedMij beheer in sync gehouden. Bepalen juiste authorization endpoint door DVP:
De flow voor verzamelen verloopt dan als volgt:
Oplossingsrichting 2 - Toestemming voor toestemmingscategorie Deze oplossingsrichting maakt zowel meer grofmazige als meer fijnmazige toestemmingen mogelijk, e.e.a. afhankelijk van de gekozen omvang van een toestemmingscategorie. Onderstaande figuur toont het gehanteerde metamodel. Een gegevensdienst bestaat uit één of meerdere systeemrollen. Binnen een systeemrol zijn één of meerdere interacties gespecificeerd, waarmee gegevens kunnen worden uitgewisseld. Om een interactie te mogen initieren is een access_token vereist. Een access_token wordt pas uitgegeven:
Nadere uitwerking:
Gewijzigde structuur van de GNL:
Gewijzigde structuur van de ZAL (slechts deels getoond):
Onderstaande tabel toont de relatie tussen de huidige verzamel-gegevensdiensten, systeemrollen, de initiële toestemmingscategorieën en de toestemmingsonderdelen.
*) De kolom "Te verzamelen bij" is gevuld a.d.h.v. de categorieën van zorgaanbieders die binnen Mitz worden onderkend:
**) De toestemmingscategorie waaronder de betreffende gegevensdienst valt is afhankelijk van de categorie van de zorgaanbieder die de documenten aanbiedt. Oplossingsrichting 3 - Introductie van overkoepelende gegevensdienst(en)
Toestemming in de WGBO WGBO artikel 457: Vergelijking van de oplossingsrichtingen
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Aanpassing van | De OAuth-flow in het MedMij afsprakenstelsel en de introductie van een nieuwe lijst op de stelselnode. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op rollen | DVP (optioneel), DVA (optioneel). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op beheer | Administreren van interfaceversies, aanbieders en gegevensdiensten waarvoor een DVA meervoudige toestemming ondersteunt. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op RnA | Administreren van interfaceversies, aanbieders en gegevensdiensten waarvoor een DVA meervoudige toestemming ondersteunt. Beschikbaarstellen van een nieuwe lijst, de ASL. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Impact op Acceptatie | Ja, vereist aanpassingen in acceptatiescripts. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Gerelateerd aan (Andere RFCs, PIM issues) | AF-1127 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Eigenaar | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementatietermijn | 1.4.0 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Motivatie verkorte RFC procedure (patch) |
Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |
Principe's
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | Positief | 11 Stelselfuncties worden vanaf de start ingevuld | Positief |
2 Dienstverleners zijn transparant over de (gegevens)diensten | 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 | Positief |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | Positief | 14 Uitwisseling is een keuze | Positief |
5 De persoon wisselt gegevens uit met de aanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Positief |
6 MedMij spreekt alleen af wat nodig is | Positief | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Positief |
7 De persoon en de aanbieder kiezen hun eigen dienstverlener | Positief | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Positief |
9 De dienstverleners zijn deelnemers van het afsprakenstelsel | Positief | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | Positief |
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | Positief | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Positief |
Uitwerking
Architectuur en technische specificaties
>> aanpassen plaat bovenaan pagina (toevoegen UC en UCI Opvragen ASL)
Coördinatie, regie en uitwisseling
Toevoegen UC Opvragen ASL, UCI Opvragen ASL en ASL interface op diverse plaatsen.
Processen en informatie
>> aanpassen plaat bovenaan pagina (toevoegen UC Opvragen ASL
Verantwoordelijkheden
Toelichting
De verantwoordelijkheden op deze laag zijn geordend in hoofdstukken en secties als volgt:
- Dossier
- Use cases
- Gegevensdiensten
- Authenticatie
- Autorisatie
- Lijsten
- Zorgaanbiederslijst
- Autorisatieserverlijst
- OAuth Client List
- Gegevensdienstnamenlijst
- Whitelist
- Logging en portabiliteit
Op meerdere plaatsen komen daarbij use cases (op deze laag) en use case-implementaties (op de Applicatie-laag) aan de orde. Een use case-implementatie is de implementatie van de use case met dezelfde naam. In deze release van het MedMij Afsprakenstelsel zijn er negen use cases, waarvan er zich zeven afspelen tussen het Persoons- en het Zorgaanbiedersdomein. Van deze zeven maken, om de interoperabiliteit in het MedMij-netwerk te borgen, stroomdiagrammen deel uit van het MedMij Afsprakenstelsel. De andere twee spelen zich helemaal binnen het Persoonsdomein af. Hiervan eist het MedMij Afsprakenstelsel wel dat erin moet worden voorzien, maar niet of slechts deels hoe; dat wordt aan de vrijheid van de MedMij-deelnemers gelaten.
Het gaat om de volgende use cases:
Use case | Stroomdiagram | |
---|---|---|
UC Verzamelen | met | Regie en Uitwisseling |
UC Delen | met | Regie en Uitwisseling |
UC Raadplegen dossier | zonder | Regie |
UC Portabiliteitsrapport | zonder | Regie |
UC Abonneren | met | Regie |
UC Notificeren | met | Regie en Uitwisseling |
UC Opvragen ZAL | met | Coördinatie |
UC Opvragen ASL | met | Coördinatie |
UC Opvragen OCL | met | Coördinatie |
UC Opvragen GNL | met | Coördinatie |
Voor registratie van Deelnemers en de vanwege hun deelname belangrijke gegevens zijn vooralsnog geen separate use cases geïdentificeerd, omdat registratie als een secundair proces wordt gezien. Zie hiervoor de pagina Operationele processen.
De interpretatie door een Zorggebruiker van zorg- en gezondheidsinformatie die hij heeft verzameld bij een Zorgaanbieder, en de interpretatie door een Zorgaanbieder van zulke informatie die met hem/haar gedeeld is door een Zorggebruiker, hangt niet alleen af van de inhoud van die informatie, maar ook van de partij die de betreffende informatie oorspronkelijk heeft geregistreerd. We gebruiken hiervoor niet zomaar de term Bron, omdat deze term in de zin van het MedMij Afsprakenstelsel niet per se de oorspronkelijke herkomst (de auteur) betekent, maar alleen de onmiddellijke herkomst, gezien vanuit de Uitgever. In het MedMij Afsprakenstelsel is de auteursrol geen juridische rol. Dat betekent niet alleen dat er binnen de grenzen van het MedMij Afsprakenstelsel momenteel geen basis is om auteursauthenticiteit (met bijvoorbeeld certificaten) te arrangeren, maar het brengt ook met zich mee dat informatie over de auteur, hoe wezenlijk ook, voor het MedMij Afsprakenstelsel een gegevens-inhoudelijke aangelegenheid is. Die informatie wordt immers ook gebruikt voor de interpretatie van de gedeelde zorg- en gezondheidsinformatie. Omdat, conform principe 1, het MedMij Afsprakenstelsel gegevensneutraal wil zijn, wordt de auteursinformatie een onderdeel geacht van de inhoud van een Gegevensdienst.
Gegevensdiensten
6. MedMij Beheer zal alleen in de Zorgaanbiederslijst en in de Autorisatieserverlijst opnemen dat een zekere Gegevensdienst door een zekere Zorgaanbieder via een zekere Bron, respectievelijk Lezer, wordt aangeboden, indien zij (Stichting MedMij) heeft vastgesteld dat de Dienstverlener zorgaanbieder die daarbij de Bron, respectievelijk Lezer, is, voldoet aan de specifiek op die Gegevensdienst toepasselijke eisen.
7a. Voor elke Gegevensdienst waarvan de Zorgaanbiederslijst of de Autorisatieserverlijst aangeeft dat een zekere Zorgaanbieder deze aanbiedt, zal Bron, respectievelijk Lezer, ervoor zorgdragen dat die Gegevensdienst ook geleverd wordt. Daarbij wordt geen enkel onderscheid gemaakt tussen Uitgevers, tenzij het MedMij Afsprakenstelsel daartoe uitdrukkelijk verplicht. Dit geldt ook voor de mogelijke andere Gegevensdienst(en) die in de Catalogus staan genoemd als Vereist bij eerstgenoemde Gegevensdienst.
7b. Het is verantwoordelijkheid 7a bepaalde is ook van toepassing zolang de geldigheid van de toepasselijke vermelding in de Zorgaanbiederslijst of in de Autorisatieserverlijst niet langer dan één uur (3600 seconden) geleden is verstreken.
Toelichting
Zo wordt ervoor ruimte geboden dat na-ijlende sessies, die nog gebruik maken van de verstrijkende versie van de Zorgaanbiederslijst of de Autorisatieserverlijst, nog kunnen worden afgemaakt.
Lijsten
Lijsten t.b.v. Coördinatie
In het MedMij Afsprakenstelsel worden, ten behoeven van de hoofdfunctie Coördinatie, een aantal lijsten gebruikt voor de interoperabiliteit en het vertrouwen tussen het Persoonsdomein en het Zorgaanbiedersdomein.
lijst | afkorting | wordt opgehaald en gebruikt door | informatie-inhoud | |
---|---|---|---|---|
Uitgever | Bron/Lezer | |||
Zorgaanbiederslijst | ZAL | X | welke Zorgaanbieders welke Gegevensdiensten aanbieden, en eventueel ook Abonnementen daarop, en op welke adressen zij die laten laten ontsluiten, gegeven een zekere Interfaceversie | |
Autorisatieserverlijst | ASL | X | welke Autorisatieservers beschikbaar zijn in het MedMij netwerk en welke Aanbieders en Gegevensdiensten zij ondersteunen | |
OAuth Client List | OCL | X | de namen van PGO's, welke Gegevensdiensten zij mogen gebruiken en naar welke adressen mogelijk Notificaties in het kader van Abonnementen op die Gegevensdiensten kunnen worden gestuurd, gegeven een zekere Interfaceversie | |
Gegevensdienstnamenlijst | GNL | X | X | de gebruiksvriendelijke namen van Gegevensdiensten |
Whitelist | WHL | X | X | welke Nodes actief mogen zijn op het MedMij-netwerk |
Zorgaanbiederslijst en Autorisatieserverlijst
10. MedMij Beheer beheert en publiceert een Zorgaanbiederslijst en een Autorisatieserverlijst , namens de deelnemende Dienstverleners zorgaanbieder. De gepubliceerde lijsten bevatten steeds en slechts alle actuele entries, en beschrijven van elke Zorgaanbieder:
- welke Gegevensdiensten deze momenteel aanbiedt via welke Bron en Lezer, en welke technische adressen daarvoor moeten worden aangesproken bij de Dienstverlener zorgaanbieder, gegeven een zekere Interfaceversie;
- voor welke Gegevensdiensten het mogelijk is om Abonnementen aan te gaan en via welke technische adressen dit kan worden gedaan, gegeven een zekere Interfaceversie. In deze release van het MedMij Afsprakenstelsel staat de Catalogus alleen Abonnementen toe op Gegevensdiensten die zijn gebaseerd op de UC Verzamelen.
Toelichting
Deze afspraak wijst MedMij Beheer de verantwoordelijkheid toe om ten behoeve van alle Dienstverleners persoon de benodigde lijsten te verspreiden van Zorgaanbieders en de door hen aangeboden Gegevensdiensten en Abonnementen. Zonder deze functie zou het stelsel niet functioneren.
In de Catalogus staat bij elke Gegevensdienst de maximale duur van een Abonnement op (Notificaties van) die Gegevensdienst. Bij een Gegevensdienst gebaseerd op UC Delen zal hier vooralsnog altijd 0
als maximale duur staan, hetgeen betekent dat er geen Abonnementen mogelijk zijn op deze Gegevensdienst.
11. De Zorgaanbiederslijst en de Autorisatieserverlijst voldoen aan wat over hen is bepaald in de Informatiemodellen.
12. MedMij Beheer beheert en publiceert, in de Zorgaanbiederslijst en in de Autorisatieserverlijst, unieke en gebruikersvriendelijke namen van Zorgaanbieders, van het formaat <zorgaanbieder>@medmij.
Daarop is naamgevingsbeleid van toepassing.
Toelichting
13a. MedMij Beheer biedt aan Uitgever een use case (UC Opvragen ZAL) om de actuele versie van die Zorgaanbiederslijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.
13b. MedMij Beheer biedt aan Uitgever een use case (UC Opvragen ASL) om de actuele versie van die Autorisatieserverlijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.
Processen en informatie - UC Verzamelen - Totaalperspectief
De totale procesgang van de UC Verzamelen kent de volgende stappen:
- De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om te verzamelen.
- De Zorggebruiker kiest expliciet de zorgaanbieder waarbij hij de informatie wenst te verzamelen en de specifieke Gegevensdienst(en). Daarvoor kunnen desgewenst de Gegevensdienstnamen worden gebruikt uit de Gegevensdienstnamenlijst. Het verzoek gaat naar de passende Bron.
- De Bron ontvangt de Zorggebruiker.
- De Bron laat de Zorggebruiker zich authenticeren.
- Wanneer de Zorggebruiker de authenticatie heeft afgebroken geeft de Bron de mogelijkheid alsnog te authenticeren of de flow af te breken.
- Dan breekt het moment aan waarop de Bron op zijn vroegst ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. In deze release staat het MedMij Afsprakenstelsel het toe die voorwaarde op een later moment van kracht te laten zijn, maar niet later dan het laatste in het figuur aangegeven moment.
- De Bron vraagt aan de Zorggebruiker of hij toestemming geeft tot het verstrekken van de gevraagde informatie aan de Uitgever. Deze vraag staat op de pagina Toestemmingsverklaring.
- De Bron logt die toestemming en laat de Uitgever weten dat de toestemming gegeven is.
- Nu kan de Uitgever de Bron vragen om de gezondheidsinformatie.
- Uiterlijk na de ontvangst van het verzoek zal de Bron ervoor instaan dat de Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
- Bij ontvangst slaat de Uitgever die informatie op in het persoonlijke dossier.
- Mocht de afgegeven autorisatie meerdere Gegevensdiensten omvatten, of mocht een Gegevensdienst uit meerdere Transacties bestaan (zie hiervoor de Catalogus), dan bevraagt de Uitgever de Bron daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe interactie met de Zorggebruiker.
- Bij de informatie wordt ook de meta-informatie opgeslagen die wordt bedoeld in verantwoordelijkheid 19 van de Processen- en Informatielaag.
Processen en informatie - UC Verzamelen - Uitzonderingen (Totaalperspectief)
nr. | uitzondering | actie | vervolg |
---|---|---|---|
UC Verzamelen 1 | Bron vindt het ontvangen verzoek ongeldig. | Bron informeert Uitgever over deze uitzondering. Uitgever informeert daarop Zorggebruiker hierover. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
UC Verzamelen 2 | Bron kan de identiteit van de Zorggebruiker niet vaststellen. | Bron informeert Uitgever dat verzoek niet wordt ingewilligd. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
UC Verzamelen 3 | Bron stelt op enig moment vast dat van Persoon bij Zorgaanbieder geen gezondheidsinformatie voor geen van de gevraagde Gegevensdiensten beschikbaar is. Hiervan is in elk geval sprake indien hetzij:
Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde. | ||
UC Verzamelen 4 | De voorgelegde Toestemmingsverklaring wordt niet afgegeven. | ||
UC Verzamelen 5 | Bron kan het antwoord op de toestemmingsvraag niet vaststellen. | Bron informeert Uitgever over deze uitzondering. Uitgever informeert daarop Zorggebruiker hierover. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
UC Verzamelen 6 | Bron kan, zelfs na toestemming, de gezondheidsinformatie alsnog niet ter beschikking stellen aan de Uitgever. | Bron informeert Uitgever over deze uitzondering. Uitgever informeert daarop Zorggebruiker hierover, met opgave van oorzaak. | Mocht de gezondheidsinformatie deels wel (geautoriseerd) ter beschikking staan, dan kan de flow dat nog verzorgen. |
UC Verzamelen 7 | Zorggebruiker annuleert het inloggen. | Bron presenteert een annuleringspagina en biedt Zorggebruiker de optie om toch in te loggen. | Indien Zorggebruiker kiest niet in te willen loggen, kan het scherm gesloten worden. Zorggebruiker kan er ook voor kiezen toch in te loggen. In dat geval vraagt Bron weer om credentials. |
Processen en informatie - UC Opvragen ASL
Tekst en plaatje analoog aan UC Opvragen ZAL.
Applicatie
>> aanpassen plaat bovenaan pagina (toevoegen UCI Opvragen ASL)
Toelichting
Voor een overzicht over alle lagen van de architectuur, en voor een toelichting van de betekenis van de symbolen en lijntjes, zie de overzichtspagina.
De afkorting:
- ASL staat voor Autorisatieserverlijst
- BV staat voor Bevestigingsverklaring;
- GNL staat voor Gegevensdienstnamenlijst;
- OCL staat voor OAuth Client List;
- TV staat voor Toestemmingsverklaring;
- TVA staat voor Toestemmingsverklaring Abonneren;
- ZAL staat voor Zorgaanbiederslijst.
Use cases en Gegevensdiensten
Toelichting
Van de meeste use cases (zie de laag Processen en Informatie) wordt op deze (Applicatie)laag een use case-implementatie (UCI) voorgeschreven. Het gaat om de volgende.
use case-implementatie | Stroomdiagram | |
---|---|---|
UCI Verzamelen | met | Regie en Uitwisseling |
UCI Delen | met | Regie en Uitwisseling |
UCI Abonneren | met | Regie |
UCI Notificeren | met | Regie of Uitwisseling |
UCI Opvragen ZAL | met | Coördinatie |
UCI Opvragen ASL | met | Coördinatie |
UCI Opvragen OCL | met | Coördinatie |
UCI Opvragen GNL | met | Coördinatie |
Autorisatie en OAuth
6. De OAuth Client maakt alleen gebruik van één scope tegelijk. De OAuth Authorization Server genereert authorization codes en access tokens met een enkelvoudige scope die geheel vervat moet zijn in de Gegevensdienst(en) waarom de OAuth Client heeft gevraagd.
Toelichting
Lijsten
10a. MedMij Registratie en elke PGO Server implementeren de use cases UC Opvragen ZAL en UC Opvragen ASL (optioneel voor PGO Server) met de use case-implementaties UCI Opvragen ZAL en UCI Opvragen ASL, door middel van het bepaalde inzake de interfacebeschrijvingen op ASL-, GNL-, OCL- en ZAL-interface. Zij gebruiken hiertoe de betreffende stroomdiagrammen.
10b. Wanneer de betreffende UC wordt geïmplementeerd, dan betrekt PGO Server minstens elke vijftien minuten (900 seconden) de meest recente ZAL-implementatie en ASL-implementatie van de MedMij Registratie.
10c. PGO Server valideert elke nieuw verkregen ZAL-implementatie en ASL-implementatie tegen de bijbehorende XML-schema. De XML-schema's zijn een technische implementatie van het MedMij-metamodel.
Beveiliging
13. In het gegevensverkeer voor alle, in het afsprakenstelsel beschreven, use case-implementaties maken betrokken rollen gebruik van de functies Versleuteling, Server Authentication en Server Authorization, volgens het bepaalde op de Netwerk-laag.
Applicatie - Interfaces
Interfaces en use cases
Op deze pagina's staan de verantwoordelijkheden die horen bij de interfaces in het MedMij Afsprakenstelsel. In elke use case-implementatie wordt gebruik gemaakt van één of meer van deze interfaces. Onderstaande tabel laat zien welke use case-implementaties welk interface gebruiken.
hoofdfunctie | Regie | Uitwisseling | Coördinatie | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
interface | user interface | authorization interface | token interface | subscription interface | subscription notification interface | resource notification interface | resource interface | GNL interface | OCL interface | ZAL interface | ASL interface |
geboden door rol | Authorization Server | Subscription Server | Notification Server | Resource Server | MedMij Registratie | ||||||
UCI Verzamelen | X | X | X | X | |||||||
UCI Delen | X | X | X | X | |||||||
UCI Abonneren | X | X | X | X | |||||||
UCI Notificeren | X | X | |||||||||
UCI Opvragen GNL | X | ||||||||||
UCI Opvragen OCL | X | ||||||||||
UCI Opvragen ZAL | X | ||||||||||
UCI Opvragen ASL | X |
Verantwoordelijkheden over de adressering van deze interfaces komen hieronder aan de orde. Verantwoordelijkheden voor de specifieke interfaces zijn opgenomen in specifieke subpagina's, die klikbaar zijn in bovenstaande tabel.
Adressering
2b. Voor het samenstellen van alle adressen van het authorization request, het token request en het subscription request, betrekt de OAuth Client de eerste onderdelen van de URI, namelijk host
en path
, uit de Zorgaanbiederslijst op basis van de van toepassing zijnde Zorgaanbieder, Interfaceversie en Gegevensdienst. Andere elementen van de algemene URI-syntax, zoals user
, password
, query
en fragment
, zijn afwezig in de adressen. Bij het samenstellen van de adressen van het authorization request en het token request wordt, indien de scope van het authorization request meerdere Gegevensdiensten bevat, verplicht gebruik gemaakt van de Autorisatieserverlijst.
2c. Voor het samenstellen van alle adressen van het resource request, betrekt de OAuth Client de base url (het onderdeel van de URI dat is aangeduid als [base]
in de specificaties van de Transactie die behoort bij de van toepassing zijnde combinatie Zorgaanbieder, Gegevensdienst en Systeemrol), uit de Zorgaanbiederslijst, op basis van de van toepassing zijnde Zorgaanbieder, Interfaceversie, Gegevensdienst en Systeemrol. Wanneer de specificaties een request identificeren maar geen [base]
aanduiden, mag de OAuth Client het resource request alleen indienen als de volledige, absolute URI van het resource request begint met de volledige ResourceEndpointuri zoals die is verkregen uit de Zorgaanbiederslijst, op basis van de van toepassing zijnde Zorgaanbieder, Interfaceversie, Gegevensdienst en Systeemrol.
2d. De adressen voor de subscription notification en de resource notification betrekt de Notification Client uit de OAuth Client List, op basis van de van toepassing zijnde OAuth Client en Gegevensdienst.
3. MedMij Registratie wordt in UCI Opvragen ZAL, UCI Opvragen ASL, UCI Opvragen OCL en UCI Opvragen GNL geadresseerd met de hostname stelselnode.medmij.nl
.
Applicatie - Interfaces - User interface (Autorisatieserver)
2a. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "autoriseer" in UCI Verzamelen staat gespecificeerd op de pagina Toestemmingsverklaring. Daarbij geldt dat:
- de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (
NaamZorgaanbieder
) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder; - de gebruikersvriendelijke weergave van de Gegevensdienst (
NaamGegevensdienst
) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen; - de gebruikersvriendelijke weergave van de identiteit van de Uitgever (
NaamLeverancierPGO
) wordt betrokken uit de OAuth Client List, op basis van deredirect_uri
(van OAuth) die in stap 1 is verkregen; - indien de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen meer dan één Gegevensdienst bevat en de Zorgaanbieder tenminste één, maar niet alle gevraagde Gegevensdiensten beschikbaar stelt aan de Persoon, dan dient deze situatie te worden getoond aan de Persoon, op de wijze zoals staat gespecificeerd op de pagina Toestemmingsverklaring.
Applicatie - Interfaces - Authorization interface
1a. De parameters in de authorization request worden als volgt gevuld:
parameter | vulling | toelichting |
---|---|---|
parameter | vulling | toelichting |
| letterlijke waarde code | Dit is het gevolg van verantwoordelijkheid 4 op de Applicatielaag. |
| de hostname, die in de OAuth Client List is opgenomen, van de Node van de OAuth Client die de authorization request doet | |
|
| 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. |
| abonnementsdeel:
gegevensdienstdeel:
| De scope kan worden gevuld met:
Indien de scope bestaat uit meerdere gegevensdienstdelen, dan dienen deze delen betrekking te hebben op dezelfde Zorgaanbieder. Het abonnementsdeel wordt gebruikt voor het aangaan, verlengen of beëindigen van een Abonnement. Als de gevraagde duur van het Abonnement Een gegevensdienstdeel wordt gebruikt om aan te geven welke Gegevensdienst wordt aangevraagd bij welke Zorgaanbieder, of om aan te geven op welke Gegevensdienst en Zorgaanbieder het abonnementsdeel van de scope betrekking heeft.
Er worden geen andere scopes of onderdelen van scopes opgenomen dan de hier genoemde. Voorbeelden van syntactisch juiste scopes zijn:
|
|
| 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 |
2b. Vervolgens verifieert de Authorization Server dat:
- deze GegevensdienstId voorkomt bij de betreffende
client_id
op de OAuth Client List; - optioneel: de gevraagde set van GegevensdienstId's voorkomt bij de betreffende
client_id
op de OAuth Client List; - zij namens deze Zorgaanbieder deze Gegevensdienst ontsluit, in overeenstemming met de gepubliceerde Zorgaanbiederslijst;
- optioneel: zij namens deze Zorgaanbieder deze set van Gegevensdiensten ontsluit, in overeenstemming met de gepubliceerde Autorisatieserverslijst;
- 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;
- >> inspringen > de waarde van de duur parameter in het request de waarde heeft van
0
of een waarde groter dan0
die kleiner of gelijk is aan de maximale duur van het Abonnement zoals de betreffende Zorgaanbieder deze aanbiedt.
- bij de betreffende
Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid 6.
Verificatie van erkenning op Gegevensdienst
6. 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 Client uit, 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 1a. Deze situatie kan ook optreden wanneer een PGO Server meerdere gegevensdienstdelen opneemt in de scope van een authorization request, terwijl de Authorization Server dit niet ondersteunt. | Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Zorggebruiker daarover. | conform OAuth 2.0-specificatie, par. 4.1.2.1, met de daar genoemde, zo specifiek mogelijke, toepasselijke error code | ||
Authorization interface 2 | UC Verzamelen 2 UC Delen 2 UC Abonneren 2 | Authorization Server kan de identiteit van de Zorggebruiker niet vaststellen. | Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Zorggebruiker 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:
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 Zorggebruiker hierover. | conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied , met in de error description "Authorization failed. " |
Applicatie - Interfaces - Token interface
2. De parameters in de access token response worden als volgt gevuld:
parameter | vulling | toelichting |
---|---|---|
| Het hiermee uitgegeven access token. | |
token_type | letterlijke waarde "Bearer" | |
| 900 | Conform verantwoordelijkheid 7 op de Applicatie-laag. |
| niet gebruikt | Conform verantwoordelijkheid 7 op de Applicatie-laag. |
scope | Conform sectie 5.1 van de OAuth 2.0-specificatie. Er gelden hierop een aantal toevoegingen. Verplicht indien het authorization request verzocht om het gebruik van meerdere Gegevensdiensten. In dat geval is de scope-parameter gelijk aan het door de Autorisatieserver daadwerkelijk toegekende deel van de gevraagde scope. Verplicht indien het authorization request verzocht om een Abonnement. In dat geval is de
|
Applicatie - Interfaces - GNL-, OCL-, ASL- en ZAL-interface
1. De URI van de:
- Zorgaanbiederslijst is
https://stelselnode.medmij.nl/MedMij_Zorgaanbiederslijst.xml?api=1.3.0
- Autorisatieserverslijst is
https://stelselnode.medmij.nl/MedMij_Autorisatieserverslijst.xml?api=1.4.0
- OAuthclientlist is
https://stelselnode.medmij.nl/MedMij_OAuthclientlist.xml?api=1.3.0
- Gegevensdienstnamenlijst is
https://stelselnode.medmij.nl/MedMij_Gegevensdienstnamenlijst.xml?api=1.3.0
Versionering van de lijst-interfaces
Binnen het MedMij Afsprakenstelsel hebben de lijst-interfaces een versienummer. Dat maakt het mogelijk om meerdere versies van deze interfaces tegelijkertijd in productie te hebben. De versies worden, vanaf release 1.1.2, van elkaar onderscheiden door een query-parameter in de URI.
Het versienummer is identiek aan dat van de betreffende release. Opeenvolgende versies van de lijst-interfaces kunnen daarom inhoudelijk identiek zijn.
2. Het aandeel van MedMij Registratie in elk van de use case-implementaties UCI Opvragen ZAL, UCI Opvragen ASL, UCI Opvragen OCL en UCI Opvragen GNL is voor minstens 99,9% van de tijd beschikbaar. MedMij Beheer laat, na het niet beschikbaar raken van bedoelde aandeel, maximaal acht uren (480 minuten) verstrijken voordat het weer beschikbaar is.
4. Ingeval MedMij Registratie in UCI Opvragen ZAL, UCI Opvragen ASL, UCI Opvragen OCL en/of UCI Opvragen GNL niet beschikbaar is, mogen betreffende opvragers gedurende maximaal 10 uur gebruik maken van het meest recente exemplaar van de betreffende lijst in de cache.
Applicatie - Use case-implementaties
Deze pagina groepeert de pagina's van de verschillende use case-implementaties.
Applicatie - Use case-implementaties - UCI Opvragen ZAL
Stroomdiagram
Toelichting
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
Beide interacties met MedMij Registratie zijn backchannel-verkeer.
>> Figuur toevoegen.
Informatiemodellen - Logische modellen
Lijsten
>> Toevoegen Autorisatieserverlijst
Informatiemodellen - XML-schema's
Schema's
>> Toevoegen Autorisatieserverlijst
Informatiemodellen - XML-bestanden voor lijsten
Toelichting
1. Het XML-bestand van de Zorgaanbiederslijst heet MedMij_Zorgaanbiederslijst.xml
. Het XML-bestand van de Autorisatieserverslijst heet MedMij_Autorisatieserverslijst.xml
. Het XML-bestand van de Whitelist heet MedMij_Whitelist.xml
. Het XML-bestand van de OAuth Client List heet MedMij_OAuthclientlist.xml
. Het XML-bestand van de Gegevensdienstnamen heet MedMij_Gegevensdienstnamenlijst.xml
. Het XML-bestand van de Catalogus heet MedMij_Catalogus.xml.
Communicatie - Toestemmingsverklaring
De toestemmingsverklaring en de toelichting daarop zijn verplichte teksten die de Dienstverlener zorgaanbieder dient voor te leggen aan de Persoon bij het ophalen van gezondheidsgegevens bij de Zorgaanbieder. Deze toestemmingsverklaring heeft betrekking op die gegevensuitwisseling. De verplichte toestemmingsverklaring volgt uit de Wet geneeskundige behandelingsovereenkomst (WGBO). De Zorgaanbieder is verplicht ervoor te zorgen dat ‘anderen’ dan de patiënt geen inlichtingen hebben over, inzage hebben in of een afschrift hebben van het medisch dossier, tenzij hiervoor toestemming is verleend. Binnen de MedMij afspraken verstrekt de Zorgaanbieder via de Dienstverlener zorgaanbieder gegevens aan de Dienstverlener persoon. Aangezien dit een 'andere' is dan de Persoon zelf, moet de Zorgaanbieder weten dat de persoon hiervoor toestemming heeft verleend. Bij de UC Verzamelen en de UC Abonneren staat beschreven hoe het proces rondom het geven van toestemming eruit ziet. De Dienstverlener zorgaanbieder implementeert de toestemmingsverklaring en toont deze aan de Persoon.
In de toestemmingsverklaring worden de gegevensdiensten genoemd waarop de toestemming betrekking heeft. Wanneer middels één interactie tussen de Persoon en de Dienstverlener zorgaanbieder wordt getracht om meerdere Gegevensdiensten tegelijk te verzamelen, dan kan het voorkomen dat een Zorgaanbieder sommige Gegevensdiensten wel beschikbaar stelt aan Persoon, maar andere Gegevensdiensten niet. Deze situatie wordt dan in de toestemmingverklaring benoemd.
Toestemmingsverklaring U geeft hierbij
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. |
>> Aanpassen HTML schermen.
Operationele processen
Registratieprocessen Zorgaanbiederslijst, Whitelist en OAuthclientlist
- Doel: De registratieprocessen voor de Zorgaanbiederslijst, Autorisatieserverslijst, Whitelist en OAuthclientlist hebben als doel de juiste informatie te verzamelen benodigd voor een goede operationele werking van het stelsel.
- Initiatie:
- Deelnemer dient een verzoek in bij Stichting MedMij om een entry in de Zorgaanbiederslijst, Autorisatieserverslijst, Whitelist of OAuthclientlist aan te maken, te wijzigen of te verwijderen.
- Triggers voor wijzigingen zijn per lijst verschillend:
- Whitelist:
- Deelnemer wil een node op het MedMij-netwerk gebruiken.
- Deelnemer wil een van haar eigen nodes niet meer op het MedMij-netwerk gebruiken.
- Whitelist:
- Zorgaanbiederslijst, Autorisatieserverslijst en Zorgaanbiederskoppellijst:
- Dienstverlener zorgaanbieder wil in het MedMij-netwerk kenbaar maken een Gegevensdienst namens een Zorgaanbieder te ontsluiten.
- Dienstverlener zorgaanbieder wil in het MedMij-netwerk kenbaar maken een Gegevensdienst namens een Zorgaanbieder niet meer te ontsluiten.
- Alleen Zorgaanbiederslijst en Autorisatieserverslijst:
- Dienstverlener zorgaanbieder wil een of meerdere endpoints bij een ZorgaanbiederGegevensdienst wijzigen.
- Dienstverlener zorgaanbieder wil een of meerdere Gegevensdiensten die namens een Zorgaanbieder worden ontsloten, richting Persoon kunnen combineren in één Toestemmingsverklaring.
- OAuthclientlist:
- Dienstverlener persoon wil een OAuthclient toevoegen.
- Dienstverlener persoon wil een OAuthclient verwijderen.
- Zorgaanbiederslijst, Autorisatieserverslijst en Zorgaanbiederskoppellijst:
- Afspraken over het proces:
- Deelnemer is verantwoordelijk voor het aanleveren van mutaties voor de Zorgaanbiederslijst, Autorisatieserverslijst, WhiteList en OAuthclientlist. Aanvullend, bovenop de gegevens die zijn vereist voor de Zorgaanbiederslijst, dient voor het samenstellen van een Autorisatieserverlijst door Stichting MedMij, door de Dienstverlener zorgaanbieder, per interfaceversie, te worden aangegeven welke Gegevensdiensten die namens een Zorgaanbieder worden ontsloten, richting Persoon mogen worden gecombineerd in één Toestemmingsverklaring.
- Bij het kenbaar maken van het ontsluiten van een Gegevensdienst voor een Zorgaanbieder overlegt de Dienstverlener zorgaanbieder de volgende verklaring van de Zorgaanbieder:
"Ik, [Zorgaanbieder], verklaar onder de Zorgaanbiedersnaam [Zorgaanbiedersnaam] één of meerdere Gegevensdiensten aan te willen bieden op het MedMij-netwerk, vanaf [ingangsdatum] en deze te laten ontsluiten door [Dienstverlener zorgaanbieder]. Tevens geef ik stichting MedMij toestemming de Gegevensdiensten die op enig moment onder Zorgaanbiedersnaam [Zorgaanbiedersnaam] worden aangeboden openbaar te publiceren." - Mutaties zijn gebonden aan de verantwoordelijkheden en regels zoals gespecificeerd in de Architectuur en technische specificaties, het Zorgaanbiedersnamenbeleid en OAuthclient-namenbeleid.
- Stichting MedMij neemt het verzoek in behandeling en is verantwoordelijk voor een check op integriteit.
- Valide mutaties worden in 95 procent van de gevallen door Stichting MedMij binnen 2 werkdagen verwerkt. Urgente mutaties krijgen daarbij voorrang. De mutatietijd voor urgente mutaties wordt in overleg met Stichting MedMij bepaald. Bij verwachte overschrijding van de (overeengekomen) verwerkingstijd, informeert Stichting MedMij de deelnemer hierover.
- Resultaat: Stichting MedMij heeft het betreffende register aangepast. De deelnemer wordt geïnformeerd over de doorgevoerde wijziging.
- Uitzonderingen: Een van de verantwoordelijkheden en regels in de Architectuur en technische specificaties wordt overtreden. Stichting MedMij vraagt de deelnemer om het verzoek aan te passen.
Actualiseren van Zorgaanbiederslijst, Zorgaanbiederkoppellijst en de OauthClientList bij publicatie nieuwe release
- Doel: Borgen dat in de Zorgaanbiederslijst, de Autorisatieserverslijst, de Zorgaanbiederkoppellijst en de OAuthclientlist alleen Interfaceversies voorkomen van actieve releases van het MedMij Afsprakenstelsel.
- Initiatie:
- Er komt een nieuwe release uit van het MedMij Afsprakenstelsel. Dat wil zeggen dat de tot dan toe verplichte release de status verouderd krijg.
- Afspraken over het proces:
- MedMij Beheer is verantwoordelijk voor het verwijderen van alle entries in de Zorgaanbiederslijst, de Autorisatieserverslijst, Zorgaanbiederkoppellijst en de OAuthClientList die horen bij een (zojuist) verouderde Interfaceversie.
- Resultaat: Stichting MedMij heeft de betreffende lijsten aangepast.
- Uitzonderingen: Geen.
Processen inzake gecontroleerde livegang
Toetreding tot een gecontroleerde livegang
- Doel: Het in de gelegenheid stellen van een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon toe te treden tot een bestaande gecontroleerde livegang conform Beleid inzake gecontroleerde livegang.
- Initiatie: Een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon wenst toe te treden tot een gecontroleerde livegang. De betreffende Dienstverlener moet gekwalificeerd zijn voor de origineel-Gegevensdienst van de gecontroleerde livegang. De Zorgaanbieder mag in de afgelopen drie maanden niet al betrokken zijn geweest bij een gecontroleerde livegang op deze origineel-Gegevensdienst.
- Afspraken over het proces:
- De MedMij Beheerorganisatie erkent de betreffende Dienstverlener op de kopie-Gegevensdienst, indien deze is gekwalificeerd op de origineel-Gegevensdienst.
- Betrokken Dienstverlener laat zich inzake de kopie-Gegevensdienst op gebruikelijke wijze registreren in de Zorgaanbiederslijst, de Autorisatieserverslijst, de OAuth Client List en de Whitelist.
- Resultaat: De betreffende partij is operationeel in de gecontroleerde livegang, tenzij niet aan de toepasselijke eisen is voldaan.
- Uitzonderingen: -
Uittreding uit een gecontroleerde livegang
- Doel: Het in de gelegenheid stellen van een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon uit te treden uit een bestaande gecontroleerde livegang conform Beleid inzake gecontroleerde livegang.
- Initiatie: Een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon wenst uit te treden uit een gecontroleerde livegang. Bij een Zorgaanbieder kan dat gepaard gaan met een wens tot promotie tot het gewone live MedMij-netwerk.
- Afspraken over het proces:
- De MedMij Beheerorganisatie beëindigt de erkenning van betreffende Dienstverlener op de kopie-Gegevensdienst.
- De MedMij Beheerorganisatie verwijdert de op de betreffende partij betrekking hebbende elementen uit de Zorgaanbiederslijst, de Autorisatieserverslijst, de OAuth Client List en de Whitelist.
- Indien het een Zorgaanbieder betreft die wens te promoveren, start de MedMij Beheerorganisatie het proces 'Promotie uit een gecontroleerde livegang'.
- Mocht de uitreder de laatste Zorgaanbieder, Dienstverlener zorgaanbieder of Dienstverlener persoon zijn in de gecontroleerde livegang, start hij het proces 'Beëindiging van een gecontroleerde livegang'.
- Resultaat: De betreffende partij is niet meer operationeel in de gecontroleerde livegang.
- Uitzonderingen: -
Promotie uit een gecontroleerde livegang
- Doel: Het live gaan van een Zorgaanbieder, met diens Dienstverlener zorgaanbieder, in het MedMij-netwerk, vanuit een gecontroleerde livegang, conform Beleid inzake gecontroleerde livegang.
- Initiatie: Een Zorgaanbieder (met diens Dienstverlener zorgaanbieder) geven bij uitreding uit de gecontroleerde livegang aan te willen promoveren.
- Afspraken over het proces:
- De MedMij Beheerorganisatie vervangt in de Zorgaanbiederslijst en in de Autorisatieserverslijst die elementen die betrekking hebben op de betreffende Zorgaanbieder-kopie-Gegevensdienst-combinaties de kopie-Gegevensdienst door de origineel-Gegevensdienst.
- Resultaat: De betreffende Zorgaanbieder is live met de betreffende Gegevensdienst.
- Uitzonderingen: -
Beëindiging van een gecontroleerde livegang
- Doel: Het beëindigen van de gelegenheid van een groep Deelnemers tot het uitvoeren van een gecontroleerde livegang conform Beleid inzake gecontroleerde livegang.
- Initiatie: Wanneer één van de volgende gebeurtenissen zich voordoet:
- de looptijd van de kopie-Gegevensdienst verstrijkt, al dan niet na een eenmalige verlenging;
- de laatste Zorgaanbieder, Dienstverlener zorgaanbieder of Dienstverlener persoon treedt uit uit de gecontroleerde livegang;