Document toolboxDocument toolbox

RFC0023 Harmonisering Register van Informatiestandaarden en Catalogus: informatiemodellen

Samenvatting

Waarom is deze RFC nodig?

A. Onderscheid tussen Register en Catalogus is onwenselijk (en enkele kleine verbeterpunten)

A1. Het huidige onderscheid tussen het Register van Informatiestandaarden en de Catalogus is onnodig en niet goed verklaarbaar. Op dit moment bevat het Register de informatiestandaarden die zijn toegelaten voor gebruik binnen MedMij, en de Catalogus de gegevensdiensten. Beide hebben geen bestaansrecht zonder elkaar: een informatiestandaard zonder gegevensdienst kan niet worden gebruikt, een gegevensdienst zonder informatiestandaard kan niet worden gedefinieerd. Het onderscheid tussen de twee lijsten leidt tot een onnodige beheerlast, tot kans op fouten door inconsistenties, en tot verlaagde toegankelijkheid van de opzet van en verantwoordelijkheden van MedMij.

A2. Het Register bevat enkele concepten die vooral betrekking hebben op het ontwikkel- en toetsingsproces van standaarden, maar geen operationele betekenis hebben binnen MedMij. Dit leidt tot ambiguïteit in de formele status van een informatiestandaard.

A3. Binnen het MedMij Afsprakenstelsel is niet voorzien in een mogelijkheid om aan te geven welke versies van de afsprakenset gebruikt kunnen worden in combinatie met welke Gegevensdienst. De Catalogus bepaalt wel de geldigheidsperiode van een Gegevensdienst, maar in die periode kunnen er op enig moment twee versies van de afsprakenset (de gepubliceerde en de verplichte versie) in operationeel gebruik zijn. Het is denkbaar dat een Gegevensdienst niet compatibel is met beide versies.

B. Catalogus is niet machine-leesbaar

De Catalogus is maar beperkt machineleesbaar en de juistheid wordt ook maar beperkt afgedwongen door de implementatie van het logische model in ODS of HTML. Ook is (facultatief) geautomatiseerd gebruik door belanghebbende partijen daarmee moeilijk.

Oplossingsrichting

Ad A: Catalogus neemt functie van Register over en het concept Gegevensdienst krijgt een nog centralere rol

  1. Het Register van Informatiestandaarden komt te vervallen. De Catalogus blijft het overzicht waarin de binnen MedMij te gebruiken gegevensdiensten zijn gedefinieerd. Een geldige gegevensdienst is gebaseerd op (delen van) informatiestandaarden die geschikt zijn bevonden voor gebruik binnen MedMij. Niet langer worden informatiestandaarden zelfstandig toegelaten tot gebruik binnen MedMij. Een goede toetsing kan alleen plaatsvinden als ook de manier waarop de informatiestandaard binnen MedMij wordt gebruikt helder is. Uiteraard kan bij informatiestandaarden die in meerdere gegevensdiensten terugkomen gebruik worden gemaakt van de inzichten uit eerdere beoordelingen.
  2. In de Catalogus worden enkele concepten uit het voormalige Register toegevoegd, zoals de informatiestandaardnaam en -versie. Enkele concepten zullen niet meer terugkeren, bijvoorbeeld MedMijVolwassenheidsniveau, Publicatiedatum en de vermelding van de versie van de afsprakenset waartegen de informatiestandaard is getoetst. We gaan uit van de structuur van de informatiestandaarden van Nictiz. Mochten er gegevensdiensten worden gecreëerd die zijn gebaseerd op een andere interne structuur van de onderliggende informatiestandaard, dan kan op dat moment een specifiek stukje model worden overwogen.

  3. In het Testbeleid wordt de verwijzing naar het Register vervangen door een verwijzing naar de Catalogus. Het is ook wenselijk om de eisen aan de testresultaten, die een deelnemer moet overleggen om een gegevensdienst te kunnen ontsluiten, bij die gegevensdienst zelf te formuleren. Let wel, het gaat hier niet om de manier waarop een deelnemer wordt gekwalificeerd door de kwalificerende organisatie van de informatiestandaard, noch om het kwalificatie-aanbod. Het gaat om de ingangseisen: welke kwalificatieresultaten (of anderszins) moet een deelnemer overleggen bij de aanvraag voor de erkenning van de ontsluiting van een gegevensdienst? Die vraag wordt, volgens het Testbeleid, nu beantwoord in het Register, en deze RFC wijzigt dat in de Catalogus. In de Catalogus zal voor elke Systeemrol onder een Gegevensdienst een verwijzing naar het bijbehorende kwalificatieloket worden opgenomen.
  4. Eventuele gerelateerde (niet-controversiële) optimalisaties van de modellen en formuleringen kunnen worden meegenomen, zoals het expliciteren van de contactmogelijkheden van het ondersteuningsloket behorend bij een Systeemrol binnen een Gegevensdienst, het schrappen van de vaste opbouw van de Gegevensdienstnaam (die de vrijheid om gegevensdiensten samen te stellen onbedoeld kan beperken), het minder restrictief maken van de opbouw van het Versienummer (gebruikt binnen de klasse Informatiestandaard), het wegnemen van onnodige variëteit in attribuutnamen en basisklassen en het verlengen van het aantal toegestane karakters van enkele namen.
  5. De Catalogus wordt uitgebreid, zodanig dat een relatie tussen Gegevensdienst en Interfaceversie wordt gelegd als de Gegevensdienst kan worden gebruikt in combinatie met de betreffende Interfaceversie.
  6. De verplichting om een Gegevensdienst die wordt aangeboden op de gepubliceerde versie van de afsprakenset, ook aan te bieden op de verplichte versie van de afsprakenset, wordt aangepast zodanig dat die alleen geldt als de Gegevensdienst ook gebruikt kan worden in combinatie met de Interfaceversie die overeenkomt met de verplichte versie.
  7. De "Vervangt"-relatie tussen Gegevensdiensten wordt geschrapt. De relatie is nauwelijks gebruikt in de bestaande set Gegevensdiensten. Omwille van de interoperabiliteit in een decentraal stelsel is het ook niet wenselijk om Zorgaanbieders te verplichten uit een set sterk gelijkende Gegevensdiensten slechts één 'versie' of 'variant' aan te bieden.

