OHDSI Home | Forums | Wiki | Github

Seeking guidance regarding VISIT_CONCEPT_ID in VISIT_OCCURRENCE

Implementers
#1

I have some questions regarding how to implement VISIT_CONCEPT_ID in VISIT_OCCURRENCE. We are currently using OMOP CDM v5.3.

The process to populate our OMOP data starts by combining different representations of encounters across disparate EHR systems and then assigns them new patient and encounter numbers. Patient information is extracted into a separate table in the following step. The scope of the encounter number is roughly analogous to one episode of care. At this stage of the process, we have encounter types of Outpatient, Inpatient, Emergency, and Emergency to Inpatient only. These encounter types are derived from our locations, so an encounter inherits the encounter type of a location that it’s associated with.

The problem that I am running into at the OMOP implementation step is that many of my encounters have multiple VISIT_CONCEPT_IDs that are are correct at different times within the context of the encounter. Here are some examples of what I’ve seen:

  • Outpatient encounters (based on location) with an attached telephone component.
  • Outpatient encounters that our Epic instance flags as ambulatory care visits.
  • Inpatient encounters with follow-up telephone calls.
  • Inpatient encounters flagged in our Epic instance as being an Office Visit.
  • Outpatient encounters flagged in our Epic instance as being an Office Visit.
  • Inpatient encounters flagged as both Ambulatory Care and Office Visit.

What I’m running into is that there is no clean way to represent all facets of a VISIT_CONCEPT with just one row. I find that many of these meta groups - Ambulatory Care, Office Visit, Telephone Encounter - cross the divide between Outpatient, Emergency, Inpatient, etc., and that the best way to represent them is to have one row per VISIT_OCCURRENCE_ID/VISIT_CONCEPT_ID, and treat that as the primary key.

Am I mistaken in my approach to either conceptualizing or solving this issue?

#2

Suggest you read this documentation on visit_occurrence, it is for CDMv5.4, but also applicable to 5.3. I do not believe there is a one to one match between and Epic episode and the OMOP definition of a visit. For example an inpatient visit with follow-up telephone calls should, in OMOP, be separated into two Visit Occurrence records, one for the hospitalization and another for the telephone follow-up (if you care to record that information).

Another way to help you in deciding what constitutes a visit is to think about how your OMOP CDM will be used. Visit type is often used in selecting cohorts of patients. A researcher may only be interested procedures performed within a hospitalization.

“…and that the best way to represent them is to have one row per VISIT_OCCURRENCE_ID/VISIT_CONCEPT_ID, and treat that as the primary key” Not so, make these into separate Visit Occurrence records.

1 Like
#3

Let me start with the following: encounters in Epic can be very difficult to define into the 4-5 major categories (ER, IP, OP, IP to ER, SNF) of OMOP Visits. And an encounter type in Epic doesn’t necessarily align with OMOP visit types. Even when it seems obvious.

Upon chart review and deep dives into the data, we have discovered Office and Ambulatory visits happening when a person is in the ICU on a ventilator. That person didn’t get up and go to the clinic. The Provider came to them, but this is the way it is recorded in Epic. So, you can’t rely on the encounter type to define the Visit.

There are also a lot of EHR transactional visits where a person is not interacting with a provider, but some interaction occurred with the person’s EMR record, so a visit/encounter was created in Epic. OMOP doesn’t consider these real visits and these shouldn’t be brought in to the CDM

There are some Epic Clarity and Caboodle tables which mostly define IP and ER visits. Use those as a starting point, but note that Epic doesn’t consider an “observation visit” as an inpatient visit even though a person could be in a hospital bed receiving care just as a person having an “inpatient visit”. Also, make sure to exclude visits which did not happen. People go to the ER, wait a few hours and then leave without being seen. This is an encounter record in the EHR, but the person never got further than checking in and sitting in the waiting room. This is not a visit in OMOP. And check out the forums on the Epic User Web, search “OMOP”, there is some guidance there. But note, Epic encounters are very different at every institution. Chart review and experts at your EHR sites are your SME’s.

#4

This is what I was searching for in the documentation but did not explicitly see. Why would these be split into separate Visit Occurrence records instead of tied to the same one? My Visit Occurrence IDs are assigned based on the episode of care, so I only have one source identifier (the account number) to join back to my source on. There’s a many-to-one mapping between the contact serial number and visit occurrence id that I flatten out as part of my ETL.

I would definitely agree that this mapping is not as straightforward as it would seem. I can also confirm I remove all data fragments that do not represent an “OMOP visit”.

#5

The OMOP Common Data Model is intended to be independent of the source data. The fact that an Epic episode does not correspond to the OMOP definition of a Visit Occurrence is not really pertinent. If you feel it important to maintain the Epic episode tie to visits, look into the Oncology Episode table. But as far as the OMOP definition of a visit, it is what it is, and to fit into the Common Data Model scheme you have to follow the OMOP rules. Otherwise the tables may be common, but what they represent will not be the same across different ETL’ed database.

#6

Look into the visit_detail table: “The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim.”

This allows you to have multiple visit(_detail)_concept_ids linked to the same main visit occurrence. The same concepts from the visit domain can be used.

2 Likes
#7

Are you combing >1 encounter to create one encounter? Or what do the above statements mean? Can you give some examples?

What is meant by “one episode of care”? Some healthcare systems consider a series of 12 physical therapy visits to be one episode of care. Or the beginning of a pregnancy to outcome of the pregnancy to be one episode of care. Are these the data you have?

