Proposal Owner: Gowtham Rao

Use cases: http://forums.ohdsi.org/t/new-table-for-encounters-encounters-care-transitions/2297 http://forums.ohdsi.org/t/how-to-represent-encounter-payer-information-in-the-model/369 http://forums.ohdsi.org/t/capturing-more-than-one-care-site-id-or-provider-id-per-encounter-occurrence/1901 Also addresses using new Definition table the concern of atomicity and lineage of data to source http://forums.ohdsi.org/t/purpose-of-the-omop-cdm-analytics-ready-or-close-to-source/2358

See discussions: http://forums.ohdsi.org/t/definition-of-encounter-transfers-and-referrals-and-distinction-of-er-from-hospital-encounters/1311/4?u=gowtham_rao http://forums.ohdsi.org/t/new-table-for-encounters-encounters-care-transitions/2297

Proposal intent and problem statement:

• Current VISIT_OCCURRENCE table does not meet use-cases that need the granular information, such as movement of person while in a hospital.
• The intent of this proposal is to capture detail information about a record in visit_occurrence. Examples of detail information may be encounters, micro-visits etc., and will be collected as is from the source data.
• We propose a new VISIT_DETAIL table with a structure that is similar to current VISIT_OCCURRENCE table. For every record in visit_occurrence there maybe 0 or more records in visit_detail.
• Records in visit_detail will be related to each other sequentially or hierarchially, AND will be related to visit_occurrence table (using chaining/sequential method or parent-child/part-of).
• All information will belong to the domain visit.
• Example: an entire inpatient stay maybe on record in visit_occurrence table. This may have one or more detail information such as ER, ICU, medical floor, rehabilitation floor etc. Each of these visit_details may have different start/end date-times, different concept_id's and fact_id's - that would be separate record in visit_detail with a FK link to visit_occurrence. Each record within visit_detail maybe related to each other, sequentially –> ER leading to ICU leading to medical floor, leading to rehabilitation, or in hierarchical parent-child visit –> a visit for dialysis while in ICU.

Proposed VISIT_DETAIL table: Will have the same structure as current VISIT_OCCURRENCE table, except for two new fields (FK to visit_occurrence and a parent_visit_detail_id), and removal of just _date fields

Relationship between VISIT_OCCURRENCE and clinical events tables like CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, SPECIMEN etc.

Use existing visit_occurrence_id (Fk) in these (event)_OCCURRENCE tables.

Representation of US claim data

US claims data generally has header/summary data and line/detail level data. Detail is a child of the summary. If parent_visit_occurrence_id = visit_occurrence_id then it is header/summary data. If parent_visit_occurrence_id is not equal to visit_occurrence_id then it is a detail. We create new visit_type_concept_id for the following - Facility claim (Summary) - Facility claim (Detail) - Professional claim (Summary) - Professional claim (Detail) - Professional claim (Any) - Facility claim (Any)

Proposed new VISIT_OCCURRENCE_ERA table: Will have the same structure as current VISIT_OCCURRENCE table.

Linking VISIT_OCCURRENCE table to VISIT_OCCURRENCE_ERA will allow for provenance/lineage.

There may be n:m relationship between VISIT_OCCURRENCE and VISIT_OCCURRENCE_ERA, however one of them may be primary. This may be represented using primary_visit_ocurrence_era_id on VISIT_OCCURRENCE table.

All other non-primary relationship may be represented using FACT_RELATIONSHIP tables.

Relationship between visit_occurrence and clinical events tables like CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, SPECIMEN etc.

By joining through VISIT_OCCURRENCE table

• Join VISIT_OCCURRENCE_ERA to VISIT_OCCURRENCE.
• Join VISIT_OCCURRENCE to (event)_occurrence tables.