Vdraft Handleiding Kardinaliteiten en conformance: verschil tussen versies
(→Versie geschiedenis/ Release notes: release notes aangemaakt) |
|||
| Regel 1: | Regel 1: | ||
__NOINDEX__ | __NOINDEX__ | ||
| − | {{IssueBox|'''<big> Consultatieversie ter verbetering van de originele editie | + | {{IssueBox|'''<big> Consultatieversie ter verbetering van de originele editie op 2-10-2026: [[Handleiding_Kardinaliteiten_en_conformance|"Handleiding Kardinaliteiten en conformance"]]. |
Wij willen graag nogmaals feedback bij de IA en SGU vakgroep ophalen om te evalueren of de herziene handleiding de openstaande vragen bij collega's beantwoord. | Wij willen graag nogmaals feedback bij de IA en SGU vakgroep ophalen om te evalueren of de herziene handleiding de openstaande vragen bij collega's beantwoord. | ||
Huidige versie van 2 okt 2026 om 17:49
|
|
Consultatieversie ter verbetering van de originele editie op 2-10-2026: "Handleiding Kardinaliteiten en conformance". Wij willen graag nogmaals feedback bij de IA en SGU vakgroep ophalen om te evalueren of de herziene handleiding de openstaande vragen bij collega's beantwoord. Link naar de feedback forms: https://forms.cloud.microsoft/e/j5xmNircwx Bedankt voor alle feedback op de originele handleiding. Deze hebben wij zo goed als mogelijk meegenomen. Met deze forms willen we jullie verzoeken om de verbetering te beoordelen. Vanuit de Informatieanalyse werkgroep is de handleiding over Kardinaliteiten en Conformance herzien. De aanleiding voor deze herziening was een combinatie van wijzigingsverzoeken en interne signalen als ook vanuit leveranciersvragen.
Voor deze handleiding hebben we originele scope expliciet gemaakt en de reikwijdte aangegeven. In het kort, gaat dit over informatiestandaarden VOOR het generieke bouwblokken tijdperk. De groep die verder gaat met de verwerking van feedback zijn: Lilian M., Madelaine en Ilias |
Inhoud
Introductie
Bij informatiestandaarden spelen de begrippen kardinaliteit, conformance en NullFlavor een belangrijke rol voor de eisen die gesteld worden in een functioneel ontwerp (in art-decor) en technisch ontwerp (zoals implementation guides of CDA-templates). Afhankelijk van de context en de mogelijke combinaties gelden andere eisen en afspraken voor de gegevensuitwisseling en systeemrollen. In deze handleiding kun je lezen hoe kardinaliteit, conformance en NullFlavor moeten worden geïnterpreteerd voor de informatiestandaarden van Nictiz. Dit vanuit een generiek en praktisch perspectief. Het kan voorkomen dat informatiestandaarden aanvullende eisen stellen aan de gegevensuitwisseling.
Scope en reikwijdte handleiding:
- Deze handleiding is alleen van toepassing op versies van informatiestandaarden die gemaakt zijn zonder de zibs 2.0 methodiek en niet opgebouwd zijn met generieke bouwblokken (GBB). Hoe conformance, kardinaliteiten en meer zal gaan werken voor informatiestandaarden die opgebouwd zijn met de GBB valt buiten scope van deze handleiding.
- Het is belangrijk om onderscheid te maken tussen eisen bij het uitwisselen en registreren van gegevens. Voor beide situaties kunnen andere afspraken gelden omtrent de kardinaliteit en conformance. Deze handleiding is primair gericht op uitwisseling van gegevens van een usecase. Wanneer binnen een informatiestandaard aanvullende afspraken zijn gemaakt over registratie, zoals een registratiescenario, zijn deze terug te vinden bij de usecases in het desbetreffende functionele ontwerp.
Eerst wordt uitgelegd waarom kardinaliteit, conformance en NullFlavor nodig zijn. Vervolgens worden deze begrippen afzonderlijk behandeld.
Daarna wordt aan de hand van praktijkvoorbeelden toegelicht hoe deze begrippen worden toegepast en hoe ze zich tot elkaar verhouden.
Gegevens uitwisselen: wat moet, wat mag en wat als een waarde ontbreekt?
Wanneer applicaties berichten met elkaar uitwisselen, gelden er afspraken over welke gegevens wel en niet in een bericht moeten of mogen staan. Dit wordt door de kardinaliteit en conformance van de elementen bepaald. De kardinaliteit geeft aan hoe vaak een element voor moet of mag komen. De conformance geeft aan of een element moet of mag worden meegestuurd en of er een waarde meegestuurd moet worden.
Aanvullend kan voor een element bepaald zijn of een reden voor ontbrekende gegevens is toegestaan. Dat kan met o.a. een NullFlavor, deze geeft de reden aan waarom er geen waarde wordt doorgegeven. NullFlavor komt voor in HL7v3. In FHIR komt dit ook voor, maar vaker gebruiken ze hier DataAbsentReason in de plaats.
Kardinaliteit
Een algemene definitie van kardinaliteit is: "een maat voor het aantal toegestane instanties van een element in een verzameling". Dit specificeert het minimale en maximale aantal keer dat een element in een bericht mag voorkomen.
| Kardinaliteit | Betekenis |
|---|---|
| 0..* | Het gegevenselement mag 0, 1 of meerdere keren voorkomen |
| 1..* | Het gegevenselement moet minimaal 1 keer en mag meerdere keren voorkomen |
| 0..1 | Het gegevenselement mag 0 of 1 keer voorkomen |
| 1..1 | Het gegevenselement moet precies 1 keer voorkomen |
Conformance
Conformance geeft aan welke verplichtingen er gelden voor de aanwezigheid van een element in een bericht. In de onderstaande tabel worden de verschillende types conformance beschreven.
| Conformance | Opstellen bericht (sturen/beschikbaarstellen) |
Verwerken bericht (ontvangen/raadplegen) | |
|---|---|---|---|
| M | Mandatory / vereist |
Element moet aanwezig zijn in bericht. Moet ingevoerde waarde bevatten; zonder waarde is bericht ongeldig. |
Element moet verwerkt1 worden. |
| R | Required / verplicht |
Systeem moet in staat zijn element en waarde te ondersteunen2. Bericht: Indien waarde aanwezig in systeem, moet bericht het element en waarde bevatten. Indien toegestaan in de definitie van het element, kan hierbij een NullFlavor in het bericht staan. |
Als element aanwezig, moet deze verwerkt1 worden. |
| O | Optional / optioneel |
Systeem mag element en waarde ondersteunen2. Element mag aanwezig zijn in het bericht. |
Het element mag verwerkt1 worden. |
| NP | Not Permitted / niet toegestaan |
Niet toegestaan, het element mag niet in het bericht voorkomen | NVT |
| C | Conditional / voorwaardelijk |
Conformance op het element is afhankelijk van (tekstuele) voorwaarden. De voorwaarden bepalen welke van bovenstaande conformances van toepassing is voor het bericht. | |
1Verwerken: Betreft het zonder problemen overweg kunnen gaan van het systeem met de aanwezigheid van een element. De exacte vorm van verwerken is niet eenduidig gedefinieerd, maar denk bijvoorbeeld aan tonen, opslaan, hergebruiken, etc. Het kan voorkomen dat informatiestandaarden aanvullende eisen over verwerken bevatten.
2Ondersteunen: Betreft het in staat zijn van het systeem om een element te voorzien van een waarde in een bericht.
In FHIR wordt geen gebruik gemaakt van conformance. De rol van conformance wordt in FHIR afgedekt met obligations, mustSupport flags en constraints. Deze zijn buiten scope van deze handleiding.
NullFlavor
NullFlavors worden gebruikt om aan te geven waarom een element zonder waarde verstuurd wordt. Of het gebruik van een NullFlavor is toegestaan is afhankelijk van de conformance en eventueel de coding strength. Een bericht kan per element een apart attribuut bevatten om een NullFlavor-waarde te versturen.
Een NullFlavor kan gebruikt worden om aan te geven dat:
- er geen waarde beschikbaar is in het bronsysteem (waarde NoInformation/NI);
- er een waarde aanwezig is in het bronsysteem die niet doorgegeven kan of mag worden (bijv. de waarde Masked/MSK of Invalid/INV);
- er een NullFlavor-waarde is vastgelegd in het bronsysteem (bijv. de waarde Other/OTH).
In dit overzicht zijn alle beschikbare NullFlavor-waarden te vinden. Als uitzondering voor de NullFlavor-waarden Other/OTH en Un-encoded/UNC geldt dat in een aanvullend tekstveld de nadere specificatie van deze waarde meegestuurd kan worden (de waarden Other en Un-encoded impliceren dat er wel een waarde bekend is, maar dat deze waarde niet voorkomt in de gedefinieerde waardelijst van het element).
NullFlavor in relatie tot coding strength
In HL7v3 wordt ‘coding strength’ gebruikt om bij een element met een waardelijst aan te geven of alleen de waarden uit de waardelijst gebruikt mogen worden, of dat ook andere waarden zijn toegestaan. Alleen bij coding strength “CNE” (Coded with No Exceptions: alléén waarden uit de betreffende waardelijst zijn toegestaan) is het gebruik van een NullFlavor toegestaan. In latere versies van HL7 is coding strength vervangen door ‘binding strength’. In FHIR zijn de NullFlavors vervangen door DataAbsentReason.
Gebruik in de praktijk
Samenhang tussen kardinaliteit en conformance
De eisen en verwachtingen die van toepassing zijn voor een bericht worden per element beschreven met een combinatie van kardinaliteit en conformance. Onderstaande tabel geeft aan wat de meest voorkomende combinaties zijn, wat de functionele betekenis daarvan is en of een nullFlavor is toegestaan.
| Kardinaliteit + conformance | Functionele betekenis | Voorbeeld |
|---|---|---|
|
0..1 Optional |
In het bericht mag het element aan- of afwezig zijn. Bij 0..1 mag het maximaal één keer voorkomen. Bij 0..* mag het meerdere keren voorkomen. Verzender en ontvanger zijn niet verplicht element en waarde te ondersteunen. Als het element wordt meegestuurd, mag ontvanger verwerken. |
Toelichting bij een verrichting: de toelichting mag worden meegestuurd, maar systemen hoeven deze niet te ondersteunen. |
|
0..1 Required |
In het bericht mag het element aan- of afwezig zijn. Bij 0..1 mag het maximaal één keer voorkomen en bij 0..* mag het meerdere keren voorkomen. Indien de waarde aanwezig is in het systeem moet het meegestuurd worden in het bericht. Verzender en ontvanger moeten element en waarde kunnen ondersteunen. Als het element wordt meegestuurd, moet ontvanger verwerken. |
E-mailadres patiënt: indien bekend bij systeem moet het e-mailadres meegestuurd worden. |
|
1..1 Required |
In het bericht moet het element aanwezig zijn. Bij 1..1 mag het maximaal één keer voorkomen en bij 1..* mag het meerdere keren voorkomen. Indien geen waarde aanwezig in systeem, moet een NullFlavor meegestuurd worden in het bericht. Verzender en ontvanger moeten element en waarde kunnen ondersteunen. Als het element wordt meegestuurd, moet ontvanger verwerken. |
Geboortedatum: De geboortedatum wordt altijd verwacht. Indien onbekend voor het systeem, dan moet een NullFlavor-waarde meegestuurd worden. |
|
1..1 Mandatory |
In het bericht moet het element aanwezig zijn. Bij 1..1 mag het maximaal één keer voorkomen en bij 1..* mag het meerdere keren voorkomen. Indien geen waarde aanwezig in systeem, is het verboden een NullFlavor mee te sturen. Zonder deze waarde mag het bericht niet verzonden worden. Verzender moet element en waarde ondersteunen. Ontvanger moet het element kunnen verwerken. |
BSN: Mandatory alleen voor usecases waarin is gegarandeerd dat iedere betrokken patiënt een BSN heeft en deze essentieel is. Er wordt precies één geldig BSN meegestuurd. Zonder BSN kan het bericht niet verstuurd worden. |
|
0..0 Not permitted |
In het bericht moet het element afwezig zijn. Deze conformance wordt voornamelijk gebruikt bij conditionele conformance. |
Zie onderstaand voorbeeld |
|
0..1 Conditional |
Op dit element gelden (tekstuele) voorwaarden voor welke kardinaliteit en conformance gelden op welk moment. De voorwaarden staan altijd beschreven in de informatiestandaard bij het element. |
Zie onderstaand voorbeeld |
Conditional conformance
Voorbeeld MedicatieafspraakStopType:
In de informatiestandaard Medicatieproces bevat de medicatieafspraak een conditional conformance voor het element MedicatieafspraakStopType (0..1C).
Voorwaarde: Het stoptype wordt uitsluitend in het bericht ingevuld wanneer een medicatieafspraak wordt gestopt of geannuleerd. In deze gevallen geldt kardinaliteit 1..1 en conformance R.
|
In het geval een |
➜ |
1..1 R |
Indien een medicatieafspraak niet wordt gestopt of geannuleerd, is het niet toegestaan om het stoptype in te vullen. Hier geldt kardinaliteit 0..0 en conformance NP.
|
In alle andere |
➜ |
0..0 |
Gebruik in combinatie met hiërarchieën van elementen (zoals containers of groepen)
Om elementen hiërarchisch te kunnen rangschikken wordt een container (ook wel groep genoemd) gebruikt. Een container kan een of meerdere elementen, containers en/of verwijzingen bevatten.
Containers kunnen voor verschillende doeleinden worden toegepast.
Cluster van elementen definiëren
Een container kan een aantal elementen bevatten die elkaar betekenis verlenen; los van elkaar hebben deze elementen veelal onvoldoende betekenis.
Een typisch voorbeeld is container Adresgegevens. Meerdere elementen moeten ingevuld zijn om een volledig adres vast te leggen; los van elkaar hebben de elementen onvoldoende betekenis. Alleen als deze gegevens in relatie tot elkaar worden weergegeven, kan een adres betekenisvol geïnterpreteerd worden.
Context toevoegen
Alleen als de container Adresgegevens binnen een andere container wordt geplaatst, wordt duidelijk op wie het adres betrekking heeft. Zo verleent de container Patiënt in het onderstaande voorbeeld context aan de container Adresgegevens. Bij het weergeven van de adresgegevens moet deze context ook getoond worden om ze betekenisvol te laten zijn.Toepassen van specifieke kardinaliteiten en/of conformance
Door aan een container een bepaalde kardinaliteit en conformance toe te kennen, hebben deze effect op alle elementen binnen de container.
In het onderstaande voorbeeld zorgt de kardinaliteit van de container Adresgegevens ervoor dat je meerdere adressen voor een patiënt vast kunt leggen.
Voorbeeld element: Patiënt
Een Patiënt heeft maar één set Naamgegevens, maar kan meerdere adressen hebben. Ook kan een Patiënt meerdere telefoonnummers en emailadressen hebben. Door deze structuur van containers met kardinaliteiten, kun je voor een Patiënt een keer de Naamgegevens invullen en meerdere clusters van Adresgegevens, Telefoonnummers en EmailAdressen.
Zou de kardinaliteit van Naamgegevens niet 1..1 maar 0..1 zijn, dan hoeft Naamgegevens niet ingevuld te worden. Als je Naamgegevens wel invult, dan moet tenminste de container Geslachtsnaam een waarde bevatten.NullFlavor
Tijdstip: Voor het sturen van een bericht is het verplicht gesteld dat het voorschrijftijdstip aanwezig is met conformance en kardinaliteit 1..1R. Helaas weet de verzender tijdens het opstellen van het bericht niet meer wanneer de medicatie is voorgeschreven en kan daardoor het voorschrijftijdstip niet invullen. Vanwege 1..1R zal dit element geen waarde bevatten en moet de NullFlavor “unknown” worden meegestuurd in het bericht.
Opleidingsniveau: Het element opleidingsniveau met kardinaliteit en conformance 1..1R bevat een waardelijst. Van een persoon is bekend dat deze de huishoudschool heeft gevolgd, maar deze waarde komt niet voor in deze lijst. In dit geval kan gebruik worden gemaakt van de NullFlavor “other”. In combinatie met <originalText> kan de opleiding als vrije tekst ingevuld worden en kan de informatie alsnog met het bericht mee worden gestuurd.
BSN: Een patiënt heeft zorg nodig maar het is niet mogelijk de BSN te achterhalen. Doordat de identificatie mandatory (1..1 M) is en daarom een waarde moet hebben, is het NIET toegestaan om een NullFlavor in te vullen. Er kan daarom geen bericht uitgestuurd worden totdat het BSN bekend is.
Versie geschiedenis/ Release notes
Versie Datum Auteur(s) Omschrijving 2.0.0 vDraft 2-10-2026 Gijs, Maaike, Taco en Yvette Consultatieversie ter review van de verbeteringen. Wijzigingen: scope afbakening, definities aangescherpt, begeleidende teksten opgesteld, tabellen leesbaarheid en context toegevoegd en meer voorbeelden aangemaakt. 1.0.0 16-03-2018 Marijke van Gijn, Alexander Henket, De eerste versie van de handleiding is opgesteld door Marijke van Gijn. In 2022 heeft Alexander Henket nog een toepassingsvoorbeeld als aanvulling gedaan.
