Cardinaliteit, mandatory en conformance

Return to InM V2 voorstellen

• meeting: TC-InM
• Author: Alexander Henket
• Status: FINAL - for discussion in TC

Inleiding

Onderstaande is de voorgestelde nieuwe tekst voor paragraaf 6.4 uit de aanstaande Implementatiehandleiding Basiscomponenten v2.2.

'6.4 Cardinaliteit, “mandatory" en conformance'

In de HL7 versie 3 berichten kan bij de modelattributen gebruik gemaakt worden van verdere eigenschappen zoals de cardinaliteit van het betreffende modelattribuut. De volgende tabel geeft een overzicht van de betekenis van deze aanvullende eigenschappen.

Begrip	Verklaring / opmerkingen
Cardinaliteit	Specificeert het minimale en maximale aantal herhalingen van het betreffende modelonderdeel (d.w.z. modelattribuut of associatieve klasse) in de XML-instance. Bijvoorbeeld 1..* houdt in dat het XML-element minimaal 1 keer aanwezig moet zijn, en dat het XML-element een onbeperkt keer mag herhalen in de instance.
Mandatory	Een “mandatory” modelonderdeel moet altijd aanwezig zijn in de XML-instance en er is geen nullFlavor toegestaan. Zonder dit onderdeel is de XML-instance ongeldig. Voor “mandatory” modelonderdelen (en bijbehorend XML-element) is het aantal herhalingen (cardinaliteit) per definitie minimaal 1 (één).
Conformance	Hier wordt onderscheid gemaakt tussen R (required, vereist), NP (not permitted, niet toegestaan) en optional (optioneel). R = Required betekent dat zowel de zendende als de ontvangende applicatie dit modelonderdeel moeten ondersteunen. Als er gegevens beschikbaar zijn, dan moet dit onderdeel ook in de XML-instance aanwezig zijn. Als de minimale cardinaiteit 0 is en er geen gegevens beschikbaar zijn, mag het element ontbreken in de XML-instance en is het bericht toch geldig. Als de minimale cardinaliteit 1 is en er geen gegevens beschikbaar zijn, dient dit door een nullFlavor (zie paragraaf 6.5) aangeduid te worden. Als een zendende applicatie het optionele modelonderdeel altijd zou weglaten of als deze in het verplichte modelonderdeel altijd een nullFlavor zou zenden omdat deze het concept niet ondersteunt, dan is zo’n applicatie niet-conformant. Als een ontvangende applicatie het modelonderdeel indien aanwezig nooit zou verwerken, dan is zo’n applicatie niet-conformant. NP = not permitted (niet toegestaan) betekent dat het modelonderdeel niet in de instance mag voorkomen (en ook niet aanwezig is in het onderliggend schema). Optional (optioneel) betekent dat een modelonderdeel niet of wél aanwezig mag zijn en dat geen support door zendende en ontvangende applicaties verplicht is.
NullFlavor	Voor modelonderdelen met een minimale cardinaliteit van 1 dient een nullFlavor doorgegeven te worden als er geen gegevens voor dit element beschikbaar zijn in een zendende applicatie. Voorbeelden zijn “geen informatie” (NI – no information), “onbekend” (UNK – unknown) enz. Voor verdere toelichting zie paragraaf 6.5.

De onderstaande tabel vat de verschillende varianten samen (met ROOD voor verzenders en BLAUW voor ontvangers)

Conformance Cardinaliteit	Optioneel	Required	Mandatory
0..1	Invoer MAG mogelijk zijn Hoeveel waarden ingevoerd? 0 → GEEN XML element 1 → 0 of 1 elementen N → 0 of 1 elementen	Invoer MOET mogelijk zijn Hoeveel waarden ingevoerd? 0 → GEEN XML element 1 → 1 GEVULD element N → 1 GEVULD element
	Evt. verzonden waarde MAG verwerkt worden.	Evt. verzonden waarde MOET verwerkt worden.
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 GEVULD element N → N GEVULDE elementen
	Evt. verzonden waarde(n) MOGEN (evt. deels) verwerkt worden.	Evt. verzonden waarde(n) MOETEN ALLEMAAL verwerkt worden.
1..1	Invoer MAG mogelijk zijn Hoeveel waarden ingevoerd? 0 → LEEG XML element 1 → 1 element (evt. LEEG) N → 1 element (evt. LEEG)	Invoer MOET mogelijk zijn Hoeveel waarden ingevoerd? 0 → 1 XML element (nullFlavor) 1 → 1 GEVULD element N → 1 GEVULD element	Invoer MOET VERPLICHT zijn Hoeveel waarden ingevoerd? 0 → NIET toegestaan 1 → 1 GEVULD element N → 1 GEVULD element
	Evt. verzonden waarde MAG verwerkt worden.	Evt. verzonden waarde MOET verwerkt worden.	Verzonden waarde MOET verwerkt worden.
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
	Evt. verzonden waarde(n) MOGEN (evt. deels) verwerkt worden.	Evt. verzonden waarde(n) MOETEN ALLEMAAL verwerkt worden.	Verzonden waarde(n) MOETEN ALLEMAAL verwerkt worden.

File:Info.png

INVOER betekent hier dat het gegeven betekenis heeft binnen de applicatie. Dat betekent meestal dat de gebruiker het invoert (terwijl die zich bewust is van de betekenis), maar kan in sommige gevallen ook betekenen dat de applicatie het automatisch vult (als de waarde duidelijk is uit de context van een bepaalde functie). Wat NIET is toegestaan, is het standaard versturen van betekenisloze dummy waarden (dus zon-der dat de betekenis geborgd is in de applicatie). VERWERKING betekent ook dat het gegeven betekenis heeft binnen de applicatie. Verwerken kan betekenen: opslaan, afwijzen van specifieke waarden binnen een concept, vertalen naar interne variant op het concept, tonen aan de gebruiker, etc. Het is niet per se noodzakelijk dat het gegeven reproduceerbaar wordt opgeslagen. Voorbeeld: een verloskundigensysteem dat geen geslacht (van wordende moeders) vastlegt omdat het altijd vrouwen zijn, maar dat wel ontvangen berichten over mannen uitfiltert en niet verder verwerkt, ondersteunt op deze manier het concept geslacht - want anders kan het systeem er ook niet op filteren. Een leeg XML element heeft de vorm <element xsi:nil="true"/>. Een XML element met een nullFlavor heeft de vorm <element nullFlavor=”{type NullFlavor}”/>.