Vdraft Handleiding Kardinaliteiten en conformance: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
k
Regel 159: Regel 159:
 
|}
 
|}
  
 +
 +
=Gebruik in de praktijk=
 +
==Samenhang tussen kardinaliteit, conformance en nullFlavor==
 +
 +
Een conformance “required” betekent dat applicaties het data-element verplicht moeten implementeren. Bij deze conformance moet een data-element altijd meegestuurd en verwerkt worden '''ALS''' er een waarde is.
 +
 +
Bij een conformance “mandatory” moeten applicaties het data-element verplicht implementeren én moet er altijd een waarde in het bericht staan. Het kan hier niet voorkomen dat een data-element ontbreekt, ook niet als nullFlavor. Vandaar dat de kardinaliteit bij mandatory alleen 1..1 of 1..* moet zijn.
 +
 +
De onderstaande tabel vertaalt de meest voorkomende combinaties naar functionele afspraken. Daarbij is onderscheid gemaakt tussen het ontbreken van een element en het ontbreken van een inhoudelijke waarde.
 +
 +
{|
 +
!width="20%"| '''Kardinaliteit +''' '''conformance'''
 +
!width="48%"| '''Functionele betekenis'''
 +
!width="30%"| '''Voorbeeld'''
 +
|-
 +
| 0..1/0..* Optional
 +
| Het element mag ontbreken of één keer voorkomen. Ondersteuning en verzending zijn niet vereist. Als het element wordt meegestuurd, moet het aan de overige afspraken van de standaard voldoen.
 +
| Toelichting bij een verrichting: de toelichting mag worden meegestuurd, maar systemen hoeven deze niet te ondersteunen.
 +
|-
 +
| 0..1 Required
 +
| Verzender en ontvanger moeten het element ondersteunen. Een bekende waarde wordt één keer meegestuurd en verwerkt. Bij een bewust ontbrekende waarde kan, indien toegestaan, een NullFlavor worden gebruikt. Als het element niet van toepassing is, mag het ontbreken.
 +
| E-mailadres patiënt: bekend betekent meesturen; onbekend betekent een reden voor ontbreken meesturen indien toegestaan; heeft de patiënt geen e-mailadres, dan mag het element ontbreken.
 +
|-
 +
| 1..1 Required
 +
| Het element moet precies één keer voorkomen in het bericht en door verzender en ontvanger worden ondersteund. Bij een bekende waarde bevat het de inhoudelijke waarde; anders bevat het, indien toegestaan, een NullFlavor.
 +
| Geboortedatum: bekend betekent de datum meesturen; onbekend betekent het element met een toegestane reden voor ontbreken meesturen.
 +
|-
 +
| 1..1 Mandatory
 +
| Het element moet precies één keer voorkomen en een inhoudelijke waarde bevatten. Het mag niet ontbreken en NullFlavor is niet toegestaan.
 +
| BSN: alleen voor een usecase waarin is gegarandeerd dat iedere betrokken patiënt een BSN heeft. Er wordt precies één geldig BSN meegestuurd.
 +
|-
 +
|
 +
|
 +
|
 +
|-
 +
| 0..* Optional / Required
 +
| Het element mag nul, één of meerdere keren voorkomen. De verplichtingen van Optional en Required zijn gelijk aan die bij 0..1, maar gelden voor alle beschikbare en relevante voorkomens.
 +
| Contactgegevens: er kunnen geen, één of meerdere telefoonnummers of e-mailadressen worden uitgewisseld, afhankelijk van de usecase en conformance.
 +
|-
 +
| 1..* Required / Mandatory
 +
| Het element moet minimaal één keer voorkomen en mag vaker voorkomen. Bij Required mag een verplicht voorkomen, indien toegestaan, een reden voor ontbreken bevatten. Bij Mandatory moet ieder voorkomen een inhoudelijke waarde bevatten.
 +
| Resultaten: de usecase vereist ten minste één resultaat en staat meerdere resultaten toe; per resultaat geldt de gekozen conformance.
 +
|}
 +
 +
==Conditional conformance==
 +
 +
''Voorbeeld MedicatieafspraakStopType:''
 +
 +
In de informatiestandaard Medicatieproces bevat de medicatieafspraak een conditional conformance voor het element MedicatieafspraakStopType (0..1C).
 +
 +
