jgz:V1.0.1.0 Toelichting structuur BDS JGZ

{{#customtitle:Toelichting structuur BDS JGZ|Toelichting structuur BDS JGZ}}

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)

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.