Updates to documentation and creation of CDM_v5.2 pdf.

Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/NOTE.md

@@ -26,13 +26,15 @@ Field|Required|Type|Description
 ### Mapping of clinical documents to Clinical Document Ontology (CDO) and standard terminology
 
 HL7/LOINC CDO is a standard for consistent naming of documents to support a range of use cases: retrieval, organization, display, and exchange. It guides the creation of LOINC codes for clinical notes. CDO annotates each document with 5 dimensions:
+
 * **Kind of Document:** Characterizes the generalc structure of the document at a macro level (e.g. Anesthesia Consent)
-* **Type of Service:** Characterizes the kind of service or activity (e.g. evaluations, consultations, and summaries). The notion of time sequence, e.g., at the beginning (admission) at the end (discharge) is subsumed in this axis. Example: Discharge Teaching.
+* **Type of Service**: Characterizes the kind of service or activity (e.g. evaluations, consultations, and summaries). The notion of time sequence, e.g., at the beginning (admission) at the end (discharge) is subsumed in this axis. Example: Discharge Teaching.
 * **Setting:** Setting is an extension of CMS’s definitions (e.g. Inpatient, Outpatient)
 * **Subject Matter Domain (SMD):** Characterizes the subject matter domain of a note (e.g. Anesthesiology)
 * **Role:** Characterizes the training or professional level of the author of the document, but does not break down to specialty or subspecialty (e.g. Physician)
 
 Each combination of these 5 dimensions should roll up to a unique LOINC code. For example, Dentistry Hygienist Outpatient Progress note (LOINC code 34127-1) has the following dimensions:
+
 * According to CDO requirements, only 2 of the 5 dimensions are required to properly annotate a document: Kind of Document and any one of the other 4 dimensions.
 * However, not all the permutations of the CDO dimensions will necessarily yield an existing LOINC code.2 HL7/LOINC workforce is committed to establish new LOINC codes for each new encountered combination of CDO dimensions. 3
  
@@ -65,6 +67,7 @@ concept_code | 34127-1 | 11488-4
 vocabulary_id | LOINC | LOINC
 
 #### 4.  Represent dimensions of each document concept in Concept_Relationship table by its relationships to the respective concepts from CDO. 
+
 * Use the “Member Of” – “Has Member”  (new) relationship pair. 
 * Using example from the Dentistry Hygienist Outpatient Progress note (LOINC code 34127-1):
 
@@ -84,7 +87,7 @@ concept_id_1 | concept_id_1 | relationship_id
 Where concept codes represent the following concepts:
 
 Content | Description
-:-- | :--
+:---------- | :--------------------------------------------------------------------
 193240 | Corresponds to LOINC 34127-1, Dentistry Hygienist Outpatient Progress note
 55443322132 | Corresponds to LOINC LP173418-7, Kind of Document = Note
 55443322175 | Corresponds to LOINC LP173213-2, Type of Service = Progress
@@ -95,30 +98,34 @@ Content | Description
 Most of the codes will not have all 5 dimensions. Therefore, they may be represented by 2-5 relationship pairs.
 
 #### 5. If LOINC does not have a code corresponding to a permutation of the 5 CDO encountered in the source, this code will be generated as OMOP vocabulary code. 
+
 * Its relationships to the CDO dimensions will be represented exactly as those of existing LOINC concepts (as described above). If/when a proper LOINC code for this permutation is released, the old code should be deprecated.  Transition between the old and new codes should be represented by “Concept replaces” – “Concept replaced by” pairs.
 
 #### 6.  Mapping from the source data will be performed to the 2-5 CDO dimensions.
 
 Query below finds LOINC code for Dentistry Hygienist Outpatient Progress note (see example above) that has all 5 dimensions:
 
-`SELECT 
-FROM Concept_Relationship
-WHERE relationship_id = ‘Has Member’ AND
-(concept_id_1 = 55443322132
-OR concept_id_1 = 55443322175
-OR concept_id_1 = 55443322166
-OR concept_id_1 = 55443322107
-OR concept_id_1 = 55443322146)
-GROUP BY concept_ID_2
-`
-If less than 5 dimensions are available, HAVING COUNT(n) clause should be added to get a unique record at the intersection of these dimensions. n is the number of dimensions available:
+```sql	
+	SELECT   
+	FROM Concept_Relationship  
+	WHERE relationship_id = ‘Has Member’ AND
+		(concept_id_1 = 55443322132 
+		OR concept_id_1 = 55443322175
+		OR concept_id_1 = 55443322166
+		OR concept_id_1 = 55443322107
+		OR concept_id_1 = 55443322146)
+	GROUP BY concept_ID_2
+```
 
-`SELECT
-FROM Concept_Relationship
-WHERE relationship_id = ‘Has Member’ AND
-(concept_id_1 = 55443322132
-OR concept_id_1 = 55443322175
-OR concept_id_1 = 55443322146)
-GROUP BY concept_ID_2
-HAVING COUNT(*) = 3
-`
+If less than 5 dimensions are available, `HAVING COUNT(n)` clause should be added to get a unique record at the intersection of these dimensions. n is the number of dimensions available:
+
+```sql
+	SELECT  
+	FROM Concept_Relationship  
+	WHERE relationship_id = ‘Has Member’ AND  
+		(concept_id_1 = 55443322132  
+		OR concept_id_1 = 55443322175  
+		OR concept_id_1 = 55443322146)  
+	GROUP BY concept_ID_2  
+	HAVING COUNT(*) = 3  
+```

Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/NOTE_NLP.md

