rendered docs

docs/cdm53.html

@@ -953,7 +953,8 @@ source data. It is not intended for use in standard analytics but for
 reference only.
 </td>
 <td style="text-align:left;">
-Put the biological sex of the person as it appears in the source data.
+Put the assigned sex at birth of the person as it appears in the source
+data.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -980,8 +981,8 @@ gender_source_concept_id
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes biological sex in a non-standard vocabulary,
+If the source data codes asigned sex at birth in a non-standard
-store the concept_id here.
+vocabulary, store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -3432,14 +3433,16 @@ entry is stored with only the corresponding SOURCE_CONCEPT_ID and
 DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the
 most detailed content of information is preferred during the mapping
 process. These are indicated in the CONCEPT_CLASS_ID field of the
-Concept and are recorded in the following order of precedence: ‘Branded
+Concept and are recorded in the following order of precedence:
-Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug
+<d2>Marketed Product<d3>, <d2>Branded Pack<d3>, <d2>Clinical Pack<d3>,
-Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical
+<d2>Branded Drug<d3>, <d2>Clinical Drug<d3>, <d2>Branded Drug
-Drug Form’, and only if no other information is available ‘Ingredient’.
+Component<d3>, <d2>Clinical Drug Component<d3>, <d2>Branded Drug
-Note: If only the drug class is known, the DRUG_CONCEPT_ID field should
+Form<d3>, <d2>Clinical Drug Form<d3>, and only if no other information
-contain 0. <a
+is available <d2>Ingredient<d3>. Note: If only the drug class is known,
+the DRUG_CONCEPT_ID field should contain 0. <a
 href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
 Concepts</a>.
+</d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2>
 </td>
 <td style="text-align:left;">
 integer
@@ -5248,12 +5251,13 @@ measurement_concept_id
 </td>
 <td style="text-align:left;">
 The MEASUREMENT_CONCEPT_ID field is recommended for primary use in
-analyses, and must be used for network studies.
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a measurement.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only
+The CONCEPT_ID that the MEASUREMENT_SOURCE_VALUE maps to. Only records
-records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain
+whose source values map to concepts with a domain of <d2>Measurement<d3>
-of “Measurement” should go in this table.
+should go in this table. </d3></d2>
 </td>
 <td style="text-align:left;">
 integer
@@ -5517,19 +5521,17 @@ CONCEPT
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual measurements,
+At present, there isn’t a prescribed unit for individual measurements,
-i.e. it is not mandatory to represent Hemoglobin a1C measurements as a
+such as Hemoglobin A1C, meaning it’s not obligatory to express these
-percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+measurements as a percentage. UNIT_SOURCE_VALUES should be linked to a
-the Unit domain that best represents the unit as given in the source
+Standard Concept within the Unit domain that most accurately reflects
-data.
+the unit provided in the source data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with
+If the source data does not include units, set UNIT_CONCEPT_ID to NULL.
-MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to
+If units are provided but not mapped, set UNIT_CONCEPT_ID to 0.
-choose the most plausible unit. If the source unit is NULL (applicable
+Otherwise, map the units to a CONCEPT_ID. Remember that units are
-to cases when there’s no numerical value or when it doesn’t require a
+case-sensitive in vocabulary.
-unit), keep unit_concept_id NULL as well. If there’s no mapping of a
-source unit, populate unit_concept_id with 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -5782,12 +5784,13 @@ CONCEPT
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing
+This field contains the exact value from the source data that represents
-the unit of the Measurement that occurred.
+the unit of measurement used.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized
+This value corresponds to a standardized CONCEPT_ID found in
-Vocabularies and the original code is stored here for reference.
+UNIT_CONCEPT_ID and in the ‘Unit’ domain within the Standardized
+Vocabularies. The original code is retained here for reference purposes.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -5858,10 +5861,18 @@ to a standardized result, the data item is recorded in the MEASUREMENT
 table. If the clinical fact observed determines a sign, symptom,
 diagnosis of a disease or other medical condition, it is recorded in the
 CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced
-to be from any domain though they still should be Standard Concepts.</p>
+to be from any domain but they must not belong to the Condition,
+Procedure, Drug, Device, Specimen, or Measurement domains and they must
+be Standard Concepts. <br><br>The observation table usually records the
+date or datetime of when the observation was obtained, not the date of
+the observation starting. For example, if the patient reports that they
+had a heart attack when they were 50, the observation date or datetime
+is the date of the report, the heart attack observation can have a
+value_as_concept which captures how long ago the observation applied to
+the patient.</p>
 <p><strong>ETL Conventions</strong></p>
 <p>Records whose Source Values map to any domain besides Condition,
