Thanks @fabkury , this is a great thread to initiate as part of PhenotypePhebruary:).
I’m hoping that, as we are building phenotypes and consider using ATLAS, we can expose ‘limitations’ based on real need (rather than just unavailable features that aren’t actually required to complete an applied task).
That said, some of the limitations are listed in issue tracker on github for CIRCE (the cohort component underneath ATLAS) that @Chris_Knoll maintains: https://github.com/OHDSI/Circe/issues. And if anyone encounters other limitations, this would be a good place to capture them.
As it relates to phenotypes that I personally have had to build for which I KNOW that ATLAS can’t (yet) handle:
- currently, the entry event in ATLAS is always the START_DATE in each of the CDM tables. The user can’t change that to END_DATE. So, for example, you can create a cohort of ‘hospital admissions’ but not ‘hospital discharges’ (meaning cohort_start_date = visit_end_date).
- Also, the user cannot add an offset to the entry event. So, for example, if you wanted a simple phenotype for pregnancy episodes amongst women with live births, you can’t make cohort_start_date = (‘live birth’ condition_start_date) - 9 months. When you use future markers to infer prior events, this could be helpful (and in our more advanced ‘pregnancy episode’ algorithm that we previously published, it would likely enable us to implement in ATLAS rather than having to rely on our current code)
- Currently, the exit strategy allows for selection of one event persistence option: ‘end of continuous observation’ OR ‘fixed duration relative to initial event’ OR ‘end of a continuous drug exposure’. I’ve encountered some situations where I want to end after continuous observation of non-drug events (for example, if you are dealing with a condition and want to try to end it after the last of follow-up care, you might want to era-fy the data after you no longer see any symptoms, conditions, treatments or procedures indicating active management of the disease). Also, I had a recent edge case where I wanted to use multiple event persistent options (example from our GLP1 reproducibility challenge cohort: I want a person to leave an exposure cohort after EITHER they stopped exposure OR had made to to 365d post-index (whichever came first)).
Other ‘limitations’ that I am aware of but have never personally impacted any of my phenotype development work: ATLAS doesn’t cover all CDM tables: for example, the new EPISODE tables added in v5.4 are not used. It also doesn’t support the COST, NOTE, NOTE_NLP, FACT_RELATIONSHIP. And as @fabkury points out, ATLAS doesn’t do generic computation of composite scores or derived values across sets of measurement values.
All that said, I have to say that I’m always extremely impressed with what @Chris_Knoll has built, because I’ve now made hundreds, maybe thousands, of cohorts using ATLAS and it is quite rare (<1%) that I reach the conclusion of ‘can’t be done’, sometimes it takes a little creativity to model but often I find a solution for the data that I’m working with. So, on expectation, ATLAS is a great place to start if you are starting your journey to build a rule-based phenotype algorithm.