pa:VDraft Toetsingscriteria

This page has been removed from search engines' indexes.

Aandachtspunten

Toepassingsregels voor zibs in informatiestandaarden

• Zibs en hun rol:
  • Zibs vormen de logische modellen voor informatiestandaarden
  • Nieuwe architectuurprincipes voor zibs zijn opgesteld via het ontwikkeltraject 'Zib-transitie', met betrokkenen buiten en binnen Nictiz
• Belangrijke punten van deze architectuurprincipes zibs 2.0:¹
  • Zibs worden zo veel mogelijk gebaseerd op bestaande internationale standaarden, zoals OpenEHR, FHIR en Xt-EHR
  • Zibs zijn maximale modellen die alle informatie modelleren waar behoefte aan is. Informatiestandaarden kunnen zibs niet uitbreiden, alleen inperken
  • Zibs kunnen alle soorten informatie modelleren, dus ook logistiek en workflow
  • Zibs zijn een logisch model (nu worden ze soms als logisch en andere keren alleen als conceptueel model beschouwd)
  • Zibs hebben kardinaliteiten op logisch niveau (nu hebben zibs conceptuele kardinaliteiten)
• Nieuwe regels voor toepassing in informatiestandaarden:
  • De nieuwe vorm van zibs betekent andere toepassingsregels in informatiestandaarden
  • Zib-publicaties van 2017, 2020 en 2024 zijn nog vóór architectuurprincipes zibs 2.0
  • Toetsingscriteria zijn zo geformuleerd dat er een beweging ontstaat naar zibs 2.0 en de nieuwe toepassingsregels

Verantwoordelijkheden van productteam bij uitbreidingen of aanpassingen op zibs

• Productteam en Zib-centrum:
  • Werken nauw samen in het ontwikkelen en doorontwikkelen van zibs
• Productteam (als beheerder van de informatiestandaard):
  • Heeft inzicht in de samenhang tussen standaarden in het stelsel en overziet de gevolgen van wijzigingen in de eigen informatiestandaard²
  • Verantwoordelijk voor een impactanalyse³ bij wijzigingsverzoeken voor de eigen informatiestandaard naar:
    • samenhang binnen de eigen informatiestandaard
    • samenhang tussen standaarden
    • compliance
    • gebruik
• Wenselijke werkwijze voor samenhang:
  • Wijzigingen eerst generiek verwerken in de zib
  • Pas daarna vanuit de vernieuwde zib toepassen in de informatiestandaard
  • → vereist flexibel releasebeleid voor zibs
  • Nictiz werkt aan plan voor flexibel publiceren van zibs⁴
• Huidige situatie:
  • Ook nu is de beheerder van de informatiestandaard verantwoordelijk voor samenhang
  • Toegepaste generieke wijzigingen moeten geschikt zijn voor opname in de eerstvolgende zib-release

Ontwikkeling van zibs zo veel mogelijk op basis van bestaande internationale standaarden

• Nadere invulling van toetsingscriterium 2.1.4 en 2.1.5 volgt uit de praktische handvatten (de spelregels) voor het ontwikkelen van een zib 2.0
  • Deze praktische handvatten worden door Nictiz en de Zib 2.0-community opgeleverd⁴
  • Dit is een praktische uitwerking van de reeds opgeleverde architectuurprincipes zibs 2.0

¹ Intern document Architectuurprincipes zibs 2.0 v1.0; ² NEN 7522:2021 Ontwikkelen en beheren van standaarden en stelsels van standaarden; ³ Duurzaam Releasebeleid v1.0.0 par. 3.2.1; ⁴ Plan van aanpak: Verder met zibs in databeschikbaarheid v1.1

Taal

