OHDSI Home | Forums | Wiki | Github

Repeatedly entering a cohort

(Swammer) #1

Hello - I am hoping someone might be able to shed some light on a cohort question. I am attempting to build a cohort on atlas that allows one person to enter the cohort multiple times. More concretely: I am trying to count all ED visits with a dx of Asthma that occur at my hospital. This should include multiple visits by more than one person, yet when I generate the SQL query on ohdsi/atlas and run it on my local CDM, the table that is generated only allows a person to enter the cohort a single time (i.e. there is only one ED visit recorded per person). The cohort definition is [DBMI] ED Visits w/ Asthma Dx (cohort#1769235) on ohdsi/atlas, and it’s unclear to me why this query does not allow multiple visits from the same person. The description of the cohort is as follows:

[DBMI] ED Visits w/ Asthma Dx
Initial Event Cohort
People having any of the following:
a visit occurrence of [DBMI] ED Visit2
with continuous observation of at least 0 days prior and 0 days after event index date, and limit initial events to: all events per person.

For people matching the Primary Events, include:
Having all of the following criteria:
at least 1 occurrences of a condition occurrence of [DBMI] Asthma Dx1
starting between 0 days Before and 0 days After event index date
occurring within the same visit
Limit cohort of initial events to: all events per person.
Limit qualifying cohort to: all events per person.

I think there is something embedded in the limiting of initial events or limiting of qualifying cohort, but as I’ve specified all events, I would think that this allows one person to be counted in the cohort one time for each repeated visit rather than one time overall. Any thoughts?


(Eldar Allakhverdiiev) #2

Hi @Swammer,

These are couple of things:

  1. I can be wrong but I’d use Condition occurrence as initial event instead of Visit (more knowledge about your data is needed)
  2. You specified cohort_start_date, but didn’t do it for cohort_end_date. By default observation_period_end_date is used for it. Records are then collapsed to some union period (cohort era overlapping is not allowed). Change cohort Exit criteria.

I only added cohort end for 1 showcase as well as used Condition domain as proxy
and run on data. Number of records is 2-3 times person count in both designs.

Here You can find more profound talks about the logic of builder

(Chris Knoll) #3

@Eldar has the right of it. However, one thing I’d modify in the cohort definition: if you are going to use ‘restrict to same visit’, then you don’t need to restrict the before/after days to 0 days. you can make it very wide to allow finding the condition during a long visit (even specifying ‘all days before to all days after’. Using the ‘restrict to same visit’ option ensures that the diagnosis occurred during the outer visit from the initial events.

(Swammer) #4

Thank you @Eldar and @Chris_Knoll! I wanted to use visit occurrence as the initial event because my actual goal is to count the number of asthma-related ED visits each day. Your suggestion, if I’m understanding you correctly, is to first find all asthma diagnoses, and then find the visit occurrence = ED visit that is linked with that asthma condition occurrence? Regarding cohort exit criteria, if I’m understanding correctly, when not specified in the Atlas builder, the implied exit date for a subject is the end of the observation period. If the end of the observation period is many days from the entry date -> then multiple visits by the same person may be obscured because they need to exit the cohort in order to re-enter it? So then we’re saying: a person needs to exit the cohort in order to re-enter it and be counted multiple times?

(Chris Knoll) #5

No, if you want visits, then make your initial events ‘all visits’ and qualifying criteria : diagnosis of asthma during visit, all days before all days after’. You can also ‘nest’ that diagosis with the visit criteria, but that’s more advanced usage. You can get by via any visits, and then add qualifying crteria that visit must have a asthma diagnosis during the visit. The cohort events will be visit dates, not diagnosis dates, which I think is what you want.

Yes, that’s right: if you don’t specify an exit, then the person would have each visit identified ‘squashed’ into one long episode starting with the earliest qualifying visit to the end of their observation period. If you want to treat the visits as the ‘episodes’ then add a ‘fixed date exit strategy’ to your cohort definition: exit on the event (visit) end date + 0 days. Then each sub-episode will be the visit_start -> visit_end. On the other hand, if you want to count distinct visits, you can set the exit strategy as start_date + 1 day. and then visits that might overlap should be counted (because you’re making the episode duration 1 day). However, if you have multiple visits on the same day, they will get squashed so you can’t rely on the number of episodes = number of visits.

The use-case you are stepping into is more ‘cohort characterization’ than cohort definition. when you say ‘I want to know the number of visits these people had’, you’re pre-supposing an existing cohort of people. You could design a cohort definition to be interpreted as ‘the number of episodes = number of visits’, but you’re working outside the intended purpose of cohort defintion. Ie: population selection vs. population characterization.


Hello everyone,

I experienced the problem similar to this topic.

What i tried was to get a single ER or ERIP visit as a single cohort.

Referring to topic and answers(thanks @Chris_Knoll)
i made a cohort as below. but, the generated count of ‘people’ and ‘records’ was same which means multiple visits of a single person didn’t go to different cohort records.

I wonder whether this is a bug or my misunderstanding of using Atlas.


(Eldar Allakhverdiiev) #7

Hi @Suho_Jin,

You can try the following:

  1. Click ‘Remove initial event restriction’ - ( this is optional building block, and since your cohort doesn’t have it, no need to keep it)
  2. In the ‘Inclusion Criteria’ switch ‘Limit qualifying events’ to ‘all events’.
  3. Rerun generation.

The point is that part of the cohort generation code, that is generating ‘Inclusion Criteria’, is essential and can’t be skipped. Thus, even if you didn’t specify any inclusion criteria, you still need to sync limit strategy between ’Cohort Entry Events’ and ’Inclusion Criteria’
You can go to ‘Export’ tab in the cohort and choose SQL to see what’s going on in the code:


Thanks so much! @Eldar

it works great.

I spent hours looking for SQL and found ordinal=1
but, as i put nothing on inclusion criteria, thought it was a bug.

thanks again for your help.