Skip to end of metadata
Go to start of metadata


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 worden gebruikt in de hoofdfunctie Coördinatie van MedMij. Het metamodel is allereerst de basis voor de structuur van:

  • de Zorgaanbiederslijstwaaraan de OAuth Client kan zien welke Zorgaanbieders momenteel welke Gegevensdiensten aanbieden en waarmee hij, gegeven een zekere Interfaceversie, 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);
  • de Whitelist, waarmee de Nodes elkaar accepteren als MedMij-nodes;
  • de OAuthclientlist, waarin de OAuth Authorization Server:
  • 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 lijst, de Catalogus, wordt door MedMij gepubliceerd als annex van het MedMij Afsprakenstelsel, op deze pagina. Ten slotte is het metamodel de conceptuele basis voor twee rapportages die van Deelnemers worden verwacht:

  • het Beheerrapport, waarmee elke Deelnemer de Beheerorganisatie periodiek inlicht over kentallen over het functioneren van het MedMij-netwerk;
  • het Portabiliteitsrapport, waarmee de Persoon door diens Dienstverlener Persoon wordt ingelicht over welke gezondheidsinformatie die Persoon van Zorgaanbieders in zijn PGO heeft verzameld, zodat hij een eventuele andere of nieuwe PGO opnieuw met dezelfde verzamelacties zou kunnen vullen. 

Voor alle zeven 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 negen modelgebieden: Rollen, Deelnemers, PGO'sZorgaanbieders, Gegevensdiensten, Informatiestandaarden, Netwerk, Changes en Gebruik. Linksboven de plaat van het metamodel staat in een kaartje hoe de verschillende gebieden gebruik maken van concepten uit andere gebieden.

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.

Toelichting

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

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.

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

Gegevensdiensten horen bij een Usecase en hebben een geldigheidsperiode. Bovendien wordt, door middel van het attribuut Vereist, van sommige Gegevensdiensten vereist dat, als een Zorgaanbieder die Gegevensdienst aanbiedt, hij ook zekere andere Gegevensdiensten moet aanbieden. Vaak zal die lijst leeg zijn, maar het heeft bijvoorbeeld weinig zin het Delen van een afspraakverzoek aan te bieden, zonder ook het Verzamelen van het antwoord daarop aan te bieden. De klasse RolInGegevensdienst wordt gebruikt om, via de Deelnemer, de MedMij-rollen DienstverlenerpersoonDeelnemersrol en DienstverlenerzorgaanbiederDeelnemersrol te verbinden met de dienovereenkomstige rollen die Nictiz in het Informatiestandaarden-domein heeft geformuleerd, namelijk 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 elke Systeemrol hoort een Informatiestandaard. Systeemrollen worden gegroepeerd in Systeemrolverzamelingen die samen met een Usecase een Gegevensdienst vormen. Een actueel voorbeeld van een Systeemrolverzameling is een verzameling van vier Systeemrollen waarvan er twee (één voor elke betrokken Bedrijfsrol) een overzicht van beschikbare PDF-documenten uitwisselen en twee (opnieuw één voor elke betrokken Bedrijfsrol) een PDF-document uit dat overzicht uitwisselen. Gegevensdiensten 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 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.

Interfaces zijn geversioneerd: verschillende versies van interfaces kunnen tegelijkertijd op het MedMij-netwerk worden aangeboden. Daarom is er de klasse Interfaceversie in het modelgebied Changes. Alle endpoints in de Zorgaanbiederslijst en Oauth Client List (zie onder) horen bij één Interfaceversie

Een Zorgaanbieder kan de maximale abonnementsduur die hij aanbiedt voor een Gegevensduur, op een Interfaceversie, beperken. Daarbij moet hij echter blijven onder de maximale duur die MedMij voor die Gegevensdienst in de Catalogus heeft aangegeven. De maximale duur geeft de doorlooptijd aan in dagen waarbij de waarde 0 aangeeft dat een abonnement niet wordt ondersteund.

Bij een ZorgaanbiederGegevensdienst hoort één AuthorizationEndpoint, één TokenEndpoint en, indien daarop ook Abonnementen worden aangeboden, één SubscriptionEndpoint. Bij een ZorgaanbiederGegevensdienstSysteemrol hoort één ResourceEndpoint. Bij alle soorten endpoints noemt het metamodel het Endpointpath, het path in de URI waarmee de endpoints geadresseerd worden, en een Interfaceversion, waarmee gelijktijdig operationele versies van dezelfde endpoints kunnen worden onderscheiden. 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 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.

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

