Wijzigingen

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>

Domain Message Information Models

D-MIM REPC_DM000000

Dit hoofdstuk omvat een algemene beschrijving van het D-MIM (core structure) voor het Care Provision domein. De herkomst van het D-MIM wordt hier vermeld.

Voor een beschrijving van het universele domein Care Provision wordt verwezen naar [HL7NL_IH_CareProvision_Generiek].

Het Care Provision model kent als ingang een CareProvision (PCP) in de ‘Event mood’ omdat het in de zorg communicatie van (deel-)dossiers vrijwel altijd om een registratie van medische handelingen gaat. Deels gaat het om statische informatie, gegevens die in de loop van de tijd redelijk stabiel blijven en rechtstreeks te koppelen zijn aan de patiën,t deels gaat het om dynamische informatie, de registratie van het beloop in de tijd (registratie van anamnese en lichamelijk onderzoek).

Een Care provision bevat op hoofdlijnen contactmomenten (encounters). Deze contacten kunnen vervolgens weer vrije tekst-regels bevatten, diagnoses, metingen (observaties) en verwijzingen (referral).

De verschillende onderdelen van het model worden hierna kort beschreven.

Careprovision

Het startpunt (Entrypoint) van het D-MIM Care Provision is aan CareProvision gekoppeld. Dit is het centrale object in het model. Alle gegevens benodigd voor de berichten zijn aan dit object gekoppeld. Dit is in feite de container van zorgdossier.

CMET’s aan Care Provison

Sommige data-elementen kunnen op verschillende plaatsen een rol spelen en worden dan als herbruikbaar blokje (CMET) in het D-MIM opgenomen.

De volgende CMET’s zijn in het model aan PCP opgenomen:

R_AssignedEntityNL_PO: wordt gebruikt om zorgverleners, medewerkers en derden (personen of organisaties) te beschrijven. Als author is dit de vaste huisarts die verantwoordelijk is voor het beheer van het dossier.

R_PatientNL: wordt gebruikt voor het vastleggen van administratieve patiëntgegevens; speelt de rol van de patiënt.

Patiëntkoppeling

Alle informatie (observaties en verwiijzingen) hebben betrekking op dezelfde patiënt. Deze wordt bepaald door de patiënt die aan de focal class (CareProvision) hangt. Impliciet wordt ervan uitgegaan dat alle informatie betrekking heeft op deze zelfde patiënt.

Persoon- en organisatiekoppeling

Wat betreft de rollen van personen en organisaties, heeft het Care Provision model (D-MIM inclusief de bijbehorende CMET’s) alleen de author en performer nodig. De author is degene die (inhouds)verantwoordelijkheid draagt voor de betreffende medische gebeurtenis. De performer (uitvoerende) van een medische gebeurtenis in een zorgdossier is bijna altijd de auteur. Omdat de verwijzingen vanuit Care Provision ook naar organisaties gaan, wordt hier de Assigned_Entity gebruikt. In alle andere gevallen wordt Assigned_Person gebruikt om de geldende restricties zoveel mogelijk modelmatig vast te leggen. In de AssignedPerson kan desgewenst worden meegegeven namens welke organisatie de persoon handelt. Dit betekent niet dat in elk bericht altijd alle personen en organisaties worden verstuurd. Als algemene regel geldt dat alleen die personen en/of organisatie worden meegestuurd die van belang zijn voor de meegestuurde medische inhoud en als zodanig in het bronsysteem zijn vastgelegd.

Wat betreft de identificatie van personen en organisaties: in de medische gegevens (de payload van de berichten) mag naast de UZI ook de AGB-code gebruikt worden. De identificatie van zorgverleners en gemandateerde medewerkers in de wrappers van de berichten vereist echter UZI-nummers. Deze UZI-nummers zijn noodzakelijk voor authenticatie en autorisatie op het Landelijk Schakelpunt.

Verder is van belang dat degene die verantwoordelijk is voor de zorgrelatie met de patiënt degene is die als zender optreedt. Dit is nodig voor de authenticatie en autorisatie op basis van de gegevens op de envelop (de ‘wrapper’ waar de zender en ontvanger in horen).

Refined Message Information Models

R-MIM REPC RM000100UV - Care Statement

D-MIM:	REPC_DM000000
HL7v3 artefact type:	R-MIM
HL7v3 gestructureerde naam:	CareStatement [care provision]
Herkomst	HL7v3, gebaseerd op choicebox CareStatement in REPC_DM000000, zie [HL7v3_Sep2006].

Diagram

Beschrijving van R-MIM REPC_RM000100UV

