diff --git a/docs/cdm53.html b/docs/cdm53.html index 6e225fa..4c3d44a 100644 --- a/docs/cdm53.html +++ b/docs/cdm53.html @@ -953,7 +953,8 @@ source data. It is not intended for use in standard analytics but for reference only. -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. varchar(50) @@ -980,8 +981,8 @@ gender_source_concept_id Due to the small number of options, this tends to be zero. -If the source data codes biological sex in a non-standard vocabulary, -store the concept_id here. +If the source data codes asigned sex at birth in a non-standard +vocabulary, store the concept_id here. 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 -Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug -Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical -Drug Form’, and only if no other information is available ‘Ingredient’. -Note: If only the drug class is known, the DRUG_CONCEPT_ID field should -contain 0. Marketed Product, Branded Pack, Clinical Pack, +Branded Drug, Clinical Drug, Branded Drug +Component, Clinical Drug Component, Branded Drug +Form, Clinical Drug Form, and only if no other information +is available Ingredient. Note: If only the drug class is known, +the DRUG_CONCEPT_ID field should contain 0. Accepted Concepts. + integer @@ -5248,12 +5251,13 @@ measurement_concept_id 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. -The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only -records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain -of “Measurement” should go in this table. +The CONCEPT_ID that the MEASUREMENT_SOURCE_VALUE maps to. Only records +whose source values map to concepts with a domain of Measurement +should go in this table. integer @@ -5517,19 +5521,17 @@ CONCEPT unit_concept_id -There is currently no recommended unit for individual measurements, -i.e. it is not mandatory to represent Hemoglobin a1C measurements as a -percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in -the Unit domain that best represents the unit as given in the source -data. +At present, there isn’t a prescribed unit for individual measurements, +such as Hemoglobin A1C, meaning it’s not obligatory to express these +measurements as a percentage. UNIT_SOURCE_VALUES should be linked to a +Standard Concept within the Unit domain that most accurately reflects +the unit provided in the source data. -There is no standardization requirement for units associated with -MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to -choose the most plausible unit. If the source unit is NULL (applicable -to cases when there’s no numerical value or when it doesn’t require a -unit), keep unit_concept_id NULL as well. If there’s no mapping of a -source unit, populate unit_concept_id with 0. +If the source data does not include units, set UNIT_CONCEPT_ID to NULL. +If units are provided but not mapped, set UNIT_CONCEPT_ID to 0. +Otherwise, map the units to a CONCEPT_ID. Remember that units are +case-sensitive in vocabulary. integer @@ -5782,12 +5784,13 @@ CONCEPT unit_source_value -This field houses the verbatim value from the source data representing -the unit of the Measurement that occurred. +This field contains the exact value from the source data that represents +the unit of measurement used. -This code is mapped to a Standard Condition Concept in the Standardized -Vocabularies and the original code is stored here for reference. +This value corresponds to a standardized CONCEPT_ID found in +UNIT_CONCEPT_ID and in the ‘Unit’ domain within the Standardized +Vocabularies. The original code is retained here for reference purposes. 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.

+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.

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.

ETL Conventions

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 -The date of the Observation. Depending on what the Observation -represents this could be the date of a lab test, the date of a survey, -or the date a patient’s family history was taken. +The date of when the Observation was obtained. Depending on what the +Observation represents this could be the date of a lab test, the date of +a survey, or the date a patient’s family history was taken. For some observations the ETL may need to make a choice as to which date @@ -6711,7 +6722,8 @@ cause_source_concept_id 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. integer @@ -8542,11 +8554,12 @@ delivery is practiced (offices, wards, hospitals, clinics, etc.).

User Guide

NA

ETL Conventions

-

Care site is a unique combination of location_id and -place_of_service_source_value. Care site does not take into account the -provider (human) information such a specialty. Many source data do not -make a distinction between individual and institutional providers. The -CARE_SITE table contains the institutional providers. If the source, +

