OHDSI Home | Forums | Wiki | Github

Atlas: How to set index date to absolute day or to get_todays_date()

Researchers
#1

For a cohort that finds patients for a review by case manager, I need to have criteria relative to index date that is somewhat different from typical OHDSI cohorts.

Is it possible to set the index date in Atlas for a cohort to some absolute day (e.g., April 1, 2020) or to today minus 20 days)? From the SQL logic, I know it should be possible.

If it is not possible within Atlas (which I think is the case), I will file a github issue about this - but I wanted to be sure I did not miss anything.

Here is the click in Atlas where I need to select an absolute date: Add Initial Event (options there)

image
image1003×624 51.2 KB

2 Likes
#2

create an observation period cohort entry event, and use the option to ‘specify start and end date’ If you just want a single date, then just set the start date = end date…I recommend you do this.

Btw: this criteria will automatically only include those people who have an observation period that covers the specified dates. If you do something like 2013-01-01 to 2018-01-01, only people who have a single observation period that spans this range will be included in the cohort.

2 Likes
#3

Thanks.
Here is the cohort I just created using your guidance
http://atlas-demo.ohdsi.org/#/cohortdefinition/1774429

image
image1628×1761 258 KB

I need the cohort end date to be wide (for cohort pathway analysis) (so I used offset from start date to have cohort end date to be +365 days after my absolute index date of jan 1 2017.

If I got something still wrong, let me know.

#4

That’s fine, just remember that even tho you ask for 365 days, some people may end their cohort at the end of observation before the 365 days. Therefore, if you want to require that they have the 365 days, you can specify the observation period must end after jan 1 2018.

1 Like
#5

@Chris_Knoll – this only works if you want a specific absolute day that is actually observed, right?

Is it possible to identify an observation period and then set the cohort start date to be something explicit, like 2017-01-01?

#6

Nope, it doesn’t require the date was actually observed, and Yep! you can do that: if you make an entry event from ‘Observation Period’ and you use the ‘user specified date’ param, the person will enter the cohort on that date IF they have an observation period that covers the date. The date you enter does not need to come from an observation that appears in the data (ie from a visit, condition, drug exposure, etc).

-Chris

#7

So if I try this with 2017, looking to identify patients that contribute any time in 2017 and then specifying the ultimate cohort start date be 2017-01-01 and cohort end date be 2017-12-31 like this:

https://atlas-demo.ohdsi.org/#/cohortdefinition/1787935/definition

Doesn’t the SQL not do this? If a patient has a small observation period beginning and ending in June 2017, they wouldn’t be be allowed in based on the snippet below.

WHERE C.OBSERVATION_PERIOD_START_DATE <= DATEFROMPARTS(2017, 1, 1) and C.OBSERVATION_PERIOD_END_DATE >= DATEFROMPARTS(2017, 1, 1)
AND C.OBSERVATION_PERIOD_START_DATE <= DATEFROMPARTS(2017, 12, 31) and C.OBSERVATION_PERIOD_END_DATE >= DATEFROMPARTS(2017, 12, 31)
#8

That means that you are requiring the person’s observation period time that covers the entire year.

The challenge of what you’re asking for is ‘people having any time in 2017’ and then turning around and specifying a date. if the ‘any time’ is september 1 2017 and later, and you specify a start date that is June 1, that person can’t come in (they weren’t in the data in June 1).

In order for the described function to work, you need to specify a date that the person is required to be in (or a date range) and if their OP covers it, they are in.

What we’ve done is we’ve specified a start/end of Jan1 - jan1, meaning that if they are in the data on jan 1, make the cohort entry event Jan 1, and then later we can extend the ‘presence’ in the cohort by adding 365d to the start date. This gives you a ‘calendar cohort’.

I think I understand with the concern with your context: you want the person’s start date to be sometime in the target year of interest…, and there could be a way to expand the entry event criteria to allow these ‘mid year’ starts:

Entry Events:

  1. OP Start date where start date between Jan1-2017 to Dec31-2017
  2. OP with user defined dates: Jan1 , 2017 - Jan 1, 2017

#1 will give you the OP start date of when the person starts in 2017
#2 will give you a Jan1 start date if the person is in the data as of Jan 1 2017.

The trick now is that the people that enter in the middle of the year, you can’t just add 365 to them because that will make their end date go past 12/31 (We want the cohort episode to end on 12/31 in our case).

To do that, we could make both entry events last till end of OP, but use CENSOR EVENTS to create end dates of 12/31 for each year of interest.

So, for the person who starts sometime in 2017, we’ll have the #1 cover that case and yield a date of when they started in 2017, but they will be censored not at end of OP, but at 12/31/2017 (by using a censoring criteria of 12/31/2017

A person who started outside of 2017 but led into 2017 will be captured in #2: the’ll get a Jan1 2017 start date, and they would default exit at end of OP, but with the 12/31/2017 censor event, they will get stopped at the end of the year. We’d repeat this pattern for each year we want to capture patients.

This is 5th dimensional thinking, but I hope it makes sense.

#9

I’m enjoying the 5th dimension here :slight_smile:

Can we censor purely on dates in Atlas? I thought we can only use criteria events there.

#10

Observation Period with a user defined date is a criteria event!

#11

I’m not seeing Observation Period as a censoring event?

image
image792×1238 101 KB

#12

That’s a bug, it should be. Tho the only way for it to make sense is when you specify a start/end date of the OP criteria…but, if they can be used in entry events, they should be allowed in exit events. We’ll add it next release.

As a work-around, maybe creating a re-usable with an OP criteria will let you add it :slight_smile:

1 Like
#13

Ugh, unfortunately, a reusable borrows the same options for censoring event (this is where we have the distinction between primary events/censoring events and criteria groups).

I’ll log as a bug. Thanks for the brainstorm!

t