https://w3id.org/omop/ontology/Exposure
Instances of Exposure can have the following properties:
| PROPERTY | TYPE | DESCRIPTION | RANGE |
|---|---|---|---|
| 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 Date duration | |||
| End date | owl:DatatypeProperty | For Visit Occurrence: For inpatient visits the end date is typically the discharge date. Visit end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them: Outpatient Visit: visit_end_datetime = visit_start_datetime Emergency Room Visit: visit_end_datetime = visit_start_datetime Inpatient Visit: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. Non-hospital institution Visits: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs. For Inpatient Visits ongoing at the date of ETL, put date of processing the data into visit_end_datetime and visit_type_concept_id with 32220 "Still patient" to identify the visit as incomplete. All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date. - For Device Exposure: The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if given. Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable. - For Condition Occurrence: Use this date to determine the end date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. - For Visit Detail: This the end date of the patient-provider interaction. Visit Detail end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them:<br> - Outpatient Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Emergency Room Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Inpatient Visit Detail: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visit Details: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs.<br> For Inpatient Visit Details ongoing at the date of ETL, put date of processing the data into visit_detai_end_datetime and visit_detail_type_concept_id with 32220 "Still patient" to identify the visit as incomplete. All other Visits Details: visit_detail_end_datetime = visit_detail_start_datetime. - For Payer Plan Period: End date of Plan coverage. - For Location History: The date the relationship ended - For Drug Exposure: The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient. If this information is not explicitly available in the data, infer the end date using the following methods:/n/n 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. [Examples by dose form](https://ohdsi.github.io/CommonDataModel/drug_dose.html) - For Observation Period: Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded. It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. | date |
| Start date | owl:DatatypeProperty | For Location History: The date the relationship started - For Visit Detail: This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with. When populating visit_start_date, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction. - For Drug Exposure: Use this date to determine the start date of the drug record. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration was recorded. It is a valid ETL choice to use the date the drug was ordered as the DRUG_EXPOSURE_START_DATE. - For Device Exposure: Use this date to determine the start date of the device record. Valid entries include a start date of a procedure to implant a device, the date of a prescription for a device, or the date of device administration. - For Condition Occurrence: Use this date to determine the start date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. - For Payer Plan Period: Start date of Plan coverage. - For Observation Period: Use this date to determine the start date of the Observation Period It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm60.html#payer_plan_period). - For Visit Occurrence: For inpatient visits, the start date is typically the admission date. For outpatient visits the start date and end date will be the same. When populating visit_start_date, you should think about the patient experience to make decisions on how to define visits. In the case of an inpatient visit this should be the date the patient was admitted to the hospital or institution. In all other cases this should be the date of the patient-provider interaction. | date |
| From class Datetime duration | |||
| End datetime | owl:DatatypeProperty | For Visit Detail: If no time is given for the end date of a visit, set it to midnight (00:00:0000). - For Dose Era: The date the Person was no longer exposed to the dosage of the specific drug ingredient. An era is ended if there are 31 days or more between dosage records. - For Drug Exposure: 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 Drug Era: The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era. - For Device Exposure: If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) - For Condition Era: The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition. - For Visit Occurrence: If no time is given for the end date of a visit, set it to midnight (00:00:0000). - For Condition Occurrence: If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) | dateTime |
| Start datetime | owl:DatatypeProperty | For Drug Exposure: 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 Dose Era: The date the Person started on the specific dosage, with at least 31 days since any prior exposure. - For Condition Era: The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition with at least 31 days since any prior record of the same Condition. - For Device Exposure: 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 Visit Occurrence: If no time is given for the start date of a visit, set it to midnight (00:00:0000). - For Condition Occurrence: If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) - For Visit Detail: If no time is given for the start date of a visit, set it to midnight (00:00:0000). - For Drug Era: The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure. | dateTime |
| 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:Exposure a owl:Class ;
rdfs:label "Exposure"^^xsd:string ;
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 omop:Provider ;
owl:onProperty omop:has_provider ],
[ a owl:Restriction ;
owl:allValuesFrom xsd:string ;
owl:onProperty omop:source_value ],
omop:ClinicalElement,
omop:DateDuration,
omop:DatetimeDuration .