documentation:next_cdm:visits_microvisits
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
documentation:next_cdm:visits_microvisits [2017/05/07 16:43] gowtham_rao |
documentation:next_cdm:visits_microvisits [2017/07/06 16:30] (current) clairblacketer |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Proposal for Visit_detail: Represent granular encounters or microvisits ====== | ====== Proposal for Visit_detail: Represent granular encounters or microvisits ====== | ||
| + | ** Proposals are now housed as github issues ** [[https://github.com/OHDSI/CommonDataModel/issues/70|link to github issue]] | ||
| Line 19: | Line 20: | ||
| * 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. | ||
| Line 31: | Line 32: | ||
| | visit_detail_id| Yes| integer| A unique identifier for each Person's visit-detail at a healthcare provider.| | | visit_detail_id| Yes| integer| A unique identifier for each Person's visit-detail 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.| | | 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_detail_concept_id| Yes | integer | A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies. | |
| | <del>visit_start_date</del>| <del>Yes</del> | <del>date </del> | <del>The start date of the visit.</del>| | | <del>visit_start_date</del>| <del>Yes</del> | <del>date </del> | <del>The start date of the visit.</del>| | ||
| | visit_start_datetime | Yes | datetime | The date and time of the visit-detail started.| | | visit_start_datetime | Yes | datetime | The date and time of the visit-detail started.| | ||
documentation/next_cdm/visits_microvisits.1494175435.txt.gz · Last modified: 2017/05/07 16:43 by gowtham_rao
Page Tools
