In overleg met het NCJ is besloten om de nieuwe elementen in R052 alleen op te nemen in het scenario 'registratie jeugdige'. De voorgestelde technische/template uitwerking is uit dit ticket gehaald.

ik zie nu pas jouw comment, zie ook waar we onze reactie hebben geplaatst

Allereerst:
Deze rubriek wordt nog niet uitgewisseld, dus alle aanpassingen die we doen hebben als het goed is geen of minimale impact op de huidige uitwisselingcode van leveranciers. Voor registratie kan ik bevestigen dat de voorgestelde wijzigingen in ons pakket weinig uitmaken.

Ik zal proberen kort te schetsen wat er ook tijdens het leveranciersoverleg naar voren is gekomen.

• Er is gevraagd of dit element ook "los" geregistreerd kan worden als het bespreken plaatsvindt in een ander contactmoment dan het "contactmoment/registratie" van de (eerste) melding.

• Het achteraf aanpassen van een registratie in een voorgaand contactmoment/registratie is onwenselijk (vanuit de inhoud/RR/NCJ), dit ivm afsluiten en definitief maken van registratie.

• Door het element buiten de groep te plaatsen wordt dan het verplichte karakter van de aanmelddatum/afmelddatum ontweken en is dat mogelijk (in registratie).

Het lijkt erop dat er nu in allerlei bochten gewrongen wordt om de directe relatie met het (enkele, kardinaliteit = 1..1) contactmoment te behouden, ten koste van context en relevantie.

Je kan namelijk niet in contactmoment A een melding maken en in contactmoment B het bijvoorbeeld behandelen en in contactmoment C de melding sluiten, en het allemaal binnen dezelfde registratiegroep houden. Als je dat nu doet, met hoe de BDS in elkaar steekt (een boom, met leaves per contactmoment), zal de melding verspreid zijn over meerdere registraties, over meerdere contactmomenten, zonder een verbindende link tussen deze registraties. En zelfs al zou de software dat faciliteren, dan is die samenhang verdwenen na overdracht. De enige manier om die samenhang dan terug te vinden is door handmatig zoekwerk in het dossier (e.e.a. gecombineerd met het lezen van de PDF).

Wat hier ontbreekt is een meerdere-contactmomenten-overkoepelend rubriek/groep/element. Dit bestaat op dit moment niet in de BDS, omdat de BDS uitsluitend dossier-gebonden en contactmomentgebonden rubrieken/groepen/elementen kent.

Wat in de zorgwereld best bekend staat als zorgplan/episode (of wat voor label je er ook op wil plakken), in de BDS is dit nauwelijks gefaciliteerd. De elementen die er nu voor zijn, kunnen we wel gaan overdragen, maar door de platgeslagen keuze tussen dossier- en contactmomentgebonden krijg je in beide gevallen een onsamenhangende registratie (en zeker na overdracht). Ik (en volgens mij een aantal andere leveranciers met mij) betwijfelen of het forceren van deze opname in de overdracht leidt tot een wenselijk resultaat. En daarmee bedoel ik de acceptatie onder gebruikers. Natuurlijk is het fijn als er meer gestructureerd overkomt, maar die meerwaarde wordt al snel minder op het moment dat de arts/vpk alle elementen omtrent 1 signaal/melding bij elkaar moet zoeken in het overgedragen dossier.

We pleiten voor een bewuste strategie om elementen goed op te nemen in de registratie en uitwisselingsset en na te denken over contactmoment-overstijgende rubrieken/groepen/elementen in een evolutie van de BDS, en dit ook mee te wegen in de beslissing wat er opgenomen wordt in de voorgestelde set van wijzigingen.

Er is een functionele eis voor dit element naar voren gekomen die stelt dat het mogelijk moet zijn om dit element los van de overige elementen in G075 (Melding veilig thuis) te registreren. Op dit moment is het in de DOB specificatie niet mogelijk om elementen van groep G075 over te dragen zonder melding veilig thuis. 

Kan het element buiten de groep geplaatst worden? Dan kan het ook los van de groep overgedragen worden in de DOB.

De JGZ-professional moet kunnen aantonen dat hij dit gesprek heeft gevoerd en daarmee de meldcode heeft gevolgd. Daarom heeft de RR ervoor gekozen een apart BDS-element te maken.