Ad B: de Catalogus wordt gepubliceerd in XML-formaat en een human readable formaat

  1. De Catalogus wordt gepubliceerd in XML-formaat, naast een versie die gemakkelijk 'human readable' is (en die automatisch wordt gegenereerd zodat inhoudelijke consistentie te allen tijde kan worden geborgd). De Catalogus zal gepubliceerd worden op een openbare locatie. De zekerheden van de stelselnode zijn niet vereist (er is geen operationeel gebruik van de Catalogus voorgeschreven, buiten de informatie die al in de GNL staat) en het niet-openbare karakter ervan is ongewenst.
Aanpassing van

Er is geen aanpassing nodig van de logische modellen en XML-schema's van de OCL, de ZAL en de GNL.

Impact op rollen

Niet op de relatie Deelnemer - Deelnemer of Deelnemer - Beheerorganisatie. Wel op rollen die niet in het MedMij Afsprakenstelsel zijn beschreven (rollen gerelateerd aan het "stelsel van standaarden").

Impact op beheer
  • De (interne) beheerafspraken rond de Catalogus behoeven aanpassing.
  • De tooling voor het bewerken van de Catalogus verandert. Geavanceerde tooling is geen vereiste maar kan wel wenselijk zijn. In de meest minimale variant kan het XML-bestand van de Catalogus worden beheerd met een teksteditor.
  • De publicatieplaats van de Catalogus verandert.
Impact op RnA

Optioneel: mogelijkheid tot geautomatiseerd inlezen van de Catalogus.

Optioneel: mogelijkheid tot eenvoudige geautomatiseerde afleiding van de GNL uit de Catalogus.

Verplicht: bij de registratie van een ZAL-entry moet worden gecontroleerd op een geldige combinatie Gegevensdienst-Interfaceversie.

Verplicht: bij de publicatie van de nieuwe versie van de Catalogus moet deze worden ingelezen en worden gebruikt als bron voor andere het genereren van de Gegevensdienstnamenlijst.

Impact op Acceptatie

Geen.

Gerelateerd aan (Andere RFCs, PIM issues)

Geanalyseerd: de RFC's die per 30-10-2020 kandidaat zijn voor release 1.3.0.

Inhoudelijke relatie:

  • RFC0017 Koppelen van Zorgaanbiedersnamen (ter consultatie)
    • RFC0017 beïnvloedt RFC0023 v.v.: het is wenselijk de technische publicatiewijze van de Zorgaanbiederskoppellijst (ZKL) en de Catalogus gelijk te trekken.
    • RFC0023 beïnvloedt RFC0017: Interfaceversie wordt een mogelijk relevant attribuut voor de ZKL.
  • RFC0024 Harmonisatie Gegevensdiensten- en Stelselbeleid
    • RFC0023 beïnvloedt RFC0024: enkele onderwerpen uit het Governance-document voor het stelsel van standaarden worden in RFC0023 geregeld, mede reden waarom RFC0024 ervan uit gaat dat het Governance-document kan vervallen; RFC0023 is ook relevant op onderwerpen die (anders) in het Gegevensdienstenbeleid geregeld moeten worden, zoals de relatie met het Register van Informatiestandaarden en het vervallen van het "Vervangt"-attribuut bij Gegevensdiensten.
    • RFC0024 bevat een uitwerking van Gegevensdienstenbeleid waarin tevens de gevolgen van RFC0023 zijn opgenomen.
  • RFC0035 Verzamel RFC
    • De uitwerking van RFC0023 gaat ervan uit dat RFC0035 reeds is verwerkt.
    • RFC0035 gaat ervan uit dat RFC0023 in dezelfde release wordt verwerkt.

De volgende RFC's hebben geen inhoudelijke relatie, maar vragen wel om bijstelling van de informatiemodellen. Dit vraagt om extra coördinatie/integratie bij de uitwerking:

Geen relatie:

RFC0023 is gekoppeld aan intern issue AF-967.

Eigenaar
Implementatietermijn

De RFC heeft betrekking op de Catalogus en de afsprakenset. Die kennen elk een eigen releasecyclus. De Catalogus ontleent haar structuur echter aan de afsprakenset; synchronisatie van de wijzigingen in de Catalogus en de afsprakenset is dus nodig. De implementatie van deze RFC is beoogd voor:

  • Release 1.3.0 van de afsprakenset.
  • Per publicatiedatum van release 1.3.0: een nieuwe release (releasenr. 3) van de Catalogus. Deze Catalogus vervangt, zoals gebruikelijk, de voorgaande, en is van toepassing voor alle vigerende versies van de afsprakenset.
Motivatie verkorte RFC procedure (patch)

Geen patch benodigd.

