This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
documentation:next_cdm:visits_microvisits [2017/05/07 16:43] gowtham_rao |
documentation:next_cdm:visits_microvisits [2017/06/06 17:05] gowtham_rao |
||
---|---|---|---|
Line 19: | Line 19: | ||
* 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. | * 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. | * 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). | + | * Records in visit_detail will be related to each other sequentially or hierarchically, 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. | * 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. | + | * Example: an entire inpatient stay maybe one 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 ====== | |
- | **Proposed VISIT_DETAIL table:** Will have the same structure as current VISIT_OCCURRENCE table, except for two changes: | + | This table will have the same structure as current VISIT_OCCURRENCE table, except for two changes: |
* Two new foreign keys pointing to itself (visit_detail_parent_id) and to visit_occurrence table (visit_occurrence_id) | * Two new foreign keys pointing to itself (visit_detail_parent_id) and to visit_occurrence table (visit_occurrence_id) | ||
* Removal of _date fields. | * Removal of _date fields. |