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. |
...
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.
...
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 |
|
...
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. |
...
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 |
...
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
...
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.
...
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
GegevensdienstenGegevensdienstengeen probleem meer en kunnen in de namen de achtervoegsels_ZAL,_GNL,_OCL,_BRen_PRachterwege 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.
...
(Equivalente pagina in release 1.2.0: https://afsprakenstelselvzvz.medmijatlassian.nlnet/wiki/display/MedMijAfsprakenstelsel120/MedMij+Afsprakenstelsel+1.2.0)
- De beheerorganisatie onderhoudt
twee registerseen Catalogus die relevantzijnis voor de dienstverlening die via het MedMij-netwerk kan worden aangeboden.Het Register van Informatiestandaarden bevat de toegelaten informatiestandaarden.De Catalogus definieert welke Gegevensdiensten deelnemers kunnen ontsluitenaanbieden. - Verwijderen tabelrij "Register van Informatiestandaarden".
...
Voor (C) geldt dat in de Catalogus te vinden is welke Informatiestandaard bij een Gegevensdienst hoort en in het Register van Informatiestandaarden bij de Informatiestandaard vervolgens is opgenomen waar de ondersteuning van de Systeemrollen behorend bij een Gegevensdienst kan worden aangetoond.
...
|
|
|
|
|---|---|---|---|
Algemene toelichting
De Catalogus bevat de Gegevensdiensten die over het MedMij-netwerk kunnen worden ontsloten. De Catalogus wordt formeel gepubliceerd in XML-formaat (hier te vinden). Een gebruiksvriendelijke weergave is te vinden op de pagina /wiki/spaces/MMCatalogus/pages/159187749. Een gebruiksvriendelijke weergave is te vinden op de pagina Actuele catalogus.
| Info | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Op de pagina Actuele Catalogus zorgdragen voor een goede human-readable weergave (zie elders in deze RFC). De te gebruiken CSS-stylesheet voor de tabel:
De te gebruiken XML-stylesheet voor het genereren van de human-readable versie:
|
in een spreadsheet weergegeven als een (niet-genormaliseerde) tabel. Het is een implementatie van het logisch model van de Catalogus. Er is gekozen voor het open bestandsformaat OpenDocument Spreadsheet (ODS) omdat hiermee aansluiting wordt gezocht bij een reeds beschikbare en open norm.
De Systeemrollen waaruit een Systeemrolverzameling bestaat zijn onderdeel van het Register van Informatiestandaarden. Voor informatieve doeleinden bevat de spreadsheet ook enkele klassen uit het Register van Informatiestandaarden. Ook is ter informatie de Deelnemersrol weergegeven; deze volgt echter niet uit de Catalogus, maar uit de invarianten van het metamodel. Wanneer mutaties worden doorgevoerd binnen een reeds gedefinieerde Gegevensdienst, wordt dit aangegeven onder de kolommen bij Wijzigingsbeheer. Ter vergroting van de leesbaarheid is een Datum aanmaak opgenomen, zodat wijzigingen in de Catalogus (toevoegingen dan wel mutaties) gemakkelijk zichtbaar zijn.
Wijzigingen in de Catalogus kunnen op grond van het Gegevensdienstenbeleid plaatsvinden onafhankelijk van releases van het afsprakenstelsel. Het bestuur van de Stichting MedMij stelt (wijzigingen in) de Catalogus vast.
...
De Catalogus bevat ook Gegevensdiensten die inmiddels niet meer geldig zijn, omdat de einddatum van de geldigheidsperiode is gepasseerd. Door deze Gegevensdiensten te blijven vermelden wordt op een gemakkelijke wijze inzage geboden in de historie van Gegevensdiensten (bijvoorbeeld ten behoeve van het interpreteren van loggegevens). Het voorkomt ook dat de Catalogus (een op dit moment handmatig beheerd en gepubliceerd product) aanpassing behoeft op het moment van het verstrijken van de geldigheid van een Gegevensdienst. Gegevensdiensten die al bij publicatie van de betreffende versie van de Catalogus ongeldig waren, hebben voor de overzichtelijkheid een grijze achtergrond.
Toelichting bij inhoud van de Catalogus
...