OHDSI Home | Forums | Wiki | Github

"Restrict to the same visit occurrence" in ATLAS Feture analysis

Hi all,

I have an issue with “restrict to the same visit occurrence” in the feature analysis.

While creating a new feature analysis, I added a new criteria feature and marked it as “restrict to the same visit occurrence” it returns zero results.

When replacing the “restrict to the same visit occurrence” with “Event starts between 0-7 days after index date” it returns value.

My data is based on Hospital EHR and visit_occurence_id connects all facts.



Hi @guy_livne!

Yes, visit_occurrence_id is a really handy field that can create linkages among CDM Domains. The challenge is that visit_occurrence_id is only a required field in some CDM Domains (e.g. VISIT_OCCURRENCE, VISIT_DETAIL). It is not required in CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT, OBSERVATION, and NOTE. This is true for both V5.3 and V5.4 specifications (See the CDM wiki here: OMOP CDM v5.3).

What this means is that if you build logic to restrict to the same visit occurrence for a feature that comes from one of these domains where it’s not required, you may be asking your CDM to join on visit_occurrence_id but there’s nothing populated. Because of that requirement you get a 0 count. However, when you change to a date range, you are no longer requiring that the visit_occurrence_id be populated. You are use date stamps to link features adjacent to that index date without imposing that the visit_occurrence_id exist to confirm it’s exactly the same visit occurrence. There’s a lot of reasons why visits (or encounters as some EHR users call them) get enumerated and all their pieces don’t always end up neatly tied together via this linkage ID. I’m sure @MPhilofsky can layer on more experience here.

I try not to mandate my queries pull from not required fields unless I know there’s been a local ETL project to populate that element. Most ETL teams start by filling in what’s absolutely required to build the OMOP CDM and over the years, go back and augment when they have capacity to do so.

Hope that helps clarify!

In addition, I want to point out one element that may not be obvious when creating ‘feature analysis’ that @guy_livne mentioned:

When starting with a cohort to characterize, all information about visits that were attached to events that built the cohort is lost. The cohort is just a period of time you satisfied the criteria.

So, when you create a feature, and you create a count where you are looking for events relative to the cohort start/end date, there are no visits attached to those records that are coming from the cohort table. so you will never find a match from a cohort record to a domain record where you are restricting to same visit.

So, where do you use ‘restrict to same visit’ in feature analysis? Nested criteria. You can look for a condition relative to the cohort entry, and then find a procedure (via nesting) that occurred during the same visit.

Hope that helps.


Thanks, @krfeeney, and @Chris_Knoll the information is very helpful.

Indeed, not all our records have the Visit_occurence_id populated but we have managed to populate almost all the event tables except for some records in observations table that cannot be related to a specific visit.

I understand Chris argument and I will try to do it, I will publish the solution here while manage to do it.




It was more complicated then I thought, but here is the solution for how to find the population of death in the same cohort entry date visit, as both entities have no relation to a specific visit.

The solution is first to query the cohort entry date between the visit start date and visit end date, and then check if the death date is between the specific start and end visit dates.

In the ATLAS Feature analysis it will look like this:


1 Like