Principe 1.1 Gebruik bestaande concepten en waardelijsten. Rationale: Door gemeenschappelijke taal te gebruiken is het mogelijk om tussen verschillende domeinen op een semantisch correcte manier gegevens te delen.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
1.1.1	MUST	Waardelijsten in informatiestandaarden zijn gelijk aan de corresponderende waardelijsten in de zibs of zijn een inperking hiervan, maar geen uitbreiding. Uitzonderingen: Indien de binding van de waardelijst van de zib 'extensible' is, mogen waarden toegevoegd worden die voldoen voor de criteria voor 'extensible'. Indien het gaat om een waardelijst van de zib met OTH Nullflavor, mag vrije tekst gebruikt worden als waarde wanneer de gecodeerde waarden uit de waardelijst niet voldoen.	Waardelijsten in informatiestandaarden Bindings van zibs ZIB-2685 ZIBFHIR-249
1.1.2	MUST NOT	Informatiestandaarden voegen geen waardelijsten toe naast de in de zib gespecificeerde waardelijsten.	Waardelijsten in informatiestandaarden
1.1.3	SHOULD	Indien een waardelijst in een informatiestandaard minder waarden bevat dan de in de zib gespecificeerde waardelijst, dan beschrijft de informatiestandaard hoe geborgd wordt dat alleen de ingeperkte lijst wordt verwerkt en/of gedeeld.	Waardelijsten in informatiestandaarden
1.1.4	SHOULD	Er is een verplichting opgenomen voor systemen voor het meesturen van een weergavenaam bij terminologiecoderingen van waardelijsten en voor het kunnen ontvangen en verwerken van onbekende codes. Wanneer een ontvangen code onbekend is, wordt de meegestuurde weergavenaam aan de gebruiker getoond. Als de informatiestandaard deze verplichting niet toepast, moet er een alternatieve werkwijze zijn om het gebruik van verschillende versies van codestelsels tussen systemen te ondersteunen.	Advies Dynamische waardelijsten

Principe 1.2 Producten voldoen aan besluiten over de te gebruiken terminologiestelsels. Rationale: Gebruik van hetzelfde terminologiestelsel voor dezelfde doeleinden zorgt voor eenheid van taal.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
1.2.1	MUST	Informatiestandaarden gebruiken de generieke standaarden SNOMED, LOINC en IDMP (in Nederland: G-Standaard) voor het koppelen van terminologie, tenzij een code buiten de grondplaat beter voldoet. De keuze voor het te gebruiken terminologiestelsel is op basis van de Visie Eenheid van Taal, waarin de scope van elk terminologiestelsel van de grondplaat beschreven staat. Er zijn uitzonderingen waarbij het noodzakelijk is om buiten de grondplaat te coderen, bijvoorbeeld bij NHG-tabellen of DSM, maar ook op deze gebieden is het doel om naar de grondplaat te bewegen.	Visie Eenheid van Taal
1.2.2	MUST	Diagnoses, problemen, behandelingen en verrichtingen worden gecodeerd met SNOMED. Zo niet, dan verloopt de overstap volgens de opgestelde SNOMED-roadmap.	SNOMED-besluit 2024
1.2.3	MUST	Terminologiekoppelingen in de dataset van een informatiestandaard zijn conform de Richtlijn Terminologie koppelen.	Richtlijn Terminologie koppelen v1.0

Principe 1.3 Definieer welk deel van de dialoog geïmplementeerd wordt; gebruik hiervoor bestaande definities; voor zowel communicatie als ook verwerking. Rationale: door duidelijk te maken wat de verwachting is waarmee de gegevens opgeslagen of gedeeld worden kunnen alle partijen de correcte actie nemen.

Toetsingscriteria nog in ontwikkeling

Logisch

