Skip to end of metadata
Go to start of metadata

Toelichting

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


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.


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


Logische invarianten

Betreft instanties van logische klasse ...InvariantComponentToelichtingAardHerkomst
Abonneren

Voor elk Abonneren a geldt:

a.MaximaleDuur <= de maximale duur van Abonnementen op die Gegevensdienst zoals in de Catalogus aangegeven

ZorgaanbiederslijstEen 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 afhankelijkheidmetamodel (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 Interfaces-pagina.

ZorgaanbiederslijstZie de Interfaces-pagina.verervinglogisch model
AuthorizationEndpoint

Voor elk AuthorizationEndpoint a geldt: a.AuthorizationEndpointuri  
combinatie van a.MedMijNode.DeelnemerNode.Node.Hostname en a.AuthorizationEndpointpath, conform de adresseringsverantwoordelijkheden op de Interfaces-pagina.

ZorgaanbiederslijstZie de Interfaces-pagina.verervinglogisch model
Gegevensdienst_OCLVoor elke Gegevensdienst_OCL g met haar corresponderende ZorgaanbiederGegevensdienst z geldt:
g.GegevensdienstId
 ← z.Gegevensdienst.GegevensdienstId
ZorgaanbiederslijstZo erft de Zorgaanbiederslijst de GegevensdienstId's van de Catalogus.verervinglogisch model
Gegevensdienst_ZALVoor elke Gegevensdienst_ZAL g met haar corresponderende ZorgaanbiederGegevensdienst z geldt:
g.GegevensdienstId
 ← z.Gegevensdienst.GegevensdienstId
ZorgaanbiederslijstZo erft de Zorgaanbiederslijst de GegevensdienstId's van de Catalogus.verervinglogisch model
GegevensdienstnamenlijstEr is precies één instantie hiervan.GegevensdienstnamenlijstDit is een eenling in het model.getalsverhoudinglogisch model
Interfaceversies_ZAL

Voor elke Gegevensdienst_OCL g1 geldt dat:

ALS:

  • g1.Gegevensdiensten_OCL.
    Interfaceversie_OCL is de gepubliceerde Interfaceversie
  • er is een Abonneren a1 zodat a1.Gegevensdienst_OCL = g1

DAN is er een Gegevensdienst_ZAL g2 waarvoor geldt dat:

  • g2.GegevensdienstId = g1.GegevensdienstId
  • g1.Gegevensdiensten_OCL.
    Interfaceversie_OCL is de verplichte Interfaceversie
  • er is een Abonneren a2 zodat a2.Gegevensdienst_OCL = g2
ZorgaanbiederslijstOp Gegevensdiensten waarvoor door een OAuthClient onder de gepubliceerde Interfaceversie Abonnementen worden aangeboden, worden ook onder de verplichte Interfaceversie Abonnementen aangeboden.niet-lokale afhankelijkheidmetamodel
Interfaceversies_ZAL

Voor elke Interfaceversies_ZAL, dienst verplichte Interfaceversie_ZAL vi en diens gepubliceerde Interfaceversie_ZAL gi geldt dat 

ALS er een Gegevensdienst_ZAL g1 is waarvoor geldt dat  g1.Gegevensdiensten_ZAL.
Interfaceversie_ZAL
 = gi

DAN is er een Gegevensdienst_ZAL g2 waarvoor geldt dat g2.Gegevensdiensten_ZAL.
Interfaceversie_ZAL
 = vi

ZorgaanbiederslijstGegevensdiensten die door een Zorgaanbieder onder de gepubliceerde Interfaceversie worden aangeboden, worden ook onder de verplichte Interfaceversie aangeboden.niet-lokale afhankelijkheidmetamodel
Interfaceversies_ZAL

Voor elke Gegevensdienst_ZAL g1 geldt dat:

ALS:

  • g1.Gegevensdiensten_ZAL.
    Interfaceversie_ZAL is de gepubliceerde Interfaceversie
  • er is een Abonneren a1 zodat a1.Gegevensdienst_ZAL = g1

DAN is er een Gegevensdienst_ZAL g2 waarvoor geldt dat:

  • g2.GegevensdienstId = g1.GegevensdienstId
  • g1.Gegevensdiensten_ZAL.
    Interfaceversie_ZAL is de verplichte Interfaceversie
  • er is een Abonneren a2 zodat a2.Gegevensdienst_ZAL = g2
ZorgaanbiederslijstOp Gegevensdiensten waarvoor door een Zorgaanbieder onder de gepubliceerde Interfaceversie Abonnementen worden aangeboden, worden ook onder de verplichte Interfaceversie Abonnementen aangeboden.niet-lokale afhankelijkheidmetamodel
MedMijNode

Voor elke MedMijNode m geldt:
m.Hostname = m.DeelnemerNode.Node.Hostname

WhitelistZo erft de MedMijNode de Hostname van de Node die het is.verervinglogisch model
MedMijNodeDe hostname van een MedMijNode bevat een domeinnaam die een fully-qualified domain name is, conform RFC3696, sectie 2.WhitelistDit is een maatregel tegen risico 4.4.1.4 uit RFC 6819.lokale afhankelijkheidmetamodel (bij Node)
OAuthclientVoor elke OAuthclient o:
o.OAuthclientOrganisatienaam voldoet aan het OAuthclient-namenbeleid
ApplicatieZie het OAuthclient-namenbeleid.lokale afhankelijkheidmetamodel (bij OAuthclient)
OAuthclientVoor elke OAuthclient o geldt: o.Hostname ←  o.MedMijNode .Hostname.OAuthclientlistZo erft de OAuthclientlist de Hostnames van de Nodes.verervinglogisch model
OAuthclientlistEr is precies één instantie hiervan.OAuthclientlistDit is een eenling in het model.getalsverhoudinglogisch model
ResourceEndpoint

Voor elk ResourceEndpoint r geldt: r.ResourceEndpointuri ← 
combinatie van r.MedMijNode.DeelnemerNode.Node.Hostname en r.ResourceEndpointpath, conform de adresseringsverantwoordelijkheden op de Interfaces-pagina.

ZorgaanbiederslijstZie de Interfaces-pagina.verervinglogisch model
ResourceNotificationEndpointVoor elk ResourceNotificationEndpoint r geldt: r.ResourceNotificationEndpointuri ← 
combinatie van r.MedMijNode.DeelnemerNode.Node.Hostname en r.AuthorizationEndpointpath, conform de adresseringsverantwoordelijkheden op de Interfaces-pagina.
OAuthclientlistZie de Interfaces-pagina.verervinglogisch model
SubscriptionNotificationEndpointVoor elk SubscriptionNotificationEndpoint s geldt: s.SubscriptionNotificationEndpointuri ← 
combinatie van s.MedMijNode.DeelnemerNode.Node.Hostname en s.AuthorizationEndpointpath, conform de adresseringsverantwoordelijkheden op de Interfaces-pagina.
OAuthclientlistZie de Interfaces-pagina.verervinglogisch model
SysteemrolVoor elke Systeemrol s met haar corresponderende ZorgaanbiederGegevensdienstSysteemrol z geldt:
s.Systeemrolcode ← z.Systeemrol.Systeemrolcode.
ZorgaanbiederslijstZo erft de Zorgaanbiederslijst de Systeemrolcodes van het Register van Informatiestandaarden.verervinglogisch model
TokenEndpoint

Voor elk TokenEndpoint t geldt: t.TokenEndpointuri ← 
combinatie van t.MedMijNode.DeelnemerNode.Node.Hostname en t.TokenEndpointpath, conform de adresseringsverantwoordelijkheden op de Interfaces-pagina.

ZorgaanbiederslijstZie de Interfaces-pagina.lokale afhankelijkheidlogisch model
WhitelistEr is precies één instantie hiervan.WhitelistDit is een eenling in het model.getalsverhoudinglogisch model
ZorgaanbiederslijstEr is precies één instantie hiervan.ZorgaanbiederslijstDit is een eenling in het model.getalsverhoudinglogisch model

Logische basisklassen

BasisklasseDefinitieHerkomst
BackchanneluriZie adresseringsverantwoordelijkheden op de Interfaces-pagina. De domeinnaam is een fully-qualified domain name, conform RFC3696, sectie 2.logisch model
DatumTijdConform het type  xs:dateTime, zoals gespecificeerd in XML Schema 1.0 en inclusief een tijdzone-indicatie.logisch model
FrontchanneluriZie adresseringsverantwoordelijkheden op de Interfaces-pagina. De domeinnaam is een fully-qualified domain name, conform RFC3696, sectie 2 .logisch model
GegevensdienstIdString van minimaal één teken en maximaal 30 tekens.metamodel
HostnameZie adresseringsverantwoordelijkheden op de Interfaces-pagina.metamodel
InterfaceversieIdString van minimaal één en maximaal 30 tekens.metamodel

OAuthclientOrganisatienaam

Conform toepasselijk Oauthclient-namenbeleid.

metamodel
PositiefnummerEen geheel getal ongelijk 0.logisch model
SysteemrolcodeString van minimaal één teken en maximaal 30 tekens.metamodel
WeergavenaamString van minimaal drie en maximaal 50 tekens.metamodel
Zorgaanbiedernaam

Conform toepasselijk Zorgaanbiedersnamenbeleid.

metamodel

Verband met metamodel

Klasse in logisch modelHerkomstklasse in metamodel
AbonnerenZorgaanbiederAbonnerenOpGevensdienstInterfaceversie
AuthorizationEndpointAuthorizationEndpoint
Gegevensdienst_GNLGegevensdienst
Gegevensdienst_OCLOAuthClientGegevensdienstInterfaceversie
Gegevensdienst_ZALZorgaanbiederGegevensdienstInterfaceversie
Interfaceversie_OCLInterfaceversie
Interfaceversie_ZALInterfaceversie
MedMijNodeMedMijNode
OAuthclientOAuthclient
ResourceEndpointResourceEndpoint
ResourceNotificationEndpointResourceNotificationEndpoint
SubscriptionNotificationEndpointSubscriptionNotificationEndpoint
SysteemrolZorgaanbiederGegevensdienstSysteemrol
TokenEndpointTokenEndpoint
ZorgaanbiederZorgaanbieder

Catalogus

Logisch model

Logische invarianten

Betreft instanties van klasse ...InvariantComponentToelichtingAardHerkomst
Usecase

Voor elke Usecase u geldt: u.Weergavenaam = "Verzamelen" OF u.Weergavenaam = "Delen"

CatalogusDit koppelt de namen van de subklassen aan de weergavenamen.lokale afhankelijkheidmetamodel (bij Usecase)

Logische basisklassen

BasisklasseDefinitieHerkomst
DatumConform het type xs:date, zoals gespecificeerd in XML Schema 1.0.metamodel
GegevensdienstIdString van minimaal één teken en maximaal 30 tekens.metamodel
GegevensdienstnaamString van minimaal drie en maximaal 50 tekens.metamodel
NietnegatiefgetalConform het type  xs:nonNegativeInteger, zoals gespecificeerd in XML Schema 1.0.metamodel
SysteemrolcodeString van minimaal één teken en maximaal 30 tekens.metamodel
WeergavenaamString van minimaal drie en maximaal 50 tekens.metamodel

Verband met metamodel

Klasse/waarde in logisch modelHerkomstklasse in metamodel
GegevensdienstGegevensdienst
Usecase Usecase , VerzamelenUsecase en DelenUsecase

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.


MedMijStelselNode

Logisch model

Logische invarianten

Betreft instanties van klasse ...InvariantComponentToelichtingAard
MedMijStelselNode

Voor de MedMijStelselNode m geldt: m.Hostname ← m.Node.Hostname

MedMijStelselNodeZo erft de MedMijStelselNode, van de Node die het is, de Hostname.vererving

Logische basisklassen

BasisklasseDefinitieHerkomst
HostnameZie adresseringsverantwoordelijkheden op de Interfaces-pagina.metamodel

Verband met metamodel

Klasse in logisch modelHerkomstklasse in metamodel
MedMijStelselNodeMedMijStelselNode

Rapporten

Logisch model

Logische invarianten

Betreft instanties van logische klasse ...InvariantComponentToelichtingAardHerkomst
BeheerrapportEr is precies één instantie hiervan.BeheerrapportDit is een eenling in het model.getalsverhoudinglogisch model
Gegevensdienst_BRVoor elke Gegevensdienst_BR g met haar corresponderende ZorgaanbiederGegevensdienst z geldt:
g.GegevensdienstId
 ← z.Gegevensdienst.GegevensdienstId
BeheerrapportZo erft het Beheerrapport de GegevensdienstId's van de Catalogus.verervinglogisch model
Gegevensdienst_PRVoor elke Gegevensdienst_PR g met haar corresponderende ZorgaanbiederGegevensdienst z geldt:
g.GegevensdienstId
 ← z.Gegevensdienst.GegevensdienstId
PortabiliteitsrapportZo erft het Portabiliteitsrapport de GegevensdienstId's van de Catalogus.verervinglogisch model
PortabiliteitsrapportEr is precies één instantie hiervan.PortabiliteitsrapportDit is een eenling in het model.getalsverhoudinglogisch model

Logische basisklassen

BasisklasseDefinitieHerkomst
DatumTijdConform het type  xs:dateTime, zoals gespecificeerd in XML Schema 1.0 en inclusief een tijdzone-indicatie.logisch model
DeelnemerIdString van minimaal één en maximaal 30 tekens.metamodel
GegevensdienstIdString van minimaal één teken en maximaal 30 tekens.metamodel
NietnegatiefgetalConform het type  xs:nonNegativeInteger, zoals gespecificeerd in XML Schema 1.0.logisch model
RequestUriString van minimaal twaalf en maximaal 2048 tekens.metamodel
Zorgaanbiedernaam

Conform toepasselijk Zorgaanbiedersnamenbeleid.

metamodel

Verband met metamodel

Klasse in logisch modelHerkomstklasse in metamodel
Gegevensdienst_BRGegevensdienst
Gegevensdienst_PRGegevensdienst
ResourceRequestResourceRequest
ZorgaanbiederZorgaanbieder
  • No labels