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: 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.
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
enGegevensdiensten
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 ... | Invariant | Component | Toelichting | Aard | Herkomst |
---|---|---|---|---|---|
Abonneren | Voor elk Abonneren a geldt: a.MaximaleDuur <= de maximale duur van Abonnementen op die Gegevensdienst zoals in de /wiki/spaces/MMCatalogus/overview 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 /wiki/spaces/MMCatalogus/overview heeft aangegeven. | niet-lokale afhankelijkheid | metamodel (zie ZorgaanbiederGegevensdienst |
Abonneren | Voor elk Abonneren a geldt: a.SubscriptionEndpointuri ← | Zorgaanbiederslijst | Zie de Interfaces-pagina. | vererving | logisch model |
AuthorizationEndpoint | Voor elk AuthorizationEndpoint a geldt: a.AuthorizationEndpointuri ← | Zorgaanbiederslijst | Zie de Interfaces-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: | 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 OAuthclient-namenbeleid. | Applicatie | Zie het OAuthclient-namenbeleid. | 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 ← | Zorgaanbiederslijst | Zie de Interfaces-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 Interfaces-pagina. | OAuthclientlist | Zie de Interfaces-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 Interfaces-pagina. | OAuthclientlist | Zie de Interfaces-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 ← | Zorgaanbiederslijst | Zie de Interfaces-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 |
---|---|---|
Backchanneluri | Zie adresseringsverantwoordelijkheden op de Interfaces-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 Interfaces-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 Interfaces-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 |
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 ... | 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:
| 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 | 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 | metamodel |
LangeWeergavenaam | String van minimaal één en maximaal 125 tekens. | metamodel |
NederlandseDatum | Semantiek: datum volgens lokale Nederlandse tijd. Syntax: datum volgens het type | 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
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
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 |
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
enGegevensdiensten
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 ... | Invariant | Component | Toelichting | Aard | Herkomst |
---|---|---|---|---|---|
Abonneren | Voor elk Abonneren a geldt: a.MaximaleDuur <= de maximale duur van Abonnementen op die Gegevensdienst zoals in de /wiki/spaces/MMCatalogus/overview 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 /wiki/spaces/MMCatalogus/overview heeft aangegeven. | niet-lokale afhankelijkheid | metamodel (zie ZorgaanbiederGegevensdienst |
Abonneren | Voor elk Abonneren a geldt: a.SubscriptionEndpointuri ← | Zorgaanbiederslijst | Zie de Interfaces-pagina. | vererving | logisch model |
AuthorizationEndpoint | Voor elk AuthorizationEndpoint a geldt: a.AuthorizationEndpointuri ← | Zorgaanbiederslijst | Zie de Interfaces-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: | 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 OAuthclient-namenbeleid. | Applicatie | Zie het OAuthclient-namenbeleid. | 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 ← | Zorgaanbiederslijst | Zie de Interfaces-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 Interfaces-pagina. | OAuthclientlist | Zie de Interfaces-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 Interfaces-pagina. | OAuthclientlist | Zie de Interfaces-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 ← | Zorgaanbiederslijst | Zie de Interfaces-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 |
---|---|---|
Backchanneluri | Zie adresseringsverantwoordelijkheden op de Interfaces-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 Interfaces-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 Interfaces-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 |
Catalogus
Logisch model
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:
| 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 | 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 | metamodel |
LangeWeergavenaam | String van minimaal één en maximaal 125 tekens. | metamodel |
NederlandseDatum | Semantiek: datum volgens lokale Nederlandse tijd. Syntax: datum volgens het type | 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
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
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 |