mz-health/OMOP
mz-health
/
OMOP
mirror of https://github.com/OHDSI/CommonDataModel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

measurement_source_value 

closes #647
This commit is contained in:
Clair Blacketer 2024-04-17 20:42:37 -04:00
parent b4d156c3c5
commit f114b8d5fd
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
inst/csv/OMOP_CDMv5.3_Field_Level.csv
View File

@ -157,7 +157,7 @@ measurement,provider_id,No,integer,"The provider associated with measurement rec
measurement,visit_occurrence_id,No,integer,The visit during which the Measurement occurred.,"Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates.",No,Yes,VISIT_OCCURRENCE,VISIT_OCCURRENCE_ID,NA,NA,NA measurement,visit_occurrence_id,No,integer,The visit during which the Measurement occurred.,"Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates.",No,Yes,VISIT_OCCURRENCE,VISIT_OCCURRENCE_ID,NA,NA,NA
measurement,visit_detail_id,No,integer,"The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.",Same rules apply as for the VISIT_OCCURRENCE_ID.,No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,NA,NA,NA measurement,visit_detail_id,No,integer,"The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.",Same rules apply as for the VISIT_OCCURRENCE_ID.,No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,NA,NA,NA
measurement,measurement_source_value,No,varchar(50),This field contains the exact value from the source data that represents the measurement that occurred.,This value corresponds to a standardized CONCEPT_ID found in MEASUREMENT_CONCEPT_ID and in the 'Measurement' domain within the Standardized Vocabularies. The original code is retained here for reference purposes.,No,No,NA,NA,NA,NA,NA measurement,measurement_source_value,No,varchar(50),This field contains the exact value from the source data that represents the measurement that occurred.,This value corresponds to a standardized CONCEPT_ID found in MEASUREMENT_CONCEPT_ID and in the 'Measurement' domain within the Standardized Vocabularies. The original code is retained here for reference purposes.,No,No,NA,NA,NA,NA,NA
measurement,measurement_source_concept_id,No,integer,"This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.",If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA measurement,measurement_source_concept_id,No,integer,"This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.","If the MEASUREMENT_SOURCE_VALUE is coded in the source data using a vocabulary supported by OMOP Standardized Vocabularies, insert the CONCEPT_ID representing the source value here.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
measurement,unit_source_value,No,varchar(50),This field contains the exact value from the source data that represents the unit of measurement used.,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.,No,No,NA,NA,NA,NA,NA measurement,unit_source_value,No,varchar(50),This field contains the exact value from the source data that represents the unit of measurement used.,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.,No,No,NA,NA,NA,NA,NA
measurement,value_source_value,No,varchar(50),This field houses the verbatim result value of the Measurement from the source data .,"If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here.",No,No,NA,NA,NA,NA,NA measurement,value_source_value,No,varchar(50),This field houses the verbatim result value of the Measurement from the source data .,"If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here.",No,No,NA,NA,NA,NA,NA
observation,observation_id,Yes,integer,The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled.,Each instance of an observation present in the source data should be assigned this unique key.,Yes,No,NA,NA,NA,NA,NA observation,observation_id,Yes,integer,The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled.,Each instance of an observation present in the source data should be assigned this unique key.,Yes,No,NA,NA,NA,NA,NA

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
157 observation value_as_concept_id No Integer It is possible that some records destined for the Observation table have two clinical ideas represented in one source code. This is common with ICD10 codes that describe a family history of some Condition, for example. In OMOP the Vocabulary breaks these two clinical ideas into two codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the VALUE_AS_CONCEPT_ID. It is important when using the Observation table to keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID field for relevant information. Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the 'Maps to' record contains a second record with the relationship_id set to 'Maps to value'. For example, ICD10 [Z82.4](https://athena.ohdsi.org/search-terms/terms/45581076) 'Family history of ischaemic heart disease and other diseases of the circulatory system' has a 'Maps to' relationship to [4167217](https://athena.ohdsi.org/search-terms/terms/4167217) 'Family history of clinical finding' as well as a 'Maps to value' record to [134057](https://athena.ohdsi.org/search-terms/terms/134057) 'Disorder of cardiovascular system'. If there's no categorial result in a source_data, set value_as_concept_id to NULL, if there is a categorial result in a source_data but without mapping, set value_as_concept_id to 0. No Yes CONCEPT CONCEPT_ID NA NA NA
158 observation qualifier_concept_id No integer This field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc. Use your best judgement as to what Concepts to use here and if they are necessary to accurately represent the clinical record. There is no restriction on the domain of these Concepts, they just need to be Standard. No Yes CONCEPT CONCEPT_ID NA NA NA
159 observation unit_concept_id No integer There is currently no recommended unit for individual observation concepts. 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. There is no standardization requirement for units associated with OBSERVATION_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. No Yes CONCEPT CONCEPT_ID Unit NA NA
160 observation provider_id No integer The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record. No Yes PROVIDER PROVIDER_ID NA NA NA
161 observation visit_occurrence_id No integer The visit during which the Observation occurred. Depending on the structure of the source data, this may have to be determined based on dates. If an OBSERVATION_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the observation record. If an observation is related to a visit explicitly in the source data, it is possible that the result date of the Observation falls outside of the bounds of the Visit dates. No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
162 observation visit_detail_id No integer The VISIT_DETAIL record during which the Observation occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. Same rules apply as for the VISIT_OCCURRENCE_ID. No Yes VISIT_DETAIL VISIT_DETAIL_ID NA NA NA
163 observation observation_source_value No varchar(50) This field houses the verbatim value from the source data representing the Observation that occurred. For example, this could be an ICD10 or Read code. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference. No No NA NA NA NA NA

2
inst/csv/OMOP_CDMv5.4_Field_Level.csv
View File

@ -163,7 +163,7 @@ measurement,provider_id,No,integer,"The provider associated with measurement rec
measurement,visit_occurrence_id,No,integer,The visit during which the Measurement occurred.,"Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates.",No,Yes,VISIT_OCCURRENCE,VISIT_OCCURRENCE_ID,NA,NA,NA measurement,visit_occurrence_id,No,integer,The visit during which the Measurement occurred.,"Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates.",No,Yes,VISIT_OCCURRENCE,VISIT_OCCURRENCE_ID,NA,NA,NA
measurement,visit_detail_id,No,integer,"The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.",Same rules apply as for the VISIT_OCCURRENCE_ID.,No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,NA,NA,NA measurement,visit_detail_id,No,integer,"The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit.",Same rules apply as for the VISIT_OCCURRENCE_ID.,No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,NA,NA,NA
measurement,measurement_source_value,No,varchar(50),This field contains the exact value from the source data that represents the measurement that occurred.,This value corresponds to a standardized CONCEPT_ID found in MEASUREMENT_CONCEPT_ID and in the 'Measurement' domain within the Standardized Vocabularies. The original code is retained here for reference purposes.,No,No,NA,NA,NA,NA,NA measurement,measurement_source_value,No,varchar(50),This field contains the exact value from the source data that represents the measurement that occurred.,This value corresponds to a standardized CONCEPT_ID found in MEASUREMENT_CONCEPT_ID and in the 'Measurement' domain within the Standardized Vocabularies. The original code is retained here for reference purposes.,No,No,NA,NA,NA,NA,NA
measurement,measurement_source_concept_id,No,integer,"This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.",If the MEASUREMENT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA measurement,measurement_source_concept_id,No,integer,"This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.","If the MEASUREMENT_SOURCE_VALUE is coded in the source data using a vocabulary supported by OMOP Standardized Vocabularies, insert the CONCEPT_ID representing the source value here.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
measurement,unit_source_value,No,varchar(50),This field contains the exact value from the source data that represents the unit of measurement used.,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.,No,No,NA,NA,NA,NA,NA measurement,unit_source_value,No,varchar(50),This field contains the exact value from the source data that represents the unit of measurement used.,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.,No,No,NA,NA,NA,NA,NA
measurement,unit_source_concept_id,No,integer,"""This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using UNIT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.""",If the UNIT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA measurement,unit_source_concept_id,No,integer,"""This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using UNIT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.""",If the UNIT_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
measurement,value_source_value,No,varchar(50),This field houses the verbatim result value of the Measurement from the source data .,"If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here.",No,No,NA,NA,NA,NA,NA measurement,value_source_value,No,varchar(50),This field houses the verbatim result value of the Measurement from the source data .,"If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here.",No,No,NA,NA,NA,NA,NA

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
163 observation observation_type_concept_id Yes integer This field can be used to determine the provenance of the Observation record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources. Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
164 observation value_as_number No float This is the numerical value of the Result of the Observation, if applicable and available. It is not expected that all Observations will have numeric results, rather, this field is here to house values should they exist. NA No No NA NA NA NA NA
165 observation value_as_string No varchar(60) This is the categorical value of the Result of the Observation, if applicable and available. NA No No NA NA NA NA NA
166 observation value_as_concept_id No Integer It is possible that some records destined for the Observation table have two clinical ideas represented in one source code. This is common with ICD10 codes that describe a family history of some Condition, for example. In OMOP the Vocabulary breaks these two clinical ideas into two codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the VALUE_AS_CONCEPT_ID. It is important when using the Observation table to keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID field for relevant information. Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the 'Maps to' record contains a second record with the relationship_id set to 'Maps to value'. For example, ICD10 [Z82.4](https://athena.ohdsi.org/search-terms/terms/45581076) 'Family history of ischaemic heart disease and other diseases of the circulatory system' has a 'Maps to' relationship to [4167217](https://athena.ohdsi.org/search-terms/terms/4167217) 'Family history of clinical finding' as well as a 'Maps to value' record to [134057](https://athena.ohdsi.org/search-terms/terms/134057) 'Disorder of cardiovascular system'. If there's no categorial result in a source_data, set value_as_concept_id to NULL, if there is a categorial result in a source_data but without mapping, set value_as_concept_id to 0. No Yes CONCEPT CONCEPT_ID NA NA NA
167 observation qualifier_concept_id No integer This field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc. Use your best judgement as to what Concepts to use here and if they are necessary to accurately represent the clinical record. There is no restriction on the domain of these Concepts, they just need to be Standard. No Yes CONCEPT CONCEPT_ID NA NA NA
168 observation unit_concept_id No integer There is currently no recommended unit for individual observation concepts. 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. There is no standardization requirement for units associated with OBSERVATION_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. No Yes CONCEPT CONCEPT_ID Unit NA NA
169 observation provider_id No integer The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record. No Yes PROVIDER PROVIDER_ID NA NA NA