ER locations are pretty straightforward, unless they also have an urgent care component. And outpatient clinics almost never have the means to keep a patient overnight for an “inpatient” visit. However, it gets tricky with hospital encounters because a hospital almost always provides inpatient services, ER services and many outpatient services.

Regarding this:

I don’t think you have “encounters”. I think you have episodes, which is the parent of an encounter/s

This is two visits. One is the outpatient encounter and one is the telephone encounter happening separate from the OP encounter.

Some people have >1 ambulatory care visit in one day. Clinic visit, lab visit, imaging visit, etc. It can be hard to distinguish what happens together (ortho visit and x-ray) and what happens separately (ortho visit and labs for diabetes). It’s easiest to keep these as separate records in the Visit Occurrence table.

Again, separate visits.

How do you know it is an inpatient encounter and not an outpatient office or ambulatory care visit?

Outpatient encounters can be office visits.

If you help me tease out your data, I most likely can help you identify the episodes/visits/visit details within the data.

#8

In short, yes.

I architected an extensive pre-processing pipeline which combines visits from nine different EHR systems and assigns them a synthetic patient and encounter identifier. The patient identifier is used in OMOP directly, while the encounter identifier is mapped to a visit occurrence id and that is used instead (but the mapping is 1:1). One of the discoveries I made while creating it is that there is a one to many mapping between encounters from our Epic instance and encounters from our legacy Allscripts SCM instance. I also discovered this property exists between encounters from our Epic instance and a separate Allscripts instance for our regional partners. This also affected how billing data was tracked up until very recently, as billing data was stored both in Epic and the local Eagle EHR system. There is also a regional Eagle EHR system that joins into our data the same way. The synthetic patient and encounter identifier I generate combines these disparate encounters into one, and this bundles Telephone, Telehealth, and Telemedicine encounters with the one that generated it. So I guess what I end up with is an identifier that covers the entire episode.

As far as patients having multiple ambulatory care visits in one day, I do not see that occurring after a quick glance at my data. However, I am very certain that Epic will flag them separately and they will come in already separated.

It’s partially a definition built from encounter types and billing account numbers. The encounter types that I use upstream of OMOP are Outpatient, Inpatient, Emergency, Emergency to Inpatient, and Ambulatory Care Visits. I use the billing information to determine when a non-Outpatient/ACV encounter begins and ends, and what system I source that information from and how those rules are applied differs depending on when the visit occurred, since I have three potential systems to reference from.

The only way I know what an encounter type is is by referencing what I can in our front-end. But our front end is just Epic Hyperspace, and there is a lot of legacy data that left stubs in Epic and the rest of the information that I link to this stub is elsewhere. But I have also observed that systems can disagree over the encounter type of a visit (aka one can say Inpatient and another says Outpatient and a third says Emergency), which is why the definition I mentioned above references the department location tied to a visit as a part of the criteria.

A lot of it is site-specific, but I hope some of this information was useful.

#9

If you can change this, you should. OMOP expects a visit to be a single patient-provider interaction. You can find some general guidance on visit types here. But the gist, each Telehealth call, clinic visit, inpatient admittance, etc. are separate visits. “Follow up” interactions with a provider are separate visits. Each physical therapy appointment in a series is a separate visit. You can’t put these combined visits into the Visit Occurrence table.

One thing to note, is an outpatient, ambulatory, clinic visit is ALWAYS a one day visit.The person begins and ends the visit interaction on the same day. If your source says differently, you need to investigate the data further.

1 Like
#10

Thanks for this! I will definitely explore the data further.

#11

What did you end up doing with those office/ambulatory encounters that occurred while a patient was in the ICU? Were they included as separate visits or were they moved to the visit detail table? What concept_ids were they assigned? I see this a lot in our data with appointments/office visit encounters that occur during an inpatient stay, and I don’t want to lose the information about provider/department/timing of those encounters, but classifying them as inpatient because the patient was inpatient at the time clearly isn’t right either.

#12

Hello @nflower5,

The OP visits during an IP stay are loaded into the Visit Detail table. The standard concept_ids for the visit domain are fairly high level and generic. So, we give most Visit Detail records visit_detail_concept_id = 0. We have only assigned visit_detail_concept_ids for our intensive care unit visit details and that was for a specific use case.

Per the conventions for the Visit Detail table, " In EHR data, for example, a Person may be in the hospital but instead of one over-arching Visit their encounters are recorded as times they interacted with a health care provider. A Person in the hospital interacts with multiple providers multiple times a day so the encounters must be strung together using some heuristic (defined by the ETL) to identify the entire Visit. In this case the encounters would be considered Visit Details and the entire Visit would be the Visit Occurrence. In this example it is also possible to use the Vocabulary to distinguish Visit Details from a Visit Occurrence by setting the VISIT_CONCEPT_ID to 9201 and the VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate where the patient was in the hospital at the time of care."

OMOP is a person centric data model. If the person was in the bed at the hospital with the staff going to them to give care, then the visit is an inpatient. Outpatient visits are when the person goes to the healthcare provider to receive care and then goes home after.

The Healthcare Systems Interest Group discussed this topic on May 8, 2023. You can find a link to all our recordings on our MS Teams page. Note - you must be logged in to the OHDSI tenant of MS Teams in order to view the recording.

t