Het “Care Statement Model” presenteert een standaard structuur op hoog niveau voor het opnemen van klinische informatie in “Care Provision” communicatie bedoeld ter ondersteuning van specifieke zakelijke functionaliteiten. Hoewel niet bedoeld om geïmplementeerd te worden ”as is”, kan het “Care Statement model” beperkt worden om aan de eisen tegemoet te komen van vele specifieke communicatie met betrekking tot klinische informatie. Aan dit model wordt gerefereerd via een externe “Act” naar de “Care Statements”. Vaak levert deze externe “Act” de “Entry Point” naar een specificatie voor communicatie en representeert de context waarin de “care statement” informatie wordt verzonden. Bijvoorbeeld: informatie over degene die de informatie verzendt zit in een externe “Act” naar de “Care Statements”. De “Care Provision Act” in het “Care Provision” Domein is een voorbeeld van een externe “Act” naar de “Care Statement”. Het model kan verdeeld worden in 3 gerelateerde onderdelen:

• “Care Entry” Keuzebox;
• participaties om de “Acts” heen;
• ”Acts” buiten de “CareEntry” Keuzebox.

De Care Entry keuzebox deel van het model wordt gebruikt voor het overbrengen van de gedetailleerde “care statements” die verzonden worden ter ondersteuning van de specifieke zakelijke behoeften. Evenals het leveren van een mechanisme voor het overbrengen van de componenten van deze informatie ondersteunt het het groeperen van deze componenten en levert het mechanismen om expliciet beweringen te linken waar er een specifieke relatie is. Wanneer een klinische verklaring al eerder verzonden is en dus bij de ontvanger bekend is, mag de klinische verklaring worden opgenomen middels een verwijzing of door het volledige herhalen van de verklaring. Wanneer de verklaring volledige herhaald wordt, moeten alle attributen en de context (expliciet of geërfd) identiek zijn.

Message Types

HL7v3 gestructureerde naam	HL7v3 naam
A_CareStatement [care provision]	REPC_MT000100UV

R-MIM REPC RM002000UV - Zorgoverdrachtverzoek

D-MIM:	REPC_DM000000
HL7v3 gestructureerde naam:	Care Transfer Request

Voor meer informatie zie [HL7NL_IH_CareProvision_Generiek].

R-MIM REPC RM002000NL JGZ - Zorgoverdrachtverzoek

D-MIM:	REPC_DM000000
HL7v3 artefact type:	R-MIM
HL7v3 gestructureerde naam:	Care Transfer Activate Fulfillment Request
Herkomst	AORTA

Diagram

Beschrijving

De zogenaamde focal class van het R-MIM is dus de klasse CareProvisionRequest, die betrekking heeft op één enkel dossieroverdracht verzoek. Deze klasse fungeert als entry point (startpunt) bij de opbouw van de payload voor berichten.

Message Types

HL7v3 gestructureerde naam	HL7v3 naam
Care Transfer Request NL	REPC_MT002000NL_JGZ

R-MIM REPC RM003000UV - Acceptatie zorgoverdracht

D-MIM:	REPC_DM000000
HL7v3 gestructureerde naam:	Care Transfer Promise

Voor meer informatie zie [HL7NL_IH_CareProvision_Generiek].

Bijlage G

Inleiding

Aangezien de gezondheidszorg en dus ook de jeugdgezondheidszorg niet stilstaat, zijn er een aantal generieke afspraken gemaakt om tussentijdse wijzingen wel door te kunnen voeren zonder dat er wijzigingen in de schema’s plaats vinden. Het gaat hier om wijzigingen in de basis dataset tussen twee officiële releases in. In principe geldt voor wijzigingen in de basis dataset dat deze pas worden doorgevoerd op het moment dat er een nieuwe release plaatsvindt (één keer per jaar). Er zijn echter enkele uitzonderingen waarbij er niet gewacht kan worden op de nieuwe release. Te denken is bijvoorbeeld aan een nieuw vaccinatie soort. Er kan in een proces van drie maanden besloten worden dat er een nieuw vaccinsoort bijkomt. Het toedienen van dit vaccin moet wel worden geregistreerd en bij een dossieroverdracht mee overgedragen worden. In een dergelijke situatie kan niet worden gewacht op een nieuwe release, want dan zou er in het ergste geval gedurende negen maanden informatie verloren gaan. Vandaar dat er voor tussentijdse cruciale wijzigingen in de basis dataset onderling afspraken zijn gemaakt om het gewijzigde gegeven toch over te kunnen dragen, zonder dat de technische specificaties, zoals de XML-schema’s, de schematron en implementatiehandleiding aangepast worden.

Soorten wijzigingen die er kunnen optreden in de basis data set:

1. BDS item wordt toegevoegd
2. BDS item wordt verwijderd
3. Waarde uit waardendomein wordt verwijderd
4. Waarde wordt toegevoegd aan waardendomein
5. Nieuw waardendomein
6. Datatype wordt gewijzigd

Conversie	Hoe elementen geconverteerd moeten worden die geregistreerd zijn voordat de wijziging is doorgevoerd.
Verzender	Welke procedure gevolgd moet worden bij het verzenden van berichten.
Ontvanger	Welke procedure gevolgd moet worden bij het ontvangen van berichten.

Mechanismen Niet-BDS elementen

