https://w3id.org/omop/ontology/Observation
The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here. **New to CDM v6.0** An Observation can now be linked to other records in the CDM instance using the fields OBSERVATION_EVENT_ID and OBS_EVENT_FIELD_CONCEPT_ID. To link another record to an Observation, the primary key goes in OBSERVATION_EVENT_ID (CONDITION_OCCURRENCE_ID, DRUG_EXPOSURE_ID, etc.) and the Concept representing the field where the OBSERVATION_EVENT_ID was taken from go in the OBS_EVENT_FIELD_CONCEPT_ID. For example, a CONDITION_OCCURRENCE of Asthma might be linked to an Observation of a family history of Asthma. In this case the CONDITION_OCCURRENCE_ID of the Asthma record would go in OBSERVATION_EVENT_ID of the family history record and the CONCEPT_ID [1147127](https://athena.ohdsi.org/search-terms/terms/1147127) would go in OBS_EVENT_FIELD_CONCEPT_ID to denote that the OBSERVATION_EVENT_ID represents a CONDITION_OCCURRENCE_ID.
Instances of Observation can have the following properties:
| PROPERTY | TYPE | DESCRIPTION | RANGE |
|---|---|---|---|
| From class Observation | |||
| Qualifier source value | owl:DatatypeProperty | For Observation: This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. | string |
| Value as datetime | owl:DatatypeProperty | For Observation: It is possible that some Observation records might store a result as a date value. | dateTime |
| Has obs event field | owl:FunctionalProperty | For Observation: If the Observation 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 OBSERVATION_EVENT_ID came from. | Concept |
| Has qualifier | owl:FunctionalProperty | For Observation: 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. | Concept |
| From class Event | |||
| Date | owl:DatatypeProperty | For Procedure Occurrence: Use this date to determine the date the procedure occurred. If a procedure lasts more than a day, then it should be recorded as a separate record for each day the procedure occurred, this logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM. - For Note Nlp: The date of the note processing. - For Observation: 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. For some observations the ETL may need to make a choice as to which date to choose. - For Note: The date the note was recorded. - For Specimen: The date the specimen was collected. - 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. | date |
| Datetime | owl:DatatypeProperty | For Note Nlp: The date and time of the note processing. - 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 Procedure Occurrence: 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 Observation: If no time is given set to midnight (00:00:00). - For Note: If time is not given set the time to midnight. | dateTime |
| From class OMOP CDM thing | |||
| Id | owl:DatatypeProperty | For Note: A unique identifier for each note. - For Vocabulary: A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. - 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 Note Nlp: A unique identifier for the NLP record. - 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 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. - For Specimen: Unique identifier for each specimen. - 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 Cohort Definition: This is the identifier given to the cohort, usually by the ATLAS application - For Concept Class: A unique key for each class. - 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 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 Cost: A unique identifier for each COST record. - For Domain: A unique key for each domain. - For Survey Conduct: Unique identifier for each completed survey. For each instance of a survey completion create a unique identifier. - 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 Care Site: Assign an id to each unique combination of location_id and place_of_service_source_value. - For Concept: A unique identifier for each Concept across all domains. - 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 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 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 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 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 Payer Plan Period: A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. | 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:Observation a owl:Class ;
rdfs:label "Observation"^^xsd:string ;
rdfs:comment "The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here. **New to CDM v6.0** An Observation can now be linked to other records in the CDM instance using the fields OBSERVATION_EVENT_ID and OBS_EVENT_FIELD_CONCEPT_ID. To link another record to an Observation, the primary key goes in OBSERVATION_EVENT_ID (CONDITION_OCCURRENCE_ID, DRUG_EXPOSURE_ID, etc.) and the Concept representing the field where the OBSERVATION_EVENT_ID was taken from go in the OBS_EVENT_FIELD_CONCEPT_ID. For example, a CONDITION_OCCURRENCE of Asthma might be linked to an Observation of a family history of Asthma. In this case the CONDITION_OCCURRENCE_ID of the Asthma record would go in OBSERVATION_EVENT_ID of the family history record and the CONCEPT_ID [1147127](https://athena.ohdsi.org/search-terms/terms/1147127) would go in OBS_EVENT_FIELD_CONCEPT_ID to denote that the OBSERVATION_EVENT_ID represents a CONDITION_OCCURRENCE_ID."@en ;
rdfs:subClassOf [ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_concept ],
[ a owl:Restriction ;
owl:onProperty omop:has_concept ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_type ],
[ a owl:Restriction ;
owl:onProperty omop:has_type ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_source ],
[ a owl:Restriction ;
owl:onProperty omop:has_source ;
owl:someValuesFrom omop:Concept ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:decimal ;
owl:onProperty omop:value_as_number ],
[ 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_unit ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:unit_source_value ],
[ a owl:Restriction ;
owl:onProperty [ owl:inverseOf omop:has_observation ] ;
owl:someValuesFrom omop:Person ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:value_as_string ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_qualifier ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:qualifier_source_value ],
[ a owl:Restriction ;
owl:allValuesFrom owl:Thing ;
owl:onProperty omop:has_event ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Concept ;
owl:onProperty omop:has_obs_event_field ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:dateTime ;
owl:onProperty omop:value_as_datetime ],
[ a owl:Restriction ;
owl:allValuesFrom omop:Provider ;
owl:onProperty omop:has_provider ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:source_value ],
omop:Event ;
omop:omop_cdm_name "observation"^^xsd:string .