nullflavors

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen


Dit materiaal is onderdeel van Jeugdgezondheidszorg V1.0.1.0_Weergave_in_HL7_berichten.
  • Compatible wijzigingen/nadere bewoordingen, tikfouten kunnen direct in de Wiki gewijzigd worden
  • Open issues die discussie vergen s.v.p. in de commentaarsectie opnemen.

nullflavors

Elk element in een HL7 versie 3 XML bericht heeft het optionele attribuut nullFlavor, dat gebruikt wordt om aan te geven dat de betreffende waarde in het geheel ontbreekt, inclusief mogelijk een reden voor het ontbreken.

Er zijn drie soorten nullFlavor die binnen HL7 berichten gebruikt worden:

‘NASK’ Er is niet geïnformeerd bij de cliënt of de ouders/verzorgers en geen onderzoek gedaan naar de juiste waarde van het gegeven. 
Dit is de standaardwaarde als geen registratie heeft plaatsgevonden.
‘ASKU’ Er is wel informatie ingewonnen, maar de juiste waarde is onbekend (cliënt weet het niet). 
Dit is een bewust geregistreerde waarde.
‘OTH’ De waarde is wel bekend, maar valt buiten het domein van het voorgeschreven codesysteem (er is dus geen geschikte code).

Kijkend naar bovenstaande waarden zal het duidelijk zijn waarom in de vele code-lijsten die binnen de BDS zijn gedefinieerd geen codes voor onbekend of overigen voorkomen. Een aanduiding voor ‘onbekend’ is immers geen echte waarde, maar een nullFlavor (onbekende waarde). Alle codelijsten binnen de BDS zijn hierop geschoond en in plaats van een code moet in dat geval dus een nullFlavor gebruikt worden. Hetzelfde geldt voor ‘overigen’, waarvoor ook geen codes meer bestaan (maar waarbij het wel mogelijk is om een ingevoerde vrije tekst door te geven als alternatief voor een code).

De toepassing bij het ‘vullen’ van de BDS binnen het dossieroverdrachtsbericht is dan:

  1. Zolang niet naar de waarde geïnformeerd is: gebruik de nullFlavor ‘NASK’.
  2. Als wel geïnformeerd en geregistreerd is, maar de waarde is onbekend: ‘ASKU’.
  3. Als wel informatie bekend is, maar buiten de betreffende codelijst valt: ‘OTH’.
  4. Als gewoon een waarde uit het juiste domein bekend is, geef deze dan door.

Een nullFlavor wordt in het XML bericht gevuld als:

<attribute nullFlavor=’NASK’ />	standaardwaarde bij geen invoer
<attribute nullFlavor=’ASKU’ />	bewust ‘onbekend’ geselecteerd
<attribute nullFlavor=’OTH’ />	invoer buiten normale codelijst

Als hetzelfde element met een ‘echte’ waarde gevuld zou worden:

<attribute value=’Dit is een tekstveld.’/>   bij datatype string
<attribute
	code="2"
	codeSystem="2.16.840.1.113883.2.4.99"
	displayName=’omschrijving van de code’/>   bij datatype code

Merk op: Op deze manier is dus het onderscheid te maken tussen een vraag uit de BDS die ‘nog niet beantwoord is’ en een vraag waar ‘bewust onbekend is ingevoerd’. Als de gebruiker van de applicatie geen selectie heeft gemaakt of anderszins gegevens heeft ingevoerd, is nullFlavor ‘NASK’ van toepassing. Als bewust voor ‘onbekend’ is gekozen, zal de nullFlavor ‘ASKU’ gebruikt worden. Het is voor statistische doeleinden zeer belangrijk dat dit onderscheid gemaakt kan worden. Het selecteren of invoeren van ‘onbekend’ als invoerwaarde moet dus altijd een bewuste handeling zijn. Een element met nullFlavor ‘NASK’ (not asked) als waarde wordt normaal gesproken niet doorgegeven in het HL7v3 bericht, dus deze nullFlavor is impliciet voor niet-aanwezige elementen.

Vrije tekst bij nullFlavor ‘OTH’ (overigen) Als de nullFlavor ‘OTH’ gebruikt wordt, om aan te geven dat geen van de standaardcodes van toepassing is, dan kan in plaats van een code wel een stuk vrije tekst worden doorgegeven dat door de gebruiker is ingevoerd. Dit kan dus gebruikt worden als geen van de waarden van toepassing is, maar de gebruiker toch iets wil registreren.

In het XML bericht ziet dit er als volgt uit:

<attribute nullFlavor=’OTH’>
	<originalText>’Er is iets anders aan de hand.’</originalText>
</attribute>