RFC0023 Harmonisering Register van Informatiestandaarden en Catalogus: informatiemodellen
Samenvatting
Waarom is deze RFC nodig? | A. Onderscheid tussen Register en Catalogus is onwenselijk (en enkele kleine verbeterpunten) A1. Het huidige onderscheid tussen het Register van Informatiestandaarden en de Catalogus is onnodig en niet goed verklaarbaar. Op dit moment bevat het Register de informatiestandaarden die zijn toegelaten voor gebruik binnen MedMij, en de Catalogus de gegevensdiensten. Beide hebben geen bestaansrecht zonder elkaar: een informatiestandaard zonder gegevensdienst kan niet worden gebruikt, een gegevensdienst zonder informatiestandaard kan niet worden gedefinieerd. Het onderscheid tussen de twee lijsten leidt tot een onnodige beheerlast, tot kans op fouten door inconsistenties, en tot verlaagde toegankelijkheid van de opzet van en verantwoordelijkheden van MedMij. A2. Het Register bevat enkele concepten die vooral betrekking hebben op het ontwikkel- en toetsingsproces van standaarden, maar geen operationele betekenis hebben binnen MedMij. Dit leidt tot ambiguïteit in de formele status van een informatiestandaard. A3. Binnen het MedMij Afsprakenstelsel is niet voorzien in een mogelijkheid om aan te geven welke versies van de afsprakenset gebruikt kunnen worden in combinatie met welke Gegevensdienst. De Catalogus bepaalt wel de geldigheidsperiode van een Gegevensdienst, maar in die periode kunnen er op enig moment twee versies van de afsprakenset (de gepubliceerde en de verplichte versie) in operationeel gebruik zijn. Het is denkbaar dat een Gegevensdienst niet compatibel is met beide versies. B. Catalogus is niet machine-leesbaar De Catalogus is maar beperkt machineleesbaar en de juistheid wordt ook maar beperkt afgedwongen door de implementatie van het logische model in ODS of HTML. Ook is (facultatief) geautomatiseerd gebruik door belanghebbende partijen daarmee moeilijk. |
---|---|
Oplossingsrichting | Ad A: Catalogus neemt functie van Register over en het concept Gegevensdienst krijgt een nog centralere rol
Ad B: de Catalogus wordt gepubliceerd in XML-formaat en een human readable formaat
|
Aanpassing van | Er is geen aanpassing nodig van de logische modellen en XML-schema's van de OCL, de ZAL en de GNL. |
Impact op rollen | Niet op de relatie Deelnemer - Deelnemer of Deelnemer - Beheerorganisatie. Wel op rollen die niet in het MedMij Afsprakenstelsel zijn beschreven (rollen gerelateerd aan het "stelsel van standaarden"). |
Impact op beheer |
|
Impact op RnA | Optioneel: mogelijkheid tot geautomatiseerd inlezen van de Catalogus. Optioneel: mogelijkheid tot eenvoudige geautomatiseerde afleiding van de GNL uit de Catalogus. Verplicht: bij de registratie van een ZAL-entry moet worden gecontroleerd op een geldige combinatie Gegevensdienst-Interfaceversie. Verplicht: bij de publicatie van de nieuwe versie van de Catalogus moet deze worden ingelezen en worden gebruikt als bron voor andere het genereren van de Gegevensdienstnamenlijst. |
Impact op Acceptatie | Geen. |
Gerelateerd aan (Andere RFCs, PIM issues) | Geanalyseerd: de RFC's die per 30-10-2020 kandidaat zijn voor release 1.3.0. Inhoudelijke relatie:
De volgende RFC's hebben geen inhoudelijke relatie, maar vragen wel om bijstelling van de informatiemodellen. Dit vraagt om extra coördinatie/integratie bij de uitwerking:
Geen relatie:
RFC0023 is gekoppeld aan intern issue AF-967. |
Eigenaar | |
Implementatietermijn | De RFC heeft betrekking op de Catalogus en de afsprakenset. Die kennen elk een eigen releasecyclus. De Catalogus ontleent haar structuur echter aan de afsprakenset; synchronisatie van de wijzigingen in de Catalogus en de afsprakenset is dus nodig. De implementatie van deze RFC is beoogd voor:
|
Motivatie verkorte RFC procedure (patch) | Geen patch benodigd. Analyse van de impact van deze RFC op afsprakenset release 1.2.0 (de enig andere release van de afsprakenset, naast 1.3.0, die gebruikt kan worden op het moment van het doorvoeren van deze RFC):
|
Input voor release notes / communicabele samenvatting | Wijzigingen zonder directe implementatie-impact voor de Deelnemers: Catalogus is vernieuwd, Register van Informatiestandaarden is vervallen - Het Register van Informatiestandaarden is vervallen, voortaan worden Informatiestandaarden niet meer zelfstandig toegelaten maar worden de eisen waaraan een systeemrol/Informatiestandaard moet voldoen meegewogen bij het samenstellen van een specifieke Gegevensdienst. De Catalogus is uitgebreid om de relevante onderdelen van het Register van Informatiestandaarden over te kunnen nemen. Tegelijkertijd is die geoptimaliseerd zodat die alleen relevante en heldere concepten bevat. De Catalogus wordt beschikbaar gesteld als XML-bestand en een automatische vertaling naar een gebruiksvriendelijke versie. Het Gegevensdienstenbeleid reflecteert de vereenvoudiging. Relatie tussen Gegevensdiensten en Interfaceversies is geëxpliciteerd - In de Catalogus wordt aangegeven met welke Interfaceversies een Gegevensdienst mag worden gebruikt. |
Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |
Principes
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | Positief | 11 Stelselfuncties worden vanaf de start ingevuld | Neutraal |
2 Dienstverleners zijn transparant over de gegevensdiensten | Positief | 12 Het afsprakenstelsel is een groeimodel | Neutraal |
3 Dienstverleners concurreren op de functionaliteiten | Neutraal | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Neutraal |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | Neutraal | 14 Uitwisseling is een keuze | Neutraal |
5 De persoon wisselt gegevens uit met de zorgaanbieder | Neutraal | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Neutraal |
6 MedMij spreekt alleen af wat nodig is | Neutraal | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Neutraal |
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Neutraal | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Neutraal |
9 De dienstverleners zijn deelnemers van het afsprakenstelsel | Neutraal | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | Neutraal |
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | Neutraal | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Neutraal |
Uitwerking
Toevoegingen in paars. Verwijderingen doorgehaald.
Uitgangspunt is dat toelichtingen in de te publiceren producten (bijvoorbeeld bij het metamodel) vooral daar worden verschaft waar die zinvol zijn (bijdragen aan duidelijkheid, begrip, gewenste standaardisatie).
Links naar andere pagina's binnen het Afsprakenstelsel zijn niet nagelopen, dat kan het beste bij de eindredactie plaatsvinden.
Noot voor eindredactie
De uitwerking van deze RFC gaat ervan uit dat RFC0035 Verzamel RFC reeds is verwerkt.
Metamodel (aanpassing)
Model
Noot voor eindredactie
In dit model zijn alleen de voor de aanpassing relevante klassen opgenomen. Dit deel moet door de eindredactie worden geïntegreerd in de afbeelding van het volledige metamodel.
Het plaatje met de 'domeinen', onderdeel van het metamodel, behoeft ook aanpassing om de nieuwe situatie te reflecteren.
Toelichting
Op enkele punten is afgeweken van deze modelleerstijl, om de presentatie van het model niet onnodig te compliceren. door gebruik van:
de uses-relatie, vooral in het Informatiestandaarden-domein, omdat dat domein niet onder beheer van MedMij valt;de aggregatie-relatie, idem;de objectgeoriënteerde specialisatie, namelijk waar we een opsommende definitie geven van Deelnemersrol, Businessrol, Usecase en Bedrijfsrol;attributen voor identificatie of omschrijving.
In al deze gevallen zouden ook associatieklassen gebruikt kunnen worden, maar zou dat de presentatie van het model onnodig compliceren.
(...)
Gegevensdiensten horen bij een Usecase en hebben een geldigheidsperiode. Bovendien wordt, door middel van het attribuut Vereist, van sommige Gegevensdiensten vereist dat, als een Zorgaanbieder die Gegevensdienst aanbiedt, hij ook zekere andere Gegevensdiensten moet aanbieden. Vaak zal die lijst leeg zijn, maar het heeft bijvoorbeeld weinig zin het Delen van een afspraakverzoek aan te bieden, zonder ook het Verzamelen van het antwoord daarop aan te bieden. De klasse RolInGegevensdienst wordt gebruikt om, via de Deelnemer, de MedMij-rollen DienstverlenerpersoonDeelnemersrol en DienstverlenerzorgaanbiederDeelnemersrol te verbinden met de dienovereenkomstige rollen die Nictiz in het Informatiestandaarden-domein heeft geformuleerd, namelijk respectievelijk PatiëntBedrijfsrol en ZorgaanbiederBedrijfsrol. Een GegevensdienstInterfaceversie geeft aan dat een Gegevensdienst via de Interfaceversie mag worden aangeboden.
De klassen in het modeldomein Informatiestandaarden, inclusief hun namen, moeten begrepen worden in de zin waarin Nictiz ze gebruikt in het kader van de Informatiestandaarden die voor gebruik binnen MedMij zijn toegelaten waarvan de onderdelen de basis vormen voor Gegevensdiensten. Daarom zijn de randen van deze klassen gestippeld. De bouwblokjes van een Informatiestandaard noemen we een Transactie, die zowel functionele als technische specificaties bevat. Een Bedrijfsrol, waarvan er twee zijn (PatiëntBedrijfsrol en ZorgaanbiederBedrijfsrol), wordt aangenomen door een Systeemrol Transactie.
De klassen in het modeldomein Systeemrollen leggen de verbinding tussen het domein van de Informatiestandaarden en dat van de Gegevensdiensten. Een Systeemrol is een Transactie die voorzien is van een Systeemrolcode om hem binnen MedMij uniek te kunnen aanduiden. Merk op dat een Systeemrol een concept is met een specifieke betekenis binnen het MedMij Afsprakenstelsel. Het is niet hetzelfde als het concept "Systeemrol" zoals dat wordt gebruikt binnen de Nictiz-informatiestandaarden. Een Systeemrol kan een Ondersteuningsorganisatie hebben die dienstverlening biedt aan Deelnemers bij vragen over de specificaties behorend bij de Systeemrol. Vaak zal dit de beheerder van de onderliggende Informatiestandaard zijn, maar het is ook denkbaar dat er geen beheerder is of dat een andere partij de rol van beheerder vervult (bijvoorbeeld als de beheerder van de Informatiestandaard geen dienstverlening biedt voor MedMij-stakeholders). Een Systeemrol kan ook verbonden zijn met een Kwalificatieloket waar de ondersteuning van Systeemrollen kan worden aangetoond.
Systeemrollen worden gegroepeerd in Systeemrolverzamelingen die samen met een Usecase een Gegevensdienst vormen. Een actueel voorbeeld van een Systeemrolverzameling is een verzameling van vier Systeemrollen waarvan er twee (één voor elke betrokken Bedrijfsrol) een overzicht van beschikbare PDF-documenten uitwisselen en twee (opnieuw één voor elke betrokken Bedrijfsrol) een PDF-document uit dat overzicht uitwisselen. Gegevensdiensten worden als geheel (dat wil zeggen met hun gehele Systeemrolverzameling) aan Zorggebruikers aangeboden en die gebruikers zullen deze ook ineens autoriseren.
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. Alleen bij de Nictiz-klassen in het Register van Informatiestandaarden hebben we dit achterwege gelaten.
Invarianten
Betreft instanties van klasse ... | Invariant | Modeldomein | Toelichting | Aard |
---|---|---|---|---|
| ||||
ZorgaanbiederGegevensdienst | Voor elke ZorgaanbiederGegevensdienst zg geldt: ALS er een ZorgaanbiederGegevensdienstInterfaceversie zgi1 is zodat:
EN er een GegevensdienstInterfaceversie gi is zodat:
DAN is er een ZorgaanbiederGegevensdienstInterfaceversie zgi2 zodat:
| Zorgaanbieders | Wanneer een Zorgaanbieder een Gegevensdienst aanbiedt op de gepubliceerde Interfaceversie, moet hij deze ook aanbieden op de verplichte Interfaceversie. Dit geldt uiteraard alleen als de Gegevensdienst ook mag worden aangeboden op de verplichte Interfaceversie. Zie Change- en releasebeleid. | niet-lokale afhankelijkheid |
ZorgaanbiederGegevensdienst | Voor elke ZorgaanbiederGegevensdienst zg geldt: ALS er een ZorgaanbiedersAbonnerenOpGegevensdienstInterfaceversie zagi1 is zodat:
EN er een GegevensdienstAbonnerenOpGegevensdienstInterfaceversie agi is zodat:
DAN is er een ZorgaanbiedersAbonnerenOpGegevensdienstInterfaceversie zagi2 zodat:
| Zorgaanbieders | Wanneer een Zorgaanbieder Abonneren op een Gegevensdienst aanbiedt op de gepubliceerde Interfaceversie, moet hij dat ook aanbieden op de verplichte Interfaceversie. Dit geldt uiteraard alleen als de Gegevensdienst ook mag worden aangeboden op de verplichte Interfaceversie. Zie Change- en releasebeleid. | niet-lokale afhankelijkheid |
Ondersteuningsloket | Elk Ondersteuningsloket heeft ten minste één van de volgende attributen: Emailadres, Telefoonnummer en Emailadres. | Systeemrollen | Een Ondersteuningsloket moet ten minste langs één wijze een contactadres kennen. | lokale afhankelijkheid |
ResourceEndpoint | Voor elk ResourceEndpoint r geldt:
de combinatie van r.MedMijNode.DeelnemerNode.Node.Hostname en r.ResourceEndpointpath is gelijk aan wat in de specificaties van r.ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.Systeemrol.Transactie
| Zorgaanbieders | Deze invariant regelt | niet-lokale afhankelijkheid |
Gegevensdienst | Voor elke Gegevensdienst geldt: g.Usecase is ofwel VerzamelenUsecase ofwel DelenUsecase. | Gegevensdiensten | Zo wordt geregeld dat een Gegevensdienst alleen gebaseerd kan zijn op de primaire use cases Verzamelen of Delen. | opsomming |
Kwalificatieloket | Elk Kwalificatieloket heeft ten minste één van de volgende attributen: Emailadres, Telefoonnummer en Emailadres. | Systeemrollen | Een Kwalificatieloket moet ten minste langs één wijze een kanaal kennen waarlangs meer informatie over de kwalificatie kan worden verkregen. | lokale afhankelijkheid |
| ||||
ZorgaanbiederGegevensdienst | Voor elke ZorgaanbiederGegevensdienst.Gegevensdienst. waarvoor geldt dat s.Transactie.Bedrijfsrol = ZorgaanbiederBedrijfsrol, geldt dat er een ZorgaanbiederGegevensdienstSysteemrol z is zodat z.Systeemrol = s. | Zorgaanbieders | Als in de Catalogus een Systeemrol voor Zorgaanbieders hoort bij een namens een zekere Zorgaanbieder aangeboden Gegevensdienst, dan moet namens dezelfde Zorgaanbieder ook deze Systeemrol worden aangeboden. | niet-lokale afhankelijkheid |
| ||||
| ||||
OAuthclientGegevensdienstInterfaceversie | Voor elke OAuthclientGegevensdienstInterfaceversie ogi geldt: ALS er een OAuthClientAbonnerenOpGegevensdienstInterfaceversie oagi1 is zodat:
DAN is er een OAuthClientAbonnerenOpGegevensdienstInterfaceversie oagi2 zodat:
| Zorgaanbieders | Wanneer een OAuthClient Abonneren op een Gegevensdienst aanbiedt op de gepubliceerde Interfaceversie, moet hij dat ook aanbieden op de verplichte Interfaceversie. Zie /wiki/spaces/MedMijAfsprakenstelsel130/pages/135628810. | niet-lokale afhankelijkheid |
|
Noot voor eindredactie
Er is vanuit gegaan dat OAuthclientGegevensdienst niet meer voorkomt in het metamodel, op grond van RFC0014 Extra controles door Authorization Interface.
Basisklassen
Basisklasse | Definitie |
---|---|
HttpsUrl | Semantiek: adres van een resource die via het internet benaderbaar is volgens het HTTPS-protocol. Syntax: string die altijd start met |
Versienummer | |
Telefoonnummer | Semantiek: internationaal telefoonnummer volgens Recommendation ITU-T E.164 (11/2010). Syntax: string die altijd start met + en vervolgens bestaat uit maximaal vijftien cijfers (0 tot en met 9). |
Emailadres | Semantiek: e-mailadres volgens sectie 3.4.1 van IETF RFC 5322. Syntax: string van een of meer tekens, gevolgd door het teken |
NederlandseDatum | Semantiek: datum volgens lokale Nederlandse tijd. Syntax: datum volgens het type |
LangeWeergavenaam | String van minimaal drie en maximaal 125 tekens. |
Logische modellen (aanpassing)
Model Catalogus
Noot voor eindredactie
Het model wordt worden vervangen door de inhoud van onderstaand model. De stijl van de bestaande logische modellen kan daarop worden toegepast.
Toelichting bij wijziging (niet verwerken)
De Catalogus is geen specialisatie van MedMijBeheerlijst, omdat het een aantal (impliciete) kenmerken van MedMijBeheerlijsten niet deelt, zoals de gebondenheid aan een specifieke interfaceversie.
Invarianten bij logisch model Catalogus
Betreft instanties van klasse ... | Invariant | Component | Toelichting | Aard | Herkomst |
---|---|---|---|---|---|
Catalogus | Er is precies één instantie hiervan. | Catalogus | Dit is een eenling in het model. | getalsverhouding | logisch model |
| |||||
Systeemrol | Voor elke Systeemrol s geldt: s.Presentatievolgorde wordt bepaald door de relatieve positie van de systeemrol in de tijdsvolgorde waarin s.Transactie binnen de uitvoering van s.Systeemrolverzameling.Gegevensdienst.Usecase zijn werk moet doen. Daarbij gelden als elkaar aanvullende richtlijnen:
| Catalogus | De volgorde waarin die Systeemrolcodes bij een Gegevensdienst staan opgesomd is formeel om het even, maar voor de presentatie wel relevant. Die volgorde van presentatie komt overeen met de tijdsvolgorde waarin de betreffende Systeemrollen hun werk moeten doen. | lokale afhankelijkheid | logisch model |
Invarianten bij logisch model Lijsten
Betreft instanties van logische klasse ... | Invariant | Component | Toelichting | Aard | Herkomst |
---|---|---|---|---|---|
| |||||
| |||||
| |||||
Systeemrol | Voor elke Systeemrol s met haar corresponderende ZorgaanbiederGegevensdienstSysteemrol z geldt: s.Systeemrolcode ← z.Systeemrol.Systeemrolcode. | Zorgaanbiederslijst | Zo erft de Zorgaanbiederslijst de Systeemrolcodes van | vererving | logisch model |
Toelichting bij wijziging (niet verwerken)
De invarianten voor de klasse "Interfaceversies_ZAL" zouden moeten worden aangepast als gevolg van een wijziging van de gerelateerde invariant in het metamodel. De logische invariant zou daardoor nog complexer worden. Omdat de invariant echter geen duidelijke functie lijkt te hebben in het logische model (dat is gericht op de publicatie van de ZAL, en niet op de registratie; de betreffende invarianten hebben nu ook geen vertaling in het technische model), worden zij in plaats daarvan geschrapt.
Basisklassen bij logisch model Catalogus
Basisklasse | Definitie | Herkomst |
---|---|---|
DeelnemersrolWeergavenaam | String met de waarde "Dienstverlener persoon" of "Dienstverlener zorgaanbieder". | logisch model |
UsecaseWeergavenaam | String met de waarde "Verzamelen" of "Delen". | logisch model |
BedrijfsrolWeergavenaam | String met de waarde "Patiënt" of "Zorgaanbieder". | logisch model |
NederlandseDatum | Semantiek: datum volgens lokale Nederlandse tijd. Syntax: datum volgens het type | metamodel |
HttpsUrl | Semantiek: adres van een resource die via het internet benaderbaar is volgens het HTTPS-protocol. Syntax: string die altijd start met | metamodel |
Telefoonnummer | Semantiek: internationaal telefoonnummer volgens Recommendation ITU-T E.164 (11/2010). Syntax: string die altijd start met + en vervolgens bestaat uit maximaal vijftien cijfers (0 tot en met 9). | metamodel |
Emailadres | Semantiek: e-mailadres volgens sectie 3.4.1 van IETF RFC 5322. Syntax: string van een of meer tekens, gevolgd door het teken | metamodel |
Versienummer | String van minimaal één en maximaal 30 tekens. | metamodel |
Positiefnummer | Een geheel getal ongelijk 0. | logisch model |
LangeWeergavenaam | String van minimaal één en maximaal 125 tekens. | metamodel |
Verband klassen logisch model Catalogus met metamodel
Klasse/waarde in logisch model | Herkomstklasse in metamodel |
---|---|
Usecase | Usecase |
Interfaceversie | Interfaceversie |
Transactie | Transactie |
Bedrijfsrol | Bedrijfsrol |
Ondersteuningsloket | Ondersteuningsloket |
Kwalificatieloket | Kwalificatieloket |
Transactieaanduiding | Transactieaanduiding |
Volledigetransactienaam | Volledigetransactienaam |
Deelnemersrol | Deelnemersrol |
VereisteGegevensdienst | Gegevensdienst |
Toelichting
De klasse Usecase is een abstracte klasse in het metamodel. In het logische model zijn, in de compositiehiërarchie, echter concrete klassen nodig. In het kader van de Catalogus zijn we hier niet geïnteressseerd in de gehele semantiek van de conceptuele klassen VerzamelenUsecase en DelenUsecase, maar enkel in hun respectievelijke instanties, met de Weergavenaam die zij van de abstracte klasse Usecase krijgen, door middel van een invariant. Daarom gebruiken we in dit logische model een concrete klasse Usecase, die tot deze twee instantieert.
Toelichting bij wijziging (niet verwerken)
Er zijn bewust geen klassen opgenomen t.b.v. het wijzigingsbeheer. In de huidige Catalogus komen de kolommen "Datum aanmaak", "Datum mutatie" en "Opmerking mutatie" voor. Voor toelichting op de wijzigingen wordt verwezen naar de toelichting op de Catalogus. Daarnaast kunnen gebruikers met eigen tooling desgewenst een automatische vergelijking uitvoeren tussen verschillende versies van het XML-bestand van de Catalogus. Aan de toelichting op de Catalogus zal voor nieuwe wijzigingen ook de datum van de mutatie worden toegevoegd.
XML-schema Catalogus (nieuw)
Het releasenummer wordt met één opgehoogd omdat de structuur van het technische model van de Catalogus is gewijzigd.
De bestandsnaam bevat niet de bestandsversie, noch het volgnummer, maar wel het nummer van de release van de Catalogus.
Pagina XML-schema’s (aanpassing)
Toelichting
Op deze pagina staan de XML-schema's van:
- de lijsten die door MedMij Beheer aan Bron en Uitgever voor uiteenlopende doelen ter beschikking worden gesteld;
- de rapporten die door Deelnemers moeten kunnen worden opgeleverd;
- de Catalogus.
De XML-schema's zijn een implementatie van de relevante logische modellen van de lijsten in XML-syntax en vervullen daarom de rol van technisch model. XML past bij de hiërarchische structurering waarop al in de logische modellen is ingezet.
- Bij het logische model van de lijsten en rapporten horen vier technische componenten. De hoogste klasse van elke component wordt het rootelement van het betreffende XML-schema. De attributen van de abstracte klassen bovenaan (MedMijBeheerlijst en MedMijRapport) worden over de technische modellen van de vier lijsten, respectievelijk de twee rapporten, verspreid. Er is dus voor elke lijst of rapport een apart XML-schema. Daardoor is de homonymie van
Gegevensdienst
enGegevensdiensten
geen probleem meer en kunnen in de namen de achtervoegsels_ZAL
,_GNL
,_OCL
,_BR
en_PR
achterwege blijven.- De Catalogus vormt hierop een uitzondering. Die kent een zelfstandig logisch model. De klasse Catalogus uit het logisch model dient als root element van het XML-schema van de Catalogus.
Lijst of rapport | Bestandsnaam | Release | Versie bestand |
---|---|---|---|
Catalogus | MedMij_Catalogus_release3.xsd | 3 | 5 |
Tijdaspect
Het metamodel en de logische modellen, met hun invarianten, werken "door de tijd". Zij beschrijven hoe de klassen samenhangen op elk moment. De XML-bestanden voor de lijsten zijn echter specifieke momentopnames van de instanties van de klassen. Er moet daarom een tijdselement worden toegevoegd om lijsten die op verschillende momenten zijn gegenereerd, uit elkaar te kunnen houden, en om in retrospectief de geldigheidstermijn van een lijst te kunnen vaststellen.
- Elk XML-bestand kent een versie-aanduiding. Hiertoe wordt de combinatie van een
Volgnummer
en eenTijdstempel
gebruikt. Hiermee wordt aan drie informatiebehoeften tegemoet gekomen:- Wanneer twee lijsten (van hetzelfde type) met opeenvolgende
Volgnummers
beschikbaar zijn, kan de geldigheidstermijn van de oudere lijst worden vastgesteld. Dat helpt bij de interpretatie van audit logs of foutopsporing. - Lijsten kunnen uniek worden geïdentificeerd. Dit kan aan de hand van
Volgnummer
ofTijdstempel
, waarbijVolgnummer
voor menselijke gebruikers vaak de meest intuïtieve zal zijn. - Per lijst kan worden nagegaan wanneer de laatste mutatie heeft plaatsgevonden. Dit zal in de regel een 'functionele' mutatie betreffen, geen foutherstel. Hieruit kan door vergelijking van opeenvolgende versies worden afgeleid wanneer de actuele lijst voor het laatst is gewijzigd; dat kan zinvol zijn bij het beoordelen van de effecten van changes of bij foutopsporing.
- Wanneer twee lijsten (van hetzelfde type) met opeenvolgende
Tijdstempel
bestaat uit Datum, Tijd en Tijdzone-aanduiding, gebaseerd opxs:dateTime
-type. Door voor een native XML-datatype te kiezen, wordt de implementatie vergemakkelijkt. Er geldt wel een restrictie op het element, dat afdwingt dat er altijd een Tijdzone-aanduiding wordt meegegeven.- Voor de Catalogus geldt een uitzondering, en wordt gebruikgemaakt van een uitdrukking van de lokale Nederlandse datum (
xs:date
-type zonder tijdzone-aanduiding).
- Voor de Catalogus geldt een uitzondering, en wordt gebruikgemaakt van een uitdrukking van de lokale Nederlandse datum (
Namespaces
Voor de aanduiding van namespaces wordt gebruikgemaakt van een URL. Dit is de gemakkelijkste optie, omdat dit - anders dan bij een URN - geen namespaceregistratie bij IANA vereist. De namespace-URL kent de volgende opbouw: xmlns://afsprakenstelsel.medmij.nl/[naamLijst|naamRapport|"catalogus"]/release[releasenummer]
.
- Een namespace-URL gebruikt
xmlns://
als schema-aanduiding. Daarmee wordt duidelijk gemaakt dat het slechts een identificatie betreft, en dat de URL niet is bedoeld voor dereferencing (bijvoorbeeld om het XML-schema te downloaden). - Het domein
afsprakenstelsel.medmij.nl
is een unieke hostname op het internet. Gebruik daarvan biedt zowel voldoende herkenbaarheid als uniciteit. - De
naamLijst
kent één van de volgende waarden:Whitelist
,OAuthclientlist
,Zorgaanbiederslijst
ofGegevensdienstnamenlijst
. - De
naamRapport
kent één van de volgende waarden:Beheerrapport
ofPortabiliteitsrapport
. - De aanduiding
release
is toegevoegd voor de menselijke leesbaarheid en daarmee duidelijkheid.
Waar het metamodel geen namen heeft gedefinieerd, kiezen we om redenen van consistentie en elegantie voor lowercase in de opbouw van de URL. Er wordt gebruikgemaakt van elementFormDefault
= "qualified
". Dit vergroot de leesbaarheid van de XML-schema's omdat er geen prefixes nodig zijn bij het definiëren van elementen, en doet niet af aan enige functionaliteit . 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.
Pagina XML-bestanden voor lijsten (aanpassing)
De XML-bestanden waarmee MedMij Beheer de Zorgaanbiederslijst, de Whitelist, de OAuth Client List en de Gegevensdienstnamenlijst en de Catalogus ontsluit voldoen aan enkele eisen, zodat PGO Server, Authorization Server en MedMijNode en anderen weten waarop zij kunnen rekenen voor de goede verwerking van deze lijsten.
1. Het XML-bestand van de Zorgaanbiederslijst heet MedMij_Zorgaanbiederslijst.xml
. Het XML-bestand van de Whitelist heet MedMij_Whitelist.xml
. Het XML-bestand van de OAuth Client List heet MedMij_OAuthclientlist.xml
. Het XML-bestand van de Gegevensdienstnamen heet MedMij_Gegevensdienstnamenlijst.xml
. Het XML-bestand van de Catalogus heet MedMij_Catalogus.xml
.
XML-bestand Catalogus (nieuw)
Noot voor eindredactie
De definitieve versie van het XML-bestand van de Catalogus volgt later. Bij deze RFC is een voorbeeld opgenomen.