Document toolboxDocument toolbox

RFC0035 Verzamel RFC

Samenvatting

Waarom is deze RFC nodig?

Bij het opstellen van diverse RFC's kwamen kleine foutjes en inconsistenties in het Afsprakenstelsel boven. Deze RFC is de verzamelplaats voor correcties op deze vondsten.

Oplossingsrichting

Bijwerken en corrigeren.

Aanpassing van

Afsprakenstelsel

Impact op rollen

Geen (voorwaarde, anders mag deze correctie niet geplaatst).

Impact op beheer

Geen (voorwaarde, anders mag deze correctie niet geplaatst).

Impact op RnA

Geen (voorwaarde, anders mag deze correctie niet geplaatst).

Impact op Acceptatie

Geen (voorwaarde, anders mag deze correctie niet geplaatst).

Gerelateerd aan (Andere RFCs, PIM issues)


Eigenaar
Implementatietermijn

1.3.0

Motivatie verkorte RFC procedure (patch)


Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
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 gegevensdiensten 

Positief

12 Het afsprakenstelsel is een groeimodel

Positief

Dienstverleners concurreren op de functionaliteiten

Positief

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

Positief

Dienstverleners zijn aanspreekbaar door de gebruiker

Positief

14 Uitwisseling is een keuze

Positief

De persoon wisselt gegevens uit met de zorgaanbieder

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Positief

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Positief

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Positief

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Positief

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

Toevoegingen in paars. Verwijderingen doorgehaald.

Niet alle items betreffen wijzigingen, sommige zijn correcties die vooral van doen hebben met de publicatie.

Item: aanduiding van incorrecte vermelding bij Interfaceversie_ZAL in herkomsttabel

Eigenaar: Former user (Deleted)

Aanpassing

Toevoegen infobox onder de 'herkomsttabel' op de pagina Logische modellen:

Known issue

De klasse Interfaceversie_ZAL in het logisch model heeft een corresponderende conceptuele klasse "ZorgaanbiederInterfaceversie" die nog niet is opgenomen in het metamodel. Deze klasse is een associatie van de klassen "Zorgaanbieder" en "Interfaceversie".

Toelichting

Dit verdient een zuivere correctie. Vermelding als known issue zorgt voor helderheid over bedoeling.

Item: corrigeren herkomst Interfaceversie_OCL

Eigenaar: Former user (Deleted)

Aanpassing

In de 'herkomsttabel' op de pagina Logische modellen:

Klasse in logisch modelHerkomstklasse in metamodel
Interfaceversie_OCL

Interfaceversie

OAuthclientInterfaceversie

Toelichting

Zuivere correctie.

Item: Aanpassingen van de diagrammen

Eigenaar: Casper van der Harst

Aanpassingen

Voor RFC0030 en RFC0019 zijn wijzigingen doorgevoerd in de diagrammen van de UC's en de UCI's. Daarnaast zijn wat oneffenheden gladgestreken. Zie 1.3.0, Diagrammen.

Item: publicatie Catalogus loskoppelen van publicatie release afsprakenset

Eigenaar: Former user (Deleted)

Aanpassing

De Catalogus behoeft een eigen 'space' op Confluence. Vanuit de spaces van het MedMij Afsprakenstelsel, die geversioneerd zijn op basis van het releasenummer van de afsprakenset die in de space is gepubliceerd, kan dan een verwijzing worden opgenomen naar deze nieuwe space.

Toelichting

Opheffen redundantie. De Catalogus kent een eigen releasecyclus.

Item: uitdunnen toelichting XML-schema's

Eigenaar: Former user (Deleted)

Aanpassing
Pagina XML-schema's

Bovendien zijn XML-schema's en XML-bestanden serieel. Dat wil zeggen dat in de vertaling vanuit het logische model de klassen achter elkaar geplaatst moeten worden zonder hun diagrammatische ordening in het logische model te laten verdwijnen. Een compositierelatie in het logische model wordt een nesting in het XML-schema. Om de achter elkaar geplaatste modelelementen onderling te kunnen scheiden, zowel in het XML-schema als in de XML-instantie, en om de elementen te voorzien van meta-informatie, worden in XML tags gebruikt.

      • Elk van de logische klassen, behalve de klasse die dienst doet als 'root', wordt afzonderlijk gedefinieerd als complexType in XML Schema, zodat hergebruik binnen het XML-schema mogelijk is.
      • Elk van de basisklassen wordt afzonderlijk gedefinieerd als  simpleType  in XML Schema, zodat hergebruik binnen het XML-schema mogelijk is.
  • Daar waar in het logische model sprake is van identifiers, is in het XML-schema een 'uniqueness constraint' opgenomen.

