ZIB Probleem Diagnosedatum

Dit issue is geaccepteerd in de peer-review van 07-02-2024.

kun je nog even reageren? 

 In de voorgestelde herziening van de zib Probleem zullen we drie verschillende datumvelden hebben:

• BeginDatum van de aandoening: dit is het moment waarop het ziekteproces of de conditie (bijv. zwangerschap) bij de patiënt is begonnen. Vaak zal dat het moment zijn van het eerste symptoom van dat ziekteproces of die conditie. Dit mag een vage datum zijn en desnoods niet gevuld als het helemaal niet bekend is.

• DiagnoseDatum van het diagnostisch inzicht: dit is het moment waarop de zorgverlener tot het inzicht van de diagnose kwam: m.a.w. de diagnose heeft gesteld. Dit moment kan op zijn vroegst dezelfde datum hebben als de BeginDatum van de aandoening. Op het moment dat een zorgverlener bij voortschrijdend inzicht de diagnose wijzigt, zal ook de DiagnoseDatum worden aangepast, want het nieuwe diagnostisch inzicht is na het voorgaande verkregen. Beide diagnoseregistraties zullen wel gekoppeld zijn aan dezelfde aandoening. Zo is duidelijk dat het om voortschrijdend inzicht bij dezelfde ziekte/conditie gaat.

• RegistratieDatum van de administratieve handeling van het vastleggen. Deze datum zie je niet terug in de zib, maar wordt wel altijd vastgelegd in relatie tot de medisch inhoudelijke gegevens die worden ingevoerd. Als een diagnose later wordt gewijzigd, zal elke afzonderlijk ingevoerde diagnose zijn eigen registratiedatum hebben.

Op deze manier zou het altijd duidelijk moeten zijn wat medisch inhoudelijk al of niet bekend is en wanneer dit is geregistreerd.

Als toelichting op de genoemde voorbeelden:

• Als je geen DiagnoseDatum krijgt aangeleverd, maar wel een RegistratieDatum, dan is het moment waarop de diagnose is gesteld niet in de gegevens gespecificeerd en vooralsnog dus onbekend.

• Als het stellen van de diagnose lastig was en er na een voorlopig DBC subtraject alsnog (7 weken later) een diagnose is ingevuld, dan zal

  • de DiagnoseDatum van die diagnose inderdaad zeven weken liggen na de ingangsdatum van het DBC-subtraject;

  • de BeginDatum van de aandoening - indien bekend - zeven weken of meer vóór deze DiagnoseDatum liggen;

  • de RegistratieDatum van de diagnose ws gelijk zijn aan de DiagnoseDatum.

Het is dus inderdaad belangrijk dat het EPD de datum/tijd velden correct hanteert en de gebruiker uitnodigt om ze goed te gebruiken, zodat altijd duidelijk is wat elk vastgelegd datum/tijd gegeven betekent en wat wel en niet bekend is.

Hallo Keetje,

Ik probeer wat duidelijkheid te krijgen over wat je precies bedoelt. Je hebt het over een samensteller van een zib en een gebruiker van een zib. Bedoel je hiermee een zorgverlener die gegevens vastlegt respectievelijk een zorgverlener die gegevens overneemt?

Hai Marty,

Mijn issue zit niet zozeer in hoe het vanuit de arts en de geneeskunde bekeken (functioneel) verloopt in de tijd.

Meer is mijn probleem afkomstig vanuit de praktijk: een diagnose lijkt iets heel hards maar dat wordt helemaal niet 'hard' vastgelegd. Om het functionele gegeven [wanneer is welke diagnose voor het eerst vastgesteld] te zoeken in een Nederlands ZIS, moet je meestal veel tekst interpreteren....helaas.

Wat je altijd wel 'feitelijk' hebt is een (eerst bekende) registratiedatum. Om vervolgens geen interpretatieproblemen tussen een samensteller van een ZIB en een gebruiker van een ZIB te krijgen denk ik dat het relevant is dat het eenduidig te kunnen aangeven.

bv:

1. Samensteller van de ZIB Probleem data heeft gevonden: EEN eerste registratiedatum van een diagnose in ICD10 bij deze patient in dit ziekenhuis.

   1. Misschien heeft een ander ziekenhuis die diagnose al veel eerder gesteld, maar is dat niet zichtbaar of gestructureerd vastgelegd in het ZIS. De WERKELIJKE diagnosedatum ligt dan vroeger in de tijd.

   2. Misschien was het stellen van de diagnose lastig en is een DBC geopend in het ziekenhuis die achteraf de diagnose C90.0 heeft gekregen maar dat was pas na 7 weken onderzoek echt bekend geworden. De WERKELIJKE diagnosedatum ligt dan 7 weken verder in de tijd.

2. Gebruiker van de ZIB Probleem kan de diagnose uit ZIB probleem op dit moment interpreteren als de WERKELIJKE diagnosedatum terwijl deze niet weet dat dit ook de subsituaties zou kunnen zijn, omdat de naamgeving van onsetDatetime dat niet impliceert. Mijns insziens is een registrationDatetime handig om dit onderscheid te kunnen aangeven. Op die manier maak je het onderscheid voor een gebruiker en kan deze de gegevens juist interpreteren, zonder extra uitleg.