Samenvatting

Goedkeuring

Principe's

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:

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.

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.

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

Toelichting

Zuivere correctie.

Item: dubbele regels

Eigenaar: Former user (Deleted)

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

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

Logisch model, tabel Verband met metamodel

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 user, password, query 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 Zorgaanbieder, Interfaceversie en Gegevensdienst. Andere elementen van de algemene URI-syntax, zoals user, password, query 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 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.

Metamodel, tabel Invarianten

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: Former user (Deleted)

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.

Bijlagen