Analyse van de impact van deze RFC op afsprakenset release 1.2.0 (de enig andere release van de afsprakenset, naast 1.3.0, die gebruikt kan worden op het moment van het doorvoeren van deze RFC):

  • Het logisch model van de Catalogus (zoals gedefinieerd in afsprakenset release 1.3.0) is backwards compatible met het logisch model van de Catalogus (zoals gedefinieerd in afsprakenset release 1.2.0). Dat wil zeggen dat de vernieuwde Catalogus ook gebruikt kan worden binnen afsprakenset release 1.2.0 en dat geen separate Catalogus aangehouden hoeft te worden voor die release. Wanneer gedurende de periode dat release 1.2.0 gebruikt mag worden, een Gegevensdienst geldig wordt die alleen met Interfaceversie 1.3.0 gebruikt kan worden, is een toelichting benodigd voor gebruikers van 1.2.0: niet de gehele Catalogus is dan voor hen van toepassing.
  • De wijzigingen in het technisch model en de publicatiewijze van de Catalogus hebben geen inhoudelijke gevolgen voor gebruikers van afsprakenset release 1.2.0. Dat wil zeggen dat de XML/XSLT-publicatie ook gebruikt kan worden binnen afsprakenset release 1.2.0 en dat de oude technische modellen en publicatiewijze (spreadsheet) kunnen vervallen.
  • Daar waar in afsprakenset release 1.2.0 verwezen wordt naar het Register van Informatiestandaarden, maken de toelichting en de doorverwijzing op de oude publicatieplek van het Register duidelijk hoe de nieuwe Catalogus deze functie heeft overgenomen en hoe die gebruikt moet worden.
Input voor release notes / communicabele samenvatting

Wijzigingen zonder directe implementatie-impact voor de Deelnemers:

Catalogus is vernieuwd, Register van Informatiestandaarden is vervallen - Het Register van Informatiestandaarden is vervallen, voortaan worden Informatiestandaarden niet meer zelfstandig toegelaten maar worden de eisen waaraan een systeemrol/Informatiestandaard moet voldoen meegewogen bij het samenstellen van een specifieke Gegevensdienst. De Catalogus is uitgebreid om de relevante onderdelen van het Register van Informatiestandaarden over te kunnen nemen. Tegelijkertijd is die geoptimaliseerd zodat die alleen relevante en heldere concepten bevat. De Catalogus wordt beschikbaar gesteld als XML-bestand en een automatische vertaling naar een gebruiksvriendelijke versie. Het Gegevensdienstenbeleid reflecteert de vereenvoudiging.

Relatie tussen Gegevensdiensten en Interfaceversies is geëxpliciteerd - In de Catalogus wordt aangegeven met welke Interfaceversies een Gegevensdienst mag worden gebruikt.

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principes

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Positief

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten

Positief

12 Het afsprakenstelsel is een groeimodel

Neutraal

Dienstverleners concurreren op de functionaliteiten

Neutraal

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Neutraal

Dienstverleners zijn aanspreekbaar door de gebruiker

Neutraal

14 Uitwisseling is een keuze

Neutraal

De persoon wisselt gegevens uit met de zorgaanbieder

Neutraal

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

MedMij spreekt alleen af wat nodig is

Neutraal

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Neutraal

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Neutraal

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Neutraal

De dienstverleners zijn deelnemers van het afsprakenstelsel

Neutraal

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Neutraal

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Neutraal

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Neutraal

Uitwerking

Toevoegingen in paars. Verwijderingen doorgehaald.

Uitgangspunt is dat toelichtingen in de te publiceren producten (bijvoorbeeld bij het metamodel) vooral daar worden verschaft waar die zinvol zijn (bijdragen aan duidelijkheid, begrip, gewenste standaardisatie).

Links naar andere pagina's binnen het Afsprakenstelsel zijn niet nagelopen, dat kan het beste bij de eindredactie plaatsvinden.

Noot voor eindredactie

De uitwerking van deze RFC gaat ervan uit dat RFC0035 Verzamel RFC reeds is verwerkt.

Metamodel (aanpassing)

Model

Noot voor eindredactie

In dit model zijn alleen de voor de aanpassing relevante klassen opgenomen. Dit deel moet door de eindredactie worden geïntegreerd in de afbeelding van het volledige metamodel.

Het plaatje met de 'domeinen', onderdeel van het metamodel, behoeft ook aanpassing om de nieuwe situatie te reflecteren.

Toelichting

Op enkele punten is afgeweken van deze modelleerstijl, om de presentatie van het model niet onnodig te compliceren. 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.

(...)

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. Een GegevensdienstInterfaceversie geeft aan dat een Gegevensdienst via de Interfaceversie mag worden aangeboden.

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 waarvan de onderdelen de basis vormen voor Gegevensdiensten. Daarom zijn de randen van deze klassen gestippeld. De bouwblokjes van een Informatiestandaard noemen we een Transactie, die zowel functionele als technische specificaties bevat. Een Bedrijfsrol, waarvan er twee zijn (PatiëntBedrijfsrol en ZorgaanbiederBedrijfsrol), wordt aangenomen door een Systeemrol Transactie.

