Updated CDM v5.3 wiki files

StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md

@@ -15,11 +15,12 @@ Field|Required|Type|Description
 | condition_type_concept_id      | Yes       | integer      | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the condition was recorded, the level of standardization, and the type of occurrence.  |
 | stop_reason                    | No        | varchar(20)  | The reason that the condition was no longer present, as indicated in the source data.                                                                                                                            |
 | provider_id                    | No        | integer      | A foreign key to the Provider in the PROVIDER table who was responsible for capturing (diagnosing) the Condition.                                                                                                |
-| visit_occurrence_id            | No        | integer      | A foreign key to the visit in the VISIT table during which the Condition was determined (diagnosed).                                                                                                             |
+| visit_occurrence_id            | No        | integer      | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Condition was determined (diagnosed).                                                                                                  |
+| visit_detail_id                | No        | integer      | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed).                                                                                                           | visit_detail_id            | No        | integer      | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed).                                                                                                             |
 | condition_source_value         | No        | varchar(50)  | The source code for the condition as it appears in the source data. This code is mapped to a standard condition concept in the Standardized Vocabularies and the original code is stored here for reference.     |
 | condition_source_concept_id    | No        | integer      | A foreign key to a Condition Concept that refers to the code used in the source.                                                                                                                                 |
 | condition_status_source_value  | No        | varchar(50)  | The source code for the condition status as it appears in the source data.    |
-| condition_status_concept_id    | No        | integer      | A foreign key to the predefined concept in the standard vocabulary reflecting the condition status |                                                                                                                               |
+| condition_status_concept_id    | No        | integer      | A foreign key to the predefined Concept in the Standard Vocabulary reflecting the condition status |                                                                                                                               |
 
 ### Conventions 
 
@@ -36,5 +37,5 @@ Field|Required|Type|Description
   * Condition source codes are typically ICD-9-CM, Read or ICD-10 diagnosis codes from medical claims or discharge status/visit diagnosis codes from EHRs.
   * Presently, there is no designated vocabulary, domain, or class that represents condition status. The following concepts from SNOMED are recommended:
     * Admitting diagnosis: 4203942
-    * Final diagnosis: 4230359 <EFBFBD> should also be used for <20>Discharge diagnosis<69>
+    * Final diagnosis: 4230359 (should also be used for discharge diagnosis)
     * Preliminary diagnosis: 4033240

StandardizedClinicalDataTables/DEVICE_EXPOSURE.md

@@ -13,7 +13,8 @@ Field|Required|Type|Description
 |unique_device_id |No|varchar(50)|A UDI or equivalent identifying the instance of the Device used in the Person.|
 |quantity|No|integer|The number of individual Devices used for the exposure.|
 |provider_id|No|integer|A foreign key to the provider in the PROVIDER table who initiated of administered the Device.|
-|visit_occurrence_id|No|integer|A foreign key to the visit in the VISIT table during which the device was used.|
+|visit_occurrence_id|No|integer|A foreign key to the visit in the VISIT_OCCURRENCE table during which the device was used.|
+|visit_detail_id|No|integer|A foreign key to the visit detail in the VISIT_DETAIL table during which the Drug Exposure was initiated.|
 |device_source_value|No|varchar(50)|The source code for the Device as it appears in the source data. This code is mapped to a standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.|
 |device_source_ concept_id|No|integer|A foreign key to a Device Concept that refers to the code used in the source.|
 
@@ -24,4 +25,5 @@ Field|Required|Type|Description
   * Valid Device Concepts belong to the "Device" domain.  The Concepts of this domain are derived from the DI portion of a UDI or based on other source vocabularies, like HCPCS.
   * A Device Type is assigned to each Device Exposure to track from what source the information was drawn or inferred. The valid domain_id for these Concepts is "Device Type".
   * The Visit during which the Device was first used is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
+  * The Visit Detail during which the Device was first used is recorded through a reference to the VISIT_DETAIL table. This information is not always available.
   * The Provider exposing the patient to the Device is recorded through a reference to the PROVIDER table. This information is not always available.

StandardizedClinicalDataTables/DRUG_EXPOSURE.md