-Procedure, Drug, Measurement or Device should be stored in the
+Procedure, Drug, Specimen, Measurement or Device should be stored in the
 Observation table. Observations can be stored as attribute value pairs,
 with the attribute as the Observation Concept and the value representing
 the clinical fact. This fact can be a Concept (stored in
@@ -5999,9 +6010,9 @@ CONCEPT
 observation_date
 </td>
 <td style="text-align:left;">
-The date of the Observation. Depending on what the Observation
+The date of when the Observation was obtained. Depending on what the
-represents this could be the date of a lab test, the date of a survey,
+Observation represents this could be the date of a lab test, the date of
-or the date a patient’s family history was taken.
+a survey, or the date a patient’s family history was taken.
 </td>
 <td style="text-align:left;">
 For some observations the ETL may need to make a choice as to which date
@@ -6711,7 +6722,8 @@ cause_source_concept_id
 </td>
 <td style="text-align:left;">
 If the cause of death was coded using a Vocabulary present in the OMOP
-Vocabularies put the CONCEPT_ID representing the cause of death here.
+Vocabularies (not necessarily a standard concept) put the CONCEPT_ID
+representing the cause of death here.
 </td>
 <td style="text-align:left;">
 integer
@@ -8542,11 +8554,12 @@ delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
 <p><strong>User Guide</strong></p>
 <p>NA</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Care site is a unique combination of location_id and
+<p>Care site is a unique combination of location_id and nature of the
-place_of_service_source_value. Care site does not take into account the
+site - the latter could be the place of service, name, or another
-provider (human) information such a specialty. Many source data do not
+characteristic in your source data. Care site does not take into account
-make a distinction between individual and institutional providers. The
+the provider (human) information such a specialty. Many source data do
-CARE_SITE table contains the institutional providers. If the source,
+not make a distinction between individual and institutional providers.
+The CARE_SITE table contains the institutional providers. If the source,
 instead of uniquely identifying individual Care Sites, only provides
 limited information such as Place of Service, generic or “pooled” Care
 Site records are listed in the CARE_SITE table. There can be

docs/cdm54.html

@@ -1061,7 +1061,8 @@ source data. It is not intended for use in standard analytics but for
 reference only.
 </td>
 <td style="text-align:left;">
-Put the biological sex of the person as it appears in the source data.
+Put the assigned sex at birth of the person as it appears in the source
+data.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -1088,8 +1089,8 @@ gender_source_concept_id
 Due to the small number of options, this tends to be zero.
 </td>
 <td style="text-align:left;">
-If the source data codes biological sex in a non-standard vocabulary,
+If the source data codes assigned sex at birth in a non-standard
-store the concept_id here.
+vocabulary, store the concept_id here.
 </td>
 <td style="text-align:left;">
 integer
@@ -3568,14 +3569,16 @@ entry is stored with only the corresponding SOURCE_CONCEPT_ID and
 DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the
 most detailed content of information is preferred during the mapping
 process. These are indicated in the CONCEPT_CLASS_ID field of the
-Concept and are recorded in the following order of precedence: ‘Branded
+Concept and are recorded in the following order of precedence:
-Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug
+<d2>Marketed Product<d3>, <d2>Branded Pack<d3>, <d2>Clinical Pack<d3>,
-Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical
+<d2>Branded Drug<d3>, <d2>Clinical Drug<d3>, <d2>Branded Drug
-Drug Form’, and only if no other information is available ‘Ingredient’.
+Component<d3>, <d2>Clinical Drug Component<d3>, <d2>Branded Drug
-Note: If only the drug class is known, the DRUG_CONCEPT_ID field should
+Form<d3>, <d2>Clinical Drug Form<d3>, and only if no other information
-contain 0. <a
+is available <d2>Ingredient<d3>. Note: If only the drug class is known,
+the DRUG_CONCEPT_ID field should contain 0. <a
 href="https://athena.ohdsi.org/search-terms/terms?domain=Drug&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
 Concepts</a>.
+</d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2></d3></d2>
 </td>
 <td style="text-align:left;">
 integer
@@ -5579,12 +5582,13 @@ measurement_concept_id
 </td>
 <td style="text-align:left;">
 The MEASUREMENT_CONCEPT_ID field is recommended for primary use in
-analyses, and must be used for network studies.
+analyses, and must be used for network studies. This is the standard
+concept mapped from the source value which represents a measurement.
 </td>
 <td style="text-align:left;">
-The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only
+The CONCEPT_ID that the MEASUREMENT_SOURCE_VALUE maps to. Only records
-records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain
+whose source values map to concepts with a domain of <d2>Measurement<d3>
-of “Measurement” should go in this table.
+should go in this table. </d3></d2>
 </td>
 <td style="text-align:left;">
 integer
@@ -5851,19 +5855,17 @@ CONCEPT
 unit_concept_id
 </td>
 <td style="text-align:left;">
-There is currently no recommended unit for individual measurements,
+At present, there isn’t a prescribed unit for individual measurements,
-i.e. it is not mandatory to represent Hemoglobin a1C measurements as a
+such as Hemoglobin A1C, meaning it’s not obligatory to express these
-percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in
+measurements as a percentage. UNIT_SOURCE_VALUES should be linked to a
-the Unit domain that best represents the unit as given in the source
+Standard Concept within the Unit domain that most accurately reflects
-data.
+the unit provided in the source data.
 </td>
 <td style="text-align:left;">
-There is no standardization requirement for units associated with
+If the source data does not include units, set UNIT_CONCEPT_ID to NULL.
-MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to
+If units are provided but not mapped, set UNIT_CONCEPT_ID to 0.
-choose the most plausible unit. If the source unit is NULL (applicable
+Otherwise, map the units to a CONCEPT_ID. Remember that units are
-to cases when there’s no numerical value or when it doesn’t require a
+case-sensitive in vocabulary.
-unit), keep unit_concept_id NULL as well. If there’s no mapping of a
-source unit, populate unit_concept_id with 0.
 </td>
 <td style="text-align:left;">
 integer
@@ -6116,12 +6118,13 @@ CONCEPT
 unit_source_value
 </td>
 <td style="text-align:left;">
-This field houses the verbatim value from the source data representing
+This field contains the exact value from the source data that represents
-the unit of the Measurement that occurred.
+the unit of measurement used.
 </td>
 <td style="text-align:left;">
-This code is mapped to a Standard Condition Concept in the Standardized
+This value corresponds to a standardized CONCEPT_ID found in
-Vocabularies and the original code is stored here for reference.
+UNIT_CONCEPT_ID and in the ‘Unit’ domain within the Standardized
+Vocabularies. The original code is retained here for reference purposes.
 </td>
 <td style="text-align:left;">
 varchar(50)
@@ -6288,10 +6291,18 @@ to a standardized result, the data item is recorded in the MEASUREMENT
 table. If the clinical fact observed determines a sign, symptom,
 diagnosis of a disease or other medical condition, it is recorded in the
 CONDITION_OCCURRENCE table. Valid Observation Concepts are not enforced
-to be from any domain though they still should be Standard Concepts.</p>
+to be from any domain but they must not belong to the Condition,
+Procedure, Drug, Device, Specimen, or Measurement domains and they must
+be Standard Concepts. <br><br>The observation table usually records the
+date or datetime of when the observation was obtained, not the date of
+the observation starting. For example, if the patient reports that they
+had a heart attack when they were 50, the observation date or datetime
+is the date of the report, the heart attack observation can have a
+value_as_concept which captures how long ago the observation applied to
+the patient.</p>
 <p><strong>ETL Conventions</strong></p>
 <p>Records whose Source Values map to any domain besides Condition,
-Procedure, Drug, Measurement or Device should be stored in the
+Procedure, Drug, Specimen, Measurement or Device should be stored in the
 Observation table. Observations can be stored as attribute value pairs,
 with the attribute as the Observation Concept and the value representing
 the clinical fact. This fact can be a Concept (stored in
@@ -6429,9 +6440,9 @@ CONCEPT
 observation_date
 </td>
 <td style="text-align:left;">
-The date of the Observation. Depending on what the Observation
+The date of when the Observation was obtained. Depending on what the
-represents this could be the date of a lab test, the date of a survey,
+Observation represents this could be the date of a lab test, the date of
-or the date a patient’s family history was taken.
+a survey, or the date a patient’s family history was taken.
 </td>
 <td style="text-align:left;">
 For some observations the ETL may need to make a choice as to which date
@@ -7243,7 +7254,8 @@ cause_source_concept_id
 </td>
 <td style="text-align:left;">
 If the cause of death was coded using a Vocabulary present in the OMOP
-Vocabularies put the CONCEPT_ID representing the cause of death here.
+Vocabularies (not necessarily a standard concept) put the CONCEPT_ID
+representing the cause of death here.
 </td>
 <td style="text-align:left;">
 integer
@@ -9250,11 +9262,12 @@ delivery is practiced (offices, wards, hospitals, clinics, etc.).</p>
 <p><strong>User Guide</strong></p>
 <p>NA</p>
 <p><strong>ETL Conventions</strong></p>
-<p>Care site is a unique combination of location_id and
+<p>Care site is a unique combination of location_id and nature of the
-place_of_service_source_value. Care site does not take into account the
+site - the latter could be the place of service, name, or another
-provider (human) information such a specialty. Many source data do not
+characteristic in your source data. Care site does not take into account
-make a distinction between individual and institutional providers. The
+the provider (human) information such a specialty. Many source data do
-CARE_SITE table contains the institutional providers. If the source,
+not make a distinction between individual and institutional providers.
+The CARE_SITE table contains the institutional providers. If the source,
 instead of uniquely identifying individual Care Sites, only provides
 limited information such as Place of Service, generic or “pooled” Care
 Site records are listed in the CARE_SITE table. There can be