Principe 2.1 Informatiestandaarden maken gebruik van bestaande logische modellen. Rationale: hergebruik van logische modellen leidt tot standaardisatie van gegevens en maakt hergebruik van deze gegevens voor andere doeleinden mogelijk.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
2.1.1	MUST	Informatiestandaarden gebruiken zibs als generieke standaard voor de logische modellen.	QA Instructie opstellen dataset v3.0.1 Stelselcriteria v0.91
2.1.2	MUST	De vigerende versies van zibs conform het stelselbesluit worden toegepast. Uitzondering: Onder voorwaarden mag een pre-adopt zib 2024 toegepast worden.	FHIR-besluit 2022 Ontwerpkaders Gebruik pre-adopts zibs 2024
2.1.3	MUST NOT	Een informatiestandaard maakt geen aanpassingen aan elementen van de zib.	Intern document Architectuurprincipes zibs 2.0 v1.0
2.1.4	MUST	Indien er geen geschikte zib is, wordt gebruik gemaakt van een bestaand internationaal informatiemodel indien beschikbaar (een Xt-EHR logical model, bestaande DCM/CIM, openEHR archetype of FHIR Resource/Profile). Indien er geen geschikt internationaal informatiemodel is, worden relevante beschikbare ontwerppatronen en spelregels gevolgd uit internationale literatuur (zoals de HL7 CIMI style guide en openEHR editorial style guide) voor het opstellen van een nieuw informatiemodel.	" "
2.1.5	MUST NOT	De gebruikte informatiemodellen mogen EHDS-compatibiliteit niet hinderen.	" "

Principe 2.2 Logische modellen worden zowel voor verwerking(opslag) als ook deling gebruikt. Rationale: door opslag en deling dezelfde structuur te geven is de kans op verlies van semantiek minimaal.

Toetsingscriteria nog in ontwikkeling

Principe 2.3 Een informatiestandaard voegt geen elementen of relaties toe aan; of verruimt de kardinaliteit van elementen of relaties in een logisch model. Rationale: toevoegen van elementen zorgt ervoor dat ontvangers mogelijk de gegevens niet kunnen verwerken.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
2.3.1	MUST NOT	Een informatiestandaard voegt geen elementen toe aan een zib.	Intern document Architectuurprincipes zibs 2.0 v1.0
2.3.2	MUST NOT	De kardinaliteit in een informatiestandaard is niet ruimer dan de kardinaliteit van elementen of relaties in een zib.	" "

Principe 2.4 Een informatiestandaard kan de kardinaliteit inperken voor een specifieke usecase. Rationale: bepaalde berichten of opslag kan voor een usecase alleen relevant zijn met bepaalde gegevens of relaties. Als deze optioneel zijn in het logische model, kunnen ze voor deze usecase met een specifiek minimumaantal worden opgenomen.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
2.4.1	MAY	Voor het produceren van uitwisselberichten of het verwerken van informatie kan een informatiestandaard de kardinaliteit van een zib beperken.	Intern document Architectuurprincipes zibs 2.0 v1.0
2.4.2	MUST NOT	Voor het ontvangen van berichten past de informatiestandaard geen beperkingen toe op de kardinaliteit van een zib.	" "

Systeem

Principe 3.1 Voor elk product is er een usecase. Rationale: Een product bestaat uit elementen uit zowel de concepten/dialogen als ook de logische modellen. Producten kunnen deze elementen niet uitbreiden, maar wel de kardinaliteit inperken. Producten lossen een specifieke usecase op.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
3.1.1	MUST	Een informatiestandaard beschrijft het vastleggen en/of uitwisselen van informatie voor één of meerdere concrete situaties. Een informatiestandaard is daarmee een oplossing voor één of meerdere specifieke usecases.	QA Instructie opstellen dataset v3.0.1
3.1.2	MUST	Een informatiestandaard beschrijft een usecase aan de hand van actoren (mensen en informatiesystemen) en trasacties (welke informatie wordt wanneer vastgelegd en/of uitgewisseld).	" "