Care site is a unique combination of location_id and nature of the +site - the latter could be the place of service, name, or another +characteristic in your source data. Care site does not take into account +the provider (human) information such a specialty. Many source data do +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 diff --git a/docs/cdm54.html b/docs/cdm54.html index a418236..1134533 100644 --- a/docs/cdm54.html +++ b/docs/cdm54.html @@ -1061,7 +1061,8 @@ source data. It is not intended for use in standard analytics but for reference only. -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. varchar(50) @@ -1088,8 +1089,8 @@ gender_source_concept_id Due to the small number of options, this tends to be zero. -If the source data codes biological sex in a non-standard vocabulary, -store the concept_id here. +If the source data codes assigned sex at birth in a non-standard +vocabulary, store the concept_id here. 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 -Pack’, ‘Clinical Pack’, ‘Branded Drug’, ‘Clinical Drug’, ‘Branded Drug -Component’, ‘Clinical Drug Component’, ‘Branded Drug Form’, ‘Clinical -Drug Form’, and only if no other information is available ‘Ingredient’. -Note: If only the drug class is known, the DRUG_CONCEPT_ID field should -contain 0. Marketed Product, Branded Pack, Clinical Pack, +Branded Drug, Clinical Drug, Branded Drug +Component, Clinical Drug Component, Branded Drug +Form, Clinical Drug Form, and only if no other information +is available Ingredient. Note: If only the drug class is known, +the DRUG_CONCEPT_ID field should contain 0. Accepted Concepts. + integer @@ -5579,12 +5582,13 @@ measurement_concept_id 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. -The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only -records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain -of “Measurement” should go in this table. +The CONCEPT_ID that the MEASUREMENT_SOURCE_VALUE maps to. Only records +whose source values map to concepts with a domain of Measurement +should go in this table. integer @@ -5851,19 +5855,17 @@ CONCEPT unit_concept_id -There is currently no recommended unit for individual measurements, -i.e. it is not mandatory to represent Hemoglobin a1C measurements as a -percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in -the Unit domain that best represents the unit as given in the source -data. +At present, there isn’t a prescribed unit for individual measurements, +such as Hemoglobin A1C, meaning it’s not obligatory to express these +measurements as a percentage. UNIT_SOURCE_VALUES should be linked to a +Standard Concept within the Unit domain that most accurately reflects +the unit provided in the source data. -There is no standardization requirement for units associated with -MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to -choose the most plausible unit. If the source unit is NULL (applicable -to cases when there’s no numerical value or when it doesn’t require a -unit), keep unit_concept_id NULL as well. If there’s no mapping of a -source unit, populate unit_concept_id with 0. +If the source data does not include units, set UNIT_CONCEPT_ID to NULL. +If units are provided but not mapped, set UNIT_CONCEPT_ID to 0. +Otherwise, map the units to a CONCEPT_ID. Remember that units are +case-sensitive in vocabulary. integer @@ -6116,12 +6118,13 @@ CONCEPT unit_source_value -This field houses the verbatim value from the source data representing -the unit of the Measurement that occurred. +This field contains the exact value from the source data that represents +the unit of measurement used. -This code is mapped to a Standard Condition Concept in the Standardized -Vocabularies and the original code is stored here for reference. +This value corresponds to a standardized CONCEPT_ID found in +UNIT_CONCEPT_ID and in the ‘Unit’ domain within the Standardized +Vocabularies. The original code is retained here for reference purposes. 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.

+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.

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.

ETL Conventions

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 -The date of the Observation. Depending on what the Observation -represents this could be the date of a lab test, the date of a survey, -or the date a patient’s family history was taken. +The date of when the Observation was obtained. Depending on what the +Observation represents this could be the date of a lab test, the date of +a survey, or the date a patient’s family history was taken. For some observations the ETL may need to make a choice as to which date @@ -7243,7 +7254,8 @@ cause_source_concept_id 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. integer @@ -9250,11 +9262,12 @@ delivery is practiced (offices, wards, hospitals, clinics, etc.).

User Guide

NA

ETL Conventions

-

Care site is a unique combination of location_id and -place_of_service_source_value. Care site does not take into account the -provider (human) information such a specialty. Many source data do not -make a distinction between individual and institutional providers. The -CARE_SITE table contains the institutional providers. If the source, +

Care site is a unique combination of location_id and nature of the +site - the latter could be the place of service, name, or another +characteristic in your source data. Care site does not take into account +the provider (human) information such a specialty. Many source data do +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