Vdraft Handleiding Kardinaliteiten en conformance: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(tabellen in wiki format klaargezet)
 
(Een tussenliggende versie door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
 
__NOINDEX__
 
__NOINDEX__
  
=Toelichting op kardinaliteit, conformance en bewust leeg=
+
=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 kenbaar gemaakt via kardinaliteit en conformance per element. 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.
 
Aan het versturen van berichten door applicaties worden eisen gesteld qua het bevatten van concepten/elementen. Deze eisen worden kenbaar gemaakt via kardinaliteit en conformance per element. 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.
Regel 10: Regel 10:
 
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.
 
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.
  
[[Bestand:Kardinaliteit.PNG]]
 
 
{| class="wikitable"
 
{| class="wikitable"
 
! kardinaliteit
 
! kardinaliteit
Regel 31: Regel 30:
 
Conformance gaat over of een element verplicht opgenomen moet worden in een bericht.  
 
Conformance gaat over of een element verplicht opgenomen moet worden in een bericht.  
  
[[Bestand:Conformance.PNG]]
 
 
{| class="wikitable"
 
{| class="wikitable"
 
!
 
!
Regel 71: Regel 69:
 
* 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.<br>
 
* 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.<br>
  
[[Bestand:TabelKC.png]]
 
 
{| class="wikitable"
 
{| class="wikitable"
! Conformance / Cardinaliteit
+
! Conformance / Kardinaliteit
 
! Optioneel
 
! Optioneel
 
! Required
 
! Required
Regel 162: Regel 159:
 
|}
 
|}
  
 +
 +
==NullFlavor==
  
 
==Toepassingsvoorbeeld==
 
==Toepassingsvoorbeeld==

Huidige versie van 18 aug 2026 om 09:53


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 kenbaar gemaakt via kardinaliteit en conformance per element. 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


NullFlavor

Toepassingsvoorbeeld

NullFlavor wordt in HL7v3 gebruikt om te duiden waarom een waarde er niet is. Data Absent Reason heeft in HL7 FHIR een vergelijkbare functie. Bindingsterkte required betekent dat alléén waarden uit de betreffende waardelijst zijn toegestaan.

  • datasetconcept A is 1..1 M en heeft binding met sterkte required op een waardelijst met NullFlavor of Data Absent Reason
  • 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
b. Datasetconcept B
c. Allebei
d. Geen van beide

Selecteer deze regel om het antwoord te zien. 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.