@@ -1,7 +1,7 @@
 The NOTE_NLP table will encode all output of NLP on clinical notes. Each row represents a single extracted term from a note.
 
 Field | Required | Type | Description
-:-- | :-- | :-- | :--
+:------------------------------- | :-------- | :------------ | :---------------------------------------------------
 note_nlp_id | Yes | Big 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.
@@ -15,12 +15,13 @@ nlp_date | Yes | date | The date of the note processing.Useful for data provenan
 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_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
 
 **Term_exists**
 Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false:
+
 * Negation = true
 * Subject = [anything other than the patient]
 * Conditional = true
@@ -30,6 +31,7 @@ Term_exists is defined as a flag that indicates if the patient actually has or h
 A complete lack of modifiers would make Term_exists true. 
 
 For the modifiers that are there, they would have to have these values:
+
 * Negation = false
 * Subject = patient
 * Conditional = false
@@ -40,6 +42,7 @@ For the modifiers that are there, they would have to have these values:
 Term_temporal is to indicate if a condition is “present” or just in the “past”.
 
 The following would be past:
+ 
 * History = true
 * Concept_date = anything before the time of the report
 

Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md

@@ -9,6 +9,7 @@
 [CONDITION_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE)  
 [MEASUREMENT](https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT)  
 [NOTE](https://github.com/OHDSI/CommonDataModel/wiki/NOTE)  
+[NOTE_NLP](https://github.com/OHDSI/CommonDataModel/wiki/NOTE_NLP)  
 [OBSERVATION](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION)  
 [FACT_RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/FACT_RELATIONSHIP)  
   

Documentation/CommonDataModel_Wiki_Files/StandardizedDerivedElements/CONDITION_ERA.md

@@ -1,8 +1,10 @@
 A Condition Era is defined as a span of time when the Person is assumed to have a given condition. 
 Similar to Drug Eras, Condition Eras are chronological periods of Condition Occurrence. Combining individual Condition Occurrences into a single Condition Era serves two purposes:
+
   * It allows aggregation of chronic conditions that require frequent ongoing care, instead of treating each Condition Occurrence as an independent event.
   * It allows aggregation of multiple, closely timed doctor visits for the same Condition to avoid double-counting the Condition Occurrences.
-For example, consider a Person who visits her Primary Care Physician (PCP) and who is referred to a specialist. At a later time, the Person visits the specialist, who confirms the PCP’s original diagnosis and provides the appropriate treatment to resolve the condition. These two independent doctor visits should be aggregated into one Condition Era.
+  
+For example, consider a Person who visits her Primary Care Physician (PCP) and who is referred to a specialist. At a later time, the Person visits the specialist, who confirms the PCP's original diagnosis and provides the appropriate treatment to resolve the condition. These two independent doctor visits should be aggregated into one Condition Era.
 
 Field|Required|Type|Description
 :----------------------------|:--------|:------------|:----------------------------------
@@ -16,7 +18,7 @@ Field|Required|Type|Description
 ### Conventions 
   * Condition Era records will be derived from the records in the CONDITION_OCCURRENCE table using a standardized algorithm.
   * Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval.
-The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers.
-The Condition Era Start Date is the start date of the first Condition Occurrence.
-The Condition Era End Date is the end date of the last Condition Occurrence.
+    * The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers.
+    * The Condition Era Start Date is the start date of the first Condition Occurrence.
+    * The Condition Era End Date is the end date of the last Condition Occurrence.
   * Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.

Documentation/CommonDataModel_pdf_create/.Rproj.user/shared/notebooks/4CB4ECEA-OMOP_CDM_PDF/1/C9B3802/chunks.json

@@ -1 +0,0 @@
-{"chunk_definitions":[],"doc_write_time":1500488165}

Documentation/CommonDataModel_pdf_create/.Rproj.user/shared/notebooks/4CB4ECEA-OMOP_CDM_PDF/1/s/chunks.json

@@ -1 +0,0 @@
-{"chunk_definitions":[],"doc_write_time":1500488165}

Documentation/CommonDataModel_pdf_create/.Rproj.user/shared/notebooks/paths

@@ -1,3 +1 @@
-C:/Git/GitHub/CDM_v5.2/CommonDataModel/Documentation/CommonDataModel_pdf_create/OMOP_CDM_PDF.Rmd="642ADD90"
-C:/Git/GitHub/CommonDataModel/Documentation/CommonDataModel_pdf_create/.Rhistory="F8815F2B"
-C:/Git/GitHub/CommonDataModel/Documentation/CommonDataModel_pdf_create/OMOP_CDM_PDF.Rmd="4CB4ECEA"
+C:/Git/CommonDataModel/Documentation/CommonDataModel_pdf_create/OMOP_CDM_PDF.Rmd="71819BA2"