https://w3id.org/omop/ontology/Measurement
The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person's sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured.
Instances of Measurement can have the following properties:
| PROPERTY | TYPE | DESCRIPTION | RANGE |
|---|---|---|---|
| From class Measurement | |||
| Range high | owl:DatatypeProperty | For Measurement: Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given. If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided. | decimal |
| Range low | owl:DatatypeProperty | For Measurement: Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and should remain NULL if not given. If reference ranges for upper and lower limit of normal as provided (typically by a laboratory) these are stored in the RANGE_HIGH and RANGE_LOW fields. This should be set to NULL if not provided. | decimal |
| Time | owl:DatatypeProperty | For Measurement: This is present for backwards compatibility and will be deprecated in an upcoming version. | string |
| Has meas event field | owl:FunctionalProperty | For Measurement: If the Measurement record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from. Put the CONCEPT_ID that identifies which table and field the MEASUREMENT_EVENT_ID came from. | Concept |
| Has operator | owl:FunctionalProperty | For Measurement: The meaning of Concept [4172703](https://athena.ohdsi.org/search-terms/terms/4172703) for '=' is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it's important when devising analyses to not to forget testing for the content of this field for values different from =. Operators are <, <=, =, >=, > and these concepts belong to the 'Meas Value Operator' domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&standardConcept=Standard&page=1&pageSize=15&query=). The operator_concept_id explictly refers to the value of the measurement. Leave it NULL if there's an exact numeric value given (instead of putting '=') or there's no numeric value at all. | Concept |
| From class Event | |||
| Date | owl:DatatypeProperty | For Specimen: The date the specimen was collected. - For Note Nlp: The date of the note processing. - For Measurement: Use this date to determine the date of the measurement. If there are multiple dates in the source data associated with a record such as order_date, draw_date, and result_date, choose the one that is closest to the date the sample was drawn from the patient. - For Observation: 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 to choose. - For Death: The date the person was deceased. If the precise date include day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day. For additional conventions related to this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_death_date.html). - For Procedure Occurrence: Use this date to determine the date the procedure started. This is meant to be the **start date** of the procedure. It will be renamed in a future version to **PROCEDURE_START_DATE**. - For Note: The date the note was recorded. | date |
| Datetime | owl:DatatypeProperty | For Observation: If no time is given set to midnight (00:00:00). - For Measurement: This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) - For Death: If you have date and time of death, populate death_datetime, otherwise leave NULL - For Procedure Occurrence: If the procedure has a start time in the native date, use this field to house that information. This will be renamed in a future version to **PROCEDURE_START_DATETIME**. - For Note Nlp: The date and time of the note processing. - For Note: If time is not given set the time to midnight. | dateTime |
| From class OMOP CDM thing | |||
| Id | owl:DatatypeProperty | For Cohort Definition: This is the identifier given to the cohort, usually by the ATLAS application - For Procedure Occurrence: The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled. Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. - For Vocabulary: A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. - For Device Exposure: The unique key given to records a person's exposure to a foreign physical object or instrument. Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key. - For Condition Occurrence: The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled. Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. - For Note Nlp: A unique identifier for the NLP record. - For Payer Plan Period: A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. - For Visit Detail: Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. - For Visit Occurrence: Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. - For Concept Class: A unique key for each class. - For Measurement: The unique key given to a Measurement record for a Person. Refer to the ETL for how duplicate Measurements during the same Visit were handled. Each instance of a measurement present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same measurement within the same visit. It is valid to keep these duplicates and assign them individual, unique, MEASUREMENT_IDs, though it is up to the ETL how they should be handled. - For Observation: 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. - For Concept: A unique identifier for each Concept across all domains. - For Specimen: Unique identifier for each specimen. - For Domain: A unique key for each domain. - For Provider: It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently. This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number. - For Observation Period: A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id. Assign a unique observation_period_id to each discrete Observation Period for a Person. - For Note: A unique identifier for each note. - For Location: The unique key given to a unique Location. Each instance of a Location in the source data should be assigned this unique key. - For Metadata: The unique key given to a Metadata record. Attribute value is auto-generated - For Relationship: The type of relationship captured by the relationship record. - For Care Site: Assign an ID to each combination of a location and nature of the site - the latter could be the Place of Service, name or another characteristic in your source data. - For Person: It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently. Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number. - For Drug Exposure: The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled. Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled. | owl:Thing |
| From class Thing | |||
| OMOP CDM name | owl:AnnotationProperty | owl:Thing | |
@prefix omop: <https://w3id.org/omop/ontology/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
omop:Measurement a owl:Class ;
rdfs:label "Measurement"^^xsd:string ;
rdfs:comment "The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person's sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID). The Procedure for obtaining the sample is housed in the PROCEDURE_OCCURRENCE table, though it is unnecessary to create a PROCEDURE_OCCURRENCE record for each measurement if one does not exist in the source data. Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result. If there is no result, it is assumed that the lab test was conducted but the result was not captured."@en ;
rdfs:subClassOf [ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_type ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:decimal ;
owl:onProperty omop:range_low ],
[ a owl:Restriction ;
owl:onProperty omop:has_concept ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_meas_event_field ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:value_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:decimal ;
owl:onProperty omop:value_as_number ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_operator ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_unit ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_value_as_concept ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_source ],
[ a owl:Restriction ;
owl:onProperty [ owl:inverseOf omop:has_measurement ] ;
owl:someValuesFrom omop:Person ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_unit_source ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:time ],
[ a owl:Restriction ;
owl:allValuesFrom owl:Thing ;
owl:onProperty omop:has_event ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Provider ;
owl:onProperty omop:has_provider ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:decimal ;
owl:onProperty omop:range_high ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:unit_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:source_value ],
[ a owl:Restriction ;
owl:onProperty omop:has_type ;
owl:someValuesFrom omop:Concept ],
omop:Event,
omop:Occurrence ;
omop:omop_cdm_name "measurement"^^xsd:string .