@@ -22,11 +22,12 @@ Field|Required|Type|Description
 |refills|No|integer|The number of refills after the initial prescription. The initial prescription is not counted, values start with 0.|
 |quantity |No|float|The quantity of drug as recorded in the original prescription or dispensing record.|
 |days_supply|No|integer|The number of days of supply of the medication as recorded in the original prescription or dispensing record.|
-|sig|No|clob|The directions ("signetur") on the Drug prescription as recorded in the original prescription (and printed on the container) or dispensing record.|
+|sig|No|varchar(MAX)|The directions ("signetur") on the Drug prescription as recorded in the original prescription (and printed on the container) or dispensing record.|
 |route_concept_id|No|integer|A foreign key to a predefined concept in the Standardized Vocabularies reflecting the route of administration.|
 |lot_number|No|varchar(50)|An identifier assigned to a particular quantity or lot of Drug product from the manufacturer.|
-|provider_id|No|integer|A foreign key to the provider in the provider table who initiated (prescribed or administered) the Drug Exposure.|
+|provider_id|No|integer|A foreign key to the provider in the PROVIDER table who initiated (prescribed or administered) the Drug Exposure.|
-|visit_occurrence_id|No|integer|A foreign key to the visit in the visit table during which the Drug Exposure was initiated.|
+|visit_occurrence_id|No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Drug Exposure was initiated.|
+|visit_detail_id|No|integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Drug Exposure was initiated.|
 |drug_source_value|No|varchar(50)|The source code for the Drug as it appears in the source data. This code is mapped to a Standard Drug concept in the Standardized Vocabularies and the original code is, stored here for reference.|
 |drug_source_concept_id|No|integer|A foreign key to a Drug Concept that refers to the code used in the source.|
 |route_source_value|No|varchar(50)|The information about the route of administration as detailed in the source.|

StandardizedClinicalDataTables/MEASUREMENT.md

@@ -16,6 +16,7 @@ Field|Required|Type|Description
 |range_high|No|float|The upper limit of the normal range of the Measurement. The upper range is assumed to be of the same unit of measure as the Measurement value.|
 |provider_id|No|integer|A foreign key to the provider in the PROVIDER table who was responsible for initiating or obtaining the measurement.|
 |visit_occurrence_id|No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Measurement was recorded.|
+|visit_detail_id|No|integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Measurement was recorded. |
 |measurement_source_value|No|varchar(50)|The Measurement name as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.|
 |measurement_source_concept_id|No|integer|A foreign key to a Concept in the Standard Vocabularies that refers to the code used in the source.|
 |unit_source_value|No|varchar(50)|The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the Standardized Vocabularies and the original code is stored here for reference.|

StandardizedClinicalDataTables/NOTE.md

@@ -9,12 +9,13 @@ Field|Required|Type|Description
 |note_type_concept_id	|Yes|integer|A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the type, origin or provenance of the Note.|
 |note_class_concept_id	|Yes|	integer|	A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the HL7 LOINC Document Type Vocabulary classification of the note.|
 |note_title				|No|	varchar(250)|	The title of the Note as it appears in the source.|
-|note_text|Yes|RBDMS dependent text|The content of the Note.|
+|note_text				|Yes|varchar(MAX)|The content of the Note.|
 |encoding_concept_id	|Yes	|integer|	A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the note character encoding type|
 |language_concept_id	|Yes	|integer	|A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the language of the note|
 |provider_id			|No|integer|A foreign key to the Provider in the PROVIDER table who took the Note.|
-|note_source_value|No|varchar(50)|The source value associated with the origin of the note|
+|visit_occurrence_id	|No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table when the Note was taken.|
-|visit_occurrence_id|No|integer|Foreign key to the Visit in the VISIT_OCCURRENCE table when the Note was taken.|
+|visit_detail_id		|No|integer|A foreign key to the Visit in the VISIT_DETAIL table when the Note was taken.|
+|note_source_value		|No|varchar(50)|The source value associated with the origin of the Note|
 
 ### Conventions 
   * The NOTE table contains free text (in ASCII, or preferably in UTF8 format) taken by a healthcare Provider.

StandardizedClinicalDataTables/NOTE_NLP.md

