Differences

This shows you the differences between two versions of the page.

--- documentation:next_cdm:visits_microvisits [2017/05/07 16:44] – 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 ======
+** 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.
   * 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.
-  * 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 ======
@@ Line 31: / Line 32: @@
 | 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.|
-| 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>|
 | visit_start_datetime | Yes | datetime | The date and time of the visit-detail started.|