Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Aanpassingen aan pagina.


Info

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

...

TODO: invoegen aangepast Metamodel



Info

Toelichting
De MedMij-beheerorganisatie houdt bij welke welke Organisaties, door het aangaan van een een Deelnemersovereenkomst, Deelnemer worden worden. Deelnemers zijn  zijn er in twee rollen: DienstverlenerpersoonDeelnemersrol en  en DienstverlenerzorgaanbiederDeelnemersrol. Deze komen overeen met de respectievelijke rollen rollen Dienstverlener Persoon en  en Dienstverlener Zorgaanbieder op de  op de juridische laag.

Organisaties gebruiken Nodes waarvan Organisaties gebruiken Nodes waarvan zij de houder zijn. Als een Organisatie een Deelnemer iseen 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 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 het MedMijnetwerk. De De MedMijNodes gebruiken  gebruiken deze lijst als als Whitelist, dat wil zeggen, om te bepalen of een een Node die  die zich bij hen aandient, geautoriseerd is om op het het MedMijnetwerk actief  actief te zijn. Deze Deze Whitelist verschijnt verschijnt, als implementatiecomponent, pas in de de logische modellen. Dat geldt ook voor de de MedMijStelselNode, de Node via welke welke MedMij Beheer vier  vier lijsten publiceert. De De MedMijStelselNode staat  staat niet expliciet op de de Whitelist, maar is wel geautoriseerd deel te nemen op het het MedMijnetwerk. Sterker, zonder de MedMijStelselNode kan het MedMijnetwerk niet de MedMijStelselNode kan het MedMijnetwerk niet werken.

Voor de OAuth Clients van Deelnemers die Dienstverlener persoon zijn bevat de OAuthclientlist gebruikersvriendelijke namen (Organisatienaam), om gebruikt te worden in de toestemmingsverklaringen en de bevestigingsverklaringen. Ook de OAuthclientlist is een implementatiecomponent en verschijnt pas in de logische modellen.

In het het Rollen-modeldomein verschijnen de de Deelnemerrollen, Businessrollen en en Usecases die  die in deze release van het MedMij Afsprakenstelsel bestaan, en hun toegestane combinaties. In hun toegestane combinaties. In het Deelnemers-modeldomein komen modeldomein komen de Deelnemers Deelnemers in het MedMij Afsprakenstelsel aan de orde en voor welke Zorgaanbieders zij  zij welke Gegevensdiensten ontsluiten ontsluiten.

Gegevensdiensten horen  horen bij een een Usecase en  en hebben een geldigheidsperiode. Bovendien wordt, door middel van het attribuut attribuut Vereist, van sommige sommige Gegevensdiensten vereist  vereist dat, als een Zorgaanbieder die Gegevensdienst aanbiedt als een Zorgaanbieder die Gegevensdienst aanbiedt, hij ook zekere andere andere Gegevensdiensten moet  moet aanbieden. Vaak zal die lijst leeg zijn, maar het heeft bijvoorbeeld weinig zin het het Delen van  van een afspraakverzoek aan te bieden, zonder ook het het Verzamelen van  van het antwoord daarop aan te bieden. De klasse RolInGegevensdienst wordt gebruikt om, via de Deelnemer, de MedMij-rollen DienstverlenerpersoonDeelnemersrol en DienstverlenerzorgaanbiederDeelnemersrol te rollen DienstverlenerpersoonDeelnemersrol en DienstverlenerzorgaanbiederDeelnemersrol te verbinden met de dienovereenkomstige rollen die Nictiz in het Informatiestandaarden-domein heeft geformuleerd, namelijk respectievelijk PatiëntBedrijfsrol en respectievelijk PatiëntBedrijfsrol en ZorgaanbiederBedrijfsrol.

De klassen in het modeldomein Informatiestandaarden, inclusief hun namen, moeten begrepen worden in de zin waarin Nictiz ze gebruikt in het kader van de Informatiestandaarden die voor gebruik binnen MedMij zijn toegelaten. Daarom zijn de randen van deze klassen gestippeld. Een Bedrijfsrol, waarvan er twee zijn (PatiëntBedrijfsrol en ZorgaanbiederBedrijfsrol), wordt aangenomen door een Systeemrol. Bij  Bij elke Systeemrol hoort een  hoort een Informatiestandaard. Systeemrollen worden  worden gegroepeerd in Systeemrolverzamelingen die samen in Systeemrolverzamelingen die samen met een Usecase een Gegevensdienst vormen vormen. Een actueel voorbeeld van een Systeemrolverzameling is  is een verzameling van vier Systeemrollen waarvan er twee (één voor elke betrokken Bedrijfsrol) een  een overzicht van beschikbare PDF-documenten uitwisselen en twee (opnieuw één voor elke betrokken Bedrijfsrol) een  een PDF-document uit dat overzicht uitwisselen. Gegevensdiensten worden  worden als geheel (dat wil zeggen met hun gehele Systeemrolverzameling) aan Zorggebruikers aangeboden en die gebruikers zullen deze ook ineens autoriseren.

