Your browser does not appear to support JavaScript. You may want to try one of the following:
You may want to try one of the following:
If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:
shift
control
Show details
Hide details
This form has to be reloaded. This most likely happened because your session has expired, which might take to the login page. (If you think that you shouldn't see this message and that the problem persists, please contact support.)
In de redactieraad van 31-01-2020 is besloten om alle elementen uit de rubirek contactmoment gebonden te maken/houden. In een registratiehandleiding zal beschreven worden dat de drie elementen 1583, 1584 en 1587 slechts eenmalig geregistreerd dienen te worden. Er hoeft in de DOB niet gecontroleerd te worden of het betreffende element niet toch meerdere malen voor komt.
Als men de elementen toch vaker registreert, dan is de meest actuele registratie geldig.
Allereerst denk ik dat Meindert-Jan gelijk heeft dat minimaal een aantal van de BDS-elementen 869, 5063, 1584, 870, 871, 1587 en 1583 niet thuishoren op de huidige locatie encounter/component3/substanceAdministration.
Echter: zonder schemawijziging is er binnen encounter/component3 geen alternatieve ruimte. Het alternatief dat ik zie is deze elementen verplaatsen naar encounter/pertinentInformation/rubricCluster/observation elementen. Ze komen dan op dezelfde plaats te staan als elementen uit de meeste andere contactgebonden rubrieken.
Dat ziet er dan zo uit:
Berekende velden gaan normaal niet mee in de DOB dus 1583 (Interval maternale kinkhoestvaccinatie en geboorte meer dan 2 weken: 1583 0..1 (W0167, BER, Berekend veld)) zou je om die reden niet verwachten.
Op de vraag of (sommige van) deze elementen eigenlijk wel contactgebonden elementen zijn, moet ik het NCJ raadplegen.
Betreft BDS-elementen: 869, 5063, 1584, 870, 871, 1587 en 1583
Ik zat nog eens naar ons datamodel te kijken en deze naast de BDS en de Templates te leggen. Hieruit bleek dat we het bijna volledig conform de template geimplementeerd hebben, maar dat hierin ook een vreemde situatie kan ontstaan.
Men neme bijvoorbeeld BDS-element BCG litteken (5063). Het lijkt mij logisch dat een medewerker dit altijd zou moeten kunnen vastleggen in een DDJGZ, ongeacht of er ook vaccinaties gegeven worden. Het lijkt mij ook logischer om een dergelijk element slechts éénmaal te registreren en niet meerdere keren in het dossier (m.a.w. niet-contactmomentgebonden), maar dat is niet mijn grootste zorg.
De BDS is niet in lijn met de template. Bovendien klopt ook de cardinaliteit niet.
BDS: R041 = 0..1 (contactmomentgebonden), BCG litteken (5063) = 0..1.Effectief dus 0..1 (per contactmoment)
In de template: hl7:component3 (0..1) / hl7:substanceAdministrationEvent (0..*) / hl7:vaccinationObservation (0..1). Effectief dus 0..* (per contactmoment, mits een vaccinatie of bezwaar geregistreerd wordt, die zijn namelijk M binnen een vaccinationObservation)
Als iemand dus een dossier zou willen versturen met een BCG-litteken registatie, maar zonder vastgelegde vaccinaties, dan is dat nu dus onmogelijk.
Als we dit aanpassen is dat best wel een schemawijziging. Ik vraag me echter wel af hoeveel leveranciers al gegevens geimplementeerd hebben buiten de benodigde gegevens voor uitwisseling met RIVM om.
Kan dit in ieder geval besproken worden door een aantal inhoudelijke instanties/artsen? Ik ben vooral benieuwd of de huidige BDS-opzet klopt met een dossier (dus is bijv BCG litteken een contactmoment-gebonden gegeven?)
Ik mis overigens ook een voorbeeld van één van de bijzondere elementen.
Mijn voorstel zou zijn om de BDS-elementen 869, 5063, 1584, 870, 871, 1587 en 1583 één niveau hoger te plaatsen, als direct kind van component3.
Ik vermoed dat veel leveranciers dit en de andere "bijzondere" vaccinatie-elementen, niet conditioneel aan een vaccinatie hebben geimplementeerd. Wij hebben dat wel, maar ik sta er zeker voor open om dat aan te passen, aangezien onze huidige setup niet klopt met de cardinaliteiten van de BDS.