View source for 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.<br/>

{| class="prettytable" border="1"
|- style="background-color:silver; text-align:left;" 
! 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).<br/><br/>''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.<br/><br/>''NP = not permitted'' (niet toegestaan) betekent dat het modelonderdeel niet in de instance mag voorkomen (en ook niet aanwezig is in het onderliggend schema).<br/><br/>''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.
|-
|}
<br/>
{| class="prettytable" border="1"
|- style="text-align:left;" 
| [[Image:info.png]] ||  style="background:yellow" | ‘Verwerken’ wordt in de breedste des woords bedoeld. Verwerken kan betekenen: opslaan, afwijzen van specifieke waarden binnen een concept, vertalen naar interne variant op het concept, tonen aan de gebruiker, etc.<br/>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.
|-
|}