cdm v5.3.1 updates

Documentation/CommonDataModel_Wiki_Files/Home.md

@@ -1,7 +1,7 @@
-***OMOP Common Data Model v5.2 Specifications***
+***OMOP Common Data Model v5.3 Specifications***
 
 <br>*Authors: Christian Reich, Patrick Ryan, Rimma Belenkaya, Karthik Natarajan, Clair Blacketer*
-<br>*12 July 2017*
+<br>*3 January 2018*
 
 Welcome to the Common Data Model wiki! This wiki houses all of the documentation for the latest version as well as changes added with each release. You can find a pdf added to each [release](https://github.com/OHDSI/CommonDataModel/releases) with a historical version of the wiki as it was at the time of the release. You can navigate the pages using the table of contents below or the links to the right.
 
@@ -13,6 +13,7 @@ Welcome to the Common Data Model wiki! This wiki houses all of the documentation
 <br>  [The Role of the Common Data Model](wiki/The-Role-of-the-Common-Data-Model)
 <br>  [Design Principles](wiki/Design-Principles)
 <br>  [Data Model Conventions](wiki/Data-Model-Conventions)
+<br>  [Frequently Asked Questions](wiki/Frequently-Asked-Questions)
 <br>
 <br>**[Glossary of Terms](wiki/Glossary-of-Terms)**
 <br>
@@ -32,13 +33,15 @@ Welcome to the Common Data Model wiki! This wiki houses all of the documentation
 <br>
 <br>**[Standardized Metadata](wiki/Standardized-Metadata)**
 <br>[CDM_SOURCE](wiki/CDM_SOURCE)
+<br>[METADATA](wiki/METADATA)
 <br>
 <br>**[Standardized Clinical Data Tables](Standardized-Clinical-Data-Tables)**
 <br>[PERSON](wiki/PERSON)
 <br>[OBSERVATION_PERIOD](wiki/OBSERVATION_PERIOD)
 <br>[SPECIMEN](wiki/SPECIMEN)
 <br>[DEATH](wiki/DEATH)
 <br>[VISIT_OCCURRENCE](wiki/VISIT_OCCURRENCE)
+<br>[VISIT_DETAIL](wiki/VISIT_DETAIL)
 <br>[PROCEDURE_OCCURRENCE](wiki/PROCEDURE_OCCURRENCE)
 <br>[DRUG_EXPOSURE](wiki/DRUG_EXPOSURE)
 <br>[DEVICE_EXPOSURE](wiki/DEVICE_EXPOSURE)

Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/MEASUREMENT.md

@@ -7,7 +7,7 @@ Field|Required|Type|Description
 |measurement_concept_id|Yes|integer|A foreign key to the standard measurement concept identifier in the Standardized Vocabularies.|
 |measurement_date|Yes|date|The date of the Measurement.|
 |measurement_datetime|No|datetime|The date and time of the Measurement. Some database systems don't have a datatype of time. To accomodate all temporal analyses, datatype datetime can be used (combining measurement_date and measurement_time [forum discussion](http://forums.ohdsi.org/t/date-time-and-datetime-problem-and-the-world-of-hours-and-1day/314))|
-|measurement_time |No|varchar(10)|The time of the Measurement. This is present for backwards compatibility and will deprecated in an upcoming version|
+|measurement_time |No|varchar(10)|The time of the Measurement. This is present for backwards compatibility and will be deprecated in an upcoming version|
 |measurement_type_concept_id|Yes|integer|A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the provenance from where the Measurement record was recorded.|
 |operator_concept_id|No|integer|A foreign key identifier to the predefined Concept in the Standardized Vocabularies reflecting the mathematical operator that is applied to the value_as_number. Operators are <, <=, =, >=, >.|
 |value_as_number|No|float|A Measurement result where the result is expressed as a numeric value.|

Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/VISIT_DETAIL.md

@@ -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,34 +15,34 @@ 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.
   * One record in VISIT_DETAIL can only have one VISIT_OCCURRENCE parent.
   * 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
+Note the CONCEPT_ID for visit domain is 8, and it is shared between VISIT_OCCURRENCE and VISIT_DETAIL in OMOP CDM. The key deviation from VISIT_OCCURRENCE is
 - self-referencing key: a new foreign key visit_detail_parent_id allows self referencing for nested visits.
 - VISIT_DETAIL points to its parent record in the VISIT_OCCURRENCE table (visit_occurrence_id)

Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/VISIT_OCCURRENCE.md

@@ -37,6 +37,6 @@ Field|Required|Type|Description
     * Patient died: 4216643
 	* Absent without leave: 44814693
 	* Patient self-discharge against medical advice: 4021968
-  * In the case where 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").
+  * In the case where 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").
   * PRECEDING_VISIT_ID can be used to link a visit immediately preceding the current visit
-  * Some EMR systems combine emergency room followed by inpatient admission into one visit, and it is close to impossible to separate the two. To annotate this visit type, a new visit concept "Emergency Room and Inpatient Visit" was added (CONCEPT_ID 262).
+  * Some EMR systems combine emergency room followed by inpatient admission into one visit, and it is close to impossible to separate the two. To annotate this visit type, a new visit concept "Emergency Room and Inpatient Visit" was added (CONCEPT_ID 262).