nullflavors

{{#customtitle:HL7v3-domeinspecificatie Care Provision|HL7v3-domeinspecificatie Care Provision}}

Basisdataset Jeugdgezondheidszorg

Toelichting structuur BDS JGZ

In deze paragraaf wordt beschreven hoe de BDS JGZ geïnterpreteerd en geïmplementeerd moet worden.

Opbouw

De BDS is opgebouwd uit rubrieken, groepen, elementen (vragen) en waardendomeinen met waarden (antwoorden). Al deze onderdelen hebben unieke nummers. Voorbeeld BDS:

Rubriek: ID, cardinaliteit
	Groep: ID, cardinaliteit
		Element: ID, cardinaliteit (waardendomeinID, type, Waardendomein)
			Waarde: code, HL7code

Rubrieken

Rubrieken zijn groeperingen van elementen die een zorginhoudelijke relatie met elkaar hebben. De rubrieken zijn in twee categorieën op te delen:

• dossiergebonden rubrieken, bestaande uit persoons- en zorggerelateerde gegevens;
• activiteitgebonden rubrieken.

Alle rubrieken die voorkomen vóór de rubriek Activiteiten zijn de dossiergebonden rubrieken. Alle rubrieken van de rubriek Activiteiten zijn de activiteitgebonden rubrieken. Er zijn twee uitzonderingen: de rubrieken Erfelijke belasting en ouderkenmerken en Bedreigingen uit de directe omgeving zijn ook activiteitgebonden rubrieken in plaats van dossiergebonden.

De rubrieken kunnen maximaal één keer voorkomen in een dossier.

Groepen

In een groep worden elementen gebundeld die meerdere keren kunnen voorkomen. In dat geval kunnen aan de elementen meerdere waarden toegekend worden, die aan elkaar gerelateerd zijn. Bijvoorbeeld een kind kan tussen twee contactmomenten in meerdere keren zijn opgenomen in het ziekenhuis en van elke keer kan afzonderlijk de reden en de duur vastgelegd worden. Voorbeeld BDS:

Opname ziekenhuis: G087, 0..*
	Reden opname ziekenhuis: 150, 1..1  (W0082, AN, Alfanumeriek 4000)
	Duur opname ziekenhuis: 149, 1..1  (W0125, N, Dagen)

Elementen

De elementen zijn de gegevens die geregistreerd worden in een dossier. Voor elk van de elementen uit de BDS gelden de volgende bepalingen:

• de datum waarop de waarde van het element geregistreerd is, moet worden vastgelegd;
• de auteur van de registratie moet worden vastgelegd, zodat bekend is welke systeemgebruiker de gegevens heeft ingevoerd;
• de bron van het gegeven moet geregistreerd worden op het niveau van de verantwoordelijke JGZ-organisatie (behorend bij de auteur);
• de historie van elk element moet bewaard blijven. Voor de twee verschillende categoriën rubrieken gelden hier verschillende regels, zie paragraaf 2.1.10.

Alle elementen zijn required. Dat wil zeggen zeggen dat elk systeem ze moet ondersteunen, maar er niet per se een waarde hoeft te zijn. Dit betekent dat:

• elk verzendend systeem in staat moet zijn om de volledige BDS te laten registreren (ook al hoeven bij verzending niet alle gegevens gevuld te zijn);
• elk ontvangend systeem in staat moet zijn om de volledige BDS te verwerken in de eigen database (afhankelijk van wat de verzender gevuld heeft).

Lichaamskant

In de BDS wordt op twee verschillende wijzen omgegaan met het aangeven van de lichaamskant:

1. als elementen altijd uitgevraagd worden voor rechts en links dan zijn zij gesplitst in een element voor rechts en een element voor links;
2. als bij een waarde bij een element een keuze mogelijk is voor rechts of links, dan is een apart element voor lichaamskant opgenomen (en bij meerdere mogelijke waarden wordt dit in een groep geplaatst).

Voorbeeld BDS splitsing in rechts en links:

Bijzonderheden lies rechts: 210, 0..*   (W0235, KL_AN, Bijzonderheden lies)
	Liesbreuk: 01, 01
	Vergrote lymfeklieren: 02, 02
	Anders: 98, 98
Bijzonderheden lies links: 211, 0..*   (W0235, KL_AN, Bijzonderheden lies)
	Liesbreuk: 01, 01
	Vergrote lymfeklieren: 02, 02
	Anders: 98, OTH (nullFlavor)

Voorbeeld BDS keuzemogelijkheid rechts of links:

Heupen: G026, 0..*
	Bijzonderheden heupen: 219, 1..1   (W0241, KL_AN, Bijzonderheden heupen)
		Abductie beperking: 01, 01
		Kniehoogteverschil: 02, 02
		Bilplooiverschil: 03, 03
		Beenlengteverschil: 04, 04
		Anders: 98, OTH (nullFlavor)
	Lichaamskant bijzonderheden heupen: 220, 1..*   (W0206, KL_AN, Rechts Links)
		Rechts: 1, 1
		Links: 2, 2

Waardendomeinen

Aan de elementen zijn waardendomeinen toegekend of er wordt verwezen naar (inter-) nationale codeertabellen. Waardendomeinen bevatten waarden. Deze waardendomeinen hebben verschillende “eigenaren”, die verantwoordelijk zijn voor de inhoud. Dit betekent dat men er niet vanuit mag gaan dat op het oog gelijkluidend waardendomeinen ook gelijk zijn. Deze kunnen dus door andere organisaties beheerd en dus ook aangepast worden. Slechts in de gevallen waarbij het WaardedomeinID gelijk is mag men er vanuit gaan dat het om dezelfde codetabel gaat. In de tabel is dit ook te zien doordat de waardedomeinen dan hetzelfde OID (object identifier), zie paragraaf 1.2.1, toegekend gekregen hebben.

Veldlengte

In de BDS is een veldlengte aan waardendomeinen toegekend. Het gaat hierbij om de maximale veldlengte. Deze veldlengten zijn van belang voor de implementatie van de BDS in de systemen. Voor de berichten speelt de veldlengte geen rol. HL7 versie 3 stelt namelijk geen beperkingen aan de veldlengten.

Waarde "Anders"

De waarde “Anders” in waardendomeinen is vrije tekst met een veldlengte van AN30. Deze antwoordmogelijkheid is bedoeld als optie als geen van de waarden van toepassing is, maar de gebruiker toch een waarde wil registreren. Het is niet de bedoeling deze optie te gebruiken als toelichting op één van de andere waarden. Zie ook de toelichting in paragraaf 2.2.3 over de nullFlavor ‘OTH’. Voorbeeld BDS:

Soort toegevoegd bestand: 1169, 1..1   (W0084, KL_AN, Onderwerp document)
	Integraal dossier JGZ: 01, 01
	Scan van oefeningenblad BFMT: 02, 01
	Anders: 98, OTH (nullFlavor)

Cardinaliteiten

Rubrieken, groepen en elementen hebben een cardinaliteit. Dit geeft het minimale en maximale aantal keer aan dat een onderdeel voorkomt in relatie tot het bovenliggende onderdeel (dossier, rubriek of groep). Hieronder worden de verschillende mogelijkheden beschreven: 0..1: onderdeel hoeft niet voor te komen en mag maximaal één keer voorkomen; 0..*: onderdeel hoeft niet voor te komen en mag maximaal onbeperkt voorkomen; 1..1: onderdeel moet minimaal één keer voorkomen en mag maximaal één keer voorkomen; 1..*: onderdeel moet minimaal één keer voorkomen en mag maximaal onbeperkt voorkomen.

Voorbeeld BDS – er kunnen meerdere waarden ingevuld worden bij Bijzonderheden uiterlijk oor:

Bijzonderheden uiterlijk oor rechts: 794, 0..*   (W0221, KL_AN, Bijzonderheden uiterlijk oor)
	Afwijkende vorm kraakbenig deel van het oor: 01
	Afwijkende stand: 02
	Lage-implantatie: 03
	Resten van kieuwboogspleten: 04
	Bij-oortje: 05
	Anders: 98

Voorbeeld BDS - de groep is herhalend en kan meerdere keren voorkomen, maar per groep kan maar één Taal ingevuld worden:

Taal: G036, 0..*
	Taal: 302, 1..1   (W0050, AN_EXT, Taal)
	Dialect: 1329, 0..1   (W0017, AN, Alfanumeriek 50)
	Eerste/tweede taal: 307, 1..1   (W0280, KL_AN, Eerste/tweede taal)
		Eerste taal: 1
		Tweede taal: 2
	Taalomgeving stimulerend: 816, 0..1   (W0281, KL_AN, Taalomgeving stimulerend)
		Voldoende: 1
		Matig: 2
		Onvoldoende: 3

Historie

Van elk element moet de historie worden bewaard. Voor de elementen uit de dossier gebondenrubrieken gelden andere regels dan voor de elementen uit de activiteit¬gebonden rubrieken.

Regels voor dossiergebonden rubrieken:

• elke registratie is gekoppeld aan een specifieke gebruikssessie van de applicatie;
• de registratiedatum, auteur en bron worden afgeleid van de gebruikssessie;
• een gebruiksessie kan, maar hoeft niet te horen bij een contactmoment;
• bij elke mutatie moet worden vastgelegd wat de ingangsdatum van de betreffende waarde is (bijvoorbeeld vanaf welk moment een bepaald adres geldig is);
• van elke element wordt slechts één waarde per gebruikssessie vastgelegd (of zoveel waarden als nodig zijn in het geval van een herhalende gegevenselementen);
• als tijdens een gebruikssessie correctie van een eerder ingevoerd gegeven nodig is, dan hoeft alleen de uiteindelijke waarde te worden vastgelegd (overschrijving). Dit geldt eveneens voor situaties waarbij de ingangsdatum wordt aangepast;
• als bij volgende gebruikssessies nieuwe waarden worden bepaald, dan blijven de oude waarden onveranderd bewaard (gekoppeld aan een vorige gebruikssessie);
• als bij een volgende gebruikssessie de gegevens van een eerdere gebruikssessie moeten worden gecorrigeerd, dan moeten de oorspronkelijke waarde wel bewaard blijven - deze blijft zichtbaar in de audit trail van de betreffende registratie;
• het verloop van waarde(n) en ingangsdata over de tijd (voor achtereenvolgende gebruikssessies) blijft oproepbaar en wordt het historisch verloop genoemd.

Regels voor activiteitgebonden rubrieken:

• elke registratie is gekoppeld aan een specifieke activiteit in de applicatie;
• de registratiedatum, auteur en bron worden afgeleid van de activiteit;
• van elk gegeven wordt slecht één waarde per activiteit vastgelegd (of zoveel waarden als nodig zijn in het geval van herhalende elementen);
• als tijdens een activiteit correctie van een eerder ingevoerd element nodig is, dan hoeft alleen de uiteindelijke waarde te worden vastgelegd (overschrijving);
• als bij een volgende activiteit de gegevens van een eerdere activiteit moeten worden gecorrigeerd, dan moet de oorspronkelijke waarde wel bewaard blijven - deze blijft zichtbaar in de audit trail van de betreffende registratie;
• het verloop van de waarde(n) over de tijd (voor achtereenvolgende activiteiten) blijft oproepbaar en wordt het historisch verloop genoemd.

Condities

De BDS kent enkele aanvullende verplichtingen die niet door de cardinaliteit en de groepsstructuur afgedwongen worden. Ook deze zullen ingebouwd moeten worden in het DD JGZ.

Voorbeeld BDS:

Bij elementnummer 236: als 235

Als het element Lengte (235) wordt ingevuld dan moet ook het element Methode Lengtemeting (236) worden ingevuld. Immers zonder informatie over de gehanteerde methode is een waarde bij Lengte niet eenduidig.

Niet-BDS gegevens

Een organisatie kan elementen aan de eigen applicatie toe voegen, als deze nog niet in de BDS staan. Bij de overdracht aan een andere JGZ-organisatie gaan deze aanvullende elementen mee als vrije tekst (als vraag en antwoord). De koppeling met een bepaalde rubriek en activiteit waarin het element geregistreerd is, blijft behouden bij de overdracht.

Rubriek Niet gespecificeerde gegevens in BDS:
Niet gespecificeerde gegevens: R051, 0..1
	Niet gespecificeerde gegevens: G083, 1..*
		Element: 1332, 1..1   (W0020, AN, Alfanumeriek 200)
		Waarde: 1333, 1..1   (W0020, AN, Alfanumeriek 200)
		Activiteit ID: 1334, 0..1   (W0642, AN, Alfanumeriek 10)
		Rubriek ID: 1335, 0..1   (W0639, KL_AN, RubriekID)

Vrijheid leveranciers

Een leverancier is gehouden aan het gebruik van de rubrieken, elementen en waarden zoals gedefinieerd in de BDS. Ook de naamgeving zoals gehanteerd in de BDS is verplicht. Het is belangrijk dat de betekenis van de items uit de BDS gehandhaafd blijven ten behoeve van eenduidige gegevensoverdracht. Een leverancier is vrij in de wijze waarop de BDS-onderdelen getoond worden op het scherm, bijvoorbeeld in tabel- of grafiekvorm of het meerdere keren tonen van elementen.

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>