De prefixes voor de namespaces worden omwille van de leesbaarheid van de XML-schema's zo kort mogelijk gehouden, bestaan altijd uit drie letters en zijn geheel in lowercase. Onderstaande tabel geeft weer bij welke lijst of rapport welke prefix wordt gebruikt.

Lijst of rapport

Prefix

Gegevensdienstnamenlijstgnl
OAuthclientlistocl
Whitelistwhl
Zorgaanbiederslijstzal
Beheerrapportbhr
Portabiliteitsrapportpbr

Voor uniqueness constraints wordt gebruikgemaakt van <xs:unique>. De (verplichte) naam van uniqueness constraints in XML wordt opgebouwd volgens Unieke_[naamKlasse]. Zo vertaalt de eigenschap van het attribuut Hostname van de klasse MedMijNode uit het logische model waartoe de whitelist behoort zich in een uniqueness constraint met de naam Unieke_MedMijNode. Er kan worden volstaan met de naam van de klasse (zonder de hiërarchische context), omdat klassenamen op grond van het  logische model uniek zijn. De naam van het attribuut hoeft niet te worden benoemd. Welke attributen tezamen de identiteit van een instantie van een klasse vormen is weergegeven in het logische model . Binnen <xs:unique> wordt enkel <xs:selector> gebruikt voor de XPath-expressie; <xs:field> wordt opgenomen (conform de XML-specificatie) maar leeggelaten (kent de vulling . (punt)). Dit is een eenvoudiger keuze dan wanneer een criterium voor de splitsing van de XPath-expressie over <xs:selector> en <xs:field> zou moeten worden gegeven.

Er wordt gebruikgemaakt van <xs:sequence> binnen alle complexTypes, niet van <xs:all> , omdat het zo mogelijk is om elementen vaker dan eenmaal te gebruiken. Dat is een eigenschap waar veel gebruik van wordt gemaakt; het is inherent aan het karakter van de lijsten en is relevant bij veel van de compositierelaties (die geen maximum-omvang van de verzameling kennen).

Basisklassen

Toelichting

De definitie van de basisklassen in het logische model is vertaald naar simpleTypes in XML-schema, die voortbouwen op een native XML-datatype en daar soms verdere restricties aan verbinden.

Merk op dat de patronen van Backchanneluri en Frontchanneluri identiek zijn.


Basisklasse

Basis (XML-datatype)

minLength

maxLength

pattern

Backchannelurixs:string

https://(([a-z0-9])([a-z0-9-])*(\.))+([a-z0-9])([a-z0-9-])*([a-z0-9])?(/[^?#/]+)*
DatumTijdxs:dateTime

.{20,}
Duurxsd:duration


Frontchannelurixs:string

https://(([a-z0-9])([a-z0-9-])*(\.))+([a-z0-9])([a-z0-9-])*([a-z0-9])?(/[^?#/]+)*
GegevensdienstIdxs:string130
Hostnamexs:string

(([a-z0-9])([a-z0-9-])*(\.))+([a-z0-9])([a-z0-9-])*([a-z0-9])
Nietnegatiefgetalxs:nonNegativeInteger


OAuthclientOrganisatienaamxs:string350
Positiefnummerxs:positiveInteger


Systeemrolcodexs:string130
Weergavenaamxs:string350
Zorgaanbiedernaamxs:string10287([a-z][0-9]{0,4})+((-|&amp;|\.)?([a-z][0-9]{0,4})+)*@medmij
Toelichting

De te schrappen delen op de pagina zijn voor de deelnemers niet relevant, en ook voor de beheerorganisatie is het niet nodig de betreffende ontwerpkeuzes te formaliseren omdat er geen noodzaak of maar een beperkt voordeel is de XML-schema's op die punten op een vergelijkbare manier op te bouwen. De huidige hoeveelheid tekst levert een beheerlast op (in RFC0023 Harmonisering Register van Informatiestandaarden en Catalogus: informatiemodellen wordt bijvoorbeeld afgeweken van een deel van de richtlijnen) en maakt de beschrijving van de afsprakenset minder toegankelijk.

Item: redundante Introductie-pagina

Eigenaar: Former user (Deleted)

Aanpassing

De '/wiki/spaces/MedMijAfsprakenstelsel120/overview' van de space en de pagina /wiki/spaces/MedMijAfsprakenstelsel120/pages/135103101 zijn nagenoeg identiek.

Toelichting

Zuivere correctie om ongewenste redundantie op te heffen.

Noot van eindredactie: een van de pagina's betrekt haar inhoud nu uit de andere. Daarmee is er geen redundantie meer vanuit beheerperspectief.

Item: deelnemers bieden Gegevensdiensten niet aan, maar ontsluiten ze

Eigenaar: Former user (Deleted)

Aanpassing
Begrippenlijst

