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.

t