Het stoptype wordt uitsluitend in het bericht ingevuld wanneer een medicatieafspraak wordt gestopt of geannuleerd. In deze gevallen geldt kardinaliteit van '''1..1''' en conformance '''R.'''
 +
 +
Indien een medicatieafspraak niet wordt gestopt of geannuleerd is het niet toegestaan om het stoptype in te vullen. Hier geldt kardinaliteit van '''0..0''' en conformance '''NP'''.
 +
 +
''<br />
 +
''
 +
==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.
 +
 +
<ul>
 +
<li><blockquote><p>'''Cluster van elementen definiëren'''<br />
 +
Een container kan een aantal elementen bevatten die elkaar betekenis verlenen; los van elkaar hebben deze elementen veelal onvoldoende betekenis.<br />
 +
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.</p></blockquote></li>
 +
<li><blockquote><p>'''Context toevoegen'''<br />
 +
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.</p></blockquote></li>
 +
<li><blockquote><p>'''Toepassen van specifieke kardinaliteiten en/of conformance'''<br />
 +
[[Bestand:Container handleiding.png|omkaderd|rechts|Voorbeeld Patiënt met containers Naamgegevens, Adresgegevens en Contactgegevens]]
 +
''Voorbeeld element: Patiënt''<br />
 +
Door aan een container een bepaalde kardinaliteit en conformance toe te kennen, hebben deze effect op alle elementen binnen de container.<br />
 +
In het onderstaande voorbeeld zorgt de kardinaliteit van de container Adresgegevens ervoor dat je meerdere adressen voor een patiënt vast kunt leggen.<br />
 +
<br />
 +
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.<br />
 +
<br />
 +
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.
 +
</blockquote>
  
 
==NullFlavor==
 
==NullFlavor==
  
−
==Toepassingsvoorbeeld==
+
'''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.
−
[https://terminology.hl7.org/6.5.0/CodeSystem-v3-NullFlavor.html NullFlavor] wordt in HL7v3 gebruikt om te duiden waarom een waarde er niet is. [https://terminology.hl7.org/6.5.0/CodeSystem-data-absent-reason.html Data Absent Reason] heeft in HL7 FHIR een vergelijkbare functie. Bindingsterkte ''required'' betekent dat alléén waarden uit de betreffende waardelijst zijn toegestaan.
+
 
 +
'''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 “OTH”. In combinatie met &lt;originalText&gt; kan de opleiding als vrije tekst ingevuld worden en kan de informatie alsnog met het bericht mee worden gestuurd.
  
