nullflavors

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

Weergave in HL7 berichten

Alle elementen zijn conditioneel aanwezig in het bericht. Dat wil zeggen dat er alleen een HL7 component wordt doorgegeven als er voor het betreffende element uit de BDS een waarde is ingevuld. Hierop zijn een paar uitzonderingen. Er zijn enkele verplichte elementen. Dit zijn de elementen die een cardinaliteit van minimaal één hebben waarbij ook de rubriek een minimale cardinaliteit van één heeft.

Bij de uitwisseling in de vorm van HL7 versie 3 berichten zijn er bepaalde beperkingen aan de wijze waarop aan bovenstaande eisen voldaan wordt. Dit doet niets af aan de eisen ten aanzien van de registratie van de BDS elementen, aangezien de functionele mogelijkheden van de HL7 berichten in een later stadium zullen worden uitgebreid.

• Het doorgeven van de registratiedatum, de auteur en de bron gebeurt in het HL7 bericht voor alle elementen die als zogenaamde Act of een specialisatie daarvan worden weergegeven in het model. Voor elementen die als Entity of Role klasse worden weergegeven (zoals persoonsgegevens) is deze informatie (nog) niet beschikbaar in het HL7 bericht. Hiervoor wordt later functionaliteit toegevoegd.
• Binnen het HL7 bericht wordt de historie doorgegeven door meerdere versies van hetzelfde type Act door te geven (bijvoorbeeld meerdere groeimetingen), elk met hun eigen datum, auteur en bron. Voor elementen die niet als Act worden aangeduid is deze mogelijkheid er niet, maar deze komt beschikbaar zodar ook voor deze elementen de zogenaamde audit trail (mutatie historie) kan worden opgenomen.

OID's

Object identifiers (OIDs) is een concept dat wordt gebruikt door de wereldwijde standaardisatie-organisatie om te komen tot unieke identificatie van een systeem waarbinnen zelf weer identifiers of codes worden uitgedeeld en beheerd. Binnen de BDS wordt gebruik gemaakt van reeds bestaande OID’s, zoals voor UZI, URA, BSN, etc. Daarnaast bevat de BDS veel jeugdgezondheidszorg specifieke codelijsten, die elk hun eigen OID gekregen hebben en beheerd worden door de jeugdgezondheidszorg.

"mandatory" of "required"

In de HL7 versie 3 berichten kan bij de klassen attributen aangeven of deze “mandatory” of “required”.

mandatory een “mandatory” element dient aanwezig te zijn in een XML instantiatie, anders is het bericht ongeldig.

required  als er gegevens beschikbaar zijn, dan moet het veld in het bericht aanwezig zijn. 
Als de minimale cardinaliteit nul is en er zijn geen gegevens  beschikbaar, mag het element ontbreken in een XML instantie. 
Als de minimale cardinaliteit één is en er zijn geen gegevens beschikbaar, dan dient dit door een null¬Flavor, 
zie  paragraaf 2.2.3, aangeduid te worden.

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>