@@ -2,20 +2,20 @@ The NOTE_NLP table will encode all output of NLP on clinical notes. Each row rep
 
 Field | Required | Type | Description
 :------------------------------- | :-------- | :------------ | :---------------------------------------------------
-note_nlp_id | Yes | Big Integer | A unique identifier for each term extracted from a note.
+note_nlp_id 				| Yes | integer | A unique identifier for each term extracted from a note.
 note_id 					| Yes | integer | A foreign key to the Note table note the term was extracted from.
 section_concept_id 			| No | integer | A foreign key to the predefined Concept in the Standardized Vocabularies representing the section of the extracted term.
 snippet 					| No | varchar(250) | A small window of text surrounding the term.
 offset 						| No | varchar(50) | Character offset of the extracted term in the input note.
 lexical_variant 			| Yes | varchar(250) | Raw text extracted from the NLP tool.
 note_nlp_concept_id 		| No | integer | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the normalized concept for the extracted term. Domain of the term is represented as part of the Concept table.
-note_nlp_source_concept_id | no | integer | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system
+note_nlp_source_concept_id  | No | integer | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system
 nlp_system 					| No | varchar(250) | Name and version of the NLP system that extracted the term.Useful for data provenance.
 nlp_date 					| Yes | date | The date of the note processing.Useful for data provenance.
-nlp_datetime | No | datetime | The date and time of the note processing. Useful for data provenance.
+nlp_date_time 				| No | datetime | The date and time of the note processing. Useful for data provenance.
 term_exists 				| No | varchar(1) | A summary modifier that signifies presence or absence of the term for a given patient. Useful for quick querying. *
-term_temporal | No | varchar(50) | An optional time modifier associated with the extracted term. (for now “past” or “present” only). Standardize it later.
+term_temporal 				| No | varchar(50) | An optional time modifier associated with the extracted term. (for now “past” or “present” only). Standardize it later.
-term_modifiers | No | varchar(2000) | A compact description of all the modifiers of the specific term extracted by the NLP system. (e.g. “son has rash” ? “negated=no,subject=family, certainty=undef,conditional=false,general=false”).
+term_modifiers 				| No | varchar(2000) | A compact description of all the modifiers of the specific term extracted by the NLP system. (e.g. “son has rash” ? “negated=no,subject=family, certainty=undef,conditional=false,general=false”).
 
 ### Conventions
 
@@ -39,7 +39,7 @@ For the modifiers that are there, they would have to have these values:
 * Uncertain = true or high or moderate or even low (could argue about low)
 
 **Term_temporal**
-Term_temporal is to indicate if a condition is “present” or just in the “past”.
+Term_temporal is to indicate if a condition is “present” or just in the “past”.
 
 The following would be past:
  

StandardizedClinicalDataTables/OBSERVATION.md

@@ -15,6 +15,7 @@ Field|Required|Type|Description
 |unit_concept_id|No|integer|A foreign key to a Standard Concept ID of measurement units in the Standardized Vocabularies.|
 |provider_id|No|integer|A foreign key to the provider in the PROVIDER table who was responsible for making the observation.|
 |visit_occurrence_id|No|integer|A foreign key to the visit in the VISIT_OCCURRENCE table during which the observation was recorded.|
+|visit_detail_id|No|integer|A foreign key to the visit in the VISIT_DETAIL table during which the observation was recorded.|
 |observation_source_value|No|varchar(50)|The observation code as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is, stored here for reference.|
 |observation_source_concept_id|No|integer|A foreign key to a Concept that refers to the code used in the source.|
 |unit_source_value|No|varchar(50)|The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the Standardized Vocabularies and the original code is, stored here for reference.|

StandardizedClinicalDataTables/PROCEDURE_OCCURRENCE.md

@@ -13,11 +13,12 @@ Field|Required|Type|Description
 |procedure_type_concept_id|Yes|integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the procedure record is derived.|
 |modifier_concept_id|No|integer|A foreign key to a Standard Concept identifier for a modifier to the Procedure (e.g. bilateral)|
 |quantity|No|integer|The quantity of procedures ordered or administered.|
