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 or microvisits
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/microsivists/visits as is from the source data.
- Current VISIT_OCCURRENCE table is a derived/calculated/inferred table - equivalent to “_ERA” tables. Current VISIT_OCCURRENCE table does not meet use-cases that need the granular occurrence level information (sometime with lineage to source data).
- We propose VISIT_OCCURRENCE and a new VISIT_OCCURRENCE_ERA tables, where VISIT_OCCURRENCE will be repurposed to represent data as is, while a new table that is a replica of VISIT_OCCURRENCE table will become VISIT_OCCURRENCE_ERA and will be equivalent to current VISIT_OCCURRENCE table. (Current VISIT_OCCURRENCE table becomes VISIT_OCCURRENCE_ERA and is equivalent to DRUG_ERA or DOSE_ERA.) VISIT_OCCURRENCE is used to derive thru computation VISIT_OCCURRENCE_ERA table in a manner similar to the derived _ERA tables.
- Since we are proposing the VISIT_OCCURRENCE and VISIT_OCCURRENCE_ERA to have similar table structure, we will retain backward compatibility.
- Multiple visits must be related to each other. We can represent that in VISIT_OCCURRENCE and VISIT_OCCURRENCE_ERA using chaining/sequential method or parent-child/part-of.
- Example: an entire inpatient stay in one hospital may be one 'higher level' visit, with several smaller visits at ER, ICU, medical floor, rehabilitation floor etc. Each visit may have different start/end date-times. Example of sequential visits –> ER leading to ICU leading to medical floor, leading to rehabilitation. Example of parent-child visit: a visit for dialysis while in ICU.
Proposed VISIT_OCCURRENCE table: Will have the same structure as current VISIT_OCCURRENCE table. We will add place_of_service_concept_id, parent_visit_occurrence_id and visit_occurrence_era_id
| Field | Required | Type | Description |
|---|---|---|---|
| visit_occurrence_id | Yes | integer | A unique identifier for each Person's visit at a healthcare provider. |
| person_id | Yes | integer | A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table. |
| visit_concept_id | Yes | integer | A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies. |
| visit_start_datetime | Yes | datetime | The date and time of the visit started. |
| visit_end_datetime | No | datetime | The date and time of the visit end. |
| visit_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 visit record is derived. |
| provider_id | No | integer | A foreign key to the provider in the provider table who was associated with the visit. |
| care_site_id | No | integer | A foreign key to the care site in the care site table where visit occurred |
| location_id | No | integer | A foreign key to the location record in the location table where visit occurred |
| place_of_service_concept_id | No | integer | The standard concept id for place_of_service where visit 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 visit. |
| 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 visit. |
| visit_source_value | No | string | The source code for the visit 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_visit_occurrence_id | No | integer | A foreign key to the visit_occurrence table record of the visit immediately preceding this visit. |
| parent_visit_occurrence_id | No | integer | |
| primary_visit_occurrence_era_id | Yes | integer | A foreign key that refers to the record in the visit_occurrence_era that was primary derived _era record from visit_occurrence_id |
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.
| Field | Required | Type | Description |
|---|---|---|---|
| visit_occurrence_era_id | Yes | integer | A unique identifier for each Person's visit at a healthcare provider. |
| person_id | Yes | integer | A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table. |
| visit_concept_id | Yes | integer | A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies. |
| visit_start_datetime | Yes | datetime | The date and time of the visit started. |
| visit_end_datetime | No | datetime | The date and time of the visit end. |
| visit_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 visit record is derived. |
| provider_id | No | integer | A foreign key to the provider in the provider table who was associated with the visit. |
| care_site_id | No | integer | A foreign key to the care site in the care site table where visit occurred |
| location_id | No | integer | A foreign key to the location record in the location table where visit occurred |
| place_of_service_concept_id | No | integer | The standard concept id for place_of_service where visit 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 visit. |
| 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 visit. |
| visit_source_value | No | string | The source code for the visit 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_visit_occurrence_id | No | integer | A foreign key to the visit_occurrence table record of the visit immediately preceding this visit. |
Relationship between VISIT_OCCURRENCE and VISIT_OCCURRENCE_ERA
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.
| primary_VISIT_OCCURRENCE_ERA_id | Yes | integer | A foreign key that refers to the record in the VISIT_OCCURRENCE_ERA that was primary derived _ERA record from VISIT_OCCURRENCE_id |
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.
documentation/next_cdm/visits_microvisits.1493492698.txt.gz · Last modified: 2017/04/29 19:04 by cgreich