Ten behoeve van het Beheerrapport en het Portabiliteitsrapport moet door Deelnemers informatie kunnen worden overlegd over wat er op het MedMij-netwerk gebeurt. Deze informatie wordt opgespannen door het modelgebied Gebruik. Deze informatie is hoofdzakelijk gestoeld op requests die worden gedaan over het MedMij-netwerk. Die zijn er in zes soorten. Van elke request moet bekend zijn wat de RequestUri was en of de request al dan niet succesvol was.


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 lagen in de architectuur van het afsprakenstelsel. De betreffende laag is aangegeven door de inkleuringen van de klassen. Alleen bij de Nictiz-klassen in het Register van Informatiestandaarden hebben we dit achterwege gelaten.


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

  • MedMij-zorgaanbiedernamen voor Zorgaanbieders, zoals beschreven in verantwoordelijkheid 13 op 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. 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.

Invarianten

Het diagram hierboven wordt geordend door (bestaans)afhankelijkheden tussen klassen. Binnen deze ordening bestaan er ook nog consistentie-eisen aan de instanties van deze klassen. Dit zijn de invarianten die in onderstaande tabel zijn opgenomen. Wat een invariant uitdrukt is dat een instantie van de betreffende klasse niet bestaat als zij niet aan de invariant voldoet. De tabel doet verder geen uitspraken over hoe de bewaking van deze consistentie wordt geïmplementeerd. In menige implementatie zullen tijdelijke inconsistenties worden toegestaan en pas later geweigerd of verholpen worden. Dat kan op vele manieren, maar het MedMij Afsprakenstelsel wil grote vrijheid laten in hoe de consistentie in registraties wordt geborgd.

De pad-expressies in de invarianten bestaan uit namen gescheiden door punten. Vanuit een zekere klasse wordt altijd een stap gemaakt naar een klasse waarvan eerstgenoemde onmiddellijk bestaansafhankelijk is. De naam van de zijde van de associatie waarover de stap wordt gemaakt wordt geacht de naam te dragen van de klasse aan het betreffende eindpunt van de associatie, de bestemming van de stap dus.

Betreft instanties van klasse ...InvariantModeldomeinToelichtingAard
AbonnerenUsecaseEr is precies één instantie hiervan.RollenDit is een eenling in het model.getalsverhouding
AuthotizationEndpoint

Voor elk AuthorizationEndpoint a en 
voor elke DeelnemerInRolZorgaanbiederGegevensdienst d,
geldt:

ALS d.ZorgaanbiederGegevensdienstInterfaceversie =
a.ZorgaanbiederGegevensdienstInterfaceversie

DAN d.DeelnemerInRol.Deelnemera.MedMijNode.DeelnemerNode.Deelnemer

ZorgaanbiedersDeze invariant regelt dat de URI van elk authorization endpoint hoort bij een MedMijNode die van dezelfde Deelnemer is die ook de betreffende ZorgaanbiederGegevensdienst aanbiedt.niet-lokale afhankelijkheid
Bedrijfsrol Elke Bedrijfsrol is hetzij PatiëntBedrijfsrol of ZorgaanbiedersBedrijfsrol.InformatiestandaardenDit is een uitsluitende opsomming.opsomming
BedrijfsrolVoor elke Bedrijfsrol b geldt:
ALS(
b : PatiëntBedrijfsrol DAN b.Weergavenaam = "Patiënt";
b : ZorgaanbiedersBedrijfsrol DAN b.Weergavenaam = "Zorgaanbieder";

ANDERS FOUT) 
InformatiestandaardenDit koppelt de namen van de subklassen aan de weergavenamen.lokale afhankelijkheid
BronBusinessrolEr is precies één instantie hiervan.DeelnemersDit is een eenling in het model.getalsverhouding
Businessrol

Voor elke Businessrol b geldt:
ALS(
b : BronBusinessrol DAN b.Weergavenaam = "Bron";
b : LezerBusinessrol DAN b.Weergavenaam = "Lezer";
b : UitgeverBusinessrol DAN b.Weergavenaam = "
Uitgever";
ANDERS FOUT) 

RollenDit koppelt de namen van de subklassen aan de weergavenamen.lokale afhankelijkheid
DeelnemerInRol

Voor elke DeelnemerInRol d geldt:
d.Deelnemer.Deelnemersrol en d.RolInGegevensdienst. DeelnemersrolUsecaseBusinessrol.Deelnemersrol zijn identiek.

