Usage and implementation of visit_occurrence and visit_details

[jackson_black]

I am reaching out to seek clarity on a topic that I find somewhat confusing, and I believe your expertise could greatly help me understand it better.

I’m currently working on a healthcare utilization segment for the OMOP CDM database, and have been exploring the OHDSI data model and noticed that there are separate tables for “Visit Occurrence” and “Visit Details.” From my current understanding, both tables capture information related to patient visits, but they serve slightly different purposes. Given their similarities, I find myself questioning the necessity of having both tables as distinct entities. While I do understand that visit_details is more granular than visit_occurrences , I wonder if including the movements of the patients into visit_occurrences is still in the realms of standard practice.

My current understanding of the two tables is that:

1. visit_occurrences table would refer to their ‘first visit’ (i.e their first visit to the doctor, or A&E) ,
2. and more granular details , such as their movements to the OT, ward, etc will be captured in the visit_details,

which means that there is only 1 parent in the visit occurrences and >= 0 children in the
visit_details, which would be linking the “first” visit and the follow-up movements.

Questions :

1. Could someone kindly explain the fundamental differences between these two tables, aside from the granularity? Specifically, I’m interested in understanding how they complement each other and whether there are scenarios where one table might be preferred over the other.

2. Additionally, what could be the practical implications of consolidating visit-related data. Would it be feasible or advisable to merge all visit details into the “Visit Occurrence” table and forego the use of the “Visit Details” table ? Or are there compelling reasons to maintain these as separate entities within the database structure?

3. Also, if I were to utilize both tables, I assume visit details would be more than enough to get details of a patient’s movement across healthcare services. Meaning all of these details would be in the visit_details
   Example of a patient’s progress.
   Admission to the emergency department ->Transfer to the intensive care unit (ICU). ->Move to a general ward for continued recovery. ->Discharge from the hospital.)
   In this scenerio:
   Admission to the emergency department would be in the details_occurrence table
   while the Transfer, General Ward, and Discharge would be in the visit_details table, is that fair?

I understand that this might be a nuanced topic, and there could be specific design considerations behind this choice. I appreciate any insights you could provide on this matter, including any examples or best practices you might share.

Thank you for taking the time and for any guidance you can offer.

[Christian_Reich]

@jackson_black:

All good questions. The current distinction between VISIT_OCCURRENCE and VISIT_DETAIL is a compromise. It still needs to be tested against real use cases. The compromise tries to support different use cases without making one use case easier at the expense of the other:

• Using visit information as a way to measure severity (intensive care visits make the condition worse than mere hospital or hospice stays worse than outpatient visits)
• Studying visit as an intervention for disease (is blood pressure adjustment more effective in an inpatient versus an outpatient setting)
• Measuring healthcare and societal cost and burden of disease

But also

• Understanding the treatment pathway of patients (outpatient doctor visit → A&E → ICU → general ward → outpatient)

The latter requires all sorts of detail about what happens while the patient is inside an institution and gets moved around, which means it is hierarchical information (ICU and general ward is part of an inpatient stay). The former just needs a single flag, and usually it is sufficient to roll it up to the top of the hierarchy. During Covid, we had a little bit of ICU usage.

So: You got it all right, except the VISIT_OCCURRENCE is not the first, but the overarching visit information. VISIT_DETAIL, as a single hierarchical step down, gives you the actual patient career inside that Visit Occurrence.

Will that work for your use cases?

[jackson_black]

@Christian_Reich Thank you for your insights on differentiating between VISIT_OCCURRENCE and VISIT_DETAIL within the OMOP CDM. Based on your explanation, I’ve devised a plan for adhering to the OMOP practices. I plan to use cases, visits, and movements table and transform them into VISIT_OCCURRENCE and VISIT_DETAIL. I’d appreciate your feedback on this strategy to ensure it aligns with OMOP’s principles and effectively supports our analytical goals.

My idea is to map all cases into the VISIT_OCCURRENCE table. Each case represents a distinct healthcare encounter, encapsulating significant interactions such as hospital admissions, outpatient visits, etc. This approach aims to capture the overarching context of each patient’s healthcare experience at a high level. My ‘case no.’ which is unique to my cases table will become the visit_occurrence id. (Mapped through using case id)

For the granular details, including visits and movements within these overarching encounters, I plan to utilize the VISIT_DETAIL table. By doing this, we can record the patient’s journey through various healthcare services, including department transfers, specific treatments, and other relevant activities within each case.

To analyze these data, we would query the VISIT_DETAIL table by patient ID, sorting the results by visit_occurrence_id (linked to VISIT_OCCURRENCE table , which is also my case id.) and date. This method should reveal a comprehensive and chronological timeline of healthcare services utilized by the patient, offering deep insights into their healthcare journey, service utilization patterns, and the sequencing of care activities.

For example:

The colors might not be in order in the visit_details table, if we are going by date, as different cases can be ongoing at once.

Does this approach effectively leverage the OMOP CDM structure for capturing and analyzing detailed healthcare interactions? Are there any considerations or adjustments you would recommend to optimize this strategy for accuracy and comprehensiveness?

Another Question: this would affect the preceding_visit_occurence column, as if we were to use the previous ‘visit_occurrence_id’ based on the previous date, then we get may a visit_occurrence_id that is totally different but is ongoing at the same time (a patient can have multiple cases at the same time)

Thank you for your time and any further guidance you can provide.

[Christian_Reich]

Sounds like you are spot on.

[MPhilofsky (Melanie Philofsky)]

@jackson_black

Here is a link to a discussion we had in the Health Systems group on how to use the Visit Occurrence and Visit Detail tables. Here’s a link to the slides.

*Edited to update link

[jackson_black]

@MPhilofsky
Hi Melanie, thank you for your reply.

We have come up with something like this :
This example shows the occurrences table for a patient with 2 separate cases, highlighted by yellow and blue. The yellow row which indicates Visit Occurrence ID 2, represents an outpatient visit. On the other hand, the yellow row with Visit Occurrence ID 3 denotes an inpatient visit. The inpatient visit is further connected to the Visit Details section, which details the movements associated with that specific inpatient visit, Occurrence ID 3. This design seems to allow for clear tracking and differentiation between outpatient and inpatient visits, as well as providing detailed information for the inpatient stays.

What do you think?

p.s I noticed that the discussion link you’ve posted is the same as the slides.

[MPhilofsky (Melanie Philofsky)]

Yes, that is the correct implementation of the Visit Occurrence and Visit Detail tables.

I updated the link in my post above, thanks