Gegevensdiensttussen Persoonsdomein en ZorgaanbiedersdomeinEen gestandaardiseerde dienst voor gegevensuitwisseling met waarde voor de Gebruiker die door een Dienstverlener kan worden aangeboden ontsloten over het MedMij-netwerk. MedMij definieert welke gegevensdiensten over het MedMij-netwerk aangeboden mogen worden en biedt een faciliteit om het aanbod van de dienstverleners inzichtelijk te maken.
Toelichting

Zuivere correctie.

Item: dubbele regels

Eigenaar: Former user (Deleted)

Let op!

T.b.v. eindredactie: eerst deze verwerken. De betreffende regels worden namelijk ook inhoudelijk gewijzigd.

Aanpassing
Metamodel, tabel Invarianten

Er komen twee regels met invarianten voor instanties van de klasse ZorgaanbiederGegevensdienst voor, die duplicaten zijn. Deze regels moeten verwijderd worden.

Toelichting

Zuivere correctie.

Item: Registratie ResourceEndpoints

Eigenaar: Former user (Deleted)

Aanpassing
Metamodel, tabel Invarianten
ZorgaanbiederGegevensdienstSysteemrolInterfaceversieElke combinatie van een ZorgaanbiederGegevensdienstInterfaceversie
en een ZorgaanbiederGegevensdienstSysteemrol heeft ten hoogste precies
één ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.
ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder, een Gegevensdienst, een Interfaceversie en een Systeemrol het ResourceEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
Toelichting

Van de DVZA wordt in de praktijk verwacht dat per Zorgaanbieder-Gegevensdienst-Interfaceversie voor elke Systeemrol die hoort bij die Gegevensdienst een ResourceEndpoint wordt geregistreerd in de ZAL. De Informatiemodellen verplichten niet dat voor elke systeemrol een ResourceEndpoint wordt geregistreerd, maar dat is waarschijnlijk een omissie, want de registratieverplichting onder elke systeemrol is wel bedoeld. (De Informatiemodellen dwingen nu af dat er per Gegevensdienst voor ten minste één Systeemrol een ResourceEndpoint wordt geregistreerd.)

Item: Interfaceversie toevoegen aan ZorgaanbiederGegevensdienst en ZorgaanbiederGegevensdienstSysteemrol

Eigenaar: Former user (Deleted)

Aanpassingen
Metamodel, toelichting

Elke Zorgaanbieder kent bij elke ZorgaanbiederGegevensdienstInterfaceversie (die hij aanbiedt via een Dienstverlener Zorgaanbieder) één AuthorizationEndpoint en één TokenEndpoint en bij elke ZorgaanbiederGegevensdienstInterfaceversieSysteemrol daarbinnen één ResourceEndpoint.

Metamodel, tabel Invarianten
ZorgaanbiederGegevensdienstSysteemrolInterfaceversie(...)ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder, een Gegevensdienst, een Interfaceversie en een Systeemrol het ResourceEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding

ZorgaanbiederGegevensdienstInterfaceversie

Elke ZorgaanbiederGegevensdienstInterfaceversie heeft precies één AuthorizationEndpoint.ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder en, een Gegevensdienst en een Interfaceversie het AuthorizationEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
ZorgaanbiederGegevensdienstInterfaceversieElke ZorgaanbiederGegevensdienstInterfaceversie heeft precies één TokenEndpoint.ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder en, een Gegevensdienst en een Interfaceversie het TokenEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
Logisch model, tabel Verband met metamodel

Klasse in logisch model

Herkomstklasse in metamodel

SysteemrolZorgaanbiederGegevensdienstInterfaceversieSysteemrol
Toelichting

Zuivere correctie. De correctie op de pagina Interfaces is opgenomen in het item "URL-onderdelen in relatie tot endpoints in ZAL".

Item: Spelfout

Eigenaar: Former user (Deleted)

Aanpassingen
Metamodel, tabel Invarianten

"ZorgaanbiedersBedrijfsrol" overal vervangen door "ZorgaanbiederBedrijfsrol".

Toelichting

Zuivere correctie.

Item: URL-onderdelen in relatie tot endpoints in ZAL

Eigenaar: Former user (Deleted)

Aanpassingen
Pagina Interfaces

2b. Voor het samenstellen van alle adressen van het authorization request, het token request, het subscription request en het resource 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 en hetzij Gegevensdienst (wanneer geadresseerde Authorization Server is) of Systeemrol (wanneer geadresseerde Resource Server is). Andere elementen van de algemene URI-syntax, zoals userpasswordquery en fragment, zijn afwezig in de adressen.

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 ZorgaanbiederInterfaceversie en Gegevensdienst. Andere elementen van de algemene URI-syntax, zoals userpasswordquery en fragment, zijn afwezig in de adressen.
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 ZorgaanbiederInterfaceversie, 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 ZorgaanbiederInterfaceversieGegevensdienst en Systeemrol.