DeelnemersDe betreffende Deelnemer kan zich alleen aanmelden voor rollen die hem door de Catalogus geboden worden.niet-lokale afhankelijkheid
DeelnemerInRolZorgaanbiederGegevensdienstVoor elke DeelnemerInRolZorgaanbiederGegevensdienst d geldt:
d. ZorgaanbiederGegevensdienst.Gegevensdienst = d.DeelnemerInRol.RolInGegevensdienst.Gegevensdienst
ZorgaanbiedersEen Deelnemer kan alleen gezag doen gelden over de opname, in de Zorgaanbiederslijst, van een Gegevensdienst bij een Zorgaanbieder, als die Deelnemer ook voor die Gegevensdienst is toegelaten in MedMij.niet-lokale afhankelijkheid
Dienstverlenerpersoon Er bestaat hooguit één instantie hiervan bij één Deelnemer,
en precies één als de Deelnemersrol van laatstgenoemde van het type DienstverlenerpersoonDeelnemersrol is.
DeelnemersEen Deelnemer heet een Dienstverlenerpersoon dan en slechts dan als hij de toepasselijke rol speelt.getalsverhouding
Deelnemersrol

Voor elke Deelnemersrol d geldt:
ALS(
d : DienstverlenerpersoonDeelnemersrol DAN d.Weergavenaam = "Dienstverlener persoon";
d : DienstverlenerzorgaanbiederDeelnemersrol DAN d.Weergavenaam = "Dienstverlener zorgaanbieder";
ANDERS FOUT) 

RollenDit koppelt de namen van de subklassen aan de weergavenamen.lokale afhankelijkheid
DeelnemersrolBusinessrol

Er bestaan precies drie instanties hiervan, namelijk:

  • één zodanig dat DeelnemersrolBusinessrol.Deelnemersrol : DienstverlenerpersoonDeelnemersrol en DeelnemersrolBusiness.Businessrol : UitgeverBusinessrol;
  • één zodanig dat DeelnemersrolBusinessrol.Deelnemersrol : DienstverlenerzorgaanbiederDeelnemersrol en DeelnemersrolBusiness.Businessrol : BronBusinessrol; en
  • één zodanig dat DeelnemersrolBusinessrol. Deelnemersrol : DienstverlenerzorgaanbiederDeelnemersrol en DeelnemersrolBusiness. Businessrol : LezerBusinessrol;
RollenHier worden de twee juridische rollen Dienstverlener zorgaanbieder en Dienstverlener persoon verbonden aan de Businessrollen Uitgever, Bron en Lezer.rolbinding
DeelnemersrolUsecaseBusinessRolDeze klasse bestaat uit precies één instantie voor elke combinatie van een instantie d van DeelnemersrolBusinessrol en een instantie u van UsecaseBusinessrol waarvoor geldt: d.BusinessRol = u.BusinessRol. Rollen

Hier worden alle (namelijk vier) passende combinaties gemaakt van DeelnemersrolBusinessrol en UsecaseBusinessrol. Het gaat om: DienstverlenerPersoon/Uitgever/Verzamelen, DienstverlenerPersoon/Uitgever/Delen, DienstverlenerZorgaanbieder/Bron/Verzamelen en DienstverlenerZorgaanbieder/Lezer/Delen.

opsomming
DelenUsecaseEr is precies één instantie hiervan.RollenDit is een eenling in het model.getalsverhouding
DienstverlenerpersoonDeelnemersrolEr is precies één instantie hiervan.RollenDit is een eenling in het model.getalsverhouding
DienstverlenerzorgaanbiederDeelnemersrolEr is precies één instantie hiervan.RollenDit is een eenling in het model.getalsverhouding
GegevensdienstEr zijn nul of meer Gegevensdiensten.GegevensdienstenEr kunnen op enig moment nul Gegevensdiensten zijn.getalsverhouding
GegevensdienstVoor elke Gegevensdienst g geldt:
g
.Startdatum ligt voor g.Einddatum.
GegevensdienstenAnders heeft de geldigheidsperiode geen zin.lokale afhankelijkheid
Gegevensdienst

Voor elke Gegevensdienst g1 en g2 geldt:
ALS g2 voorkomt in g1.Vereist DAN
(g2 staat als Gegevensdienst in Catalogus EN
g1.Startdatum ligt niet voor g2.Startdatum
EN
g1.Einddatum ligt niet na g2.Einddatum)

GegevensdienstenEen geldige Gegevensdienst kan geen onbestaande of ongeldige Gegevensdienst vereisen. Een ontbrekende Einddatum (want die is optioneel) betekent "voor onbepaalde tijd" en ligt na elke "bepaalde tijd".lokale afhankelijkheid
Gegevensdienst

Voor elke Gegevensdienst g geldt:

g.Gegevensdienstnaam is een concatenatie van g.Usecase.Weergavenaam, g.Weergavenaam en de eerste twee cijferreeksen (voor zover aanwezig en met de scheidende punt) van g.Systeemrol.Informatiestandaard.Informatiestandaardversie, met een spatie als scheidingsteken.

