RFC0023 Harmonisering Register van Informatiestandaarden en Catalogus: informatiemodellen

Samenvatting

Goedkeuring

Principes

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.

Metamodel (aanpassing)

Model

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

Basisklassen

Logische modellen (aanpassing)

Model Catalogus

Invarianten bij logisch model Catalogus

Invarianten bij logisch model Lijsten

Basisklassen bij logisch model Catalogus

Verband klassen logisch model Catalogus met metamodel

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.

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.

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.xml. Het XML-bestand van de Catalogus heet MedMij_Catalogus.xml.

XML-bestand Catalogus (nieuw)

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.

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 de bestandsnaam onderdeel is van de URL en gelijk is aan MedMij_Catalogus.xml, en er geen query- of fragment-onderdeel in de URL voorkomt.

Sluit daarbij waar mogelijk aan bij de publicatiewijze van de AKL zoals gedefinieerd in RFC0017 Koppelen van Zorgaanbiedersnamen (ter consultatie).

Historische, eerder geldige versies van het XML-bestand van de Catalogus blijven beschikbaar in een archief op Confluence.

Historische releases van de XSD blijven gepubliceerd als onderdeel van het archief van een bepaalde release van de afsprakenset.

Oplegger/introductie afsprakenstelsel (aanpassing)

