Documentation
Common Data Model (CDM)
Convert Database to CDM (ETL)
Tool Specific Documentation
Sidebar
documentation:next_cdm:visits_microvisits
This is an old revision of the document!
Representing granular encounters - new table encounter_occurrence table
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:
- The intent of this proposal is to capture granular information in OMOP Common Data Model about encounters as is from the source data.
- Visit_occurrence table is a derived/calculated/inferred table - equivalent to “_ERA” tables. Visit_occurrence table does not meet use-cases that need the granular occurrence level information (sometime with lineage to source data).
- Encounter_occurrence is proposed to overcome that with the intent of representing data as is. This information may then be used to derive thru computation existing visit_occurrence in a manner similar to _ERA concepts. (Visit_occurrence thus becomes equivalent to Drug_ERA or Dose_ERA.)
- Since encounter records are used to build a visit - multiple encounters must be related to each other. The relationship may be chaining/sequential or parent-child/part-of.
- Example: an entire inpatient stay in one hospital may be one 'high level ' visit, with several encounters at ER, ICU, medical floor, rehabilitation floor etc. Each encounter may have different start/end date-times. Example of sequential encounters ER leading to ICU leading to medical floor, leading to rehabilitation. Example of parent-child encounter: an encounter for dialysis while in ICU.
Proposed Encounter_occurrence table: Structure is similar to Visit_occurrence table
| Field | Required | Type | Description |
|---|---|---|---|
| encounter_occurrence_id | Yes | integer | A unique identifier for each Person's encounter at a healthcare provider. |
| person_id | Yes | integer | A foreign key identifier to the Person for whom the encounter is recorded. The demographic details of that Person are stored in the PERSON table. |
| encounter_concept_id | Yes | integer | A foreign key that refers to a encounter Concept identifier in the Standardized Vocabularies. |
| encounter_start_datetime | Yes | datetime | The date and time of the encounter started. |
| encounter_end_datetime | No | datetime | The date and time of the encounter end. |
| encounter_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the encounter record is derived. |
| provider_id | No | integer | A foreign key to the provider in the provider table who was associated with the encounter. |
| care_site_id | No | integer | A foreign key to the care site in the care site table where encounter occurred |
| location_id | No | integer | A foreign key to the location record in the location table where encounter occurred |
| place_of_service_concpet_id | No | integer | The standard concept id for place_of_service where encounter occurred |
| admitting_source_concept_id | No | integer | A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a encounter. |
| discharge_to_concept_id | No | integer | A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition (destination) for a encounter. |
| encounter_source_value | No | string | The source code for the encounter as it appears in the source data. |
| admitting_source_value | No | string | The source code for the admitting source as it appears in the source data. |
| discharge_to_source_value | No | string | The source code for the discharge disposition as it appears in the source data. |
| preceding_encounter_occurrence_id | No | integer | A foreign key to the encounter_OCCURRENCE table record of the encounter immediately preceding this encounter. |
| parent_encounter_occurrence_id | No | integer | |
| visit_occurrence_id | Yes | integer | A foreign key that refers to the record in the visit_occurrence that was derived from encounter_occurrence_id |
Relationship between encounter_occurrence and clinical events tables like condition_occurrence, procedure_occurrence, specimen etc.
Add encounter_occurrence_id (Fk) to each of 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_encounter_id = encounter_id then it is header/summary data. If parent_encounter_id not equal to encounter_id then it is a detail. We create new encounter_type_concept_id for the following
- Facility claim (Summary)
- Facility claim (Detail)
- Professional claim (Summary)
- Professional claim (Detail)
- Professional claim (Any)
- Facility claim (Any)
Relationship between encounter_occurrence and visit_occurrence
Linking visit_occurrence table to encounter_occurrence with allow for provenance/lineage. Add visit_ocurrence_id to encounter_occurrence table.
| visit_occurrence_id | Yes | integer | A foreign key that refers to the record in the visit_occurrence that was derived from encounter_occurrence_id |
documentation/next_cdm/visits_microvisits.1491337123.txt.gz · Last modified: 2017/04/04 20:18 by gowtham_rao