GegevensdienstenDit standaardiseert de naamgeving van de Gegevensdiensten. Merk op dat van de Informatiestandaardversie alleen de eerste twee cijferreeksen worden overgenomen. Alle verdere cijferreeksen (voor patches bijvoorbeeld) worden als niet-significant gezien.niet-lokale afhankelijkheid
Gegevensdienst

Voor elke twee verschillende Gegevensdiensten g1 en g2 geldt:

g1.Gegevensdienstnaam /= g2.Gegevensdienstnaam

GegevensdienstenZo worden verschillende Gegevensdiensten niet verward door eenzelfde naam.lokale afhankelijkheid
GepubliceerdeInterfaceversieEr is precies één instantie hiervan.ChangesDit is een eenling in het model.getalsverhouding
LezerBusinessrol

Er is precies één instantie hiervan.

RollenDit is een eenling in het model.getalsverhouding
MedMijnetwerkEr is precies één instantie hiervan.NetwerkDit is een eenling in het model.getalsverhouding
MedMijStelselNodeEr is precies één instantie hiervan.Netwerk Zonder MedMijStelselNode geen MedMijNetwerk en geen Whitelist.getalsverhouding
NodeDe hostname van een Node bevat een domeinnaam die een fully-qualified domain name is, conform RFC3696, sectie 2.NetwerkDit is een maatregel tegen risico 4.4.1.4 uit RFC 6819.lokale afhankelijkheid
OAuthclientVoor elke OAuthclient o geldt:
o.OAuthclientOrganisatienaam voldoet aan het OAuthclient-namenbeleid
ApplicatieZie het OAuthclient-namenbeleid.lokale afhankelijkheid
OAuthclientAbonnerenOpGegevensdienstInterfaceversieElke OAuthclientAbonnerenOpGegevensdienstInterfaceversie heeft precies één ResourceNotificationEndpoint.PGO'sZo kan de Notification Client bij de combinatie van een OAuth Client en een Gegevensdienst het ResourceNotificationEndpoint vinden in de OAuthclientlist, voor zover die OAuth Client de betreffende Interfaceversie daarvoor ondersteund.getalsverhouding
OAuthclientAbonnerenOpGegevensdienstInterfaceversieElke OAuthclientAbonnerenOpGegevensdienstInterfaceversie heeft precies één SubscriptionNotificationEndpoint.PGO'sZo kan de Notification Client bij de combinatie van een OAuth Client en een Gegevensdienst het SubscriptionNotificationEndpoint vinden, in de OAuthclientlist, voor zover die OAuth Client de betreffende Interfaceversie daarvoor ondersteund.getalsverhouding
OAuthClientGegevensdienst

Voor elke OAuthClientGegevensdienst zg geldt:

ALS er een OAuthClientAbonnerenOpGegevensdienstInterfaceversie zagi1 is zodat:

  • zagi1.OAuthClientGegevensdienstInterfaceversie.
    ZorgaanbiederGegevensdienst = zg
    en
  • zagi1.OAuthClientGegevensdienstInterfaceversie.
    Interfaceversie
    is de GepubliceerdeInterfaceversie

DAN is er een OAuthClientAbonnerenOpGegevensdienstInterfaceversie zagi2 zodat:

  • zagi2.OAuthClientGegevensdienstInterfaceversie.
    ZorgaanbiederGegevensdienst = zg
    en
  • zagi2.OAuthClientGegevensdienstInterfaceversie.
    Interfaceversie
    is de VerplichteInterfaceversie
ZorgaanbiedersWanneer een OAuthClient Abonneren op een Gegevensdienst aanbiedt op de gepubliceerde Interfaceversie, moet hij dat ook aanbieden op de verplichte Interfaceversie. Zie Change- en releasebeleid.niet-lokale afhankelijkheid
ZorgaanbiederGegevensdienstVoor elke ZorgaanbiederGegevensdienst.Gegevensdienst. TransactieVerzameling.Transactie.Systeemrol s
waarvoor geldt dat s.Bedrijfsrol = ZorgaanbiederBedrijfsrol,
geldt dat er een ZorgaanbiederGegevensdienstSysteemrol z is
zodat z.Systeemrol = s.
ZorgaanbiedersAls in de Catalogus een Systeemrol voor Zorgaanbieders hoort bij een namens een zekere Zorgaanbieder aangeboden Gegevensdienst, dan moet namens dezelfde Zorgaanbieder ook deze Systeemrol worden aangeboden.niet-lokale afhankelijkheid

ZorgaanbiederGegevensdienst

Elke ZorgaanbiederGegevensdienst heeft precies één AuthorizationEndpoint.ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder en een Gegevensdienst het AuthorizationEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
ResourceEndpoint

Voor elk ResourceEndpoint r en 
voor elke DeelnemerInRolZorgaanbiederGegevensdienst d,
geldt:

