Brontekst bekijken van qa:Instructie opstellen dataset

{| 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]
|}

<!-- BACK TO TOP BUTTON -->
<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>
<!-- EINDE BACK TO TOP BUTTON -->
<!-- QA -->
[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]
<!-- TITEL en INHOUDSOPGAVE die alleen Niveau 1 en 2 kopjes toont -->
__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Instructie opstellen dataset 3.0.0 {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>

==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
|-
|
|
|
|-
|}