| OHDSI Home | Forums | Wiki | Github |
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.
Thanks,
Guy
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!
Kristin
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.
-Chris
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.
Thanks,
Guy
Hi,
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:
Regards,
Guy
Hello.
I have a question… about “restrict to the same visit occurrence”.
It means that all the rules included in a specific inclusion criteria must occur in the same visit?
Or ir also needs that these rules occur in the same visit than the cohort entry event?
The visit of the cohort entry event must be the same as the ones found in the inclusion criteria. By extension, all the rules in the specific inclusion criteria will also be at the same visit (because those will be at the same visit as the cohort entry event).
If you use ‘nested criteria’ then when you specify ‘same visit’, the criteria in the nested criteria must be at the same visit as the ‘root’ criteria.
Some things do not have visits…if you start with an Observation Period as the root criteria and you nest to a condition, there are no visits associated to observation period, so no nested criteria will match with ‘same visit’.
What if you have several visits (because your are “limiting initial events to all events” in your cohort entry events section)?
Then how will “restrict to the same visit occurrence” work?
Each entry event can have a visit associated to it. You can’t say all entry events must come from a single visit. But, once you have your ‘all events per person’ set of entry events, each entry event is evaluated to find the associated nested/inclusion rule criteria and if you specify ‘same visit’, then all the associated criteria referencing the entry event will all occur at the same visit as each other.