ALS d.ZorgaanbiederGegevensdienstInterfaceversie =
r.ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.
ZorgaanbiederGegevensdienstInterfaceversie

DAN d.DeelnemerInRol.Deelnemerr.MedMijNode.DeelnemerNode.Deelnemer

ZorgaanbiedersDeze invariant regelt dat de URI van elk resource endpoint hoort bij een MedMijNode die van dezelfde Deelnemer is die ook de betreffende ZorgaanbiederGegevensdienst aanbiedt.niet-lokale afhankelijkheid
ResourceEndpoint

Voor elk ResourceEndpoint r geldt:

ALS r.ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.
ZorgaanbiederGegevensdienstInterfaceversie.
ZorgaanbiederGegevensdienst.Gegevensdienst is gebaseerd op een Informatiestandaard uit het Register Informatiestandaarden,

DAN is r gelijk aan wat in het technische ontwerp van de Informatiestandaard [base] heet.

ZorgaanbiedersDeze invariant regelt een goede scheiding, voor de genoemde klasse van Gegevensdiensten, tussen enerzijds de base URL en anderzijds de specifieke (FHIR-)resource.niet-lokale afhankelijkheid
ResourceNotificationEndpoint

Voor elk ResourceNotificationEndpoint s geldt:

s.MedMijNode.DeelnemerNode.Deelnemer = s.OAuthClientAbonnerenOpGegevensdienst.
OAuthclient.MedMijNode.DeelnemerNode.Deelnemer

PGO'sDe MedMijNode van elk ResourceNotificationEndpoint is van dezelfde Deelnemer als die van de betreffende OAuthClient.niet-lokale afhankelijkheid
RolInGegevensdienstDeze klasse bestaat uit precies één instantie r voor elke combinatie van een instantie d van r.DeelnemersrolUsecaseBusinessrol en een instantie g van r.Gegevensdienst waarvoor geldt: g.Usecase = d.UsecaseBusinessrol.UsecaseDeelnemersZo wordt ervoor gezorgd dat de Usecase die bij de betreffende Gegevensdienst hoort overeenkomt met de Usecase die bij de DeelnemersrolUsecaseBusinessrol hoort. Voor elke keer dat dat zo is, heeft deze klasse een instantie.niet-lokale afhankelijkheid
SubscriptionEndpoint

Voor elk SubscriptionEndpoint s en 
voor elke DeelnemerInRolZorgaanbiederGegevensdienst d,
geldt:

ALS d.ZorgaanbiederGegevensdienstInterfaceversie =
s.ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie.
ZorgaanbiederGegevensdienstInterfaceversie

DAN d.DeelnemerInRol.Deelnemers.MedMijNode.DeelnemerNode.Deelnemer

ZorgaanbiedersDeze invariant regelt dat de URI van elk subscription endpoint hoort bij een MedMijNode die van dezelfde Deelnemer is die ook de betreffende ZorgaanbiederGegevensdienst aanbiedt.niet-lokale afhankelijkheid
SubscriptionEndpoint

Voor elke ZorgaanbiederGegevensdienst zg,
voor elke ZorgaanbiedergegevensdienstInterfaceversie zgi van zg,
voor elke ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie  zag van zgi,
voor elk ResourceEndpoint r van zagi en
voor elke DeelnemerinRolZorgaanbiederGegevensdienst d van zg geldt: 

r.MedMijNode.DeelnemerNode.Deelnemer = d.DeelnemerInRol.Deelnemer 

ZorgaanbiedersDeze invariant regelt dat de URI van elk subscription endpoint hoort bij een MedMijNode die van dezelfde Deelnemer is die ook de betreffende ZorgaanbiederGegevensdienst aanbiedt. Hoewel de invariant spreekt van "elk SubscriptionEndpoint" en van "elke DeelnemerinRolZorgaanbiederGegevensdienst" zijn er van beide maar (maximaal) één voor elke ZorgaanbiederGegevensdienstInterfaceversie. Dat wordt geregeld door andere invarianten, maar daarvan wil deze invariant niet afhankelijk zijn.niet-lokale afhankelijkheid
SubscriptionNotificationEndpoint

Voor elk SubscriptionNotificationEndpoint s geldt:

s.MedMijNode.DeelnemerNode.Deelnemer = s.OAuthClientAbonnerenOpGegevensdienst.
OAuthclient.MedMijNode.DeelnemerNode.Deelnemer

PGO'sDe MedMijNode van elk SubscriptionNotificationEndpoint is van dezelfde Deelnemer als die van de betreffende OAuthClient.niet-lokale afhankelijkheid
Systeemrol

