OHDSI Home | Forums | Wiki | Github

Hierarchical cohort entry using Atlas

Hello everyone!

I had a question regarding building cohorts on Atlas.

I would like to implement a hierarchical cohort entry criterion using Atlas, however did not manage to find a way around and would like to have your input to see if it is possible. I want to include patients with HF in my cohort based on inpatient and emergency visits. The hierarchy would be:

  1. If the patient only has inpatient visit, the index event would be the inpatient visit.
  2. If the patient only has no inpatient visit, the index event would be the emergency visit which lasts for max 24h.
  3. If the patient has both inpatient and emergency visit, the index event would be the inpatient visit (not the emergency visit).

Since I would be using the Standard Concepts for visits, the information I provided above might be a bit redundant and this might be then more of an ETL question. When I use the combination of Inpatient, ER, Inpatient and ER visit concepts and take the latest record, would the patient record already only contain the inpatient visit entry since this would occur after ER visit and would be linked?

As a bonus question, to make sure that I am only capturing acute events, should I define a cohort exit criteria for the hospitalization period as well as a cohort era collapse period?

Thank you for your input in advance!

You would use nested criteria to make each option mutually exclusive (ie: 1 if 2 and 3 fail, 2 if 1 and 3 fail, 3 if 1 and 2 fail).

But there’s some missing information. when dealing with cohorts, you have to be considerate of time:

One inpatient visit…ever? For their whole lives? Ok, then just say:

  • an inpatient visit having all of (no inpatient visits before and no inpatient visits after and no emergency visits ever where duration is > 24h).

No inpatient … ever? Ok…you want the ER visit that lasted at least 24 hr:

  • an er visit lasting with duration of 1 day having (no inpatient visit any time before or after)

an emergency visit with an inpatient visit…ever? Ok

  • an er visit with duration of 1 day having (an inpatient visit any time before or after)

I believe these three rules are mutually exclusive because if you satisfy 1, then you won’t have ER visits from 3 and you by definition have an IP visit so you won’t satisfy 2.

If you satisfy 2, then you couldn’t satisfy 1 and 3 requires that you have both, so the ‘no inpatient visit’ precludes you from 3.

If you satisfy 3, then you had both IP and ER, the ER exclues you from 1, and the IP excludes you from 2.

Thank you for your answer!!

You are completely right that I have missing information here with regards to the construction of the cohorts. The idea would not be so much of mutual exclusivity, but if the patient has both an inpatient and ER visit in the same occurrence of their condition occurrence within 7 days (assuming this is an acute event), then we would like to define their cohort entry as the inpatient visit, instead of the ER visit. This might already be resolved when we use the visit concept of ‘Inpatient and ER visit’ if the condition occurrence for the same patient is already linked, which is where my information on the CDM logic is lacking. And as you suggested, for using ‘Emergency Room Visit’, I can then add a nested criteria to indicate exactly ‘0’ inpatient visit around the time when the patient would be expected to be hospitalized.

Overall, it was not the aim to look into patients who have one inpatient/ER visit ever, but to be able to capture all the acute events of HF. That’s why I was also wondering to achieve this ‘acute event’ aspect, whether I should implement the cohort exit criteria as the end date of the cohort entry event and define cohort era gap size as the predicted hospitalization period.

I hope this makes it a bit clearer now, it is always difficult to explain these cohort logics in writing.


This is classic. You are trying to do several things at the same time:

  1. Find patients with the clinical idea (phenotype): acute and severe event of heart failure
  2. Determine the right onset of the condition for time-based causal inference
  3. Count the number of such events, for which you need the time of resolution of the condition so you can separate one from another acute HF event.

Unfortunately, there is no nice Condition record with an acute and severe heart failure concept and a condition_start_date and condition_end_date to rely on. Instead, the diagnosis records keep coming, usually just for HF, and at some point stop. To get the acuity, severity and timing, you use other contemporaneous data, making the assumption that an ER visit or an inpatient visit with the right diagnosis will do the trick for you. So, just use the visit as the index criterion, and require the right diagnosis in a separate HF condition inclusion criterion to happen between the start and end_date. To make sure the HF is not some trivial side problem you can also

  • Make the condition the index criterion and add the attribute of the right visit (that will make sure they are linked)
  • Make the condition the index criterion and add the attribute of the right condition status (confirmed diagnosis, discharge diagnosis, primary admission diagnosis, primary diagnosis, primary discharge diagnosis, primary referral diagnosis, referral diagnosis)

What I don’t understand is your puzzle with the ER and inpatient visits. What are you trying to do? Patients with symptoms of an acute and severe HF either call 911 and get rushed to the ER or they go to their doctors who refer them to the ER or right to the hospital. Both are equally good for detecting acuity, severity and index date. To get the cohort exit time all you have to do is to let Atlas collapse events with a gap of 0 days: That way, any inpatient visit immediately following the ER will be merged, making the visit_end_date of the inpatient visit the cohort_end_date. It will also de-duplicate several conditions with the same visit, if you used the condition with attributes as the index criterion.

To add to Christian’s list, many people overlook the condition_type_concept_id field. In order to identify an acute heart failure condition, I would exclude condition_type_concept_id = 32840, EHR problem list. The problem list is a list of active conditions a person has which might be influencing their current physiological state. So, they might have a visit for acute pneumonia and HF will be listed as a condition on their problem list during their visit.