Principe 3.2 Producten (informatiestandaarden) zijn zelfstandig implementeerbaar. Rationale: Een product is een verzameling van specificaties die verwijzen naar alle lagen en leveren een consistent product. Producten duiden de relatie tussen de verschillende lagen in context van een usecase.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
3.2.1	MUST	Een informatiestandaard omvat ook een technische specificatie. Deze technische specificatie is gebaseerd op het functioneel ontwerp.	Nictiz FHIR Profiling Guidelines R4 Nictiz FHIR Profiling Guidelines STU3
3.2.2	MUST	Elk data-element in de dataset van de informatiestandaard is gemapt naar de technische specificatie. Het gaat hierbij om datasetconcepten met een data-definitie. Groeperende datasetconcepten hebben mogelijk geen mapping.	" "
3.2.3	MUST	Alle verplichtingen en verwachtingen vanuit het functioneel ontwerp zijn uitgewerkt in een profiel of in een tekst in de technische specificatie.	" "

Principe 3.3 Producten voldoen aan technische besluiten. Rationale: Producten implementeren oplossingen en gebruiken hiervoor technische middelen. Deze middelen moeten passen bij besluiten zoals gemaakt (zoals het FHIR besluit).

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
3.3.1	MUST	Informatiestandaarden gebruiken de generieke uitwisselingsstandaard FHIR voor de technische representatie.	Stelselcriteria v0.91
3.3.2	MUST	De vigerende versies van FHIR conform het stelselbesluit worden toegepast. Zo niet, dan verloopt de overstap volgens de opgestelde migratieplannen.	FHIR-besluit 2022
3.3.3	MUST	De generieke profielen in het nl-core-package zijn gebruikt, direct of als basis voor usecase-specifieke profielen.	Nictiz FHIR Profiling Guidelines R4 Nictiz FHIR Profiling Guidelines STU3
3.3.4	MUST	Profielen zijn gebaseerd of zijn compatibel met zib en nl-core.	" "
3.3.5	MUST	Indien een informatiestandaard specifieke profielen, transacties, eigen concepten etc. publiceert, zijn deze afgeleid op de relevante nl-core-profielen.	" "
3.3.6	MUST	Informatiestandaard-specifieke profielen zijn ingericht op het specifieke doel en niet op de generieke uitwisseling.	" "
3.3.7	MUST	Uitbreidingen aan de profielen in het kader van een informatiestandaard zijn aangemeld voor opname in het nl-core-package (tenzij ze echt niet generiek toepasbaar zijn).	" "

Transactie

Principe 4.1 Producten gebruiken (waar ze beschikbaar zijn) internationale standaarden. Rationale: leveranciers hebben typisch niet alleen te maken met de standaarden in Nederland, door internationale standaarden te gebruiken is de drempel voor een leverancier om de standaard te implementeren lager.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
4.1.1	MUST	FHIR wordt zuiver toegepast (met andere woorden: de instance heeft dezelfde betekenis zonder dat het profiel bekend is).	https://hl7.org/fhir/resource.html#profile-tags
4.1.2	MUST NOT	Custom extensies worden vermeden wanneer FHIR core al een aanpak heeft om het concept te vertegenwoordigen.	Nictiz FHIR Profiling Guidelines R4 Nictiz FHIR Profiling Guidelines STU3
4.1.3	MUST	Bij het maken van profielen of andere conformance resources worden de FHIR profiling guidelines gevolgd.	" "
4.1.4	MUST	Indien een situatie past binnen een patroon zoals beschreven in de profling guidelines, volgt de FHIR-uitwerking dit patroon.	" "
4.1.5	MUST	Profielen zijn gebaseerd of zijn compatibel met eu-core en indien relevant met IG's die als de facto standaard gelden (denk aan de IPS FHIR IG, IHE MHD, Structured Data Capture, mCode).	" "
4.1.6	MUST	Beschreven uitwisselpatronen en queries zijn gebaseerd of zijn compatibel met IG's die als als de facto standaard gelden (denk aan IHE MHD, mCode).	" "
4.1.7	MUST	Profielen en andere conformance resources zijn gevalideerd tegen de FHIR core specificaties met de HL7-validatietooling. Afwijkingen moeten zijn verklaard.	" "
4.1.8	MUST	De voorbeeldmaterialen zijn gevalideerd tegen de profielen. Afwijkingen moeten zijn verklaard.	" "

