MaximMoinat
commented
3 months ago That makes sense to me. The check is already implemented such that a record violates it if event_date < birth_date. So same date is allowed. https://github.com/OHDSI/DataQualityDashboard/blob/98c825a9449a5d15413669a7e931f98b1e1c51c9/inst/sql/sql_server/field_plausible_after_birth.sql#L45-L46
When looking at event datetime, things indeed go wrong. The event is cast to a date, but the birth_datetime is not and will still have a time component. This explains your findings; all datetime of events happening at same date as birth will violated the check.
Two possible solutions:
- Cast
birth_datetimeto date, allowing all events that are on the same day as birth (disregarding time of day) - Add separate clause when dealing with datetime fields to take the birth time into account.
I would propose the first as it is simple to implement and consistent.
katy-sadowski
rakeshnbabu
First, thank you @katy-sadowski, @MaximMoinat and all who update, maintain and support the DQD! This is a very useful tool and we rely on it to ensure our data are of high quality.
One suggestion, the new plausible before birth checks require an even start before birth. However, in our source data some of our events start at birth. So, a baby has a birthdatetime of 10am on December 31, 2024, their visit_start_datime is also at 10am on December 31, 2024. The DQD requires birthdatetime < visit_start_datime. I think changing the check of birthdatetime < or = visit_start_datime would be more appropriate since visits (and possibly other clinical events) can start at birthdatetime.