Logische modellen | MedMij Afsprakenstelsels

Inleiding

Er is één metamodel, maar er zijn meerdere logische modellen. Logische modellen bereiden de implementatie voor van bepaalde onderdelen van het metamodel. Deze versie van het MedMij Afsprakenstelsel kent drie logische modellen. Elk daarvan hoort bij een of enkele specifieke implementatie-component(en) in MedMij Afsprakenstelsel. Het gaat om de volgende componenten:

de vier door MedMij Registratie gepubliceerde lijsten: Gegevensdienstnamenlijst, OAuthclientlist, Whitelist en Zorgaanbiederslijst;
de in het MedMij Afsprakenstelsel te publiceren Catalogus van Gegevensdiensten;
de in het MedMij Afsprakenstelsel te publiceren (Hostname van de) MedMijStelselNode;
de twee van Deelnemers gevraagde rapportages: Beheerrapport en Portabiliteitsrapport.

De vier lijsten staan gecombineerd in één logisch model, onder de klasse MedMijBeheerlijst, omdat zij basiskenmerken delen. Iets dergelijks geldt voor de twee rapporten, onder de klasse MedMijRapport.

Vertaling van metamodel naar logisch model

Logische modellen gehoorzamen het metamodel, maar verbijzonderen dat. In de stap van metamodel naar logisch model kunnen er (logische) klassen, invarianten en basisklassen bijkomen. Maar de logische modellen bouwen vooral ook voort op het metamodel door klassen en attributen daarvan te gebruiken. In dat geval hebben logische klassen, waarde en basisklassen dus overeenkomstige klassen in het metamodel. De overeenkomsten staan hieronder bij het logische model genoemd in een tabel. Waar de tabel bij een zekere logisch klasse, waarde of basisklasse de overeenkomst met het metamodel niet noemt, is deze nieuw voor het logische niveau.

Logische klassen hebben minder of meer attributen dan de overeenkomstige klassen in het metamodel. Waar het er minder zijn, hoeven de weggelaten attributen dus niet te worden opgenomen in de te implementeren component, bijvoorbeeld van een te publiceren lijst. Waar het er meer zijn, worden deze attributen overgeërfd van een klasse in het metamodel waarvan de overeenkomstige klasse in dat metamodel bestaansafhankelijk was. In het metamodel was laatstgenoemde klasse dus toegankelijk voor de bestaansafhankelijke klasse, maar in het specifieke logische model niet meer aanwezig en dus ook niet meer toegankelijk. Zou de betreffende klasse in het logische model het attribuut dus niet hebben overgenomen, zou deze verloren zijn.

Waar een invariant uit het metamodel past binnen de scope van het specifieke logische model, verschijnt deze ook als invariant bij het logische model, hoewel de formulering zal zijn aangepast aan de ordening en naamgeving in het logische model. Daarenboven kunnen op logisch niveau ook nieuwe invarianten verschijnen. De meeste daarvan zijn verervingen: in de stap van het metamodel naar een logisch model raken verbanden verbroken tussen klassen. Als die verbanden toch van belang zijn in het logische model worden er attributen uit het metamodel verorven van een bepaalde klasse in het metamodel naar een lagere klasse, waarvan wel een pendant voorkomt in het logische model. Met "lagere klasse" wordt bedoeld dat deze bestaansafhankelijk is van de andere (hogere) klasse. Zo'n verervingsinvariant staat opgeschreven met een ←. Vóór dat pijltje staat het ervende attribuut van de logische klasse, erachter staat het pad in het metamodel naar de verervende klasse.

Ook de basisklassen uit het metamodel worden, waar van toepassing, overgenomen door het logische model. Op een enkele plek verschijnen in het logische model ook nieuwe basisklassen.

Vuistregels

De logische modellen hebben een meer op implementatie toegespitste structuur dan het metamodel. Dat metamodel is gestoeld op associatieklassen en bestaansafhankelijkheid, de logische modellen zijn meer hiërarchisch. Hiërarchie is een insnoering van associatieve bestaansafhankelijkheid, maar past beter bij menige gangbare implementatietechnologie, waaronder zeker XML, waarin de vier lijsten geïmplementeerd worden. Die insnoering betekent wel dat de logische modellen minder duurzaam en minder uitbreidbaar zijn dan het metamodel; wat voor het metamodel een eenvoudige uitbreiding is kan voor de logische modellen een stevige ingreep zijn. Dat is de prijs van hiërarchie.

Bij de vertaling van de associativiteit van het metamodel naar de hiërarchie van de logische modellen is een aantal vuistregels gebruikt.