−
* datasetconcept A is 1..1 M en heeft binding met sterkte ''required'' op een waardelijst met NullFlavor of Data Absent Reason
+
'''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.
−
* datasetconcept B is 1..1 R en heeft binding met sterkte ''required'' op een waardelijst met NullFlavor of Data Absent Reason
 
−
 
−
Welke van deze concepten mag in de uitwisseling een NullFlavor of DataAbsentReason krijgen?
 
−
 
−
a. Datasetconcept A<br/>
 
−
b. Datasetconcept B<br/>
 
−
c. Allebei<br/>
 
−
d. Geen van beide
 
  
−
Selecteer deze regel om het antwoord te zien. <span style="color: white;">Het juiste antwoord is ''b''. Een mandatory concept ''moet'' een waarde hebben en kan dus niet ontbreken. Hoewel de waardelijst NullFlavor ondersteunt, kunnen deze in dit geval niet worden gebruikt. Een required concept ''kan'' ontbreken en vanwege de kardinaliteit moet in dat geval worden geduid waarom.</span>
+
=Versie geschiedenis/ Release notes=

Versie van 25 sep 2026 om 13:07


Toelichting op kardinaliteit, conformance en NullFlavor

Aan het versturen van berichten door applicaties worden eisen gesteld qua het bevatten van concepten/elementen. Deze eisen worden per element kenbaar gemaakt door middel van kardinaliteit en conformance. Naast deze kardinaliteit en conformance is het ook van belang dat de betekenis van een nullFlavor (bewust leeg element) of het ontbreken van een element in een bericht duidelijk is. Hieronder worden deze toegelicht.

Bron: Implementatiehandleiding HL7v3 basiscomponenten - Nictiz/HL7 Nederland (gemigreerd uit wiki)

Kardinaliteit

Een algemene definitie van kardinaliteit is: "een maat voor het aantal elementen in een verzameling". Dit gaat over hoe vaak een bepaald element in een bericht voorkomt.

kardinaliteit betekenis
0..* Het gegevenselement mag 0, 1 of meerdere malen voorkomen
1..* Het gegevenselement moet minimaal 1 keer en mag meerdere malen voorkomen
0..1 Het gegevenselement mag 0 of 1 keer voorkomen
1..1 Het gegevenselement moet precies 1 keer voorkomen

Conformance

Conformance gaat over of een element verplicht opgenomen moet worden in een bericht.

voor zenders voor ontvangers
M Mandatory verplicht vullen met een waarde verplicht verwerken
R Required verplicht versturen indien bekend verplicht verwerken
C Conditional verplicht vullen in bepaalde gevallen conditioneel verwerken
O Optional optioneel versturen indien bekend optioneel verwerken

NullFlavor in een concept of ontbreken element in bericht:

  • NullFlavor betekent geen waarde in een meegestuurd element. Dit is dus anders dan het totaal ontbreken (niet meesturen) van een element.
  • Mandatory betekent dat applicaties het element verplicht moeten ondersteunen. Er moet altijd een waarde in het bericht staan, een nullFlavor (geen waarde) is niet toegestaan. Het element mag ook nooit ontbreken in het bericht (Mandatory is alleen mogelijk in combinatie met 1..1 of 1..*).
  • Required betekent dat applicaties het element verplicht moeten ondersteunen. Het moet meegestuurd en verwerkt worden als er een waarde is. Er mag echter bewust een nullFlavor verstuurd worden. Dit betekent dat de applicatie eventuele elementen met lege waarden aan de gebruiker presenteert. De gebruiker kan dan nog aanvullen (maar dat is niet verplicht) voordat het bericht verstuurd wordt.

Voorbeelden

0..1 of 0..* Required:

  • Element gevuld met waarde -> element met waarde wordt doorgestuurd.
  • Element bewust leeg gelaten (nullFlavor) -> element met nullFlavor wordt doorgestuurd. Dit is indien de gebruiker bewust niks invult omdat het bijvoorbeeld onbekend is.
  • Element in zijn geheel niet gebruiken -> het element wordt in zijn geheel niet doorgestuurd. Dit is indien het element niet van toepassing is. Deze optie is dus niet mogelijk in geval van 1..1 of 1..* kardinaliteit.
Conformance / Kardinaliteit Optioneel Required Mandatory
0..1

Invoer MAG mogelijk zijn
Hoeveel waarden ingevoerd?

0      → GEEN XML element
1      → 0 of 1 elementen

Invoer MOET mogelijk zijn
Hoeveel waarden ingevoerd?

0      → GEEN XML element
1      → 1 XML element (nullFlavor)
1      → 1 GEVULD element

NVT

0..*

Invoer MAG mogelijk zijn
Hoeveel waarden ingevoerd?

0      → GEEN XML element
1      → 0 of 1 elementen
N      → 0 tot N elementen

Invoer MOET mogelijk zijn
Hoeveel waarden ingevoerd?

0      → GEEN XML element
1      → 1 XML element (nullFlavor)
1      → 1 GEVULD element
N      → N GEVULDE elementen

NVT

1..1

Invoer MAG mogelijk zijn
Hoeveel waarden ingevoerd?

0      → LEEG XML element
1      → 1 element (evt. LEEG)

Invoer MOET mogelijk zijn
Hoeveel waarden ingevoerd?

0      → 1 XML element (nullFlavor)
1      → 1 GEVULD element

Invoer MOET VERPLICHT zijn
Hoeveel waarden ingevoerd?

0      → NIET toegestaan
1      → 1 GEVULD element

1..*

Invoer MAG mogelijk zijn
Hoeveel waarden ingevoerd?

0      → LEEG XML element
1      → 1 element (evt. LEEG)
N      → 1 (evt. LEEG) tot N elementen

Invoer MOET mogelijk zijn
Hoeveel waarden ingevoerd?

0      → 1 XML element (nullFlavor)
1      → 1 GEVULD element
N      → N GEVULDE elementen

Invoer MOET VERPLICHT zijn
Hoeveel waarden ingevoerd?

0      → NIET toegestaan
1      → 1 GEVULD element
N      → N GEVULDE elementen


Gebruik in de praktijk

Samenhang tussen kardinaliteit, conformance en nullFlavor

Een conformance “required” betekent dat applicaties het data-element verplicht moeten implementeren. Bij deze conformance moet een data-element altijd meegestuurd en verwerkt worden ALS er een waarde is.

Bij een conformance “mandatory” moeten applicaties het data-element verplicht implementeren én moet er altijd een waarde in het bericht staan. Het kan hier niet voorkomen dat een data-element ontbreekt, ook niet als nullFlavor. Vandaar dat de kardinaliteit bij mandatory alleen 1..1 of 1..* moet zijn.

De onderstaande tabel vertaalt de meest voorkomende combinaties naar functionele afspraken. Daarbij is onderscheid gemaakt tussen het ontbreken van een element en het ontbreken van een inhoudelijke waarde.

Kardinaliteit + conformance Functionele betekenis Voorbeeld
0..1/0..* Optional Het element mag ontbreken of één keer voorkomen. Ondersteuning en verzending zijn niet vereist. Als het element wordt meegestuurd, moet het aan de overige afspraken van de standaard voldoen. Toelichting bij een verrichting: de toelichting mag worden meegestuurd, maar systemen hoeven deze niet te ondersteunen.
0..1 Required Verzender en ontvanger moeten het element ondersteunen. Een bekende waarde wordt één keer meegestuurd en verwerkt. Bij een bewust ontbrekende waarde kan, indien toegestaan, een NullFlavor worden gebruikt. Als het element niet van toepassing is, mag het ontbreken. E-mailadres patiënt: bekend betekent meesturen; onbekend betekent een reden voor ontbreken meesturen indien toegestaan; heeft de patiënt geen e-mailadres, dan mag het element ontbreken.
1..1 Required Het element moet precies één keer voorkomen in het bericht en door verzender en ontvanger worden ondersteund. Bij een bekende waarde bevat het de inhoudelijke waarde; anders bevat het, indien toegestaan, een NullFlavor. Geboortedatum: bekend betekent de datum meesturen; onbekend betekent het element met een toegestane reden voor ontbreken meesturen.
1..1 Mandatory Het element moet precies één keer voorkomen en een inhoudelijke waarde bevatten. Het mag niet ontbreken en NullFlavor is niet toegestaan. BSN: alleen voor een usecase waarin is gegarandeerd dat iedere betrokken patiënt een BSN heeft. Er wordt precies één geldig BSN meegestuurd.
0..* Optional / Required Het element mag nul, één of meerdere keren voorkomen. De verplichtingen van Optional en Required zijn gelijk aan die bij 0..1, maar gelden voor alle beschikbare en relevante voorkomens. Contactgegevens: er kunnen geen, één of meerdere telefoonnummers of e-mailadressen worden uitgewisseld, afhankelijk van de usecase en conformance.
1..* Required / Mandatory Het element moet minimaal één keer voorkomen en mag vaker voorkomen. Bij Required mag een verplicht voorkomen, indien toegestaan, een reden voor ontbreken bevatten. Bij Mandatory moet ieder voorkomen een inhoudelijke waarde bevatten. Resultaten: de usecase vereist ten minste één resultaat en staat meerdere resultaten toe; per resultaat geldt de gekozen conformance.

Conditional conformance

Voorbeeld MedicatieafspraakStopType:

In de informatiestandaard Medicatieproces bevat de medicatieafspraak een conditional conformance voor het element MedicatieafspraakStopType (0..1C).

Het stoptype wordt uitsluitend in het bericht ingevuld wanneer een medicatieafspraak wordt gestopt of geannuleerd. In deze gevallen geldt kardinaliteit van 1..1 en conformance R.

Indien een medicatieafspraak niet wordt gestopt of geannuleerd is het niet toegestaan om het stoptype in te vullen. Hier geldt kardinaliteit van 0..0 en conformance NP.


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

    Voorbeeld Patiënt met containers Naamgegevens, Adresgegevens en Contactgegevens

    Voorbeeld element: Patiënt
    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.

    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 “OTH”. 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

Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=Vdraft_Handleiding_Kardinaliteiten_en_conformance&oldid=322772"