Samenvatting
Waarom is deze RFC nodig? | Na publicatie van patch 2.0.1 zijn 'broken links' geconstateerd. |
|---|---|
Oplossingsrichting | Broken links repareren |
RACI |
|
Aanpassing van | MedMij Afsprakenstelsel versie 2.0.2 |
Impact op rollen | N.v.t. |
Impact op beheer | N.v.t. |
Impact op RnA | N.v.t. |
Impact op Acceptatie | N.v.t. |
PIA noodzakelijk | N.v.t. |
Gerelateerd aan (Andere RFCs, PIM issues) | N.v.t. |
Implementatietermijn | Volgende release |
Motivatie verkorte RFC procedure (patch) | N.v.t. |
Uitwerking
- MedMij Afsprakenstelsel versie 2.0.2
Locatie | Oude tekst | Nieuwe Tekst | In te voegen links bij paarse woorden | Opmerkingen |
|---|---|---|---|---|
Het metamodel is gericht op het samenhangend beschrijven van begrippen en relaties die worden gebruikt in de hoofdfunctie Coördinatie van MedMij. Het metamodel is allereerst de basis voor de structuur van: | Het metamodel is gericht op het samenhangend beschrijven van begrippen en relaties die worden gebruikt in de hoofdfunctie Coördinatie van MedMij. Het metamodel is allereerst de basis voor de structuur van: | |||
een gebruikersvriendelijke naam van de OAuth Client kan vinden om te gebruiken in de toestemmingsverklaring danwel de bevestigingsverklaring; | een gebruikersvriendelijke naam van de OAuth Client kan vinden om te gebruiken in de toestemmingsverklaring danwel de bevestigingsverklaring; | Aanname verplaatsing toestemmingsverklaring naar schermen Aanname verplaatsing bevestigingsverklaring naar schermen met toevoeging van delen aan de titel. | ||
Deze komen overeen met de respectievelijke rollen Dienstverlener Persoon en Dienstverlener Zorgaanbieder op de juridische laag. | Deze komen overeen met de respectievelijke rollen Dienstverlener Persoon en Dienstverlener Zorgaanbieder beschreven in de rolbeschrijvingen binnen de core. | |||
Voor de MedMijNodes van Deelnemers die Dienstverlenerpersoon zijn (beter gezegd: voor de OAuth Clients op de applicatielaag gedurende de autorisatiefase van UCI Verzamelen en UCI Delen) bevat de OAuthclientlist gebruikersvriendelijke namen (Organisatienaam), om gebruikt te worden in de toestemmingsverklaring en de bevestigingsverklaring. | Voor de MedMij | Met casper overlegt, zin mag weg. | ||
De eisen aan al deze componenten en de wijzen van samenstellen tot de URI's staat beschreven op de Interface-pagina. |
|
| Met casper overlegt, zin mag weg. | |
Lagen in het afsprakenstelselDe klassen in het metamodel horen bij de verschillende lagen in de architectuur van het afsprakenstelsel. De betreffende laag is aangegeven door de inkleuringen van de klassen | Lagen in het afsprakenstelselDe klassen in het metamodel horen bij de verschillende lagen in de architectuur van het afsprakenstelsel. De betreffende laag is aangegeven door de inkleuringen van de klassen | |||
MedMij-zorgaanbiedernamen voor Zorgaanbieders, zoals beschreven in verantwoordelijkheid 13 op de Processen-en-Informatielaag; | MedMij-zorgaanbiedernamen voor Zorgaanbieders, zoals beschreven in verantwoordelijkheid core.alst.102; | |||
De hostname van een Node bevat een domeinnaam die een fully-qualified domain name is, conform RFC3696, sectie 2. | De hostname van een Node bevat een domeinnaam die een fully-qualified domain name is, conform RFC3696, sectie 2. | |||
Voor elke OAuthclient o geldt: | Voor elke OAuthclient o geldt: | |||
Zie adresseringsverantwoordelijkheden op de Interfaces-pagina. | Zie adresseringsverantwoordelijkheden binnen de Core. | tabel rij Endpointpath | ||
Zie adresseringsverantwoordelijkheden op de Interfaces-pagina. | Zie adresseringsverantwoordelijkheden binnen de Core. | Tabel rij Hostname | ||
Conform toepasselijk Oauthclient-namenbeleid. | Conform toepasselijk Oauthclient-namenbeleid. | |||
Conform toepasselijk Zorgaanbiedersnamenbeleid. | Conform toepasselijk Zorgaanbiedersnamenbeleid. | |||
Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoon om een Toestemmingsverklaring (in het geval van Verzamelen) of een Bevestigingsverklaring (in het geval van Delen), volgens het daaromtrent bepaalde op de pagina User interface (Autorisatieserver), volgens de standaard OAuth 2.0, op de wijze waarop deze in het MedMij Afsprakenstelsel wordt toegepast. | Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoon om een Toestemmingsverklaring (in het geval van Verzamelen) of een Bevestigingsverklaring (in het geval van Delen), volgens het daaromtrent bepaalde op de pagina Schermen (User interface), volgens de standaard OAuth 2.0, op de wijze waarop deze in het MedMij Afsprakenstelsel wordt toegepast. | Aanname gemaakt dat om de schermen gevraagd werd | ||
Zie ook verantwoordelijkheid core.tknint.206. | Zie ook verantwoordelijkheid core.tknint.206. | |||
Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoon om een Toestemmingsverklaring (in het geval van Verzamelen of Abonneren) of een Bevestigingsverklaring (in het geval van Delen), volgens het daaromtrent bepaalde op de pagina User interface (Autorisatieserver), volgens de standaard OAuth 2.0, op de wijze waarop deze in het MedMij Afsprakenstelsel wordt toegepast. | Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoon om een Toestemmingsverklaring (in het geval van Verzamelen of Abonneren) of een Bevestigingsverklaring (in het geval van Delen), volgens het daaromtrent bepaalde op de pagina Schermen (User interface), volgens de standaard OAuth 2.0, op de wijze waarop deze in het MedMij Afsprakenstelsel wordt toegepast. | |||
MedMij Beheer beheert en publiceert een actuele OAuth Client List, namens de deelnemende Dienstverleners persoon. De gepubliceerde OAuth Client List bevat steeds en slechts alle actuele entries, en beschrijft van elke OAuth Client:
Toelichting De OAuth Client List bevat dus geen namen voor Dienstverleners aanbieder. Dat is niet nodig, omdat deze niet voorkomen in de Toestemmingsverklaring. | MedMij Beheer beheert en publiceert een actuele OAuth Client List, namens de deelnemende Dienstverleners persoon. De gepubliceerde OAuth Client List bevat steeds en slechts alle actuele entries, en beschrijft van elke OAuth Client:
Toelichting De OAuth Client List bevat dus geen namen voor Dienstverleners aanbieder. Dat is niet nodig, omdat deze niet voorkomen in de Toestemmingsverklaring. | |||
het kennisnemen van de naam van de Dienstverlener persoon die moet verschijnen in de Toestemmingsverklaring en de Bevestigingsverklaring. | het kennisnemen van de naam van de Dienstverlener persoon die moet verschijnen in de Toestemmingsverklaring en de Bevestigingsverklaring. | |||
De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling. | De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling. | Oauth authorization server staat niet op pagina maar wel in afbeelding → er is een ticket voor aangemaakt om dit aan te passen tekst. | ||
Gebruik van TLS False Start is verboden. Toelichting Gebruik van TLS False Start is verboden om te voorkomen dat er inhoudelijke verwerking plaatsvindt van uitgewisselde gegevens voordat voor de betreffende uitwisseling authenticatie en autorisatie geslaagd zijn (zie onder). | Gebruik van TLS False Start is verboden. Toelichting Gebruik van TLS False Start is verboden om te voorkomen dat er inhoudelijke verwerking plaatsvindt van uitgewisselde gegevens voordat voor de betreffende uitwisseling authenticatie en autorisatie geslaagd zijn (zie onder). | |||
De keuze voor de PKI-standaard past bij principe 19 van het MedMij Afsprakenstelsel. | De keuze voor de PKI-standaard past bij principe 19 van het MedMij Afsprakenstelsel. | Niet langer link gebruiken voor pki | ||
<Naam Aanbieder> en <Naam PGO> zijn placeholders, zoals opgenomen in de Toestemmingsverklaring en de Bevestigingsverklaring. | <Naam Aanbieder> en <Naam PGO> zijn placeholders, zoals opgenomen in de Toestemmingsverklaring en de Bevestigingsverklaring. | |||
Communicatie beschrijft de afspraken over het Merkgebruik en het hanteren van de verplichte Gebruikersvoorlichting, Toestemmingsverklaring en Bevestigingsverklaring. | Communicatie beschrijft de afspraken over het Merkgebruik en het hanteren van de verplichte Gebruikersvoorlichting. | Links niet langer relevant voor deze pagina. Verwijderen | ||
In de OAuth-flow krijgt de Persoon een verzoek om toestemming voor de gegevensuitwisseling tussen een Aanbieder en de OAuthclient van de Dienstverlener persoon (zie Toestemmingsverklaring). | In de OAuth-flow krijgt de Persoon een verzoek om toestemming voor de gegevensuitwisseling tussen een Aanbieder en de OAuthclient van de Dienstverlener persoon (zie Toestemmingsverklaring). | |||
Dienstverlener persoon stelt, indien deze de functie Notificeren aanbiedt, aan Aanbieder een geautomatiseerde rol Notification Server ter beschikking, waarop de Aanbieder Notificaties kan aanbieden | Dienstverlener persoon stelt, indien deze de functie Abonneren | |||
Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd in combinatie met een Resource Server en/of Subscription Server. | Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd in combinatie met een Resource Server en/of Subscription Server. | |||
Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd in combinatie met een Resource Server en/of Subscription Server. | Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd in combinatie met een Resource Server en/of Subscription Server. | |||
wat de gebruikersvriendelijke namen zijn die voor de Dienstverleners persoon worden gebruikt in de Toestemmingsverklaring , de Bevestigingsverklaring en de Notificatie van Persoon; | wat de gebruikersvriendelijke namen zijn die voor de Dienstverleners persoon worden gebruikt in de Toestemmingsverklaring | |||
|
Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )
Principe's
Principe | Principe | ||
|---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | 11 Stelselfuncties worden vanaf de start ingevuld | ||
2 Dienstverleners zijn transparant over de gegevensdiensten | 12 Het afsprakenstelsel is een groeimodel | ||
3 Dienstverleners concurreren op de functionaliteiten | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | ||
4 Dienstverleners zijn aanspreekbaar door de gebruiker | 14 Uitwisseling is een keuze | ||
5 De persoon wisselt gegevens uit met de zorgaanbieder | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | ||
6 MedMij spreekt alleen af wat nodig is | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | ||
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | ||
9 De dienstverleners zijn deelnemers van het afsprakenstelsel | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | ||
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | ||
Toelichting | |||
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 |
|---|---|---|---|---|
N.v.t. | N.v.t. | N.v.t. | N.v.t. | N.v.t. |
Bijlagen
Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
|---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |