Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...

  •  MedMij Afsprakenstelsel versie 2.0.2
Note

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

Metamodel


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:

Coördinatie, regie en uitwisseling

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;

Toestemmingsverklaring, Core

Bevestigingsverklaring Delen, Core

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 derolbeschrijvingen binnen de core.

Rollen, 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 MedMijNodes van Deelnemers die Dienstverlenerpersoon 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

Architectuur en technische specificaties

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.

https://datatracker.ietf.org/doc/html/rfc3696#section-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.

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.

OAuthclient-namenbeleid

Conform toepasselijk Zorgaanbiedersnamenbeleid.

Conform toepasselijk Zorgaanbiedersnamenbeleid.

Aanbiedersnamenbeleid

Authorization interface

Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoonom 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 Persoonom 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.

Token interface

Authorization interface, Abonneren

Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoonom 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 Persoonom 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 deToestemmingsverklaring.

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).

https://datatracker.ietf.org/doc/html/rfc7918

https://datatracker.ietf.org/doc/html/rfc7918

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

Schermen (User interface), Core

<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

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

OAuthclient-namenbeleid

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).

Verantwoordelijkheden, Abonneren

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 Notificerenaanbiedt, 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.

Verantwoordelijkheden, Core

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 Aanbiedersuitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd in combinatie met een Resource Server en/of Subscription Server.

Verantwoordelijkheden, Core

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;

Coördinatie, regie en uitwisseling

Schermen (User interface), Core

...