Metamodel, tabel Invarianten

Let op!

T.b.v. eindredactie: de formulering gaat ervan uit dat RFC0023 Harmonisering Register van Informatiestandaarden en Catalogus: informatiemodellen in dezelfde release wordt verwerkt.


ResourceEndpoint

(...)

Wanneer de specificaties een request identificeren maar geen [base] aanduiden, is de combinatie van r.MedMijNode.DeelnemerNode.Node.Hostname en r.ResourceEndpointpath gelijk aan het volledige begin van elke volledige, absolute URI voor resource requests die door de Resource Server mogen en kunnen worden geaccepteerd in de context van de ZorgaanbiederGegevensdienstInterfaceversieSysteemrol.

Zorgaanbieders(...)niet-lokale afhankelijkheid
Toelichting

Er is een inconsistentie aanwezig tussen de Interfaces-pagina en het Metamodel op het gebied van het deel van het adres van een resource request dat uit de ZAL moet worden betrokken. Dat is niet het volledige URL-path (zoals op de Interfaces-pagina vermeld), maar de base URL (zoals het Metamodel correct stelt).

De huidige formulering van de adresseringsverantwoordelijkheid van het resource request is ook op twee punten strijdig of potentieel onnodig restrictief ten opzichte van een of meer van de Informatiestandaarden:

  • Soms is geen base URL beschikbaar in de specificaties van de Transactie. In dat geval moet het adres uit de ZAL overeenkomen met de start van de van elders verkregen URL.
  • Het al dan niet voorkomen van query, user, password en fragment behoeft niet geregeld te worden door het afsprakenstelsel.

Dit item bevat ook de toevoeging van Interfaceversie in lijn met het item "Interfaceversie toevoegen aan ZorgaanbiederGegevensdienst en ZorgaanbiederGegevensdienstSysteemrol".

Verder bevat de nieuwe tekst een kleine correctie (niet ZorgaanbiederInterfaceversieSysteemrol, maar ZorgaanbiederGegevensdienstInterfaceversieSysteemrol is het relevante concept bij het resource request).

Ook worden de namen van de servers gecorrigeerd (door deze te verwijderen). Het subscription request wordt gericht aan de Subscription Server en niet aan de Authorization Server.

Item: Zorgaanbiedernaam mag starten met cijfer(s)

Eigenaar: Arjan van Krimpen (Unlicensed)

Aanpasingen:

/wiki/spaces/MedMijAfsprakenstelsel120/pages/135105026

  1. De naam wordt geregistreerd (ook in de Zorgaanbiederslijst) in het volgende formaat:
    1. een reeks van één of meer segmenten, gescheiden door
      1. hetzij één koppelteken,
      2. hetzij één ampersand,
      3. hetzij één punt;
    2. gevolgd door @medmij, waarin
    3. elk segment een reeks van één of meer fragmenten is, zodanig dat
    4. elk fragment bestaat uit een reeks van , met een minimale lengte van één karakter, van 
      1. minimaal één kleine letter kleine letters uit het Nederlandse alfabet (bestaande uit de zesentwintig letters a..z) en/of
      2. gevolgd door een reeks van maximaal vier Arabische cijfers (0..9).
Toelichting

De huidige eisen aan hoe een fragment is opgebouwd, verbieden het starten van een Zorgaanbiedersnaam met een cijfer. Dit is niet nodig én blokkeert valide namen van zorgaanbieders.

Item: verduidelijken verantwoordelijkheid correct hanteren specificaties Systeemrol

Eigenaar: Former user (Deleted)

Aanpassing
Applicatie

2. Als een Uitgever een zekere Gegevensdienst ontsluit ten behoeve van zijn Zorggebruikers en daartoe laat leveren door een Bron of Lezer, zullen de PGO Server van die Uitgever en de Authorization Server en Resource Server van die Bron, respectievelijk Lezer, daarvoor de bij de Gegevensdienst horende use case implementeren en de bij de Gegevensdienst horende Informatiestandaarden Systeemrollen gebruiken, zoals deze in de Catalogus zijn opgenomen, en zich daarbij te conformeren aan de specificaties van die Systeemrollen zoals die zijn gepubliceerd op de plaats(en) waarnaar de Catalogus verwijst met Functionelespecificatieverwijzing en Technischespecificatieverwijzing.

Toelichting

Zo wordt geborgd dat de juiste use case-implementaties en informatiestandaarden worden gebruikt. Ook het correcte gebruik wordt geborgd, wat bijdraagt aan interoperabiliteit en vertrouwen.

Toelichting

Zie de toelichting in de aanpassing.

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.

DreigingKansImpactDreigingsID (intern)Maatregelen





Bijlagen

  File Modified
No files shared here yet.