rendered docs
This commit is contained in:
Clair Blacketer
parent
880d0b6eeb
commit
f65047daaa
|
|
@ -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,
|
||||
store the concept_id here.
|
||||
If the source data codes asigned sex at birth in a non-standard
|
||||
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
|
||||
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. <a
|
||||
Concept and are recorded in the following order of precedence:
|
||||
<d2>Marketed Product<d3>, <d2>Branded Pack<d3>, <d2>Clinical Pack<d3>,
|
||||
<d2>Branded Drug<d3>, <d2>Clinical Drug<d3>, <d2>Branded Drug
|
||||
Component<d3>, <d2>Clinical Drug Component<d3>, <d2>Branded Drug
|
||||
Form<d3>, <d2>Clinical Drug Form<d3>, and only if no other information
|
||||
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&standardConcept=Standard&page=1&pageSize=15&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
|
||||
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 <d2>Measurement<d3>
|
||||
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,
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;">
|
||||
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.
|
||||
</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
|
||||
the unit of the Measurement that occurred.
|
||||
This field contains the exact value from the source data that represents
|
||||
the unit of measurement used.
|
||||
</td>
|
||||
<td style="text-align:left;">
|
||||
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.
|
||||
</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
|
||||
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.
|
||||
</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
|
||||
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,
|
||||
<p>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
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
store the concept_id here.
|
||||
If the source data codes assigned sex at birth in a non-standard
|
||||
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
|
||||
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. <a
|
||||
Concept and are recorded in the following order of precedence:
|
||||
<d2>Marketed Product<d3>, <d2>Branded Pack<d3>, <d2>Clinical Pack<d3>,
|
||||
<d2>Branded Drug<d3>, <d2>Clinical Drug<d3>, <d2>Branded Drug
|
||||
Component<d3>, <d2>Clinical Drug Component<d3>, <d2>Branded Drug
|
||||
Form<d3>, <d2>Clinical Drug Form<d3>, and only if no other information
|
||||
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&standardConcept=Standard&page=1&pageSize=15&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
|
||||
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 <d2>Measurement<d3>
|
||||
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,
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;">
|
||||
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.
|
||||
</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
|
||||
the unit of the Measurement that occurred.
|
||||
This field contains the exact value from the source data that represents
|
||||
the unit of measurement used.
|
||||
</td>
|
||||
<td style="text-align:left;">
|
||||
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.
|
||||
</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
|
||||
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.
|
||||
</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
|
||||
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,
|
||||
<p>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
|
||||
|
|
|
|||
Loading…
Reference in New Issue