OHDSI Home | Forums | Wiki | Github

Perhaps `condition_end_datetime` should also be mandatory?


(Clark C. Evans) #1

For the move to CDMv6, perhaps condition_end_datetime should be not null as consistent with other tables?

I’ve noticed drug_exposure_end_datetime is mandatory. This is smart since analysis logic doesn’t have the background necessary to easily know when a drug exposure period has ended, besides guessing that it’s the start_datetime plus the days_supply, or failing that, the start_datetime + 1day. In this case, an ETL process could make a better guess, and this guess can be seen in the database itself.

For other tables, end_datetime is also mandatory, except for condition, where it remains nullable. Why? Perhaps a null ending datetime might indicate a condition isn’t yet resolved and is ongoing? But, there’s a challenge with this. Most of the cohort logic that I’ve reviewed is defaulting a missing end_date to start_date + 1day – it is not defaulting to the last day of the observation period. In other words, the cohort logic doesn’t treat the null value as an indeterminate interval ending, as is the treatment in the Clinical Quality Language (CQL). Instead, the default logic (making it equal to start_date +1 day) is applied universally, when other information at the data source might be better equipped to make a more plausible ending value on a case by case basis.

(Christian Reich) #2


Very apropos. @clairblacketer, @Patrick_Ryan and I are rewriting the logic behind what is mandatory and needs be inferred, and what isn’t. We also are fixing some mistakes in the documentation.

In your example, you are right: For drugs, it’s easier to infer the duration, for conditions it is not. The reason is that drug duration is anticipated and planned, and the ETL can figure out the way to determine that. While conditions come and go as they please (some are more acute than others, but still). When people heal, they just stop showing up at the healthcare system. There is often little explicit resolution of a condition provided in our data. Usually, conditions are just captured in a moment of time.

The cohorts actually can be specified whether or not the end is based on the start date or the end date of the indexing feature for exactly that reason.

(Clark C. Evans) #3

@Christian_Reich It’d be nice to document how a null condition_end_datetime should be treated with various cohort definition use cases, as a cross reference. For the most part, I’ve only run across end_date = start_date + 1day in CDM5 SQL cohort logic. Regardless, for the limited cohort SQL that I examined, the inclusion logic seems to be driven only from the start_date (aka index date) and not this calculated end_date. Are there public examples of cohorts where the end_date of a condition is relevant to the query logic?