De top van de hiërarchie van een logisch model wordt bepaald door de scope van de implementatiecomponent. De Zorgaanbiederslijst, bijvoorbeeld, somt allereerst de Zorgaanbieders op. Vanuit dat "logische centrum" wordt de hiërarchie van boven naar beneden afgelopen, zonder de scope van de implementatiecomponent te overschrijden. De stap naar beneden in de hiërarchie krijgt in het logische model typisch de vorm van een uses-relatie (de gestippelde pijl).
Onderweg wordt een compositiehiërarchie aangelegd en in elke stap een selectie gemaakt uit de in het metamodel beschikbare attributen, op basis van de scope van de implementatiecomponent. Daarbij worden logische klassen niet gecombineerd tot een grofmaziger klasse, zelfs niet als er geen enkel attribuut overblijft. De klasse-granulariteit van het logische model is dus vergelijkbaar met die van het metamodel.
Bovendien worden, zoals hierboven beschreven, attributen die in het

metamodel

buiten de scope dreigen te vallen, maar wel nodig zijn, vererfd naar binnen de scope. Waar dat gebeurt, wordt de vererving gepreciseerd in de lijst van logische invarianten.
Lagere klassen in de uses-hiërarchie vallen geheel binnen de logische scope van de hogere. Een hiërarchie creëert zo ook gesloten "name spaces". Dat betekent dat hun naamgeving eenvoudiger en korter kan dan in het

metamodel

, waar alle contexten juist open zijn. In de logische modellen krijgen de namen van de klassen dus pas betekenis wanneer hogere klassen mee worden beschouwd. Maar dat vereenvoudigt de implementatie. In een aparte tabel bij elk logisch model wordt voorkomen dat door deze naamwijzigingen het verband met het

metamodel

verloren zou gaan.
Een enkele keer heeft het vorige punt de consequentie dat er een homoniem dreigt te ontstaan binnen één logisch model (zoals Gegevensdienst en Gegevensdiensten in de logische model van de lijsten en de rapporten). In dat geval worden de namen uitgebreid zodat hun hiërarchische context zichtbaar wordt (namelijk met _GNL, _OCL, _ZAL, _BR en _PR).

Merk op dat de uses-hiërarchie de bestaansafhankelijkheidsrelatie ondersteboven zet. In de corresponderende klassen in het metamodel wordt in de uses-relatie de gebruikte klasse boven de gebruikende geplaatst, in de logische modellen juist andersom. Dit kenmerkt het doorslaggevende verschil tussen de conceptuele denkwijze van het metamodel en de bouw-gerichte denkwijze van de logische modellen. Voor de consistentie en duurzaamheid van het MedMij Afsprakenstelsel is het zaak om in het modelbeheer het metamodel centraal te plaatsen en vervolgens de logische modellen ermee in overeenstemming te houden. Het metamodel zorgt zo ook voor de duurzame consistentie tussen de verschillende logische modellen. Van die consistentie zijn de betrouwbaarheid en interoperabiliteit afhankelijk die door het MedMij Afsprakenstelsel geleverd moet worden.

Lijsten

Logisch model

Lijsten (logisch model-V2.0.0).png

Logische invarianten

