OHDSI Home | Forums | Wiki | Github

Timestamps for cohort_start and cohort_end instead of just dates

Please excuse my naivety, but our group had a question on if there was a reason cohort_start and cohort_end fields are dates instead of timestamps.

Because the granularity of the timeframes are at the day level not the second level.

Or put another way: ATLAS currently operates at the day level.

The CDM supports below the day level but we do not currently have this functionality in ATLAS.

Thank you @Chris_Knoll & @krfeeney, do we know why ATLAS is limited to the day level?

ATLAS has been around longer than the CDM’s support of datetime fields.

You’re always welcome to stop by the ATLAS workgroup meeting to learn how the tooling is evolving. The Workgroup has set their OKRs for the year and are marching ahead.

The next meeting is on Wednesday, April 6 at 9AM EDT. More details are available on the Upcoming Work Group Calls. You can also follow along by joining the area on MS Teams – fill out this form to be added to the ATLAS group.

Thank you for the information Kristin, I signed up and hope to attend future meetings!

1 Like

Perhaps also relevant: there was a discussion on date_time vs date in the CDM. In the end, we decided to keep using date as our primary unit of time (e.g. in CDM 5.4, but also in most of our tools). The reason is that most of our data is at the date level. If your entire database is at the date_time level, then the logic in our tools would still be straightforward. However, it gets hopelessly complicated if only some of your data is at date_time, and some is at date. @Selvin : is all your data at the date_time level of precision?

@schuemie, our CDM data is at the date_time level of precision. We are being asked to have Atlas generate cohorts at the same level so figured we would ask before starting development on our end.

@schuemie or @Selvin, any updates on when Atlas might support datetime?

We have a number of quality and safety metrics and protocols we want to assess what require datetime. For example, some sepsis protocols require a series of events to occur over several hours. Separately, there are metrics that require (or contraindicate) certain drugs within X hours of other drugs or procedures.

Although we have been able to mock up these rules as cohorts, we then have to modify the generated SQL to use datetime, which makes them harder to maintain and less portable.

Perhaps if there were an Atlas option to specify (either globally or by criteria widget) whether to use datetime instead of date?