Voor elke Systeemrol s geldt:
ALS s.Bedrijfsrol : PatiëntBedrijfsrol
DAN geldt voor alle RolInGegevensdienst r:
(ALS s in r.Gegevensdienst.TransactieVerzameling 
DAN r.DeelnemersrolUsecaseBusinessrol.Deelnemersrol : DienstverlenerpersoonDeelnemersrol)

DeelnemersDit koppelt de MedMij-rol Dienstverlener Persoon aan de Nictiz-rol Patiënt.rolbinding
Systeemrol

Voor elke Systeemrol s geldt:
ALS s.Bedrijfsrol : ZorgaanbiederBedrijfsrol
DAN geldt voor alle RolInGegevensdienst r :
(ALS s in r.Gegevensdienst.TransactieVerzameling
DAN r.DeelnemersrolUsecaseBusinessrol.Deelnemersrol : DienstverlenerzorgaanbiederDeelnemersrol)

DeelnemersDit koppelt de MedMij-rol Dienstverlener Zorgaanbieder aan de Nictiz-rol Zorgaanbieder.rolbinding
TokenEndpoint

Voor elk TokenEndpoint t en 
voor elke DeelnemerInRolZorgaanbiederGegevensdienst d,
geldt:

ALS d.ZorgaanbiederGegevensdienstInterfaceversie =
t.ZorgaanbiederGegevensdienstInterfaceversie

DAN d.DeelnemerInRol.Deelnemert.MedMijNode.DeelnemerNode.Deelnemer

ZorgaanbiedersDeze invariant regelt dat de URI van elk token endpoint hoort bij een MedMijNode die van dezelfde Deelnemer is die ook de betreffende ZorgaanbiederGegevensdienst aanbiedt.niet-lokale afhankelijkheid
UitgeverBusinessrolEr is precies één instantie hiervan.RollenDit is een eenling in het model.getalsverhouding
Usecase

Voor elke Usecase u geldt:
ALS(
u : VerzamelenUsecase DAN u.Weergavenaam = "Verzamelen";
u : DelenUsecase DAN u.Weergavenaam = "Delen";
ANDERS FOUT) 

RollenDit koppelt de namen van de subklassen aan de weergavenamen.lokale afhankelijkheid
Usecase Businessrol

Er zijn precies vier instanties hiervan, namelijk:

  • één zodanig dat UseCaseBusinessrol.Businessrol : UitgeverBusinessrol en UseCaseBusinessrol.Usecase : VerzamelenUsecase;
  • één zodanig dat UseCaseBusinessrol.Businessrol : UitgeverBusinessrol en UseCaseBusinessrol.Usecase : DelenUsecase; en
  • één zodanig dat UseCaseBusinessrol.Businessrol : BronBusinessrol en UseCaseBusinessrol.Usecase : VerzamelenUsecase; en
  • één zodanig dat UseCaseBusinessrol.Businessrol : LezerBusinessrol en UseCaseBusinessrol.Usecase : DelenUsecase.
RollenHier wordt bepaald welke Businessrollen participeren in welke Usecases.opsomming
VerplichteInterfaceversieEr is precies één instantie hiervan.ChangesDit is een eenling in het model.getalsverhouding
VerzamelenUsecaseEr is precies één instantie hiervan.RollenDit is een eenling in het model.getalsverhouding
ZorgaanbiedersBedrijfsrolEr is precies één instantie hiervan.InformatiestandaardenDit is een eenling in het model.getalsverhouding
ZorgaanbiederElke Zorgaanbieder heeft minstens één ZorgaanbiederGegevensdienstZorgaanbiedersAnders is de opname van de Zorgaanbieder in de Zorgaanbiederslijst nutteloos.getalsverhouding
ZorgaanbiederElke Zorgaanbieder heeft bij elke Gegevensdienst ten hoogste één ZorgaanbiederGegevensdienst.ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder en een Gegevensdienst het AuthorizationEndpoint en TokenEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
Zorgaanbieder

Voor elke ZorgaanbiederGegevensdienst zg1 en voor elke Gegevensdienst g in zg1.Gegevensdienst.Vereist geldt:

er een ZorgaanbiederGegevensdienst zg2, zodat
zg1.Zorgaanbieder = zg2.Zorgaanbieder en
zg1.Gegevensdienst = g.

ZorgaanbiedersZo wordt ervoor gezorgd dat, als een Zorgaanbieder een Gegevensdienst aanbiedt die een andere vereist, deze Zorgaanbieder ook de andere aanbiedt.niet-lokale afhankelijkheid
Zorgaanbieder

Voor elke ZorgaanbiederGegevensdienst zg1 en voor elke Gegevensdienst g in zg1.Gegevensdienst.Vervangt geldt:

er zijn, anders dan zg1, geen ZorgaanbiederGegevensdiensten zg2, zodat zg1.Zorgaanbieder = zg2.Zorgaanbieder en