-|provider_id|No|integer|A foreign key to the provider in the provider table who was responsible for carrying out the procedure.|
+|provider_id|No|integer|A foreign key to the provider in the PROVIDER table who was responsible for carrying out the procedure.|
-|visit_occurrence_id|No|integer|A foreign key to the visit in the visit table during which the Procedure was carried out.|
+|visit_occurrence_id|No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Procedure was carried out.|
+|visit_detail_id|No|integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Procedure was carried out.|
 |procedure_source_value|No|varchar(50)|The source code for the Procedure as it appears in the source data. This code is mapped to a standard procedure Concept in the Standardized Vocabularies and the original code is, stored here for reference. Procedure source codes are typically ICD-9-Proc, CPT-4, HCPCS or OPCS-4 codes.|
 |procedure_source_concept_id|No|integer|A foreign key to a Procedure Concept that refers to the code used in the source.|
-|qualifier_source_value|No|varchar(50)|The source code for the qualifier as it appears in the source data.|
+|modifier_source_value|No|varchar(50)|The source code for the qualifier as it appears in the source data.|
 
 ### Conventions 
 
@@ -27,4 +28,5 @@ Field|Required|Type|Description
   * If the quantity value is omitted, a single procedure is assumed.
   * The Procedure Type defines from where the Procedure Occurrence is drawn or inferred. For administrative claims records the type indicates whether a Procedure was primary or secondary and their relative positioning within a claim. 
   * The Visit during which the procedure was performed is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
+  * The Visit Detail during with the procedure was performed is recorded through a reference to the VISIT_DETAIL table. This information is not always available.
   * The Provider carrying out the procedure is recorded through a reference to the PROVIDER table. This information is not always available.

StandardizedClinicalDataTables/VISIT_DETAIL.md

@@ -0,0 +1,48 @@
+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
+:------------------------|:--------|:-----|:-------------------------------------------------
+|visit_detail_id			|Yes|integer|A unique identifier for each Person's visit or encounter 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_start_date			|Yes|date|The start date of the visit.|
+|visit_start_datetime		|No|datetime|The date and time of the visit started.|
+|visit_end_date				|Yes|date|The end date of the visit. If this is a one-day visit the end date should match the start date.|
+|visit_end_datetime			|No|datetime|The date and time of the visit end.|
+|visit_type_concept_id		|Yes|Integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived.|
+|provider_id				|No|integer|A foreign key to the provider in the provider table who was associated with the visit.|
+|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		|Varchar(50)|	No|	The source code for the admitting source as it appears in the source data.|
+|admitting_source_concept_id	|Integer	|No	|A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.|
+|discharge_to_source_value	|	Varchar(50)|	No|	The source code for the discharge disposition as it appears in the source data.|
+|discharge_to_concept_id	|	Integer	|No	|A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
+|preceding_visit_detail_id	|Integer|	No	|A foreign key to the VISIT_DETAIL table of the visit immediately preceding this visit|
+|visit_detail_parent_id		|Integer|	No	|A foreign key to the VISIT_DETAIL table record to represent the immediate parent visit-detail record.|
+|visit_occurrence_id		|Integer|	Yes	|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 
+
+  * 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. 
+  * 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. 
+  * 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. 
+ 
+ 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
+- 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)

StandardizedClinicalDataTables/VISIT_OCCURRENCE.md

