Inleiding

Het metamodel ordent kernbegrippen uit het MedMij Afsprakenstelsel. Het is een conceptueel gegevensmodel, in de vorm van een UML-klassediagram. Het metamodel is gericht op het samenhangend beschrijven van begrippen en relaties die worden gebruikt in de hoofdfunctie Coördinatie van MedMij. Het metamodel is allereerst de basis voor de structuur van:

...

Voor alle zeven zijn logische modellen beschikbaar, op een aparte pagina, die implementaties zijn van het metamodel.

Model

Image RemovedImage Added

Het model

Het metamodel is in een bepaalde stijl opgezet, met vooral associatieklassen. Het voordeel daarvan is dat het metamodel zo aanpasbaar en uitbreidbaar mogelijk blijft. Veel voorkomende constructies, zoals attributen en specialisatie zijn allemaal implementaties van associatieklassen. Implementatie willen we echter aan de logische modellen en de technische modellen (de XML-schema's) overlaten. Een tweede voordeel is dat bestaansafhankelijkheidsrelaties expliciet worden. Bestaansafhankelijkheid wil zeggen dat de ene klasse betekenisloos is zonder de andere en dus dat eerstgenoemde klasse niet kan bestaan zonder laatstgenoemde. Bij een associatieklasse is die associatieklasse altijd bestaansafhankelijk van de twee klassen die het associeert.

...

Organisaties gebruiken Nodes waarvan zij de houder zijn. Als een Organisatie een Deelnemer is, zal zij zo'n Node als DeelnemerNode bij de MedMij-beheerorganisatie aanmelden. Op het MedMijnetwerk verschijnt zo'n DeelnemerNode als een MedMijNode. De Hostnames van deze MedMijNodes ontsluit de MedMij-beheerorganisatie over het MedMijnetwerk. De MedMijNodes gebruiken deze lijst als Whitelist, dat wil zeggen, om te bepalen of een Node die zich bij hen aandient, geautoriseerd is om op het MedMijnetwerk actief te zijn. Deze Whitelist verschijnt, als implementatiecomponent, pas in de logische modellen. Dat geldt ook voor de MedMijStelselNode, de Node via welke MedMij Beheer vier lijsten publiceert. De MedMijStelselNode staat niet expliciet op de Whitelist, maar is wel geautoriseerd deel te nemen op het MedMijnetwerk. Sterker, zonder de MedMijStelselNode kan het MedMijnetwerk niet werken.

Voor de MedMijNodes van Deelnemers die Dienstverlenerpersoon zijn (beter gezegd: voor de OAuth Clients op de applicatielaag gedurende de autorisatiefase van UCI Verzamelen en UCI Delen) bevat de OAuthclientlist gebruikersvriendelijke namen (Organisatienaam), om gebruikt te worden in de toestemmingsverklaring en de bevestigingsverklaring. Ook de OAuthclientlist is een implementatiecomponent en verschijnt pas in de logische modellen. Wanneer een OAuth Client (een PGO) het gebruiken van Abonnementen mogelijk maakt voor de Persoon, moet zij endpoints aanbieden voor de twee soorten notificaties die de Zorgaanbieder in dat kader moet kunnen sturen: een SubscriptionNotificationEndpoint en een ResourceNotificationEndpoint.

...

Onder in het model wordt het verband gelegd met de Zorgaanbieders. Dit modeldomein is de basis voor het logische model van de Zorgaanbiederslijst. Wanneer een Zorgaanbieder een zekere Gegevensdienst aanbiedt volgens een zekere Interfaceversie, hoort daarbij een ZorgaanbiederGegevensdienstInterfaceversie. Wanneer een Zorgaanbieder bovendien Abonnementen op deze Gegevensdienst aanbiedt, hoort daarbij een ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie. Deze klassen worden gebruikt om Zorggebruikers te informeren over wie van de Zorgaanbieders (Abonnementen op) welke Gegevensdiensten aanbieden. Binnen een Gegevensdienst zijn bovendien één of meerdere Systeemrollen aan de orde. Deze relatie is vervat in de klasse ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.

...

Deze onderdelen worden samen met de Hostname van de betreffende MedMijNode samengesteld tot een URI die geldt als het adres van het respectievelijke endpoint. Dat gebeurt in het logische model (met invarianten). De eisen aan al deze componenten en de wijzen van samenstellen tot de URI's staat beschreven op de Interface-pagina.

...