Betreft instanties van logische klasse ...	Invariant	Component	Toelichting	Aard	Herkomst
Abonneren	Voor elk Abonneren a geldt: a.MaximaleDuur <= de maximale duur van Abonnementen op die Gegevensdienst zoals in de Catalogus aangegeven	Zorgaanbiederslijst	Een Zorgaanbieder kan de maximale abonnementsduur die hij aanbiedt voor een Gegevensduur, op een Interfaceversie, beperken. Daarbij moet hij echte blijven onder de maximale duur die MedMij voor die Gegevensdienst in de Catalogus heeft aangegeven.	niet-lokale afhankelijkheid	metamodel (zie ZorgaanbiederGegevensdienst
Abonneren	Voor elk Abonneren a geldt: a.SubscriptionEndpointuri ← combinatie van s.MedMijNode.DeelnemerNode.Node.Hostname en s.AuthorizationEndpointpath, conform de adresseringsverantwoordelijkheden op de -pagina.	Zorgaanbiederslijst	Zie de -pagina.	vererving	logisch model
AuthorizationEndpoint	Voor elk AuthorizationEndpoint a geldt: a.AuthorizationEndpointuri ← combinatie van a.MedMijNode.DeelnemerNode.Node.Hostname en a.AuthorizationEndpointpath, conform de adresseringsverantwoordelijkheden op de -pagina.	Zorgaanbiederslijst	Zie de -pagina.	vererving	logisch model
Gegevensdienst_OCL	Voor elke Gegevensdienst_OCL g met haar corresponderende ZorgaanbiederGegevensdienst z geldt: g.GegevensdienstId ← z.Gegevensdienst.GegevensdienstId	Zorgaanbiederslijst	Zo erft de OAuthclientlist de GegevensdienstId's van de Catalogus.	vererving	logisch model
Gegevensdienst_ZAL	Voor elke Gegevensdienst_ZAL g met haar corresponderende ZorgaanbiederGegevensdienst z geldt: g.GegevensdienstId ← z.Gegevensdienst.GegevensdienstId	Zorgaanbiederslijst	Zo erft de Zorgaanbiederslijst de GegevensdienstId's van de Catalogus.	vererving	logisch model
Gegevensdienst_ZKL	Voor elke Gegevensdienst_ZKL g met haar corresponderende ZorgaanbiederGegevensdienst z geldt: g.GegevensdienstId ← z.Gegevensdienst.GegevensdienstId	Zorgaanbiederskoppellijst	Zo erft de Zorgaanbiederskoppellijst de GegevensdienstId's van de Catalogus.	vererving	logisch model
Gegevensdienstnamenlijst	Er is precies één instantie hiervan.	Gegevensdienstnamenlijst	Dit is een eenling in het model.	getalsverhouding	logisch model
MedMijNode	Voor elke MedMijNode m geldt: m.Hostname = m.DeelnemerNode.Node.Hostname	Whitelist	Zo erft de MedMijNode de Hostname van de Node die het is.	vererving	logisch model
MedMijNode	De hostname van een MedMijNode bevat een domeinnaam die een fully-qualified domain name is, conform RFC3696, sectie 2 .	Whitelist	Dit is een maatregel tegen risico 4.4.1.4 uit RFC 6819.	lokale afhankelijkheid	metamodel (bij Node)
OAuthclient	Voor elke OAuthclient o: o.OAuthclientOrganisatienaam voldoet aan het .	Applicatie	Zie het .	lokale afhankelijkheid	metamodel (bij OAuthclient)
OAuthclient	Voor elke OAuthclient o geldt: o.Hostname ← o.MedMijNode .Hostname.	OAuthclientlist	Zo erft de OAuthclientlist de Hostnames van de Nodes.	vererving	logisch model
OAuthclientlist	Er is precies één instantie hiervan.	OAuthclientlist	Dit is een eenling in het model.	getalsverhouding	logisch model
ResourceEndpoint	Voor elk ResourceEndpoint r geldt: r.ResourceEndpointuri ← combinatie van r.MedMijNode.DeelnemerNode.Node.Hostname en r.ResourceEndpointpath, conform de adresseringsverantwoordelijkheden op de -pagina.	Zorgaanbiederslijst	Zie de -pagina.	vererving	logisch model
ResourceNotificationEndpoint	Voor elk ResourceNotificationEndpoint r geldt: r.ResourceNotificationEndpointuri ← combinatie van r.MedMijNode.DeelnemerNode.Node.Hostname en r.AuthorizationEndpointpath, conform de adresseringsverantwoordelijkheden op de -pagina.	OAuthclientlist	Zie de -pagina.	vererving	logisch model
SubscriptionNotificationEndpoint	Voor elk SubscriptionNotificationEndpoint s geldt: s.SubscriptionNotificationEndpointuri ← combinatie van s.MedMijNode.DeelnemerNode.Node.Hostname en s.AuthorizationEndpointpath, conform de adresseringsverantwoordelijkheden op de -pagina.	OAuthclientlist	Zie de -pagina.	vererving	logisch model
Systeemrol	Voor elke Systeemrol s met haar corresponderende ZorgaanbiederGegevensdienstSysteemrol z geldt: s.Systeemrolcode ← z.Systeemrol.Systeemrolcode.	Zorgaanbiederslijst	Zo erft de Zorgaanbiederslijst de Systeemrolcodes van de Catalogus.	vererving	logisch model
TokenEndpoint	Voor elk TokenEndpoint t geldt: t.TokenEndpointuri ← combinatie van t.MedMijNode.DeelnemerNode.Node.Hostname en t.TokenEndpointpath, conform de adresseringsverantwoordelijkheden op de -pagina.	Zorgaanbiederslijst	Zie de -pagina.	lokale afhankelijkheid	logisch model
Whitelist	Er is precies één instantie hiervan.	Whitelist	Dit is een eenling in het model.	getalsverhouding	logisch model
Zorgaanbiederslijst	Er is precies één instantie hiervan.	Zorgaanbiederslijst	Dit is een eenling in het model.	getalsverhouding	logisch model
Zorgaanbiederskoppellijst	Er is precies één instantie hiervan.	Zorgaanbiederskoppellijst	Dit is een eenling in het model.	getalsverhouding	logisch model

Logische basisklassen

Basisklasse	Definitie	Herkomst
Aanbiedertype	String die ZA of BAZB bevat om de aanbieder te typeren als respectievelijk Zorgaanbieder en BSN-gerechtigde aanbieder zonder behandelrelatie.	metamodel
Backchanneluri	Zie adresseringsverantwoordelijkheden op de -pagina. De domeinnaam is een fully-qualified domain name, conform RFC3696, sectie 2 .	logisch model
DatumTijd	Conform het type `xs:dateTime`, zoals gespecificeerd in XML Schema 1.0 en inclusief een tijdzone-indicatie.	logisch model
Frontchanneluri	Zie adresseringsverantwoordelijkheden op de -pagina. De domeinnaam is een fully-qualified domain name, conform RFC3696, sectie 2 .	logisch model
GegevensdienstId	String van minimaal één teken en maximaal 30 tekens.	metamodel
Hostname	Zie adresseringsverantwoordelijkheden op de -pagina.	metamodel
InterfaceversieId	String van minimaal één en maximaal 30 tekens.	metamodel
OAuthclientOrganisatienaam	Conform toepasselijk Oauthclient-namenbeleid.	metamodel
Positiefnummer	Een geheel getal ongelijk 0.	logisch model
Systeemrolcode	String van minimaal één teken en maximaal 30 tekens.	metamodel
Weergavenaam	String van minimaal drie en maximaal 50 tekens.	metamodel
Zorgaanbiedernaam	Conform toepasselijk Zorgaanbiedersnamenbeleid.	metamodel

Verband met metamodel

Klasse in logisch model	Herkomstklasse in metamodel
Abonneren	ZorgaanbiederAbonnerenOpGevensdienstInterfaceversie
AuthorizationEndpoint	AuthorizationEndpoint
Gegevensdienst_GNL	Gegevensdienst
Gegevensdienst_OCL	OAuthclientGegevensdienstInterfaceversie
Gegevensdienst_ZAL	ZorgaanbiederGegevensdienstInterfaceversie
Interfaceversie_OCL	OAuthclientInterfaceversie
MedMijNode	MedMijNode
OAuthclient	OAuthclient
ResourceEndpoint	ResourceEndpoint
ResourceNotificationEndpoint	ResourceNotificationEndpoint
SubscriptionNotificationEndpoint	SubscriptionNotificationEndpoint
Systeemrol	ZorgaanbiederGegevensdienstInterfaceversieSysteemrol
TokenEndpoint	TokenEndpoint
Zorgaanbieder_ZAL	Zorgaanbieder
Zorgaanbieder_ZKL	Zorgaanbieder

Toelichting

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

Catalogus

Logisch model

Catalogus (logisch model).jpg

Logische invarianten

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.Presentatievolgordewordt 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: een Transactie t met t.Bedrijfsrol: PatiëntBedrijfsrol gaat vooraf aan een Transactie t met t.Bedrijfsrol : ZorgaanbiederBedrijfsrol; bij meerdere Transacties van hetzelfde type: in tijdsvolgorde van de transactie.	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

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.Presentatievolgordewordt 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:

een Transactie t met t.Bedrijfsrol: PatiëntBedrijfsrol gaat vooraf aan een Transactie t met t.Bedrijfsrol : ZorgaanbiederBedrijfsrol;
bij meerdere Transacties van hetzelfde type: in tijdsvolgorde van de transactie.

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

Logische basisklassen

Basisklasse	Definitie	Herkomst
BedrijfsrolWeergavenaam	String met de waarde "Patiënt" of "Zorgaanbieder".	logisch model
DeelnemersrolWeergavenaam	String met de waarde "Dienstverlener persoon" of "Dienstverlener zorgaanbieder".	logisch model
Emailadres	Semantiek: e-mailadres volgens sectie 3.4.1 van IETF RFC 5322. Syntax: string van een of meer tekens, gevolgd door het teken `@`, gevolgd door een of meer tekens, gevolgd door het teken `.`, gevolgd door twee of meer tekens. Witruimte (spatie, tab, line feed of carriage return) is niet toegestaan.	metamodel
GegevensdienstId	String van minimaal één teken en maximaal 30 tekens.	metamodel
HttpsUrl	Semantiek: adres van een resource die via het internet benaderbaar is volgens het HTTPS-protocol. Syntax: string die altijd start met `https://` en daarna ten minste vier karakters bevat, niet zijnde witruimtekarakters (spatie, tab, line feed of carriage return) bevat.	metamodel
LangeWeergavenaam	String van minimaal één en maximaal 125 tekens.	metamodel
NederlandseDatum	Semantiek: datum volgens lokale Nederlandse tijd. Syntax: datum volgens het type `xs:date`, zoals gespecificeerd in XML Schema 1.0, zonder tijdzone-indicatie.	metamodel
Nietnegatiefgetal	Conform het type `xs:nonNegativeInteger`, zoals gespecificeerd in XML Schema 1.0.	metamodel
Positiefnummer	Een geheel getal ongelijk 0.	logisch model
Systeemrolcode	String van minimaal één teken en maximaal 30 tekens.	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
UsecaseWeergavenaam	String met de waarde "Verzamelen" of "Delen".	logisch model
Versienummer	String van minimaal één en maximaal 30 tekens.	metamodel
Weergavenaam	String van minimaal drie en maximaal 50 tekens.	metamodel

Verband met metamodel

Klasse/waarde in logisch model	Herkomstklasse in metamodel
Gegevensdienst	Gegevensdienst
Usecase	Usecase
Interfaceversie	Interfaceversie
Transactie	Transactie
Bedrijfsrol	Bedrijfsrol
Ondersteuningsloket	Ondersteuningsloket
Kwalificatieloket	Kwalificatieloket
Transactieaanduiding	Transactieaanduiding
Volledigetransactienaam	Volledigetransactienaam
Deelnemersrol	Deelnemersrol
VereisteGegevensdienst	Gegevensdienst

MedMijStelselNode

Logisch model

logisch model (draw.io, 30 jul 2018)-MedMijStelselNode.png

Logische invarianten

Betreft instanties van klasse ...	Invariant	Component	Toelichting	Aard
MedMijStelselNode	Voor de MedMijStelselNode m geldt: m.Hostname ← m.Node.Hostname	MedMijStelselNode	Zo erft de MedMijStelselNode, van de Node die het is, de Hostname.	vererving

Logische basisklassen

Basisklasse	Definitie	Herkomst
Hostname	Zie adresseringsverantwoordelijkheden op de Interfaces-pagina.	metamodel

Verband met metamodel

Klasse in logisch model	Herkomstklasse in metamodel
MedMijStelselNode	MedMijStelselNode

Rapporten

Logisch model

Rapporten (logische model).jpg

Logische invarianten

Betreft instanties van logische klasse ...	Invariant	Component	Toelichting	Aard	Herkomst
Beheerrapport	Er is precies één instantie hiervan.	Beheerrapport	Dit is een eenling in het model.	getalsverhouding	logisch model
Gegevensdienst_BR	Voor elke Gegevensdienst_BR g met haar corresponderende ZorgaanbiederGegevensdienst z geldt: g.GegevensdienstId ← z.Gegevensdienst.GegevensdienstId	Beheerrapport	Zo erft het Beheerrapport de GegevensdienstId's van de Catalogus.	vererving	logisch model
Gegevensdienst_PR	Voor elke Gegevensdienst_PR g met haar corresponderende ZorgaanbiederGegevensdienst z geldt: g.GegevensdienstId ← z.Gegevensdienst.GegevensdienstId	Portabiliteitsrapport	Zo erft het Portabiliteitsrapport de GegevensdienstId's van de Catalogus.	vererving	logisch model
Portabiliteitsrapport	Er is precies één instantie hiervan.	Portabiliteitsrapport	Dit is een eenling in het model.	getalsverhouding	logisch model

Logische basisklassen

Basisklasse	Definitie	Herkomst
DatumTijd	Conform het type `xs:dateTime`, zoals gespecificeerd in XML Schema 1.0 en inclusief een tijdzone-indicatie.	logisch model
DeelnemerId	String van minimaal één en maximaal 30 tekens.	metamodel
GegevensdienstId	String van minimaal één teken en maximaal 30 tekens.	metamodel
Nietnegatiefgetal	Conform het type `xs:nonNegativeInteger`, zoals gespecificeerd in XML Schema 1.0 .	logisch model
RequestUri	String van minimaal twaalf en maximaal 2048 tekens.	metamodel
Zorgaanbiedernaam	Conform toepasselijk Zorgaanbiedersnamenbeleid.	metamodel

Verband met metamodel

Klasse in logisch model	Herkomstklasse in metamodel
Gegevensdienst_BR	Gegevensdienst
Gegevensdienst_PR	Gegevensdienst
ResourceRequest	ResourceRequest
Zorgaanbieder	Zorgaanbieder