Mapping VISIT_CONCEPT_ID in VISIT_OCCURRENCE for multiple encounters in EPIC

CDM or THEMIS convention?

THEMIS

Table or Field level?

Field

Is this a general convention?

Summary of issues

How to combine encounter data from various EHR systems into a single OMOP data model?
Encounter types (Outpatient, Inpatient, etc.) are assigned based on location.
The issue is that some encounters have multiple valid VISIT_CONCEPT_IDs depending on the context (e.g., outpatient with phone call, inpatient with follow-up call).
Since a single VISIT_CONCEPT_ID can't capture all aspects, the author proposes using one row per VISIT_OCCURRENCE_ID/VISIT_CONCEPT_ID combination as the primary key.
The author seeks confirmation on their approach to conceptualising and solving this issue.

Summary of answer

Author 1 summery:

There's no direct one-to-one mapping between Epic episode and the OMOP definition.
An example: An inpatient stay with follow-up calls requires two separate OMOP visit occurrences - one for hospitalisation and another for the phone call (optional).
The author emphasises considering your OMOP CDM's purpose:
Visit type helps define patient groups for research (e.g., procedures during hospitalisation).
They disagree with the previous suggestion of one row per VISIT_OCCURRENCE_ID/VISIT_CONCEPT_ID combination. Instead, they recommend creating separate Visit Occurrence records for each distinct encounter within an episode.

Author 2 summery:

Epic encounter types don't always align with OMOP visit types (e.g., Office visit in ICU)
EHR transactional visits (no provider interaction) shouldn't be included in OMOP
Epic Clarity and Caboodle tables are a good starting point for inpatient/ER visits
Exclude encounters where patients weren't seen (e.g., ER check-in but left)
Consult Epic User Web forums and EHR experts for specific guidance (Epic encounters vary)

In summary, there are challenges due to the way Epic records encounters compared to how OMOP defines visit types. It's important to be aware of these discrepancies and to carefully select the data to be included in the OMOP CDM.

Author 3 summery The use of visit_detail table

This is an optional table. It allows you to represent finer-grained details within a visit already captured in the visit_occurrence table.
An example: You can use it to track a patient's movement between different units (ICU, ward) during a single hospitalisation stay.
The key point is that you can link multiple visit_detail_concept_ids to a single parent visit_occurrence record.
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.

Other comments/notes

Summery notes from Google Gemini:

Challenge: Electronic health records (EHR) might record in-patient stays as multiple encounters for each provider interaction.

Solution: Visit Occurrence: Represents the entire in-patient stay as a single record.

Visit Details: Capture individual provider interactions within the stay.

Vocabulary Usage:

Visit Occurrence: Use concept ID 9201 (Inpatient Visit).
Visit Details: Use concept ID 9201 (Inpatient Visit) or its children (more specific locations within the hospital) to indicate where the care happened.

Key Point:

OMOP focuses on patient-centric data.
Inpatient visits are defined by the patient being admitted to the hospital, regardless of encounter type (provider visits them).
Outpatient visits involve the patient going to and leaving the healthcare facility.
Additional Resources: Mentions a discussion on this topic by the Healthcare Systems Interest Group (HSIG) on May 8th, 2023.

OHDSI / Themis