(Equivalente pagina in release 1.2.0: https://afsprakenstelsel.medmij.nl/display/MedMijAfsprakenstelsel120/MedMij+Afsprakenstelsel+1.2.0)

• De beheerorganisatie onderhoudt twee registers een Catalogus die relevant zijn is voor de dienstverlening die via het MedMij-netwerk kan worden aangeboden. Het Register van Informatiestandaarden bevat de toegelaten informatiestandaarden. De Catalogus definieert welke Gegevensdiensten deelnemers kunnen ontsluitenaanbieden.
• Verwijderen tabelrij "Register van Informatiestandaarden".

Gegevensdienstenbeleid (aanpassing)

De aanpassingen in het Gegevensdienstenbeleid zijn geïntegreerd in de uitwerking van RFC0024 Harmonisatie Gegevensdiensten- en Stelselbeleid.

Testbeleid (aanpassing)

Voor (C) geldt dat in de Catalogus te vinden is welke Informatiestandaard bij een Gegevensdienst hoort en in het Register van Informatiestandaarden bij de Informatiestandaard vervolgens is opgenomen waar de ondersteuning van de Systeemrollen behorend bij een Gegevensdienst kan worden aangetoond.

Catalogus: toelichting (aanpassing)

Actuele Catalogus

Algemene toelichting

De Catalogus bevat de Gegevensdiensten die over het MedMij-netwerk kunnen worden ontsloten. De Catalogus is gepubliceerd in XML-formaat op LINK. Een gebruiksvriendelijke weergave is te vinden op de pagina Actuele catalogus.

in een spreadsheet weergegeven als een (niet-genormaliseerde) tabel. Het is een implementatie van het logisch model van de Catalogus. Er is gekozen voor het open bestandsformaat OpenDocument Spreadsheet (ODS) omdat hiermee aansluiting wordt gezocht bij een reeds beschikbare en open norm.

De Systeemrollen waaruit een Systeemrolverzameling bestaat zijn onderdeel van het Register van Informatiestandaarden. Voor informatieve doeleinden bevat de spreadsheet ook enkele klassen uit het Register van Informatiestandaarden. Ook is ter informatie de Deelnemersrol weergegeven; deze volgt echter niet uit de Catalogus, maar uit de invarianten van het metamodel. Wanneer mutaties worden doorgevoerd binnen een reeds gedefinieerde Gegevensdienst, wordt dit aangegeven onder de kolommen bij Wijzigingsbeheer. Ter vergroting van de leesbaarheid is een Datum aanmaak opgenomen, zodat wijzigingen in de Catalogus (toevoegingen dan wel mutaties) gemakkelijk zichtbaar zijn.

Wijzigingen in de Catalogus kunnen op grond van het Gegevensdienstenbeleid plaatsvinden onafhankelijk van releases van het afsprakenstelsel. Het bestuur van de Stichting MedMij stelt (wijzigingen in) de Catalogus vast.

Actuele Catalogus: pagina (nieuw)

Voor de gebruiksvriendelijke weergave van de actuele Catalogus moet:

• een nieuwe pagina op Confluence worden aangemaakt, in de space Catalogus;
• op deze pagina een macro worden gebruikt;
• de stylesheet voor de Catalogus-space worden aangevuld;
• een XSL-stylesheet worden toegevoegd;
• een plugin worden geïnstalleerd en geconfigureerd.

Releasebeheer

Bij een wijziging in de Catalogus wordt het releasenummer met één opgehoogd.

De spreadsheet krijgt daarnaast een versienummer mee. Het versienummer is een geheel getal en wordt bij elke wijziging in het bestand met één opgehoogd. Met behulp van versienummering kunnen bestandsversies gedurende de ontwikkeling uit elkaar worden gehouden. Het nummer is ook aanwezig in productieversies. De versienummering is, om redenen van eenvoud en duidelijkheid, onafhankelijk van de releasenummering van de Catalogus.

De Catalogus bevat ook Gegevensdiensten die inmiddels niet meer geldig zijn, omdat de einddatum van de geldigheidsperiode is gepasseerd. Door deze Gegevensdiensten te blijven vermelden wordt op een gemakkelijke wijze inzage geboden in de historie van Gegevensdiensten (bijvoorbeeld ten behoeve van het interpreteren van loggegevens). Het voorkomt ook dat de Catalogus (een op dit moment handmatig beheerd en gepubliceerd product) aanpassing behoeft op het moment van het verstrijken van de geldigheid van een Gegevensdienst. Gegevensdiensten die al bij publicatie van de betreffende versie van de Catalogus ongeldig waren, hebben voor de overzichtelijkheid een grijze achtergrond.

Toelichting bij inhoud van de Catalogus

De volgende Gegevensdiensten vereisen of vervangen een andere Gegevensdienst:

• Gegevensdiensten 43 en 45 en Gegevensdiensten 59 en 60 vereisen elkaar paarsgewijs, omdat het Verzamelen van een verwijzing naar een vragenlijst en het Delen van de ingevulde vragenlijst vast deel uitmaken van hetzelfde gebruikersproces.

• Gegevensdienst 31 vervangt Gegevensdienst 35 omdat Gegevensdienst 35 geïntroduceerd is als tijdelijke tussenstap richting Gegevensdienst31. Een Dienstverlener zorgaanbieder mag deze Gegevensdiensten niet tegelijkertijd ontsluiten voor een Zorgaanbieder, omdat de Gegevensdiensten niet te onderscheiden zijn voor de Zorggebruiker.

In de Catalogus staan bij een Gegevensdienst de Systeemrolcodes die bij de Gegevensdienst betrokken zijn. De 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, dat wil zeggen:

• Raadplegen (te herkennen aan de suffix ...R-FHIR) vóór Beschikbaar stellen (te herkennen aan de suffix ...B-FHIR);
• Sturen (te herkennen aan de suffix ...S-FHIR) vóór Ontvangen (te herkennen aan de suffix ...O-FHIR);
• bij meerdere transacties: in tijdsvolgorde van transactie.

Toelichting bij versie 23 van de Catalogus (mutatiedatum: 30-10-2020)

• De Systeemrollen behorend bij de Gegevensdienst "Verzamelen Basisgegevens zorg 1.0" kwamen niet voor in het Register van Informatiestandaarden. In de Catalogus zijn deze nu wel opgenomen en is verwezen naar publicatie 2018.01 van Nictiz; de meest recente publicatie waarin de systeemrolcodes behorend bij de Gegevensdienst voorkomen.
• De Catalogus heeft een herziene opzet. Daarmee is ook het afzonderlijke Register van Informatiestandaarden vervallen. Enkele relevante concepten uit het voormalige Register zijn opgenomen in de Catalogus. Het attribuut Vervangt van een Gegevensdienst is verwijderd.
• De Technischespecificatieverwijzingen zijn toegevoegd aan de Transacties behorend bij Systeemrollen.
• De Majorminorversies zijn toegevoegd aan de Transacties behorend bij Systeemrollen.
• De Interfaceversies zijn toegevoegd aan de Gegevensdiensten.
• De Ondersteuningsloketten zijn toegevoegd aan de Gegevensdiensten.
• De Kwalificatieloketten zijn toegevoegd aan de Gegevensdiensten.
• De Gegevensdienstnamen van de Gegevensdiensten met id's 2 en 3 zijn gewijzigd in "Verzamelen Medicatieoverzichten 9.0 (2018.06)" respectievelijk "Verzamelen Medicatiegegevens 9.0 (2018.06)".
• Uitgebreidere toelichting kan worden gevonden in RFC0023 Harmonisering Register van Informatiestandaarden en Catalogus: informatiemodellen.

Archief Catalogus (aanpassen)

Toevoegen van de huidige Catalogus (versie 22) aan het Archief.

Register van Informatiestandaarden (uitfaseren)

In de plaats van het huidige Register zal een korte toelichting op de wijziging worden geplaatst met een link naar de vindplaats van de Catalogus. In die toelichting wordt aangegeven hoe de Catalogus de relevante functies van het Register heeft overgenomen, en hoe die met betrekking tot die functies moet worden gelezen en gebruikt.

De doorverwijzing blijft ten minste twee jaar in stand. Daarna mag de pagina van het Register geheel worden verwijderd.

Beheerinstructies (aanpassing)

Toevoegen van het volgende aan bestaande beheerinstructies, of creëren van een nieuw overzicht met daarin:

• 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.
• Voordat een nieuwe versie van het XML-bestand van de Catalogus wordt gepubliceerd, moet die worden gevalideerd tegen het XML-schema van de Catalogus en moet die worden gecontroleerd tegen de regels op de pagina /wiki/spaces/MedMijAfsprakenstelsel112/pages/134710553.
• Voordat een nieuwe versie van het XML-bestand van de Catalogus wordt gepubliceerd, moet de vorige versie worden opgenomen in het openbaar toegankelijke archief van de Catalogus.
• Historische releases van het XML-schema van de Catalogus blijven gepubliceerd op de publicatieplaats, zonder wijziging van de permalink.

Risico's

Er zijn geen significante nettorisico's (risico's die resteren na volledige doorvoering van deze RFC, dus inclusief maatregelen die al in de RFC zelf zijn opgenomen) onderkend.

Bijlagen