informatiestandaarden - Gebruikersbijdragen [nl]

Sandbox/qa:Instructie opstellen dataset

2026-02-10T13:44:13Z

Lilian Brouwer:

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Instructie opstellen dataset 3.0.1 {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__

==Inleiding==
Dit document beschrijft de ‘best practices’ bij het opstellen van een dataset, behorende bij een informatiestandaard. Deze ‘best practices voor Nictiz datasets’ is de richtlijn voor iedereen die zich bezighoudt met het opstellen en beheren van datasets. Door op een eenduidige wijze deze datasets samen te stellen, wordt de uitwisselbaarheid in (delen van) datasets verbeterd en wordt het voor beheerders van datasets ook eenvoudiger om datasets die zijn opgesteld door collega’s, inzichtelijk te krijgen. Hiermee wordt ook getracht om de mapping van met name de datascenario’s op de HL7 berichten (HL7v3 templates en FHIR-profielen) te vereenvoudigen.
Daarnaast is de uniformiteit in de samenstelling van datasets van groot belang voor externe partijen – met name zorginstellingen en hun ICT-leveranciers die met behulp van de datasets en datascenario's de gegevensuitwisselingen conform de Nictiz informatiestandaarden moeten implementeren.
Voor de leesbaarheid en de juiste context van begrippen zijn een aantal relevante definities hieronder ingevoegd. Deze komen vanuit de
[https://nictiz.nl/standaarden/begrippen/ Nictiz begrippenlijst] of zijn er aan toegevoegd (met de intentie om deze alsnog op te nemen in de begrippenlijst):

{| class="wikitable"
! Begrip
! Definitie
|-
| Richtlijn
| Beschrijving die verduidelijkt wat behoort te worden gedaan en hoe, om de doelstellingen te bereiken die in het beleid zijn vastgelegd (NEN 7510)
|-
| Functioneel ontwerp
| In een Nictiz functioneel ontwerp worden alle eisen en wensen voor alle usecases (ook wel uitwisselscenario’s genoemd) binnen één informatiestandaard verzameld en geordend. Per usecase wordt beschreven op welke manier dat gebeurt: tussen welke gebruikers vindt de gegevensuitwisseling plaats, welke handelingen worden daarbij uitgevoerd en welke resultaten leveren deze op.
|-
| Usecase
| Een beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het vastleggen en/of uitwisselen van
|-
|
| informatie wordt beschreven aan de hand van actoren (mensen, informatiesystemen) en transacties (welke informatie wordt wanneer uitgewisseld).
|-
| Dataset
| Een dataset bevat definities van alle gegevens die binnen de context van een specifiek zorgproces en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Deze definities zijn functioneel van aard en worden vastgesteld door het zorgveld. Voor specifieke transacties binnen het zorgproces wordt gebruik gemaakt van een subset van de gegevens uit deze dataset (het datascenario).
|-
| Zib
| Zorginformatiebouwstenen (zibs) worden gebruikt om inhoudelijke (niet technische) afspraken vast te leggen ten behoeve van het standaardiseren van informatie, die gebruikt wordt in het zorgproces. Het doel van de standaardisatie is dat deze informatie uit het zorgproces wordt hergebruikt voor andere doeleinden, zoals kwaliteitsregistraties, overdracht, patiëntgebonden onderzoek. Een zorginformatiebouwsteen is een informatiemodel, waarin een zorginhoudelijk concept wordt beschreven in termen van de gegevenselementen waaruit dat concept bestaat, de datatypes van die gegevenselementen etc.
|-
| Informatiebouwsteen
| Een concrete voorziening, standaard, afspraak of arrangement, met een eigenaar, beheerder, financiering et cetera die bovensectoraal of zorgbreed (her)gebruikt kan worden. Informatiebouwstenen kunnen zijn (opgebouwd uit) zibs en/of opgebouwd uit gegevenselementen.
|-
| Dataelement / gegeven
| Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
|-
| Scenario
| De representatie van een usecase in ART DECOR waarin de actoren en een specifieke subset gegevens uit de dataset (transactiedataset) zijn uitgewerkt.
|-
| Transactiegroep
| Een model van een verzameling van gegevens die wordt overgedragen tussen actoren (personen of systeemrollen) binnen één usecase. Een transactie wordt schematisch weergegeven door de uitwisseling van een transactiedataset tussen twee actoren.
|-
| Transactiedataset
| Een subset van gegevens uit de dataset voor een specifieke transactie met kardinaliteiten en conformiteiten.
|-
| Intensionele waardelijst en expressie
| Zie 2.3.2

Een intentionele waardelijst geeft niet direct aan welke directe waarden je moet hebben, maar alleen een intentie geeft voor elke waarde erin in thuishoort. Dit doe je door een intentionele expressie (dat in feite een query is), zoals :

< T : alle waarden onder T

of

<< T : T en alle waarden daaronder

of

< T1

OR

< T2 : alle waarden onder T1 of T2
N.B. Daarnaast kun je waardes in de intentionele expressie ook excluderen
|}

===Doelstelling===
Het eerste doel van dit document is het bevorderen van inzicht in hoe een dataset wordt samengesteld. De richtlijnen en methoden voor het samenstellen van een dataset worden in dit document nader toegelicht.
Het tweede doel van dit document is het bevorderen van inzicht in hoe een datascenario wordt samengesteld vanuit een dataset. De richtlijnen en methoden voor het samenstellen van een datascenario worden in dit document nader toegelicht.

===Scope van dit document===
Dit document geeft definities van een dataset, zib, informatiebouwsteen, data-element en een datascenario. Ook wordt uitgelegd hoe een dataset en een datascenario op een eenduidige wijze moet worden samengesteld. De verschillende methoden die hiervoor gebruikt worden, zijn nader beschreven.
Dit document kan als een richtlijn worden beschouwd voor wijze waarop binnen Nictiz datasets en datascenario’s worden samengesteld. Ook voor beheer van reeds bestaande datasets en datascenario’s is deze richtlijn van toepassing.

===Buiten scope van dit document===
Een dataset bevat definities van alle gegevens die in een specifieke context binnen het zorgproces, en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Voor elke usecase moeten door betrokken partijen afspraken gemaakt worden over de inhoud van de te gebruiken gegevens – het datascenario. De definities die van toepassing zijn in het zorgproces zijn functioneel van aard en worden vastgesteld door de zorgverleners in een functioneel ontwerp en daarmee buiten de scope van dit document.
Eveneens buiten scope is een uitleg van de tooling waarmee datasets worden samengesteld en gepresenteerd. Hiervoor wordt verwezen naar ART DECOR [https://decor.nictiz.nl/wiki/index.php/Ontwikkelaars#Proces_ontwikkelen_DECOR-project, https://simplifier.net/, Zibs 2017: https://simplifier.net/NictizSTU3-Zib2017, http://www.art-decor.org]. Echter, vanwege praktische redenen worden in dit document afbeeldingen gebruikt van (delen van) datasets en datascenario’s in ART DECOR om beschrijvingen nader toe te lichten.
Dit document is gericht aan inhoudelijke experts op het gebied van Nictiz informatiestandaarden (informatieanalisten, product managers, Specialisten gegevensuitwisseling, etc.) waarvan wordt verondersteld dat men bekend is met de gebruikte terminologieën, tooling, documentatie, etc.. Deze worden daarom niet verder toegelicht en beschreven in dit document.

==Samenstellen datasets==

===Richtlijnen voor het samenstellen van datasets===
Voor het opstellen van een dataset gelden een aantal basisprincipes. In het kort komt dit neer op de volgende punten:
*Zoveel mogelijk gebruik maken van de meest recent gepubliceerde zibs
*Indien geen zibs beschikbaar, bekijk reeds bestaande datasets, CIMS en/of kandidaat-zibs op de aanwezigheid van informatiebouwstenen die toegepast kunnen worden in de nieuwe dataset
*Conformeer zoveel mogelijk aan het zorgproces, de informatiestandaard (op basis van richtlijnen en functioneel ontwerp) maar ook aan de gegevensmodellen van de zibs en informatiebouwstenen
*Voeg alleen dataelementen en (waarden in) waardelijsten toe als deze niet worden gerepresenteerd door reeds beschikbare dataelementen en (waarden in) waardelijsten in zibs en/of informatiebouwstenen
*Conformeer zo veel mogelijk aan de generieke volgorde van zibs en informatiebouwstenen in een dataset
*Zorg voor het gebruik van correcte en up-to-date terminologie(koppelingen). Betrek hiervoor in een zo vroeg mogelijk stadium het Terminologiecentrum.
In dit best practice document wordt in de subhoofdstukken hierna voor elk van deze punten beschreven wat dit betekent voor de daadwerkelijke samenstelling van een dataset.

'''2.1.1 Meest recent gepubliceerde zibs'''

Over het nut en noodzaak van zibs is reeds de nodige literatuur [https://zibs.nl/wiki/Hoofdpagina beschikbaar]. Door voortschrijdend inzicht en met inbreng van vele stakeholders worden zibs middels een strikt nageleefd beheerproces aangepast. Bij het samenstellen van een nieuwe dataset is het dan ook van groot belang om de meest recent gepubliceerde zibs te gebruiken.
In ART-DECOR zijn alle zibs van de meest recente publicatie beschikbaar en kunnen worden gebruikt als informatiebouwsteen om een dataset mee samen te stellen. Door zoveel mogelijk gebruik te maken van de zib concepten, kan informatie in alle afzonderlijke zorgtoepassingen op dezelfde manier worden vastgelegd (tussen de zender en ontvanger) en blijft de betekenis gelijk.
Zibs zijn concepten die zorgbreed kunnen worden toegepast. Het kan daarom voorkomen dat in specifieke gegevensoverdrachten in een bepaald domein een aanvulling op dit concept nodig is. Bijvoorbeeld extra dataelementen of waardelijsten die niet in de zibs zijn opgenomen. Ook kan het voorkomen dat binnen een dataset slechts een deel van de zib wordt gebruikt. Elementen van een zib kunnen daarom ook worden verwijderd, zolang dit het conceptuele model van de zib niet compromitteert.

'''2.1.2 Informatiebouwstenen'''

Naast zibs kunnen ook informatiebouwstenen worden gebruikt bij het samenstellen van een dataset. Informatiebouwstenen kunnen zibs zijn met een aantal toevoegingen of verwijderingen van dataelementen en/of waardelijsten, detailed clinical models (DCM’s) die geen zibs zijn of nog kandidaat-zibs zijn (zie ook ‘Zorginformatiebouwstenen – Richtlijnen bij afwezigheid van zib’s’) of een zelf opgebouwde informatiebouwsteen. Vaak zijn deze informatiebouwstenen voor één of hooguit enkele zorgdomeinen van toepassing, in tegenstelling tot zibs die zorgbreed toegepast kunnen worden.
Bekijk daarom ook functioneel ontwerpen en informatiebouwstenen in datasets van andere informatiestandaarden om te bepalen of er, al dan niet gedeeltelijke, overlap is met betrekking tot de inhoud van de gegevensuitwisseling. Door hergebruik van informatiebouwstenen worden ook gegevensuitwisselingen die niet met zibs kunnen worden gemodelleerd, zoveel mogelijk gestandaardiseerd.

[[File:Opstellen_dataset_paragraaf2.1.png|576×254px]]

Hoe een zib in een bepaalde zorgsituatie (usecase) wordt gebruikt is vastgelegd in een informatiestandaard. Een informatiestandaard voegt context en relaties toe aan de zib gegevensmodellen en beschrijft in welke zorgsituatie je welke gegevens vastlegt en uitwisselt [zie ook https://www.nictiz.nl/standaardisatie/informatiestandaarden/].

'''2.1.3 Zorgproces, informatiestandaard en gegevensmodellering'''

Vanzelfsprekend zijn het zorgproces en kwaliteitstandaarden/richtlijnen de leidraad voor wat er in de dataset moet worden toegevoegd aan zibs, informatiebouwstenen en/of dataelementen en waardelijsten. Vaak wordt er bij het samenstellen van de dataset en meer nog het datascenario (zie het hoofdstuk Samenstellen datascenario) ruggespraak gehouden met experts uit het zorgveld. Deze dataexperts kunnen waardevol inzicht verschaffen bij het ‘fijnslijpen’ en completeren van een dataset en de datascenario’s. Hierbij dient er wel scherp op gelet te worden dat de dataset samenstelling er is voor interoperabiliteit en niet voor het modelleren van systemen.

'''2.1.4 Toevoegen dataelementen en waardelijsten'''

In een dataset kunnen ook ‘losse’ dataelementen en specifieke waardelijsten worden toegevoegd. Meestal worden deze dataelementen en/of waardelijsten toegevoegd aan onterfde zibs en/of informatiebouwstenen om deze op maat te maken voor een specifieke informatiestandaard, zie ook Methoden voor samenstellen datasets bij subhoofdstuk 2.2.5 Invoegen en verwijderen dataelementen en waarden in waardelijsten. In een enkel geval kunnen dataelementen ook rechtstreeks in een dataset worden ingevoegd.
Er moet goed worden overwogen welke gevolgen dit heeft voor de datascenario’s en onderliggende HL7-berichten. Ook moet er scherp op gelet worden dat eventuele toevoegingen van dataelementen en (waarden in) waardelijsten complementair zijn aan de reeds beschikbare gegevens in de zibs en niet als vervanging voor terminologie.

'''2.1.5 Volgordelijkheid (zorg)informatiebouwstenen en dataelementen in dataset'''

Naast dat datasets de verzameling zijn van alle gegevens in alle datascenario’s, zijn datasets ook bedoeld om een overzicht te bieden aan Nictiz collega’s en externe dataexperts. Door een zoveel mogelijk gestandaardiseerde volgorde van zibs en informatiebouwstenen aan te houden in een dataset, wordt er een beter overzicht gecreëerd. Ook is het mogelijk om bepaalde segmenten toe te passen, zoals een groep ‘bundel’ of ‘bouwstenen’ waarbinnen de (zorg)informatiebouwstenen zijn ondergebracht waarnaar wordt verwezen vanuit andere delen van de dataset.
Een strak gereguleerde volgordelijkheid van informatiebouwstenen in alle informatiestandaard-datasets is lastig te realiseren. Het voornaamste is dat Nictiz collega’s en externe partijen op een zo eenvoudig en intuïtief mogelijke wijze de samenstelling van een dataset goed kunnen overzien.
Hieronder is een voorbeeld als leidraad voor een volgordelijkheid van zibs en informatiebouwstenen in een dataset:
*Patiënt
*Zorgverlener
*Zorgaanbieder
*Contactmomenten
*Zibs en informatiebouwstenen m.b.t. triage, diagnose
*Zibs en informatiebouwstenen m.b.t. behandeling en verrichting
*Zibs en informatiebouwstenen m.b.t. uitslagen en verslaglegging
*Zibs en informatiebouwstenen voor specifieke onderwerpen in een usecase
Echter, het is mogelijk dat deze volgordelijkheid in bestaande en nieuwe datasets in ART DECOR niet is toegepast. Vooral de wat oudere datasets zijn hierin soms afwijkend. En regelmatig zijn er in datasets de eerder genoemde segmenten gebruikt waarbij zibs en informatiebouwstenen in een groep zijn samengevoegd, zoals “Demografie en identificatie” met zibs Patiënt, Contactgegevens en BurgerlijkeStaat of “Sociale Anamnese” met zibs Woonsituatie, Taalvaardigheid, ParticipatieInMaatschappij en HulpVanAnderen.

===Methoden voor samenstellen datasets===
Datasets kunnen met verschillende methoden worden samengesteld:
*Erven (zibs en informatiebouwstenen)
*Onterven (na eerst te hebben geërfd)
*Verwijzen
*Relaties maken tussen informatiebouwstenen
*Invoegen en verwijderen dataelementen en (waarden in) waardelijsten
In dit best practice document wordt elk van deze methoden beschreven, alsook een uitleg over welke methode te gebruiken in bepaalde situaties.

'''2.2.1 Erven'''

Binnen ART-DECOR kan een zib of een informatiebouwsteen uit een andere dataset in de eigen dataset worden geërfd. Erven houdt in dat alle gegevenselementen van een zib of informatiebouwsteen, inclusief de onderlinge samenhang (structuur), worden gekopieerd en toegevoegd in de nieuwe dataset.

'''2.2.2 Onterven'''

Een geërfde zib of (zelf ontwikkelde) informatiebouwsteen dient in veel gevallen nog te worden aangepast. Er kunnen gegevenselementen aan worden toegevoegd of juist verwijderd (hoofdstuk 2.2.5). Ook kunnen er relaties worden toegevoegd, zoals wordt beschreven in hoofdstuk 2.2.4 – Relaties binnen datasets. Om dit te kunnen doen, dient een overerfde zib of informatiebouwsteen te worden onterfd, alvorens wijzigingen te kunnen doorvoeren.
Op deze manier ontstaan nieuwe informatiebouwstenen, welke volledig naar informatiebehoefte zijn gemaakt maar waarbij toch zoveel mogelijk de generieke zibs blijven behouden. Hierbij geldt wel dat alleen optionele elementen uit een zib kunnen worden verwijderd en niet de elementen die de kern van een concept omvatten; alleen dan is een nieuwe bouwsteen compatibel met oorspronkelijke zib.
Om in een dataset meer duiding te geven aan de toepassing van een zib, kan na onterven de naamgeving van een zib worden hernoemd. Als voorbeeld: in de dataset voor de informatiestandaard Geboortezorg wordt de zib Probleem twee keer toegepast maar elk in een andere context. Daarom is de zib Probleem voor de twee contexten hernoemd naar respectievelijk ProbleemKind en ProbleemMoeder. In de referentie van de zib is nog steeds zichtbaar dat voor elk van de twee contexten de zib Probleem de basis is.
Edoch, middels het plaatsen van een zib in een datagroep met een context kan ook duiding worden gegeven aan de specifieke toepassing van een zib in een dataset. Dit is beschreven in paragraaf 2.2.3 Verwijzingen. Uit oogpunt van herkenning van het gebruik van zibs en het gebruik van ADA is de voorkeur om datagroepen met context te gebruiken boven het hernoemen van zibs.

'''2.2.3 Verwijzingen'''

In een dataset kan een verwijzing vanuit een informatiebouwsteen naar een andere informatiebouwsteen of losse gegevenselementen worden gemaakt. Dit wordt gedaan wanneer een generieke informatiebouwsteen – in de meeste gevallen een zib – binnen een dataset meerdere keren op de zelfde wijze wordt gebruikt. Bij een verwijzing worden dus de gegevens van de informatiebouwsteen waar naar verwezen wordt ook opgenomen binnen de informatiebouwsteen van waaruit verwezen wordt. Door de verwijzing te maken in een datagroep met een specifieke context, zijn de gegevens vanuit de verwezen bouwsteen daarmee ook van toepassing op deze context.
Hieronder is een voorbeeld van de zib Labuitslag waarin gegevens over de laboratoriumverantwoordelijke, aanvrager en de uitvoerder zijn opgenomen. Voor drie verschillende contexten wordt steeds de zib Zorgverlener gebruikt; elk dus met een specifieke context. Hieronder de uitwerking van dit voorbeeld in ART DECOR, in blauw omrand:

[[File:Opstellen_dataset_paragraaf2.2.png|576×254px]]

In dit voorbeeld staat de zib Zorgverlener elders in de dataset uitgewerkt. Deze uitwerking is dus van toepassing op de drie contexten waarin deze zib wordt gebruikt.
Verwijzingen tussen informatiebouwstenen en/of losse gegevenselementen worden doorgaans binnen één dataset te worden gemaakt (want je kunt in principe ook verwijzen naar bouwstenen die in een andere dataset staan). Alleen in dat geval is er op de volledige dataset, inclusief de bouwstenen waar naar wordt verwezen, volledig beheer mogelijk.

'''2.2.4 Relaties'''

In een dataset kunnen ook relaties worden gelegd tussen informatiebouwstenen. Het verschil met het maken van een verwijzing is dat bij een relatie vanuit een bouwsteen naar een andere bouwsteen niet de gegevens van die gerelateerde bouwsteen worden opgenomen maar zijn wel te herleiden.
Als bijvoorbeeld gegevens over een medicatieafspraak worden uitgewisseld, dan wil men weten of er een relatie is met een andere medicatieafspraak (start- en stop afspraken over dezelfde medicatie), toedieningsafspraak, medicatiegebruik, contact waarin de medicatieafspraak is gemaakt en de zorgepisode. Het is dan niet de bedoeling om alle gegevens over al deze bouwstenen mee te sturen, alleen om welke specifieke instantiaties van deze bouwstenen het gaat. Dit kan worden gedaan door een relatie te leggen naar de identificatie van deze specifieke instantiaties van de bouwstenen middels het Object Identifier (OID).
Het OID nummer is samengesteld uit een deel met de identificatie van de uitgevende organisatie – de zorgaanbieder van waaruit gegevens worden verstuurd – en een deel met de identificatie van een uniek gegeven dat is opgeslagen in het informatiesysteem van deze zorgaanbieder. Voor meer uitleg hierover zie de informatie op de HL7 site.
Hieronder de uitwerking van dit voorbeeld, waarin de relaties naar de OID’s van andere bouwstenen oranje zijn omkaderd:

[[File:Opstellen_dataset_paragraaf2.2.4png.png|576×254px]]

Om een volledig overzicht te hebben van alle relaties tussen informatiebouwstenen en gegevenselementen in een dataset, is het zeer aan te bevelen om een datamodel te maken voor elke usecase.

'''2.2.5 Invoegen en verwijderen dataelementen en (waarden in) waardelijsten'''

Zoals in hoofdstuk 2.1.4 reeds is toegelicht kunnen in een dataset ook afzonderlijke dataelementen en/of (waarden in) waardelijsten worden toegevoegd of verwijderd.
Het toevoegen of juist verwijderen van dataelementen – of groepen met dataelementen – binnen een informatiebouwsteen zorgt ervoor dat een informatiebouwsteen specifieker wordt gemaakt. In gegevensuitwisselingen binnen één domein (bijvoorbeeld huisartsen) kan het nodig zijn om specifieke elementen toe te voegen. Als voorbeeld is het toegevoegde dataelement ‘Presentatierol’ in de zib ‘Zorgverlener’ binnen het huisartsendomein.
Een dergelijke toevoeging moet altijd goed worden overwogen, zoals ook al in hoofdstuk 2.1.4 is toegelicht. Dit heeft namelijk ook consequenties voor het HL7 materiaal. Daarbij draagt een toevoeging ten behoeve van één domein niet bij aan standaardisatie van gegevensuitwisselingen over de domeinen heen. Zo zal een ‘Presentatierol’ in een gegevensuitwisseling van een huisarts naar een medisch specialist geen nut hebben.
Verwijdering van één of meerdere gegevenselementen uit een zib of informatiebouwsteen in de dataset wordt gedaan als deze in geen enkele gegevensuitwisseling van de informatiestandaard voorkomt. Belangrijk is wel dat het concept van de zib daarmee niet wordt aangetast; alleen optionele elementen in een zib mogen worden verwijderd.
Ook waardelijsten kunnen in zijn geheel worden toegevoegd of verwijderd, maar ook specifieke waarden ín een waardelijst. Een regelmatig voorkomende situatie is dat een waardelijst in een zib teveel algemene waarden bevat voor een gegevensuitwisseling en/of dat er specifieke waarden ontbreken. In dat geval wordt er een waardelijst op maat gemaakt ter vervanging van de initiële zib-waardelijst. Ook kan het voorkomen dat in een gegevensuitwisseling binnen één domein een aparte waardelijst van gelijke conceptuele strekking kan worden gebruikt. Denk hierbij aan specifieke NHG-tabel waardelijsten zoals NHG-tabel 12 ‘Soort derde’ naast de Vektis AGB AfdelingSpecialismeCodelijst.
In de handleiding voor ART DECOR [Documentatie-ART] is beschreven hoe dit in zijn werk gaat. Door te koppelen aan een dataelement wordt er context gegeven aan hoe een waardelijst wordt gebruikt in gegevensuitwisseling.
Ook kunnen waardelijsten zelf worden opgesteld en ingevoegd worden. In dit geval is het van belang om de termen in deze waardelijst te toetsen bij het Terminologiecentrum. Het Terminologiecentrum zorgt er dan voor dat de termen worden gekoppeld aan termen in codestelsels zoals SNOMED CT of LOINC. In het volgende hoofdstuk wordt hier verder op ingegaan.

===Terminologie in datasets===
Deze paragraaf biedt een werkvoorschrift voor het vastleggen van terminologiekoppelingen in ART-DECOR met een onderbouwing voor de keuze in werkwijze. Het document gaat hoofdzakelijk in op de werkvoorschriften omtrent SNOMED-termen, terwijl er verschillende (inter)nationale terminologiestelsels zijn. Gezien SNOMED het meest complexe stelsel is met de meeste regels, is vooral ten aanzien van SNOMED-terminologiekoppelingen een leidraad nodig om te komen tot consistentie binnen en tussen informatiestandaarden. Tot slot, huidig document gaat uit van ART-DECOR 2. Momenteel biedt ART-DECOR 3 niet dezelfde opties. Bij doorontwikkeling van ART-DECOR 3 zal gekeken worden welke opties noodzakelijk zijn (zie BITS-issues binnen het project ART-DECOR).

'''2.3.1 Terminologiekoppelingen'''

Een dataset wordt gecodeerd via het aanbrengen van terminologiekoppelingen. Dit omvat terminologiekoppelingen bij dataset-concepten en bij waardes in waardelijsten. In de [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn terminologie koppelen] geeft het Terminologiecentrum achtergrondinformatie over de verschillende terminologiestandaarden en worden handvatten geboden voor het uitvoeren van terminologiekoppelingen en het gebruik van terminologie in informatiestandaarden.

'''2.3.1.1 Dataset-concepten'''

Aan een dataset-concept kan een definitiecode via een terminologiekoppeling toegekend worden. In de Leidraad terminologiestandaarden (paragraaf 4.2) zijn de regels terug te vinden om te komen tot een juiste terminologiekoppeling als definitiecode van een dataset-concept. De naam van het dataset-concept zou overeen moeten komen met een beschrijving van het gekoppelde terminologieconcept, die door de beheerder van het stelsel geaccordeerd is (in SNOMED betreft dit een vertaling uit de Nederlandse extensie en in LOINC een vertaling uit de Nederlandse taalset van het Regenstrief). Terminologiekoppelingen van dataset-concept en waardelijst zouden op elkaar afgestemd moeten zijn (via vraag en antwoord of op basis van hoofdcategorie en verfijning). Waar mogelijk dient context gebruikt te worden: een gedetailleerd dataset-concept kan gekoppeld worden aan een generiek terminologieconcept, mits de ontbrekende informatie uit de andere terminologiekoppelingen blijkt.

'''2.3.1.2 Waardelijsten'''

Dataset-concepten kunnen een waardedomein hebben waarin concepten worden benoemd die als waarde kunnen dienen. Deze waardes behorende bij een dataset-concept kunnen op twee manieren vastgelegd worden in ART-DECOR: via de Waardelijst-editor (gecodeerde waardes) of via de Dataset-editor (ongecodeerde conceptnamen). De Waardelijst-editor is best practice. Via de Waardelijst-editor is het waardedomein te definiëren via het koppelen van een waardelijst. Deze waardelijst kan bestaan uit een geheel codesysteem of deel van een codesysteem (referentieset, tabel, etc.), een query van codes in een codesysteem (bijvoorbeeld: ‘is-een-kind-van’) of een selectie van losse codes. Indien het waardedomein is gedefinieerd via een selectie van losse codes, wordt in ART-DECOR tevens terminologie bij de codes vastgelegd. In de overige gevallen haalt de softwareleverancier de terminologie op bij het codesysteem (bij voorkeur via de Nationale Terminologieserver).
Het opbouwen van een lijst met ongecodeerde conceptnamen (via de Dataset-editor) kan als aanzet dienen tot het opbouwen van een lijst met gecodeerde conceptnamen (via de Waardelijst-editor). Indien er vanuit gebruikers behoefte is om in de informatiestandaard aanvullend andere termen op te nemen dan die in het terminologiestelsel staan opgenomen, heeft het voorkeur om hiervoor het veld Omschrijving te gebruiken in plaats van een aanvullende lijst met ongecodeerde conceptnamen. Overigens wordt deze lijst met ongecodeerde conceptnamen niet verwerkt in de technische berichten, maar deze dient door leveranciers separaat opgehaald te worden vanuit ART-DECOR.

'''2.3.2 Terminologievelden'''

ART-DECOR biedt verschillende velden om termen bij een terminologiecode vast te leggen. Dit betreffen de velden Weergavenaam (displayName), Benamingen (designation) en Omschrijving (description).
In de documentatie over ART-DECOR worden deze velden als volgt omschreven:
*displayName: The optional human readable display name for the code for orientation purposes. This display name corresponds to an official display name or synonym for the code in the code system.
*designation: Designations are language dependent display names for the code. For any language there might be multiple, each specifying the type (fully specified name, preferred, synonym, …).
*description: You may add a description for convenience, but should note that most of the time the description here overlaps with the designation/description of the coded concept.
Wat getoond wordt in ADA in het dropdownmenu bij het maken van kwalificatiemateriaal, is afhankelijk van wat ingevuld is in ART-DECOR bij het opbouwen van de waardelijst. Tekst uit het veld description wordt niet getoond in ADA.
Voor de specifieke toepassing van deze velden in zibs en informatiestandaarden is na overleg tussen informatieanalisten, informatiearchitecten van het Zib-centurm, terminologen en HL7-specialisten functie/ doel als volgt gedefinieerd:
*Weergavenaam: Leesbare weergave van de terminologiecode, waarbij de term afkomstig is uit het oorspronkelijke codesysteem. Dit is een hulp ter herkenning voor informatieanalisten, informatiearchitecten, terminologen, HL7-specialisten, softwareontwikkelaars en zorgverleners die betrokken zijn bij de ontwikkeling en het beheer van een zib of informatiestandaard.
*Benaming (volledig gespecificeerde naam): Hulp voor informatieanalisten en terminologen ter validatie van de terminologiekoppeling.
*Omschrijving: Toelichting ter verduidelijking van de betekenis van de gekoppelde terminologiecode, in aanvulling op terminologie uit het oorspronkelijke codesysteem. Dit kan een definitie van de waarde betreffen, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of de userinterfaceterm.

Het opnemen van terminologie in ART-DECOR uit een codesysteem heeft consequenties voor het beheer van een zib of informatiestandaard: bij elke release van een zib of informatiestandaard zal via het TerminologyReport gecontroleerd moeten worden of de terminologie in ART-DECOR nog overeenkomt met de terminologie in het codesysteem (een term kan in de tussentijd, tussen release van een zib of informatiestandaard en een meer recente release van het codesysteem, veranderd zijn in het codesysteem), net zoals gecontroleerd dient te worden of een terminologiecode niet is komen te vervallen.
Bij het vastleggen van terminologie in ART-DECOR kan gebruik gemaakt worden van de selectietool. Met deze tool kan een concept in een codesysteem worden opgezocht en worden opgenomen in de waardelijst. De terminologie is afkomstig uit een lokale kopie van het codesysteem. Terminologie wordt niet automatisch bijgewerkt als deze in het codesysteem verandert.
Indien gebruik gemaakt wordt van de selectietool in ART-DECOR voor het inladen van SNOMED-concepten, wordt voor het veld Weergavenaam de Nederlandse fully specified name ingeladen (indien er een Nederlandse vertaling beschikbaar is) en voor het veld Benamingen de fully specificied name, preferred term en synonyms in de beschikbare talen. Om de best practice uit dit document te volgen, kan het nodig zijn om de ingeladen termen via de selectietool aan te passen.
Gezien er een aantal jaar geleden nog weinig Nederlandse vertalingen van SNOMED beschikbaar waren, kunnen bij terminologiecodes in eerder gepubliceerde zibs en informatiestandaarden nog Engelstalige termen staan. Inmiddels heeft het merendeel van de SNOMED-termen een Nederlandse vertaling. Indien een vertaling toch ontbreekt, dient deze aangevraagd te worden bij het Terminologiecentrum.
Soms maakt het Terminologiecentrum een nieuwe SNOMED-code aan binnen de Nederlandse extensie, wanneer er geen geschikte SNOMED-code is binnen de internationale versie. Deze nieuwe SNOMED-code zal in de meeste gevallen nog niet opgenomen zijn in de huidige gepubliceerde versie van SNOMED op moment van release van de zib of informatiestandaard. In dat geval dient de term bij de terminologiecode handmatig ingevoerd te worden. Let hierbij op dat de Nederlandse SNOMED-termen beginnen met een kleine letter en de Engelstalige SNOMED-termen met een hoofdletter.

'''2.3.2.1 Dataset-concepten'''

'''2.3.2.1.1 Weergavenaam'''

Bij het aanbrengen van een terminologiekoppeling bij een dataset-concept biedt ART-DECOR één veld, namelijk Weergavenaam, om een term in tekst mee te geven bij de code. Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse fully specified name te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een waarde). Er is gekozen voor de volledig gespecificeerd naam, gezien deze term niet alleen een leesbare weergave biedt bij de code, maar tevens validatie van de terminologiekoppeling mogelijk maakt.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2 Waardelijsten'''

'''2.3.2.2.1 Weergavenaam '''

Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse preferred term te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een dataset-concept). Er is gekozen voor de Nederlandse preferred term, gezien deze term het beste aansluit bij het doel van het bieden van een leesbare weergave van de terminologiecode. De fully specificied name in SNOMED bevat een semantic tag, waarbij kennis van SNOMED vereist is om deze te kunnen interpreteren. Bovendien is de fully specified name langer dan de preferred term, wat een onoverzichtelijkere weergave kan betekenen.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2.2 Benamingen'''

Het veld Benaming (type volledig gespecificeerde naam) dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient in dit veld de Nederlandse fully specified name opgenomen te worden. De fully specified name bevat de semantic tag die aangeeft in welke SNOMED-hiërarchie het concept valt, waardoor het mogelijk is om te beoordelen of de terminologiekoppeling correct is (op basis van de semantic tag kunnen bepaalde inconsistenties in een waardelijst in het oog springen, waar anders gemakkelijk overheen gekeken kan worden).
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.
De overige typen Benamingen (type voorkeursterm en type synoniem) dienen niet gevuld te worden. Deze velden vervullen, in tegenstelling tot Benaming (type volledig gespecificeerde naam), geen specifieke functie in het functioneel ontwerp van een informatiestandaard of zib.

'''2.3.2.2.3 Omschrijving'''

Het veld Omschrijving wordt gevuld afhankelijk van de behoeften van de eindgebruikers van de zib of informatiestandaard. In het veld Omschrijving kan tekst meegegeven worden die niet in het codesysteem opgenomen staat. Dit kan een toelichting zijn ter verduidelijking van de betekenis van de gekoppelde terminologiecode in aanvulling op terminologie uit het oorspronkelijke codesysteem, een definitie van de waarde, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of (suggestie voor) de userinterfaceterm. Dit veld is daarmee een hulp voor ontwikkelaars om te komen tot een geschikte benaming in de userinterface.
Indien het veld Omschrijving een userinterfaceterm bevat, hebben informatieanalist/informatiearchitect en terminoloog gevalideerd dat deze term en gekoppelde terminologiecode overeenkomen in betekenis binnen de context van de waardelijst. Een userinterfaceterm kan specifieker zijn dan de term in het codesysteem door de context die de waardelijst meegeeft, of juist meer generiek, doordat de context van de waardelijst een specifieke benaming van de waarde overbodig maakt.
Indien er met de betrokken partijen afgesproken is dat het beheer van de gebruikte terminologie van een waardelijst binnen de informatiestandaard valt, waarbij er afspraken gemaakt zijn over de letterlijke term die op de gebruikersinterface getoond dient te worden, is dit veld onderdeel van de kwalificatie.
2.3.3 Het maken van gespecialiseerde waardelijsten
Zoals in 2.2.5 is benoemd kan het nodig zijn om een waardelijst van een geërfde bouwsteen te vervangen door een gespecialiseerde waardelijst. In het geval dat er een beperkt aantal concepten aan de oorspronkelijke waardelijst moeten worden toegevoegd of juist verwijderd zijn er twee alternatieven:
*Een kopie maken van de waardelijst van de geërfde bouwsteen en deze bewerken. De relatie van de nieuwe waardelijst met de oorspronkelijke waardelijst gaat verloren. Wijzigingen in de oorspronkelijke waardelijst worden niet doorgevoerd op de gespecialiseerde waardelijst. Je kiest hiervoor als de gespecialiseerde waardelijst niet lijkt op oorspronkelijke waardelijst, bijvoorbeeld omdat de gespecialiseerde waardelijst een opsomming is van mogelijke waarden en de oorspronkelijke een codestelsel, of een deel van een codestelsel gespecificeerd met een intensionele expressie.
*De waardelijst van de geërfde bouwsteen includeren in de gespecialiseerde waardelijst. Hierbij blijft de relatie met de oorspronkelijke waardelijst zichtbaar. Dit kan op twee manieren:
*Statische inclusie: een specifieke versie van de waardelijst wordt geïncludeerd (deze zal niet meer wijzigen)
*Dynamische inclusie: de laatste versie van de waardelijst wordt geïncludeerd. Doorgaans wordt bij een gespecialiseerde lijst geen dynamische inclusie toegepast. Maar indien hier wel voor is gekozen, moet ervoor wordt gewaakt of de inclusie en de zelf toegevoegde waarden inderdaad volledig disjunct zijn en blijven zodat er geen dubbelingen ontstaan. Het alternatief is om de eigen toevoegingen mee te laten nemen in de volgende release van een waardelijst.
De extra concepten, nodig voor de specialisatie, kunnen los worden toegevoegd of met Inclusies. Bij deze laatste methode moet een intentionele expressie worden ingevuld. Concepten uit de waardelijst van de geërfde bouwsteen die juist niet gewenst zijn in de gespecialiseerde waardelijst, kunnen met exclusies worden uitgesloten (ook weer met intentionele expressie).

===Generieke modelering – afspraken===

In hoofdstuk 2.2.4 is uitgelegd dat er tussen de verschillende bouwstenen en/of dataelementen in bouwstenen relaties kunnen worden gelegd. Deze relaties geven context aan of nadere aanvulling van gegevens. In het kader van standardisatie van gegevensuitwisseling niet alleen binnen één informatiestandaard maar ook in standaardisatie tussen alle informatiestandaarden is het belangrijkom dit soort relaties op een zoveel mogelijk eenduidige manier te doen. Als in alle informatiestandaarden op dezelfde manier relaties en modeleringen van gegevens worden gemaakt, is het voor de informatieanalisten veel eenvoudiger om te bepalen wat er in de verschillende informatiestandaarden aan gegevens worden uitgewisseld en hoe dit op elkaar aansluit. Evenzo belangrijk is dat de technische specificaties in HL7 berichten veel meer generiek kunnen worden uitgewerkt.

==Samenstellen scenario’s==

Een Nictiz informatiestandaard bevat minimaal één maar meestal meerdere usecases. Een usecase is een beschrijving van een informatie-uitwisseling op een specifiek moment in het zorgproces, waarbij voor een concrete praktijksituatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Zoals eerder gemeld staan alle usecases van één informatiestandaard beschreven in een functioneel ontwerp.
De specifieke gegevens die worden uitgewisseld binnen elk van de usecases zijn een subset van de dataset voor een gehele informatiestandaard. Daarom moet voor elke usecase een datascenario worden aangemaakt. In dit hoofdstuk wordt verder ingegaan op de keuzes en mogelijkheden voor het samenstellen van een datascenario.
N.B.: In dit document wordt consequent de term ‘datascenario’ gebruikt in plaats van de term ‘scenario’ zoals dat wordt gebruikt in ART DECOR. De reden is dat ‘scenario’ een term is die breed kan worden opgevat en daarom met verschillende betekenissen in velerlei documentatie wordt gebruikt. ‘Datascenario’ geeft meer context aan de betekenis voor dit document.

===Usecase en datascenario===
In principe wordt er voor elke usecase binnen een informatiestandaard een datascenario samengesteld. De naamgeving van een datascenario volgt veelal de hoofdlijn van elke usecase. Bijvoorbeeld in de informatiestandaard Acute zorg is er de usecase ‘Uitwisseling ambulance naar SEH’ waarvoor het datascenario ‘AMB (ambulance) draagt over aan SEH (Spoedeisende hulp)’ is samengesteld.
Het kan voorkomen dat de inhoud van de gegevensuitwisseling voor meerdere usecases binnen één informatiestandaard hetzelfde is. In dit geval wordt er voor meerdere usecases één datascenario samengesteld, waarbij in de naamgeving van het datascenario de meerdere usecases worden benoemd. Rugten naar ‘scenario

===Datascenario, transactiegroepen en transacties===
Elk datascenario is opgebouwd uit één of meerdere transactiegroepen. Een transactiegroep bevat alle transacties die bijdragen aan één specifieke gegevensuitwisseling tussen twee partijen.
Vaak is het zo dat binnen één datascenario ook maar één transactiegroep wordt gebruikt maar het is evengoed mogelijk om binnen één datascenario meerdere transactiegroepen te gebruiken, dit wordt verderop in dit hoofdstuk toegelicht.
Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.
Elke transactiegroep kan weer één of meerdere transacties bevatten. Een transactie is een werkelijke overdracht van gegevens.
Een transactiegroep waarin berichten worden verstuurd, bevat doorgaans een transactie met de verstuurde gegevens en een transactie met de ontvangstbevestiging. Dit zijn een zogenaamde push-transacties: overdrachten van gegevens waarbij de verzender op eigen initiatief een bericht verstuurt en waarbij de ontvanger dit bericht ontvangt zonder dat daarvoor actief naar is gevraagd.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het versturen van een specifieke gegevensset, ofwel dat het gaat om een ontvangstbevestiging. Vaak wordt deze transactie als overbodig beschouwd en daarom achterwege gelaten.

Een transactiegroep waarin gegevens worden geraadpleegd, bevat doorgaans een transactie met de raadpleging op maat en een transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Dit is een zogenaamde pull-transactie: een overdracht van gegevens waarbij de ontvanger van deze gegevens actief om heeft gevraagd en waarbij de verzender deze gegevens beschikbaar heeft gesteld.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het raadplegen van een specifieke gegevens set, ofwel dat het gaat om het beschikbaarstellen van de geraadpleegde gegevens.
Zoals eerder gemeld kan er in een transactiegroep in plaats van één transactie met alle benodigde gegevens ook worden gekozen voor het toepassen van meerdere transacties voor het versturen van gegevens: bijvoorbeeld één transactie per (zorginformatie-)bouwsteen. Deze constructie kan worden toegepast als er één datascenario wordt gebruikt voor meerdere usecases, waarbij het merendeel van de verstuurde gegevens gelijk is, maar waar er per usecase soms wel of niet een extra bouwsteen moet worden meegestuurd. Een voorbeeld hiervan is het opvragen van de professionele samenvatting door meerdere raadplegende partijen in de acute zorg – de meldkamer, ambulance en de SEH – waarbij de meldkamer geen gegevens over overgevoeligheden wil ontvangen. In dit geval is er geen transactie met de bouwsteen voor overgevoeligheden.
Als voorbeeld voor de hierboven beschreven samenstelling van datascenario’s met transactiegroepen en push- en pull-transacties dient wederom de informatiestandaard voor acute zorg. met hieronder een aantal usecases waarvoor datascenario’s zijn samengesteld met push-transacties, zoals:
*Berichten van de ambulance naar de SEH
*Verwijzen van een patiënt van (waarnemend) huisarts naar de meldkamer
*Versturen rapportages van meldkamer, ambulance en SEH naar de huisarts
In het plaatje hieronder is een uitwerking van het datascenario voor berichten van de ambulance naar de SEH:

[[File:Opstellen_dataset_paragraaf_3.2a.png|576×254px]]

En een drietal usecases waarvoor één datascenario is samengesteld met pull-transacties:
*Opvragen van de professionele samenvatting bij de huisarts door de meldkamer, ambulance of SEH

[[File:Opstellen_dataset_paragraaf_3.2b.png|576×254px]]

In ART-DECOR worden de transacties binnen een datascenario gegroepeerd tot een transactiegroep. In datascenario’s waarin berichten worden verstuurd, bestaan een transactiegroep uit de transactie met verstuurde gegevens en de transactie met de ontvangstbevestiging. In datascenario’s waarin gegevens worden geraadpleegd bestaat de transactiegroep uit de transactie met de raadpleging op maat en de transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.

===Transactiedataset===
Per transactie wordt er een specifieke set gegevens verstuurd van de verzender naar de ontvanger. In een transactiedataset is dit gedetailleerd uitgewerkt. Alle gegevenselementen en (delen van) zibs en/of informatiebouwstenen n een transactiedataset worden betrokken uit de informatiestandaard dataset zoals beschreven in hoofdstuk 2. Andersom kan ook worden gezegd dat alle transactiedatasets van de transacties als onderdeel van een transactiegroep, die op hun beurt weer onderdeel zijn van een datascenario, tezamen de informatiestandaard dataset vormen.

'''3.3.1 Cardinaliteit en conformance'''
In een transactiedataset wordt per gegevenselement ook de kardinaliteit aangegeven. Op de informatiepagina van het zib-centrum is uitgelegd wat kardinaliteiten zijn: https://zibs.nl/wiki/Zib_kardinaliteiten
In informatiemodellen wordt kardinaliteit gebruikt om de multipliciteit van een element ten opzichte van zijn parent – of als het een top level element is, de multipliciteit van de boom eronder - in een transactie aan te geven. Daarbij wordt de notatie ‘m..n’ gebruikt, waarbij ‘m’ de minimale multipliciteit is en ‘n’ de maximale. In het model wordt de kardinaliteit genoteerd bij het element waarvoor dit geldt. Dus als er tussen element A en element B en relatie bestaat en bij element B de kardinaliteit m..n staat, betekent dit dat een element A minimaal met ‘m’ elementen B een relatie heeft en maximaal met ‘n’ elementen B
Naast de multipliciteit wordt met een letter aangegeven of deze relatie Mandatory, Required, Conditional of Optional is:

{| class="wikitable"
! M (Mandatory)
|Een gegeven moet altijd worden aangeleverd. De minimale multipliciteit is dan ook 1..1M
|-
! R (Required)
| Indien een gegeven beschikbaar is, moet deze worden aangeleverd. Bijvoorbeeld als één of meerdere voornamen van een patiënt bekend zijn. De kardinaliteit is in dit geval 0..*R
|-
! C (Conditional)
| Een gegeven dat moet worden aangeleverd, afhankelijk van de waarde of aanwezigheid van een ander gegeven. Bijvoorbeeld de invulling van een toelichting indien in een waardelijst de optie ‘Anders’ is geselecteerd. De kardinaliteit van de toelichting is in dit geval 1..1C
|-
! O (Optional)
| Een gegeven dat eventueel kan worden aangeleverd maar niet noodzakelijk. Deze optie wordt vrijwel niet toegepast. Als een gegeven niet noodzakelijk is binnen een overdracht, wordt deze in de regel ook niet opgenomen in een informatiestandaard.
|}

De kardinaliteiten zoals vastgesteld in de transactiedatasets zijn functioneel leidend. Op basis hiervan kan worden afgeleid wat er in een gegevensoverdracht aan gegevens moet worden meegestuurd. Een verzendende partij weet welke gegevens er moeten worden opgeleverd, al dan niet verplicht, verplicht indien beschikbaar of conditioneel. Een ontvangende partij weet wat er aan gegevens moet worden verwerkt en getoond kunnen worden.
Let op: de kardinaliteit in zibs zijn conceptueel; het kan dus voorkomen dat een kardinaliteit van een gegeven in een transactiedataset enger is als die in een zib. Dit geldt ook voor de kardinaliteiten in HL7v3 tempates en FHIR profielen; deze kunnen minder eng zijn als die in een transactiedataset.
Andersom is conceptueel niet mogelijk. Als iets conceptueel verplicht is of in bijvoorbeeld een FHIR profiel verplicht staat (zoals 1..1M), is het niet mogelijk om in de functionele transactiedataset hier geen verplichting aan te geven (zoals 0..1R).
Zoals in hoofdstuk 2.3.3 en 2.3.4 is uitgelegd kunnen in een dataset – en dus ook in een transactiedataset – verwijzingen en relaties voorkomen. Ook deze kennen kardinaliteiten. Bij verwijzingen geldt dat de bron-bouwsteen waar naar verwezen wordt in de dataset, ook in de transactiedataset moet voorkomen. De kardinaliteit van deze bron-bouwsteenen alle gegevens daarbinnen geldt dat voor alle contexten met verwijzingen. Als voorbeeld is wederom de LaboratoriumUitslag van hoofdstuk 2.3.3:

[[File:Opstellen_dataset_paragraaf_3.3.1.png|576×254px]]

Hierbij geldt dat in de bouwsteen LaboratoriumUitslag de kardinaliteit van de context – LaboratoriumUitslagVerantwoordelijke, Aanvrager en Uitvoerder – aangeeft hoe elk van deze contexten in het bericht moeten worden meegenomen. In dit geval dus alle drie verplicht. De kardinaliteit van de verwezen bouwstenen onder de context geeft aan dat áls er bijvoorbeeld een Uitvoerder is, dat dan de verwezen Zorgverlener óf Zorgaanbieder aanwezig moet zijn (vandaar de kardinaliteit van beiden 0..1 R). Bij de Aanvrager is er maar één mogelijkheid – de Zorgverlener – en vandaar dat deze dan ook mandatory is.
In de verwezen bron-bouwsteen Zorgverlener gelden vervolgens de kardinaliteiten zoals hierin is opgezet.

'''3.3.2 Raadplegen: Query Parameters'''

Voor de transactieset waarin gegevens worden opgevraagd door een partij (PULL), is vaak een selectie op de gegevens van toepassing.

Dit kan op twee manieren zijn ingericht in ART DECOR:
*Vooraf vastgestelde selectie: als onderdeel van de transactie beschikbaarstellen
*Variabele selectie: als query parameter in de transactie raadplegen

De eerst genoemde situatie is vooral van toepassing wanneer er landelijke afspraken zijn dat er altijd een standaard selectie wordt toegepast. Dit zorgt ervoor dat altijd eenzelfde overzicht voor een patiënt wordt gegenereerd. Bijvoorbeeld in de BgZ, is de “laatst bekende bloeddruk” in beschikbaarstellen opgenomen als 0..1 conditioneel:

[[File:Opstellen_dataset_paragraaf_3.3.2a.png|576×254px]]

De laatst genoemde situatie met query parameters, is van toepassing wanneer het nodig is een specifieke selectie per individuele raadpleging te maken. Bijvoorbeeld; de eindgebruiker van een systeem geeft zelf aan voor welke patiënt en in welke periode er informatie opgevraagd wordt. Welke gegevens als query parameters gebruikt kunnen worden, is afhankelijk van de usecase. Vaak zal er een identificatie(nummer) uit de Patiënt zib gebruikt worden zodat de raadpleging gericht voor één persoon plaats vindt.
In ART-DECOR dit worden ingericht, door in de dataset een groep “QueryParameters” op te nemen en dan de relevante parameters in de transactie(s) Raadplegen te gebruiken. Een parameter kan gebruik maken van een gegevenselement uit 1 bouwsteen, bijv. het identificatienummer van de Patiënt. Een andere mogelijkheid is dat een parameter gebruik maakt van 1 type gegeven die op meerdere plaatsen in de dataset voor komt, bijv. een datum(periode) waarin meerdere metingen (zoals bloeddruk, gewicht en lengte) uitgevoerd kunnen zijn.
Om duidelijk te maken aan wélke gegevens de parameters gelinkt zijn, kan je de in de dataset dit toelichten in de naam en omschrijving van de query parameter. Ook de zoekwijze kan je hier toelichten, zoals voor periodes waarin gezocht kan worden. Als daarnaast per transactie nog aparte regels gelden, kan je dit via het veld context bij de transactie uitleggen (en/of via een Conditie indien dit van toepassing is).
Als voorbeeld hieronder een weergave van de Gebruiksperiode in de transactie Raadplegen medicatieafspraak (MP 2.0.0): voor de gebruiksperiode is in de omschrijving van het concept aangegeven op welke conceptgroepen uit de dataset (“MA, WDS en TA”) de periode van toepassing is. Voor de transactie is dan ook nog een conditie opgenomen ter nadere specificatie.

[[File:Opstellen_dataset_paragraaf_3.3.2b.png|576×254px]]

=Release notes=
In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Ontwikkelen en Testen

2025-11-13T09:50:33Z

Lilian Brouwer: /* Procesactiviteiten */

qa:Ontwikkelen en Testen

2025-11-13T09:49:26Z

Lilian Brouwer: /* Procesactiviteiten */

qa:Ontwikkelen en Testen

2025-11-13T09:39:21Z

Lilian Brouwer: /* Procesactiviteiten */

pa:VDraft Toetsingscriteria

2025-11-11T11:19:46Z

Lilian Brouwer: /* Taal */

{{underconstruction}}
{{NOINDEX|visible=yes}}
{{DISPLAYTITLE:Toetsingscriteria Productarchitectuur (draft-versie)}}
{| class="wikitable"
|-
! | [https://informatiestandaarden.nictiz.nl/wiki/pa:Hoofdproces Hoofdpagina Productarchitectuur] | [https://informatiestandaarden.nictiz.nl/wiki/pa:Productarchitectuurprincipes Productarchitectuurprincipes] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingskader Toetsingskader] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingscriteria Toetsingscriteria]
|}
=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:1
** 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 logische modellen (nu worden ze soms als logisch en andere keren alleen als conceptueel model beschouwd)
** Zibs hebben kardinaliteiten op logisch niveau (nu hebben zibs [https://zibs.nl/wiki/Zib_kardinaliteiten 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 (door)ontwikkelen 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 informatiestandaard2
** Verantwoordelijk voor een impactanalyse3 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 nieuwe versie van de informatiestandaard
** → vereist flexibel releasebeleid voor zibs
** Nictiz werkt aan plan voor flexibel publiceren van zibs4
* 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 [[#Logisch|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 opgeleverd4
** Dit is een praktische uitwerking van de reeds opgeleverde architectuurprincipes zibs 2.0
 
1 [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0];
2 [https://www.nen.nl/nen-7522-2021-nl-283706 NEN 7522:2021 Ontwikkelen en beheren van standaarden en stelsels van standaarden];
3 [https://nictiz.nl/app/uploads/2023/10/Duurzaam-Releasebeleid-versie-1.0.0_oktober2023.pdf Duurzaam Releasebeleid v1.0.0 par. 3.2.1];
4 [https://nictiz.nl/app/uploads/2025/07/Plan-van-Aanpak-zib-transitie_Verder-met-zibs-in-databeschikbaarheid_v1.1.pdf Plan van aanpak: Verder met zibs in databeschikbaarheid v1.1]

=Taal=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|1.1.1]]
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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 aan de criteria voor 'extensible'. 
* Indien het gaat om een waardelijst van de zib met OTH Nullflavor, moet vrije tekst gebruikt worden als OTH de gekozen waarde is.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden] 
 
[https://zibs.nl/wiki/Codelist_Bindings_Backup Bindings van zibs] 
[https://nictiz.atlassian.net/browse/ZIB-2685| ZIB-2685] 
[https://nictiz.atlassian.net/issues/ZIBFHIR-249| ZIBFHIR-249]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|1.1.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Informatiestandaarden voegen geen waardelijsten toe naast de in de zib gespecificeerde waardelijsten.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden]
|-
| style="vertical-align:top; text-align:left" | 1.1.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden]
|-
| style="vertical-align:top; text-align:left" | 1.1.4
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://nictiz.nl/app/uploads/2024/10/Dynamische-waardelijsten_oktober2024.pdf?_gl=1*g821zl*_up*MQ..*_ga*MTkwNzg4MTcwMS4xNzQ0NzA3NjQ1*_ga_0ZRXV90GXH*MTc0NDcwNzY0NS4xLjEuMTc0NDcwNzY0OS4wLjAuMjA0Mzk0MzMyNA.. Advies Dynamische waardelijsten]
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''Principe 1.2''' Producten voldoen aan besluiten over de te gebruiken terminologiestelsels. ''Rationale: Gebruik van hetzelfde terminologiestelsel voor dezelfde doeleinden zorgt voor [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=eenheid+van+taal eenheid van taal].''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.2.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://www.nictiz.nl/overig/van-eenduidige-informatie-uitwisseling-tot-hulpmiddel-voor-betere-zorg/ Visie Eenheid van Taal]
|-
| style="vertical-align:top; text-align:left" | 1.2.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Diagnoses, problemen, behandelingen en verrichtingen worden gecodeerd met SNOMED. 
Zo niet, dan verloopt de overstap volgens de opgestelde SNOMED-roadmap.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/bibliotheek/snomed-besluit/ SNOMED-besluit 2024]
|-
| style="vertical-align:top; text-align:left" | 1.2.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Terminologiekoppelingen in de dataset van een informatiestandaard zijn conform de Richtlijn Terminologie koppelen.
| style="vertical-align:top; text-align:left" | [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn Terminologie koppelen v1.0]
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 2.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaarden gebruiken zibs als generieke standaard voor de logische modellen. 
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset QA Instructie opstellen dataset v3.0.1] 
[https://nationalebibliotheek.nictiz.nl/assets/uploads/2025/02/Notitie-Stelselcriteria-v0.91-werkdocument.pdf Stelselcriteria v0.91]
|-
| style="vertical-align:top; text-align:left" | 2.1.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De vigerende versies van zibs conform het stelselbesluit worden toegepast. 
Uitzondering:
* Onder voorwaarden mag een pre-adopt zib 2024 toegepast worden.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/releases/fhir-besluit-2022/ FHIR-besluit 2022] 
 
[[pa:Ontwerpkaders_Gebruik_zibs_2024|Ontwerpkaders Gebruik pre-adopts zibs 2024]]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.3]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Een informatiestandaard maakt geen aanpassingen aan elementen van de zib.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.4]]
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.5]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | De gebruikte informatiemodellen mogen EHDS-compatibiliteit niet hinderen.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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'' 
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.3.1]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Een informatiestandaard voegt geen elementen toe aan een zib.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.3.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | De [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset#Transactiedataset kardinaliteit] in een informatiestandaard is niet ruimer dan de kardinaliteit van elementen of relaties in een zib.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.4.1]]
| style="vertical-align:top; text-align:left" | MAY
| style="vertical-align:top; text-align:left" | Voor het produceren van uitwisselberichten of het verwerken van informatie kan een informatiestandaard de kardinaliteit van een zib beperken.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.4.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Voor het ontvangen van berichten past de informatiestandaard geen beperkingen toe op de kardinaliteit van een zib.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

=Systeem=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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 [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=usecases usecases].
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset QA Instructie opstellen dataset v3.0.1]
|-
| style="vertical-align:top; text-align:left" | 3.1.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Een informatiestandaard beschrijft een usecase aan de hand van [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=actoren&op=DISPTERM actoren] (mensen en informatiesystemen) en [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=transactie&op=DISPTERM trasacties] (welke informatie wordt wanneer vastgelegd en/of uitgewisseld).
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.2.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Een informatiestandaard omvat ook een technische specificatie. Deze technische specificatie is gebaseerd op het functioneel ontwerp.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 3.2.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.2.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Alle verplichtingen en verwachtingen vanuit het functioneel ontwerp zijn uitgewerkt in een profiel of in een tekst in de technische specificatie.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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).''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.3.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaarden gebruiken de generieke uitwisselingsstandaard FHIR voor de technische representatie.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/assets/uploads/2025/02/Notitie-Stelselcriteria-v0.91-werkdocument.pdf Stelselcriteria v0.91]
|-
| style="vertical-align:top; text-align:left" | 3.3.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De vigerende versies van FHIR conform het stelselbesluit worden toegepast. 
Zo niet, dan verloopt de overstap volgens de opgestelde migratieplannen.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/releases/fhir-besluit-2022/ FHIR-besluit 2022]
|-
| style="vertical-align:top; text-align:left" | 3.3.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De generieke profielen in het nl-core-package zijn gebruikt, direct of als basis voor usecase-specifieke profielen.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 3.3.4
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Profielen zijn gebaseerd of zijn compatibel met zib en nl-core.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.5
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Indien een informatiestandaard specifieke profielen, transacties, eigen concepten etc. publiceert, zijn deze afgeleid op de relevante nl-core-profielen.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.6
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaard-specifieke profielen zijn ingericht op het specifieke doel en niet op de generieke uitwisseling.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.7
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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).
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

= Transactie=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 4.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | FHIR wordt zuiver toegepast (met andere woorden: de instance heeft dezelfde betekenis zonder dat het profiel bekend is).
| style="vertical-align:top; text-align:left" | https://hl7.org/fhir/resource.html#profile-tags
|-
| style="vertical-align:top; text-align:left" | 4.1.2
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Custom extensies worden vermeden wanneer FHIR core al een aanpak heeft om het concept te vertegenwoordigen.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 4.1.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Bij het maken van profielen of andere conformance resources worden de FHIR profiling guidelines gevolgd.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.4
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Indien een situatie past binnen een patroon zoals beschreven in de profling guidelines, volgt de FHIR-uitwerking dit patroon.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.5
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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).
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.6
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Beschreven uitwisselpatronen en queries zijn gebaseerd of zijn compatibel met IG's die als als de facto standaard gelden (denk aan IHE MHD, mCode).
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.7
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Profielen en andere conformance resources zijn gevalideerd tegen de FHIR core specificaties met de HL7-validatietooling. Afwijkingen moeten zijn verklaard.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.8
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De voorbeeldmaterialen zijn gevalideerd tegen de profielen. Afwijkingen moeten zijn verklaard.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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'' 
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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==
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|-
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.1.1
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=bronsysteem&op=DISPTERM Bronsystemen] kennen wereldwijd unieke identifiers toe aan nieuwe [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=gegevensobjecten&op=DISPTERM gegevensobjecten].
| style="vertical-align:top; text-align:left" | [https://nictiz.atlassian.net/browse/NICTIZ-34076 NICTIZ-34076 Objectidentificatie alfa-versie]
|-
| style="vertical-align:top; text-align:left" | 1.1.2
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Secundaire systemen persisteren de identifiers van binnenkomende objecten.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 1.1.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Secundaire systemen hanteren bij het uitwisselen van overgenomen objecten de oorspronkelijke identifier die was toegekend door het bronsysteem.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''Principe 1.2''' Data wordt beheerd waar ze ontstaat. ''Rationale: Dit voorkomt dataduplicatie en inconsistenties.''
|-
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.2.1
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=wijzigingen Thesaurus Data voor de Zorg 'wijzigingen']
|-
| style="vertical-align:top; text-align:left" | 1.2.2
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Het bronsysteem behoudt de identifier van een object bij een mutatie; de versie van het object wordt wel vernieuwd.
| style="vertical-align:top; text-align:left" | [https://nictiz.atlassian.net/browse/NICTIZ-34076 NICTIZ-34076 Objectidentificatie alfa-versie]
|-
| style="vertical-align:top; text-align:left" | 1.2.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Het secundaire systeem wijst een nieuwe identifier toe bij aanpassingen op overgenomen gegevens.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 1.2.4
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Een informatiestandaard vereist van systemen dat de datum en tijd van mutatie met volledige datum- en tijdstempels, inclusief tijdzone, worden vastgelegd en uitgewisseld.
| style="vertical-align:top; text-align:left" | " "
|-
|}

=Documenthistorie=
{| class="wikitable" style="table-layout:fixed; width:50%;"
|-
! style="width:8%; vertical-align:top; text-align:left" | Versie
! style="width:8%; vertical-align:top; text-align:left" | Status
! style="width:8%; vertical-align:top; text-align:left" | Datum
! style="width:34%; vertical-align:top; text-align:left" | Wijziging
|-
| style="vertical-align:top; text-align:left" | 0.1.0-alfa.2
| style="vertical-align:top; text-align:left" | draft
| style="vertical-align:top; text-align:left" | 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.

pa:VDraft Toetsingscriteria

2025-11-11T11:14:42Z

Lilian Brouwer: /* Aandachtspunten */

{{underconstruction}}
{{NOINDEX|visible=yes}}
{{DISPLAYTITLE:Toetsingscriteria Productarchitectuur (draft-versie)}}
{| class="wikitable"
|-
! | [https://informatiestandaarden.nictiz.nl/wiki/pa:Hoofdproces Hoofdpagina Productarchitectuur] | [https://informatiestandaarden.nictiz.nl/wiki/pa:Productarchitectuurprincipes Productarchitectuurprincipes] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingskader Toetsingskader] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingscriteria Toetsingscriteria]
|}
=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:1
** 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 logische modellen (nu worden ze soms als logisch en andere keren alleen als conceptueel model beschouwd)
** Zibs hebben kardinaliteiten op logisch niveau (nu hebben zibs [https://zibs.nl/wiki/Zib_kardinaliteiten 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 (door)ontwikkelen 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 informatiestandaard2
** Verantwoordelijk voor een impactanalyse3 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 nieuwe versie van de informatiestandaard
** → vereist flexibel releasebeleid voor zibs
** Nictiz werkt aan plan voor flexibel publiceren van zibs4
* 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 [[#Logisch|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 opgeleverd4
** Dit is een praktische uitwerking van de reeds opgeleverde architectuurprincipes zibs 2.0
 
1 [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0];
2 [https://www.nen.nl/nen-7522-2021-nl-283706 NEN 7522:2021 Ontwikkelen en beheren van standaarden en stelsels van standaarden];
3 [https://nictiz.nl/app/uploads/2023/10/Duurzaam-Releasebeleid-versie-1.0.0_oktober2023.pdf Duurzaam Releasebeleid v1.0.0 par. 3.2.1];
4 [https://nictiz.nl/app/uploads/2025/07/Plan-van-Aanpak-zib-transitie_Verder-met-zibs-in-databeschikbaarheid_v1.1.pdf Plan van aanpak: Verder met zibs in databeschikbaarheid v1.1]

=Taal=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|1.1.1]]
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden] 
 
[https://zibs.nl/wiki/Codelist_Bindings_Backup Bindings van zibs] 
[https://nictiz.atlassian.net/browse/ZIB-2685| ZIB-2685] 
[https://nictiz.atlassian.net/issues/ZIBFHIR-249| ZIBFHIR-249]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|1.1.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Informatiestandaarden voegen geen waardelijsten toe naast de in de zib gespecificeerde waardelijsten.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden]
|-
| style="vertical-align:top; text-align:left" | 1.1.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden]
|-
| style="vertical-align:top; text-align:left" | 1.1.4
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://nictiz.nl/app/uploads/2024/10/Dynamische-waardelijsten_oktober2024.pdf?_gl=1*g821zl*_up*MQ..*_ga*MTkwNzg4MTcwMS4xNzQ0NzA3NjQ1*_ga_0ZRXV90GXH*MTc0NDcwNzY0NS4xLjEuMTc0NDcwNzY0OS4wLjAuMjA0Mzk0MzMyNA.. Advies Dynamische waardelijsten]
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''Principe 1.2''' Producten voldoen aan besluiten over de te gebruiken terminologiestelsels. ''Rationale: Gebruik van hetzelfde terminologiestelsel voor dezelfde doeleinden zorgt voor [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=eenheid+van+taal eenheid van taal].''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.2.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://www.nictiz.nl/overig/van-eenduidige-informatie-uitwisseling-tot-hulpmiddel-voor-betere-zorg/ Visie Eenheid van Taal]
|-
| style="vertical-align:top; text-align:left" | 1.2.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Diagnoses, problemen, behandelingen en verrichtingen worden gecodeerd met SNOMED. 
Zo niet, dan verloopt de overstap volgens de opgestelde SNOMED-roadmap.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/bibliotheek/snomed-besluit/ SNOMED-besluit 2024]
|-
| style="vertical-align:top; text-align:left" | 1.2.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Terminologiekoppelingen in de dataset van een informatiestandaard zijn conform de Richtlijn Terminologie koppelen.
| style="vertical-align:top; text-align:left" | [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn Terminologie koppelen v1.0]
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 2.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaarden gebruiken zibs als generieke standaard voor de logische modellen. 
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset QA Instructie opstellen dataset v3.0.1] 
[https://nationalebibliotheek.nictiz.nl/assets/uploads/2025/02/Notitie-Stelselcriteria-v0.91-werkdocument.pdf Stelselcriteria v0.91]
|-
| style="vertical-align:top; text-align:left" | 2.1.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De vigerende versies van zibs conform het stelselbesluit worden toegepast. 
Uitzondering:
* Onder voorwaarden mag een pre-adopt zib 2024 toegepast worden.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/releases/fhir-besluit-2022/ FHIR-besluit 2022] 
 
[[pa:Ontwerpkaders_Gebruik_zibs_2024|Ontwerpkaders Gebruik pre-adopts zibs 2024]]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.3]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Een informatiestandaard maakt geen aanpassingen aan elementen van de zib.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.4]]
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.5]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | De gebruikte informatiemodellen mogen EHDS-compatibiliteit niet hinderen.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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'' 
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.3.1]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Een informatiestandaard voegt geen elementen toe aan een zib.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.3.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | De [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset#Transactiedataset kardinaliteit] in een informatiestandaard is niet ruimer dan de kardinaliteit van elementen of relaties in een zib.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.4.1]]
| style="vertical-align:top; text-align:left" | MAY
| style="vertical-align:top; text-align:left" | Voor het produceren van uitwisselberichten of het verwerken van informatie kan een informatiestandaard de kardinaliteit van een zib beperken.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.4.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Voor het ontvangen van berichten past de informatiestandaard geen beperkingen toe op de kardinaliteit van een zib.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

=Systeem=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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 [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=usecases usecases].
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset QA Instructie opstellen dataset v3.0.1]
|-
| style="vertical-align:top; text-align:left" | 3.1.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Een informatiestandaard beschrijft een usecase aan de hand van [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=actoren&op=DISPTERM actoren] (mensen en informatiesystemen) en [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=transactie&op=DISPTERM trasacties] (welke informatie wordt wanneer vastgelegd en/of uitgewisseld).
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.2.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Een informatiestandaard omvat ook een technische specificatie. Deze technische specificatie is gebaseerd op het functioneel ontwerp.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 3.2.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.2.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Alle verplichtingen en verwachtingen vanuit het functioneel ontwerp zijn uitgewerkt in een profiel of in een tekst in de technische specificatie.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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).''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.3.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaarden gebruiken de generieke uitwisselingsstandaard FHIR voor de technische representatie.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/assets/uploads/2025/02/Notitie-Stelselcriteria-v0.91-werkdocument.pdf Stelselcriteria v0.91]
|-
| style="vertical-align:top; text-align:left" | 3.3.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De vigerende versies van FHIR conform het stelselbesluit worden toegepast. 
Zo niet, dan verloopt de overstap volgens de opgestelde migratieplannen.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/releases/fhir-besluit-2022/ FHIR-besluit 2022]
|-
| style="vertical-align:top; text-align:left" | 3.3.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De generieke profielen in het nl-core-package zijn gebruikt, direct of als basis voor usecase-specifieke profielen.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 3.3.4
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Profielen zijn gebaseerd of zijn compatibel met zib en nl-core.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.5
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Indien een informatiestandaard specifieke profielen, transacties, eigen concepten etc. publiceert, zijn deze afgeleid op de relevante nl-core-profielen.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.6
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaard-specifieke profielen zijn ingericht op het specifieke doel en niet op de generieke uitwisseling.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.7
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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).
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

= Transactie=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 4.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | FHIR wordt zuiver toegepast (met andere woorden: de instance heeft dezelfde betekenis zonder dat het profiel bekend is).
| style="vertical-align:top; text-align:left" | https://hl7.org/fhir/resource.html#profile-tags
|-
| style="vertical-align:top; text-align:left" | 4.1.2
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Custom extensies worden vermeden wanneer FHIR core al een aanpak heeft om het concept te vertegenwoordigen.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 4.1.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Bij het maken van profielen of andere conformance resources worden de FHIR profiling guidelines gevolgd.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.4
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Indien een situatie past binnen een patroon zoals beschreven in de profling guidelines, volgt de FHIR-uitwerking dit patroon.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.5
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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).
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.6
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Beschreven uitwisselpatronen en queries zijn gebaseerd of zijn compatibel met IG's die als als de facto standaard gelden (denk aan IHE MHD, mCode).
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.7
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Profielen en andere conformance resources zijn gevalideerd tegen de FHIR core specificaties met de HL7-validatietooling. Afwijkingen moeten zijn verklaard.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.8
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De voorbeeldmaterialen zijn gevalideerd tegen de profielen. Afwijkingen moeten zijn verklaard.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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'' 
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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==
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|-
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.1.1
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=bronsysteem&op=DISPTERM Bronsystemen] kennen wereldwijd unieke identifiers toe aan nieuwe [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=gegevensobjecten&op=DISPTERM gegevensobjecten].
| style="vertical-align:top; text-align:left" | [https://nictiz.atlassian.net/browse/NICTIZ-34076 NICTIZ-34076 Objectidentificatie alfa-versie]
|-
| style="vertical-align:top; text-align:left" | 1.1.2
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Secundaire systemen persisteren de identifiers van binnenkomende objecten.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 1.1.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Secundaire systemen hanteren bij het uitwisselen van overgenomen objecten de oorspronkelijke identifier die was toegekend door het bronsysteem.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''Principe 1.2''' Data wordt beheerd waar ze ontstaat. ''Rationale: Dit voorkomt dataduplicatie en inconsistenties.''
|-
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.2.1
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=wijzigingen Thesaurus Data voor de Zorg 'wijzigingen']
|-
| style="vertical-align:top; text-align:left" | 1.2.2
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Het bronsysteem behoudt de identifier van een object bij een mutatie; de versie van het object wordt wel vernieuwd.
| style="vertical-align:top; text-align:left" | [https://nictiz.atlassian.net/browse/NICTIZ-34076 NICTIZ-34076 Objectidentificatie alfa-versie]
|-
| style="vertical-align:top; text-align:left" | 1.2.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Het secundaire systeem wijst een nieuwe identifier toe bij aanpassingen op overgenomen gegevens.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 1.2.4
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Een informatiestandaard vereist van systemen dat de datum en tijd van mutatie met volledige datum- en tijdstempels, inclusief tijdzone, worden vastgelegd en uitgewisseld.
| style="vertical-align:top; text-align:left" | " "
|-
|}

=Documenthistorie=
{| class="wikitable" style="table-layout:fixed; width:50%;"
|-
! style="width:8%; vertical-align:top; text-align:left" | Versie
! style="width:8%; vertical-align:top; text-align:left" | Status
! style="width:8%; vertical-align:top; text-align:left" | Datum
! style="width:34%; vertical-align:top; text-align:left" | Wijziging
|-
| style="vertical-align:top; text-align:left" | 0.1.0-alfa.2
| style="vertical-align:top; text-align:left" | draft
| style="vertical-align:top; text-align:left" | 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.

pa:VDraft Toetsingscriteria

2025-11-11T11:13:07Z

Lilian Brouwer: /* Aandachtspunten */

{{underconstruction}}
{{NOINDEX|visible=yes}}
{{DISPLAYTITLE:Toetsingscriteria Productarchitectuur (draft-versie)}}
{| class="wikitable"
|-
! | [https://informatiestandaarden.nictiz.nl/wiki/pa:Hoofdproces Hoofdpagina Productarchitectuur] | [https://informatiestandaarden.nictiz.nl/wiki/pa:Productarchitectuurprincipes Productarchitectuurprincipes] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingskader Toetsingskader] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingscriteria Toetsingscriteria]
|}
=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:1
** 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 logische modellen (nu worden ze soms als logisch en andere keren alleen als conceptueel model beschouwd)
** Zibs hebben kardinaliteiten op logisch niveau (nu hebben zibs [https://zibs.nl/wiki/Zib_kardinaliteiten 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 (door)ontwikkelen 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 informatiestandaard2
** Verantwoordelijk voor een impactanalyse3 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 zibs4
* 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 [[#Logisch|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 opgeleverd4
** Dit is een praktische uitwerking van de reeds opgeleverde architectuurprincipes zibs 2.0
 
1 [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0];
2 [https://www.nen.nl/nen-7522-2021-nl-283706 NEN 7522:2021 Ontwikkelen en beheren van standaarden en stelsels van standaarden];
3 [https://nictiz.nl/app/uploads/2023/10/Duurzaam-Releasebeleid-versie-1.0.0_oktober2023.pdf Duurzaam Releasebeleid v1.0.0 par. 3.2.1];
4 [https://nictiz.nl/app/uploads/2025/07/Plan-van-Aanpak-zib-transitie_Verder-met-zibs-in-databeschikbaarheid_v1.1.pdf Plan van aanpak: Verder met zibs in databeschikbaarheid v1.1]

=Taal=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|1.1.1]]
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden] 
 
[https://zibs.nl/wiki/Codelist_Bindings_Backup Bindings van zibs] 
[https://nictiz.atlassian.net/browse/ZIB-2685| ZIB-2685] 
[https://nictiz.atlassian.net/issues/ZIBFHIR-249| ZIBFHIR-249]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|1.1.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Informatiestandaarden voegen geen waardelijsten toe naast de in de zib gespecificeerde waardelijsten.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden]
|-
| style="vertical-align:top; text-align:left" | 1.1.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://richtlijnen.zibtransitie.nl/terminologie/waardelijst-in-informatiestandaard/ Waardelijsten in informatiestandaarden]
|-
| style="vertical-align:top; text-align:left" | 1.1.4
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://nictiz.nl/app/uploads/2024/10/Dynamische-waardelijsten_oktober2024.pdf?_gl=1*g821zl*_up*MQ..*_ga*MTkwNzg4MTcwMS4xNzQ0NzA3NjQ1*_ga_0ZRXV90GXH*MTc0NDcwNzY0NS4xLjEuMTc0NDcwNzY0OS4wLjAuMjA0Mzk0MzMyNA.. Advies Dynamische waardelijsten]
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''Principe 1.2''' Producten voldoen aan besluiten over de te gebruiken terminologiestelsels. ''Rationale: Gebruik van hetzelfde terminologiestelsel voor dezelfde doeleinden zorgt voor [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=eenheid+van+taal eenheid van taal].''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.2.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://www.nictiz.nl/overig/van-eenduidige-informatie-uitwisseling-tot-hulpmiddel-voor-betere-zorg/ Visie Eenheid van Taal]
|-
| style="vertical-align:top; text-align:left" | 1.2.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Diagnoses, problemen, behandelingen en verrichtingen worden gecodeerd met SNOMED. 
Zo niet, dan verloopt de overstap volgens de opgestelde SNOMED-roadmap.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/bibliotheek/snomed-besluit/ SNOMED-besluit 2024]
|-
| style="vertical-align:top; text-align:left" | 1.2.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Terminologiekoppelingen in de dataset van een informatiestandaard zijn conform de Richtlijn Terminologie koppelen.
| style="vertical-align:top; text-align:left" | [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn Terminologie koppelen v1.0]
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 2.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaarden gebruiken zibs als generieke standaard voor de logische modellen. 
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset QA Instructie opstellen dataset v3.0.1] 
[https://nationalebibliotheek.nictiz.nl/assets/uploads/2025/02/Notitie-Stelselcriteria-v0.91-werkdocument.pdf Stelselcriteria v0.91]
|-
| style="vertical-align:top; text-align:left" | 2.1.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De vigerende versies van zibs conform het stelselbesluit worden toegepast. 
Uitzondering:
* Onder voorwaarden mag een pre-adopt zib 2024 toegepast worden.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/releases/fhir-besluit-2022/ FHIR-besluit 2022] 
 
[[pa:Ontwerpkaders_Gebruik_zibs_2024|Ontwerpkaders Gebruik pre-adopts zibs 2024]]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.3]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Een informatiestandaard maakt geen aanpassingen aan elementen van de zib.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.4]]
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.1.5]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | De gebruikte informatiemodellen mogen EHDS-compatibiliteit niet hinderen.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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'' 
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.3.1]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Een informatiestandaard voegt geen elementen toe aan een zib.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.3.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | De [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset#Transactiedataset kardinaliteit] in een informatiestandaard is niet ruimer dan de kardinaliteit van elementen of relaties in een zib.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.4.1]]
| style="vertical-align:top; text-align:left" | MAY
| style="vertical-align:top; text-align:left" | Voor het produceren van uitwisselberichten of het verwerken van informatie kan een informatiestandaard de kardinaliteit van een zib beperken.
| style="vertical-align:top; text-align:left" | [https://engage.cloud.microsoft/main/org/nictiz.nl/threads/eyJfdHlwZSI6IlRocmVhZCIsImlkIjoiMzU1MDUwNjM2MzY5OTIwMCJ9?trk_copy_link=V2 Intern document Architectuurprincipes zibs 2.0 v1.0]
|-
| style="vertical-align:top; text-align:left" | [[#Aandachtspunten|2.4.2]]
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Voor het ontvangen van berichten past de informatiestandaard geen beperkingen toe op de kardinaliteit van een zib.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

=Systeem=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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 [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=usecases usecases].
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/qa:Instructie_opstellen_dataset QA Instructie opstellen dataset v3.0.1]
|-
| style="vertical-align:top; text-align:left" | 3.1.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Een informatiestandaard beschrijft een usecase aan de hand van [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=actoren&op=DISPTERM actoren] (mensen en informatiesystemen) en [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=transactie&op=DISPTERM trasacties] (welke informatie wordt wanneer vastgelegd en/of uitgewisseld).
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.2.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Een informatiestandaard omvat ook een technische specificatie. Deze technische specificatie is gebaseerd op het functioneel ontwerp.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 3.2.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.2.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Alle verplichtingen en verwachtingen vanuit het functioneel ontwerp zijn uitgewerkt in een profiel of in een tekst in de technische specificatie.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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).''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 3.3.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaarden gebruiken de generieke uitwisselingsstandaard FHIR voor de technische representatie.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/assets/uploads/2025/02/Notitie-Stelselcriteria-v0.91-werkdocument.pdf Stelselcriteria v0.91]
|-
| style="vertical-align:top; text-align:left" | 3.3.2
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De vigerende versies van FHIR conform het stelselbesluit worden toegepast. 
Zo niet, dan verloopt de overstap volgens de opgestelde migratieplannen.
| style="vertical-align:top; text-align:left" | [https://nationalebibliotheek.nictiz.nl/releases/fhir-besluit-2022/ FHIR-besluit 2022]
|-
| style="vertical-align:top; text-align:left" | 3.3.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De generieke profielen in het nl-core-package zijn gebruikt, direct of als basis voor usecase-specifieke profielen.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 3.3.4
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Profielen zijn gebaseerd of zijn compatibel met zib en nl-core.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.5
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Indien een informatiestandaard specifieke profielen, transacties, eigen concepten etc. publiceert, zijn deze afgeleid op de relevante nl-core-profielen.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.6
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Informatiestandaard-specifieke profielen zijn ingericht op het specifieke doel en niet op de generieke uitwisseling.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 3.3.7
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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).
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

= Transactie=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 4.1.1
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | FHIR wordt zuiver toegepast (met andere woorden: de instance heeft dezelfde betekenis zonder dat het profiel bekend is).
| style="vertical-align:top; text-align:left" | https://hl7.org/fhir/resource.html#profile-tags
|-
| style="vertical-align:top; text-align:left" | 4.1.2
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Custom extensies worden vermeden wanneer FHIR core al een aanpak heeft om het concept te vertegenwoordigen.
| style="vertical-align:top; text-align:left" | [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4 Nictiz FHIR Profiling Guidelines R4] 
[https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_STU3 Nictiz FHIR Profiling Guidelines STU3]
|-
| style="vertical-align:top; text-align:left" | 4.1.3
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Bij het maken van profielen of andere conformance resources worden de FHIR profiling guidelines gevolgd.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.4
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Indien een situatie past binnen een patroon zoals beschreven in de profling guidelines, volgt de FHIR-uitwerking dit patroon.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.5
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | 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).
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.6
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Beschreven uitwisselpatronen en queries zijn gebaseerd of zijn compatibel met IG's die als als de facto standaard gelden (denk aan IHE MHD, mCode).
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.7
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Profielen en andere conformance resources zijn gevalideerd tegen de FHIR core specificaties met de HL7-validatietooling. Afwijkingen moeten zijn verklaard.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 4.1.8
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | De voorbeeldmaterialen zijn gevalideerd tegen de profielen. Afwijkingen moeten zijn verklaard.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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=
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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'' 
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;"| '''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==
{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''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.''
|-
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.1.1
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=bronsysteem&op=DISPTERM Bronsystemen] kennen wereldwijd unieke identifiers toe aan nieuwe [https://thesauruszorgenwelzijn.multites.net/default.asp?searchString=gegevensobjecten&op=DISPTERM gegevensobjecten].
| style="vertical-align:top; text-align:left" | [https://nictiz.atlassian.net/browse/NICTIZ-34076 NICTIZ-34076 Objectidentificatie alfa-versie]
|-
| style="vertical-align:top; text-align:left" | 1.1.2
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Secundaire systemen persisteren de identifiers van binnenkomende objecten.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 1.1.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Secundaire systemen hanteren bij het uitwisselen van overgenomen objecten de oorspronkelijke identifier die was toegekend door het bronsysteem.
| style="vertical-align:top; text-align:left" | " "
|-
|}
 

{| class="wikitable" style="table-layout:fixed; width:100%;"
|-
| style="vertical-align:top; text-align:left; font-weight:normal; background-color:white;" | '''Principe 1.2''' Data wordt beheerd waar ze ontstaat. ''Rationale: Dit voorkomt dataduplicatie en inconsistenties.''
|-
|}
{| class="wikitable" style="table-layout:fixed; width:100%;"
|+ style="text-align:left;" | Toetsingscriteria
|-
! style="width:4%; vertical-align:top; text-align:left" | Item
! style="width:6%; vertical-align:top; text-align:left" | [[pa:VDraft_Toetsingskader#Niveau van verplichting|Niveau]]
! style="width:67%; vertical-align:top; text-align:left" | Beschrijving
! style="width:23%; vertical-align:top; text-align:left" | Bron
|-
| style="vertical-align:top; text-align:left" | 1.2.1
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | 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.
| style="vertical-align:top; text-align:left" | [https://thesauruszorgenwelzijn.multites.net/default.asp?op=DISPTERM&searchString=wijzigingen Thesaurus Data voor de Zorg 'wijzigingen']
|-
| style="vertical-align:top; text-align:left" | 1.2.2
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Het bronsysteem behoudt de identifier van een object bij een mutatie; de versie van het object wordt wel vernieuwd.
| style="vertical-align:top; text-align:left" | [https://nictiz.atlassian.net/browse/NICTIZ-34076 NICTIZ-34076 Objectidentificatie alfa-versie]
|-
| style="vertical-align:top; text-align:left" | 1.2.3
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Het secundaire systeem wijst een nieuwe identifier toe bij aanpassingen op overgenomen gegevens.
| style="vertical-align:top; text-align:left" | " "
|-
| style="vertical-align:top; text-align:left" | 1.2.4
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Een informatiestandaard vereist van systemen dat de datum en tijd van mutatie met volledige datum- en tijdstempels, inclusief tijdzone, worden vastgelegd en uitgewisseld.
| style="vertical-align:top; text-align:left" | " "
|-
|}

=Documenthistorie=
{| class="wikitable" style="table-layout:fixed; width:50%;"
|-
! style="width:8%; vertical-align:top; text-align:left" | Versie
! style="width:8%; vertical-align:top; text-align:left" | Status
! style="width:8%; vertical-align:top; text-align:left" | Datum
! style="width:34%; vertical-align:top; text-align:left" | Wijziging
|-
| style="vertical-align:top; text-align:left" | 0.1.0-alfa.2
| style="vertical-align:top; text-align:left" | draft
| style="vertical-align:top; text-align:left" | 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.

pa:VDraft Toetsingskader

2025-11-11T09:09:12Z

Lilian Brouwer: /* Toepassing */

{{underconstruction}}
{{NOINDEX|visible=yes}}
{{DISPLAYTITLE:Toetsingskader Productarchitectuur (draft-versie)}}
{| class="wikitable"
|-
! | [https://informatiestandaarden.nictiz.nl/wiki/pa:Hoofdproces Hoofdpagina Productarchitectuur] | [https://informatiestandaarden.nictiz.nl/wiki/pa:Productarchitectuurprincipes Productarchitectuurprincipes] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingskader Toetsingskader] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingscriteria Toetsingscriteria]
|}
=Doel=
De toetsingscriteria dragen bij aan de consistentie en samenhang tussen informatiestandaarden en ondersteunen daarmee de zorgbrede interoperabiliteit. Ze vormen een concrete uitwerking van de overkoepelende productarchitectuurprincipes en bieden kaders voor het ontwerpen van informatiestandaarden.

=Reikwijdte=
De toetsingscriteria zijn van toepassing op:
* het ontwerp van nieuwe informatiestandaarden;
* het beheer en de doorontwikkeling van bestaande informatiestandaarden.
De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz.

=Definitie=
Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur.

De toetsingscriteria specificeren:
* welke generieke standaarden (en welke versies daarvan) moeten worden toegepast;
* welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard.

=Niveau van verplichting=
Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie:
* Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat.
* Aanbevolen: afgeleid van documentatie met een alfa- of bètastatus die nog niet volledig is gevalideerd of beproefd.

De volgende niveaus worden gehanteerd:

{| class="wikitable" style="table-layout:fixed; width:76%;"
|-
! style="width:8%; vertical-align:top; text-align:left" | Niveau
! style="width:34%; vertical-align:top; text-align:left" | Betekenis
! style="width:34%; vertical-align:top; text-align:left" | Afwijking toegestaan?
|-
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Verplicht. Dit criterium moet worden gevolgd. Er is brede consensus over de onderliggende documentatie.
| style="vertical-align:top; text-align:left" | Alleen bij onderbouwing met zeer zwaarwegende argumenten. Er moet een plan zijn hoe op termijn wel kan worden voldaan aan dit criterium.
|-
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Niet toegestaan.
| style="vertical-align:top; text-align:left" | Nee
|-
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Aanbevolen. Sterke voorkeur om te volgen. De onderliggende documentatie heeft nog geen definitieve status.
| style="vertical-align:top; text-align:left" | Ja, mits de afwijking onderbouwd wordt.
|-
| style="vertical-align:top; text-align:left" | SHOULD NOT
| style="vertical-align:top; text-align:left" | Afgeraden.
| style="vertical-align:top; text-align:left" | Nee
|-
| style="vertical-align:top; text-align:left" | MAY
| style="vertical-align:top; text-align:left" | Optioneel. Toepassing is toegestaan, maar niet verplicht.
| style="vertical-align:top; text-align:left" | -
|-
|}

=Toepassing=
De toetsingscriteria vormen het kader voor:
* het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard;
* de toetsing tijdens besluitvorming over acceptatie of wijziging van een informatiestandaard door het Productarchitectuurteam en de Productarchitectuurboard;
* de borging van EHDS-compatibiliteit en interoperabiliteit binnen het stelsel van informatiestandaarden.

=Proces=
De toetsing productarchitectuur is onderdeel van het [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen QA-proces] van Nictiz voor het ontwikkelen van informatiestandaarden. De beheerder van de informatiestandaard is verantwoordelijk voor het tijdig benaderen van het Productarchitectuurteam om de vereiste toetsingen uit te voeren op de momenten die in QA zijn vastgelegd.

==Ingangstoets==
Het toetsingsproces start met een ingangstoets. Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review. De ingangstoets resulteert in een toetsingsrapport op de interne [https://nictiz.atlassian.net/wiki/spaces/POB/pages/340099187/Product+Architectuur?atlOrigin=eyJpIjoiM2YyM2YzMTY4ODQ4NDIzZjk5NzE5NGM4N2FiMjBkOGUiLCJwIjoiYyJ9 Confluence-pagina Productarchitectuur]. Het toetsingsrapport bevat Jira-tickets voor de opvolging van afwijkingen en potentiële afwijkingen.

==Monitoring==
De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de Confluence-pagina Productarchitectuur, met verwijzingen naar de aangemaakte Jira-tickets. Elke informatiestandaard heeft een toegewezen productarchitect die fungeert als eerste aanspreekpunt voor vragen en advies over productarchitectuur. De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen.

==Toets voorafgaand aan publicatie==
Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. Bij onopgeloste afwijkingen geeft de beheerder van de informatiestandaard een onderbouwing volgens het comply or explain-principe. Ook geeft de beheerder aan hoe op termijn alsnog aan het criterium kan worden voldaan. De Productarchitectuurboard beoordeelt op basis van deze onderbouwing of publicatie kan doorgaan.

=Beheer=
De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd.

Afwijkingen van verplichte of aanbevolen criteria worden vastgelegd en periodiek geëvalueerd om te bepalen of aanpassing van de toetsing nodig is. Wijzigingen of aanvullingen worden vastgesteld na consultatie van betrokken stakeholders en gepubliceerd in de meest recente versie van dit document. De toetsingscriteria kennen een hogere wijzigingsfrequentie dan de meer stabiele, overkoepelende productarchitectuurprincipes.

=Documenthistorie=
{| class="wikitable" style="table-layout:fixed; width:50%;"
|-
! style="width:8%; vertical-align:top; text-align:left" | Versie
! style="width:8%; vertical-align:top; text-align:left" | Status
! style="width:8%; vertical-align:top; text-align:left" | Datum
! style="width:34%; vertical-align:top; text-align:left" | Wijziging
|-
| style="vertical-align:top; text-align:left" | 0.1.0-alfa.1
| style="vertical-align:top; text-align:left" | draft
| style="vertical-align:top; text-align:left" | 07-11-2025
|-
|}

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

pa:VDraft Toetsingskader

2025-11-11T09:06:55Z

Lilian Brouwer: /* Niveau van verplichting */

{{underconstruction}}
{{NOINDEX|visible=yes}}
{{DISPLAYTITLE:Toetsingskader Productarchitectuur (draft-versie)}}
{| class="wikitable"
|-
! | [https://informatiestandaarden.nictiz.nl/wiki/pa:Hoofdproces Hoofdpagina Productarchitectuur] | [https://informatiestandaarden.nictiz.nl/wiki/pa:Productarchitectuurprincipes Productarchitectuurprincipes] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingskader Toetsingskader] | [https://informatiestandaarden.nictiz.nl/wiki/pa:VDraft_Toetsingscriteria Toetsingscriteria]
|}
=Doel=
De toetsingscriteria dragen bij aan de consistentie en samenhang tussen informatiestandaarden en ondersteunen daarmee de zorgbrede interoperabiliteit. Ze vormen een concrete uitwerking van de overkoepelende productarchitectuurprincipes en bieden kaders voor het ontwerpen van informatiestandaarden.

=Reikwijdte=
De toetsingscriteria zijn van toepassing op:
* het ontwerp van nieuwe informatiestandaarden;
* het beheer en de doorontwikkeling van bestaande informatiestandaarden.
De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz.

=Definitie=
Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur.

De toetsingscriteria specificeren:
* welke generieke standaarden (en welke versies daarvan) moeten worden toegepast;
* welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard.

=Niveau van verplichting=
Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie:
* Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat.
* Aanbevolen: afgeleid van documentatie met een alfa- of bètastatus die nog niet volledig is gevalideerd of beproefd.

De volgende niveaus worden gehanteerd:

{| class="wikitable" style="table-layout:fixed; width:76%;"
|-
! style="width:8%; vertical-align:top; text-align:left" | Niveau
! style="width:34%; vertical-align:top; text-align:left" | Betekenis
! style="width:34%; vertical-align:top; text-align:left" | Afwijking toegestaan?
|-
| style="vertical-align:top; text-align:left" | MUST
| style="vertical-align:top; text-align:left" | Verplicht. Dit criterium moet worden gevolgd. Er is brede consensus over de onderliggende documentatie.
| style="vertical-align:top; text-align:left" | Alleen bij onderbouwing met zeer zwaarwegende argumenten. Er moet een plan zijn hoe op termijn wel kan worden voldaan aan dit criterium.
|-
| style="vertical-align:top; text-align:left" | MUST NOT
| style="vertical-align:top; text-align:left" | Niet toegestaan.
| style="vertical-align:top; text-align:left" | Nee
|-
| style="vertical-align:top; text-align:left" | SHOULD
| style="vertical-align:top; text-align:left" | Aanbevolen. Sterke voorkeur om te volgen. De onderliggende documentatie heeft nog geen definitieve status.
| style="vertical-align:top; text-align:left" | Ja, mits de afwijking onderbouwd wordt.
|-
| style="vertical-align:top; text-align:left" | SHOULD NOT
| style="vertical-align:top; text-align:left" | Afgeraden.
| style="vertical-align:top; text-align:left" | Nee
|-
| style="vertical-align:top; text-align:left" | MAY
| style="vertical-align:top; text-align:left" | Optioneel. Toepassing is toegestaan, maar niet verplicht.
| style="vertical-align:top; text-align:left" | -
|-
|}

=Toepassing=
De toetsingscriteria vormen het kader voor:
* het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard;
* de toetsing tijdens besluitvorming over acceptatie of wijziging van een informatiestandaard door het Productarchitectuurteam en de Productarchitectuurboard;
* de borging van interoperabiliteit binnen het stelsel van informatiestandaarden, met inbegrip van EHDS-compatibiliteit.

=Proces=
De toetsing productarchitectuur is onderdeel van het [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen QA-proces] van Nictiz voor het ontwikkelen van informatiestandaarden. De beheerder van de informatiestandaard is verantwoordelijk voor het tijdig benaderen van het Productarchitectuurteam om de vereiste toetsingen uit te voeren op de momenten die in QA zijn vastgelegd.

==Ingangstoets==
Het toetsingsproces start met een ingangstoets. Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review. De ingangstoets resulteert in een toetsingsrapport op de interne [https://nictiz.atlassian.net/wiki/spaces/POB/pages/340099187/Product+Architectuur?atlOrigin=eyJpIjoiM2YyM2YzMTY4ODQ4NDIzZjk5NzE5NGM4N2FiMjBkOGUiLCJwIjoiYyJ9 Confluence-pagina Productarchitectuur]. Het toetsingsrapport bevat Jira-tickets voor de opvolging van afwijkingen en potentiële afwijkingen.

==Monitoring==
De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de Confluence-pagina Productarchitectuur, met verwijzingen naar de aangemaakte Jira-tickets. Elke informatiestandaard heeft een toegewezen productarchitect die fungeert als eerste aanspreekpunt voor vragen en advies over productarchitectuur. De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen.

==Toets voorafgaand aan publicatie==
Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. Bij onopgeloste afwijkingen geeft de beheerder van de informatiestandaard een onderbouwing volgens het comply or explain-principe. Ook geeft de beheerder aan hoe op termijn alsnog aan het criterium kan worden voldaan. De Productarchitectuurboard beoordeelt op basis van deze onderbouwing of publicatie kan doorgaan.

=Beheer=
De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd.

Afwijkingen van verplichte of aanbevolen criteria worden vastgelegd en periodiek geëvalueerd om te bepalen of aanpassing van de toetsing nodig is. Wijzigingen of aanvullingen worden vastgesteld na consultatie van betrokken stakeholders en gepubliceerd in de meest recente versie van dit document. De toetsingscriteria kennen een hogere wijzigingsfrequentie dan de meer stabiele, overkoepelende productarchitectuurprincipes.

=Documenthistorie=
{| class="wikitable" style="table-layout:fixed; width:50%;"
|-
! style="width:8%; vertical-align:top; text-align:left" | Versie
! style="width:8%; vertical-align:top; text-align:left" | Status
! style="width:8%; vertical-align:top; text-align:left" | Datum
! style="width:34%; vertical-align:top; text-align:left" | Wijziging
|-
| style="vertical-align:top; text-align:left" | 0.1.0-alfa.1
| style="vertical-align:top; text-align:left" | draft
| style="vertical-align:top; text-align:left" | 07-11-2025
|-
|}

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

QA Template TEST-KWA Standaardteksten Sjabloon

2025-11-03T15:22:12Z

Lilian Brouwer: /* Interoplab */

{{DISPLAYTITLE:Standaardteksten Nictiz test- en kwalificatiescripts}}
__NUMBEREDHEADINGS__

<noinclude>
{{NoteBox|
'''Gebruik deze pagina NIET: de tekst voor kopieren staat op de hoofdpagina van het sjabloon.'''
Deze subpagina bevat de centraal beheerde standaardteksten voor Nictiz test- en kwalificatiescripts.
Het is met dezelfde structuur opgezet, zodat het makkelijk te beheren is. Als er hier geen tekst staat onder een kopje, staat er tekst die in het toegepaste sjabloon aangepast moet worden, zie de brontekst van het sjabloon.
}}
</noinclude>

= TEST Inleiding =
== TEST Algemene informatie ==
== TEST Doelgroep ==
== TEST Voorwaarden voor testen ==
Voor het uitvoeren van dit testscript gelden de algemene voorwaarden voor test/kwalificaties bij Nictiz. Specifiek de onderstaande voorwaarden:
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie et cetera.
# Kennis, begrip, en het naleven van de aandachtspunten zoals beschreven in dit document.
# De testdocumentatie bevat de gegevens die de testende partij zelf invoert.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker.

== TEST Begrippenlijst ==
Nictiz maakt gebruik van bepaalde afkortingen en termen. Meer informatie kan gevonden worden in [https://nictiz.nl/standaarden/begrippen/ deze algemene begrippenlijst]. Daarnaast is er een [https://thesauruszorgenwelzijn.multites.net/ thesaurus] waarin begrippen kunnen worden opgezocht.

= TEST Test-informatie =
Nictiz biedt leveranciers de mogelijkheid hun producten en diensten te testen op correcte implementatie van informatiestandaarden ter voorbereiding op de kwalificatie.
Bij het uitvoeren van deze testen is het niet nodig om schermafbeeldingen te maken. Daarnaast maakt het testen van infrastructurele eisen geen onderdeel uit van dit script.
== TEST Testaanpak ==
Houd tijdens het testen de bevindingen bij van de uitgevoerde tests. Analyseer de bevindingen, corrigeer fouten waar nodig en test opnieuw.
==TEST Tools voor testen==
===ART-DECOR===
Voor meer informatie over het testen met de simulator vanuit ART-DECOR: [https://decor.nictiz.nl/wiki/index.php/Testen_met_ART-DECOR Testen met ART-DECOR].
===InteropLab===
Voor meer informatie over het testen van FHIR-materialen met de Interoplab simulator, zie [https://interoplab.atlassian.net/wiki/spaces/SUP/overview hier]. Toegang moet worden aangevraagd bij Interoplab om gebruik te kunnen maken van de simulators van Nictiz.

= TEST Testscript =
== TEST Uit te voeren stappen ==
== TEST Overzicht testscenario's ==

= TEST Aandachtspunten voor inhoudelijke gegevens =
== TEST Persoonsgegevens ==
Er is een fictief BSN (fBSN) voor testdoeleinden in de persoonsgegevens opgenomen. Dit is alleen bedoeld voor gebruik in het XIS (registratie van de testpersoon).
== Variabele T-datum ==
De T datum is altijd de maandag van de week waarin je de tests van dit script uitvoert. Als ergens staat T-100 betekent dit dus: 100 dagen eerder dan de huidige maandag.

= TEST Inhoudelijke gegevens =

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

= KWA Kwalificatie-informatie =
== KWA Algemeen ==
== KWA Doelgroep ==
== KWA Voorwaarden voor kwalificatie ==
Voor het uitvoeren van dit kwalificatiescript gelden de algemene voorwaarden voor kwalificaties bij Nictiz. Specifiek de onderstaande voorwaarden:
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie et cetera.
# Kennis, begrip, en het naleven van de aandachtspunten zoals beschreven in dit document.
# De kwalificatiedocumentatie bevat de gegevens die de kwalificerende partij zelf invoert. Het is van belang dat de gegevens juist ingevoerd worden. '''''Onjuist ingevoerde gegevens''''' (ook tijd/datum et cetera) leiden tot vertraging en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op voor controle.

== KWA Begrippenlijst ==
Nictiz maakt gebruik van bepaalde afkortingen en termen. Meer informatie kan gevonden worden in [https://nictiz.nl/standaarden/begrippen/ deze algemene begrippenlijst]. Daarnaast is er een [https://thesauruszorgenwelzijn.multites.net/ thesaurus] waarin begrippen kunnen worden opgezocht.

= KWA Kwalificatie-informatie =
Nictiz biedt leveranciers de mogelijkheid hun producten en diensten te testen op correcte implementatie van informatiestandaarden.
Kwalificatie vindt plaats per systeemrol.

== KWA Aanpak van kwalificatie ==
Houd tijdens de kwalificatie de bevindingen bij van de uitgevoerde tests. Analyseer de bevindingen, corrigeer fouten waar nodig en test opnieuw.

== KWA Op te leveren kwalificatiemateriaal ==
De op te leveren materialen bestaan uit:
# de technische uitgaande berichten (voor alle scenario’s)
# schermafdrukken (voor de aangegeven scenario's).

Indien een schermafdruk opgeleverd moet worden, staat in het scenario aangegeven wat er op het schermafdruk zichtbaar moet zijn (staat er niks genoemd, dan is er geen schermafdruk nodig).

== KWA Tools voor kwalificatie==
===ART-DECOR===
Voor meer informatie over kwalificatie met de simulator vanuit ART-DECOR: [https://decor.nictiz.nl/wiki/index.php/Testen_met_ART-DECOR Testen met ART-DECOR].
===InteropLab===
Voor meer informatie over het testen van FHIR-materialen met de Interoplab simulator, zie [https://interoplab.atlassian.net/wiki/spaces/SUP/overview hier]. Toegang moet worden aangevraagd bij Interoplab om gebruik te kunnen maken van de simulators van Nictiz.

= KWA Kwalificatiescript =
== KWA Uit te voeren stappen ==
== KWA Overzicht kwalificatiescenario's ==
= KWA Aandachtspunten voor inhoudelijke gegevens =
== KWA Persoonsgegevens ==
Er is een fictief BSN (fBSN) voor testdoeleinden in de persoonsgegevens opgenomen. Dit is alleen bedoeld voor gebruik in het XIS (registratie van de testpersoon).

== KWA Variabele T datum ==
De T datum is altijd de maandag van de week waarin je de tests van dit script uitvoert. Als ergens staat T-100 betekent dit dus: 100 dagen eerder dan de huidige maandag.

= KWA Inhoudelijke gegevens =
==Titel Scenario==

__NOINDEX__

QA Template TEST-KWA Standaardteksten Sjabloon

2025-11-03T15:18:41Z

Lilian Brouwer:

{{DISPLAYTITLE:Standaardteksten Nictiz test- en kwalificatiescripts}}
__NUMBEREDHEADINGS__

<noinclude>
{{NoteBox|
'''Gebruik deze pagina NIET: de tekst voor kopieren staat op de hoofdpagina van het sjabloon.'''
Deze subpagina bevat de centraal beheerde standaardteksten voor Nictiz test- en kwalificatiescripts.
Het is met dezelfde structuur opgezet, zodat het makkelijk te beheren is. Als er hier geen tekst staat onder een kopje, staat er tekst die in het toegepaste sjabloon aangepast moet worden, zie de brontekst van het sjabloon.
}}
</noinclude>

= TEST Inleiding =
== TEST Algemene informatie ==
== TEST Doelgroep ==
== TEST Voorwaarden voor testen ==
Voor het uitvoeren van dit testscript gelden de algemene voorwaarden voor test/kwalificaties bij Nictiz. Specifiek de onderstaande voorwaarden:
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie et cetera.
# Kennis, begrip, en het naleven van de aandachtspunten zoals beschreven in dit document.
# De testdocumentatie bevat de gegevens die de testende partij zelf invoert.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker.

== TEST Begrippenlijst ==
Nictiz maakt gebruik van bepaalde afkortingen en termen. Meer informatie kan gevonden worden in [https://nictiz.nl/standaarden/begrippen/ deze algemene begrippenlijst]. Daarnaast is er een [https://thesauruszorgenwelzijn.multites.net/ thesaurus] waarin begrippen kunnen worden opgezocht.

= TEST Test-informatie =
Nictiz biedt leveranciers de mogelijkheid hun producten en diensten te testen op correcte implementatie van informatiestandaarden ter voorbereiding op de kwalificatie.
Bij het uitvoeren van deze testen is het niet nodig om schermafbeeldingen te maken. Daarnaast maakt het testen van infrastructurele eisen geen onderdeel uit van dit script.
== TEST Testaanpak ==
Houd tijdens het testen de bevindingen bij van de uitgevoerde tests. Analyseer de bevindingen, corrigeer fouten waar nodig en test opnieuw.
==TEST Tools voor testen==
===ART-DECOR===
Voor meer informatie over het testen met de simulator vanuit ART-DECOR: [https://decor.nictiz.nl/wiki/index.php/Testen_met_ART-DECOR Testen met ART-DECOR].
===InteropLab===
Voor meer informatie over het testen van FHIR-materialen met de Interoplab simulator, zie [https://interoplab.atlassian.net/wiki/spaces/SUP/overview hier]. Toegang moet worden aangevraagd bij Interoplab om gebruik te kunnen maken van de simulators van Nictiz.

= TEST Testscript =
== TEST Uit te voeren stappen ==
== TEST Overzicht testscenario's ==

= TEST Aandachtspunten voor inhoudelijke gegevens =
== TEST Persoonsgegevens ==
Er is een fictief BSN (fBSN) voor testdoeleinden in de persoonsgegevens opgenomen. Dit is alleen bedoeld voor gebruik in het XIS (registratie van de testpersoon).
== Variabele T-datum ==
De T datum is altijd de maandag van de week waarin je de tests van dit script uitvoert. Als ergens staat T-100 betekent dit dus: 100 dagen eerder dan de huidige maandag.

= TEST Inhoudelijke gegevens =

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

= KWA Kwalificatie-informatie =
== KWA Algemeen ==
== KWA Doelgroep ==
== KWA Voorwaarden voor kwalificatie ==
Voor het uitvoeren van dit kwalificatiescript gelden de algemene voorwaarden voor kwalificaties bij Nictiz. Specifiek de onderstaande voorwaarden:
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie et cetera.
# Kennis, begrip, en het naleven van de aandachtspunten zoals beschreven in dit document.
# De kwalificatiedocumentatie bevat de gegevens die de kwalificerende partij zelf invoert. Het is van belang dat de gegevens juist ingevoerd worden. '''''Onjuist ingevoerde gegevens''''' (ook tijd/datum et cetera) leiden tot vertraging en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op voor controle.

== KWA Begrippenlijst ==
Nictiz maakt gebruik van bepaalde afkortingen en termen. Meer informatie kan gevonden worden in [https://nictiz.nl/standaarden/begrippen/ deze algemene begrippenlijst]. Daarnaast is er een [https://thesauruszorgenwelzijn.multites.net/ thesaurus] waarin begrippen kunnen worden opgezocht.

= KWA Kwalificatie-informatie =
Nictiz biedt leveranciers de mogelijkheid hun producten en diensten te testen op correcte implementatie van informatiestandaarden.
Kwalificatie vindt plaats per systeemrol.

== KWA Aanpak van kwalificatie ==
Houd tijdens de kwalificatie de bevindingen bij van de uitgevoerde tests. Analyseer de bevindingen, corrigeer fouten waar nodig en test opnieuw.

== KWA Op te leveren kwalificatiemateriaal ==
De op te leveren materialen bestaan uit:
# de technische uitgaande berichten (voor alle scenario’s)
# schermafdrukken (voor de aangegeven scenario's).

Indien een schermafdruk opgeleverd moet worden, staat in het scenario aangegeven wat er op het schermafdruk zichtbaar moet zijn (staat er niks genoemd, dan is er geen schermafdruk nodig).

== KWA Tools voor kwalificatie==
===ART-DECOR===
Voor meer informatie over kwalificatie met de simulator vanuit ART-DECOR: [https://decor.nictiz.nl/wiki/index.php/Testen_met_ART-DECOR Testen met ART-DECOR].
===Touchstone===

= KWA Kwalificatiescript =
== KWA Uit te voeren stappen ==
== KWA Overzicht kwalificatiescenario's ==
= KWA Aandachtspunten voor inhoudelijke gegevens =
== KWA Persoonsgegevens ==
Er is een fictief BSN (fBSN) voor testdoeleinden in de persoonsgegevens opgenomen. Dit is alleen bedoeld voor gebruik in het XIS (registratie van de testpersoon).

== KWA Variabele T datum ==
De T datum is altijd de maandag van de week waarin je de tests van dit script uitvoert. Als ergens staat T-100 betekent dit dus: 100 dagen eerder dan de huidige maandag.

= KWA Inhoudelijke gegevens =
==Titel Scenario==

__NOINDEX__

pa:Transactiebouwstenen

2025-09-18T13:48:48Z

Lilian Brouwer: /* Kaders voor toepassing van een bestaande transactiebouwsteen */

__NUMBEREDHEADINGS__
{{IssueBox|Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.}}

== (Transactie)bouwstenen ==

=== Doelstelling van transactiebouwstenen ===
* Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
* Verhogen van hergebruik van (setjes) bouwstenen
* Verhogen implementeerbaarheid van (setjes) bouwstenen
* Faciliteren incrementeel ontwikkelen en testen
* Verhogen databeschikbaarheid

=== Bibliotheek van transactiebouwstenen ===
Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

[[Bestand:PAT_BuildingBlocksLibrary.png|Bibliotheek Transactiebouwstenen|600px]]

=== Definitie van een transactiebouwsteen ===
Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

[[Bestand:PAT_BuildingBlockContent.png|Transactiebouwsteen|600px]]

=== Inhoud van een transactiebouwsteen ===

==== Granulariteit ====
Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuurboard.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk. Deze keuzes moeten duidelijk vindbaar gedocumenteerd worden, zodat deze ook breed toegepast worden.

==== Onderdelen ====
Een transactiebouwsteen bestaat uit de volgende onderdelen:
* Logisch model
* Relaties met andere bouwstenen
* Zoekparameters
* Obligations
* Technische mapping
* Voorbeelden

===== Logisch model =====
De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:
# Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
# Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de ''international patient summary'', IHE MHD, eu-core, us-core, etc.
# Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
# Model beproeven in minimaal 3 verschillende domeinen met elk minimaal 1 usecase.

===== Relaties met andere bouwstenen =====
Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

===== Zoekparameters =====
De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

===== Obligations =====
Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het [https://hl7.org/fhir/obligations.html Obligations Framework] van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren ''producer'' en ''consumer'' uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de [http://hl7.org/fhir/extensions/ValueSet-obligation.html Obligation Codes-waardelijst], bv:
; user-input: de mogelijkheid voor gebruikers om iets in te voeren
; populate: de eis om een waarde in te vullen indien aanwezig
; display: de eis om een waarde weer te geven
; persist: de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

===== Technische mapping =====
Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

===== Voorbeelden =====
De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):
* 3 realistische voorbeelden (1 per use case)
* minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (direct via XSLT of -als het niet anders kan- handmatig) vertaald naar FHIR.

=== Kaders voor toepassing van een bestaande transactiebouwsteen ===
Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle niet verplichte elementen te gebruiken, maar mogen er geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij de functioneel beheerder van deze bouwsteen. Hiervoor zal een beheerproces ingericht worden.

==== Usecases ====
Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:
* Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
* Een usecase zal conformeren aan de beperkingen (constraints) en verplichtigingen (obligations) gedefinieerd in een bouwsteen (SHALL)
* Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
* Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
* Een usecase mag striktere beperkingen (constraints) en verplichtingen (obligations) definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is

[[Bestand:PAT_UseCaseContent.png|Use case content|600px]]

pa:Transactiebouwstenen

2025-09-18T13:39:47Z

Lilian Brouwer: /* Logisch model */

__NUMBEREDHEADINGS__
{{IssueBox|Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.}}

== (Transactie)bouwstenen ==

=== Doelstelling van transactiebouwstenen ===
* Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
* Verhogen van hergebruik van (setjes) bouwstenen
* Verhogen implementeerbaarheid van (setjes) bouwstenen
* Faciliteren incrementeel ontwikkelen en testen
* Verhogen databeschikbaarheid

=== Bibliotheek van transactiebouwstenen ===
Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

[[Bestand:PAT_BuildingBlocksLibrary.png|Bibliotheek Transactiebouwstenen|600px]]

=== Definitie van een transactiebouwsteen ===
Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

[[Bestand:PAT_BuildingBlockContent.png|Transactiebouwsteen|600px]]

=== Inhoud van een transactiebouwsteen ===

==== Granulariteit ====
Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuurboard.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk. Deze keuzes moeten duidelijk vindbaar gedocumenteerd worden, zodat deze ook breed toegepast worden.

==== Onderdelen ====
Een transactiebouwsteen bestaat uit de volgende onderdelen:
* Logisch model
* Relaties met andere bouwstenen
* Zoekparameters
* Obligations
* Technische mapping
* Voorbeelden

===== Logisch model =====
De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:
# Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
# Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de ''international patient summary'', IHE MHD, eu-core, us-core, etc.
# Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
# Model beproeven in minimaal 3 verschillende domeinen met elk minimaal 1 usecase.

===== Relaties met andere bouwstenen =====
Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

===== Zoekparameters =====
De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

===== Obligations =====
Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het [https://hl7.org/fhir/obligations.html Obligations Framework] van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren ''producer'' en ''consumer'' uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de [http://hl7.org/fhir/extensions/ValueSet-obligation.html Obligation Codes-waardelijst], bv:
; user-input: de mogelijkheid voor gebruikers om iets in te voeren
; populate: de eis om een waarde in te vullen indien aanwezig
; display: de eis om een waarde weer te geven
; persist: de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

===== Technische mapping =====
Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

===== Voorbeelden =====
De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):
* 3 realistische voorbeelden (1 per use case)
* minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (direct via XSLT of -als het niet anders kan- handmatig) vertaald naar FHIR.

=== Kaders voor toepassing van een bestaande transactiebouwsteen ===
Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle elementen te gebruiken (mits er vanuit de bouwsteen geen verplichting op zit), maar mogen geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij de functioneel beheerder van deze bouwsteen. Hiervoor zal een beheerproces ingericht worden.

==== Usecases ====
Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:
* Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
* Een usecase zal conformeren aan de constraints en obligations gedefinieerd in een bouwsteen (SHALL)
* Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
* Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
* Een usecase mag striktere constraints en obligations definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is

[[Bestand:PAT_UseCaseContent.png|Use case content|600px]]

pa:Transactiebouwstenen

2025-09-18T12:37:14Z

Lilian Brouwer: /* Kaders voor toepassing van een bestaande transactiebouwsteen */

__NUMBEREDHEADINGS__
{{IssueBox|Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.}}

== (Transactie)bouwstenen ==

=== Doelstelling van transactiebouwstenen ===
* Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
* Verhogen van hergebruik van (setjes) bouwstenen
* Verhogen implementeerbaarheid van (setjes) bouwstenen
* Faciliteren incrementeel ontwikkelen en testen
* Verhogen databeschikbaarheid

=== Bibliotheek van transactiebouwstenen ===
Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

[[Bestand:PAT_BuildingBlocksLibrary.png|Bibliotheek Transactiebouwstenen|600px]]

=== Definitie van een transactiebouwsteen ===
Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

[[Bestand:PAT_BuildingBlockContent.png|Transactiebouwsteen|600px]]

=== Inhoud van een transactiebouwsteen ===

==== Granulariteit ====
Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuurboard.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk. Deze keuzes moeten duidelijk vindbaar gedocumenteerd worden, zodat deze ook breed toegepast worden.

==== Onderdelen ====
Een transactiebouwsteen bestaat uit de volgende onderdelen:
* Logisch model
* Relaties met andere bouwstenen
* Zoekparameters
* Obligations
* Technische mapping
* Voorbeelden

===== Logisch model =====
De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:
# Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
# Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de ''international patient summary'', IHE MHD, eu-core, us-core, etc.
# Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
# Model beproeven in minimaal 3 usecases uit verschillende domeinen.

===== Relaties met andere bouwstenen =====
Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

===== Zoekparameters =====
De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

===== Obligations =====
Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het [https://hl7.org/fhir/obligations.html Obligations Framework] van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren ''producer'' en ''consumer'' uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de [http://hl7.org/fhir/extensions/ValueSet-obligation.html Obligation Codes-waardelijst], bv:
; user-input: de mogelijkheid voor gebruikers om iets in te voeren
; populate: de eis om een waarde in te vullen indien aanwezig
; display: de eis om een waarde weer te geven
; persist: de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

===== Technische mapping =====
Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

===== Voorbeelden =====
De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):
* 3 realistische voorbeelden (1 per use case)
* minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (direct via XSLT of -als het niet anders kan- handmatig) vertaald naar FHIR.

=== Kaders voor toepassing van een bestaande transactiebouwsteen ===
Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle elementen te gebruiken (mits er vanuit de bouwsteen geen verplichting op zit), maar mogen geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij de functioneel beheerder van deze bouwsteen. Hiervoor zal een beheerproces ingericht worden.

==== Usecases ====
Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:
* Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
* Een usecase zal conformeren aan de constraints en obligations gedefinieerd in een bouwsteen (SHALL)
* Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
* Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
* Een usecase mag striktere constraints en obligations definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is

[[Bestand:PAT_UseCaseContent.png|Use case content|600px]]

pa:Transactiebouwstenen

2025-09-18T12:35:23Z

Lilian Brouwer: /* Voorbeelden */

__NUMBEREDHEADINGS__
{{IssueBox|Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.}}

== (Transactie)bouwstenen ==

=== Doelstelling van transactiebouwstenen ===
* Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
* Verhogen van hergebruik van (setjes) bouwstenen
* Verhogen implementeerbaarheid van (setjes) bouwstenen
* Faciliteren incrementeel ontwikkelen en testen
* Verhogen databeschikbaarheid

=== Bibliotheek van transactiebouwstenen ===
Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

[[Bestand:PAT_BuildingBlocksLibrary.png|Bibliotheek Transactiebouwstenen|600px]]

=== Definitie van een transactiebouwsteen ===
Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

[[Bestand:PAT_BuildingBlockContent.png|Transactiebouwsteen|600px]]

=== Inhoud van een transactiebouwsteen ===

==== Granulariteit ====
Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuurboard.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk. Deze keuzes moeten duidelijk vindbaar gedocumenteerd worden, zodat deze ook breed toegepast worden.

==== Onderdelen ====
Een transactiebouwsteen bestaat uit de volgende onderdelen:
* Logisch model
* Relaties met andere bouwstenen
* Zoekparameters
* Obligations
* Technische mapping
* Voorbeelden

===== Logisch model =====
De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:
# Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
# Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de ''international patient summary'', IHE MHD, eu-core, us-core, etc.
# Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
# Model beproeven in minimaal 3 usecases uit verschillende domeinen.

===== Relaties met andere bouwstenen =====
Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

===== Zoekparameters =====
De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

===== Obligations =====
Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het [https://hl7.org/fhir/obligations.html Obligations Framework] van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren ''producer'' en ''consumer'' uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de [http://hl7.org/fhir/extensions/ValueSet-obligation.html Obligation Codes-waardelijst], bv:
; user-input: de mogelijkheid voor gebruikers om iets in te voeren
; populate: de eis om een waarde in te vullen indien aanwezig
; display: de eis om een waarde weer te geven
; persist: de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

===== Technische mapping =====
Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

===== Voorbeelden =====
De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):
* 3 realistische voorbeelden (1 per use case)
* minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (direct via XSLT of -als het niet anders kan- handmatig) vertaald naar FHIR.

=== Kaders voor toepassing van een bestaande transactiebouwsteen ===
Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle elementen te gebruiken (mits er vanuit de bouwsteen geen verplichting op zit), maar mogen geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij het team dat deze bouwsteen beheeft. Hiervoor zal een beheerproces ingericht worden.

==== Usecases ====
Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:
* Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
* Een usecase zal conformeren aan de constraints en obligations gedefinieerd in een bouwsteen (SHALL)
* Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
* Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
* Een usecase mag striktere constraints en obligations definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is

[[Bestand:PAT_UseCaseContent.png|Use case content|600px]]

pa:Transactiebouwstenen

2025-09-18T12:32:04Z

Lilian Brouwer: /* Logisch model */

__NUMBEREDHEADINGS__
{{IssueBox|Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.}}

== (Transactie)bouwstenen ==

=== Doelstelling van transactiebouwstenen ===
* Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
* Verhogen van hergebruik van (setjes) bouwstenen
* Verhogen implementeerbaarheid van (setjes) bouwstenen
* Faciliteren incrementeel ontwikkelen en testen
* Verhogen databeschikbaarheid

=== Bibliotheek van transactiebouwstenen ===
Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

[[Bestand:PAT_BuildingBlocksLibrary.png|Bibliotheek Transactiebouwstenen|600px]]

=== Definitie van een transactiebouwsteen ===
Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

[[Bestand:PAT_BuildingBlockContent.png|Transactiebouwsteen|600px]]

=== Inhoud van een transactiebouwsteen ===

==== Granulariteit ====
Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuurboard.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk. Deze keuzes moeten duidelijk vindbaar gedocumenteerd worden, zodat deze ook breed toegepast worden.

==== Onderdelen ====
Een transactiebouwsteen bestaat uit de volgende onderdelen:
* Logisch model
* Relaties met andere bouwstenen
* Zoekparameters
* Obligations
* Technische mapping
* Voorbeelden

===== Logisch model =====
De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:
# Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
# Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de ''international patient summary'', IHE MHD, eu-core, us-core, etc.
# Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
# Model beproeven in minimaal 3 usecases uit verschillende domeinen.

===== Relaties met andere bouwstenen =====
Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

===== Zoekparameters =====
De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

===== Obligations =====
Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het [https://hl7.org/fhir/obligations.html Obligations Framework] van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren ''producer'' en ''consumer'' uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de [http://hl7.org/fhir/extensions/ValueSet-obligation.html Obligation Codes-waardelijst], bv:
; user-input: de mogelijkheid voor gebruikers om iets in te voeren
; populate: de eis om een waarde in te vullen indien aanwezig
; display: de eis om een waarde weer te geven
; persist: de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

===== Technische mapping =====
Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

===== Voorbeelden =====
De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):
* 3 realistische voorbeelden (1 per use case)
* minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (handmatig of - bij voorkeur - direct via XSLT) vertaald naar FHIR.

=== Kaders voor toepassing van een bestaande transactiebouwsteen ===
Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle elementen te gebruiken (mits er vanuit de bouwsteen geen verplichting op zit), maar mogen geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij het team dat deze bouwsteen beheeft. Hiervoor zal een beheerproces ingericht worden.

==== Usecases ====
Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:
* Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
* Een usecase zal conformeren aan de constraints en obligations gedefinieerd in een bouwsteen (SHALL)
* Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
* Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
* Een usecase mag striktere constraints en obligations definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is

[[Bestand:PAT_UseCaseContent.png|Use case content|600px]]

pa:Transactiebouwstenen

2025-09-18T12:28:10Z

Lilian Brouwer: /* Granulariteit */

__NUMBEREDHEADINGS__
{{IssueBox|Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.}}

== (Transactie)bouwstenen ==

=== Doelstelling van transactiebouwstenen ===
* Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
* Verhogen van hergebruik van (setjes) bouwstenen
* Verhogen implementeerbaarheid van (setjes) bouwstenen
* Faciliteren incrementeel ontwikkelen en testen
* Verhogen databeschikbaarheid

=== Bibliotheek van transactiebouwstenen ===
Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

[[Bestand:PAT_BuildingBlocksLibrary.png|Bibliotheek Transactiebouwstenen|600px]]

=== Definitie van een transactiebouwsteen ===
Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

[[Bestand:PAT_BuildingBlockContent.png|Transactiebouwsteen|600px]]

=== Inhoud van een transactiebouwsteen ===

==== Granulariteit ====
Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuurboard.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk. Deze keuzes moeten duidelijk vindbaar gedocumenteerd worden, zodat deze ook breed toegepast worden.

==== Onderdelen ====
Een transactiebouwsteen bestaat uit de volgende onderdelen:
* Logisch model
* Relaties met andere bouwstenen
* Zoekparameters
* Obligations
* Technische mapping
* Voorbeelden

===== Logisch model =====
De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:
# Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
# Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de ''international patient summary'', IHE MHD, eu-core, us-core, etc.
# Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
#. Model beproeven in minimaal 3 usecases uit verschillende domeinen.

===== Relaties met andere bouwstenen =====
Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

===== Zoekparameters =====
De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

===== Obligations =====
Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het [https://hl7.org/fhir/obligations.html Obligations Framework] van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren ''producer'' en ''consumer'' uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de [http://hl7.org/fhir/extensions/ValueSet-obligation.html Obligation Codes-waardelijst], bv:
; user-input: de mogelijkheid voor gebruikers om iets in te voeren
; populate: de eis om een waarde in te vullen indien aanwezig
; display: de eis om een waarde weer te geven
; persist: de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

===== Technische mapping =====
Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

===== Voorbeelden =====
De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):
* 3 realistische voorbeelden (1 per use case)
* minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (handmatig of - bij voorkeur - direct via XSLT) vertaald naar FHIR.

=== Kaders voor toepassing van een bestaande transactiebouwsteen ===
Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle elementen te gebruiken (mits er vanuit de bouwsteen geen verplichting op zit), maar mogen geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij het team dat deze bouwsteen beheeft. Hiervoor zal een beheerproces ingericht worden.

==== Usecases ====
Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:
* Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
* Een usecase zal conformeren aan de constraints en obligations gedefinieerd in een bouwsteen (SHALL)
* Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
* Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
* Een usecase mag striktere constraints en obligations definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is

[[Bestand:PAT_UseCaseContent.png|Use case content|600px]]

pa:Transactiebouwstenen

2025-09-18T12:24:42Z

Lilian Brouwer: /* Logisch model */

__NUMBEREDHEADINGS__
{{IssueBox|Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.}}

== (Transactie)bouwstenen ==

=== Doelstelling van transactiebouwstenen ===
* Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
* Verhogen van hergebruik van (setjes) bouwstenen
* Verhogen implementeerbaarheid van (setjes) bouwstenen
* Faciliteren incrementeel ontwikkelen en testen
* Verhogen databeschikbaarheid

=== Bibliotheek van transactiebouwstenen ===
Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

[[Bestand:PAT_BuildingBlocksLibrary.png|Bibliotheek Transactiebouwstenen|600px]]

=== Definitie van een transactiebouwsteen ===
Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

[[Bestand:PAT_BuildingBlockContent.png|Transactiebouwsteen|600px]]

=== Inhoud van een transactiebouwsteen ===

==== Granulariteit ====
Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuur.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk.

==== Onderdelen ====
Een transactiebouwsteen bestaat uit de volgende onderdelen:
* Logisch model
* Relaties met andere bouwstenen
* Zoekparameters
* Obligations
* Technische mapping
* Voorbeelden

===== Logisch model =====
De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:
# Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
# Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de ''international patient summary'', IHE MHD, eu-core, us-core, etc.
# Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
#. Model beproeven in minimaal 3 usecases uit verschillende domeinen.

===== Relaties met andere bouwstenen =====
Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

===== Zoekparameters =====
De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

===== Obligations =====
Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het [https://hl7.org/fhir/obligations.html Obligations Framework] van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren ''producer'' en ''consumer'' uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de [http://hl7.org/fhir/extensions/ValueSet-obligation.html Obligation Codes-waardelijst], bv:
; user-input: de mogelijkheid voor gebruikers om iets in te voeren
; populate: de eis om een waarde in te vullen indien aanwezig
; display: de eis om een waarde weer te geven
; persist: de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

===== Technische mapping =====
Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

===== Voorbeelden =====
De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):
* 3 realistische voorbeelden (1 per use case)
* minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (handmatig of - bij voorkeur - direct via XSLT) vertaald naar FHIR.

=== Kaders voor toepassing van een bestaande transactiebouwsteen ===
Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle elementen te gebruiken (mits er vanuit de bouwsteen geen verplichting op zit), maar mogen geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij het team dat deze bouwsteen beheeft. Hiervoor zal een beheerproces ingericht worden.

==== Usecases ====
Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:
* Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
* Een usecase zal conformeren aan de constraints en obligations gedefinieerd in een bouwsteen (SHALL)
* Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
* Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
* Een usecase mag striktere constraints en obligations definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is

[[Bestand:PAT_UseCaseContent.png|Use case content|600px]]

qa:Instructie opstellen dataset

2025-09-15T10:55:14Z

Lilian Brouwer: /* Inleiding */

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Instructie opstellen dataset 3.0.1 {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__

==Inleiding==
Dit document beschrijft de ‘best practices’ bij het opstellen van een dataset, behorende bij een informatiestandaard. Deze ‘best practices voor Nictiz datasets’ is de richtlijn voor iedereen die zich bezighoudt met het opstellen en beheren van datasets. Door op een eenduidige wijze deze datasets samen te stellen, wordt de uitwisselbaarheid in (delen van) datasets verbeterd en wordt het voor beheerders van datasets ook eenvoudiger om datasets die zijn opgesteld door collega’s, inzichtelijk te krijgen. Hiermee wordt ook getracht om de mapping van met name de datascenario’s op de HL7 berichten (HL7v3 templates en FHIR-profielen) te vereenvoudigen.
Daarnaast is de uniformiteit in de samenstelling van datasets van groot belang voor externe partijen – met name zorginstellingen en hun ICT-leveranciers die met behulp van de datasets en datascenario's de gegevensuitwisselingen conform de Nictiz informatiestandaarden moeten implementeren.
Voor de leesbaarheid en de juiste context van begrippen zijn een aantal relevante definities hieronder ingevoegd. Deze komen vanuit de
[https://nictiz.nl/standaarden/begrippen/ Nictiz begrippenlijst] of zijn er aan toegevoegd (met de intentie om deze alsnog op te nemen in de begrippenlijst):

{| class="wikitable"
! Begrip
! Definitie
|-
| Richtlijn
| Beschrijving die verduidelijkt wat behoort te worden gedaan en hoe, om de doelstellingen te bereiken die in het beleid zijn vastgelegd (NEN 7510)
|-
| Functioneel ontwerp
| In een Nictiz functioneel ontwerp worden alle eisen en wensen voor alle usecases (ook wel uitwisselscenario’s genoemd) binnen één informatiestandaard verzameld en geordend. Per usecase wordt beschreven op welke manier dat gebeurt: tussen welke gebruikers vindt de gegevensuitwisseling plaats, welke handelingen worden daarbij uitgevoerd en welke resultaten leveren deze op.
|-
| Usecase
| Een beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het vastleggen en/of uitwisselen van
|-
|
| informatie wordt beschreven aan de hand van actoren (mensen, informatiesystemen) en transacties (welke informatie wordt wanneer uitgewisseld).
|-
| Dataset
| Een dataset bevat definities van alle gegevens die binnen de context van een specifiek zorgproces en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Deze definities zijn functioneel van aard en worden vastgesteld door het zorgveld. Voor specifieke transacties binnen het zorgproces wordt gebruik gemaakt van een subset van de gegevens uit deze dataset (het datascenario).
|-
| Zib
| Zorginformatiebouwstenen (zibs) worden gebruikt om inhoudelijke (niet technische) afspraken vast te leggen ten behoeve van het standaardiseren van informatie, die gebruikt wordt in het zorgproces. Het doel van de standaardisatie is dat deze informatie uit het zorgproces wordt hergebruikt voor andere doeleinden, zoals kwaliteitsregistraties, overdracht, patiëntgebonden onderzoek. Een zorginformatiebouwsteen is een informatiemodel, waarin een zorginhoudelijk concept wordt beschreven in termen van de gegevenselementen waaruit dat concept bestaat, de datatypes van die gegevenselementen etc.
|-
| Informatiebouwsteen
| Een concrete voorziening, standaard, afspraak of arrangement, met een eigenaar, beheerder, financiering et cetera die bovensectoraal of zorgbreed (her)gebruikt kan worden. Informatiebouwstenen kunnen zijn (opgebouwd uit) zibs en/of opgebouwd uit gegevenselementen.
|-
| Dataelement / gegeven
| Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
|-
| Scenario
| De representatie van een usecase in ART DECOR waarin de actoren en een specifieke subset gegevens uit de dataset (transactiedataset) zijn uitgewerkt.
|-
| Transactiegroep
| Een model van een verzameling van gegevens die wordt overgedragen tussen actoren (personen of systeemrollen) binnen één usecase. Een transactie wordt schematisch weergegeven door de uitwisseling van een transactiedataset tussen twee actoren.
|-
| Transactiedataset
| Een subset van gegevens uit de dataset voor een specifieke transactie met kardinaliteiten en conformiteiten.
|-
| Intensionele waardelijst en expressie
| Zie 2.3.2

Een intentionele waardelijst geeft niet direct aan welke directe waarden je moet hebben, maar alleen een intentie geeft voor elke waarde erin in thuishoort. Dit doe je door een intentionele expressie (dat in feite een query is), zoals :

< T : alle waarden onder T

of

<< T : T en alle waarden daaronder

of

< T1

OR

< T2 : alle waarden onder T1 of T2
N.B. Daarnaast kun je waardes in de intentionele expressie ook excluderen
|}

===Doelstelling===
Het eerste doel van dit document is het bevorderen van inzicht in hoe een dataset wordt samengesteld. De richtlijnen en methoden voor het samenstellen van een dataset worden in dit document nader toegelicht.
Het tweede doel van dit document is het bevorderen van inzicht in hoe een datascenario wordt samengesteld vanuit een dataset. De richtlijnen en methoden voor het samenstellen van een datascenario worden in dit document nader toegelicht.

===Scope van dit document===
Dit document geeft definities van een dataset, zib, informatiebouwsteen, data-element en een datascenario. Ook wordt uitgelegd hoe een dataset en een datascenario op een eenduidige wijze moet worden samengesteld. De verschillende methoden die hiervoor gebruikt worden, zijn nader beschreven.
Dit document kan als een richtlijn worden beschouwd voor wijze waarop binnen Nictiz datasets en datascenario’s worden samengesteld. Ook voor beheer van reeds bestaande datasets en datascenario’s is deze richtlijn van toepassing.

===Buiten scope van dit document===
Een dataset bevat definities van alle gegevens die in een specifieke context binnen het zorgproces, en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Voor elke usecase moeten door betrokken partijen afspraken gemaakt worden over de inhoud van de te gebruiken gegevens – het datascenario. De definities die van toepassing zijn in het zorgproces zijn functioneel van aard en worden vastgesteld door de zorgverleners in een functioneel ontwerp en daarmee buiten de scope van dit document.
Eveneens buiten scope is een uitleg van de tooling waarmee datasets worden samengesteld en gepresenteerd. Hiervoor wordt verwezen naar ART DECOR [https://decor.nictiz.nl/wiki/index.php/Ontwikkelaars#Proces_ontwikkelen_DECOR-project, https://simplifier.net/, Zibs 2017: https://simplifier.net/NictizSTU3-Zib2017, http://www.art-decor.org]. Echter, vanwege praktische redenen worden in dit document afbeeldingen gebruikt van (delen van) datasets en datascenario’s in ART DECOR om beschrijvingen nader toe te lichten.
Dit document is gericht aan inhoudelijke experts op het gebied van Nictiz informatiestandaarden (informatieanalisten, product managers, Specialisten gegevensuitwisseling, etc.) waarvan wordt verondersteld dat men bekend is met de gebruikte terminologieën, tooling, documentatie, etc.. Deze worden daarom niet verder toegelicht en beschreven in dit document.

==Samenstellen datasets==

===Richtlijnen voor het samenstellen van datasets===
Voor het opstellen van een dataset gelden een aantal basisprincipes. In het kort komt dit neer op de volgende punten:
*Zoveel mogelijk gebruik maken van de meest recent gepubliceerde zibs
*Indien geen zibs beschikbaar, bekijk reeds bestaande datasets, CIMS en/of kandidaat-zibs op de aanwezigheid van informatiebouwstenen die toegepast kunnen worden in de nieuwe dataset
*Conformeer zoveel mogelijk aan het zorgproces, de informatiestandaard (op basis van richtlijnen en functioneel ontwerp) maar ook aan de gegevensmodellen van de zibs en informatiebouwstenen
*Voeg alleen dataelementen en (waarden in) waardelijsten toe als deze niet worden gerepresenteerd door reeds beschikbare dataelementen en (waarden in) waardelijsten in zibs en/of informatiebouwstenen
*Conformeer zo veel mogelijk aan de generieke volgorde van zibs en informatiebouwstenen in een dataset
*Zorg voor het gebruik van correcte en up-to-date terminologie(koppelingen). Betrek hiervoor in een zo vroeg mogelijk stadium het Terminologiecentrum.
In dit best practice document wordt in de subhoofdstukken hierna voor elk van deze punten beschreven wat dit betekent voor de daadwerkelijke samenstelling van een dataset.

'''2.1.1 Meest recent gepubliceerde zibs'''

Over het nut en noodzaak van zibs is reeds de nodige literatuur [https://zibs.nl/wiki/Hoofdpagina beschikbaar]. Door voortschrijdend inzicht en met inbreng van vele stakeholders worden zibs middels een strikt nageleefd beheerproces aangepast. Bij het samenstellen van een nieuwe dataset is het dan ook van groot belang om de meest recent gepubliceerde zibs te gebruiken.
In ART-DECOR zijn alle zibs van de meest recente publicatie beschikbaar en kunnen worden gebruikt als informatiebouwsteen om een dataset mee samen te stellen. Door zoveel mogelijk gebruik te maken van de zib concepten, kan informatie in alle afzonderlijke zorgtoepassingen op dezelfde manier worden vastgelegd (tussen de zender en ontvanger) en blijft de betekenis gelijk.
Zibs zijn concepten die zorgbreed kunnen worden toegepast. Het kan daarom voorkomen dat in specifieke gegevensoverdrachten in een bepaald domein een aanvulling op dit concept nodig is. Bijvoorbeeld extra dataelementen of waardelijsten die niet in de zibs zijn opgenomen. Ook kan het voorkomen dat binnen een dataset slechts een deel van de zib wordt gebruikt. Elementen van een zib kunnen daarom ook worden verwijderd, zolang dit het conceptuele model van de zib niet compromitteert.

'''2.1.2 Informatiebouwstenen'''

Naast zibs kunnen ook informatiebouwstenen worden gebruikt bij het samenstellen van een dataset. Informatiebouwstenen kunnen zibs zijn met een aantal toevoegingen of verwijderingen van dataelementen en/of waardelijsten, detailed clinical models (DCM’s) die geen zibs zijn of nog kandidaat-zibs zijn (zie ook ‘Zorginformatiebouwstenen – Richtlijnen bij afwezigheid van zib’s’) of een zelf opgebouwde informatiebouwsteen. Vaak zijn deze informatiebouwstenen voor één of hooguit enkele zorgdomeinen van toepassing, in tegenstelling tot zibs die zorgbreed toegepast kunnen worden.
Bekijk daarom ook functioneel ontwerpen en informatiebouwstenen in datasets van andere informatiestandaarden om te bepalen of er, al dan niet gedeeltelijke, overlap is met betrekking tot de inhoud van de gegevensuitwisseling. Door hergebruik van informatiebouwstenen worden ook gegevensuitwisselingen die niet met zibs kunnen worden gemodelleerd, zoveel mogelijk gestandaardiseerd.

[[File:Opstellen_dataset_paragraaf2.1.png|576×254px]]

Hoe een zib in een bepaalde zorgsituatie (usecase) wordt gebruikt is vastgelegd in een informatiestandaard. Een informatiestandaard voegt context en relaties toe aan de zib gegevensmodellen en beschrijft in welke zorgsituatie je welke gegevens vastlegt en uitwisselt [zie ook https://www.nictiz.nl/standaardisatie/informatiestandaarden/].

'''2.1.3 Zorgproces, informatiestandaard en gegevensmodellering'''

Vanzelfsprekend zijn het zorgproces en kwaliteitstandaarden/richtlijnen de leidraad voor wat er in de dataset moet worden toegevoegd aan zibs, informatiebouwstenen en/of dataelementen en waardelijsten. Vaak wordt er bij het samenstellen van de dataset en meer nog het datascenario (zie het hoofdstuk Samenstellen datascenario) ruggespraak gehouden met experts uit het zorgveld. Deze dataexperts kunnen waardevol inzicht verschaffen bij het ‘fijnslijpen’ en completeren van een dataset en de datascenario’s. Hierbij dient er wel scherp op gelet te worden dat de dataset samenstelling er is voor interoperabiliteit en niet voor het modelleren van systemen.

'''2.1.4 Toevoegen dataelementen en waardelijsten'''

In een dataset kunnen ook ‘losse’ dataelementen en specifieke waardelijsten worden toegevoegd. Meestal worden deze dataelementen en/of waardelijsten toegevoegd aan onterfde zibs en/of informatiebouwstenen om deze op maat te maken voor een specifieke informatiestandaard, zie ook Methoden voor samenstellen datasets bij subhoofdstuk 2.2.5 Invoegen en verwijderen dataelementen en waarden in waardelijsten. In een enkel geval kunnen dataelementen ook rechtstreeks in een dataset worden ingevoegd.
Er moet goed worden overwogen welke gevolgen dit heeft voor de datascenario’s en onderliggende HL7-berichten. Ook moet er scherp op gelet worden dat eventuele toevoegingen van dataelementen en (waarden in) waardelijsten complementair zijn aan de reeds beschikbare gegevens in de zibs en niet als vervanging voor terminologie.

'''2.1.5 Volgordelijkheid (zorg)informatiebouwstenen en dataelementen in dataset'''

Naast dat datasets de verzameling zijn van alle gegevens in alle datascenario’s, zijn datasets ook bedoeld om een overzicht te bieden aan Nictiz collega’s en externe dataexperts. Door een zoveel mogelijk gestandaardiseerde volgorde van zibs en informatiebouwstenen aan te houden in een dataset, wordt er een beter overzicht gecreëerd. Ook is het mogelijk om bepaalde segmenten toe te passen, zoals een groep ‘bundel’ of ‘bouwstenen’ waarbinnen de (zorg)informatiebouwstenen zijn ondergebracht waarnaar wordt verwezen vanuit andere delen van de dataset.
Een strak gereguleerde volgordelijkheid van informatiebouwstenen in alle informatiestandaard-datasets is lastig te realiseren. Het voornaamste is dat Nictiz collega’s en externe partijen op een zo eenvoudig en intuïtief mogelijke wijze de samenstelling van een dataset goed kunnen overzien.
Hieronder is een voorbeeld als leidraad voor een volgordelijkheid van zibs en informatiebouwstenen in een dataset:
*Patiënt
*Zorgverlener
*Zorgaanbieder
*Contactmomenten
*Zibs en informatiebouwstenen m.b.t. triage, diagnose
*Zibs en informatiebouwstenen m.b.t. behandeling en verrichting
*Zibs en informatiebouwstenen m.b.t. uitslagen en verslaglegging
*Zibs en informatiebouwstenen voor specifieke onderwerpen in een usecase
Echter, het is mogelijk dat deze volgordelijkheid in bestaande en nieuwe datasets in ART DECOR niet is toegepast. Vooral de wat oudere datasets zijn hierin soms afwijkend. En regelmatig zijn er in datasets de eerder genoemde segmenten gebruikt waarbij zibs en informatiebouwstenen in een groep zijn samengevoegd, zoals “Demografie en identificatie” met zibs Patiënt, Contactgegevens en BurgerlijkeStaat of “Sociale Anamnese” met zibs Woonsituatie, Taalvaardigheid, ParticipatieInMaatschappij en HulpVanAnderen.

===Methoden voor samenstellen datasets===
Datasets kunnen met verschillende methoden worden samengesteld:
*Erven (zibs en informatiebouwstenen)
*Onterven (na eerst te hebben geërfd)
*Verwijzen
*Relaties maken tussen informatiebouwstenen
*Invoegen en verwijderen dataelementen en (waarden in) waardelijsten
In dit best practice document wordt elk van deze methoden beschreven, alsook een uitleg over welke methode te gebruiken in bepaalde situaties.

'''2.2.1 Erven'''

Binnen ART-DECOR kan een zib of een informatiebouwsteen uit een andere dataset in de eigen dataset worden geërfd. Erven houdt in dat alle gegevenselementen van een zib of informatiebouwsteen, inclusief de onderlinge samenhang (structuur), worden gekopieerd en toegevoegd in de nieuwe dataset.

'''2.2.2 Onterven'''

Een geërfde zib of (zelf ontwikkelde) informatiebouwsteen dient in veel gevallen nog te worden aangepast. Er kunnen gegevenselementen aan worden toegevoegd of juist verwijderd (hoofdstuk 2.2.5). Ook kunnen er relaties worden toegevoegd, zoals wordt beschreven in hoofdstuk 2.2.4 – Relaties binnen datasets. Om dit te kunnen doen, dient een overerfde zib of informatiebouwsteen te worden onterfd, alvorens wijzigingen te kunnen doorvoeren.
Op deze manier ontstaan nieuwe informatiebouwstenen, welke volledig naar informatiebehoefte zijn gemaakt maar waarbij toch zoveel mogelijk de generieke zibs blijven behouden. Hierbij geldt wel dat alleen optionele elementen uit een zib kunnen worden verwijderd en niet de elementen die de kern van een concept omvatten; alleen dan is een nieuwe bouwsteen compatibel met oorspronkelijke zib.
Om in een dataset meer duiding te geven aan de toepassing van een zib, kan na onterven de naamgeving van een zib worden hernoemd. Als voorbeeld: in de dataset voor de informatiestandaard Geboortezorg wordt de zib Probleem twee keer toegepast maar elk in een andere context. Daarom is de zib Probleem voor de twee contexten hernoemd naar respectievelijk ProbleemKind en ProbleemMoeder. In de referentie van de zib is nog steeds zichtbaar dat voor elk van de twee contexten de zib Probleem de basis is.
Edoch, middels het plaatsen van een zib in een datagroep met een context kan ook duiding worden gegeven aan de specifieke toepassing van een zib in een dataset. Dit is beschreven in paragraaf 2.2.3 Verwijzingen. Uit oogpunt van herkenning van het gebruik van zibs en het gebruik van ADA is de voorkeur om datagroepen met context te gebruiken boven het hernoemen van zibs.

'''2.2.3 Verwijzingen'''

In een dataset kan een verwijzing vanuit een informatiebouwsteen naar een andere informatiebouwsteen of losse gegevenselementen worden gemaakt. Dit wordt gedaan wanneer een generieke informatiebouwsteen – in de meeste gevallen een zib – binnen een dataset meerdere keren op de zelfde wijze wordt gebruikt. Bij een verwijzing worden dus de gegevens van de informatiebouwsteen waar naar verwezen wordt ook opgenomen binnen de informatiebouwsteen van waaruit verwezen wordt. Door de verwijzing te maken in een datagroep met een specifieke context, zijn de gegevens vanuit de verwezen bouwsteen daarmee ook van toepassing op deze context.
Hieronder is een voorbeeld van de zib Labuitslag waarin gegevens over de laboratoriumverantwoordelijke, aanvrager en de uitvoerder zijn opgenomen. Voor drie verschillende contexten wordt steeds de zib Zorgverlener gebruikt; elk dus met een specifieke context. Hieronder de uitwerking van dit voorbeeld in ART DECOR, in blauw omrand:

[[File:Opstellen_dataset_paragraaf2.2.png|576×254px]]

In dit voorbeeld staat de zib Zorgverlener elders in de dataset uitgewerkt. Deze uitwerking is dus van toepassing op de drie contexten waarin deze zib wordt gebruikt.
Verwijzingen tussen informatiebouwstenen en/of losse gegevenselementen worden doorgaans binnen één dataset te worden gemaakt (want je kunt in principe ook verwijzen naar bouwstenen die in een andere dataset staan). Alleen in dat geval is er op de volledige dataset, inclusief de bouwstenen waar naar wordt verwezen, volledig beheer mogelijk.

'''2.2.4 Relaties'''

In een dataset kunnen ook relaties worden gelegd tussen informatiebouwstenen. Het verschil met het maken van een verwijzing is dat bij een relatie vanuit een bouwsteen naar een andere bouwsteen niet de gegevens van die gerelateerde bouwsteen worden opgenomen maar zijn wel te herleiden.
Als bijvoorbeeld gegevens over een medicatieafspraak worden uitgewisseld, dan wil men weten of er een relatie is met een andere medicatieafspraak (start- en stop afspraken over dezelfde medicatie), toedieningsafspraak, medicatiegebruik, contact waarin de medicatieafspraak is gemaakt en de zorgepisode. Het is dan niet de bedoeling om alle gegevens over al deze bouwstenen mee te sturen, alleen om welke specifieke instantiaties van deze bouwstenen het gaat. Dit kan worden gedaan door een relatie te leggen naar de identificatie van deze specifieke instantiaties van de bouwstenen middels het Object Identifier (OID).
Het OID nummer is samengesteld uit een deel met de identificatie van de uitgevende organisatie – de zorgaanbieder van waaruit gegevens worden verstuurd – en een deel met de identificatie van een uniek gegeven dat is opgeslagen in het informatiesysteem van deze zorgaanbieder. Voor meer uitleg hierover zie de informatie op de HL7 site.
Hieronder de uitwerking van dit voorbeeld, waarin de relaties naar de OID’s van andere bouwstenen oranje zijn omkaderd:

[[File:Opstellen_dataset_paragraaf2.2.4png.png|576×254px]]

Om een volledig overzicht te hebben van alle relaties tussen informatiebouwstenen en gegevenselementen in een dataset, is het zeer aan te bevelen om een datamodel te maken voor elke usecase.

'''2.2.5 Invoegen en verwijderen dataelementen en (waarden in) waardelijsten'''

Zoals in hoofdstuk 2.1.4 reeds is toegelicht kunnen in een dataset ook afzonderlijke dataelementen en/of (waarden in) waardelijsten worden toegevoegd of verwijderd.
Het toevoegen of juist verwijderen van dataelementen – of groepen met dataelementen – binnen een informatiebouwsteen zorgt ervoor dat een informatiebouwsteen specifieker wordt gemaakt. In gegevensuitwisselingen binnen één domein (bijvoorbeeld huisartsen) kan het nodig zijn om specifieke elementen toe te voegen. Als voorbeeld is het toegevoegde dataelement ‘Presentatierol’ in de zib ‘Zorgverlener’ binnen het huisartsendomein.
Een dergelijke toevoeging moet altijd goed worden overwogen, zoals ook al in hoofdstuk 2.1.4 is toegelicht. Dit heeft namelijk ook consequenties voor het HL7 materiaal. Daarbij draagt een toevoeging ten behoeve van één domein niet bij aan standaardisatie van gegevensuitwisselingen over de domeinen heen. Zo zal een ‘Presentatierol’ in een gegevensuitwisseling van een huisarts naar een medisch specialist geen nut hebben.
Verwijdering van één of meerdere gegevenselementen uit een zib of informatiebouwsteen in de dataset wordt gedaan als deze in geen enkele gegevensuitwisseling van de informatiestandaard voorkomt. Belangrijk is wel dat het concept van de zib daarmee niet wordt aangetast; alleen optionele elementen in een zib mogen worden verwijderd.
Ook waardelijsten kunnen in zijn geheel worden toegevoegd of verwijderd, maar ook specifieke waarden ín een waardelijst. Een regelmatig voorkomende situatie is dat een waardelijst in een zib teveel algemene waarden bevat voor een gegevensuitwisseling en/of dat er specifieke waarden ontbreken. In dat geval wordt er een waardelijst op maat gemaakt ter vervanging van de initiële zib-waardelijst. Ook kan het voorkomen dat in een gegevensuitwisseling binnen één domein een aparte waardelijst van gelijke conceptuele strekking kan worden gebruikt. Denk hierbij aan specifieke NHG-tabel waardelijsten zoals NHG-tabel 12 ‘Soort derde’ naast de Vektis AGB AfdelingSpecialismeCodelijst.
In de handleiding voor ART DECOR [Documentatie-ART] is beschreven hoe dit in zijn werk gaat. Door te koppelen aan een dataelement wordt er context gegeven aan hoe een waardelijst wordt gebruikt in gegevensuitwisseling.
Ook kunnen waardelijsten zelf worden opgesteld en ingevoegd worden. In dit geval is het van belang om de termen in deze waardelijst te toetsen bij het Terminologiecentrum. Het Terminologiecentrum zorgt er dan voor dat de termen worden gekoppeld aan termen in codestelsels zoals SNOMED CT of LOINC. In het volgende hoofdstuk wordt hier verder op ingegaan.

===Terminologie in datasets===
Deze paragraaf biedt een werkvoorschrift voor het vastleggen van terminologiekoppelingen in ART-DECOR met een onderbouwing voor de keuze in werkwijze. Het document gaat hoofdzakelijk in op de werkvoorschriften omtrent SNOMED-termen, terwijl er verschillende (inter)nationale terminologiestelsels zijn. Gezien SNOMED het meest complexe stelsel is met de meeste regels, is vooral ten aanzien van SNOMED-terminologiekoppelingen een leidraad nodig om te komen tot consistentie binnen en tussen informatiestandaarden. Tot slot, huidig document gaat uit van ART-DECOR 2. Momenteel biedt ART-DECOR 3 niet dezelfde opties. Bij doorontwikkeling van ART-DECOR 3 zal gekeken worden welke opties noodzakelijk zijn (zie BITS-issues binnen het project ART-DECOR).

'''2.3.1 Terminologiekoppelingen'''

Een dataset wordt gecodeerd via het aanbrengen van terminologiekoppelingen. Dit omvat terminologiekoppelingen bij dataset-concepten en bij waardes in waardelijsten. In de [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn terminologie koppelen] geeft het Terminologiecentrum achtergrondinformatie over de verschillende terminologiestandaarden en worden handvatten geboden voor het uitvoeren van terminologiekoppelingen en het gebruik van terminologie in informatiestandaarden.

'''2.3.1.1 Dataset-concepten'''

Aan een dataset-concept kan een definitiecode via een terminologiekoppeling toegekend worden. In de Leidraad terminologiestandaarden (paragraaf 4.2) zijn de regels terug te vinden om te komen tot een juiste terminologiekoppeling als definitiecode van een dataset-concept. De naam van het dataset-concept zou overeen moeten komen met een beschrijving van het gekoppelde terminologieconcept, die door de beheerder van het stelsel geaccordeerd is (in SNOMED betreft dit een vertaling uit de Nederlandse extensie en in LOINC een vertaling uit de Nederlandse taalset van het Regenstrief). Terminologiekoppelingen van dataset-concept en waardelijst zouden op elkaar afgestemd moeten zijn (via vraag en antwoord of op basis van hoofdcategorie en verfijning). Waar mogelijk dient context gebruikt te worden: een gedetailleerd dataset-concept kan gekoppeld worden aan een generiek terminologieconcept, mits de ontbrekende informatie uit de andere terminologiekoppelingen blijkt.

'''2.3.1.2 Waardelijsten'''

Dataset-concepten kunnen een waardedomein hebben waarin concepten worden benoemd die als waarde kunnen dienen. Deze waardes behorende bij een dataset-concept kunnen op twee manieren vastgelegd worden in ART-DECOR: via de Waardelijst-editor (gecodeerde waardes) of via de Dataset-editor (ongecodeerde conceptnamen). De Waardelijst-editor is best practice. Via de Waardelijst-editor is het waardedomein te definiëren via het koppelen van een waardelijst. Deze waardelijst kan bestaan uit een geheel codesysteem of deel van een codesysteem (referentieset, tabel, etc.), een query van codes in een codesysteem (bijvoorbeeld: ‘is-een-kind-van’) of een selectie van losse codes. Indien het waardedomein is gedefinieerd via een selectie van losse codes, wordt in ART-DECOR tevens terminologie bij de codes vastgelegd. In de overige gevallen haalt de softwareleverancier de terminologie op bij het codesysteem (bij voorkeur via de Nationale Terminologieserver).
Het opbouwen van een lijst met ongecodeerde conceptnamen (via de Dataset-editor) kan als aanzet dienen tot het opbouwen van een lijst met gecodeerde conceptnamen (via de Waardelijst-editor). Indien er vanuit gebruikers behoefte is om in de informatiestandaard aanvullend andere termen op te nemen dan die in het terminologiestelsel staan opgenomen, heeft het voorkeur om hiervoor het veld Omschrijving te gebruiken in plaats van een aanvullende lijst met ongecodeerde conceptnamen. Overigens wordt deze lijst met ongecodeerde conceptnamen niet verwerkt in de technische berichten, maar deze dient door leveranciers separaat opgehaald te worden vanuit ART-DECOR.

'''2.3.2 Terminologievelden'''

ART-DECOR biedt verschillende velden om termen bij een terminologiecode vast te leggen. Dit betreffen de velden Weergavenaam (displayName), Benamingen (designation) en Omschrijving (description).
In de documentatie over ART-DECOR worden deze velden als volgt omschreven:
*displayName: The optional human readable display name for the code for orientation purposes. This display name corresponds to an official display name or synonym for the code in the code system.
*designation: Designations are language dependent display names for the code. For any language there might be multiple, each specifying the type (fully specified name, preferred, synonym, …).
*description: You may add a description for convenience, but should note that most of the time the description here overlaps with the designation/description of the coded concept.
Wat getoond wordt in ADA in het dropdownmenu bij het maken van kwalificatiemateriaal, is afhankelijk van wat ingevuld is in ART-DECOR bij het opbouwen van de waardelijst. Tekst uit het veld description wordt niet getoond in ADA.
Voor de specifieke toepassing van deze velden in zibs en informatiestandaarden is na overleg tussen informatieanalisten, informatiearchitecten van het Zib-centurm, terminologen en HL7-specialisten functie/ doel als volgt gedefinieerd:
*Weergavenaam: Leesbare weergave van de terminologiecode, waarbij de term afkomstig is uit het oorspronkelijke codesysteem. Dit is een hulp ter herkenning voor informatieanalisten, informatiearchitecten, terminologen, HL7-specialisten, softwareontwikkelaars en zorgverleners die betrokken zijn bij de ontwikkeling en het beheer van een zib of informatiestandaard.
*Benaming (volledig gespecificeerde naam): Hulp voor informatieanalisten en terminologen ter validatie van de terminologiekoppeling.
*Omschrijving: Toelichting ter verduidelijking van de betekenis van de gekoppelde terminologiecode, in aanvulling op terminologie uit het oorspronkelijke codesysteem. Dit kan een definitie van de waarde betreffen, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of de userinterfaceterm.

Het opnemen van terminologie in ART-DECOR uit een codesysteem heeft consequenties voor het beheer van een zib of informatiestandaard: bij elke release van een zib of informatiestandaard zal via het TerminologyReport gecontroleerd moeten worden of de terminologie in ART-DECOR nog overeenkomt met de terminologie in het codesysteem (een term kan in de tussentijd, tussen release van een zib of informatiestandaard en een meer recente release van het codesysteem, veranderd zijn in het codesysteem), net zoals gecontroleerd dient te worden of een terminologiecode niet is komen te vervallen.
Bij het vastleggen van terminologie in ART-DECOR kan gebruik gemaakt worden van de selectietool. Met deze tool kan een concept in een codesysteem worden opgezocht en worden opgenomen in de waardelijst. De terminologie is afkomstig uit een lokale kopie van het codesysteem. Terminologie wordt niet automatisch bijgewerkt als deze in het codesysteem verandert.
Indien gebruik gemaakt wordt van de selectietool in ART-DECOR voor het inladen van SNOMED-concepten, wordt voor het veld Weergavenaam de Nederlandse fully specified name ingeladen (indien er een Nederlandse vertaling beschikbaar is) en voor het veld Benamingen de fully specificied name, preferred term en synonyms in de beschikbare talen. Om de best practice uit dit document te volgen, kan het nodig zijn om de ingeladen termen via de selectietool aan te passen.
Gezien er een aantal jaar geleden nog weinig Nederlandse vertalingen van SNOMED beschikbaar waren, kunnen bij terminologiecodes in eerder gepubliceerde zibs en informatiestandaarden nog Engelstalige termen staan. Inmiddels heeft het merendeel van de SNOMED-termen een Nederlandse vertaling. Indien een vertaling toch ontbreekt, dient deze aangevraagd te worden bij het Terminologiecentrum.
Soms maakt het Terminologiecentrum een nieuwe SNOMED-code aan binnen de Nederlandse extensie, wanneer er geen geschikte SNOMED-code is binnen de internationale versie. Deze nieuwe SNOMED-code zal in de meeste gevallen nog niet opgenomen zijn in de huidige gepubliceerde versie van SNOMED op moment van release van de zib of informatiestandaard. In dat geval dient de term bij de terminologiecode handmatig ingevoerd te worden. Let hierbij op dat de Nederlandse SNOMED-termen beginnen met een kleine letter en de Engelstalige SNOMED-termen met een hoofdletter.

'''2.3.2.1 Dataset-concepten'''

'''2.3.2.1.1 Weergavenaam'''

Bij het aanbrengen van een terminologiekoppeling bij een dataset-concept biedt ART-DECOR één veld, namelijk Weergavenaam, om een term in tekst mee te geven bij de code. Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse fully specified name te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een waarde). Er is gekozen voor de volledig gespecificeerd naam, gezien deze term niet alleen een leesbare weergave biedt bij de code, maar tevens validatie van de terminologiekoppeling mogelijk maakt.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2 Waardelijsten'''

'''2.3.2.2.1 Weergavenaam '''

Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse preferred term te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een dataset-concept). Er is gekozen voor de Nederlandse preferred term, gezien deze term het beste aansluit bij het doel van het bieden van een leesbare weergave van de terminologiecode. De fully specificied name in SNOMED bevat een semantic tag, waarbij kennis van SNOMED vereist is om deze te kunnen interpreteren. Bovendien is de fully specified name langer dan de preferred term, wat een onoverzichtelijkere weergave kan betekenen.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2.2 Benamingen'''

Het veld Benaming (type volledig gespecificeerde naam) dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient in dit veld de Nederlandse fully specified name opgenomen te worden. De fully specified name bevat de semantic tag die aangeeft in welke SNOMED-hiërarchie het concept valt, waardoor het mogelijk is om te beoordelen of de terminologiekoppeling correct is (op basis van de semantic tag kunnen bepaalde inconsistenties in een waardelijst in het oog springen, waar anders gemakkelijk overheen gekeken kan worden).
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.
De overige typen Benamingen (type voorkeursterm en type synoniem) dienen niet gevuld te worden. Deze velden vervullen, in tegenstelling tot Benaming (type volledig gespecificeerde naam), geen specifieke functie in het functioneel ontwerp van een informatiestandaard of zib.

'''2.3.2.2.3 Omschrijving'''

Het veld Omschrijving wordt gevuld afhankelijk van de behoeften van de eindgebruikers van de zib of informatiestandaard. In het veld Omschrijving kan tekst meegegeven worden die niet in het codesysteem opgenomen staat. Dit kan een toelichting zijn ter verduidelijking van de betekenis van de gekoppelde terminologiecode in aanvulling op terminologie uit het oorspronkelijke codesysteem, een definitie van de waarde, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of (suggestie voor) de userinterfaceterm. Dit veld is daarmee een hulp voor ontwikkelaars om te komen tot een geschikte benaming in de userinterface.
Indien het veld Omschrijving een userinterfaceterm bevat, hebben informatieanalist/informatiearchitect en terminoloog gevalideerd dat deze term en gekoppelde terminologiecode overeenkomen in betekenis binnen de context van de waardelijst. Een userinterfaceterm kan specifieker zijn dan de term in het codesysteem door de context die de waardelijst meegeeft, of juist meer generiek, doordat de context van de waardelijst een specifieke benaming van de waarde overbodig maakt.
Indien er met de betrokken partijen afgesproken is dat het beheer van de gebruikte terminologie van een waardelijst binnen de informatiestandaard valt, waarbij er afspraken gemaakt zijn over de letterlijke term die op de gebruikersinterface getoond dient te worden, is dit veld onderdeel van de kwalificatie.
2.3.3 Het maken van gespecialiseerde waardelijsten
Zoals in 2.2.5 is benoemd kan het nodig zijn om een waardelijst van een geërfde bouwsteen te vervangen door een gespecialiseerde waardelijst. In het geval dat er een beperkt aantal concepten aan de oorspronkelijke waardelijst moeten worden toegevoegd of juist verwijderd zijn er twee alternatieven:
*Een kopie maken van de waardelijst van de geërfde bouwsteen en deze bewerken. De relatie van de nieuwe waardelijst met de oorspronkelijke waardelijst gaat verloren. Wijzigingen in de oorspronkelijke waardelijst worden niet doorgevoerd op de gespecialiseerde waardelijst. Je kiest hiervoor als de gespecialiseerde waardelijst niet lijkt op oorspronkelijke waardelijst, bijvoorbeeld omdat de gespecialiseerde waardelijst een opsomming is van mogelijke waarden en de oorspronkelijke een codestelsel, of een deel van een codestelsel gespecificeerd met een intensionele expressie.
*De waardelijst van de geërfde bouwsteen includeren in de gespecialiseerde waardelijst. Hierbij blijft de relatie met de oorspronkelijke waardelijst zichtbaar. Dit kan op twee manieren:
*Statische inclusie: een specifieke versie van de waardelijst wordt geïncludeerd (deze zal niet meer wijzigen)
*Dynamische inclusie: de laatste versie van de waardelijst wordt geïncludeerd. Doorgaans wordt bij een gespecialiseerde lijst geen dynamische inclusie toegepast. Maar indien hier wel voor is gekozen, moet ervoor wordt gewaakt of de inclusie en de zelf toegevoegde waarden inderdaad volledig disjunct zijn en blijven zodat er geen dubbelingen ontstaan. Het alternatief is om de eigen toevoegingen mee te laten nemen in de volgende release van een waardelijst.
De extra concepten, nodig voor de specialisatie, kunnen los worden toegevoegd of met Inclusies. Bij deze laatste methode moet een intentionele expressie worden ingevuld. Concepten uit de waardelijst van de geërfde bouwsteen die juist niet gewenst zijn in de gespecialiseerde waardelijst, kunnen met exclusies worden uitgesloten (ook weer met intentionele expressie).

===Generieke modelering – afspraken===

In hoofdstuk 2.2.4 is uitgelegd dat er tussen de verschillende bouwstenen en/of dataelementen in bouwstenen relaties kunnen worden gelegd. Deze relaties geven context aan of nadere aanvulling van gegevens. In het kader van standardisatie van gegevensuitwisseling niet alleen binnen één informatiestandaard maar ook in standaardisatie tussen alle informatiestandaarden is het belangrijkom dit soort relaties op een zoveel mogelijk eenduidige manier te doen. Als in alle informatiestandaarden op dezelfde manier relaties en modeleringen van gegevens worden gemaakt, is het voor de informatieanalisten veel eenvoudiger om te bepalen wat er in de verschillende informatiestandaarden aan gegevens worden uitgewisseld en hoe dit op elkaar aansluit. Evenzo belangrijk is dat de technische specificaties in HL7 berichten veel meer generiek kunnen worden uitgewerkt.

==Samenstellen scenario’s==

Een Nictiz informatiestandaard bevat minimaal één maar meestal meerdere usecases. Een usecase is een beschrijving van een informatie-uitwisseling op een specifiek moment in het zorgproces, waarbij voor een concrete praktijksituatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Zoals eerder gemeld staan alle usecases van één informatiestandaard beschreven in een functioneel ontwerp.
De specifieke gegevens die worden uitgewisseld binnen elk van de usecases zijn een subset van de dataset voor een gehele informatiestandaard. Daarom moet voor elke usecase een datascenario worden aangemaakt. In dit hoofdstuk wordt verder ingegaan op de keuzes en mogelijkheden voor het samenstellen van een datascenario.
N.B.: In dit document wordt consequent de term ‘datascenario’ gebruikt in plaats van de term ‘scenario’ zoals dat wordt gebruikt in ART DECOR. De reden is dat ‘scenario’ een term is die breed kan worden opgevat en daarom met verschillende betekenissen in velerlei documentatie wordt gebruikt. ‘Datascenario’ geeft meer context aan de betekenis voor dit document.

===Usecase en datascenario===
In principe wordt er voor elke usecase binnen een informatiestandaard een datascenario samengesteld. De naamgeving van een datascenario volgt veelal de hoofdlijn van elke usecase. Bijvoorbeeld in de informatiestandaard Acute zorg is er de usecase ‘Uitwisseling ambulance naar SEH’ waarvoor het datascenario ‘AMB (ambulance) draagt over aan SEH (Spoedeisende hulp)’ is samengesteld.
Het kan voorkomen dat de inhoud van de gegevensuitwisseling voor meerdere usecases binnen één informatiestandaard hetzelfde is. In dit geval wordt er voor meerdere usecases één datascenario samengesteld, waarbij in de naamgeving van het datascenario de meerdere usecases worden benoemd. Rugten naar ‘scenario

===Datascenario, transactiegroepen en transacties===
Elk datascenario is opgebouwd uit één of meerdere transactiegroepen. Een transactiegroep bevat alle transacties die bijdragen aan één specifieke gegevensuitwisseling tussen twee partijen.
Vaak is het zo dat binnen één datascenario ook maar één transactiegroep wordt gebruikt maar het is evengoed mogelijk om binnen één datascenario meerdere transactiegroepen te gebruiken, dit wordt verderop in dit hoofdstuk toegelicht.
Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.
Elke transactiegroep kan weer één of meerdere transacties bevatten. Een transactie is een werkelijke overdracht van gegevens.
Een transactiegroep waarin berichten worden verstuurd, bevat doorgaans een transactie met de verstuurde gegevens en een transactie met de ontvangstbevestiging. Dit zijn een zogenaamde push-transacties: overdrachten van gegevens waarbij de verzender op eigen initiatief een bericht verstuurt en waarbij de ontvanger dit bericht ontvangt zonder dat daarvoor actief naar is gevraagd.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het versturen van een specifieke gegevensset, ofwel dat het gaat om een ontvangstbevestiging. Vaak wordt deze transactie als overbodig beschouwd en daarom achterwege gelaten.

Een transactiegroep waarin gegevens worden geraadpleegd, bevat doorgaans een transactie met de raadpleging op maat en een transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Dit is een zogenaamde pull-transactie: een overdracht van gegevens waarbij de ontvanger van deze gegevens actief om heeft gevraagd en waarbij de verzender deze gegevens beschikbaar heeft gesteld.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het raadplegen van een specifieke gegevens set, ofwel dat het gaat om het beschikbaarstellen van de geraadpleegde gegevens.
Zoals eerder gemeld kan er in een transactiegroep in plaats van één transactie met alle benodigde gegevens ook worden gekozen voor het toepassen van meerdere transacties voor het versturen van gegevens: bijvoorbeeld één transactie per (zorginformatie-)bouwsteen. Deze constructie kan worden toegepast als er één datascenario wordt gebruikt voor meerdere usecases, waarbij het merendeel van de verstuurde gegevens gelijk is, maar waar er per usecase soms wel of niet een extra bouwsteen moet worden meegestuurd. Een voorbeeld hiervan is het opvragen van de professionele samenvatting door meerdere raadplegende partijen in de acute zorg – de meldkamer, ambulance en de SEH – waarbij de meldkamer geen gegevens over overgevoeligheden wil ontvangen. In dit geval is er geen transactie met de bouwsteen voor overgevoeligheden.
Als voorbeeld voor de hierboven beschreven samenstelling van datascenario’s met transactiegroepen en push- en pull-transacties dient wederom de informatiestandaard voor acute zorg. met hieronder een aantal usecases waarvoor datascenario’s zijn samengesteld met push-transacties, zoals:
*Berichten van de ambulance naar de SEH
*Verwijzen van een patiënt van (waarnemend) huisarts naar de meldkamer
*Versturen rapportages van meldkamer, ambulance en SEH naar de huisarts
In het plaatje hieronder is een uitwerking van het datascenario voor berichten van de ambulance naar de SEH:

[[File:Opstellen_dataset_paragraaf_3.2a.png|576×254px]]

En een drietal usecases waarvoor één datascenario is samengesteld met pull-transacties:
*Opvragen van de professionele samenvatting bij de huisarts door de meldkamer, ambulance of SEH

[[File:Opstellen_dataset_paragraaf_3.2b.png|576×254px]]

In ART-DECOR worden de transacties binnen een datascenario gegroepeerd tot een transactiegroep. In datascenario’s waarin berichten worden verstuurd, bestaan een transactiegroep uit de transactie met verstuurde gegevens en de transactie met de ontvangstbevestiging. In datascenario’s waarin gegevens worden geraadpleegd bestaat de transactiegroep uit de transactie met de raadpleging op maat en de transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.

===Transactiedataset===
Per transactie wordt er een specifieke set gegevens verstuurd van de verzender naar de ontvanger. In een transactiedataset is dit gedetailleerd uitgewerkt. Alle gegevenselementen en (delen van) zibs en/of informatiebouwstenen n een transactiedataset worden betrokken uit de informatiestandaard dataset zoals beschreven in hoofdstuk 2. Andersom kan ook worden gezegd dat alle transactiedatasets van de transacties als onderdeel van een transactiegroep, die op hun beurt weer onderdeel zijn van een datascenario, tezamen de informatiestandaard dataset vormen.

'''3.3.1 Cardinaliteit en conformance'''
In een transactiedataset wordt per gegevenselement ook de kardinaliteit aangegeven. Op de informatiepagina van het zib-centrum is uitgelegd wat kardinaliteiten zijn: https://zibs.nl/wiki/Zib_kardinaliteiten
In informatiemodellen wordt kardinaliteit gebruikt om de multipliciteit van een element ten opzichte van zijn parent – of als het een top level element is, de multipliciteit van de boom eronder - in een transactie aan te geven. Daarbij wordt de notatie ‘m..n’ gebruikt, waarbij ‘m’ de minimale multipliciteit is en ‘n’ de maximale. In het model wordt de kardinaliteit genoteerd bij het element waarvoor dit geldt. Dus als er tussen element A en element B en relatie bestaat en bij element B de kardinaliteit m..n staat, betekent dit dat een element A minimaal met ‘m’ elementen B een relatie heeft en maximaal met ‘n’ elementen B
Naast de multipliciteit wordt met een letter aangegeven of deze relatie Mandatory, Required, Conditional of Optional is:

{| class="wikitable"
! M (Mandatory)
|Een gegeven moet altijd worden aangeleverd. De minimale multipliciteit is dan ook 1..1M
|-
! R (Required)
| Indien een gegeven beschikbaar is, moet deze worden aangeleverd. Bijvoorbeeld als één of meerdere voornamen van een patiënt bekend zijn. De kardinaliteit is in dit geval 0..*R
|-
! C (Conditional)
| Een gegeven dat moet worden aangeleverd, afhankelijk van de waarde of aanwezigheid van een ander gegeven. Bijvoorbeeld de invulling van een toelichting indien in een waardelijst de optie ‘Anders’ is geselecteerd. De kardinaliteit van de toelichting is in dit geval 1..1C
|-
! O (Optional)
| Een gegeven dat eventueel kan worden aangeleverd maar niet noodzakelijk. Deze optie wordt vrijwel niet toegepast. Als een gegeven niet noodzakelijk is binnen een overdracht, wordt deze in de regel ook niet opgenomen in een informatiestandaard.
|}

De kardinaliteiten zoals vastgesteld in de transactiedatasets zijn functioneel leidend. Op basis hiervan kan worden afgeleid wat er in een gegevensoverdracht aan gegevens moet worden meegestuurd. Een verzendende partij weet welke gegevens er moeten worden opgeleverd, al dan niet verplicht, verplicht indien beschikbaar of conditioneel. Een ontvangende partij weet wat er aan gegevens moet worden verwerkt en getoond kunnen worden.
Let op: de kardinaliteit in zibs zijn conceptueel; het kan dus voorkomen dat een kardinaliteit van een gegeven in een transactiedataset enger is als die in een zib. Dit geldt ook voor de kardinaliteiten in HL7v3 tempates en FHIR profielen; deze kunnen minder eng zijn als die in een transactiedataset.
Andersom is conceptueel niet mogelijk. Als iets conceptueel verplicht is of in bijvoorbeeld een FHIR profiel verplicht staat (zoals 1..1M), is het niet mogelijk om in de functionele transactiedataset hier geen verplichting aan te geven (zoals 0..1R).
Zoals in hoofdstuk 2.3.3 en 2.3.4 is uitgelegd kunnen in een dataset – en dus ook in een transactiedataset – verwijzingen en relaties voorkomen. Ook deze kennen kardinaliteiten. Bij verwijzingen geldt dat de bron-bouwsteen waar naar verwezen wordt in de dataset, ook in de transactiedataset moet voorkomen. De kardinaliteit van deze bron-bouwsteenen alle gegevens daarbinnen geldt dat voor alle contexten met verwijzingen. Als voorbeeld is wederom de LaboratoriumUitslag van hoofdstuk 2.3.3:

[[File:Opstellen_dataset_paragraaf_3.3.1.png|576×254px]]

Hierbij geldt dat in de bouwsteen LaboratoriumUitslag de kardinaliteit van de context – LaboratoriumUitslagVerantwoordelijke, Aanvrager en Uitvoerder – aangeeft hoe elk van deze contexten in het bericht moeten worden meegenomen. In dit geval dus alle drie verplicht. De kardinaliteit van de verwezen bouwstenen onder de context geeft aan dat áls er bijvoorbeeld een Uitvoerder is, dat dan de verwezen Zorgverlener óf Zorgaanbieder aanwezig moet zijn (vandaar de kardinaliteit van beiden 0..1 R). Bij de Aanvrager is er maar één mogelijkheid – de Zorgverlener – en vandaar dat deze dan ook mandatory is.
In de verwezen bron-bouwsteen Zorgverlener gelden vervolgens de kardinaliteiten zoals hierin is opgezet.

'''3.3.2 Raadplegen: Query Parameters'''

Voor de transactieset waarin gegevens worden opgevraagd door een partij (PULL), is vaak een selectie op de gegevens van toepassing.

Dit kan op twee manieren zijn ingericht in ART DECOR:
*Vooraf vastgestelde selectie: als onderdeel van de transactie beschikbaarstellen
*Variabele selectie: als query parameter in de transactie raadplegen

De eerst genoemde situatie is vooral van toepassing wanneer er landelijke afspraken zijn dat er altijd een standaard selectie wordt toegepast. Dit zorgt ervoor dat altijd eenzelfde overzicht voor een patiënt wordt gegenereerd. Bijvoorbeeld in de BgZ, is de “laatst bekende bloeddruk” in beschikbaarstellen opgenomen als 0..1 conditioneel:

[[File:Opstellen_dataset_paragraaf_3.3.2a.png|576×254px]]

De laatst genoemde situatie met query parameters, is van toepassing wanneer het nodig is een specifieke selectie per individuele raadpleging te maken. Bijvoorbeeld; de eindgebruiker van een systeem geeft zelf aan voor welke patiënt en in welke periode er informatie opgevraagd wordt. Welke gegevens als query parameters gebruikt kunnen worden, is afhankelijk van de usecase. Vaak zal er een identificatie(nummer) uit de Patiënt zib gebruikt worden zodat de raadpleging gericht voor één persoon plaats vindt.
In ART-DECOR dit worden ingericht, door in de dataset een groep “QueryParameters” op te nemen en dan de relevante parameters in de transactie(s) Raadplegen te gebruiken. Een parameter kan gebruik maken van een gegevenselement uit 1 bouwsteen, bijv. het identificatienummer van de Patiënt. Een andere mogelijkheid is dat een parameter gebruik maakt van 1 type gegeven die op meerdere plaatsen in de dataset voor komt, bijv. een datum(periode) waarin meerdere metingen (zoals bloeddruk, gewicht en lengte) uitgevoerd kunnen zijn.
Om duidelijk te maken aan wélke gegevens de parameters gelinkt zijn, kan je de in de dataset dit toelichten in de naam en omschrijving van de query parameter. Ook de zoekwijze kan je hier toelichten, zoals voor periodes waarin gezocht kan worden. Als daarnaast per transactie nog aparte regels gelden, kan je dit via het veld context bij de transactie uitleggen (en/of via een Conditie indien dit van toepassing is).
Als voorbeeld hieronder een weergave van de Gebruiksperiode in de transactie Raadplegen medicatieafspraak (MP 2.0.0): voor de gebruiksperiode is in de omschrijving van het concept aangegeven op welke conceptgroepen uit de dataset (“MA, WDS en TA”) de periode van toepassing is. Voor de transactie is dan ook nog een conditie opgenomen ter nadere specificatie.

[[File:Opstellen_dataset_paragraaf_3.3.2b.png|576×254px]]

=Release notes=
In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

Bestand:Opstellen dataset paragraaf 3.2a.png

2025-08-26T09:30:18Z

Lilian Brouwer: Lilian Brouwer heeft een nieuwe versie van Bestand:Opstellen dataset paragraaf 3.2a.png geüpload

Bestand:Opstellen dataset paragraaf 3.2a.png

2025-08-26T09:29:32Z

Lilian Brouwer: Lilian Brouwer heeft een nieuwe versie van Bestand:Opstellen dataset paragraaf 3.2a.png geüpload

qa:Instructie opstellen dataset

2025-08-26T08:13:31Z

Lilian Brouwer: /* Transactiedataset */

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Instructie opstellen dataset 3.0.0 {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__

==Inleiding==
Dit document beschrijft de ‘best practices’ bij het opstellen van een dataset, behorende bij een informatiestandaard. Deze ‘best practices voor Nictiz datasets’ is de richtlijn voor iedereen die zich bezighoudt met het opstellen en beheren van datasets. Door op een eenduidige wijze deze datasets samen te stellen, wordt de uitwisselbaarheid in (delen van) datasets verbeterd en wordt het voor beheerders van datasets ook eenvoudiger om datasets die zijn opgesteld door collega’s, inzichtelijk te krijgen. Hiermee wordt ook getracht om de mapping van met name de datascenario’s op de HL7 berichten (HL7v3 templates en FHIR-profielen) te vereenvoudigen.
Daarnaast is de uniformiteit in de samenstelling van datasets van groot belang voor externe partijen – met name zorginstellingen en hun ICT-leveranciers die met behulp van de datasets en datascenario's de gegevensuitwisselingen conform de Nictiz informatiestandaarden moeten implementeren.
Voor de leesbaarheid en de juiste context van begrippen zijn een aantal relevante definities hieronder ingevoegd. Deze komen vanuit de
[https://nictiz.nl/standaarden/begrippen/ Nictiz begrippenlijst] of zijn er aan toegevoegd (met de intentie om deze alsnog op te nemen in de begrippenlijst):

{| class="wikitable"
! Begrip
! Definitie
|-
| Richtlijn
| Beschrijving die verduidelijkt wat behoort te worden gedaan en hoe, om de doelstellingen te bereiken die in het beleid zijn vastgelegd (NEN 7510)
|-
| Functioneel ontwerp
| In een Nictiz functioneel ontwerp worden alle eisen en wensen voor alle usecases (ook wel uitwisselscenario’s genoemd) binnen één informatiestandaard verzameld en geordend. Per usecase wordt beschreven op welke manier dat gebeurt: tussen welke gebruikers vindt de gegevensuitwisseling plaats, welke handelingen worden daarbij uitgevoerd en welke resultaten leveren deze op.
|-
| Usecase
| Een beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het vastleggen en/of uitwisselen van
|-
|
| informatie wordt beschreven aan de hand van actoren (mensen, informatiesystemen) en transacties (welke informatie wordt wanneer uitgewisseld).
|-
| Dataset
| Een dataset bevat definities van alle gegevens die binnen de context van een specifiek zorgproces en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Deze definities zijn functioneel van aard en worden vastgesteld door het zorgveld. Voor specifieke transacties binnen het zorgproces wordt gebruik gemaakt van een subset van de gegevens uit deze dataset (het datascenario).
|-
| Zib
| Zorginformatiebouwstenen (zibs) worden gebruikt om inhoudelijke (niet technische) afspraken vast te leggen ten behoeve van het standaardiseren van informatie, die gebruikt wordt in het zorgproces. Het doel van de standaardisatie is dat deze informatie uit het zorgproces wordt hergebruikt voor andere doeleinden, zoals kwaliteitsregistraties, overdracht, patiëntgebonden onderzoek. Een zorginformatiebouwsteen is een informatiemodel, waarin een zorginhoudelijk concept wordt beschreven in termen van de gegevenselementen waaruit dat concept bestaat, de datatypes van die gegevenselementen etc.
|-
| Informatiebouwsteen
| Een concrete voorziening, standaard, afspraak of arrangement, met een eigenaar, beheerder, financiering et cetera die bovensectoraal of zorgbreed (her)gebruikt kan worden.
|-
|
| Informatiebouwstenen kunnen zijn (opgebouwd uit) zibs en/of opgebouwd uit gegevenselementen.
|-
| Dataelement / gegeven
| Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
|-
| Scenario
| De representatie van een usecase in ART DECOR waarin de actoren en een specifieke subset gegevens uit de dataset (transactiedataset) zijn uitgewerkt.
|-
| Transactiegroep
| Een model van een verzameling van gegevens die wordt overgedragen tussen actoren (personen of systeemrollen) binnen één usecase. Een transactie wordt schematisch weergegeven door de uitwisseling van een transactiedataset tussen twee actoren.
|-
| Transactiedataset
| Een subset van gegevens uit de dataset voor een specifieke transactie met kardinaliteiten en conformiteiten.
|-
| Intensionele waardelijst en expressie
| Zie 2.3.2

Een intentionele waardelijst geeft niet direct aan welke directe waarden je moet hebben, maar alleen een intentie geeft voor elke waarde erin in thuishoort. Dit doe je door een intentionele expressie (dat in feite een query is), zoals :

< T : alle waarden onder T

of

<< T : T en alle waarden daaronder

of

< T1

OR

< T2 : alle waarden onder T1 of T2
N.B. Daarnaast kun je waardes in de intentionele expressie ook excluderen
|}

===Doelstelling===
Het eerste doel van dit document is het bevorderen van inzicht in hoe een dataset wordt samengesteld. De richtlijnen en methoden voor het samenstellen van een dataset worden in dit document nader toegelicht.
Het tweede doel van dit document is het bevorderen van inzicht in hoe een datascenario wordt samengesteld vanuit een dataset. De richtlijnen en methoden voor het samenstellen van een datascenario worden in dit document nader toegelicht.

===Scope van dit document===
Dit document geeft definities van een dataset, zib, informatiebouwsteen, data-element en een datascenario. Ook wordt uitgelegd hoe een dataset en een datascenario op een eenduidige wijze moet worden samengesteld. De verschillende methoden die hiervoor gebruikt worden, zijn nader beschreven.
Dit document kan als een richtlijn worden beschouwd voor wijze waarop binnen Nictiz datasets en datascenario’s worden samengesteld. Ook voor beheer van reeds bestaande datasets en datascenario’s is deze richtlijn van toepassing.

===Buiten scope van dit document===
Een dataset bevat definities van alle gegevens die in een specifieke context binnen het zorgproces, en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Voor elke usecase moeten door betrokken partijen afspraken gemaakt worden over de inhoud van de te gebruiken gegevens – het datascenario. De definities die van toepassing zijn in het zorgproces zijn functioneel van aard en worden vastgesteld door de zorgverleners in een functioneel ontwerp en daarmee buiten de scope van dit document.
Eveneens buiten scope is een uitleg van de tooling waarmee datasets worden samengesteld en gepresenteerd. Hiervoor wordt verwezen naar ART DECOR [https://decor.nictiz.nl/wiki/index.php/Ontwikkelaars#Proces_ontwikkelen_DECOR-project, https://simplifier.net/, Zibs 2017: https://simplifier.net/NictizSTU3-Zib2017, http://www.art-decor.org]. Echter, vanwege praktische redenen worden in dit document afbeeldingen gebruikt van (delen van) datasets en datascenario’s in ART DECOR om beschrijvingen nader toe te lichten.
Dit document is gericht aan inhoudelijke experts op het gebied van Nictiz informatiestandaarden (informatieanalisten, product managers, Specialisten gegevensuitwisseling, etc.) waarvan wordt verondersteld dat men bekend is met de gebruikte terminologieën, tooling, documentatie, etc.. Deze worden daarom niet verder toegelicht en beschreven in dit document.

==Samenstellen datasets==

===Richtlijnen voor het samenstellen van datasets===
Voor het opstellen van een dataset gelden een aantal basisprincipes. In het kort komt dit neer op de volgende punten:
*Zoveel mogelijk gebruik maken van de meest recent gepubliceerde zibs
*Indien geen zibs beschikbaar, bekijk reeds bestaande datasets, CIMS en/of kandidaat-zibs op de aanwezigheid van informatiebouwstenen die toegepast kunnen worden in de nieuwe dataset
*Conformeer zoveel mogelijk aan het zorgproces, de informatiestandaard (op basis van richtlijnen en functioneel ontwerp) maar ook aan de gegevensmodellen van de zibs en informatiebouwstenen
*Voeg alleen dataelementen en (waarden in) waardelijsten toe als deze niet worden gerepresenteerd door reeds beschikbare dataelementen en (waarden in) waardelijsten in zibs en/of informatiebouwstenen
*Conformeer zo veel mogelijk aan de generieke volgorde van zibs en informatiebouwstenen in een dataset
In dit best practice document wordt in de subhoofdstukken hierna voor elk van deze punten beschreven wat dit betekent voor de daadwerkelijke samenstelling van een dataset.

'''2.1.1 Meest recent gepubliceerde zibs'''

Over het nut en noodzaak van zibs is reeds de nodige literatuur [https://zibs.nl/wiki/Hoofdpagina beschikbaar]. Door voortschrijdend inzicht en met inbreng van vele stakeholders worden zibs middels een strikt nageleefd beheerproces aangepast. Bij het samenstellen van een nieuwe dataset is het dan ook van groot belang om de meest recent gepubliceerde zibs te gebruiken.
In ART-DECOR zijn alle zibs van de meest recente publicatie beschikbaar en kunnen worden gebruikt als informatiebouwsteen om een dataset mee samen te stellen. Door zoveel mogelijk gebruik te maken van de zib concepten, kan informatie in alle afzonderlijke zorgtoepassingen op dezelfde manier worden vastgelegd (tussen de zender en ontvanger) en blijft de betekenis gelijk.
Zibs zijn concepten die zorgbreed kunnen worden toegepast. Het kan daarom voorkomen dat in specifieke gegevensoverdrachten in een bepaald domein een aanvulling op dit concept nodig is. Bijvoorbeeld extra dataelementen of waardelijsten die niet in de zibs zijn opgenomen. Ook kan het voorkomen dat binnen een dataset slechts een deel van de zib wordt gebruikt. Elementen van een zib kunnen daarom ook worden verwijderd, zolang dit het conceptuele model van de zib niet compromitteert.

'''2.1.2 Informatiebouwstenen'''

Naast zibs kunnen ook informatiebouwstenen worden gebruikt bij het samenstellen van een dataset. Informatiebouwstenen kunnen zibs zijn met een aantal toevoegingen of verwijderingen van dataelementen en/of waardelijsten, detailed clinical models (DCM’s) die geen zibs zijn of nog kandidaat-zibs zijn (zie ook ‘Zorginformatiebouwstenen – Richtlijnen bij afwezigheid van zib’s’) of een zelf opgebouwde informatiebouwsteen. Vaak zijn deze informatiebouwstenen voor één of hooguit enkele zorgdomeinen van toepassing, in tegenstelling tot zibs die zorgbreed toegepast kunnen worden.
Bekijk daarom ook functioneel ontwerpen en informatiebouwstenen in datasets van andere informatiestandaarden om te bepalen of er, al dan niet gedeeltelijke, overlap is met betrekking tot de inhoud van de gegevensuitwisseling. Door hergebruik van informatiebouwstenen worden ook gegevensuitwisselingen die niet met zibs kunnen worden gemodelleerd, zoveel mogelijk gestandaardiseerd.

[[File:Opstellen_dataset_paragraaf2.1.png|576×254px]]

Hoe een zib in een bepaalde zorgsituatie (usecase) wordt gebruikt is vastgelegd in een informatiestandaard. Een informatiestandaard voegt context en relaties toe aan de zib gegevensmodellen en beschrijft in welke zorgsituatie je welke gegevens vastlegt en uitwisselt [zie ook https://www.nictiz.nl/standaardisatie/informatiestandaarden/].

'''2.1.3 Zorgproces, informatiestandaard en gegevensmodellering'''

Vanzelfsprekend zijn het zorgproces en kwaliteitstandaarden/richtlijnen de leidraad voor wat er in de dataset moet worden toegevoegd aan zibs, informatiebouwstenen en/of dataelementen en waardelijsten. Vaak wordt er bij het samenstellen van de dataset en meer nog het datascenario (zie het hoofdstuk Samenstellen datascenario) ruggespraak gehouden met experts uit het zorgveld. Deze dataexperts kunnen waardevol inzicht verschaffen bij het ‘fijnslijpen’ en completeren van een dataset en de datascenario’s. Hierbij dient er wel scherp op gelet te worden dat de dataset samenstelling er is voor interoperabiliteit en niet voor het modelleren van systemen.

'''2.1.4 Toevoegen dataelementen en waardelijsten'''

In een dataset kunnen ook ‘losse’ dataelementen en specifieke waardelijsten worden toegevoegd. Meestal worden deze dataelementen en/of waardelijsten toegevoegd aan onterfde zibs en/of informatiebouwstenen om deze op maat te maken voor een specifieke informatiestandaard, zie ook Methoden voor samenstellen datasets bij subhoofdstuk 2.2.5 Invoegen en verwijderen dataelementen en waarden in waardelijsten. In een enkel geval kunnen dataelementen ook rechtstreeks in een dataset worden ingevoegd.
Er moet goed worden overwogen welke gevolgen dit heeft voor de datascenario’s en onderliggende HL7-berichten. Ook moet er scherp op gelet worden dat eventuele toevoegingen van dataelementen en (waarden in) waardelijsten complementair zijn aan de reeds beschikbare gegevens in de zibs en niet als vervanging voor terminologie.

'''2.1.5 Volgordelijkheid (zorg)informatiebouwstenen en dataelementen in dataset'''

Naast dat datasets de verzameling zijn van alle gegevens in alle datascenario’s, zijn datasets ook bedoeld om een overzicht te bieden aan Nictiz collega’s en externe dataexperts. Door een zoveel mogelijk gestandaardiseerde volgorde van zibs en informatiebouwstenen aan te houden in een dataset, wordt er een beter overzicht gecreëerd. Ook is het mogelijk om bepaalde segmenten toe te passen, zoals een groep ‘bundel’ of ‘bouwstenen’ waarbinnen de (zorg)informatiebouwstenen zijn ondergebracht waarnaar wordt verwezen vanuit andere delen van de dataset.
Een strak gereguleerde volgordelijkheid van informatiebouwstenen in alle informatiestandaard-datasets is lastig te realiseren. Het voornaamste is dat Nictiz collega’s en externe partijen op een zo eenvoudig en intuïtief mogelijke wijze de samenstelling van een dataset goed kunnen overzien.
Hieronder is een voorbeeld als leidraad voor een volgordelijkheid van zibs en informatiebouwstenen in een dataset:
*Patiënt
*Zorgverlener
*Zorgaanbieder
*Contactmomenten
*Zibs en informatiebouwstenen m.b.t. triage, diagnose
*Zibs en informatiebouwstenen m.b.t. behandeling en verrichting
*Zibs en informatiebouwstenen m.b.t. uitslagen en verslaglegging
*Zibs en informatiebouwstenen voor specifieke onderwerpen in een usecase
Echter, het is mogelijk dat deze volgordelijkheid in bestaande en nieuwe datasets in ART DECOR niet is toegepast. Vooral de wat oudere datasets zijn hierin soms afwijkend. En regelmatig zijn er in datasets de eerder genoemde segmenten gebruikt waarbij zibs en informatiebouwstenen in een groep zijn samengevoegd, zoals “Demografie en identificatie” met zibs Patiënt, Contactgegevens en BurgerlijkeStaat of “Sociale Anamnese” met zibs Woonsituatie, Taalvaardigheid, ParticipatieInMaatschappij en HulpVanAnderen.

===Methoden voor samenstellen datasets===
Datasets kunnen met verschillende methoden worden samengesteld:
*Erven (zibs en informatiebouwstenen)
*Onterven (na eerst te hebben geërfd)
*Verwijzen
*Relaties maken tussen informatiebouwstenen
*Invoegen en verwijderen dataelementen en (waarden in) waardelijsten
In dit best practice document wordt elk van deze methoden beschreven, alsook een uitleg over welke methode te gebruiken in bepaalde situaties.

'''2.2.1 Erven'''

Binnen ART-DECOR kan een zib of een informatiebouwsteen uit een andere dataset in de eigen dataset worden geërfd. Erven houdt in dat alle gegevenselementen van een zib of informatiebouwsteen, inclusief de onderlinge samenhang (structuur), worden gekopieerd en toegevoegd in de nieuwe dataset.

'''2.2.2 Onterven'''

Een geërfde zib of (zelf ontwikkelde) informatiebouwsteen dient in veel gevallen nog te worden aangepast. Er kunnen gegevenselementen aan worden toegevoegd of juist verwijderd (hoofdstuk 2.2.5). Ook kunnen er relaties worden toegevoegd, zoals wordt beschreven in hoofdstuk 2.2.4 – Relaties binnen datasets. Om dit te kunnen doen, dient een overerfde zib of informatiebouwsteen te worden onterfd, alvorens wijzigingen te kunnen doorvoeren.
Op deze manier ontstaan nieuwe informatiebouwstenen, welke volledig naar informatiebehoefte zijn gemaakt maar waarbij toch zoveel mogelijk de generieke zibs blijven behouden. Hierbij geldt wel dat alleen optionele elementen uit een zib kunnen worden verwijderd en niet de elementen die de kern van een concept omvatten; alleen dan is een nieuwe bouwsteen compatibel met oorspronkelijke zib.
Om in een dataset meer duiding te geven aan de toepassing van een zib, kan na onterven de naamgeving van een zib worden hernoemd. Als voorbeeld: in de dataset voor de informatiestandaard Geboortezorg wordt de zib Probleem twee keer toegepast maar elk in een andere context. Daarom is de zib Probleem voor de twee contexten hernoemd naar respectievelijk ProbleemKind en ProbleemMoeder. In de referentie van de zib is nog steeds zichtbaar dat voor elk van de twee contexten de zib Probleem de basis is.
Edoch, middels het plaatsen van een zib in een datagroep met een context kan ook duiding worden gegeven aan de specifieke toepassing van een zib in een dataset. Dit is beschreven in paragraaf 2.2.3 Verwijzingen. Uit oogpunt van herkenning van het gebruik van zibs en het gebruik van ADA is de voorkeur om datagroepen met context te gebruiken boven het hernoemen van zibs.

'''2.2.3 Verwijzingen'''

In een dataset kan een verwijzing vanuit een informatiebouwsteen naar een andere informatiebouwsteen of losse gegevenselementen worden gemaakt. Dit wordt gedaan wanneer een generieke informatiebouwsteen – in de meeste gevallen een zib – binnen een dataset meerdere keren op de zelfde wijze wordt gebruikt. Bij een verwijzing worden dus de gegevens van de informatiebouwsteen waar naar verwezen wordt ook opgenomen binnen de informatiebouwsteen van waaruit verwezen wordt. Door de verwijzing te maken in een datagroep met een specifieke context, zijn de gegevens vanuit de verwezen bouwsteen daarmee ook van toepassing op deze context.
Hieronder is een voorbeeld van de zib Labuitslag waarin gegevens over de laboratoriumverantwoordelijke, aanvrager en de uitvoerder zijn opgenomen. Voor drie verschillende contexten wordt steeds de zib Zorgverlener gebruikt; elk dus met een specifieke context. Hieronder de uitwerking van dit voorbeeld in ART DECOR, in blauw omrand:

[[File:Opstellen_dataset_paragraaf2.2.png|576×254px]]

In dit voorbeeld staat de zib Zorgverlener elders in de dataset uitgewerkt. Deze uitwerking is dus van toepassing op de drie contexten waarin deze zib wordt gebruikt.
Verwijzingen tussen informatiebouwstenen en/of losse gegevenselementen worden doorgaans binnen één dataset te worden gemaakt (want je kunt in principe ook verwijzen naar bouwstenen die in een andere dataset staan). Alleen in dat geval is er op de volledige dataset, inclusief de bouwstenen waar naar wordt verwezen, volledig beheer mogelijk.

'''2.2.4 Relaties'''

In een dataset kunnen ook relaties worden gelegd tussen informatiebouwstenen. Het verschil met het maken van een verwijzing is dat bij een relatie vanuit een bouwsteen naar een andere bouwsteen niet de gegevens van die gerelateerde bouwsteen worden opgenomen maar zijn wel te herleiden.
Als bijvoorbeeld gegevens over een medicatieafspraak worden uitgewisseld, dan wil men weten of er een relatie is met een andere medicatieafspraak (start- en stop afspraken over dezelfde medicatie), toedieningsafspraak, medicatiegebruik, contact waarin de medicatieafspraak is gemaakt en de zorgepisode. Het is dan niet de bedoeling om alle gegevens over al deze bouwstenen mee te sturen, alleen om welke specifieke instantiaties van deze bouwstenen het gaat. Dit kan worden gedaan door een relatie te leggen naar de identificatie van deze specifieke instantiaties van de bouwstenen middels het Object Identifier (OID).
Het OID nummer is samengesteld uit een deel met de identificatie van de uitgevende organisatie – de zorgaanbieder van waaruit gegevens worden verstuurd – en een deel met de identificatie van een uniek gegeven dat is opgeslagen in het informatiesysteem van deze zorgaanbieder. Voor meer uitleg hierover zie de informatie op de HL7 site.
Hieronder de uitwerking van dit voorbeeld, waarin de relaties naar de OID’s van andere bouwstenen oranje zijn omkaderd:

[[File:Opstellen_dataset_paragraaf2.2.4png.png|576×254px]]

Om een volledig overzicht te hebben van alle relaties tussen informatiebouwstenen en gegevenselementen in een dataset, is het zeer aan te bevelen om een datamodel te maken voor elke usecase.

'''2.2.5 Invoegen en verwijderen dataelementen en (waarden in) waardelijsten'''

Zoals in hoofdstuk 2.1.4 reeds is toegelicht kunnen in een dataset ook afzonderlijke dataelementen en/of (waarden in) waardelijsten worden toegevoegd of verwijderd.
Het toevoegen of juist verwijderen van dataelementen – of groepen met dataelementen – binnen een informatiebouwsteen zorgt ervoor dat een informatiebouwsteen specifieker wordt gemaakt. In gegevensuitwisselingen binnen één domein (bijvoorbeeld huisartsen) kan het nodig zijn om specifieke elementen toe te voegen. Als voorbeeld is het toegevoegde dataelement ‘Presentatierol’ in de zib ‘Zorgverlener’ binnen het huisartsendomein.
Een dergelijke toevoeging moet altijd goed worden overwogen, zoals ook al in hoofdstuk 2.1.4 is toegelicht. Dit heeft namelijk ook consequenties voor het HL7 materiaal. Daarbij draagt een toevoeging ten behoeve van één domein niet bij aan standaardisatie van gegevensuitwisselingen over de domeinen heen. Zo zal een ‘Presentatierol’ in een gegevensuitwisseling van een huisarts naar een medisch specialist geen nut hebben.
Verwijdering van één of meerdere gegevenselementen uit een zib of informatiebouwsteen in de dataset wordt gedaan als deze in geen enkele gegevensuitwisseling van de informatiestandaard voorkomt. Belangrijk is wel dat het concept van de zib daarmee niet wordt aangetast; alleen optionele elementen in een zib mogen worden verwijderd.
Ook waardelijsten kunnen in zijn geheel worden toegevoegd of verwijderd, maar ook specifieke waarden ín een waardelijst. Een regelmatig voorkomende situatie is dat een waardelijst in een zib teveel algemene waarden bevat voor een gegevensuitwisseling en/of dat er specifieke waarden ontbreken. In dat geval wordt er een waardelijst op maat gemaakt ter vervanging van de initiële zib-waardelijst. Ook kan het voorkomen dat in een gegevensuitwisseling binnen één domein een aparte waardelijst van gelijke conceptuele strekking kan worden gebruikt. Denk hierbij aan specifieke NHG-tabel waardelijsten zoals NHG-tabel 12 ‘Soort derde’ naast de Vektis AGB AfdelingSpecialismeCodelijst.
In de handleiding voor ART DECOR [Documentatie-ART] is beschreven hoe dit in zijn werk gaat. Door te koppelen aan een dataelement wordt er context gegeven aan hoe een waardelijst wordt gebruikt in gegevensuitwisseling.
Ook kunnen waardelijsten zelf worden opgesteld en ingevoegd worden. In dit geval is het van belang om de termen in deze waardelijst te toetsen bij het Terminologiecentrum. Het Terminologiecentrum zorgt er dan voor dat de termen worden gekoppeld aan termen in codestelsels zoals SNOMED CT of LOINC. In het volgende hoofdstuk wordt hier verder op ingegaan.

===Terminologie in datasets===
Deze paragraaf biedt een werkvoorschrift voor het vastleggen van terminologiekoppelingen in ART-DECOR met een onderbouwing voor de keuze in werkwijze. Het document gaat hoofdzakelijk in op de werkvoorschriften omtrent SNOMED-termen, terwijl er verschillende (inter)nationale terminologiestelsels zijn. Gezien SNOMED het meest complexe stelsel is met de meeste regels, is vooral ten aanzien van SNOMED-terminologiekoppelingen een leidraad nodig om te komen tot consistentie binnen en tussen informatiestandaarden. Tot slot, huidig document gaat uit van ART-DECOR 2. Momenteel biedt ART-DECOR 3 niet dezelfde opties. Bij doorontwikkeling van ART-DECOR 3 zal gekeken worden welke opties noodzakelijk zijn (zie BITS-issues binnen het project ART-DECOR).

'''2.3.1 Terminologiekoppelingen'''

Een dataset wordt gecodeerd via het aanbrengen van terminologiekoppelingen. Dit omvat terminologiekoppelingen bij dataset-concepten en bij waardes in waardelijsten. In de [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn terminologie koppelen] geeft het Terminologiecentrum achtergrondinformatie over de verschillende terminologiestandaarden en worden handvatten geboden voor het uitvoeren van terminologiekoppelingen en het gebruik van terminologie in informatiestandaarden.

'''2.3.1.1 Dataset-concepten'''

Aan een dataset-concept kan een definitiecode via een terminologiekoppeling toegekend worden. In de Leidraad terminologiestandaarden (paragraaf 4.2) zijn de regels terug te vinden om te komen tot een juiste terminologiekoppeling als definitiecode van een dataset-concept. De naam van het dataset-concept zou overeen moeten komen met een beschrijving van het gekoppelde terminologieconcept, die door de beheerder van het stelsel geaccordeerd is (in SNOMED betreft dit een vertaling uit de Nederlandse extensie en in LOINC een vertaling uit de Nederlandse taalset van het Regenstrief). Terminologiekoppelingen van dataset-concept en waardelijst zouden op elkaar afgestemd moeten zijn (via vraag en antwoord of op basis van hoofdcategorie en verfijning). Waar mogelijk dient context gebruikt te worden: een gedetailleerd dataset-concept kan gekoppeld worden aan een generiek terminologieconcept, mits de ontbrekende informatie uit de andere terminologiekoppelingen blijkt.

'''2.3.1.2 Waardelijsten'''

Dataset-concepten kunnen een waardedomein hebben waarin concepten worden benoemd die als waarde kunnen dienen. Deze waardes behorende bij een dataset-concept kunnen op twee manieren vastgelegd worden in ART-DECOR: via de Waardelijst-editor (gecodeerde waardes) of via de Dataset-editor (ongecodeerde conceptnamen). De Waardelijst-editor is best practice. Via de Waardelijst-editor is het waardedomein te definiëren via het koppelen van een waardelijst. Deze waardelijst kan bestaan uit een geheel codesysteem of deel van een codesysteem (referentieset, tabel, etc.), een query van codes in een codesysteem (bijvoorbeeld: ‘is-een-kind-van’) of een selectie van losse codes. Indien het waardedomein is gedefinieerd via een selectie van losse codes, wordt in ART-DECOR tevens terminologie bij de codes vastgelegd. In de overige gevallen haalt de softwareleverancier de terminologie op bij het codesysteem (bij voorkeur via de Nationale Terminologieserver).
Het opbouwen van een lijst met ongecodeerde conceptnamen (via de Dataset-editor) kan als aanzet dienen tot het opbouwen van een lijst met gecodeerde conceptnamen (via de Waardelijst-editor). Indien er vanuit gebruikers behoefte is om in de informatiestandaard aanvullend andere termen op te nemen dan die in het terminologiestelsel staan opgenomen, heeft het voorkeur om hiervoor het veld Omschrijving te gebruiken in plaats van een aanvullende lijst met ongecodeerde conceptnamen. Overigens wordt deze lijst met ongecodeerde conceptnamen niet verwerkt in de technische berichten, maar deze dient door leveranciers separaat opgehaald te worden vanuit ART-DECOR.

'''2.3.2 Terminologievelden'''

ART-DECOR biedt verschillende velden om termen bij een terminologiecode vast te leggen. Dit betreffen de velden Weergavenaam (displayName), Benamingen (designation) en Omschrijving (description).
In de documentatie over ART-DECOR worden deze velden als volgt omschreven:
*displayName: The optional human readable display name for the code for orientation purposes. This display name corresponds to an official display name or synonym for the code in the code system.
*designation: Designations are language dependent display names for the code. For any language there might be multiple, each specifying the type (fully specified name, preferred, synonym, …).
*description: You may add a description for convenience, but should note that most of the time the description here overlaps with the designation/description of the coded concept.
Wat getoond wordt in ADA in het dropdownmenu bij het maken van kwalificatiemateriaal, is afhankelijk van wat ingevuld is in ART-DECOR bij het opbouwen van de waardelijst. Tekst uit het veld description wordt niet getoond in ADA.
Voor de specifieke toepassing van deze velden in zibs en informatiestandaarden is na overleg tussen informatieanalisten, informatiearchitecten van het Zib-centurm, terminologen en HL7-specialisten functie/ doel als volgt gedefinieerd:
*Weergavenaam: Leesbare weergave van de terminologiecode, waarbij de term afkomstig is uit het oorspronkelijke codesysteem. Dit is een hulp ter herkenning voor informatieanalisten, informatiearchitecten, terminologen, HL7-specialisten, softwareontwikkelaars en zorgverleners die betrokken zijn bij de ontwikkeling en het beheer van een zib of informatiestandaard.
*Benaming (volledig gespecificeerde naam): Hulp voor informatieanalisten en terminologen ter validatie van de terminologiekoppeling.
*Omschrijving: Toelichting ter verduidelijking van de betekenis van de gekoppelde terminologiecode, in aanvulling op terminologie uit het oorspronkelijke codesysteem. Dit kan een definitie van de waarde betreffen, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of de userinterfaceterm.

Het opnemen van terminologie in ART-DECOR uit een codesysteem heeft consequenties voor het beheer van een zib of informatiestandaard: bij elke release van een zib of informatiestandaard zal via het TerminologyReport gecontroleerd moeten worden of de terminologie in ART-DECOR nog overeenkomt met de terminologie in het codesysteem (een term kan in de tussentijd, tussen release van een zib of informatiestandaard en een meer recente release van het codesysteem, veranderd zijn in het codesysteem), net zoals gecontroleerd dient te worden of een terminologiecode niet is komen te vervallen.
Bij het vastleggen van terminologie in ART-DECOR kan gebruik gemaakt worden van de selectietool. Met deze tool kan een concept in een codesysteem worden opgezocht en worden opgenomen in de waardelijst. De terminologie is afkomstig uit een lokale kopie van het codesysteem. Terminologie wordt niet automatisch bijgewerkt als deze in het codesysteem verandert.
Indien gebruik gemaakt wordt van de selectietool in ART-DECOR voor het inladen van SNOMED-concepten, wordt voor het veld Weergavenaam de Nederlandse fully specified name ingeladen (indien er een Nederlandse vertaling beschikbaar is) en voor het veld Benamingen de fully specificied name, preferred term en synonyms in de beschikbare talen. Om de best practice uit dit document te volgen, kan het nodig zijn om de ingeladen termen via de selectietool aan te passen.
Gezien er een aantal jaar geleden nog weinig Nederlandse vertalingen van SNOMED beschikbaar waren, kunnen bij terminologiecodes in eerder gepubliceerde zibs en informatiestandaarden nog Engelstalige termen staan. Inmiddels heeft het merendeel van de SNOMED-termen een Nederlandse vertaling. Indien een vertaling toch ontbreekt, dient deze aangevraagd te worden bij het Terminologiecentrum.
Soms maakt het Terminologiecentrum een nieuwe SNOMED-code aan binnen de Nederlandse extensie, wanneer er geen geschikte SNOMED-code is binnen de internationale versie. Deze nieuwe SNOMED-code zal in de meeste gevallen nog niet opgenomen zijn in de huidige gepubliceerde versie van SNOMED op moment van release van de zib of informatiestandaard. In dat geval dient de term bij de terminologiecode handmatig ingevoerd te worden. Let hierbij op dat de Nederlandse SNOMED-termen beginnen met een kleine letter en de Engelstalige SNOMED-termen met een hoofdletter.

'''2.3.2.1 Dataset-concepten'''

'''2.3.2.1.1 Weergavenaam'''

Bij het aanbrengen van een terminologiekoppeling bij een dataset-concept biedt ART-DECOR één veld, namelijk Weergavenaam, om een term in tekst mee te geven bij de code. Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse fully specified name te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een waarde). Er is gekozen voor de volledig gespecificeerd naam, gezien deze term niet alleen een leesbare weergave biedt bij de code, maar tevens validatie van de terminologiekoppeling mogelijk maakt.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2 Waardelijsten'''

'''2.3.2.2.1 Weergavenaam '''

Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse preferred term te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een dataset-concept). Er is gekozen voor de Nederlandse preferred term, gezien deze term het beste aansluit bij het doel van het bieden van een leesbare weergave van de terminologiecode. De fully specificied name in SNOMED bevat een semantic tag, waarbij kennis van SNOMED vereist is om deze te kunnen interpreteren. Bovendien is de fully specified name langer dan de preferred term, wat een onoverzichtelijkere weergave kan betekenen.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2.2 Benamingen'''

Het veld Benaming (type volledig gespecificeerde naam) dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient in dit veld de Nederlandse fully specified name opgenomen te worden. De fully specified name bevat de semantic tag die aangeeft in welke SNOMED-hiërarchie het concept valt, waardoor het mogelijk is om te beoordelen of de terminologiekoppeling correct is (op basis van de semantic tag kunnen bepaalde inconsistenties in een waardelijst in het oog springen, waar anders gemakkelijk overheen gekeken kan worden).
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.
De overige typen Benamingen (type voorkeursterm en type synoniem) dienen niet gevuld te worden. Deze velden vervullen, in tegenstelling tot Benaming (type volledig gespecificeerde naam), geen specifieke functie in het functioneel ontwerp van een informatiestandaard of zib.

'''2.3.2.2.3 Omschrijving'''

Het veld Omschrijving wordt gevuld afhankelijk van de behoeften van de eindgebruikers van de zib of informatiestandaard. In het veld Omschrijving kan tekst meegegeven worden die niet in het codesysteem opgenomen staat. Dit kan een toelichting zijn ter verduidelijking van de betekenis van de gekoppelde terminologiecode in aanvulling op terminologie uit het oorspronkelijke codesysteem, een definitie van de waarde, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of (suggestie voor) de userinterfaceterm. Dit veld is daarmee een hulp voor ontwikkelaars om te komen tot een geschikte benaming in de userinterface.
Indien het veld Omschrijving een userinterfaceterm bevat, hebben informatieanalist/informatiearchitect en terminoloog gevalideerd dat deze term en gekoppelde terminologiecode overeenkomen in betekenis binnen de context van de waardelijst. Een userinterfaceterm kan specifieker zijn dan de term in het codesysteem door de context die de waardelijst meegeeft, of juist meer generiek, doordat de context van de waardelijst een specifieke benaming van de waarde overbodig maakt.
Indien er met de betrokken partijen afgesproken is dat het beheer van de gebruikte terminologie van een waardelijst binnen de informatiestandaard valt, waarbij er afspraken gemaakt zijn over de letterlijke term die op de gebruikersinterface getoond dient te worden, is dit veld onderdeel van de kwalificatie.
2.3.3 Het maken van gespecialiseerde waardelijsten
Zoals in 2.2.5 is benoemd kan het nodig zijn om een waardelijst van een geërfde bouwsteen te vervangen door een gespecialiseerde waardelijst. In het geval dat er een beperkt aantal concepten aan de oorspronkelijke waardelijst moeten worden toegevoegd of juist verwijderd zijn er twee alternatieven:
*Een kopie maken van de waardelijst van de geërfde bouwsteen en deze bewerken. De relatie van de nieuwe waardelijst met de oorspronkelijke waardelijst gaat verloren. Wijzigingen in de oorspronkelijke waardelijst worden niet doorgevoerd op de gespecialiseerde waardelijst. Je kiest hiervoor als de gespecialiseerde waardelijst niet lijkt op oorspronkelijke waardelijst, bijvoorbeeld omdat de gespecialiseerde waardelijst een opsomming is van mogelijke waarden en de oorspronkelijke een codestelsel, of een deel van een codestelsel gespecificeerd met een intensionele expressie.
*De waardelijst van de geërfde bouwsteen includeren in de gespecialiseerde waardelijst. Hierbij blijft de relatie met de oorspronkelijke waardelijst zichtbaar. Dit kan op twee manieren:
*Statische inclusie: een specifieke versie van de waardelijst wordt geïncludeerd (deze zal niet meer wijzigen)
*Dynamische inclusie: de laatste versie van de waardelijst wordt geïncludeerd. Doorgaans wordt bij een gespecialiseerde lijst geen dynamische inclusie toegepast. Maar indien hier wel voor is gekozen, moet ervoor wordt gewaakt of de inclusie en de zelf toegevoegde waarden inderdaad volledig disjunct zijn en blijven zodat er geen dubbelingen ontstaan. Het alternatief is om de eigen toevoegingen mee te laten nemen in de volgende release van een waardelijst.
De extra concepten, nodig voor de specialisatie, kunnen los worden toegevoegd of met Inclusies. Bij deze laatste methode moet een intentionele expressie worden ingevuld. Concepten uit de waardelijst van de geërfde bouwsteen die juist niet gewenst zijn in de gespecialiseerde waardelijst, kunnen met exclusies worden uitgesloten (ook weer met intentionele expressie).

===Generieke modelering – afspraken===

In hoofdstuk 2.2.4 is uitgelegd dat er tussen de verschillende bouwstenen en/of dataelementen in bouwstenen relaties kunnen worden gelegd. Deze relaties geven context aan of nadere aanvulling van gegevens. In het kader van standardisatie van gegevensuitwisseling niet alleen binnen één informatiestandaard maar ook in standaardisatie tussen alle informatiestandaarden is het belangrijkom dit soort relaties op een zoveel mogelijk eenduidige manier te doen. Als in alle informatiestandaarden op dezelfde manier relaties en modeleringen van gegevens worden gemaakt, is het voor de informatieanalisten veel eenvoudiger om te bepalen wat er in de verschillende informatiestandaarden aan gegevens worden uitgewisseld en hoe dit op elkaar aansluit. Evenzo belangrijk is dat de technische specificaties in HL7 berichten veel meer generiek kunnen worden uitgewerkt.

==Samenstellen scenario’s==

Een Nictiz informatiestandaard bevat minimaal één maar meestal meerdere usecases. Een usecase is een beschrijving van een informatie-uitwisseling op een specifiek moment in het zorgproces, waarbij voor een concrete praktijksituatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Zoals eerder gemeld staan alle usecases van één informatiestandaard beschreven in een functioneel ontwerp.
De specifieke gegevens die worden uitgewisseld binnen elk van de usecases zijn een subset van de dataset voor een gehele informatiestandaard. Daarom moet voor elke usecase een datascenario worden aangemaakt. In dit hoofdstuk wordt verder ingegaan op de keuzes en mogelijkheden voor het samenstellen van een datascenario.
N.B.: In dit document wordt consequent de term ‘datascenario’ gebruikt in plaats van de term ‘scenario’ zoals dat wordt gebruikt in ART DECOR. De reden is dat ‘scenario’ een term is die breed kan worden opgevat en daarom met verschillende betekenissen in velerlei documentatie wordt gebruikt. ‘Datascenario’ geeft meer context aan de betekenis voor dit document.

===Usecase en datascenario===
In principe wordt er voor elke usecase binnen een informatiestandaard een datascenario samengesteld. De naamgeving van een datascenario volgt veelal de hoofdlijn van elke usecase. Bijvoorbeeld in de informatiestandaard Acute zorg is er de usecase ‘Uitwisseling ambulance naar SEH’ waarvoor het datascenario ‘AMB (ambulance) draagt over aan SEH (Spoedeisende hulp)’ is samengesteld.
Het kan voorkomen dat de inhoud van de gegevensuitwisseling voor meerdere usecases binnen één informatiestandaard hetzelfde is. In dit geval wordt er voor meerdere usecases één datascenario samengesteld, waarbij in de naamgeving van het datascenario de meerdere usecases worden benoemd. Rugten naar ‘scenario

===Datascenario, transactiegroepen en transacties===
Elk datascenario is opgebouwd uit één of meerdere transactiegroepen. Een transactiegroep bevat alle transacties die bijdragen aan één specifieke gegevensuitwisseling tussen twee partijen.
Vaak is het zo dat binnen één datascenario ook maar één transactiegroep wordt gebruikt maar het is evengoed mogelijk om binnen één datascenario meerdere transactiegroepen te gebruiken, dit wordt verderop in dit hoofdstuk toegelicht.
Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.
Elke transactiegroep kan weer één of meerdere transacties bevatten. Een transactie is een werkelijke overdracht van gegevens.
Een transactiegroep waarin berichten worden verstuurd, bevat doorgaans een transactie met de verstuurde gegevens en een transactie met de ontvangstbevestiging. Dit zijn een zogenaamde push-transacties: overdrachten van gegevens waarbij de verzender op eigen initiatief een bericht verstuurt en waarbij de ontvanger dit bericht ontvangt zonder dat daarvoor actief naar is gevraagd.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het versturen van een specifieke gegevensset, ofwel dat het gaat om een ontvangstbevestiging. Vaak wordt deze transactie als overbodig beschouwd en daarom achterwege gelaten.

Een transactiegroep waarin gegevens worden geraadpleegd, bevat doorgaans een transactie met de raadpleging op maat en een transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Dit is een zogenaamde pull-transactie: een overdracht van gegevens waarbij de ontvanger van deze gegevens actief om heeft gevraagd en waarbij de verzender deze gegevens beschikbaar heeft gesteld.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het raadplegen van een specifieke gegevens set, ofwel dat het gaat om het beschikbaarstellen van de geraadpleegde gegevens.
Zoals eerder gemeld kan er in een transactiegroep in plaats van één transactie met alle benodigde gegevens ook worden gekozen voor het toepassen van meerdere transacties voor het versturen van gegevens: bijvoorbeeld één transactie per (zorginformatie-)bouwsteen. Deze constructie kan worden toegepast als er één datascenario wordt gebruikt voor meerdere usecases, waarbij het merendeel van de verstuurde gegevens gelijk is, maar waar er per usecase soms wel of niet een extra bouwsteen moet worden meegestuurd. Een voorbeeld hiervan is het opvragen van de professionele samenvatting door meerdere raadplegende partijen in de acute zorg – de meldkamer, ambulance en de SEH – waarbij de meldkamer geen gegevens over overgevoeligheden wil ontvangen. In dit geval is er geen transactie met de bouwsteen voor overgevoeligheden.
Als voorbeeld voor de hierboven beschreven samenstelling van datascenario’s met transactiegroepen en push- en pull-transacties dient wederom de informatiestandaard voor acute zorg. met hieronder een aantal usecases waarvoor datascenario’s zijn samengesteld met push-transacties, zoals:
*Berichten van de ambulance naar de SEH
*Verwijzen van een patiënt van (waarnemend) huisarts naar de meldkamer
*Versturen rapportages van meldkamer, ambulance en SEH naar de huisarts
In het plaatje hieronder is een uitwerking van het datascenario voor berichten van de ambulance naar de SEH:

[[File:Opstellen_dataset_paragraaf_3.2a.png|576×254px]]

En een drietal usecases waarvoor één datascenario is samengesteld met pull-transacties:
*Opvragen van de professionele samenvatting bij de huisarts door de meldkamer, ambulance of SEH

[[File:Opstellen_dataset_paragraaf_3.2b.png|576×254px]]

In ART-DECOR worden de transacties binnen een datascenario gegroepeerd tot een transactiegroep. In datascenario’s waarin berichten worden verstuurd, bestaan een transactiegroep uit de transactie met verstuurde gegevens en de transactie met de ontvangstbevestiging. In datascenario’s waarin gegevens worden geraadpleegd bestaat de transactiegroep uit de transactie met de raadpleging op maat en de transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.

===Transactiedataset===
Per transactie wordt er een specifieke set gegevens verstuurd van de verzender naar de ontvanger. In een transactiedataset is dit gedetailleerd uitgewerkt. Alle gegevenselementen en (delen van) zibs en/of informatiebouwstenen n een transactiedataset worden betrokken uit de informatiestandaard dataset zoals beschreven in hoofdstuk 2. Andersom kan ook worden gezegd dat alle transactiedatasets van de transacties als onderdeel van een transactiegroep, die op hun beurt weer onderdeel zijn van een datascenario, tezamen de informatiestandaard dataset vormen.

'''3.3.1 Cardinaliteit en conformance'''
In een transactiedataset wordt per gegevenselement ook de kardinaliteit aangegeven. Op de informatiepagina van het zib-centrum is uitgelegd wat kardinaliteiten zijn: https://zibs.nl/wiki/Zib_kardinaliteiten
In informatiemodellen wordt kardinaliteit gebruikt om de multipliciteit van een element ten opzichte van zijn parent – of als het een top level element is, de multipliciteit van de boom eronder - in een transactie aan te geven. Daarbij wordt de notatie ‘m..n’ gebruikt, waarbij ‘m’ de minimale multipliciteit is en ‘n’ de maximale. In het model wordt de kardinaliteit genoteerd bij het element waarvoor dit geldt. Dus als er tussen element A en element B en relatie bestaat en bij element B de kardinaliteit m..n staat, betekent dit dat een element A minimaal met ‘m’ elementen B een relatie heeft en maximaal met ‘n’ elementen B
Naast de multipliciteit wordt met een letter aangegeven of deze relatie Mandatory, Required, Conditional of Optional is:

{| class="wikitable"
! M (Mandatory)
|Een gegeven moet altijd worden aangeleverd. De minimale multipliciteit is dan ook 1..1M
|-
! R (Required)
| Indien een gegeven beschikbaar is, moet deze worden aangeleverd. Bijvoorbeeld als één of meerdere voornamen van een patiënt bekend zijn. De kardinaliteit is in dit geval 0..*R
|-
! C (Conditional)
| Een gegeven dat moet worden aangeleverd, afhankelijk van de waarde of aanwezigheid van een ander gegeven. Bijvoorbeeld de invulling van een toelichting indien in een waardelijst de optie ‘Anders’ is geselecteerd. De kardinaliteit van de toelichting is in dit geval 1..1C
|-
! O (Optional)
| Een gegeven dat eventueel kan worden aangeleverd maar niet noodzakelijk. Deze optie wordt vrijwel niet toegepast. Als een gegeven niet noodzakelijk is binnen een overdracht, wordt deze in de regel ook niet opgenomen in een informatiestandaard.
|}

De kardinaliteiten zoals vastgesteld in de transactiedatasets zijn functioneel leidend. Op basis hiervan kan worden afgeleid wat er in een gegevensoverdracht aan gegevens moet worden meegestuurd. Een verzendende partij weet welke gegevens er moeten worden opgeleverd, al dan niet verplicht, verplicht indien beschikbaar of conditioneel. Een ontvangende partij weet wat er aan gegevens moet worden verwerkt en getoond kunnen worden.
Let op: de kardinaliteit in zibs zijn conceptueel; het kan dus voorkomen dat een kardinaliteit van een gegeven in een transactiedataset enger is als die in een zib. Dit geldt ook voor de kardinaliteiten in HL7v3 tempates en FHIR profielen; deze kunnen minder eng zijn als die in een transactiedataset.
Andersom is conceptueel niet mogelijk. Als iets conceptueel verplicht is of in bijvoorbeeld een FHIR profiel verplicht staat (zoals 1..1M), is het niet mogelijk om in de functionele transactiedataset hier geen verplichting aan te geven (zoals 0..1R).
Zoals in hoofdstuk 2.3.3 en 2.3.4 is uitgelegd kunnen in een dataset – en dus ook in een transactiedataset – verwijzingen en relaties voorkomen. Ook deze kennen kardinaliteiten. Bij verwijzingen geldt dat de bron-bouwsteen waar naar verwezen wordt in de dataset, ook in de transactiedataset moet voorkomen. De kardinaliteit van deze bron-bouwsteenen alle gegevens daarbinnen geldt dat voor alle contexten met verwijzingen. Als voorbeeld is wederom de LaboratoriumUitslag van hoofdstuk 2.3.3:

[[File:Opstellen_dataset_paragraaf_3.3.1.png|576×254px]]

Hierbij geldt dat in de bouwsteen LaboratoriumUitslag de kardinaliteit van de context – LaboratoriumUitslagVerantwoordelijke, Aanvrager en Uitvoerder – aangeeft hoe elk van deze contexten in het bericht moeten worden meegenomen. In dit geval dus alle drie verplicht. De kardinaliteit van de verwezen bouwstenen onder de context geeft aan dat áls er bijvoorbeeld een Uitvoerder is, dat dan de verwezen Zorgverlener óf Zorgaanbieder aanwezig moet zijn (vandaar de kardinaliteit van beiden 0..1 R). Bij de Aanvrager is er maar één mogelijkheid – de Zorgverlener – en vandaar dat deze dan ook mandatory is.
In de verwezen bron-bouwsteen Zorgverlener gelden vervolgens de kardinaliteiten zoals hierin is opgezet.

'''3.3.2 Raadplegen: Query Parameters'''

Voor de transactieset waarin gegevens worden opgevraagd door een partij (PULL), is vaak een selectie op de gegevens van toepassing.

Dit kan op twee manieren zijn ingericht in ART DECOR:
*Vooraf vastgestelde selectie: als onderdeel van de transactie beschikbaarstellen
*Variabele selectie: als query parameter in de transactie raadplegen

De eerst genoemde situatie is vooral van toepassing wanneer er landelijke afspraken zijn dat er altijd een standaard selectie wordt toegepast. Dit zorgt ervoor dat altijd eenzelfde overzicht voor een patiënt wordt gegenereerd. Bijvoorbeeld in de BgZ, is de “laatst bekende bloeddruk” in beschikbaarstellen opgenomen als 0..1 conditioneel:

[[File:Opstellen_dataset_paragraaf_3.3.2a.png|576×254px]]

De laatst genoemde situatie met query parameters, is van toepassing wanneer het nodig is een specifieke selectie per individuele raadpleging te maken. Bijvoorbeeld; de eindgebruiker van een systeem geeft zelf aan voor welke patiënt en in welke periode er informatie opgevraagd wordt. Welke gegevens als query parameters gebruikt kunnen worden, is afhankelijk van de usecase. Vaak zal er een identificatie(nummer) uit de Patiënt zib gebruikt worden zodat de raadpleging gericht voor één persoon plaats vindt.
In ART-DECOR dit worden ingericht, door in de dataset een groep “QueryParameters” op te nemen en dan de relevante parameters in de transactie(s) Raadplegen te gebruiken. Een parameter kan gebruik maken van een gegevenselement uit 1 bouwsteen, bijv. het identificatienummer van de Patiënt. Een andere mogelijkheid is dat een parameter gebruik maakt van 1 type gegeven die op meerdere plaatsen in de dataset voor komt, bijv. een datum(periode) waarin meerdere metingen (zoals bloeddruk, gewicht en lengte) uitgevoerd kunnen zijn.
Om duidelijk te maken aan wélke gegevens de parameters gelinkt zijn, kan je de in de dataset dit toelichten in de naam en omschrijving van de query parameter. Ook de zoekwijze kan je hier toelichten, zoals voor periodes waarin gezocht kan worden. Als daarnaast per transactie nog aparte regels gelden, kan je dit via het veld context bij de transactie uitleggen (en/of via een Conditie indien dit van toepassing is).
Als voorbeeld hieronder een weergave van de Gebruiksperiode in de transactie Raadplegen medicatieafspraak (MP 2.0.0): voor de gebruiksperiode is in de omschrijving van het concept aangegeven op welke conceptgroepen uit de dataset (“MA, WDS en TA”) de periode van toepassing is. Voor de transactie is dan ook nog een conditie opgenomen ter nadere specificatie.

[[File:Opstellen_dataset_paragraaf_3.3.2b.png|576×254px]]

=Release notes=
In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Instructie opstellen dataset

2025-08-26T08:12:19Z

Lilian Brouwer: /* Transactiedataset */

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Instructie opstellen dataset 3.0.0 {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__

==Inleiding==
Dit document beschrijft de ‘best practices’ bij het opstellen van een dataset, behorende bij een informatiestandaard. Deze ‘best practices voor Nictiz datasets’ is de richtlijn voor iedereen die zich bezighoudt met het opstellen en beheren van datasets. Door op een eenduidige wijze deze datasets samen te stellen, wordt de uitwisselbaarheid in (delen van) datasets verbeterd en wordt het voor beheerders van datasets ook eenvoudiger om datasets die zijn opgesteld door collega’s, inzichtelijk te krijgen. Hiermee wordt ook getracht om de mapping van met name de datascenario’s op de HL7 berichten (HL7v3 templates en FHIR-profielen) te vereenvoudigen.
Daarnaast is de uniformiteit in de samenstelling van datasets van groot belang voor externe partijen – met name zorginstellingen en hun ICT-leveranciers die met behulp van de datasets en datascenario's de gegevensuitwisselingen conform de Nictiz informatiestandaarden moeten implementeren.
Voor de leesbaarheid en de juiste context van begrippen zijn een aantal relevante definities hieronder ingevoegd. Deze komen vanuit de
[https://nictiz.nl/standaarden/begrippen/ Nictiz begrippenlijst] of zijn er aan toegevoegd (met de intentie om deze alsnog op te nemen in de begrippenlijst):

{| class="wikitable"
! Begrip
! Definitie
|-
| Richtlijn
| Beschrijving die verduidelijkt wat behoort te worden gedaan en hoe, om de doelstellingen te bereiken die in het beleid zijn vastgelegd (NEN 7510)
|-
| Functioneel ontwerp
| In een Nictiz functioneel ontwerp worden alle eisen en wensen voor alle usecases (ook wel uitwisselscenario’s genoemd) binnen één informatiestandaard verzameld en geordend. Per usecase wordt beschreven op welke manier dat gebeurt: tussen welke gebruikers vindt de gegevensuitwisseling plaats, welke handelingen worden daarbij uitgevoerd en welke resultaten leveren deze op.
|-
| Usecase
| Een beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het vastleggen en/of uitwisselen van
|-
|
| informatie wordt beschreven aan de hand van actoren (mensen, informatiesystemen) en transacties (welke informatie wordt wanneer uitgewisseld).
|-
| Dataset
| Een dataset bevat definities van alle gegevens die binnen de context van een specifiek zorgproces en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Deze definities zijn functioneel van aard en worden vastgesteld door het zorgveld. Voor specifieke transacties binnen het zorgproces wordt gebruik gemaakt van een subset van de gegevens uit deze dataset (het datascenario).
|-
| Zib
| Zorginformatiebouwstenen (zibs) worden gebruikt om inhoudelijke (niet technische) afspraken vast te leggen ten behoeve van het standaardiseren van informatie, die gebruikt wordt in het zorgproces. Het doel van de standaardisatie is dat deze informatie uit het zorgproces wordt hergebruikt voor andere doeleinden, zoals kwaliteitsregistraties, overdracht, patiëntgebonden onderzoek. Een zorginformatiebouwsteen is een informatiemodel, waarin een zorginhoudelijk concept wordt beschreven in termen van de gegevenselementen waaruit dat concept bestaat, de datatypes van die gegevenselementen etc.
|-
| Informatiebouwsteen
| Een concrete voorziening, standaard, afspraak of arrangement, met een eigenaar, beheerder, financiering et cetera die bovensectoraal of zorgbreed (her)gebruikt kan worden.
|-
|
| Informatiebouwstenen kunnen zijn (opgebouwd uit) zibs en/of opgebouwd uit gegevenselementen.
|-
| Dataelement / gegeven
| Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
|-
| Scenario
| De representatie van een usecase in ART DECOR waarin de actoren en een specifieke subset gegevens uit de dataset (transactiedataset) zijn uitgewerkt.
|-
| Transactiegroep
| Een model van een verzameling van gegevens die wordt overgedragen tussen actoren (personen of systeemrollen) binnen één usecase. Een transactie wordt schematisch weergegeven door de uitwisseling van een transactiedataset tussen twee actoren.
|-
| Transactiedataset
| Een subset van gegevens uit de dataset voor een specifieke transactie met kardinaliteiten en conformiteiten.
|-
| Intensionele waardelijst en expressie
| Zie 2.3.2

Een intentionele waardelijst geeft niet direct aan welke directe waarden je moet hebben, maar alleen een intentie geeft voor elke waarde erin in thuishoort. Dit doe je door een intentionele expressie (dat in feite een query is), zoals :

< T : alle waarden onder T

of

<< T : T en alle waarden daaronder

of

< T1

OR

< T2 : alle waarden onder T1 of T2
N.B. Daarnaast kun je waardes in de intentionele expressie ook excluderen
|}

===Doelstelling===
Het eerste doel van dit document is het bevorderen van inzicht in hoe een dataset wordt samengesteld. De richtlijnen en methoden voor het samenstellen van een dataset worden in dit document nader toegelicht.
Het tweede doel van dit document is het bevorderen van inzicht in hoe een datascenario wordt samengesteld vanuit een dataset. De richtlijnen en methoden voor het samenstellen van een datascenario worden in dit document nader toegelicht.

===Scope van dit document===
Dit document geeft definities van een dataset, zib, informatiebouwsteen, data-element en een datascenario. Ook wordt uitgelegd hoe een dataset en een datascenario op een eenduidige wijze moet worden samengesteld. De verschillende methoden die hiervoor gebruikt worden, zijn nader beschreven.
Dit document kan als een richtlijn worden beschouwd voor wijze waarop binnen Nictiz datasets en datascenario’s worden samengesteld. Ook voor beheer van reeds bestaande datasets en datascenario’s is deze richtlijn van toepassing.

===Buiten scope van dit document===
Een dataset bevat definities van alle gegevens die in een specifieke context binnen het zorgproces, en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Voor elke usecase moeten door betrokken partijen afspraken gemaakt worden over de inhoud van de te gebruiken gegevens – het datascenario. De definities die van toepassing zijn in het zorgproces zijn functioneel van aard en worden vastgesteld door de zorgverleners in een functioneel ontwerp en daarmee buiten de scope van dit document.
Eveneens buiten scope is een uitleg van de tooling waarmee datasets worden samengesteld en gepresenteerd. Hiervoor wordt verwezen naar ART DECOR [https://decor.nictiz.nl/wiki/index.php/Ontwikkelaars#Proces_ontwikkelen_DECOR-project, https://simplifier.net/, Zibs 2017: https://simplifier.net/NictizSTU3-Zib2017, http://www.art-decor.org]. Echter, vanwege praktische redenen worden in dit document afbeeldingen gebruikt van (delen van) datasets en datascenario’s in ART DECOR om beschrijvingen nader toe te lichten.
Dit document is gericht aan inhoudelijke experts op het gebied van Nictiz informatiestandaarden (informatieanalisten, product managers, Specialisten gegevensuitwisseling, etc.) waarvan wordt verondersteld dat men bekend is met de gebruikte terminologieën, tooling, documentatie, etc.. Deze worden daarom niet verder toegelicht en beschreven in dit document.

==Samenstellen datasets==

===Richtlijnen voor het samenstellen van datasets===
Voor het opstellen van een dataset gelden een aantal basisprincipes. In het kort komt dit neer op de volgende punten:
*Zoveel mogelijk gebruik maken van de meest recent gepubliceerde zibs
*Indien geen zibs beschikbaar, bekijk reeds bestaande datasets, CIMS en/of kandidaat-zibs op de aanwezigheid van informatiebouwstenen die toegepast kunnen worden in de nieuwe dataset
*Conformeer zoveel mogelijk aan het zorgproces, de informatiestandaard (op basis van richtlijnen en functioneel ontwerp) maar ook aan de gegevensmodellen van de zibs en informatiebouwstenen
*Voeg alleen dataelementen en (waarden in) waardelijsten toe als deze niet worden gerepresenteerd door reeds beschikbare dataelementen en (waarden in) waardelijsten in zibs en/of informatiebouwstenen
*Conformeer zo veel mogelijk aan de generieke volgorde van zibs en informatiebouwstenen in een dataset
In dit best practice document wordt in de subhoofdstukken hierna voor elk van deze punten beschreven wat dit betekent voor de daadwerkelijke samenstelling van een dataset.

'''2.1.1 Meest recent gepubliceerde zibs'''

Over het nut en noodzaak van zibs is reeds de nodige literatuur [https://zibs.nl/wiki/Hoofdpagina beschikbaar]. Door voortschrijdend inzicht en met inbreng van vele stakeholders worden zibs middels een strikt nageleefd beheerproces aangepast. Bij het samenstellen van een nieuwe dataset is het dan ook van groot belang om de meest recent gepubliceerde zibs te gebruiken.
In ART-DECOR zijn alle zibs van de meest recente publicatie beschikbaar en kunnen worden gebruikt als informatiebouwsteen om een dataset mee samen te stellen. Door zoveel mogelijk gebruik te maken van de zib concepten, kan informatie in alle afzonderlijke zorgtoepassingen op dezelfde manier worden vastgelegd (tussen de zender en ontvanger) en blijft de betekenis gelijk.
Zibs zijn concepten die zorgbreed kunnen worden toegepast. Het kan daarom voorkomen dat in specifieke gegevensoverdrachten in een bepaald domein een aanvulling op dit concept nodig is. Bijvoorbeeld extra dataelementen of waardelijsten die niet in de zibs zijn opgenomen. Ook kan het voorkomen dat binnen een dataset slechts een deel van de zib wordt gebruikt. Elementen van een zib kunnen daarom ook worden verwijderd, zolang dit het conceptuele model van de zib niet compromitteert.

'''2.1.2 Informatiebouwstenen'''

Naast zibs kunnen ook informatiebouwstenen worden gebruikt bij het samenstellen van een dataset. Informatiebouwstenen kunnen zibs zijn met een aantal toevoegingen of verwijderingen van dataelementen en/of waardelijsten, detailed clinical models (DCM’s) die geen zibs zijn of nog kandidaat-zibs zijn (zie ook ‘Zorginformatiebouwstenen – Richtlijnen bij afwezigheid van zib’s’) of een zelf opgebouwde informatiebouwsteen. Vaak zijn deze informatiebouwstenen voor één of hooguit enkele zorgdomeinen van toepassing, in tegenstelling tot zibs die zorgbreed toegepast kunnen worden.
Bekijk daarom ook functioneel ontwerpen en informatiebouwstenen in datasets van andere informatiestandaarden om te bepalen of er, al dan niet gedeeltelijke, overlap is met betrekking tot de inhoud van de gegevensuitwisseling. Door hergebruik van informatiebouwstenen worden ook gegevensuitwisselingen die niet met zibs kunnen worden gemodelleerd, zoveel mogelijk gestandaardiseerd.

[[File:Opstellen_dataset_paragraaf2.1.png|576×254px]]

Hoe een zib in een bepaalde zorgsituatie (usecase) wordt gebruikt is vastgelegd in een informatiestandaard. Een informatiestandaard voegt context en relaties toe aan de zib gegevensmodellen en beschrijft in welke zorgsituatie je welke gegevens vastlegt en uitwisselt [zie ook https://www.nictiz.nl/standaardisatie/informatiestandaarden/].

'''2.1.3 Zorgproces, informatiestandaard en gegevensmodellering'''

Vanzelfsprekend zijn het zorgproces en kwaliteitstandaarden/richtlijnen de leidraad voor wat er in de dataset moet worden toegevoegd aan zibs, informatiebouwstenen en/of dataelementen en waardelijsten. Vaak wordt er bij het samenstellen van de dataset en meer nog het datascenario (zie het hoofdstuk Samenstellen datascenario) ruggespraak gehouden met experts uit het zorgveld. Deze dataexperts kunnen waardevol inzicht verschaffen bij het ‘fijnslijpen’ en completeren van een dataset en de datascenario’s. Hierbij dient er wel scherp op gelet te worden dat de dataset samenstelling er is voor interoperabiliteit en niet voor het modelleren van systemen.

'''2.1.4 Toevoegen dataelementen en waardelijsten'''

In een dataset kunnen ook ‘losse’ dataelementen en specifieke waardelijsten worden toegevoegd. Meestal worden deze dataelementen en/of waardelijsten toegevoegd aan onterfde zibs en/of informatiebouwstenen om deze op maat te maken voor een specifieke informatiestandaard, zie ook Methoden voor samenstellen datasets bij subhoofdstuk 2.2.5 Invoegen en verwijderen dataelementen en waarden in waardelijsten. In een enkel geval kunnen dataelementen ook rechtstreeks in een dataset worden ingevoegd.
Er moet goed worden overwogen welke gevolgen dit heeft voor de datascenario’s en onderliggende HL7-berichten. Ook moet er scherp op gelet worden dat eventuele toevoegingen van dataelementen en (waarden in) waardelijsten complementair zijn aan de reeds beschikbare gegevens in de zibs en niet als vervanging voor terminologie.

'''2.1.5 Volgordelijkheid (zorg)informatiebouwstenen en dataelementen in dataset'''

Naast dat datasets de verzameling zijn van alle gegevens in alle datascenario’s, zijn datasets ook bedoeld om een overzicht te bieden aan Nictiz collega’s en externe dataexperts. Door een zoveel mogelijk gestandaardiseerde volgorde van zibs en informatiebouwstenen aan te houden in een dataset, wordt er een beter overzicht gecreëerd. Ook is het mogelijk om bepaalde segmenten toe te passen, zoals een groep ‘bundel’ of ‘bouwstenen’ waarbinnen de (zorg)informatiebouwstenen zijn ondergebracht waarnaar wordt verwezen vanuit andere delen van de dataset.
Een strak gereguleerde volgordelijkheid van informatiebouwstenen in alle informatiestandaard-datasets is lastig te realiseren. Het voornaamste is dat Nictiz collega’s en externe partijen op een zo eenvoudig en intuïtief mogelijke wijze de samenstelling van een dataset goed kunnen overzien.
Hieronder is een voorbeeld als leidraad voor een volgordelijkheid van zibs en informatiebouwstenen in een dataset:
*Patiënt
*Zorgverlener
*Zorgaanbieder
*Contactmomenten
*Zibs en informatiebouwstenen m.b.t. triage, diagnose
*Zibs en informatiebouwstenen m.b.t. behandeling en verrichting
*Zibs en informatiebouwstenen m.b.t. uitslagen en verslaglegging
*Zibs en informatiebouwstenen voor specifieke onderwerpen in een usecase
Echter, het is mogelijk dat deze volgordelijkheid in bestaande en nieuwe datasets in ART DECOR niet is toegepast. Vooral de wat oudere datasets zijn hierin soms afwijkend. En regelmatig zijn er in datasets de eerder genoemde segmenten gebruikt waarbij zibs en informatiebouwstenen in een groep zijn samengevoegd, zoals “Demografie en identificatie” met zibs Patiënt, Contactgegevens en BurgerlijkeStaat of “Sociale Anamnese” met zibs Woonsituatie, Taalvaardigheid, ParticipatieInMaatschappij en HulpVanAnderen.

===Methoden voor samenstellen datasets===
Datasets kunnen met verschillende methoden worden samengesteld:
*Erven (zibs en informatiebouwstenen)
*Onterven (na eerst te hebben geërfd)
*Verwijzen
*Relaties maken tussen informatiebouwstenen
*Invoegen en verwijderen dataelementen en (waarden in) waardelijsten
In dit best practice document wordt elk van deze methoden beschreven, alsook een uitleg over welke methode te gebruiken in bepaalde situaties.

'''2.2.1 Erven'''

Binnen ART-DECOR kan een zib of een informatiebouwsteen uit een andere dataset in de eigen dataset worden geërfd. Erven houdt in dat alle gegevenselementen van een zib of informatiebouwsteen, inclusief de onderlinge samenhang (structuur), worden gekopieerd en toegevoegd in de nieuwe dataset.

'''2.2.2 Onterven'''

Een geërfde zib of (zelf ontwikkelde) informatiebouwsteen dient in veel gevallen nog te worden aangepast. Er kunnen gegevenselementen aan worden toegevoegd of juist verwijderd (hoofdstuk 2.2.5). Ook kunnen er relaties worden toegevoegd, zoals wordt beschreven in hoofdstuk 2.2.4 – Relaties binnen datasets. Om dit te kunnen doen, dient een overerfde zib of informatiebouwsteen te worden onterfd, alvorens wijzigingen te kunnen doorvoeren.
Op deze manier ontstaan nieuwe informatiebouwstenen, welke volledig naar informatiebehoefte zijn gemaakt maar waarbij toch zoveel mogelijk de generieke zibs blijven behouden. Hierbij geldt wel dat alleen optionele elementen uit een zib kunnen worden verwijderd en niet de elementen die de kern van een concept omvatten; alleen dan is een nieuwe bouwsteen compatibel met oorspronkelijke zib.
Om in een dataset meer duiding te geven aan de toepassing van een zib, kan na onterven de naamgeving van een zib worden hernoemd. Als voorbeeld: in de dataset voor de informatiestandaard Geboortezorg wordt de zib Probleem twee keer toegepast maar elk in een andere context. Daarom is de zib Probleem voor de twee contexten hernoemd naar respectievelijk ProbleemKind en ProbleemMoeder. In de referentie van de zib is nog steeds zichtbaar dat voor elk van de twee contexten de zib Probleem de basis is.
Edoch, middels het plaatsen van een zib in een datagroep met een context kan ook duiding worden gegeven aan de specifieke toepassing van een zib in een dataset. Dit is beschreven in paragraaf 2.2.3 Verwijzingen. Uit oogpunt van herkenning van het gebruik van zibs en het gebruik van ADA is de voorkeur om datagroepen met context te gebruiken boven het hernoemen van zibs.

'''2.2.3 Verwijzingen'''

In een dataset kan een verwijzing vanuit een informatiebouwsteen naar een andere informatiebouwsteen of losse gegevenselementen worden gemaakt. Dit wordt gedaan wanneer een generieke informatiebouwsteen – in de meeste gevallen een zib – binnen een dataset meerdere keren op de zelfde wijze wordt gebruikt. Bij een verwijzing worden dus de gegevens van de informatiebouwsteen waar naar verwezen wordt ook opgenomen binnen de informatiebouwsteen van waaruit verwezen wordt. Door de verwijzing te maken in een datagroep met een specifieke context, zijn de gegevens vanuit de verwezen bouwsteen daarmee ook van toepassing op deze context.
Hieronder is een voorbeeld van de zib Labuitslag waarin gegevens over de laboratoriumverantwoordelijke, aanvrager en de uitvoerder zijn opgenomen. Voor drie verschillende contexten wordt steeds de zib Zorgverlener gebruikt; elk dus met een specifieke context. Hieronder de uitwerking van dit voorbeeld in ART DECOR, in blauw omrand:

[[File:Opstellen_dataset_paragraaf2.2.png|576×254px]]

In dit voorbeeld staat de zib Zorgverlener elders in de dataset uitgewerkt. Deze uitwerking is dus van toepassing op de drie contexten waarin deze zib wordt gebruikt.
Verwijzingen tussen informatiebouwstenen en/of losse gegevenselementen worden doorgaans binnen één dataset te worden gemaakt (want je kunt in principe ook verwijzen naar bouwstenen die in een andere dataset staan). Alleen in dat geval is er op de volledige dataset, inclusief de bouwstenen waar naar wordt verwezen, volledig beheer mogelijk.

'''2.2.4 Relaties'''

In een dataset kunnen ook relaties worden gelegd tussen informatiebouwstenen. Het verschil met het maken van een verwijzing is dat bij een relatie vanuit een bouwsteen naar een andere bouwsteen niet de gegevens van die gerelateerde bouwsteen worden opgenomen maar zijn wel te herleiden.
Als bijvoorbeeld gegevens over een medicatieafspraak worden uitgewisseld, dan wil men weten of er een relatie is met een andere medicatieafspraak (start- en stop afspraken over dezelfde medicatie), toedieningsafspraak, medicatiegebruik, contact waarin de medicatieafspraak is gemaakt en de zorgepisode. Het is dan niet de bedoeling om alle gegevens over al deze bouwstenen mee te sturen, alleen om welke specifieke instantiaties van deze bouwstenen het gaat. Dit kan worden gedaan door een relatie te leggen naar de identificatie van deze specifieke instantiaties van de bouwstenen middels het Object Identifier (OID).
Het OID nummer is samengesteld uit een deel met de identificatie van de uitgevende organisatie – de zorgaanbieder van waaruit gegevens worden verstuurd – en een deel met de identificatie van een uniek gegeven dat is opgeslagen in het informatiesysteem van deze zorgaanbieder. Voor meer uitleg hierover zie de informatie op de HL7 site.
Hieronder de uitwerking van dit voorbeeld, waarin de relaties naar de OID’s van andere bouwstenen oranje zijn omkaderd:

[[File:Opstellen_dataset_paragraaf2.2.4png.png|576×254px]]

Om een volledig overzicht te hebben van alle relaties tussen informatiebouwstenen en gegevenselementen in een dataset, is het zeer aan te bevelen om een datamodel te maken voor elke usecase.

'''2.2.5 Invoegen en verwijderen dataelementen en (waarden in) waardelijsten'''

Zoals in hoofdstuk 2.1.4 reeds is toegelicht kunnen in een dataset ook afzonderlijke dataelementen en/of (waarden in) waardelijsten worden toegevoegd of verwijderd.
Het toevoegen of juist verwijderen van dataelementen – of groepen met dataelementen – binnen een informatiebouwsteen zorgt ervoor dat een informatiebouwsteen specifieker wordt gemaakt. In gegevensuitwisselingen binnen één domein (bijvoorbeeld huisartsen) kan het nodig zijn om specifieke elementen toe te voegen. Als voorbeeld is het toegevoegde dataelement ‘Presentatierol’ in de zib ‘Zorgverlener’ binnen het huisartsendomein.
Een dergelijke toevoeging moet altijd goed worden overwogen, zoals ook al in hoofdstuk 2.1.4 is toegelicht. Dit heeft namelijk ook consequenties voor het HL7 materiaal. Daarbij draagt een toevoeging ten behoeve van één domein niet bij aan standaardisatie van gegevensuitwisselingen over de domeinen heen. Zo zal een ‘Presentatierol’ in een gegevensuitwisseling van een huisarts naar een medisch specialist geen nut hebben.
Verwijdering van één of meerdere gegevenselementen uit een zib of informatiebouwsteen in de dataset wordt gedaan als deze in geen enkele gegevensuitwisseling van de informatiestandaard voorkomt. Belangrijk is wel dat het concept van de zib daarmee niet wordt aangetast; alleen optionele elementen in een zib mogen worden verwijderd.
Ook waardelijsten kunnen in zijn geheel worden toegevoegd of verwijderd, maar ook specifieke waarden ín een waardelijst. Een regelmatig voorkomende situatie is dat een waardelijst in een zib teveel algemene waarden bevat voor een gegevensuitwisseling en/of dat er specifieke waarden ontbreken. In dat geval wordt er een waardelijst op maat gemaakt ter vervanging van de initiële zib-waardelijst. Ook kan het voorkomen dat in een gegevensuitwisseling binnen één domein een aparte waardelijst van gelijke conceptuele strekking kan worden gebruikt. Denk hierbij aan specifieke NHG-tabel waardelijsten zoals NHG-tabel 12 ‘Soort derde’ naast de Vektis AGB AfdelingSpecialismeCodelijst.
In de handleiding voor ART DECOR [Documentatie-ART] is beschreven hoe dit in zijn werk gaat. Door te koppelen aan een dataelement wordt er context gegeven aan hoe een waardelijst wordt gebruikt in gegevensuitwisseling.
Ook kunnen waardelijsten zelf worden opgesteld en ingevoegd worden. In dit geval is het van belang om de termen in deze waardelijst te toetsen bij het Terminologiecentrum. Het Terminologiecentrum zorgt er dan voor dat de termen worden gekoppeld aan termen in codestelsels zoals SNOMED CT of LOINC. In het volgende hoofdstuk wordt hier verder op ingegaan.

===Terminologie in datasets===
Deze paragraaf biedt een werkvoorschrift voor het vastleggen van terminologiekoppelingen in ART-DECOR met een onderbouwing voor de keuze in werkwijze. Het document gaat hoofdzakelijk in op de werkvoorschriften omtrent SNOMED-termen, terwijl er verschillende (inter)nationale terminologiestelsels zijn. Gezien SNOMED het meest complexe stelsel is met de meeste regels, is vooral ten aanzien van SNOMED-terminologiekoppelingen een leidraad nodig om te komen tot consistentie binnen en tussen informatiestandaarden. Tot slot, huidig document gaat uit van ART-DECOR 2. Momenteel biedt ART-DECOR 3 niet dezelfde opties. Bij doorontwikkeling van ART-DECOR 3 zal gekeken worden welke opties noodzakelijk zijn (zie BITS-issues binnen het project ART-DECOR).

'''2.3.1 Terminologiekoppelingen'''

Een dataset wordt gecodeerd via het aanbrengen van terminologiekoppelingen. Dit omvat terminologiekoppelingen bij dataset-concepten en bij waardes in waardelijsten. In de [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn terminologie koppelen] geeft het Terminologiecentrum achtergrondinformatie over de verschillende terminologiestandaarden en worden handvatten geboden voor het uitvoeren van terminologiekoppelingen en het gebruik van terminologie in informatiestandaarden.

'''2.3.1.1 Dataset-concepten'''

Aan een dataset-concept kan een definitiecode via een terminologiekoppeling toegekend worden. In de Leidraad terminologiestandaarden (paragraaf 4.2) zijn de regels terug te vinden om te komen tot een juiste terminologiekoppeling als definitiecode van een dataset-concept. De naam van het dataset-concept zou overeen moeten komen met een beschrijving van het gekoppelde terminologieconcept, die door de beheerder van het stelsel geaccordeerd is (in SNOMED betreft dit een vertaling uit de Nederlandse extensie en in LOINC een vertaling uit de Nederlandse taalset van het Regenstrief). Terminologiekoppelingen van dataset-concept en waardelijst zouden op elkaar afgestemd moeten zijn (via vraag en antwoord of op basis van hoofdcategorie en verfijning). Waar mogelijk dient context gebruikt te worden: een gedetailleerd dataset-concept kan gekoppeld worden aan een generiek terminologieconcept, mits de ontbrekende informatie uit de andere terminologiekoppelingen blijkt.

'''2.3.1.2 Waardelijsten'''

Dataset-concepten kunnen een waardedomein hebben waarin concepten worden benoemd die als waarde kunnen dienen. Deze waardes behorende bij een dataset-concept kunnen op twee manieren vastgelegd worden in ART-DECOR: via de Waardelijst-editor (gecodeerde waardes) of via de Dataset-editor (ongecodeerde conceptnamen). De Waardelijst-editor is best practice. Via de Waardelijst-editor is het waardedomein te definiëren via het koppelen van een waardelijst. Deze waardelijst kan bestaan uit een geheel codesysteem of deel van een codesysteem (referentieset, tabel, etc.), een query van codes in een codesysteem (bijvoorbeeld: ‘is-een-kind-van’) of een selectie van losse codes. Indien het waardedomein is gedefinieerd via een selectie van losse codes, wordt in ART-DECOR tevens terminologie bij de codes vastgelegd. In de overige gevallen haalt de softwareleverancier de terminologie op bij het codesysteem (bij voorkeur via de Nationale Terminologieserver).
Het opbouwen van een lijst met ongecodeerde conceptnamen (via de Dataset-editor) kan als aanzet dienen tot het opbouwen van een lijst met gecodeerde conceptnamen (via de Waardelijst-editor). Indien er vanuit gebruikers behoefte is om in de informatiestandaard aanvullend andere termen op te nemen dan die in het terminologiestelsel staan opgenomen, heeft het voorkeur om hiervoor het veld Omschrijving te gebruiken in plaats van een aanvullende lijst met ongecodeerde conceptnamen. Overigens wordt deze lijst met ongecodeerde conceptnamen niet verwerkt in de technische berichten, maar deze dient door leveranciers separaat opgehaald te worden vanuit ART-DECOR.

'''2.3.2 Terminologievelden'''

ART-DECOR biedt verschillende velden om termen bij een terminologiecode vast te leggen. Dit betreffen de velden Weergavenaam (displayName), Benamingen (designation) en Omschrijving (description).
In de documentatie over ART-DECOR worden deze velden als volgt omschreven:
*displayName: The optional human readable display name for the code for orientation purposes. This display name corresponds to an official display name or synonym for the code in the code system.
*designation: Designations are language dependent display names for the code. For any language there might be multiple, each specifying the type (fully specified name, preferred, synonym, …).
*description: You may add a description for convenience, but should note that most of the time the description here overlaps with the designation/description of the coded concept.
Wat getoond wordt in ADA in het dropdownmenu bij het maken van kwalificatiemateriaal, is afhankelijk van wat ingevuld is in ART-DECOR bij het opbouwen van de waardelijst. Tekst uit het veld description wordt niet getoond in ADA.
Voor de specifieke toepassing van deze velden in zibs en informatiestandaarden is na overleg tussen informatieanalisten, informatiearchitecten van het Zib-centurm, terminologen en HL7-specialisten functie/ doel als volgt gedefinieerd:
*Weergavenaam: Leesbare weergave van de terminologiecode, waarbij de term afkomstig is uit het oorspronkelijke codesysteem. Dit is een hulp ter herkenning voor informatieanalisten, informatiearchitecten, terminologen, HL7-specialisten, softwareontwikkelaars en zorgverleners die betrokken zijn bij de ontwikkeling en het beheer van een zib of informatiestandaard.
*Benaming (volledig gespecificeerde naam): Hulp voor informatieanalisten en terminologen ter validatie van de terminologiekoppeling.
*Omschrijving: Toelichting ter verduidelijking van de betekenis van de gekoppelde terminologiecode, in aanvulling op terminologie uit het oorspronkelijke codesysteem. Dit kan een definitie van de waarde betreffen, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of de userinterfaceterm.

Het opnemen van terminologie in ART-DECOR uit een codesysteem heeft consequenties voor het beheer van een zib of informatiestandaard: bij elke release van een zib of informatiestandaard zal via het TerminologyReport gecontroleerd moeten worden of de terminologie in ART-DECOR nog overeenkomt met de terminologie in het codesysteem (een term kan in de tussentijd, tussen release van een zib of informatiestandaard en een meer recente release van het codesysteem, veranderd zijn in het codesysteem), net zoals gecontroleerd dient te worden of een terminologiecode niet is komen te vervallen.
Bij het vastleggen van terminologie in ART-DECOR kan gebruik gemaakt worden van de selectietool. Met deze tool kan een concept in een codesysteem worden opgezocht en worden opgenomen in de waardelijst. De terminologie is afkomstig uit een lokale kopie van het codesysteem. Terminologie wordt niet automatisch bijgewerkt als deze in het codesysteem verandert.
Indien gebruik gemaakt wordt van de selectietool in ART-DECOR voor het inladen van SNOMED-concepten, wordt voor het veld Weergavenaam de Nederlandse fully specified name ingeladen (indien er een Nederlandse vertaling beschikbaar is) en voor het veld Benamingen de fully specificied name, preferred term en synonyms in de beschikbare talen. Om de best practice uit dit document te volgen, kan het nodig zijn om de ingeladen termen via de selectietool aan te passen.
Gezien er een aantal jaar geleden nog weinig Nederlandse vertalingen van SNOMED beschikbaar waren, kunnen bij terminologiecodes in eerder gepubliceerde zibs en informatiestandaarden nog Engelstalige termen staan. Inmiddels heeft het merendeel van de SNOMED-termen een Nederlandse vertaling. Indien een vertaling toch ontbreekt, dient deze aangevraagd te worden bij het Terminologiecentrum.
Soms maakt het Terminologiecentrum een nieuwe SNOMED-code aan binnen de Nederlandse extensie, wanneer er geen geschikte SNOMED-code is binnen de internationale versie. Deze nieuwe SNOMED-code zal in de meeste gevallen nog niet opgenomen zijn in de huidige gepubliceerde versie van SNOMED op moment van release van de zib of informatiestandaard. In dat geval dient de term bij de terminologiecode handmatig ingevoerd te worden. Let hierbij op dat de Nederlandse SNOMED-termen beginnen met een kleine letter en de Engelstalige SNOMED-termen met een hoofdletter.

'''2.3.2.1 Dataset-concepten'''

'''2.3.2.1.1 Weergavenaam'''

Bij het aanbrengen van een terminologiekoppeling bij een dataset-concept biedt ART-DECOR één veld, namelijk Weergavenaam, om een term in tekst mee te geven bij de code. Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse fully specified name te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een waarde). Er is gekozen voor de volledig gespecificeerd naam, gezien deze term niet alleen een leesbare weergave biedt bij de code, maar tevens validatie van de terminologiekoppeling mogelijk maakt.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2 Waardelijsten'''

'''2.3.2.2.1 Weergavenaam '''

Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse preferred term te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een dataset-concept). Er is gekozen voor de Nederlandse preferred term, gezien deze term het beste aansluit bij het doel van het bieden van een leesbare weergave van de terminologiecode. De fully specificied name in SNOMED bevat een semantic tag, waarbij kennis van SNOMED vereist is om deze te kunnen interpreteren. Bovendien is de fully specified name langer dan de preferred term, wat een onoverzichtelijkere weergave kan betekenen.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2.2 Benamingen'''

Het veld Benaming (type volledig gespecificeerde naam) dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient in dit veld de Nederlandse fully specified name opgenomen te worden. De fully specified name bevat de semantic tag die aangeeft in welke SNOMED-hiërarchie het concept valt, waardoor het mogelijk is om te beoordelen of de terminologiekoppeling correct is (op basis van de semantic tag kunnen bepaalde inconsistenties in een waardelijst in het oog springen, waar anders gemakkelijk overheen gekeken kan worden).
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.
De overige typen Benamingen (type voorkeursterm en type synoniem) dienen niet gevuld te worden. Deze velden vervullen, in tegenstelling tot Benaming (type volledig gespecificeerde naam), geen specifieke functie in het functioneel ontwerp van een informatiestandaard of zib.

'''2.3.2.2.3 Omschrijving'''

Het veld Omschrijving wordt gevuld afhankelijk van de behoeften van de eindgebruikers van de zib of informatiestandaard. In het veld Omschrijving kan tekst meegegeven worden die niet in het codesysteem opgenomen staat. Dit kan een toelichting zijn ter verduidelijking van de betekenis van de gekoppelde terminologiecode in aanvulling op terminologie uit het oorspronkelijke codesysteem, een definitie van de waarde, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of (suggestie voor) de userinterfaceterm. Dit veld is daarmee een hulp voor ontwikkelaars om te komen tot een geschikte benaming in de userinterface.
Indien het veld Omschrijving een userinterfaceterm bevat, hebben informatieanalist/informatiearchitect en terminoloog gevalideerd dat deze term en gekoppelde terminologiecode overeenkomen in betekenis binnen de context van de waardelijst. Een userinterfaceterm kan specifieker zijn dan de term in het codesysteem door de context die de waardelijst meegeeft, of juist meer generiek, doordat de context van de waardelijst een specifieke benaming van de waarde overbodig maakt.
Indien er met de betrokken partijen afgesproken is dat het beheer van de gebruikte terminologie van een waardelijst binnen de informatiestandaard valt, waarbij er afspraken gemaakt zijn over de letterlijke term die op de gebruikersinterface getoond dient te worden, is dit veld onderdeel van de kwalificatie.
2.3.3 Het maken van gespecialiseerde waardelijsten
Zoals in 2.2.5 is benoemd kan het nodig zijn om een waardelijst van een geërfde bouwsteen te vervangen door een gespecialiseerde waardelijst. In het geval dat er een beperkt aantal concepten aan de oorspronkelijke waardelijst moeten worden toegevoegd of juist verwijderd zijn er twee alternatieven:
*Een kopie maken van de waardelijst van de geërfde bouwsteen en deze bewerken. De relatie van de nieuwe waardelijst met de oorspronkelijke waardelijst gaat verloren. Wijzigingen in de oorspronkelijke waardelijst worden niet doorgevoerd op de gespecialiseerde waardelijst. Je kiest hiervoor als de gespecialiseerde waardelijst niet lijkt op oorspronkelijke waardelijst, bijvoorbeeld omdat de gespecialiseerde waardelijst een opsomming is van mogelijke waarden en de oorspronkelijke een codestelsel, of een deel van een codestelsel gespecificeerd met een intensionele expressie.
*De waardelijst van de geërfde bouwsteen includeren in de gespecialiseerde waardelijst. Hierbij blijft de relatie met de oorspronkelijke waardelijst zichtbaar. Dit kan op twee manieren:
*Statische inclusie: een specifieke versie van de waardelijst wordt geïncludeerd (deze zal niet meer wijzigen)
*Dynamische inclusie: de laatste versie van de waardelijst wordt geïncludeerd. Doorgaans wordt bij een gespecialiseerde lijst geen dynamische inclusie toegepast. Maar indien hier wel voor is gekozen, moet ervoor wordt gewaakt of de inclusie en de zelf toegevoegde waarden inderdaad volledig disjunct zijn en blijven zodat er geen dubbelingen ontstaan. Het alternatief is om de eigen toevoegingen mee te laten nemen in de volgende release van een waardelijst.
De extra concepten, nodig voor de specialisatie, kunnen los worden toegevoegd of met Inclusies. Bij deze laatste methode moet een intentionele expressie worden ingevuld. Concepten uit de waardelijst van de geërfde bouwsteen die juist niet gewenst zijn in de gespecialiseerde waardelijst, kunnen met exclusies worden uitgesloten (ook weer met intentionele expressie).

===Generieke modelering – afspraken===

In hoofdstuk 2.2.4 is uitgelegd dat er tussen de verschillende bouwstenen en/of dataelementen in bouwstenen relaties kunnen worden gelegd. Deze relaties geven context aan of nadere aanvulling van gegevens. In het kader van standardisatie van gegevensuitwisseling niet alleen binnen één informatiestandaard maar ook in standaardisatie tussen alle informatiestandaarden is het belangrijkom dit soort relaties op een zoveel mogelijk eenduidige manier te doen. Als in alle informatiestandaarden op dezelfde manier relaties en modeleringen van gegevens worden gemaakt, is het voor de informatieanalisten veel eenvoudiger om te bepalen wat er in de verschillende informatiestandaarden aan gegevens worden uitgewisseld en hoe dit op elkaar aansluit. Evenzo belangrijk is dat de technische specificaties in HL7 berichten veel meer generiek kunnen worden uitgewerkt.

==Samenstellen scenario’s==

Een Nictiz informatiestandaard bevat minimaal één maar meestal meerdere usecases. Een usecase is een beschrijving van een informatie-uitwisseling op een specifiek moment in het zorgproces, waarbij voor een concrete praktijksituatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Zoals eerder gemeld staan alle usecases van één informatiestandaard beschreven in een functioneel ontwerp.
De specifieke gegevens die worden uitgewisseld binnen elk van de usecases zijn een subset van de dataset voor een gehele informatiestandaard. Daarom moet voor elke usecase een datascenario worden aangemaakt. In dit hoofdstuk wordt verder ingegaan op de keuzes en mogelijkheden voor het samenstellen van een datascenario.
N.B.: In dit document wordt consequent de term ‘datascenario’ gebruikt in plaats van de term ‘scenario’ zoals dat wordt gebruikt in ART DECOR. De reden is dat ‘scenario’ een term is die breed kan worden opgevat en daarom met verschillende betekenissen in velerlei documentatie wordt gebruikt. ‘Datascenario’ geeft meer context aan de betekenis voor dit document.

===Usecase en datascenario===
In principe wordt er voor elke usecase binnen een informatiestandaard een datascenario samengesteld. De naamgeving van een datascenario volgt veelal de hoofdlijn van elke usecase. Bijvoorbeeld in de informatiestandaard Acute zorg is er de usecase ‘Uitwisseling ambulance naar SEH’ waarvoor het datascenario ‘AMB (ambulance) draagt over aan SEH (Spoedeisende hulp)’ is samengesteld.
Het kan voorkomen dat de inhoud van de gegevensuitwisseling voor meerdere usecases binnen één informatiestandaard hetzelfde is. In dit geval wordt er voor meerdere usecases één datascenario samengesteld, waarbij in de naamgeving van het datascenario de meerdere usecases worden benoemd. Rugten naar ‘scenario

===Datascenario, transactiegroepen en transacties===
Elk datascenario is opgebouwd uit één of meerdere transactiegroepen. Een transactiegroep bevat alle transacties die bijdragen aan één specifieke gegevensuitwisseling tussen twee partijen.
Vaak is het zo dat binnen één datascenario ook maar één transactiegroep wordt gebruikt maar het is evengoed mogelijk om binnen één datascenario meerdere transactiegroepen te gebruiken, dit wordt verderop in dit hoofdstuk toegelicht.
Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.
Elke transactiegroep kan weer één of meerdere transacties bevatten. Een transactie is een werkelijke overdracht van gegevens.
Een transactiegroep waarin berichten worden verstuurd, bevat doorgaans een transactie met de verstuurde gegevens en een transactie met de ontvangstbevestiging. Dit zijn een zogenaamde push-transacties: overdrachten van gegevens waarbij de verzender op eigen initiatief een bericht verstuurt en waarbij de ontvanger dit bericht ontvangt zonder dat daarvoor actief naar is gevraagd.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het versturen van een specifieke gegevensset, ofwel dat het gaat om een ontvangstbevestiging. Vaak wordt deze transactie als overbodig beschouwd en daarom achterwege gelaten.

Een transactiegroep waarin gegevens worden geraadpleegd, bevat doorgaans een transactie met de raadpleging op maat en een transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Dit is een zogenaamde pull-transactie: een overdracht van gegevens waarbij de ontvanger van deze gegevens actief om heeft gevraagd en waarbij de verzender deze gegevens beschikbaar heeft gesteld.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het raadplegen van een specifieke gegevens set, ofwel dat het gaat om het beschikbaarstellen van de geraadpleegde gegevens.
Zoals eerder gemeld kan er in een transactiegroep in plaats van één transactie met alle benodigde gegevens ook worden gekozen voor het toepassen van meerdere transacties voor het versturen van gegevens: bijvoorbeeld één transactie per (zorginformatie-)bouwsteen. Deze constructie kan worden toegepast als er één datascenario wordt gebruikt voor meerdere usecases, waarbij het merendeel van de verstuurde gegevens gelijk is, maar waar er per usecase soms wel of niet een extra bouwsteen moet worden meegestuurd. Een voorbeeld hiervan is het opvragen van de professionele samenvatting door meerdere raadplegende partijen in de acute zorg – de meldkamer, ambulance en de SEH – waarbij de meldkamer geen gegevens over overgevoeligheden wil ontvangen. In dit geval is er geen transactie met de bouwsteen voor overgevoeligheden.
Als voorbeeld voor de hierboven beschreven samenstelling van datascenario’s met transactiegroepen en push- en pull-transacties dient wederom de informatiestandaard voor acute zorg. met hieronder een aantal usecases waarvoor datascenario’s zijn samengesteld met push-transacties, zoals:
*Berichten van de ambulance naar de SEH
*Verwijzen van een patiënt van (waarnemend) huisarts naar de meldkamer
*Versturen rapportages van meldkamer, ambulance en SEH naar de huisarts
In het plaatje hieronder is een uitwerking van het datascenario voor berichten van de ambulance naar de SEH:

[[File:Opstellen_dataset_paragraaf_3.2a.png|576×254px]]

En een drietal usecases waarvoor één datascenario is samengesteld met pull-transacties:
*Opvragen van de professionele samenvatting bij de huisarts door de meldkamer, ambulance of SEH

[[File:Opstellen_dataset_paragraaf_3.2b.png|576×254px]]

In ART-DECOR worden de transacties binnen een datascenario gegroepeerd tot een transactiegroep. In datascenario’s waarin berichten worden verstuurd, bestaan een transactiegroep uit de transactie met verstuurde gegevens en de transactie met de ontvangstbevestiging. In datascenario’s waarin gegevens worden geraadpleegd bestaat de transactiegroep uit de transactie met de raadpleging op maat en de transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.

===Transactiedataset===
Per transactie wordt er een specifieke set gegevens verstuurd van de verzender naar de ontvanger. In een transactiedataset is dit gedetailleerd uitgewerkt. Alle gegevenselementen en (delen van) zibs en/of informatiebouwstenen n een transactiedataset worden betrokken uit de informatiestandaard dataset zoals beschreven in hoofdstuk 2. Andersom kan ook worden gezegd dat alle transactiedatasets van de transacties als onderdeel van een transactiegroep, die op hun beurt weer onderdeel zijn van een datascenario, tezamen de informatiestandaard dataset vormen.

'''3.3.1 Cardinaliteit en conformance'''
In een transactiedataset wordt per gegevenselement ook de kardinaliteit aangegeven. Op de informatiepagina van het zib-centrum is uitgelegd wat kardinaliteiten zijn: https://zibs.nl/wiki/Zib_kardinaliteiten
In informatiemodellen wordt kardinaliteit gebruikt om de multipliciteit van een element ten opzichte van zijn parent – of als het een top level element is, de multipliciteit van de boom eronder - in een transactie aan te geven. Daarbij wordt de notatie ‘m..n’ gebruikt, waarbij ‘m’ de minimale multipliciteit is en ‘n’ de maximale. In het model wordt de kardinaliteit genoteerd bij het element waarvoor dit geldt. Dus als er tussen element A en element B en relatie bestaat en bij element B de kardinaliteit m..n staat, betekent dit dat een element A minimaal met ‘m’ elementen B een relatie heeft en maximaal met ‘n’ elementen B
Naast de multipliciteit wordt met een letter aangegeven of deze relatie Mandatory, Required, Conditional of Optional is:

{| class="wikitable"
! M (Mandatory)
|Een gegeven moet altijd worden aangeleverd. De minimale multipliciteit is dan ook 1..1M
|-
! R (Required)
| Indien een gegeven beschikbaar is, moet deze worden aangeleverd. Bijvoorbeeld als één of meerdere voornamen van een patiënt bekend zijn. De kardinaliteit is in dit geval 0..*R
|-
! C (Conditional)
| Een gegeven dat moet worden aangeleverd, afhankelijk van de waarde of aanwezigheid van een ander gegeven. Bijvoorbeeld de invulling van een toelichting indien in een waardelijst de optie ‘Anders’ is geselecteerd. De kardinaliteit van de toelichting is in dit geval 1..1C
|-
! O (Optional)
| Een gegeven dat eventueel kan worden aangeleverd maar niet noodzakelijk. Deze optie wordt vrijwel niet toegepast. Als een gegeven niet noodzakelijk is binnen een overdracht, wordt deze in de regel ook niet opgenomen in een informatiestandaard.
|}

De kardinaliteiten zoals vastgesteld in de transactiedatasets zijn functioneel leidend. Op basis hiervan kan worden afgeleid wat er in een gegevensoverdracht aan gegevens moet worden meegestuurd. Een verzendende partij weet welke gegevens er moeten worden opgeleverd, al dan niet verplicht, verplicht indien beschikbaar of conditioneel. Een ontvangende partij weet wat er aan gegevens moet worden verwerkt en getoond kunnen worden.
Let op: de kardinaliteit in zibs zijn conceptueel; het kan dus voorkomen dat een kardinaliteit van een gegeven in een transactiedataset enger is als die in een zib. Dit geldt ook voor de kardinaliteiten in HL7v3 tempates en FHIR profielen; deze kunnen minder eng zijn als die in een transactiedataset.
Andersom is conceptueel niet mogelijk. Als iets conceptueel verplicht is of in bijvoorbeeld een FHIR profiel verplicht staat (zoals 1..1M), is het niet mogelijk om in de functionele transactiedataset hier geen verplichting aan te geven (zoals 0..1R).
Zoals in hoofdstuk 2.3.3 en 2.3.4 is uitgelegd kunnen in een dataset – en dus ook in een transactiedataset – verwijzingen en relaties voorkomen. Ook deze kennen kardinaliteiten. Bij verwijzingen geldt dat de bron-bouwsteen waar naar verwezen wordt in de dataset, ook in de transactiedataset moet voorkomen. De kardinaliteit van deze bron-bouwsteenen alle gegevens daarbinnen geldt dat voor alle contexten met verwijzingen. Als voorbeeld is wederom de LaboratoriumUitslag van hoofdstuk 2.3.3:

[[File:Opstellen_dataset_paragraaf_3.3.1.png|576×254px]]

Hierbij geldt dat in de bouwsteen LaboratoriumUitslag de kardinaliteit van de context – LaboratoriumUitslagVerantwoordelijke, Aanvrager en Uitvoerder – aangeeft hoe elk van deze contexten in het bericht moeten worden meegenomen. In dit geval dus alle drie verplicht. De kardinaliteit van de verwezen bouwstenen onder de context geeft aan dat áls er bijvoorbeeld een Uitvoerder is, dat dan de verwezen Zorgverlener óf Zorgaanbieder aanwezig moet zijn (vandaar de kardinaliteit van beiden 0..1 R). Bij de Aanvrager is er maar één mogelijkheid – de Zorgverlener – en vandaar dat deze dan ook mandatory is.
In de verwezen bron-bouwsteen Zorgverlener gelden vervolgens de kardinaliteiten zoals hierin is opgezet.

'''3.3.2 Raadplegen: Query Parameters'''

Voor de transactieset waarin gegevens worden opgevraagd door een partij (PULL), is vaak een selectie op de gegevens van toepassing.

Dit kan op twee manieren zijn ingericht in ART DECOR:
1.Vooraf vastgestelde selectie: als onderdeel van de transactie beschikbaarstellen
2.Variabele selectie: als query parameter in de transactie raadplegen

De eerste situatie is vooral van toepassing wanneer er landelijke afspraken zijn dat er altijd een standaard selectie wordt toegepast. Dit zorgt ervoor dat altijd eenzelfde overzicht voor een patiënt wordt gegenereerd. Bijvoorbeeld in de BgZ, is de “laatst bekende bloeddruk” in beschikbaarstellen opgenomen als 0..1 conditioneel:

[[File:Opstellen_dataset_paragraaf_3.3.2a.png|576×254px]]

De tweede situatie met query parameters, is van toepassing wanneer het nodig is een specifieke selectie per individuele raadpleging te maken. Bijvoorbeeld; de eindgebruiker van een systeem geeft zelf aan voor welke patiënt en in welke periode er informatie opgevraagd wordt. Welke gegevens als query parameters gebruikt kunnen worden, is afhankelijk van de usecase. Vaak zal er een identificatie(nummer) uit de Patiënt zib gebruikt worden zodat de raadpleging gericht voor één persoon plaats vindt.
In ART-DECOR dit worden ingericht, door in de dataset een groep “QueryParameters” op te nemen en dan de relevante parameters in de transactie(s) Raadplegen te gebruiken. Een parameter kan gebruik maken van een gegevenselement uit 1 bouwsteen, bijv. het identificatienummer van de Patiënt. Een andere mogelijkheid is dat een parameter gebruik maakt van 1 type gegeven die op meerdere plaatsen in de dataset voor komt, bijv. een datum(periode) waarin meerdere metingen (zoals bloeddruk, gewicht en lengte) uitgevoerd kunnen zijn.
Om duidelijk te maken aan wélke gegevens de parameters gelinkt zijn, kan je de in de dataset dit toelichten in de naam en omschrijving van de query parameter. Ook de zoekwijze kan je hier toelichten, zoals voor periodes waarin gezocht kan worden. Als daarnaast per transactie nog aparte regels gelden, kan je dit via het veld context bij de transactie uitleggen (en/of via een Conditie indien dit van toepassing is).
Als voorbeeld hieronder een weergave van de Gebruiksperiode in de transactie Raadplegen medicatieafspraak (MP 2.0.0): voor de gebruiksperiode is in de omschrijving van het concept aangegeven op welke conceptgroepen uit de dataset (“MA, WDS en TA”) de periode van toepassing is. Voor de transactie is dan ook nog een conditie opgenomen ter nadere specificatie.

[[File:Opstellen_dataset_paragraaf_3.3.2b.png|576×254px]]

=Release notes=
In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Instructie opstellen dataset

2025-08-26T08:08:54Z

Lilian Brouwer: /* Transactiedataset */

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Instructie opstellen dataset 3.0.0 {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__

==Inleiding==
Dit document beschrijft de ‘best practices’ bij het opstellen van een dataset, behorende bij een informatiestandaard. Deze ‘best practices voor Nictiz datasets’ is de richtlijn voor iedereen die zich bezighoudt met het opstellen en beheren van datasets. Door op een eenduidige wijze deze datasets samen te stellen, wordt de uitwisselbaarheid in (delen van) datasets verbeterd en wordt het voor beheerders van datasets ook eenvoudiger om datasets die zijn opgesteld door collega’s, inzichtelijk te krijgen. Hiermee wordt ook getracht om de mapping van met name de datascenario’s op de HL7 berichten (HL7v3 templates en FHIR-profielen) te vereenvoudigen.
Daarnaast is de uniformiteit in de samenstelling van datasets van groot belang voor externe partijen – met name zorginstellingen en hun ICT-leveranciers die met behulp van de datasets en datascenario's de gegevensuitwisselingen conform de Nictiz informatiestandaarden moeten implementeren.
Voor de leesbaarheid en de juiste context van begrippen zijn een aantal relevante definities hieronder ingevoegd. Deze komen vanuit de
[https://nictiz.nl/standaarden/begrippen/ Nictiz begrippenlijst] of zijn er aan toegevoegd (met de intentie om deze alsnog op te nemen in de begrippenlijst):

{| class="wikitable"
! Begrip
! Definitie
|-
| Richtlijn
| Beschrijving die verduidelijkt wat behoort te worden gedaan en hoe, om de doelstellingen te bereiken die in het beleid zijn vastgelegd (NEN 7510)
|-
| Functioneel ontwerp
| In een Nictiz functioneel ontwerp worden alle eisen en wensen voor alle usecases (ook wel uitwisselscenario’s genoemd) binnen één informatiestandaard verzameld en geordend. Per usecase wordt beschreven op welke manier dat gebeurt: tussen welke gebruikers vindt de gegevensuitwisseling plaats, welke handelingen worden daarbij uitgevoerd en welke resultaten leveren deze op.
|-
| Usecase
| Een beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het vastleggen en/of uitwisselen van
|-
|
| informatie wordt beschreven aan de hand van actoren (mensen, informatiesystemen) en transacties (welke informatie wordt wanneer uitgewisseld).
|-
| Dataset
| Een dataset bevat definities van alle gegevens die binnen de context van een specifiek zorgproces en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Deze definities zijn functioneel van aard en worden vastgesteld door het zorgveld. Voor specifieke transacties binnen het zorgproces wordt gebruik gemaakt van een subset van de gegevens uit deze dataset (het datascenario).
|-
| Zib
| Zorginformatiebouwstenen (zibs) worden gebruikt om inhoudelijke (niet technische) afspraken vast te leggen ten behoeve van het standaardiseren van informatie, die gebruikt wordt in het zorgproces. Het doel van de standaardisatie is dat deze informatie uit het zorgproces wordt hergebruikt voor andere doeleinden, zoals kwaliteitsregistraties, overdracht, patiëntgebonden onderzoek. Een zorginformatiebouwsteen is een informatiemodel, waarin een zorginhoudelijk concept wordt beschreven in termen van de gegevenselementen waaruit dat concept bestaat, de datatypes van die gegevenselementen etc.
|-
| Informatiebouwsteen
| Een concrete voorziening, standaard, afspraak of arrangement, met een eigenaar, beheerder, financiering et cetera die bovensectoraal of zorgbreed (her)gebruikt kan worden.
|-
|
| Informatiebouwstenen kunnen zijn (opgebouwd uit) zibs en/of opgebouwd uit gegevenselementen.
|-
| Dataelement / gegeven
| Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.
|-
| Scenario
| De representatie van een usecase in ART DECOR waarin de actoren en een specifieke subset gegevens uit de dataset (transactiedataset) zijn uitgewerkt.
|-
| Transactiegroep
| Een model van een verzameling van gegevens die wordt overgedragen tussen actoren (personen of systeemrollen) binnen één usecase. Een transactie wordt schematisch weergegeven door de uitwisseling van een transactiedataset tussen twee actoren.
|-
| Transactiedataset
| Een subset van gegevens uit de dataset voor een specifieke transactie met kardinaliteiten en conformiteiten.
|-
| Intensionele waardelijst en expressie
| Zie 2.3.2

Een intentionele waardelijst geeft niet direct aan welke directe waarden je moet hebben, maar alleen een intentie geeft voor elke waarde erin in thuishoort. Dit doe je door een intentionele expressie (dat in feite een query is), zoals :

< T : alle waarden onder T

of

<< T : T en alle waarden daaronder

of

< T1

OR

< T2 : alle waarden onder T1 of T2
N.B. Daarnaast kun je waardes in de intentionele expressie ook excluderen
|}

===Doelstelling===
Het eerste doel van dit document is het bevorderen van inzicht in hoe een dataset wordt samengesteld. De richtlijnen en methoden voor het samenstellen van een dataset worden in dit document nader toegelicht.
Het tweede doel van dit document is het bevorderen van inzicht in hoe een datascenario wordt samengesteld vanuit een dataset. De richtlijnen en methoden voor het samenstellen van een datascenario worden in dit document nader toegelicht.

===Scope van dit document===
Dit document geeft definities van een dataset, zib, informatiebouwsteen, data-element en een datascenario. Ook wordt uitgelegd hoe een dataset en een datascenario op een eenduidige wijze moet worden samengesteld. De verschillende methoden die hiervoor gebruikt worden, zijn nader beschreven.
Dit document kan als een richtlijn worden beschouwd voor wijze waarop binnen Nictiz datasets en datascenario’s worden samengesteld. Ook voor beheer van reeds bestaande datasets en datascenario’s is deze richtlijn van toepassing.

===Buiten scope van dit document===
Een dataset bevat definities van alle gegevens die in een specifieke context binnen het zorgproces, en de daarbij gedefinieerde usecases worden vastgelegd en/of uitgewisseld. Voor elke usecase moeten door betrokken partijen afspraken gemaakt worden over de inhoud van de te gebruiken gegevens – het datascenario. De definities die van toepassing zijn in het zorgproces zijn functioneel van aard en worden vastgesteld door de zorgverleners in een functioneel ontwerp en daarmee buiten de scope van dit document.
Eveneens buiten scope is een uitleg van de tooling waarmee datasets worden samengesteld en gepresenteerd. Hiervoor wordt verwezen naar ART DECOR [https://decor.nictiz.nl/wiki/index.php/Ontwikkelaars#Proces_ontwikkelen_DECOR-project, https://simplifier.net/, Zibs 2017: https://simplifier.net/NictizSTU3-Zib2017, http://www.art-decor.org]. Echter, vanwege praktische redenen worden in dit document afbeeldingen gebruikt van (delen van) datasets en datascenario’s in ART DECOR om beschrijvingen nader toe te lichten.
Dit document is gericht aan inhoudelijke experts op het gebied van Nictiz informatiestandaarden (informatieanalisten, product managers, Specialisten gegevensuitwisseling, etc.) waarvan wordt verondersteld dat men bekend is met de gebruikte terminologieën, tooling, documentatie, etc.. Deze worden daarom niet verder toegelicht en beschreven in dit document.

==Samenstellen datasets==

===Richtlijnen voor het samenstellen van datasets===
Voor het opstellen van een dataset gelden een aantal basisprincipes. In het kort komt dit neer op de volgende punten:
*Zoveel mogelijk gebruik maken van de meest recent gepubliceerde zibs
*Indien geen zibs beschikbaar, bekijk reeds bestaande datasets, CIMS en/of kandidaat-zibs op de aanwezigheid van informatiebouwstenen die toegepast kunnen worden in de nieuwe dataset
*Conformeer zoveel mogelijk aan het zorgproces, de informatiestandaard (op basis van richtlijnen en functioneel ontwerp) maar ook aan de gegevensmodellen van de zibs en informatiebouwstenen
*Voeg alleen dataelementen en (waarden in) waardelijsten toe als deze niet worden gerepresenteerd door reeds beschikbare dataelementen en (waarden in) waardelijsten in zibs en/of informatiebouwstenen
*Conformeer zo veel mogelijk aan de generieke volgorde van zibs en informatiebouwstenen in een dataset
In dit best practice document wordt in de subhoofdstukken hierna voor elk van deze punten beschreven wat dit betekent voor de daadwerkelijke samenstelling van een dataset.

'''2.1.1 Meest recent gepubliceerde zibs'''

Over het nut en noodzaak van zibs is reeds de nodige literatuur [https://zibs.nl/wiki/Hoofdpagina beschikbaar]. Door voortschrijdend inzicht en met inbreng van vele stakeholders worden zibs middels een strikt nageleefd beheerproces aangepast. Bij het samenstellen van een nieuwe dataset is het dan ook van groot belang om de meest recent gepubliceerde zibs te gebruiken.
In ART-DECOR zijn alle zibs van de meest recente publicatie beschikbaar en kunnen worden gebruikt als informatiebouwsteen om een dataset mee samen te stellen. Door zoveel mogelijk gebruik te maken van de zib concepten, kan informatie in alle afzonderlijke zorgtoepassingen op dezelfde manier worden vastgelegd (tussen de zender en ontvanger) en blijft de betekenis gelijk.
Zibs zijn concepten die zorgbreed kunnen worden toegepast. Het kan daarom voorkomen dat in specifieke gegevensoverdrachten in een bepaald domein een aanvulling op dit concept nodig is. Bijvoorbeeld extra dataelementen of waardelijsten die niet in de zibs zijn opgenomen. Ook kan het voorkomen dat binnen een dataset slechts een deel van de zib wordt gebruikt. Elementen van een zib kunnen daarom ook worden verwijderd, zolang dit het conceptuele model van de zib niet compromitteert.

'''2.1.2 Informatiebouwstenen'''

Naast zibs kunnen ook informatiebouwstenen worden gebruikt bij het samenstellen van een dataset. Informatiebouwstenen kunnen zibs zijn met een aantal toevoegingen of verwijderingen van dataelementen en/of waardelijsten, detailed clinical models (DCM’s) die geen zibs zijn of nog kandidaat-zibs zijn (zie ook ‘Zorginformatiebouwstenen – Richtlijnen bij afwezigheid van zib’s’) of een zelf opgebouwde informatiebouwsteen. Vaak zijn deze informatiebouwstenen voor één of hooguit enkele zorgdomeinen van toepassing, in tegenstelling tot zibs die zorgbreed toegepast kunnen worden.
Bekijk daarom ook functioneel ontwerpen en informatiebouwstenen in datasets van andere informatiestandaarden om te bepalen of er, al dan niet gedeeltelijke, overlap is met betrekking tot de inhoud van de gegevensuitwisseling. Door hergebruik van informatiebouwstenen worden ook gegevensuitwisselingen die niet met zibs kunnen worden gemodelleerd, zoveel mogelijk gestandaardiseerd.

[[File:Opstellen_dataset_paragraaf2.1.png|576×254px]]

Hoe een zib in een bepaalde zorgsituatie (usecase) wordt gebruikt is vastgelegd in een informatiestandaard. Een informatiestandaard voegt context en relaties toe aan de zib gegevensmodellen en beschrijft in welke zorgsituatie je welke gegevens vastlegt en uitwisselt [zie ook https://www.nictiz.nl/standaardisatie/informatiestandaarden/].

'''2.1.3 Zorgproces, informatiestandaard en gegevensmodellering'''

Vanzelfsprekend zijn het zorgproces en kwaliteitstandaarden/richtlijnen de leidraad voor wat er in de dataset moet worden toegevoegd aan zibs, informatiebouwstenen en/of dataelementen en waardelijsten. Vaak wordt er bij het samenstellen van de dataset en meer nog het datascenario (zie het hoofdstuk Samenstellen datascenario) ruggespraak gehouden met experts uit het zorgveld. Deze dataexperts kunnen waardevol inzicht verschaffen bij het ‘fijnslijpen’ en completeren van een dataset en de datascenario’s. Hierbij dient er wel scherp op gelet te worden dat de dataset samenstelling er is voor interoperabiliteit en niet voor het modelleren van systemen.

'''2.1.4 Toevoegen dataelementen en waardelijsten'''

In een dataset kunnen ook ‘losse’ dataelementen en specifieke waardelijsten worden toegevoegd. Meestal worden deze dataelementen en/of waardelijsten toegevoegd aan onterfde zibs en/of informatiebouwstenen om deze op maat te maken voor een specifieke informatiestandaard, zie ook Methoden voor samenstellen datasets bij subhoofdstuk 2.2.5 Invoegen en verwijderen dataelementen en waarden in waardelijsten. In een enkel geval kunnen dataelementen ook rechtstreeks in een dataset worden ingevoegd.
Er moet goed worden overwogen welke gevolgen dit heeft voor de datascenario’s en onderliggende HL7-berichten. Ook moet er scherp op gelet worden dat eventuele toevoegingen van dataelementen en (waarden in) waardelijsten complementair zijn aan de reeds beschikbare gegevens in de zibs en niet als vervanging voor terminologie.

'''2.1.5 Volgordelijkheid (zorg)informatiebouwstenen en dataelementen in dataset'''

Naast dat datasets de verzameling zijn van alle gegevens in alle datascenario’s, zijn datasets ook bedoeld om een overzicht te bieden aan Nictiz collega’s en externe dataexperts. Door een zoveel mogelijk gestandaardiseerde volgorde van zibs en informatiebouwstenen aan te houden in een dataset, wordt er een beter overzicht gecreëerd. Ook is het mogelijk om bepaalde segmenten toe te passen, zoals een groep ‘bundel’ of ‘bouwstenen’ waarbinnen de (zorg)informatiebouwstenen zijn ondergebracht waarnaar wordt verwezen vanuit andere delen van de dataset.
Een strak gereguleerde volgordelijkheid van informatiebouwstenen in alle informatiestandaard-datasets is lastig te realiseren. Het voornaamste is dat Nictiz collega’s en externe partijen op een zo eenvoudig en intuïtief mogelijke wijze de samenstelling van een dataset goed kunnen overzien.
Hieronder is een voorbeeld als leidraad voor een volgordelijkheid van zibs en informatiebouwstenen in een dataset:
*Patiënt
*Zorgverlener
*Zorgaanbieder
*Contactmomenten
*Zibs en informatiebouwstenen m.b.t. triage, diagnose
*Zibs en informatiebouwstenen m.b.t. behandeling en verrichting
*Zibs en informatiebouwstenen m.b.t. uitslagen en verslaglegging
*Zibs en informatiebouwstenen voor specifieke onderwerpen in een usecase
Echter, het is mogelijk dat deze volgordelijkheid in bestaande en nieuwe datasets in ART DECOR niet is toegepast. Vooral de wat oudere datasets zijn hierin soms afwijkend. En regelmatig zijn er in datasets de eerder genoemde segmenten gebruikt waarbij zibs en informatiebouwstenen in een groep zijn samengevoegd, zoals “Demografie en identificatie” met zibs Patiënt, Contactgegevens en BurgerlijkeStaat of “Sociale Anamnese” met zibs Woonsituatie, Taalvaardigheid, ParticipatieInMaatschappij en HulpVanAnderen.

===Methoden voor samenstellen datasets===
Datasets kunnen met verschillende methoden worden samengesteld:
*Erven (zibs en informatiebouwstenen)
*Onterven (na eerst te hebben geërfd)
*Verwijzen
*Relaties maken tussen informatiebouwstenen
*Invoegen en verwijderen dataelementen en (waarden in) waardelijsten
In dit best practice document wordt elk van deze methoden beschreven, alsook een uitleg over welke methode te gebruiken in bepaalde situaties.

'''2.2.1 Erven'''

Binnen ART-DECOR kan een zib of een informatiebouwsteen uit een andere dataset in de eigen dataset worden geërfd. Erven houdt in dat alle gegevenselementen van een zib of informatiebouwsteen, inclusief de onderlinge samenhang (structuur), worden gekopieerd en toegevoegd in de nieuwe dataset.

'''2.2.2 Onterven'''

Een geërfde zib of (zelf ontwikkelde) informatiebouwsteen dient in veel gevallen nog te worden aangepast. Er kunnen gegevenselementen aan worden toegevoegd of juist verwijderd (hoofdstuk 2.2.5). Ook kunnen er relaties worden toegevoegd, zoals wordt beschreven in hoofdstuk 2.2.4 – Relaties binnen datasets. Om dit te kunnen doen, dient een overerfde zib of informatiebouwsteen te worden onterfd, alvorens wijzigingen te kunnen doorvoeren.
Op deze manier ontstaan nieuwe informatiebouwstenen, welke volledig naar informatiebehoefte zijn gemaakt maar waarbij toch zoveel mogelijk de generieke zibs blijven behouden. Hierbij geldt wel dat alleen optionele elementen uit een zib kunnen worden verwijderd en niet de elementen die de kern van een concept omvatten; alleen dan is een nieuwe bouwsteen compatibel met oorspronkelijke zib.
Om in een dataset meer duiding te geven aan de toepassing van een zib, kan na onterven de naamgeving van een zib worden hernoemd. Als voorbeeld: in de dataset voor de informatiestandaard Geboortezorg wordt de zib Probleem twee keer toegepast maar elk in een andere context. Daarom is de zib Probleem voor de twee contexten hernoemd naar respectievelijk ProbleemKind en ProbleemMoeder. In de referentie van de zib is nog steeds zichtbaar dat voor elk van de twee contexten de zib Probleem de basis is.
Edoch, middels het plaatsen van een zib in een datagroep met een context kan ook duiding worden gegeven aan de specifieke toepassing van een zib in een dataset. Dit is beschreven in paragraaf 2.2.3 Verwijzingen. Uit oogpunt van herkenning van het gebruik van zibs en het gebruik van ADA is de voorkeur om datagroepen met context te gebruiken boven het hernoemen van zibs.

'''2.2.3 Verwijzingen'''

In een dataset kan een verwijzing vanuit een informatiebouwsteen naar een andere informatiebouwsteen of losse gegevenselementen worden gemaakt. Dit wordt gedaan wanneer een generieke informatiebouwsteen – in de meeste gevallen een zib – binnen een dataset meerdere keren op de zelfde wijze wordt gebruikt. Bij een verwijzing worden dus de gegevens van de informatiebouwsteen waar naar verwezen wordt ook opgenomen binnen de informatiebouwsteen van waaruit verwezen wordt. Door de verwijzing te maken in een datagroep met een specifieke context, zijn de gegevens vanuit de verwezen bouwsteen daarmee ook van toepassing op deze context.
Hieronder is een voorbeeld van de zib Labuitslag waarin gegevens over de laboratoriumverantwoordelijke, aanvrager en de uitvoerder zijn opgenomen. Voor drie verschillende contexten wordt steeds de zib Zorgverlener gebruikt; elk dus met een specifieke context. Hieronder de uitwerking van dit voorbeeld in ART DECOR, in blauw omrand:

[[File:Opstellen_dataset_paragraaf2.2.png|576×254px]]

In dit voorbeeld staat de zib Zorgverlener elders in de dataset uitgewerkt. Deze uitwerking is dus van toepassing op de drie contexten waarin deze zib wordt gebruikt.
Verwijzingen tussen informatiebouwstenen en/of losse gegevenselementen worden doorgaans binnen één dataset te worden gemaakt (want je kunt in principe ook verwijzen naar bouwstenen die in een andere dataset staan). Alleen in dat geval is er op de volledige dataset, inclusief de bouwstenen waar naar wordt verwezen, volledig beheer mogelijk.

'''2.2.4 Relaties'''

In een dataset kunnen ook relaties worden gelegd tussen informatiebouwstenen. Het verschil met het maken van een verwijzing is dat bij een relatie vanuit een bouwsteen naar een andere bouwsteen niet de gegevens van die gerelateerde bouwsteen worden opgenomen maar zijn wel te herleiden.
Als bijvoorbeeld gegevens over een medicatieafspraak worden uitgewisseld, dan wil men weten of er een relatie is met een andere medicatieafspraak (start- en stop afspraken over dezelfde medicatie), toedieningsafspraak, medicatiegebruik, contact waarin de medicatieafspraak is gemaakt en de zorgepisode. Het is dan niet de bedoeling om alle gegevens over al deze bouwstenen mee te sturen, alleen om welke specifieke instantiaties van deze bouwstenen het gaat. Dit kan worden gedaan door een relatie te leggen naar de identificatie van deze specifieke instantiaties van de bouwstenen middels het Object Identifier (OID).
Het OID nummer is samengesteld uit een deel met de identificatie van de uitgevende organisatie – de zorgaanbieder van waaruit gegevens worden verstuurd – en een deel met de identificatie van een uniek gegeven dat is opgeslagen in het informatiesysteem van deze zorgaanbieder. Voor meer uitleg hierover zie de informatie op de HL7 site.
Hieronder de uitwerking van dit voorbeeld, waarin de relaties naar de OID’s van andere bouwstenen oranje zijn omkaderd:

[[File:Opstellen_dataset_paragraaf2.2.4png.png|576×254px]]

Om een volledig overzicht te hebben van alle relaties tussen informatiebouwstenen en gegevenselementen in een dataset, is het zeer aan te bevelen om een datamodel te maken voor elke usecase.

'''2.2.5 Invoegen en verwijderen dataelementen en (waarden in) waardelijsten'''

Zoals in hoofdstuk 2.1.4 reeds is toegelicht kunnen in een dataset ook afzonderlijke dataelementen en/of (waarden in) waardelijsten worden toegevoegd of verwijderd.
Het toevoegen of juist verwijderen van dataelementen – of groepen met dataelementen – binnen een informatiebouwsteen zorgt ervoor dat een informatiebouwsteen specifieker wordt gemaakt. In gegevensuitwisselingen binnen één domein (bijvoorbeeld huisartsen) kan het nodig zijn om specifieke elementen toe te voegen. Als voorbeeld is het toegevoegde dataelement ‘Presentatierol’ in de zib ‘Zorgverlener’ binnen het huisartsendomein.
Een dergelijke toevoeging moet altijd goed worden overwogen, zoals ook al in hoofdstuk 2.1.4 is toegelicht. Dit heeft namelijk ook consequenties voor het HL7 materiaal. Daarbij draagt een toevoeging ten behoeve van één domein niet bij aan standaardisatie van gegevensuitwisselingen over de domeinen heen. Zo zal een ‘Presentatierol’ in een gegevensuitwisseling van een huisarts naar een medisch specialist geen nut hebben.
Verwijdering van één of meerdere gegevenselementen uit een zib of informatiebouwsteen in de dataset wordt gedaan als deze in geen enkele gegevensuitwisseling van de informatiestandaard voorkomt. Belangrijk is wel dat het concept van de zib daarmee niet wordt aangetast; alleen optionele elementen in een zib mogen worden verwijderd.
Ook waardelijsten kunnen in zijn geheel worden toegevoegd of verwijderd, maar ook specifieke waarden ín een waardelijst. Een regelmatig voorkomende situatie is dat een waardelijst in een zib teveel algemene waarden bevat voor een gegevensuitwisseling en/of dat er specifieke waarden ontbreken. In dat geval wordt er een waardelijst op maat gemaakt ter vervanging van de initiële zib-waardelijst. Ook kan het voorkomen dat in een gegevensuitwisseling binnen één domein een aparte waardelijst van gelijke conceptuele strekking kan worden gebruikt. Denk hierbij aan specifieke NHG-tabel waardelijsten zoals NHG-tabel 12 ‘Soort derde’ naast de Vektis AGB AfdelingSpecialismeCodelijst.
In de handleiding voor ART DECOR [Documentatie-ART] is beschreven hoe dit in zijn werk gaat. Door te koppelen aan een dataelement wordt er context gegeven aan hoe een waardelijst wordt gebruikt in gegevensuitwisseling.
Ook kunnen waardelijsten zelf worden opgesteld en ingevoegd worden. In dit geval is het van belang om de termen in deze waardelijst te toetsen bij het Terminologiecentrum. Het Terminologiecentrum zorgt er dan voor dat de termen worden gekoppeld aan termen in codestelsels zoals SNOMED CT of LOINC. In het volgende hoofdstuk wordt hier verder op ingegaan.

===Terminologie in datasets===
Deze paragraaf biedt een werkvoorschrift voor het vastleggen van terminologiekoppelingen in ART-DECOR met een onderbouwing voor de keuze in werkwijze. Het document gaat hoofdzakelijk in op de werkvoorschriften omtrent SNOMED-termen, terwijl er verschillende (inter)nationale terminologiestelsels zijn. Gezien SNOMED het meest complexe stelsel is met de meeste regels, is vooral ten aanzien van SNOMED-terminologiekoppelingen een leidraad nodig om te komen tot consistentie binnen en tussen informatiestandaarden. Tot slot, huidig document gaat uit van ART-DECOR 2. Momenteel biedt ART-DECOR 3 niet dezelfde opties. Bij doorontwikkeling van ART-DECOR 3 zal gekeken worden welke opties noodzakelijk zijn (zie BITS-issues binnen het project ART-DECOR).

'''2.3.1 Terminologiekoppelingen'''

Een dataset wordt gecodeerd via het aanbrengen van terminologiekoppelingen. Dit omvat terminologiekoppelingen bij dataset-concepten en bij waardes in waardelijsten. In de [https://nictiz.nl/app/uploads/2025/05/20250507-Richtlijn-terminologie-koppelen-v1.0.pdf Richtlijn terminologie koppelen] geeft het Terminologiecentrum achtergrondinformatie over de verschillende terminologiestandaarden en worden handvatten geboden voor het uitvoeren van terminologiekoppelingen en het gebruik van terminologie in informatiestandaarden.

'''2.3.1.1 Dataset-concepten'''

Aan een dataset-concept kan een definitiecode via een terminologiekoppeling toegekend worden. In de Leidraad terminologiestandaarden (paragraaf 4.2) zijn de regels terug te vinden om te komen tot een juiste terminologiekoppeling als definitiecode van een dataset-concept. De naam van het dataset-concept zou overeen moeten komen met een beschrijving van het gekoppelde terminologieconcept, die door de beheerder van het stelsel geaccordeerd is (in SNOMED betreft dit een vertaling uit de Nederlandse extensie en in LOINC een vertaling uit de Nederlandse taalset van het Regenstrief). Terminologiekoppelingen van dataset-concept en waardelijst zouden op elkaar afgestemd moeten zijn (via vraag en antwoord of op basis van hoofdcategorie en verfijning). Waar mogelijk dient context gebruikt te worden: een gedetailleerd dataset-concept kan gekoppeld worden aan een generiek terminologieconcept, mits de ontbrekende informatie uit de andere terminologiekoppelingen blijkt.

'''2.3.1.2 Waardelijsten'''

Dataset-concepten kunnen een waardedomein hebben waarin concepten worden benoemd die als waarde kunnen dienen. Deze waardes behorende bij een dataset-concept kunnen op twee manieren vastgelegd worden in ART-DECOR: via de Waardelijst-editor (gecodeerde waardes) of via de Dataset-editor (ongecodeerde conceptnamen). De Waardelijst-editor is best practice. Via de Waardelijst-editor is het waardedomein te definiëren via het koppelen van een waardelijst. Deze waardelijst kan bestaan uit een geheel codesysteem of deel van een codesysteem (referentieset, tabel, etc.), een query van codes in een codesysteem (bijvoorbeeld: ‘is-een-kind-van’) of een selectie van losse codes. Indien het waardedomein is gedefinieerd via een selectie van losse codes, wordt in ART-DECOR tevens terminologie bij de codes vastgelegd. In de overige gevallen haalt de softwareleverancier de terminologie op bij het codesysteem (bij voorkeur via de Nationale Terminologieserver).
Het opbouwen van een lijst met ongecodeerde conceptnamen (via de Dataset-editor) kan als aanzet dienen tot het opbouwen van een lijst met gecodeerde conceptnamen (via de Waardelijst-editor). Indien er vanuit gebruikers behoefte is om in de informatiestandaard aanvullend andere termen op te nemen dan die in het terminologiestelsel staan opgenomen, heeft het voorkeur om hiervoor het veld Omschrijving te gebruiken in plaats van een aanvullende lijst met ongecodeerde conceptnamen. Overigens wordt deze lijst met ongecodeerde conceptnamen niet verwerkt in de technische berichten, maar deze dient door leveranciers separaat opgehaald te worden vanuit ART-DECOR.

'''2.3.2 Terminologievelden'''

ART-DECOR biedt verschillende velden om termen bij een terminologiecode vast te leggen. Dit betreffen de velden Weergavenaam (displayName), Benamingen (designation) en Omschrijving (description).
In de documentatie over ART-DECOR worden deze velden als volgt omschreven:
*displayName: The optional human readable display name for the code for orientation purposes. This display name corresponds to an official display name or synonym for the code in the code system.
*designation: Designations are language dependent display names for the code. For any language there might be multiple, each specifying the type (fully specified name, preferred, synonym, …).
*description: You may add a description for convenience, but should note that most of the time the description here overlaps with the designation/description of the coded concept.
Wat getoond wordt in ADA in het dropdownmenu bij het maken van kwalificatiemateriaal, is afhankelijk van wat ingevuld is in ART-DECOR bij het opbouwen van de waardelijst. Tekst uit het veld description wordt niet getoond in ADA.
Voor de specifieke toepassing van deze velden in zibs en informatiestandaarden is na overleg tussen informatieanalisten, informatiearchitecten van het Zib-centurm, terminologen en HL7-specialisten functie/ doel als volgt gedefinieerd:
*Weergavenaam: Leesbare weergave van de terminologiecode, waarbij de term afkomstig is uit het oorspronkelijke codesysteem. Dit is een hulp ter herkenning voor informatieanalisten, informatiearchitecten, terminologen, HL7-specialisten, softwareontwikkelaars en zorgverleners die betrokken zijn bij de ontwikkeling en het beheer van een zib of informatiestandaard.
*Benaming (volledig gespecificeerde naam): Hulp voor informatieanalisten en terminologen ter validatie van de terminologiekoppeling.
*Omschrijving: Toelichting ter verduidelijking van de betekenis van de gekoppelde terminologiecode, in aanvulling op terminologie uit het oorspronkelijke codesysteem. Dit kan een definitie van de waarde betreffen, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of de userinterfaceterm.

Het opnemen van terminologie in ART-DECOR uit een codesysteem heeft consequenties voor het beheer van een zib of informatiestandaard: bij elke release van een zib of informatiestandaard zal via het TerminologyReport gecontroleerd moeten worden of de terminologie in ART-DECOR nog overeenkomt met de terminologie in het codesysteem (een term kan in de tussentijd, tussen release van een zib of informatiestandaard en een meer recente release van het codesysteem, veranderd zijn in het codesysteem), net zoals gecontroleerd dient te worden of een terminologiecode niet is komen te vervallen.
Bij het vastleggen van terminologie in ART-DECOR kan gebruik gemaakt worden van de selectietool. Met deze tool kan een concept in een codesysteem worden opgezocht en worden opgenomen in de waardelijst. De terminologie is afkomstig uit een lokale kopie van het codesysteem. Terminologie wordt niet automatisch bijgewerkt als deze in het codesysteem verandert.
Indien gebruik gemaakt wordt van de selectietool in ART-DECOR voor het inladen van SNOMED-concepten, wordt voor het veld Weergavenaam de Nederlandse fully specified name ingeladen (indien er een Nederlandse vertaling beschikbaar is) en voor het veld Benamingen de fully specificied name, preferred term en synonyms in de beschikbare talen. Om de best practice uit dit document te volgen, kan het nodig zijn om de ingeladen termen via de selectietool aan te passen.
Gezien er een aantal jaar geleden nog weinig Nederlandse vertalingen van SNOMED beschikbaar waren, kunnen bij terminologiecodes in eerder gepubliceerde zibs en informatiestandaarden nog Engelstalige termen staan. Inmiddels heeft het merendeel van de SNOMED-termen een Nederlandse vertaling. Indien een vertaling toch ontbreekt, dient deze aangevraagd te worden bij het Terminologiecentrum.
Soms maakt het Terminologiecentrum een nieuwe SNOMED-code aan binnen de Nederlandse extensie, wanneer er geen geschikte SNOMED-code is binnen de internationale versie. Deze nieuwe SNOMED-code zal in de meeste gevallen nog niet opgenomen zijn in de huidige gepubliceerde versie van SNOMED op moment van release van de zib of informatiestandaard. In dat geval dient de term bij de terminologiecode handmatig ingevoerd te worden. Let hierbij op dat de Nederlandse SNOMED-termen beginnen met een kleine letter en de Engelstalige SNOMED-termen met een hoofdletter.

'''2.3.2.1 Dataset-concepten'''

'''2.3.2.1.1 Weergavenaam'''

Bij het aanbrengen van een terminologiekoppeling bij een dataset-concept biedt ART-DECOR één veld, namelijk Weergavenaam, om een term in tekst mee te geven bij de code. Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse fully specified name te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een waarde). Er is gekozen voor de volledig gespecificeerd naam, gezien deze term niet alleen een leesbare weergave biedt bij de code, maar tevens validatie van de terminologiekoppeling mogelijk maakt.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2 Waardelijsten'''

'''2.3.2.2.1 Weergavenaam '''

Het veld Weergavenaam dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient dit veld de Nederlandse preferred term te bevatten (in tegenstelling tot het veld Weergavenaam van een terminologiekoppeling van een dataset-concept). Er is gekozen voor de Nederlandse preferred term, gezien deze term het beste aansluit bij het doel van het bieden van een leesbare weergave van de terminologiecode. De fully specificied name in SNOMED bevat een semantic tag, waarbij kennis van SNOMED vereist is om deze te kunnen interpreteren. Bovendien is de fully specified name langer dan de preferred term, wat een onoverzichtelijkere weergave kan betekenen.
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.

'''2.3.2.2.2 Benamingen'''

Het veld Benaming (type volledig gespecificeerde naam) dient altijd gevuld te worden.
Indien gebruik gemaakt wordt van SNOMED, dient in dit veld de Nederlandse fully specified name opgenomen te worden. De fully specified name bevat de semantic tag die aangeeft in welke SNOMED-hiërarchie het concept valt, waardoor het mogelijk is om te beoordelen of de terminologiekoppeling correct is (op basis van de semantic tag kunnen bepaalde inconsistenties in een waardelijst in het oog springen, waar anders gemakkelijk overheen gekeken kan worden).
Indien gebruik gemaakt wordt van LOINC, gebruiken we de volledige naam, welke overeenkomt met de long common name. Omdat Regenstrief de Nederlandse vertaling hiervan niet in LOINC heeft overgenomen, kan ervoor gekozen worden deze uit de labcodeset te halen, of hier te downloaden. Deze moet dan wel handmatig overgenomen worden.
De overige typen Benamingen (type voorkeursterm en type synoniem) dienen niet gevuld te worden. Deze velden vervullen, in tegenstelling tot Benaming (type volledig gespecificeerde naam), geen specifieke functie in het functioneel ontwerp van een informatiestandaard of zib.

'''2.3.2.2.3 Omschrijving'''

Het veld Omschrijving wordt gevuld afhankelijk van de behoeften van de eindgebruikers van de zib of informatiestandaard. In het veld Omschrijving kan tekst meegegeven worden die niet in het codesysteem opgenomen staat. Dit kan een toelichting zijn ter verduidelijking van de betekenis van de gekoppelde terminologiecode in aanvulling op terminologie uit het oorspronkelijke codesysteem, een definitie van de waarde, de praktijkterm die de basis vormde voor koppeling van de terminologiecode, of (suggestie voor) de userinterfaceterm. Dit veld is daarmee een hulp voor ontwikkelaars om te komen tot een geschikte benaming in de userinterface.
Indien het veld Omschrijving een userinterfaceterm bevat, hebben informatieanalist/informatiearchitect en terminoloog gevalideerd dat deze term en gekoppelde terminologiecode overeenkomen in betekenis binnen de context van de waardelijst. Een userinterfaceterm kan specifieker zijn dan de term in het codesysteem door de context die de waardelijst meegeeft, of juist meer generiek, doordat de context van de waardelijst een specifieke benaming van de waarde overbodig maakt.
Indien er met de betrokken partijen afgesproken is dat het beheer van de gebruikte terminologie van een waardelijst binnen de informatiestandaard valt, waarbij er afspraken gemaakt zijn over de letterlijke term die op de gebruikersinterface getoond dient te worden, is dit veld onderdeel van de kwalificatie.
2.3.3 Het maken van gespecialiseerde waardelijsten
Zoals in 2.2.5 is benoemd kan het nodig zijn om een waardelijst van een geërfde bouwsteen te vervangen door een gespecialiseerde waardelijst. In het geval dat er een beperkt aantal concepten aan de oorspronkelijke waardelijst moeten worden toegevoegd of juist verwijderd zijn er twee alternatieven:
*Een kopie maken van de waardelijst van de geërfde bouwsteen en deze bewerken. De relatie van de nieuwe waardelijst met de oorspronkelijke waardelijst gaat verloren. Wijzigingen in de oorspronkelijke waardelijst worden niet doorgevoerd op de gespecialiseerde waardelijst. Je kiest hiervoor als de gespecialiseerde waardelijst niet lijkt op oorspronkelijke waardelijst, bijvoorbeeld omdat de gespecialiseerde waardelijst een opsomming is van mogelijke waarden en de oorspronkelijke een codestelsel, of een deel van een codestelsel gespecificeerd met een intensionele expressie.
*De waardelijst van de geërfde bouwsteen includeren in de gespecialiseerde waardelijst. Hierbij blijft de relatie met de oorspronkelijke waardelijst zichtbaar. Dit kan op twee manieren:
*Statische inclusie: een specifieke versie van de waardelijst wordt geïncludeerd (deze zal niet meer wijzigen)
*Dynamische inclusie: de laatste versie van de waardelijst wordt geïncludeerd. Doorgaans wordt bij een gespecialiseerde lijst geen dynamische inclusie toegepast. Maar indien hier wel voor is gekozen, moet ervoor wordt gewaakt of de inclusie en de zelf toegevoegde waarden inderdaad volledig disjunct zijn en blijven zodat er geen dubbelingen ontstaan. Het alternatief is om de eigen toevoegingen mee te laten nemen in de volgende release van een waardelijst.
De extra concepten, nodig voor de specialisatie, kunnen los worden toegevoegd of met Inclusies. Bij deze laatste methode moet een intentionele expressie worden ingevuld. Concepten uit de waardelijst van de geërfde bouwsteen die juist niet gewenst zijn in de gespecialiseerde waardelijst, kunnen met exclusies worden uitgesloten (ook weer met intentionele expressie).

===Generieke modelering – afspraken===

In hoofdstuk 2.2.4 is uitgelegd dat er tussen de verschillende bouwstenen en/of dataelementen in bouwstenen relaties kunnen worden gelegd. Deze relaties geven context aan of nadere aanvulling van gegevens. In het kader van standardisatie van gegevensuitwisseling niet alleen binnen één informatiestandaard maar ook in standaardisatie tussen alle informatiestandaarden is het belangrijkom dit soort relaties op een zoveel mogelijk eenduidige manier te doen. Als in alle informatiestandaarden op dezelfde manier relaties en modeleringen van gegevens worden gemaakt, is het voor de informatieanalisten veel eenvoudiger om te bepalen wat er in de verschillende informatiestandaarden aan gegevens worden uitgewisseld en hoe dit op elkaar aansluit. Evenzo belangrijk is dat de technische specificaties in HL7 berichten veel meer generiek kunnen worden uitgewerkt.

==Samenstellen scenario’s==

Een Nictiz informatiestandaard bevat minimaal één maar meestal meerdere usecases. Een usecase is een beschrijving van een informatie-uitwisseling op een specifiek moment in het zorgproces, waarbij voor een concrete praktijksituatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Zoals eerder gemeld staan alle usecases van één informatiestandaard beschreven in een functioneel ontwerp.
De specifieke gegevens die worden uitgewisseld binnen elk van de usecases zijn een subset van de dataset voor een gehele informatiestandaard. Daarom moet voor elke usecase een datascenario worden aangemaakt. In dit hoofdstuk wordt verder ingegaan op de keuzes en mogelijkheden voor het samenstellen van een datascenario.
N.B.: In dit document wordt consequent de term ‘datascenario’ gebruikt in plaats van de term ‘scenario’ zoals dat wordt gebruikt in ART DECOR. De reden is dat ‘scenario’ een term is die breed kan worden opgevat en daarom met verschillende betekenissen in velerlei documentatie wordt gebruikt. ‘Datascenario’ geeft meer context aan de betekenis voor dit document.

===Usecase en datascenario===
In principe wordt er voor elke usecase binnen een informatiestandaard een datascenario samengesteld. De naamgeving van een datascenario volgt veelal de hoofdlijn van elke usecase. Bijvoorbeeld in de informatiestandaard Acute zorg is er de usecase ‘Uitwisseling ambulance naar SEH’ waarvoor het datascenario ‘AMB (ambulance) draagt over aan SEH (Spoedeisende hulp)’ is samengesteld.
Het kan voorkomen dat de inhoud van de gegevensuitwisseling voor meerdere usecases binnen één informatiestandaard hetzelfde is. In dit geval wordt er voor meerdere usecases één datascenario samengesteld, waarbij in de naamgeving van het datascenario de meerdere usecases worden benoemd. Rugten naar ‘scenario

===Datascenario, transactiegroepen en transacties===
Elk datascenario is opgebouwd uit één of meerdere transactiegroepen. Een transactiegroep bevat alle transacties die bijdragen aan één specifieke gegevensuitwisseling tussen twee partijen.
Vaak is het zo dat binnen één datascenario ook maar één transactiegroep wordt gebruikt maar het is evengoed mogelijk om binnen één datascenario meerdere transactiegroepen te gebruiken, dit wordt verderop in dit hoofdstuk toegelicht.
Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.
Elke transactiegroep kan weer één of meerdere transacties bevatten. Een transactie is een werkelijke overdracht van gegevens.
Een transactiegroep waarin berichten worden verstuurd, bevat doorgaans een transactie met de verstuurde gegevens en een transactie met de ontvangstbevestiging. Dit zijn een zogenaamde push-transacties: overdrachten van gegevens waarbij de verzender op eigen initiatief een bericht verstuurt en waarbij de ontvanger dit bericht ontvangt zonder dat daarvoor actief naar is gevraagd.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het versturen van een specifieke gegevensset, ofwel dat het gaat om een ontvangstbevestiging. Vaak wordt deze transactie als overbodig beschouwd en daarom achterwege gelaten.

Een transactiegroep waarin gegevens worden geraadpleegd, bevat doorgaans een transactie met de raadpleging op maat en een transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Dit is een zogenaamde pull-transactie: een overdracht van gegevens waarbij de ontvanger van deze gegevens actief om heeft gevraagd en waarbij de verzender deze gegevens beschikbaar heeft gesteld.
In ART-DECOR wordt in de naamgeving van deze transacties aangegeven dat het gaat om het raadplegen van een specifieke gegevens set, ofwel dat het gaat om het beschikbaarstellen van de geraadpleegde gegevens.
Zoals eerder gemeld kan er in een transactiegroep in plaats van één transactie met alle benodigde gegevens ook worden gekozen voor het toepassen van meerdere transacties voor het versturen van gegevens: bijvoorbeeld één transactie per (zorginformatie-)bouwsteen. Deze constructie kan worden toegepast als er één datascenario wordt gebruikt voor meerdere usecases, waarbij het merendeel van de verstuurde gegevens gelijk is, maar waar er per usecase soms wel of niet een extra bouwsteen moet worden meegestuurd. Een voorbeeld hiervan is het opvragen van de professionele samenvatting door meerdere raadplegende partijen in de acute zorg – de meldkamer, ambulance en de SEH – waarbij de meldkamer geen gegevens over overgevoeligheden wil ontvangen. In dit geval is er geen transactie met de bouwsteen voor overgevoeligheden.
Als voorbeeld voor de hierboven beschreven samenstelling van datascenario’s met transactiegroepen en push- en pull-transacties dient wederom de informatiestandaard voor acute zorg. met hieronder een aantal usecases waarvoor datascenario’s zijn samengesteld met push-transacties, zoals:
*Berichten van de ambulance naar de SEH
*Verwijzen van een patiënt van (waarnemend) huisarts naar de meldkamer
*Versturen rapportages van meldkamer, ambulance en SEH naar de huisarts
In het plaatje hieronder is een uitwerking van het datascenario voor berichten van de ambulance naar de SEH:

[[File:Opstellen_dataset_paragraaf_3.2a.png|576×254px]]

En een drietal usecases waarvoor één datascenario is samengesteld met pull-transacties:
*Opvragen van de professionele samenvatting bij de huisarts door de meldkamer, ambulance of SEH

[[File:Opstellen_dataset_paragraaf_3.2b.png|576×254px]]

In ART-DECOR worden de transacties binnen een datascenario gegroepeerd tot een transactiegroep. In datascenario’s waarin berichten worden verstuurd, bestaan een transactiegroep uit de transactie met verstuurde gegevens en de transactie met de ontvangstbevestiging. In datascenario’s waarin gegevens worden geraadpleegd bestaat de transactiegroep uit de transactie met de raadpleging op maat en de transactie met de beschikbaargestelde gegevens – of meerdere transacties als de beschikbaargestelde gegevens in aparte bouwstenen worden verstuurd. Bij elke transactiegroep wordt in ART-DECOR een diagram getoond van alle voorkomende transacties tussen de betrokken partijen. Doorgaans worden deze betrokken partijen aangeduid met systeemrollen.

===Transactiedataset===
Per transactie wordt er een specifieke set gegevens verstuurd van de verzender naar de ontvanger. In een transactiedataset is dit gedetailleerd uitgewerkt. Alle gegevenselementen en (delen van) zibs en/of informatiebouwstenen n een transactiedataset worden betrokken uit de informatiestandaard dataset zoals beschreven in hoofdstuk 2. Andersom kan ook worden gezegd dat alle transactiedatasets van de transacties als onderdeel van een transactiegroep, die op hun beurt weer onderdeel zijn van een datascenario, tezamen de informatiestandaard dataset vormen.

'''3.3.1 Cardinaliteit en conformance'''
In een transactiedataset wordt per gegevenselement ook de kardinaliteit aangegeven. Op de informatiepagina van het zib-centrum is uitgelegd wat kardinaliteiten zijn: https://zibs.nl/wiki/Zib_kardinaliteiten
In informatiemodellen wordt kardinaliteit gebruikt om de multipliciteit van een element ten opzichte van zijn parent – of als het een top level element is, de multipliciteit van de boom eronder - in een transactie aan te geven. Daarbij wordt de notatie ‘m..n’ gebruikt, waarbij ‘m’ de minimale multipliciteit is en ‘n’ de maximale. In het model wordt de kardinaliteit genoteerd bij het element waarvoor dit geldt. Dus als er tussen element A en element B en relatie bestaat en bij element B de kardinaliteit m..n staat, betekent dit dat een element A minimaal met ‘m’ elementen B een relatie heeft en maximaal met ‘n’ elementen B
Naast de multipliciteit wordt met een letter aangegeven of deze relatie Mandatory, Required, Conditional of Optional is:

{| class="wikitable"
! M (Mandatory)
|Een gegeven moet altijd worden aangeleverd. De minimale multipliciteit is dan ook 1..1M
|-
! R (Required)
| Indien een gegeven beschikbaar is, moet deze worden aangeleverd. Bijvoorbeeld als één of meerdere voornamen van een patiënt bekend zijn. De kardinaliteit is in dit geval 0..*R
|-
! C (Conditional)
| Een gegeven dat moet worden aangeleverd, afhankelijk van de waarde of aanwezigheid van een ander gegeven. Bijvoorbeeld de invulling van een toelichting indien in een waardelijst de optie ‘Anders’ is geselecteerd. De kardinaliteit van de toelichting is in dit geval 1..1C
|-
! O (Optional)
| Een gegeven dat eventueel kan worden aangeleverd maar niet noodzakelijk. Deze optie wordt vrijwel niet toegepast. Als een gegeven niet noodzakelijk is binnen een overdracht, wordt deze in de regel ook niet opgenomen in een informatiestandaard.
|}

De kardinaliteiten zoals vastgesteld in de transactiedatasets zijn functioneel leidend. Op basis hiervan kan worden afgeleid wat er in een gegevensoverdracht aan gegevens moet worden meegestuurd. Een verzendende partij weet welke gegevens er moeten worden opgeleverd, al dan niet verplicht, verplicht indien beschikbaar of conditioneel. Een ontvangende partij weet wat er aan gegevens moet worden verwerkt en getoond kunnen worden.
Let op: de kardinaliteit in zibs zijn conceptueel; het kan dus voorkomen dat een kardinaliteit van een gegeven in een transactiedataset enger is als die in een zib. Dit geldt ook voor de kardinaliteiten in HL7v3 tempates en FHIR profielen; deze kunnen minder eng zijn als die in een transactiedataset.
Andersom is conceptueel niet mogelijk. Als iets conceptueel verplicht is of in bijvoorbeeld een FHIR profiel verplicht staat (zoals 1..1M), is het niet mogelijk om in de functionele transactiedataset hier geen verplichting aan te geven (zoals 0..1R).
Zoals in hoofdstuk 2.3.3 en 2.3.4 is uitgelegd kunnen in een dataset – en dus ook in een transactiedataset – verwijzingen en relaties voorkomen. Ook deze kennen kardinaliteiten. Bij verwijzingen geldt dat de bron-bouwsteen waar naar verwezen wordt in de dataset, ook in de transactiedataset moet voorkomen. De kardinaliteit van deze bron-bouwsteenen alle gegevens daarbinnen geldt dat voor alle contexten met verwijzingen. Als voorbeeld is wederom de LaboratoriumUitslag van hoofdstuk 2.3.3:

[[File:Opstellen_dataset_paragraaf_3.3.1.png|576×254px]]

Hierbij geldt dat in de bouwsteen LaboratoriumUitslag de kardinaliteit van de context – LaboratoriumUitslagVerantwoordelijke, Aanvrager en Uitvoerder – aangeeft hoe elk van deze contexten in het bericht moeten worden meegenomen. In dit geval dus alle drie verplicht. De kardinaliteit van de verwezen bouwstenen onder de context geeft aan dat áls er bijvoorbeeld een Uitvoerder is, dat dan de verwezen Zorgverlener óf Zorgaanbieder aanwezig moet zijn (vandaar de kardinaliteit van beiden 0..1 R). Bij de Aanvrager is er maar één mogelijkheid – de Zorgverlener – en vandaar dat deze dan ook mandatory is.
In de verwezen bron-bouwsteen Zorgverlener gelden vervolgens de kardinaliteiten zoals hierin is opgezet.

'''3.3.2 Raadplegen: Query Parameters'''

Voor de transactieset waarin gegevens worden opgevraagd door een partij (PULL), is vaak een selectie op de gegevens van toepassing.

Dit kan op twee manieren zijn ingericht in ART DECOR:
1. Vooraf vastgestelde selectie: als onderdeel van de transactie beschikbaarstellen
2. Variabele selectie: als query parameter in de transactie raadplegen

De eerste situatie is vooral van toepassing wanneer er landelijke afspraken zijn dat er altijd een standaard selectie wordt toegepast. Dit zorgt ervoor dat altijd eenzelfde overzicht voor een patiënt wordt gegenereerd. Bijvoorbeeld in de BgZ, is de “laatst bekende bloeddruk” in beschikbaarstellen opgenomen als 0..1 conditioneel:

[[File:Opstellen_dataset_paragraaf_3.3.2a.png|576×254px]]

De tweede situatie met query parameters, is van toepassing wanneer het nodig is een specifieke selectie per individuele raadpleging te maken. Bijvoorbeeld; de eindgebruiker van een systeem geeft zelf aan voor welke patiënt en in welke periode er informatie opgevraagd wordt. Welke gegevens als query parameters gebruikt kunnen worden, is afhankelijk van de usecase. Vaak zal er een identificatie(nummer) uit de Patiënt zib gebruikt worden zodat de raadpleging gericht voor één persoon plaats vindt.
In ART-DECOR dit worden ingericht, door in de dataset een groep “QueryParameters” op te nemen en dan de relevante parameters in de transactie(s) Raadplegen te gebruiken. Een parameter kan gebruik maken van een gegevenselement uit 1 bouwsteen, bijv. het identificatienummer van de Patiënt. Een andere mogelijkheid is dat een parameter gebruik maakt van 1 type gegeven die op meerdere plaatsen in de dataset voor komt, bijv. een datum(periode) waarin meerdere metingen (zoals bloeddruk, gewicht en lengte) uitgevoerd kunnen zijn.
Om duidelijk te maken aan wélke gegevens de parameters gelinkt zijn, kan je de in de dataset dit toelichten in de naam en omschrijving van de query parameter. Ook de zoekwijze kan je hier toelichten, zoals voor periodes waarin gezocht kan worden. Als daarnaast per transactie nog aparte regels gelden, kan je dit via het veld context bij de transactie uitleggen (en/of via een Conditie indien dit van toepassing is).
Als voorbeeld hieronder een weergave van de Gebruiksperiode in de transactie Raadplegen medicatieafspraak (MP 2.0.0): voor de gebruiksperiode is in de omschrijving van het concept aangegeven op welke conceptgroepen uit de dataset (“MA, WDS en TA”) de periode van toepassing is. Voor de transactie is dan ook nog een conditie opgenomen ter nadere specificatie.

[[File:Opstellen_dataset_paragraaf_3.3.2b.png|576×254px]]

=Release notes=
In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Ontwikkelen en Testen

2025-08-14T09:36:06Z

Lilian Brouwer: /* Instructies en templates */

qa:Hoofdproces

2025-08-14T09:35:14Z

Lilian Brouwer: /* Instructies en templates */

Bestand:Template Functioneel Ontwerp 3.0.1.docx

2025-08-14T09:32:45Z

Lilian Brouwer:

Bestand:Template Functioneel Ontwerp 3.0.0.docx

2025-08-14T09:23:41Z