Principe 4.2 Producten beschrijven geen details over de keuzes in de infrastructuur laag. Rationale: technische keuzes op de infrastructuur laag veranderen vaker en zijn in de meeste gevallen configuratie in de technische laag.

Toetsingscriteria nog in ontwikkeling

Data of verwerking

Principe 5.1 Datastructuren zijn lang levend, aanpassingen zijn waar mogelijk toevoegingen. Rationale: Opslag is niet vluchtig zoals transacties, transformaties van structuren hebben het risico op gegevens verlies. Aanpassingen moeten zonder verlies van gegevens geconverteerd kunnen worden.

Toetsingscriteria nog in ontwikkeling

Principe 5.2 Fysieke dataopslag is vergevingsgezinder in het kader van ontbrekende gegevens dan transactie producten. Invoer voor usecases kan wel de kardinaliteit strenger definiëren. Rationale: De opslag moet voor meerdere usecases bruikbaar zijn en niet in alle usecases zullen alle gegevens altijd beschikbaar en/of verplicht zijn. Dat de gegevens voor de specifieke usecase verplicht zijn, betekent niet dat ze voor andere usecases ook verplicht.

Zie toetsingscriterium 2.4.1 en 2.4.2. Overige toetsingscriteria nog in ontwikkeling

Generieke patronen

Duplicaatdetectie voor ontdubbelen

Principe 1.1 Elk gegevensobject heeft één unieke identiteit. Rationale: Maakt ontdubbeling mogelijk, voorkomt dubbele informatie voor eindgebruikers en bevordert daarmee overzicht en efficiëntie in het gebruik van informatiesystemen.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
1.1.1	SHOULD	Bronsystemen kennen wereldwijd unieke identifiers toe aan nieuwe gegevensobjecten.	NICTIZ-34076 Objectidentificatie alfa-versie
1.1.2	SHOULD	Secundaire systemen persisteren de identifiers van binnenkomende objecten.	" "
1.1.3	SHOULD	Secundaire systemen hanteren bij het uitwisselen van overgenomen objecten de oorspronkelijke identifier die was toegekend door het bronsysteem.	" "

Principe 1.2 Data wordt beheerd waar ze ontstaat. Rationale: Dit voorkomt dataduplicatie en inconsistenties.

Toetsingscriteria

Item	Niveau	Beschrijving	Bron
1.2.1	SHOULD	Mutaties aan een object zijn alleen mogelijk in het bronsysteem. Mutaties in een secundair systeem zijn niet toegestaan. Wijzigingen aan een object in het bronsysteem leiden tot een nieuwe versie van dat object; wijzigingen in een secundair systeem leiden tot een nieuw (afgeleid) object waarvoor het secundaire systeem dan bronsysteem wordt.	Thesaurus Data voor de Zorg 'wijzigingen'
1.2.2	SHOULD	Het bronsysteem behoudt de identifier van een object bij een mutatie; de versie van het object wordt wel vernieuwd.	NICTIZ-34076 Objectidentificatie alfa-versie
1.2.3	SHOULD	Het secundaire systeem wijst een nieuwe identifier toe bij aanpassingen op overgenomen gegevens.	" "
1.2.4	SHOULD	Een informatiestandaard vereist van systemen dat de datum en tijd van mutatie met volledige datum- en tijdstempels, inclusief tijdzone, worden vastgelegd en uitgewisseld.	" "

Documenthistorie

Versie	Status	Datum	Wijziging
0.1.0-alfa.2	draft	07-11-2025

Voor het opstellen van deze pagina is ChatGPT gebruikt als hulp voor het verbeteren van de schrijfstijl, de zinstructuur en voor grammaticacontrole.