Een applicatie kan elementen opslaan die niet gekoppeld zijn aan een BDS nummer. Van deze elementen wordt de omschrijving van het element opgeslagen (bijvoorbeeld ‘lengte moeder’) en de omschrijving van de waarde (bijvoorbeeld ‘173 cm’).

Converteren naar een niet-BDS element

Een BDS element kan worden omgezet naar een niet-BDS element. Als omschrijving van het niet-BDS element wordt de omschrijving van het BDS element genomen zoals die in de BDS database staat. De waarde wordt omgezet naar tekst, afhankelijk van het type van het BDS element.

Alphanumeriek	Dezelfde waarde wordt gebruikt.
Boolean	De waarden ‘Ja’, ‘Nee’ en ‘Onbekend’ worden gebruikt.
Datum	De waarde wordt omgezet in het formaat dd-mm-jjjj, gevolgd door hh:mm als er ook een tijdstip is gespecificeerd.
Keuzelijst	De displayname van de keuze wordt gebruikt. Het is verplicht om displaynames van keuzes mee te sturen in een bericht.
Numeriek	De waarde wordt gebruikt, gevolgd door de eenheid als deze is gespecificeerd.
Periode	Het formaat begin t/m eind wordt gebruikt, waarbij begin en eind als datums geformatteerd zijn.

Versturen als niet-BDS element

Een element wordt naar het NonBDSData gedeelte van het bericht gemapt. Hoe dit moet staat beschreven in de implementatiehandleiding.

Verwerken als niet-BDS element

De gegevens worden als niet-BDS element opgeslagen. Behalve de gegevens in het NonBDSData gedeelte van het bericht kunnen ook andere elementen op deze manier worden verwerkt. Deze elementen worden op dezelfde manier geconverteerd naar een niet-BDS element als hierboven beschreven.

Wijzigingen

BDS element wordt toegevoegd

Conversie	Niet van toepassing
Verzender	Het is van belang of het toegevoegde element een observatie element is of niet. Een element is een observatie element als het gemapt wordt naar een van de volgende HL7-paden. CareProvisionRequest.sequelTo.CareProvisionEvent.component. {choiceboxEncounter}.{choiceboxActivities}.pertinentInformation. RubricCluster.component.{choiceboxCluster}.Observation CareProvisionRequest.sequelTo.CareProvisionEvent.component2. {A_PasgeboreneGegevens}.NeonateData.component4.NeonateObservations CareProvisionRequest.sequelTo.CareProvisionEvent.pertinentInformation. {A_Zwangerschap}.PregnancyCondition.component1.PregnancyObservations Als het toegevoegde element een observatie element is, dan wordt het element verstuurd volgens het HL7-pad. De omschrijving van het element wordt hierbij meegestuurd. In het andere geval wordt het element als niet-BDS element verstuurd.
Ontvanger	De ontvanger controleert of er een waarde is gespecificeerd op de plek in het bericht waar het verwijderde element heen mapte. Als dit zo is, wordt de waarde als niet-BDS element verwerkt.

BDS item wordt verwijderd

Conversie	Elementen met dit BDS nummer die al geregistreerd zijn worden omgezet naar niet-BDS elementen.
Verzender	Niet van toepassing.
Ontvanger	De ontvanger controleert of er een waarde is gespecificeerd op de plek in het bericht waar het verwijderde element heen mapte. Als dit zo is, wordt de waarde als niet-BDS element verwerkt.

Waarde wordt toegevoegd aan waardendomein

Conversie	Bestaande elementen worden niet geconverteerd.
Verzender	Het element wordt verstuurd met het nieuwe versienummer van het waardendomein.
Ontvanger	Elementen waarvan de OID van het waardendomein herkend wordt, maar het versienummer niet, worden als niet-BDS element verwerkt. de waarde wordt herkend het element wordt op de gebruikelijke manier verwerkt de waarde wordt niet herkend het element wordt als niet-BDS element verwerkt

Waarde wordt verwijderd uit waardendomein

Conversie	Elementen die al geregistreerd zijn en als waarde de verwijderde waarde hebben, worden omgezet naar een niet-BDS element. De overige elementen worden niet geconverteerd.
Verzender	Het element wordt verstuurd met het nieuwe versienummer van het waardendomein.
Ontvanger	De ontvanger volgt dezelfde procedure als beschreven bij de wijziging ‘Waarde wordt toegevoegd aan waardendomein’.

Nieuw waardendomein

Conversie	Elementen met dit BDS nummer die al geregistreerd zijn worden omgezet naar niet-BDS elementen.
Verzender	Het element wordt met het nieuwe waardendomein verstuurd.
Ontvanger	Elementen waarvan de OID van het waardendomein niet herkend wordt, worden als niet-BDS elementen verwerkt.

Datatype wordt gewijzigd

Conversie	Elementen met dit BDS nummer die al geregistreerd zijn worden omgezet naar niet-BDS elementen.
Verzender	Het element wordt met het nieuwe datatype verstuurd.
Ontvanger	Elementen waarvan het datatype niet wordt herkend, worden als niet-BDS elementen verwerkt.