hetzij zg2.Gegevensdienst volgt g op of g volgt zg2.Gegevensdienst op.

'Opvolgen' is daarbij als volgt (recursief) gedefinieerd: Gegevensdienst h1 volgt Gegevensdienst h2 op als hetzij h1=h2 of h2 volgt een Gegevensdienst in h1.Vervangt op.

ZorgaanbiedersZo wordt ervoor gezorgd dat een Zorgaanbieder niet twee Gegevensdiensten kan aanbieden, waarvan de ene de andere (direct of indirect) vervangt. Vanwege de indirectie is een recursieve definitie nodig.niet-lokale afhankelijkheid
ZorgaanbiederAbonnerenOpGegevensdienst

Voor elke ZorgaanbiederGegevensdienst zg,
Voor elke ZorgaanbiederAbonnerenOpGegevensdienst zaog van zg,
voor elk SubscriptionEndpoint s van zaog en
voor elke DeelnemerinRolZorgaanbiederGegevensdienst d van zg geldt:

s.MedMijNode.DeelnemerNode.Deelnemer = d.DeelnemerInRol.Deelnemer

ZorgaanbiedersDeze invariant regelt dat elk subscription endpoint hoort bij een MedMijNode die van dezelfde Deelnemer is die ook de betreffende ZorgaanbiederGegevensdienst aanbiedt. Hoewel de invariant spreekt van "elk SubscriptionEndpoint" en van "elke DeelnemerinRolZorgaanbiederGegevensdienst" zijn er van beide maar één voor elke ZorgaanbiederGegevensdienst. Dat wordt geregeld door andere invarianten, maar daarvan wil deze invariant niet afhankelijk zijn.niet-lokale afhankelijkheid
ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie

Voor elke ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie zgi geldt:

zgi.ZorgaanbiederGegevensdienstInterfaceversie.
ZorgaanbiederGegevensdienst.Gegevensdienst.Usecase =
 VerzamelenUsecase

ZorgaanbiedersVooralsnog zijn alleen Abonnementen op verzamelende Gegevensdiensten mogelijk.niet-lokale afhankelijkheid
ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversieElke ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie heeft precies één SubscriptionEndpoint.ZorgaanbiedersZo kan de OAuth Client bij een Zorgaanbieder die Abonnementen op een Gegevensdienst biedt, per Interfaceversie het SubscriptionEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie

Voor elke ZorgaanbiederAbonnerenOpGegevensdienstInterfaceversie zgi geldt:

zgi.MaximaleDuur <= zgi.ZorgaanbiederGegevensdienstInterfaceversie.
ZorgaanbiederGegevensdienst.Gegevensdienst.MaximaleDuur

ZorgaanbiedersEen Zorgaanbieder kan de maximale abonnementsduur die hij aanbiedt voor een Gegevensduur, op een Interfaceversie, beperken. Daarbij moet hij echter blijven onder de maximale duur die MedMij voor die Gegevensdienst in de Catalogus heeft aangegeven.niet-lokale afhankelijkheid
ZorgaanbiederGegevensdienst

Voor elke ZorgaanbiederGegevensdienst zg geldt:

ALS er een ZorgaanbiederGegevensdienstInterfaceversie zgi1 is zodat:

  • zgi1.ZorgaanbiederGegevensdienst = zg en
  • zgi1.Interfaceversie is de GepubliceerdeInterfaceversie

DAN is er een ZorgaanbiederGegevensdienstInterfaceversie zgi2 zodat:

  • zgi2.ZorgaanbiederGegevensdienst = zg en
  • zgi2.Interfaceversie is de VerplichteInterfaceversie
ZorgaanbiedersWanneer een Zorgaanbieder een Gegevensdienst aanbiedt op de gepubliceerde Interfaceversie, moet hij deze ook aanbieden op de verplichte Interfaceversie. Zie Change- en releasebeleid.niet-lokale afhankelijkheid
ZorgaanbiederGegevensdienst

Voor elke ZorgaanbiederGegevensdienst zg geldt:

ALS er een ZorgaanbiedersAbonnerenOpGegevensdienstInterfaceversie zagi1 is zodat:

  • zagi1.ZorgaanbiederGegevensdienstInterfaceversie.
    ZorgaanbiederGegevensdienst = zg
    en
  • zagi1.ZorgaanbiederGegevensdienstInterfaceversie.
    Interfaceversie
    is de GepubliceerdeInterfaceversie

DAN is er een ZorgaanbiedersAbonnerenOpGegevensdienstInterfaceversie zagi2 zodat:

  • zagi2.ZorgaanbiederGegevensdienstInterfaceversie.
    ZorgaanbiederGegevensdienst = zg
    en
  • zagi2.ZorgaanbiederGegevensdienstInterfaceversie.
    Interfaceversie
    is de VerplichteInterfaceversie