Onder in het model wordt het verband gelegd met de de Zorgaanbieders. Dit modeldomein Dit modeldomein is de basis voor het het logische model van de  van de Zorgaanbiederslijst. Wanneer een Zorgaanbieder een zekere Gegevensdienst aanbiedteen Zorgaanbieder een zekere Gegevensdienst aanbiedt, hoort daarbij een een ZorgaanbiederGegevensdienst. Deze klasse kan worden gebruikt om om Zorggebruikers te  te informeren over wie van de Zorgaanbieders welke Gegevensdiensten aanbieden. Binnen een Gegevensdienst zijn de Zorgaanbieders welke Gegevensdiensten aanbieden. Binnen een Gegevensdienst zijn bovendien één of meerdere meerdere Systeemrollen aan  aan de orde. Deze relatie is vervat in de klasse klasse ZorgaanbiederGegevensdienstSysteemrol.

Bij een ZorgaanbiederGegevensdienst hoort één AuthorizationEndpoint en één TokenEndpoint, en bij een ZorgaanbiederGegevensdienstSysteemrol één ResourceEndpoint en (optioneel) één SubscriptionEndpoint. Bij alle soorten endpoints noemt het metamodel het Endpointpath, het path in de URI waarmee de endpoints geadresseerd worden. In deze versie van het MedMij Afsprakenstelsel worden op zowel frontchannel als backchannel de standaard IANA-poort voor https gebruikt. Er hoeven in de endpointadressen dus geen poortnummers te worden genoemd.

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

Eenzelfde Eenzelfde Zorgaanbieder kan  kan voor verschillende verschillende Gegevensdiensten van  van diensten van verschillende verschillende Deelnemers gebruik  gebruik maken. Maar bij één één ZorgaanbiederGegevensdienst hoort  hoort precies één één DeelnemerInRol. Voor dit doel is in het metamodel de klasse klasse DeelnemerInRolZorgaanbiederGegevensdienst opgenomen opgenomen, in het het Deelnemers-modeldomein.


Invarianten, dat wil zeggen, beperkingen die te allen tijden aan de orde zijn, staan onderaan in een separate tabel opgenomen. Daarvan bestaan verschillende soorten, genoemd in de rechterkolom:

  • Opsommingen stellen dat een zekere klasse een vast aantal expliciet benoemde instanties heeft.
  • Getalsverhoudingen vereisen getalsmatige eisen aan het aantal instanties van een klasse, of de verhouding tussen de aantallen in meerdere klassen.
  • Lokale afhankelijkheden stellen beperkingen aan de inhoudelijke verhoudingen tussen attributen van eenzelfde klasse.
  • Niet-lokale afhankelijkheid stellen beperkingen aan de inhoudelijke verhoudingen tussen instanties van verschillende klassen.
  • Rolbindingen beperken de rolcombinaties van verschillende rol-klassen. Zij komen overeen met onder andere de rolbindingen tussen de verschillende lagen.

De klassen in het metamodel horen bij de verschillende verschillende lagen in  in de architectuur van het afsprakenstelsel. De betreffende laag is aangegeven door de inkleuringen van de klassen. Alleen bij de Nictiz-klassen in het het Register van Informatiestandaarden hebben  hebben we dit achterwege gelaten.


Uit dit metamodel wordt duidelijk hoe in het MedMij Afsprakenstelsel MedMij Afsprakenstelsel met adressering wordt omgegaan. De adresseringssystematiek bestaat uit drie onderdelen:

  • MedMij-zorgaanbiedernamen voor voor Zorgaanbieders, zoals beschreven in verantwoordelijkheid 13 op de de Processen-en-Informatielaag;
  • Gegevensdiensten met Systeemrollen zoals opgenomen in de Catalogus, respectievelijk het Register van Informatiestandaarden;
  • Elke Zorgaanbieder kent bij elke ZorgaanbiederGegevensdienst (die hij aanbiedt via een Dienstverlener Zorgaanbieder) één AuthorizationEndpoint en één TokenEndpoint en bij elke ZorgaanbiederGegevensdienstSysteemrol daarbinnen één ResourceEndpoint en (optioneel) één SubscriptionEndpoint. De endpoints hebben elk een URI als technisch adres.

Daar waar in het metamodel sprake is van periodes, begrensd door een start en een eind, moeten deze start en eind opgevat als beginmomenten. Als het om een startdatum en einddatum gaat, zoals in de attributen van Gegevensdienst, worden dus de beginmomenten van die data bedoeld, om 00h00m00. De start wordt opgevat als het begin van de geldigheid, het eind als het begin van de ongeldigheid. De geldigheid loopt daarom vanaf start tot eind (niet tot en met). Dit betekent ook dat, als het eind ontbreekt, de geldigheid zich voor onbepaalde tijd uitstrekt.

...