mz-health/OMOP
mz-health
/
OMOP
mirror of https://github.com/OHDSI/CommonDataModel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #183 from keithm-thompson/master 

Fix VISIT_DETAIL documentation to reflect correct 'required' and 'type' values for multiple columns
This commit is contained in:
clairblacketer 2018-06-13 10:23:22 -04:00 committed by GitHub
parent 2a2e9b0b2c 6ea92f1112
commit 8c6859fa34
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/VISIT_DETAIL.md
View File

@ -1,4 +1,4 @@
The VISIT_DETAIL table is an optional table used to represents details of each record in the parent visit_occurrence table. For every record in visit_occurrence table there may be 0 or more records in the visit_detail table with a 1:n relationship where n may be 0. The visit_detail table is structurally very similar to visit_occurrence table and belongs to the similar domain as the visit.
The VISIT_DETAIL table is an optional table used to represents details of each record in the parent visit_occurrence table. For every record in visit_occurrence table there may be 0 or more records in the visit_detail table with a 1:n relationship where n may be 0. The visit_detail table is structurally very similar to visit_occurrence table and belongs to the similar domain as the visit.
Field|Required|Type|Description
@ -15,15 +15,15 @@ Field|Required|Type|Description
|care_site_id |No|integer|A foreign key to the care site in the care site table that was visited.|
|visit_source_value |No|string(50)|The source code for the visit as it appears in the source data.|
|visit_source_concept_id |No|Integer|A foreign key to a Concept that refers to the code used in the source.|
|admitting_source_value | No|Varchar(50)| The source code for the admitting source as it appears in the source data.|
|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_source_value | No| Varchar(50)| The source code for the discharge disposition as it appears in the source data.|
|discharge_to_concept_id |No | Integer |A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
|preceding_visit_detail_id | No |Integer|A foreign key to the VISIT_DETAIL table of the visit immediately preceding this visit|
|visit_detail_parent_id |No |Integer| A foreign key to the VISIT_DETAIL table record to represent the immediate parent visit-detail record.|
|visit_occurrence_id |Yes |Integer| A foreign key that refers to the record in the VISIT_OCCURRENCE table. This is a required field, because for every visit_detail is a child of visit_occurrence and cannot exist without a corresponding parent record in visit_occurrence.|
|admitting_source_value |No|Varchar(50)| The source code for the admitting source as it appears in the source data.|
|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_source_value |No|Varchar(50)| The source code for the discharge disposition as it appears in the source data.|
|discharge_to_concept_id |No|Integer|A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
|preceding_visit_detail_id |No|Integer|A foreign key to the VISIT_DETAIL table of the visit immediately preceding this visit|
|visit_detail_parent_id |No|Integer|A foreign key to the VISIT_DETAIL table record to represent the immediate parent visit-detail record.|
|visit_occurrence_id |Yes|Integer|A foreign key that refers to the record in the VISIT_OCCURRENCE table. This is a required field, because for every visit_detail is a child of visit_occurrence and cannot exist without a corresponding parent record in visit_occurrence.|
### Conventions
### Conventions
* All conventions used in VISIT_OCCURRENCE apply to VISIT_DETAIL, some notable exceptions:
* A Visit Detail is an optional detail record for each Visit Occurrence to a healthcare facility. For every record in VISIT_DETAIL there has to be a parent VISIT_OCCURRENCE record.
@ -31,16 +31,16 @@ Field|Required|Type|Description
* A single VISIT_OCCURRENCE record may have many child VISIT_DETAIL records.
* Valid Visit Concepts belong to the "Visit" domain. Standard Visit Concepts are yet to be defined, but will represent a detail of the Standard Visit Concept in VISIT_OCCURRENCE.
* Handling of death: In the case when a patient died during admission (VISIT_OCCURRENCE.DISCHARGE_DISPOSITION_CONCEPT_ID = 4216643 'Patient died'), a record in the Death table should be created with DEATH_TYPE_CONCEPT_ID = 44818516 (EHR discharge status "Expired").
* Source Concepts from place of service vocabularies are mapped into these Standard Visit Concepts in the Standardized Vocabularies.
* Source Concepts from place of service vocabularies are mapped into these Standard Visit Concepts in the Standardized Vocabularies.
* At any one day, there could be more than one visit. VISIT_OCCURRENCE allows for more than one visit within a single day. VISIT_DETAIL is to be used to only capture details within the visit.
* One visit may involve multiple providers, in which case, in VISIT_OCCURRENCE, the ETL must specify how a single provider id is selected or leave the provider_id field null. VISIT_DETAIL allows for ETL to speicify multiple child records per visit occurrence - and each of these child records may represent different provider_ids.
* One visit may involve multiple Care Sites, in which case, in VISIT_OCCURRENCE, the ETL must specify how a single care_site id is selected or leave the care_site_id field null. VISIT_DETAIL allows for ETL to speicify multiple child records per visit occurrence - and each of these child records may represent different care_sites.
* Just like in VISIT_OCCURRENCE, records in VISIT_DETAIL may be sequentially related to each. These sequential relations are represented using preceding_visit_detail_id
* Unlike VISIT_OCCURRENCE, VISIT_DETAIL may have nested visits with hierarchial relationships to each other.
* Unlike VISIT_OCCURRENCE, VISIT_DETAIL may have nested visits with hierarchial relationships to each other.
* Representation of US claim data: US claims data generally has two-levels. Header/summary data that summarizes the entire claim; Line/detail that details a claim. Detail is thus a child of the summary, and for every record in summary there is one or more records in detail. i.e. there will be atleast one FK link from VISIT_DETAIL to VISIT_OCCURRENCE.
Example: an entire inpatient stay maybe one record in the VISIT_OCCURRENCE table. This may have one or more detail records such as ER, ICU, medical floor, rehabilitation floor etc. Each of these visit details may have different start/end date-times, different concept_ids and fact_ids. These would become separate records in VISIT_DETAIL with a FK link to VISIT_OCCURRENCE.
Example: an entire inpatient stay maybe one record in the VISIT_OCCURRENCE table. This may have one or more detail records such as ER, ICU, medical floor, rehabilitation floor etc. Each of these visit details may have different start/end date-times, different concept_ids and fact_ids. These would become separate records in VISIT_DETAIL with a FK link to VISIT_OCCURRENCE.
Each record within VISIT_DETAIL may be 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.
Note the CONCEPT_ID for visits is 8, and is shared between VISIT_OCCURRENCE and VISIT_DETAIL in OMOP CDM. The key deviation from VISIT_OCCURRENCE is