Document toolboxDocument toolbox

MMOS-64 Na publicatie van patch 2.0.1 zijn 'broken links' geconstateerd

Samenvatting

Waarom is deze RFC nodig?

Na publicatie van patch 2.0.1 zijn 'broken links' geconstateerd.

Oplossingsrichting

Broken links repareren

Changelog tekst

Op de pagina’s “Metamodel”, “Authorization interface”, “Authorization Interface, Abonneren”, “Schermen (User Interface), Core”, “Communicatie”, “OAuthclient-namenbeleid”, “Verantwoordelijkheden, Abonneren” en “Coördinatie, regie en uitwisseling” zijn kapotte links herstelt. Verder zijn op de pagina’s “Metamodel” en “Communicatie” wat regels verwijdert die niet langer van toepassing waren.

RACI

  • Responsible:

    • Team ontwikkeling

  • Accountable:

    • $RFC_RACI_Accountable

  • Consulted

    • Ontwikkelteam (ontwikkeling@medmij.nl)

    • Security Management (secmgt@medmij.nl)

    • Acceptatie (acceptatie@medmij.nl)

    • Stelselregie

    • Deelnemers (Expertgroepsessie)

  • Informed

    • Communicatie

    • Loket (info@medmij.nl)

    • Leveranciersmanagement



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

Let op: afhankelijk van het publicatiemoment (na 20 sep?) moet deze wijziging op de Confluence CLOUD omgeving worden uitgevoerd

Locatie

Oude tekst

Nieuwe Tekst

In te voegen links bij paarse woorden

Opmerkingen

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 Nodes van Deelnemers die Dienstverlener persoon zijn (beter gezegd: voor de OAuth Clients op de applicatielaag gedurende de autorisatiefase van Verzamelen en Delen) bevat de OAuthclientlist gebruikersvriendelijke namen (Organisatienaam), om gebruikt te worden in de toestemmingsverklaring en de bevestigingsverklaring.

 

 

 

 

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.

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 afsprakenstelsel

De 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 afsprakenstelsel

De 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:
o.OAuthclientOrganisatienaam voldoet aan het OAuthclient-namenbeleid

Voor elke OAuthclient o geldt:
o.OAuthclientOrganisatienaam voldoet aan het OAuthclient-namenbeleid.

 

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:

  • wat de gebruikersvriendelijke namen zijn die voor de Dienstverleners persoon worden gebruikt in de Toestemmingsverklaring, de Bevestigingsverklaring;

 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 GebruikersvoorlichtingToestemmingsverklaring en Bevestigingsverklaring.

 

 

Communicatie beschrijft de afspraken over het Merkgebruik en het hanteren van de verplichte Gebruikersvoorlichting., Toestemmingsverklaring en Bevestigingsverklaring.

 

 

 

 

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 Notificeren aanbiedt, aan Aanbieder een geautomatiseerde rol Notification Server ter beschikking, waarop de Aanbieder Notificaties kan aanbieden

 

 

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 , de Bevestigingsverklaring en de Notificatie van Persoon;

 

 





Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )



Principe's

Principe



Principe



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

 

Dienstverleners concurreren op de functionaliteiten

 

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Dienstverleners zijn aanspreekbaar door de gebruiker

14 Uitwisseling is een keuze

De persoon wisselt gegevens uit met de zorgaanbieder

15 Het MedMij-netwerk is gebruiksrechten-neutraal

MedMij spreekt alleen af wat nodig is

16 De burger regisseert zijn gezondheidsinformatie als uitgever

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

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

Dreiging

Kans

Impact

DreigingsID (intern)

Maatregelen

N.v.t.

N.v.t.

N.v.t.

N.v.t.

N.v.t.

Bijlagen

  File Modified

PNG File afbeelding-20230831-101947.png

Aug 31, 2023 by Marlotte Pannekoek

PNG File afbeelding-20230831-122130.png

Aug 31, 2023 by Marlotte Pannekoek

Goedkeuring

Beoordelaar

Datum

Toelichting

Beoordelaar

Datum

Toelichting

Beoordelaar

Datum

Toelichting

Beoordelaar

Datum

Toelichting

Productmanager Stichting MedMij





Productmanager Beheerorganisatie





Leadarchitect Stichting MedMij





Leadarchitect Beheerorganisatie





Ontwerpteam











Deelnemersraad





Eigenaarsraad