@@ -12,20 +12,20 @@ Field|Required|Type|Description
 |visit_type_concept_id|Yes|Integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived.|
 |provider_id|No|integer|A foreign key to the provider in the provider table who was associated with the visit.|
 |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_value|No|varchar(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.|
+|visit_source_concept_id|No|integer|A foreign key to a Concept that refers to the code used in the source.|
-|admitting_source_concept_id|	Integer	|No	|A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.|
+|admitting_source_concept_id	|integer	|No	|A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the admitting source for a visit.|
-|admitting_source_value	|Varchar(50)|	No|	The source code for the admitting source as it appears in the source data.|
+|admitting_source_value			|varchar(50)|	No|	The source code for the admitting source as it appears in the source data.|
-|discharge_to_concept_id|	Integer	|No	|A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
+|discharge_to_concept_id		|	integer	|No	|A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit.|
-|discharge_to_source_value|	Varchar(50)|	No|	The source code for the discharge disposition as it appears in the source data.|
+|discharge_to_source_value		|	varchar(50)|	No|	The source code for the discharge disposition as it appears in the source data.|
-|preceding_visit_occurrence_id	|Integer|	No	|A foreign key to the VISIT_OCCURRENCE table of the visit immediately preceding this visit|
+|preceding_visit_occurrence_id	|integer|	No	|A foreign key to the VISIT_OCCURRENCE table of the visit immediately preceding this visit|
 
 ### Conventions 
 
   * A Visit Occurrence is recorded for each visit to a healthcare facility. 
   * Valid Visit Concepts belong to the "Visit" domain. 
   * Standard Visit Concepts are defined as Inpatient Visit, Outpatient Visit, Emergency Room Visit, Long Term Care Visit and combined ER and Inpatient Visit. The latter is necessary because it is close to impossible to separate the two in many EHR system, treating them interchangeably. To annotate this correctly, the visit concept "Emergency Room and Inpatient Visit" (concept_id=262) should be used.
-  * Handling of death: In case when patient died during admission (Visit_Occurrence.discharge_to_concept_id = 4216643 'Patient died'), a record in the Death table should be created with death_type_concept_id = 44818516 (EHR discharge status "Expired").
+  * 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. 
   * At any one day, there could be more than one visit.
   * One visit may involve multiple providers, in which case the ETL must specify how a single provider id is selected or leave the provider_id field null.
@@ -39,4 +39,4 @@ Field|Required|Type|Description
 	* Patient self-discharge against medical advice: 4021968
   * In the case where a patient died during admission (Visit_Occurrence.discharge_disposition_concept_id = 4216643 <20>Patient died<65>), a record in the Death table should be created with death_type_concept_id = 44818516 (<28>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 <EFBFBD>Emergency Room and Inpatient Visit<69> 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).

StandardizedDerivedElements/COHORT.md

@@ -11,4 +11,6 @@ Field|Required|Type|Description
   * The core of a Cohort is the unifying definition or feature of the Cohort. This is captured in the cohort_definition_id. For example, Cohorts can include patients diagnosed with a specific condition, patients exposed to a particular drug, or Providers who have performed a specific Procedure.
   * Cohort records must have a Start Date
   * Cohort records must have an End Date, but may be set to Start Date or could have applied a censored date using the Observation Period Start Date.
-  * Cohort records must contain a Subject Id, which can refer to the Person, Provider, or Visit record. The Cohort Definition will define the type of subject through the subject concept id.
+  * Cohort records must contain a Subject Id, which can refer to the Person, Provider, Visit record or Care Site. The Cohort Definition will define the type of subject through the subject concept id.
+  * A subject can belong (or not belong) to a cohort at any moment in time
+  * A subject can only have one record in the cohort table for any moment of time, i.e. it is not possible for a person to contain multiple records indicating cohort membership that are overlapping in time

StandardizedDerivedElements/DOSE_ERA.md

@@ -6,9 +6,9 @@ Field|Required|Type|Description
 |person_id|Yes|integer|A foreign key identifier to the Person who is subjected to the drug during the drug era. The demographic details of that Person are stored in the PERSON table.|
 |drug_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the active Ingredient Concept.|
 |unit_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the unit concept.|
-|dose_value|Yes|float|The numeric value of the average daily dose of the ingredient during the course of the era.|
+|dose_value|Yes|float|The numeric value of the dose.|
-|dose_era_start_date|Yes|date|The start date for the dose era constructed from the individual instances of drug exposures. It is the start date of the very first chronologically recorded instance of utilization of a drug.|
+|dose_era_start_date|Yes|date|The start date for the drug era constructed from the individual instances of drug exposures. It is the start date of the very first chronologically recorded instance of utilization of a drug.|
-|dose_era_end_date|Yes|date|The end date for the dose era constructed from the individual instance of drug exposures. It is the end date of the final continuously recorded instance of utilization of a drug.|
+|dose_era_end_date|Yes|date|The end date for the drug era constructed from the individual instance of drug exposures. It is the end date of the final continuously recorded instance of utilization of a drug.|
 
 ### Conventions 
   * Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm.

StandardizedHealthEconomicsDataTables/COST.md

@@ -6,7 +6,7 @@ Field|Required|Type|Description
 :-----------------------------|:--------|:------------|:----------------------------------------------------
 |cost_id						|Yes|integer|A unique identifier for each COST record.|
 |cost_event_id					|Yes|integer|A foreign key identifier to the event (e.g. Measurement, Procedure, Visit, Drug Exposure, etc) record for which cost data are recorded.|
-|cost_domain_id|Yes|string(20)|The domain of the cost event, from which the corresponding table can be inferred that contains the entity for which cost information is recorded.|
+|cost_domain_id					|Yes|varchar(20)|The concept representing the domain of the cost event, from which the corresponding table can be inferred that contains the entity for which cost information is recorded.|
 |cost_type_concept_id			|Yes|integer|A foreign key identifier to a concept in the CONCEPT table for the provenance or the source of the COST data: Calculated from insurance claim information, provider revenue, calculated from cost-to-charge ratio, reported from accounting database, etc.|
 |currency_concept_id			|No|integer|A foreign key identifier to the concept representing the 3-letter code used to delineate international currencies, such as USD for US Dollar.|
 |total_charge					|No|float|The total amount charged by some provider of goods or services (e.g. hospital, physician pharmacy, dme provider) to payers (insurance companies, the patient).|
@@ -23,7 +23,7 @@ Field|Required|Type|Description
 |payer_plan_period_id			|No|integer|A foreign key to the PAYER_PLAN_PERIOD table, where the details of the Payer, Plan and Family are stored.  Record the payer_plan_id that relates to the payer who contributed to the paid_by_payer field.|
 |amount_allowed					|No|float|The contracted amount agreed between the payer and provider.|
 |revenue_code_concept_id		|No|integer|A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes.|
-|revenue_code_source_value|No|string(50)|The source code for the Revenue code as it appears in the source data, stored here for reference.|
+|revenue_code_source_value		|No|varchar(50)|The source code for the Revenue code as it appears in the source data, stored here for reference.|
 |drg_concept_id					|No|integer|A foreign key to the predefined concept in the DRG Vocabulary reflecting the DRG for a visit.|
 |drg_source_value				|No|varchar(3)|	The 3-digit DRG source code as it appears in the source data.|
 

StandardizedHealthEconomicsDataTables/PAYER_PLAN_PERIOD.md

@@ -2,15 +2,24 @@ The PAYER_PLAN_PERIOD table captures details of the period of time that a Person
 
 Field|Required|Type|Description
 :------------------------------|:--------|:------------|:----------------------------------------------
-|payer_plan_period_id|Yes|integer|An identifier for each unique combination of payer, plan, family code and time span.|
+|payer_plan_period_id			|Yes|integer|A identifier for each unique combination of payer, plan, family code and time span.|
 |person_id						|Yes|integer|A foreign key identifier to the Person covered by the payer. The demographic details of that Person are stored in the PERSON table.|
 |payer_plan_period_start_date	|Yes|date|The start date of the payer plan period.|
 |payer_plan_period_end_date		|Yes|date|The end date of the payer plan period.|
+|payer_concept_id				|No|integer|A foreign key that refers to a standard Payer concept identifier in the Standarized Vocabularies|
 |payer_source_value				|No|varchar(50)|The source code for the payer as it appears in the source data.|
+|payer_source_concept_id		|No|integer|A foreign key to a payer concept that refers to the code used in the source.|
+|plan_concept_id				|No|integer|A foreign key that refers to a standard plan concept identifier that represents the health benefit plan in the Standardized Vocabularies|
 |plan_source_value				|No|varchar(50)|The source code for the Person's health benefit plan as it appears in the source data.|
+|plan_source_concept_id			|No|integer|A foreign key to a plan concept that refers to the plan code used in the source data.|
+|sponsor_concept_id				|No|integer|A foreign key that refers to a concept identifier that represents the sponsor in the Standardized Vocabularies.|
+|sponsor_source_value			|No|varchar(50)|The source code for the Person's sponsor of the health plan as it appears in the source data.|
+|sponsor_source_concept_id		|No|integer|A foreign key to a sponsor concept that refers to the sponsor code used in the source data.|
 |family_source_value			|No|varchar(50)|The source code for the Person's family as it appears in the source data.|
+|stop_reason_concept_id			|No|integer|A foreign key that refers to a standard termination reason that represents the reason for the termination in the Standardized Vocabularies.|
+|stop_reason_source_value		|No|varchar(50)|The reason for stop-coverage as it appears in the source data.|
+|stop_reason_source_concept_id	|No|integer|A foreign key to a stop-coverage concept that refers to the code used in the source.|
 
 ### Conventions 
   * Different Payers have different designs for their health benefit Plans. The PAYER_PLAN_PERIOD table does not capture all details of the plan design or the relationship between Plans or the cost of healthcare triggering a change from one Plan to another. However, it allows identifying the unique combination of Payer (insurer), Plan (determining healthcare benefits and limits) and Person. Typically, depending on healthcare utilization, a Person may have one or many subsequent Plans during coverage by a single Payer.
-  * Payer or Plan information is not normalized or recorded as part of the Standard Vocabularies. Instead, they are referred to only by their source_value.
   * Typically, family members are covered under the same Plan as the Person. In those cases, the payer_source_value, plan_source_value and family_source_value are identical.

StandardizedHealthSystemDataTables/PROVIDER.md

@@ -3,7 +3,7 @@ The PROVIDER table contains a list of uniquely identified healthcare providers.
 Field|Required|Type|Description
 :-------------------------|:--------|:------------|:-------------------------------------
 |provider_id|Yes|integer|A unique identifier for each Provider.|
-|provider_name|No|varchar(50)|A description of the Provider.|
+|provider_name|No|varchar(255)|A description of the Provider.|
 |npi|No|varchar(20)|The National Provider Identifier (NPI) of the provider.|
 |dea|No|varchar(20)|The Drug Enforcement Administration (DEA) number of the provider.|
 |specialty_concept_id|No|integer|A foreign key to a Standard Specialty Concept ID in the Standardized Vocabularies.|

StandardizedMetadata/METADATA.md

@@ -0,0 +1,15 @@
+The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model. 
+
+Field					|Required	|Type	|Description
+:------------------------------|:--------|:------------|:-----------------------------------------
+|metadata_concept_id		|Yes		|integer		|A foreign key that refers to a Standard Metadata Concept identifier in the Standardized Vocabularies.|
+|metadata_type_concept_id	|Yes		|integer		|A foreign key that refers to a Standard Type Concept identifier in the Standardized Vocabularies.|
+|name						|Yes		|varchar(250)	|The name of the Concept stored in metadata_concept_id or a description of the data being stored.|
+|value_as_string			|No			|nvarchar		|The metadata value stored as a string.|
+|value_as_concept_id		|No			|integer		|A foreign key to a metadata value stored as a Concept ID.|
+|metadata date				|No			|date			|The date associated with the metadata|
+|metadata_datetime			|No			|datetime		|The date and time associated with the metadata|
+
+### Conventions 
+
+  * 

StandardizedVocabularies/ATTRIBUTE_DEFINITION.md

@@ -4,9 +4,9 @@ Field|Required|Type|Description
 :-------------------------|:--------|:-----|:--------------------------------------
 |attribute_definition_id|Yes|integer|A unique identifier for each Attribute.|
 |attribute_name|Yes|varchar(255)|A short description of the Attribute.|
-|attribute_description|No|CLOB|A complete description of the Attribute definition|
+|attribute_description|No|varchar(MAX)|A complete description of the Attribute definition|
 |attribute_type_concept_id|Yes|integer|Type defining what kind of Attribute Definition the record represents and how the syntax may be executed|
-|attribute_syntax|No|CLOB|Syntax or code to operationalize the Attribute definition|
+|attribute_syntax|No|varchar(MAX)|Syntax or code to operationalize the Attribute definition|
 
 
 ### Conventions

StandardizedVocabularies/COHORT_DEFINITION.md

@@ -4,9 +4,9 @@ Field|Required|Type|Description
 :------------------------------|:--------|:-----|:-----------------------------------------------
 |cohort_definition_id|Yes|integer|A unique identifier for each Cohort.|
 |cohort_definition_name|Yes|varchar(255)|A short description of the Cohort.|
-|cohort_definition_description|No|CLOB|A complete description of the Cohort definition|
+|cohort_definition_description|No|varchar(MAX)|A complete description of the Cohort definition|
 |definition_type_concept_id|Yes|integer|Type defining what kind of Cohort Definition the record represents and how the syntax may be executed|
-|cohort_definition_syntax|No|CLOB|Syntax or code to operationalize the Cohort definition|
+|cohort_definition_syntax|No|varchar(MAX)|Syntax or code to operationalize the Cohort definition|
 |subject_concept_id|Yes|integer|A foreign key to the Concept to which defines the domain of subjects that are members of the cohort (e.g., Person, Provider, Visit).|
 |cohort_instantiation_date|No|Date|A date to indicate when the Cohort was instantiated in the COHORT table|
 

StandardizedVocabularies/CONCEPT_ANCESTOR.md

@@ -9,31 +9,6 @@ Field|Required|Type|Description
 |min_levels_of_separation|Yes|integer|The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.|
 |max_levels_of_separation|Yes|integer|The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.|
 
-A path between two concepts can be characterized by the sequence of relationships that need to be traversed in order to reach a descendant concept from an ancestor concept.
-
-For example, for concepts
-
-descendant_concept_id|descendant_concept_name|ancestor_concept_id|ancestor_concept_name|min_levels_of_separation|max_levels_of_separation
-:----------|:--------------------|:--------|:---------------------|:----------|:-----------
-|313217|Atrial fibrillation|321588|Heart disease|3|4|
-
-the shortest path in concept_relationship will be :
-
-313217 Atrial fibrillation  **Is a**  4226399 Fibrillation  **Is a**
-44784217 Cardiac arrhythmia  **Is a**  321588  Heart disease
-
-the longest:
-
-313217 Atrial fibrillation  **Is a**  4068155  Atrial arrhythmia  **Is a** 
-4248028  Supraventricular arrhythmia  **Is a**  44784217 Cardiac arrhythmia 
-**Is a** 321588  Heart disease
-
-
-
-![](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?cache=&media=documentation:cdm:concept_ancestor.png)
-
-
-
 ### Conventions 
 
   * Each concept is also recorded as an ancestor of itself.

StandardizedVocabularies/CONCEPT_SYNONYM.md

@@ -8,6 +8,6 @@ The CONCEPT_SYNONYM table is used to store alternate names and descriptions for
 
 ### Conventions
 
-  * The concept_synonym_name field contains a valid Synonym of a concept, including the description in the concept_name itself. I.e. each Concept has at least one Synonym in the CONCEPT_SYNONYM table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the concept_name of the CONCEPT table, then the Preferred Term and Synonyms associated with the Concept are stored in the CONCEPT_SYNONYM table. 
+  * The concept_name field contains a valid Synonym of a concept, including the description in the concept_name itself. I.e. each Concept has at least one Synonym in the CONCEPT_SYNONYM table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the concept_name of the CONCEPT table, then the Preferred Term and Synonyms associated with the Concept are stored in the CONCEPT_SYNONYM table. 
   * Only Synonyms that are active and current are stored in the CONCEPT_SYNONYM table. Tracking synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out of scope for the Standard Vocabularies.
   * Currently, only English Synonyms are included.

StandardizedVocabularies/SOURCE_TO_CONCEPT_MAP.md

@@ -4,8 +4,8 @@ Field|Required|Type|Description
 :-------------------------|:--------|:------------|:----------------------------
 |source_code|Yes|varchar(50)|The source code being translated into a Standard Concept.|
 |source_concept_id|Yes|integer|A foreign key to the Source Concept that is being translated into a Standard Concept.|
-|source_vocabulary_id|No|varchar(20)|A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.|
+|source_vocabulary_id|Yes|varchar(20)|A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.|
-|source_code_description|Yes|varchar(255)|An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept.|
+|source_code_description|No|varchar(255)|An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept.|
 |target_concept_id|Yes|integer|A foreign key to the target Concept to which the source code is being mapped.|
 |target_vocabulary_id|Yes|varchar(20)|A foreign key to the VOCABULARY table defining the vocabulary of the target Concept.|
 |valid_start_date|Yes|date|The date when the mapping instance was first recorded.|