Page Comparison

Toelichting
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 onder andere worden gebruikt in een aantal registers, catalogi en lijsten. Vier daarvan worden door MedMij Beheer gepubliceerd voor operationeel gebruik door Dienstverleners:

• de Zorgaanbiederslijst, waaraan de OAuth Client kan zien welke Zorgaanbieders momenteel welke Gegevensdiensten aanbieden en waarmee hij de betrokken technische adressen (URI's) vindt van de OAuth Authorization Server (twee endpoints: het Authorization Endpoint en het Token Endpoint) en de OAuth Resource Server (het Resource Endpoint en (optioneel) het Subscription Endpoint);
• de Whitelist, waarmee de Nodes elkaar accepteren als MedMij-nodes;
• de OAuthclientlist, waarin de OAuth Authorization Server:
  • een gebruikersvriendelijke naam van de OAuth Client kan vinden om te gebruiken in de toestemmingsverklaring danwel de bevestigingsverklaringtoestemmingsverklaringen en bevestigingsverklaringen;
  • kan zien voor welke Gegevensdiensten de OAuth Client gekwalificeerd is;
  • (optioneel) het technische adres (URI) kan vinden van het Notification Endpoint.
• de Gegevensdienstnamenlijst, waaraan de OAuth Client kan zien welke Weergavenamen de Gegevensdiensten hebben die op enig moment beschikbaar zijn op het MedMij-netwerk.

Een vijfde, de Catalogus, wordt door MedMij gepubliceerd als annex van het MedMij Afsprakenstelsel, op deze pagina. Voor alle vijf zijn logische modellen beschikbaar, op een aparte pagina, die implementaties zijn van het metamodel.

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.

Op enkele punten is afgeweken van deze modelleerstijl, door gebruik van:

• de uses-relatie, vooral in het Informatiestandaarden-domein, omdat dat domein niet onder beheer van MedMij valt;
• de aggregatie-relatie, idem;
• de objectgeoriënteerde specialisatie, namelijk waar we een opsommende definitie geven van Deelnemersrol, Businessrol, Usecase en Bedrijfsrol;
• attributen voor identificatie of omschrijving.

In al deze gevallen zouden ook associatieklassen gebruikt kunnen worden, maar zou dat de presentatie van het model onnodig compliceren.

Het metamodel is, voor het overzicht, geordend in een aantal modeldomeinen: Rollen, Deelnemers, Zorgaanbieders, Gegevensdiensten, Informatiestandaarden en Netwerk.

De namen van de klassen en de attributen beginnen allemaal met een hoofdletter. De rest van de namen bestaat uit enkel kleine letters, behalve daar waar de rest van de naam ook als aparte naam in het metamodel voorkomt, of er een eigennaam wordt gebruikt die anderszins eist. Het metamodel noteert dus OAuthclient, omdat de naam OAuth een eigennaam is waarin de A als hoofdletter wordt geschreven, en omdat de naam Client niet als aparte naam voorkomt in het metamodel. Het metamodel noteert ZorgaanbiederGegevensdienst, met een kapitale eerste G, omdat Gegevensdienst wel als aparte naam voorkomt.