ZorgaanbiedersWanneer een Zorgaanbieder Abonneren op een Gegevensdienst aanbiedt op de gepubliceerde Interfaceversie, moet hij dat ook aanbieden op de verplichte Interfaceversie. Zie Change- en releasebeleid.niet-lokale afhankelijkheid
ZorgaanbiederGegevensdienstVoor elke ZorgaanbiederGegevensdienst.Gegevensdienst. TransactieVerzameling.Transactie.Systeemrol s
waarvoor geldt dat s.Bedrijfsrol = ZorgaanbiederBedrijfsrol,
geldt dat er een ZorgaanbiederGegevensdienstSysteemrol z is
zodat z.Systeemrol = s.
ZorgaanbiedersAls in de Catalogus een Systeemrol voor Zorgaanbieders hoort bij een namens een zekere Zorgaanbieder aangeboden Gegevensdienst, dan moet namens dezelfde Zorgaanbieder ook deze Systeemrol worden aangeboden.niet-lokale afhankelijkheid

ZorgaanbiederGegevensdienst

Elke ZorgaanbiederGegevensdienst heeft precies één AuthorizationEndpoint.ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder en een Gegevensdienst het AuthorizationEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
ZorgaanbiederGegevensdienstElke ZorgaanbiederGegevensdienst heeft precies één TokenEndpoint.ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder en een Gegevensdienst het TokenEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
ZorgaanbiederGegevensdienstElke ZorgaanbiederGegevensdienst heeft precies één DeelnemerInRolZorgaanbiederGegevensdienst d, en wel zo dat d.DeelnemerInRol.Deelnemer.Rol = DienstverlenerzorgaanbiederDeelnemersrol.ZorgaanbiedersZo is duidelijk welke DeelnemerInRol zorgt voor een ZorgaanbiederGegevensdienst en dat dat een Dienstverlener zorgaanbieder betreft.getalsverhouding en rolbinding
ZorgaanbiederGegevensdienstSysteemrolInterfaceversieElke combinatie van een ZorgaanbiederGegevensdienstInterfaceversie
en een Systeemrol heeft ten hoogste
één ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.
ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder, een Gegevensdienst en een Systeemrol het ResourceEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding

ZorgaanbiederGegevensdienstSysteemrolInterfaceversie

ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.
Systeemrol.Bedrijfsrol
= ZorgaanbiederBedrijfsrol
ZorgaanbiedersZorgaanbieders kunnen alleen Systeemrollen aanbieden die voor Zorgaanbieders bedoeld zijn.niet-lokale afhankelijkheid
ZorgaanbiederGegevensdienstSysteemrolInterfaceversieElke ZorgaanbiederGegevensdienstSysteemrolInterfaceversie heeft precies één ResourceEndpoint.ZorgaanbiedersZo kan de OAuth Client bij de combinatie van een Zorgaanbieder, een Gegevensdienst en een Systeemrol het ResourceEndpoint vinden, in de Zorgaanbiederslijst.getalsverhouding
ZorggebruikerBusinessrolEr is precies één instantie hiervan. Rollen Dit is een eenling in het model.getalsverhouding

Basisklassen

BasisklasseDefinitie
Datum Conform het type xs:date, zoals gespecificeerd in XML Schema 1.0.
DeelnemerIdString van minimaal één en maximaal 30 tekens.
EndpointpathZie adresseringsverantwoordelijkheden op de Interfaces-pagina.
GegevensdienstIdString van minimaal één en maximaal 30 tekens.
GegevensdienstnaamString van minimaal drie en maximaal 50 tekens.
HostnameZie adresseringsverantwoordelijkheden op de Interfaces-pagina.
Informatiestandaardnaam String van minimaal drie en maximaal 50 tekens.
InterfaceversieIdString van minimaal één en maximaal 30 tekens.
NietnegatiefgetalConform het type xs:nonNegativeInteger, zoals gespecificeerd in XML Schema 1.0.

OAuthclientOrganisatienaam

Conform toepasselijk Oauthclient-namenbeleid.

RequestUriString van minimaal twaalf en maximaal 2048 tekens.
SysteemrolcodeString van minimaal één en maximaal 30 tekens.
TransactienaamString van minimaal drie en maximaal 50 tekens.
VersienummerEén of meer cijferreeksen, elk bestaand uit één of meer cijfers 0 tot en met 9, gescheiden door een punt
WeergavenaamString van minimaal drie en maximaal 50 tekens.
YesNoConform het type xs:boolean, zoals gespecificeerd in XML Schema 1.0.
Zorgaanbiedernaam

Conform toepasselijk Zorgaanbiedersnamenbeleid.

  • No labels