De klassen in het modeldomein Systeemrollen leggen de verbinding tussen het domein van de Informatiestandaarden en dat van de Gegevensdiensten. Een Systeemrol is een Transactie die voorzien is van een Systeemrolcode om hem binnen MedMij uniek te kunnen aanduiden. Merk op dat een Systeemrol een concept is met een specifieke betekenis binnen het MedMij Afsprakenstelsel. Het is niet hetzelfde als het concept "Systeemrol" zoals dat wordt gebruikt binnen de Nictiz-informatiestandaarden. Een Systeemrol kan een Ondersteuningsorganisatie hebben die dienstverlening biedt aan Deelnemers bij vragen over de specificaties behorend bij de Systeemrol. Vaak zal dit de beheerder van de onderliggende Informatiestandaard zijn, maar het is ook denkbaar dat er geen beheerder is of dat een andere partij de rol van beheerder vervult (bijvoorbeeld als de beheerder van de Informatiestandaard geen dienstverlening biedt voor MedMij-stakeholders). Een Systeemrol kan ook verbonden zijn met een Kwalificatieloket waar de ondersteuning van Systeemrollen kan worden aangetoond.

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.


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.

Invarianten

Betreft instanties van klasse ...

Invariant

Modeldomein

Toelichting

Aard

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.Informatiestandaardmajorminorversie, 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
ZorgaanbiederGegevensdienst

Voor elke ZorgaanbiederGegevensdienst zg geldt:

ALS er een ZorgaanbiederGegevensdienstInterfaceversie zgi1 is zodat:

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

EN er een GegevensdienstInterfaceversie gi is zodat:

  • gi.Gegevensdienstzg.Gegevensdienst en
  • gi.Interfaceversie is de VerplichteInterfaceversie

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. Dit geldt uiteraard alleen als de Gegevensdienst ook mag worden aangeboden 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

EN er een GegevensdienstAbonnerenOpGegevensdienstInterfaceversie agi is zodat:

  • agi.Gegevensdienstzg.Gegevensdienst en
  • agi.Interfaceversie is de VerplichteInterfaceversie

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. Dit geldt uiteraard alleen als de Gegevensdienst ook mag worden aangeboden op de verplichte Interfaceversie. Zie Change- en releasebeleid.niet-lokale afhankelijkheid
OndersteuningsloketElk Ondersteuningsloket heeft ten minste één van de volgende attributen: EmailadresTelefoonnummer en Emailadres.SysteemrollenEen Ondersteuningsloket moet ten minste langs één wijze een contactadres kennen.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 

de combinatie van r.MedMijNode.DeelnemerNode.Node.Hostname en r.ResourceEndpointpath is gelijk aan wat in de specificaties van r.ZorgaanbiederGegevensdienstSysteemrolInterfaceversie.Systeemrol.Transactie

