Document toolboxDocument toolbox

Afsprakenset release 1.4.0 > Architectuur en technische specificaties > Informatiemodellen > Logische modellen

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 /wiki/spaces/MMCatalogus/overview 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 /wiki/spaces/MMCatalogus/overview 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 OAuthclientlist 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
Gegevensdienst_ZKLVoor elke Gegevensdienst_ZKL g met haar corresponderende ZorgaanbiederGegevensdienst z geldt:
g.GegevensdienstId
 ← z.Gegevensdienst.GegevensdienstId
ZorgaanbiederskoppellijstZo erft de Zorgaanbiederskoppellijst de GegevensdienstId's van de Catalogus.verervinglogisch model
GegevensdienstnamenlijstEr is precies één instantie hiervan.GegevensdienstnamenlijstDit is een eenling in het model.getalsverhoudinglogisch model
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 de Catalogus.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
ZorgaanbiederskoppellijstEr is precies één instantie hiervan.ZorgaanbiederskoppellijstDit 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_OCLOAuthclientInterfaceversie
MedMijNodeMedMijNode
OAuthclientOAuthclient
ResourceEndpointResourceEndpoint
ResourceNotificationEndpointResourceNotificationEndpoint
SubscriptionNotificationEndpointSubscriptionNotificationEndpoint
SysteemrolZorgaanbiederGegevensdienstInterfaceversieSysteemrol
TokenEndpointTokenEndpoint
Zorgaanbieder_ZALZorgaanbieder
Zorgaanbieder_ZKLZorgaanbieder

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

Catalogus

Logisch model

Logische invarianten

Betreft instanties van klasse ...InvariantComponentToelichtingAardHerkomst
CatalogusEr is precies één instantie hiervan.CatalogusDit is een eenling in het model.getalsverhoudinglogisch 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.BedrijfsrolPatiëntBedrijfsrol gaat vooraf aan een Transactie t met t.BedrijfsrolZorgaanbiederBedrijfsrol;
  • bij meerdere Transacties van hetzelfde type: in tijdsvolgorde van de transactie.
CatalogusDe 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 afhankelijkheidlogisch model

Logische basisklassen

BasisklasseDefinitieHerkomst
BedrijfsrolWeergavenaamString met de waarde "Patiënt" of "Zorgaanbieder".logisch model
DeelnemersrolWeergavenaamString 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
GegevensdienstIdString 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
LangeWeergavenaamString 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
NietnegatiefgetalConform het type  xs:nonNegativeInteger, zoals gespecificeerd in XML Schema 1.0.metamodel
PositiefnummerEen geheel getal ongelijk 0.logisch model
SysteemrolcodeString 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
UsecaseWeergavenaamString met de waarde "Verzamelen" of "Delen".logisch model
VersienummerString van minimaal één 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
InterfaceversieInterfaceversie
TransactieTransactie
BedrijfsrolBedrijfsrol
OndersteuningsloketOndersteuningsloket
KwalificatieloketKwalificatieloket
TransactieaanduidingTransactieaanduiding
VolledigetransactienaamVolledigetransactienaam
DeelnemersrolDeelnemersrol
VereisteGegevensdienstGegevensdienst

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

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

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

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 /wiki/spaces/MMCatalogus/overview 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 /wiki/spaces/MMCatalogus/overview 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 OAuthclientlist 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
Gegevensdienst_ZKLVoor elke Gegevensdienst_ZKL g met haar corresponderende ZorgaanbiederGegevensdienst z geldt:
g.GegevensdienstId
 ← z.Gegevensdienst.GegevensdienstId
ZorgaanbiederskoppellijstZo erft de Zorgaanbiederskoppellijst de GegevensdienstId's van de Catalogus.verervinglogisch model
GegevensdienstnamenlijstEr is precies één instantie hiervan.GegevensdienstnamenlijstDit is een eenling in het model.getalsverhoudinglogisch model
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 de Catalogus.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
ZorgaanbiederskoppellijstEr is precies één instantie hiervan.ZorgaanbiederskoppellijstDit 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_OCLOAuthclientInterfaceversie
MedMijNodeMedMijNode
OAuthclientOAuthclient
ResourceEndpointResourceEndpoint
ResourceNotificationEndpointResourceNotificationEndpoint
SubscriptionNotificationEndpointSubscriptionNotificationEndpoint
SysteemrolZorgaanbiederGegevensdienstInterfaceversieSysteemrol
TokenEndpointTokenEndpoint
Zorgaanbieder_ZALZorgaanbieder
Zorgaanbieder_ZKLZorgaanbieder
 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

Logische invarianten

Betreft instanties van klasse ...InvariantComponentToelichtingAardHerkomst
CatalogusEr is precies één instantie hiervan.CatalogusDit is een eenling in het model.getalsverhoudinglogisch 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.BedrijfsrolPatiëntBedrijfsrol gaat vooraf aan een Transactie t met t.BedrijfsrolZorgaanbiederBedrijfsrol;
  • bij meerdere Transacties van hetzelfde type: in tijdsvolgorde van de transactie.
CatalogusDe 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 afhankelijkheidlogisch model

Logische basisklassen

BasisklasseDefinitieHerkomst
BedrijfsrolWeergavenaamString met de waarde "Patiënt" of "Zorgaanbieder".logisch model
DeelnemersrolWeergavenaamString 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
GegevensdienstIdString 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
LangeWeergavenaamString 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
NietnegatiefgetalConform het type  xs:nonNegativeInteger, zoals gespecificeerd in XML Schema 1.0.metamodel
PositiefnummerEen geheel getal ongelijk 0.logisch model
SysteemrolcodeString 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
UsecaseWeergavenaamString met de waarde "Verzamelen" of "Delen".logisch model
VersienummerString van minimaal één 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
InterfaceversieInterfaceversie
TransactieTransactie
BedrijfsrolBedrijfsrol
OndersteuningsloketOndersteuningsloket
KwalificatieloketKwalificatieloket
TransactieaanduidingTransactieaanduiding
VolledigetransactienaamVolledigetransactienaam
DeelnemersrolDeelnemersrol
VereisteGegevensdienstGegevensdienst

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