[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 geeft aan welk deel van de URI van de resource request uit de ZAL wordt betrokken.niet-lokale afhankelijkheid
GegevensdienstVoor elke Gegevensdienst geldt: g.Usecase is ofwel VerzamelenUsecase ofwel DelenUsecase.GegevensdienstenZo wordt geregeld dat een Gegevensdienst alleen gebaseerd kan zijn op de primaire use cases Verzamelen of Delen.opsomming
KwalificatieloketElk Kwalificatieloket heeft ten minste één van de volgende attributen: EmailadresTelefoonnummer en Emailadres.SysteemrollenEen Kwalificatieloket moet ten minste langs één wijze een kanaal kennen waarlangs meer informatie over de kwalificatie kan worden verkregen.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
ZorgaanbiederGegevensdienstVoor elke ZorgaanbiederGegevensdienst.Gegevensdienst. TransactieVerzameling.Transactie.SysteemrolSysteemrolverzameling.Systeemrol s
waarvoor geldt dat s.Transactie.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
Systeemrol

Voor elke Systeemrol s geldt:
ALS s.Transactie.Bedrijfsrol : PatiëntBedrijfsrol
ALS s.Deelnemersrol : PatiëntBedrijfsrol

DAN geldt voor alle RolInGegevensdienst r:
(ALS s in r.Gegevensdienst.TransactieSysteemrolvVerzameling 
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.Transactie.Bedrijfsrol : ZorgaanbiederBedrijfsrol
ALS s.Deelnemersrol : ZorgaanbiederBedrijfsrol
DAN geldt voor alle RolInGegevensdienst r :
(ALS s in r.Gegevensdienst.TransactieVSysteemrolverzameling
DAN r.DeelnemersrolUsecaseBusinessrol.Deelnemersrol : DienstverlenerzorgaanbiederDeelnemersrol)

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

Voor elke OAuthclientGegevensdienstInterfaceversie ogi geldt:

ALS er een OAuthClientAbonnerenOpGegevensdienstInterfaceversie oagi1 is zodat:

  • oagi1.OAuthclientGegevensdienstInterfaceversie.
    Gegevensdienst = g
    en
  • oagi1.OAuthClientGegevensdienstInterfaceversie.
    OAuthclientInterfaceversie.Interfaceversie
    is de GepubliceerdeInterfaceversie

DAN is er een OAuthClientAbonnerenOpGegevensdienstInterfaceversie oagi2 zodat:

  • oagi2.OAuthclientGegevensdienstInterfaceversie.
    Gegevensdienst = g
    en
  • oagi2OAuthClientGegevensdienstInterfaceversie.
    OAuthclientInterfaceversie.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 /wiki/spaces/MedMijAfsprakenstelsel130/pages/135628810.niet-lokale afhankelijkheid
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

Noot voor eindredactie

Er is vanuit gegaan dat OAuthclientGegevensdienst niet meer voorkomt in het metamodel, op grond van RFC0014 Extra controles door Authorization Interface.

Basisklassen

Basisklasse

Definitie

HttpsUrl

Semantiek: adres van een resource die via het internet benaderbaar is volgens het HTTPS-protocol.

Syntax: string die altijd start met https:// en daarna ten minste vier karakters bevat, niet zijnde witruimtekarakters (spatie, tab, line feed of carriage return) bevat.

InformatiestandaardnaamString van minimaal drie en maximaal 50 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 String van minimaal één en maximaal 30 tekens.
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).

Emailadres

Semantiek: e-mailadres volgens sectie 3.4.1 van IETF RFC 5322.

Syntax: string van een of meer tekens, gevolgd door het teken @, gevolgd door een of meer tekens, gevolgd door het teken ., gevolgd door twee of meer tekens. Witruimte (spatie, tab, line feed of carriage return) is niet toegestaan.

NederlandseDatum

Semantiek: datum volgens lokale Nederlandse tijd.

Syntax: datum volgens het type xs:date, zoals gespecificeerd in XML Schema 1.0, zonder tijdzone-indicatie.

GegevensdienstnaamString van minimaal drie en maximaal 50 tekens.
LangeWeergavenaamString van minimaal drie en maximaal 125 tekens.

Logische modellen (aanpassing)

Model Catalogus

Noot voor eindredactie

Het model wordt worden vervangen door de inhoud van onderstaand model. De stijl van de bestaande logische modellen kan daarop worden toegepast.

Toelichting bij wijziging (niet verwerken)

De Catalogus is geen specialisatie van MedMijBeheerlijst, omdat het een aantal (impliciete) kenmerken van MedMijBeheerlijsten niet deelt, zoals de gebondenheid aan een specifieke interfaceversie.


Invarianten bij logisch model Catalogus

Betreft instanties van klasse ...

Invariant

Component

Toelichting

Aard

Herkomst

CatalogusEr is precies één instantie hiervan.CatalogusDit is een eenling in het model.getalsverhoudinglogisch model
Usecase

Voor elke Usecase u geldt: u.Weergavenaam = "Verzamelen" OF u.Weergavenaam = "Delen"

CatalogusDit koppelt de namen van de subklassen aan de weergavenamen.lokale afhankelijkheidmetamodel (bij Usecase)
Systeemrol

Voor elke Systeemrol s geldt: s.Presentatievolgorde wordt 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:

  • een Transactie t met t.BedrijfsrolPatiëntBedrijfsrol gaat vooraf aan een Transactie t met t.BedrijfsrolZorgaanbiederBedrijfsrol;
  • bij meerdere Transacties van hetzelfde type: in tijdsvolgorde van de transactie.
CatalogusDe 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 afhankelijkheidlogisch model
Invarianten bij logisch model Lijsten

Betreft instanties van logische klasse ...

Invariant

Component

Toelichting

Aard

Herkomst

Interfaceversies_ZAL

Voor elke Gegevensdienst_OCL g1 geldt dat:

ALS:

  • g1.Gegevensdiensten_OCL.
    Interfaceversie_OCL is de gepubliceerde Interfaceversie
  • er is een Abonneren a1 zodat a1.Gegevensdienst_OCL = g1

DAN is er een Gegevensdienst_ZAL g2 waarvoor geldt dat:

  • g2.GegevensdienstId = g1.GegevensdienstId
  • g1.Gegevensdiensten_OCL.
    Interfaceversie_OCL is de verplichte Interfaceversie
  • er is een Abonneren a2 zodat a2.Gegevensdienst_OCL = g2
ZorgaanbiederslijstOp Gegevensdiensten waarvoor door een OAuthClient onder de gepubliceerde Interfaceversie Abonnementen worden aangeboden, worden ook onder de verplichte Interfaceversie Abonnementen aangeboden.niet-lokale afhankelijkheidmetamodel
Interfaceversies_ZAL

Voor elke Interfaceversies_ZAL, dienst verplichte Interfaceversie_ZAL vi en diens gepubliceerde Interfaceversie_ZAL gi geldt dat 

ALS er een Gegevensdienst_ZAL g1 is waarvoor geldt dat  g1.Gegevensdiensten_ZAL.
Interfaceversie_ZAL
 = gi

DAN is er een Gegevensdienst_ZAL g2 waarvoor geldt dat g2.Gegevensdiensten_ZAL.
Interfaceversie_ZAL
 = vi

ZorgaanbiederslijstGegevensdiensten die door een Zorgaanbieder onder de gepubliceerde Interfaceversie worden aangeboden, worden ook onder de verplichte Interfaceversie aangeboden.niet-lokale afhankelijkheidmetamodel
Interfaceversies_ZAL

Voor elke Gegevensdienst_ZAL g1 geldt dat:

ALS:

  • g1.Gegevensdiensten_ZAL.
    Interfaceversie_ZAL is de gepubliceerde Interfaceversie
  • er is een Abonneren a1 zodat a1.Gegevensdienst_ZAL = g1

DAN is er een Gegevensdienst_ZAL g2 waarvoor geldt dat:

  • g2.GegevensdienstId = g1.GegevensdienstId
  • g1.Gegevensdiensten_ZAL.
    Interfaceversie_ZAL is de verplichte Interfaceversie
  • er is een Abonneren a2 zodat a2.Gegevensdienst_ZAL = g2
ZorgaanbiederslijstOp Gegevensdiensten waarvoor door een Zorgaanbieder onder de gepubliceerde Interfaceversie Abonnementen worden aangeboden, worden ook onder de verplichte Interfaceversie Abonnementen aangeboden.niet-lokale afhankelijkheidmetamodel
SysteemrolVoor elke Systeemrol s met haar corresponderende ZorgaanbiederGegevensdienstSysteemrol z geldt:
s.Systeemrolcode ← z.Systeemrol.Systeemrolcode.
ZorgaanbiederslijstZo erft de Zorgaanbiederslijst de Systeemrolcodes van het Register van Informatiestandaarden de Catalogus.verervinglogisch model

Toelichting bij wijziging (niet verwerken)

De invarianten voor de klasse "Interfaceversies_ZAL" zouden moeten worden aangepast als gevolg van een wijziging van de gerelateerde invariant in het metamodel. De logische invariant zou daardoor nog complexer worden. Omdat de invariant echter geen duidelijke functie lijkt te hebben in het logische model (dat is gericht op de publicatie van de ZAL, en niet op de registratie; de betreffende invarianten hebben nu ook geen vertaling in het technische model), worden zij in plaats daarvan geschrapt.

Basisklassen bij logisch model Catalogus

Basisklasse

Definitie

Herkomst

DeelnemersrolWeergavenaamString met de waarde "Dienstverlener persoon" of "Dienstverlener zorgaanbieder".logisch model
UsecaseWeergavenaamString met de waarde "Verzamelen" of "Delen".logisch model
BedrijfsrolWeergavenaamString met de waarde "Patiënt" of "Zorgaanbieder".logisch model
NederlandseDatum

Semantiek: datum volgens lokale Nederlandse tijd.

Syntax: datum volgens het type xs:date, zoals gespecificeerd in XML Schema 1.0, zonder tijdzone-indicatie.

metamodel
HttpsUrl

Semantiek: adres van een resource die via het internet benaderbaar is volgens het HTTPS-protocol.

Syntax: string die altijd start met https:// en daarna ten minste vier karakters bevat, niet zijnde witruimtekarakters (spatie, tab, line feed of carriage return) bevat.

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
Emailadres

Semantiek: e-mailadres volgens sectie 3.4.1 van IETF RFC 5322.

Syntax: string van een of meer tekens, gevolgd door het teken @, gevolgd door een of meer tekens, gevolgd door het teken ., gevolgd door twee of meer tekens. Witruimte (spatie, tab, line feed of carriage return) is niet toegestaan.

metamodel
VersienummerString van minimaal één en maximaal 30 tekens.metamodel
PositiefnummerEen geheel getal ongelijk 0.logisch model
LangeWeergavenaamString van minimaal één en maximaal 125 tekens.metamodel
GegevensdienstnaamString van minimaal drie en maximaal 50 tekens.metamodel
Verband klassen logisch model Catalogus met metamodel

Klasse/waarde in logisch model

Herkomstklasse in metamodel

UsecaseUsecase , VerzamelenUsecase en DelenUsecase
InterfaceversieInterfaceversie
TransactieTransactie
BedrijfsrolBedrijfsrol
OndersteuningsloketOndersteuningsloket
KwalificatieloketKwalificatieloket
TransactieaanduidingTransactieaanduiding
VolledigetransactienaamVolledigetransactienaam
DeelnemersrolDeelnemersrol
VereisteGegevensdienstGegevensdienst

Toelichting

De klasse Usecase is een abstracte klasse in het metamodel. In het logische model zijn, in de compositiehiërarchie, echter concrete klassen nodig. In het kader van de Catalogus zijn we hier niet geïnteressseerd in de gehele semantiek van de conceptuele klassen VerzamelenUsecase en DelenUsecase, maar enkel in hun respectievelijke instanties, met de Weergavenaam die zij van de abstracte klasse Usecase krijgen, door middel van een invariant. Daarom gebruiken we in dit logische model een concrete klasse Usecase, die tot deze twee instantieert.

Toelichting bij wijziging (niet verwerken)

Er zijn bewust geen klassen opgenomen t.b.v. het wijzigingsbeheer. In de huidige Catalogus komen de kolommen "Datum aanmaak", "Datum mutatie" en "Opmerking mutatie" voor. Voor toelichting op de wijzigingen wordt verwezen naar de toelichting op de Catalogus. Daarnaast kunnen gebruikers met eigen tooling desgewenst een automatische vergelijking uitvoeren tussen verschillende versies van het XML-bestand van de Catalogus. Aan de toelichting op de Catalogus zal voor nieuwe wijzigingen ook de datum van de mutatie worden toegevoegd.

XML-schema Catalogus (nieuw)

Het releasenummer wordt met één opgehoogd omdat de structuur van het technische model van de Catalogus is gewijzigd.

De bestandsnaam bevat niet de bestandsversie, noch het volgnummer, maar wel het nummer van de release van de Catalogus.

Pagina XML-schema’s (aanpassing)

Toelichting

Op deze pagina staan de XML-schema's van:

  • de lijsten die door MedMij Beheer aan Bron en Uitgever voor uiteenlopende doelen ter beschikking worden gesteld;
  • de rapporten die door Deelnemers moeten kunnen worden opgeleverd;
  • de Catalogus.

De XML-schema's zijn een implementatie van de relevante logische modellen van de lijsten in XML-syntax en vervullen daarom de rol van technisch model. XML past bij de hiërarchische structurering waarop al in de logische modellen is ingezet.

    • Bij het logische model van de lijsten en rapporten horen vier technische componenten. De hoogste klasse van elke component wordt het rootelement van het betreffende XML-schema. De attributen van de abstracte klassen bovenaan (MedMijBeheerlijst en MedMijRapport) worden over de technische modellen van de vier lijsten, respectievelijk de twee rapporten, verspreid. Er is dus voor elke lijst of rapport een apart XML-schema. Daardoor is de homonymie van Gegevensdienst en Gegevensdiensten geen probleem meer en kunnen in de namen de achtervoegsels _ZAL_GNL _OCL, _BR en _PR achterwege blijven.
      • De Catalogus vormt hierop een uitzondering. Die kent een zelfstandig logisch model. De klasse Catalogus uit het logisch model dient als root element van het XML-schema van de Catalogus.

Lijst of rapport

Bestandsnaam

Release

Versie bestand

CatalogusMedMij_Catalogus_release3.xsd35

Tijdaspect

Het metamodel en de logische modellen, met hun invarianten, werken "door de tijd". Zij beschrijven hoe de klassen samenhangen op elk moment. De XML-bestanden voor de lijsten zijn echter specifieke momentopnames van de instanties van de klassen. Er moet daarom een tijdselement worden toegevoegd om lijsten die op verschillende momenten zijn gegenereerd, uit elkaar te kunnen houden, en om in retrospectief de geldigheidstermijn van een lijst te kunnen vaststellen.

  • Elk XML-bestand kent een versie-aanduiding. Hiertoe wordt de combinatie van een Volgnummer en een Tijdstempel gebruikt. Hiermee wordt aan drie informatiebehoeften tegemoet gekomen:
    • Wanneer twee lijsten (van hetzelfde type) met opeenvolgende Volgnummers beschikbaar zijn, kan de geldigheidstermijn van de oudere lijst worden vastgesteld. Dat helpt bij de interpretatie van audit logs of foutopsporing.
    • Lijsten kunnen uniek worden geïdentificeerd. Dit kan aan de hand van Volgnummer of Tijdstempel, waarbij Volgnummer voor menselijke gebruikers vaak de meest intuïtieve zal zijn.
    • Per lijst kan worden nagegaan wanneer de laatste mutatie heeft plaatsgevonden. Dit zal in de regel een 'functionele' mutatie betreffen, geen foutherstel. Hieruit kan door vergelijking van opeenvolgende versies worden afgeleid wanneer de actuele lijst voor het laatst is gewijzigd; dat kan zinvol zijn bij het beoordelen van de effecten van changes of bij foutopsporing.
  • Tijdstempel bestaat uit Datum, Tijd en Tijdzone-aanduiding, gebaseerd op xs:dateTime-type. Door voor een native XML-datatype te kiezen, wordt de implementatie vergemakkelijkt. Er geldt wel een restrictie op het element, dat afdwingt dat er altijd een Tijdzone-aanduiding wordt meegegeven.
    • Voor de Catalogus geldt een uitzondering, en wordt gebruikgemaakt van een uitdrukking van de lokale Nederlandse datum (xs:date-type zonder tijdzone-aanduiding).

Namespaces

Voor de aanduiding van namespaces wordt gebruikgemaakt van een URL. Dit is de gemakkelijkste optie, omdat dit - anders dan bij een URN - geen namespaceregistratie bij IANA vereist. De namespace-URL kent de volgende opbouw: xmlns://afsprakenstelsel.medmij.nl/[naamLijst|naamRapport|"catalogus"]/release[releasenummer] .

  • Een namespace-URL gebruikt xmlns:// als schema-aanduiding. Daarmee wordt duidelijk gemaakt dat het slechts een identificatie betreft, en dat de URL niet is bedoeld voor dereferencing (bijvoorbeeld om het XML-schema te downloaden).
  • Het domein afsprakenstelsel.medmij.nl is een unieke hostname op het internet. Gebruik daarvan biedt zowel voldoende herkenbaarheid als uniciteit.
  • De naamLijst kent één van de volgende waarden: Whitelist, OAuthclientlist, Zorgaanbiederslijst of Gegevensdienstnamenlijst.
  • De naamRapport kent één van de volgende waarden: Beheerrapport of Portabiliteitsrapport.
  • De aanduiding release is toegevoegd voor de menselijke leesbaarheid en daarmee duidelijkheid.

Waar het metamodel geen namen heeft gedefinieerd, kiezen we om redenen van consistentie en elegantie voor lowercase in de opbouw van de URL. Er wordt gebruikgemaakt van elementFormDefault = "qualified". Dit vergroot de leesbaarheid van de XML-schema's omdat er geen prefixes nodig zijn bij het definiëren van elementen, en doet niet af aan enige functionaliteit . De prefixes voor de namespaces worden omwille van de leesbaarheid van de XML-schema's zo kort mogelijk gehouden, bestaan altijd uit drie letters en zijn geheel in lowercase. Onderstaande tabel geeft weer bij welke lijst of rapport welke prefix wordt gebruikt.

Pagina XML-bestanden voor lijsten (aanpassing)

De XML-bestanden waarmee MedMij Beheer de Zorgaanbiederslijst, de Whitelist, de OAuth Client List en de Gegevensdienstnamenlijst en de Catalogus ontsluit voldoen aan enkele eisen, zodat PGO Server, Authorization Server en MedMijNode en anderen weten waarop zij kunnen rekenen voor de goede verwerking van deze lijsten.

1. Het XML-bestand van de Zorgaanbiederslijst heet MedMij_Zorgaanbiederslijst.xml. Het XML-bestand van de Whitelist heet MedMij_Whitelist.xml. Het XML-bestand van de OAuth Client List heet MedMij_OAuthclientlist.xml. Het XML-bestand van de Gegevensdienstnamen heet MedMij_Gegevensdienstnamenlijst.xmlHet XML-bestand van de Catalogus heet MedMij_Catalogus.xml.

XML-bestand Catalogus (nieuw)

Noot voor eindredactie

De definitieve versie van het XML-bestand van de Catalogus volgt later. Bij deze RFC is een voorbeeld opgenomen.

De versie van de Catalogus maakt geen onderdeel uit van de bestandsnaam/URL, zodat de verwijzing altijd plaatsvindt naar de meest actuele versie.

Alle gegevensdiensten (volledige historie) worden geconverteerd en opgenomen in de nieuwe structuur. Daarbij wordt uitgegaan van de actuele versie van de Catalogus. Eerdere versies worden genegeerd.

Waar nodig wordt ook informatie uit de actuele versie van het Register van Informatiestandaarden betrokken. Bij concepten die voorkomen in zowel de Catalogus als het Register, is de Catalogus leidend.

Bij de conversie van gegevensdiensten die ten tijde van publicatie van release 1.3.0 niet meer geldig zijn, wordt de waarde "Pre-1.2.0" gehanteerd als InterfaceversieId. Voor die gegevensdiensten gold dat er geen specifieke koppeling met een interfaceversie was en er dus vanuit kan worden gegaan dat gebruik met elke interfaceversie voor 1.2.0 mogelijk was, zolang zowel de Gegevensdienst als de interfaceversie/versie van de afsprakenset tegelijkertijd geldig waren. Voor de overige (actueel geldige) Gegevensdiensten geldt ten tijde van publicatie van release 1.3.0 dat ervan uit wordt gegaan dat zij zowel met interfaceversie 1.2.0 als met interfaceversie 1.3.0 gebruikt kunnen worden, en dat in de Catalogus beide interfaceversies dus aan de gegevensdienst worden gekoppeld.

Voor alle Gegevensdiensten wordt een Ondersteuningsloket toegevoegd. Binnen die set worden bij elke systeemrol de kanalen als volgt gevuld:

  1. Ondersteuningsorganisatienaam = MedMij-loket
  2. Telefoonnummer = +31703173434
  3. Emailadres = info@medmij.nl
  4. Webpagina = https://www.medmij.nl

Voor alle GegevensdienstSysteemrollen wordt Kwalificatieloket als volgt gevuld:

  1. Kwalificerendeorganisatienaam = Nictiz Kwalificatiecentrum
  2. Webpagina = de Kwalificatie-pagina op de Informatiestandaarden-wiki die hoort bij de publicatie van de Systeemrol waarop de kwalificatie betrekking heeft

Het attribuut Vervangt wordt bij alle Gegevensdiensten verwijderd.

De Majorminorversie van een Transactie is aangevuld; het Register en de Catalogus bevatten dit concept eerder niet. Er is gebruikgemaakt van de release van de publicatie van Nictiz-standaarden die binnen MedMij worden gebruikt, omdat die het duidelijkst versies van Transacties van elkaar onderscheiden.

De Technischespecificatieverwijzing van een Transactie is aangevuld; het Register en de Catalogus bevatten dit concept eerder niet.

Met betrekking tot specifieke elementen:

  • De systeemrollen behorend bij de Gegevensdienst "Verzamelen Basisgegevens zorg 1.0" kwamen niet voor in het Register. In de nieuwe Catalogus zal worden verwezen naar publicatie 2018.01 van Nictiz; de meest recente publicatie waarin de systeemrolcodes behorend bij de Gegevensdienst voorkomen.
  • De Gegevensdienstnamen "Verzamelen Medicatieoverzichten 9.0" en "Verzamelen Medicatiegegevens 9.0" kwamen elk voor bij twee Gegevensdiensten, terwijl de naam uniek hoort te zijn. Om de uniciteit te herstellen wijzigen de Gegevensdienstnamen van de Gegevensdiensten met id's 2 en 3 in "Verzamelen Medicatieoverzichten 9.0 (2018.06)" respectievelijk "Verzamelen Medicatiegegevens 9.0 (2018.06)".

Omdat de conversie niet volledig neutraal verloopt, zal de eerste uitgave van de nieuwe Catalogus leiden tot ophoging van het versienummer.

N.B. In de Gegevensdienstnaam en Weergavenaam van enkele Gegevensdiensten komt nu een (*) voor. Het gebruik hiervan is niet meer nodig om Gegevensdienstnamen uniek te houden, omdat de vaste opbouw van de Gegevensdienstnaam verdwijnt en er daarmee ruimte is om eventuele naamconflicten op verschillende manieren op te lossen, of te voorkomen dat zij ontstaan (bijvoorbeeld door de gehele Majorminorversie van de Informatiestandaard op te nemen en niet alleen de eerste twee delen). Het gebruik van (*) is evenwel wel toegestaan onder de nieuwe regels. Daarom wordt er geen wijziging aangebracht bij de conversie.

Noot voor eindredactie

De publicatieplaats van het XML-bestand van de Catalogus wordt door het eindredactieteam bepaald en het team publiceert daar ook de definitieve versies van het bestand. Van belang is dat dit een (herkenbare) permalink is in het medmij.nl-domein, met https als "scheme", waarbij de bestandsnaam MedMij_Catalogus.xml is, en er geen query-of fragment-onderdeel in de URL voorkomt.

Opmerking van eindredactie: De publicatieplaats is nog niet gereed. Als tijdelijke oplossing wordt het XML-bestand als attachment bij de Catalogus in Confluence gepubliceerd.

Publicatie XML-bestanden (nieuw)

Publicatie van het XML-bestand vindt plaats op een nader (door de eindredactie) te bepalen permalink op (*).MedMij.nl (openbaar toegankelijk). Van belang is dat dit een (herkenbare) permalink is in het medmij.nl-domein, met https als "scheme", waarbij