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

death, device, drug, condition wiki files

This commit is contained in:
Clair Blacketer 2018-09-06 15:53:06 -04:00
parent 2ff3b82dd1
commit a078310b73
4 changed files with 96 additions and 84 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md
View File

@ -1,41 +1,45 @@
Conditions are records of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign or a symptom, which is either observed by a Provider or reported by the patient. Conditions are recorded in different sources and levels of standardization, for example:
Conditions are records of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient. Conditions are recorded in different sources and levels of standardization, for example:
* Medical claims data include diagnoses coded in ICD-9-CM that are submitted as part of a reimbursement claim for health services and
* EHRs may capture Person Conditions in the form of diagnosis codes or symptoms.
* Medical claims data include diagnoses coded in Source Vocabularies such as ICD-9-CM that are submitted as part of a reimbursement claim for health services
* EHRs may capture Person conditions in the form of diagnosis codes or symptoms
Field|Required|Type|Description
:--------------------------------|:--------|:------------|:------------------------------------------------------------
| condition_occurrence_id | Yes | integer | A unique identifier for each Condition Occurrence event. |
| person_id | Yes | integer | A foreign key identifier to the Person who is experiencing the condition. The demographic details of that Person are stored in the PERSON table. |
| condition_concept_id | Yes | integer | A foreign key that refers to a Standard Condition Concept identifier in the Standardized Vocabularies. |
| condition_start_date | Yes | date | The date when the instance of the Condition is recorded. |
| condition_start_datetime | No | datetime | The date and time when the instance of the Condition is recorded. |
| condition_occurrence_id | Yes | bigint | A unique identifier for each Condition Occurrence event. |
| person_id | Yes | bigint | A foreign key identifier to the Person who is experiencing the condition. The demographic details of that Person are stored in the PERSON table. |
| condition_concept_id | Yes | integer | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies belonging to the 'Condition' domain. |
| condition_start_date | No | date | The date when the instance of the Condition is recorded. |
| condition_start_datetime | Yes | datetime | The date and time when the instance of the Condition is recorded. |
| condition_end_date | No | date | The date when the instance of the Condition is considered to have ended. |
| condition_end_datetime | No | datetime | The date when the instance of the Condition is considered to have ended. |
| condition_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the condition was recorded, the level of standardization, and the type of occurrence. |
| stop_reason | No | varchar(20) | The reason that the condition was no longer present, as indicated in the source data. |
| condition_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the Condition was recorded, the level of standardization, and the type of occurrence. |
| condition_status_concept_id | No | integer | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies reflecting the point of care at which the Condition was diagnosed. |
| stop_reason | No | varchar(20) | The reason that the Condition was no longer present, as indicated in the source data. |
| provider_id | No | integer | A foreign key to the Provider in the PROVIDER table who was responsible for capturing (diagnosing) the Condition. |
| visit_occurrence_id | No | integer | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Condition was determined (diagnosed). |
| visit_detail_id | No | integer | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed). |
| condition_source_value | No | varchar(50) | The source code for the condition as it appears in the source data. This code is mapped to a standard condition concept in the Standardized Vocabularies and the original code is stored here for reference. |
| condition_source_value | No | varchar(50) | The source code for the Condition as it appears in the source data. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. |
| condition_source_concept_id | No | integer | A foreign key to a Condition Concept that refers to the code used in the source. |
| condition_status_source_value | No | varchar(50) | The source code for the condition status as it appears in the source data. |
| condition_status_concept_id | No | integer | A foreign key to the predefined Concept in the Standard Vocabulary reflecting the condition status |
| condition_status_source_value | No | varchar(50) | The source code for the condition status as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference. |
### Conventions
* Valid Condition Concepts belong to the "Condition" domain.
* Condition records are typically inferred from diagnostic codes recorded in the source data. Such code system, like ICD-9-CM, ICD-10-CM, Read etc., provide a comprehensive coverage of conditions. However, if the diagnostic code in the source does not define a condition, but rather an observation or a procedure, then such information is not stored in the CONDITION_OCCURRENCE table, but in the respective tables instead.
* Source Condition identifiers are mapped to Standard Concepts for Conditions in the Standardized Vocabularies. When the source code cannot be translated into a Standard Concept, a CONDITION_OCCURRENCE entry is stored with only the corresponding source_concept_id and source_value, while the condition_concept_id is set to 0.
* Family history and past diagnoses ("history of") are not recorded in the CONDITION_OCCURRENCE table. Instead, they are listed in the OBSERVATION table.
* Codes written in the process of establishing the diagnosis, such as "question of" of and "rule out", are not represented here. Instead, they are listed in the OBSERVATION table, if they are used for analyses.
* A Condition Occurrence Type is assigned based on the data source and type of condition attribute, for example:
* ICD-9-CM Primary Diagnosis from inpatient and outpatient Claims
* ICD-9-CM Secondary Diagnoses from inpatient and outpatient Claims
No.|Convention Description
:--------|:------------------------------------
| 1 | Valid Condition Concepts belong to the 'Condition' domain.
| 2 | Condition records are typically inferred from diagnostic codes recorded in the source data. Such code systems, like ICD-9-CM, ICD-10-CM, Read etc., provide a comprehensive coverage of conditions. However, if the diagnostic code in the source does not define a condition, but rather an observation or a procedure, then such information is not stored in the CONDITION_OCCURRENCE table, but in the respective tables indicated by the domain.
| 3 | Source Condition identifiers are mapped to Standard Concepts for Conditions in the Standardized Vocabularies. When the source code cannot be translated into a Standard Concept, a CONDITION_OCCURRENCE entry is stored with only the corresponding SOURCE_CONCEPT_ID and SOURCE_VALUE, while the CONDITION_CONCEPT_ID is set to 0.
| 4 | Family history and past diagnoses ('history of') are not recorded in the CONDITION_OCCURRENCE table. Instead, they are listed in the OBSERVATION table.
| 4 | Codes written in the process of establishing the diagnosis, such as 'question of' of and 'rule out', are not represented here. Instead, they are listed in the OBSERVATION table, if they are used for analyses.
| 5 | A Condition Occurrence Type is assigned based on the data source and type of condition attribute, for example:
* ICD-9-CM Primary Diagnosis from inpatient and outpatient claims
* ICD-9-CM Secondary Diagnoses from inpatient and outpatient claims
* Diagnoses or problems recorded in an EHR.
* The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Typical values include "Discharged", "Resolved", etc. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.
* Condition source codes are typically ICD-9-CM, Read or ICD-10 diagnosis codes from medical claims or discharge status/visit diagnosis codes from EHRs.
* Presently, there is no designated vocabulary, domain, or class that represents condition status. The following concepts from SNOMED are recommended:
| 6 | Valid Condition Occurrence Type Concepts belong to the 'Condition Type' vocabulary in the 'Type Concept' domain.
| 7 | The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Typical values include 'Discharged', 'Resolved', etc. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.
| 8 | Condition source codes are typically ICD-9-CM, Read or ICD-10-CM diagnosis codes from medical claims or discharge status/visit diagnosis codes from EHRs.
| 9 | Presently, there is no designated vocabulary, domain, or class that represents condition status. The following concepts from SNOMED are recommended:
* Admitting diagnosis: 4203942
* Final diagnosis: 4230359 (should also be used for discharge diagnosis)
* Preliminary diagnosis: 4033240

22
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/DEATH.md
View File

@ -1,4 +1,4 @@
The death domain contains the clinical event for how and when a Person dies. A person can have up to one record if the source system contains evidence about the Death, such as:
The 'Death' domain contains the clinical event for how and when a Person dies. A Person can have up to one record if the source system contains evidence about the Death, such as:
* Condition Code in the Header or Detail information of claims
* Status of enrollment into a health plan
@ -6,16 +6,16 @@ The death domain contains the clinical event for how and when a Person dies. A p
Field|Required|Type|Description
:-------------------------|:--------|:-----|:----------------------------------------------
|person_id|Yes|integer|A foreign key identifier to the deceased person. The demographic details of that person are stored in the person table.|
|death_date |Yes|date|The date the person was deceased. If the precise date including 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.|
|death_datetime |No|datetime|The date and time the person was deceased. If the precise date including 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.|
|death_type_concept_id|Yes|integer|A foreign key referring to the predefined concept identifier in the Standardized Vocabularies reflecting how the death was represented in the source data.|
|cause_concept_id|No|integer|A foreign key referring to a standard concept identifier in the Standardized Vocabularies for conditions.|
|cause_source_value|No|varchar(50)|The source code for the cause of death as it appears in the source data. This code is mapped to a standard concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|cause_source_concept_id|No|integer|A foreign key to the concept that refers to the code used in the source. Note, this variable name is abbreviated to ensure it will be allowable across database platforms.|
| person_id | Yes | bigint | A foreign key identifier to the deceased Person. The demographic details of that Person are stored in the PERSON table. |
| death_date | No | date | The date the Person was deceased. If the precise date including 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. |
| death_datetime | Yes | datetime | The date and time the Person was deceased. If the precise date including day or month is not known or not allowed, December is used as the default month, the last day of the month the default day, and midnight the default time.|
| death_type_concept_id | Yes | integer | A foreign key referring to the predefined Concept identifier in the Standardized Vocabularies reflecting how the Death was represented in the source data. |
| cause_concept_id | No | integer | A foreign key referring to a Standard Concept identifier in the Standardized Vocabularies belonging to the 'Condition" domain. |
| cause_source_value | No | varchar(50)| The source code for the cause of death as it appears in the source data. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.|
| cause_source_concept_id | No | integer | A foreign key to the Concept that refers to the code used in the source. Note, this variable name is abbreviated to ensure it will be allowable across database platforms. |
### Conventions
* Living patients should not contain any information in the DEATH table.
* Each Person may have more than one record of death in the source data. It is the task of the ETL to pick the most plausible or most accurate records to be aggregated and stored as a single record in the DEATH table.
* If the Death Date cannot be precisely determined from the data, the best approximation should be used.
* Valid Concepts for the cause_concept_id have domain_id='Condition'.
* Each Person may have more than one record of death in the source data. If a patient has clinical activity (e.g. prescriptions filled, labs performed, etc) more than 60+ days after death the ETL may want to drop the death record as it may have been falsely reported. If multiple records of death exist on multiple days the ETL may select the death that is deemed most reliable (e.g. death at discharge) or is latest.
* If the Death Datetime cannot be precisely determined from the data, the best approximation should be used.
* Valid Concepts for the CAUSE_CONCEPT_ID have domain_id='Condition'.

50
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/DEVICE_EXPOSURE.md
View File

@ -1,29 +1,35 @@
The device exposure domain captures information about a person's exposure to a foreign physical object or instrument that which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).
The 'Device' domain captures information about a person's exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).
Field|Required|Type|Description
:--------------------------------|:--------|:------------|:--------------------------------------------
|device_exposure_id|Yes|integer|A system-generated unique identifier for each Device Exposure.|
|person_id|Yes|integer|A foreign key identifier to the Person who is subjected to the Device. The demographic details of that person are stored in the Person table.|
|device_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the Device concept.|
|device_exposure_start_date|Yes|date|The date the Device or supply was applied or used.|
|device_exposure_start_datetime|No|datetime|The date and time the Device or supply was applied or used.|
|device_exposure_end_date|No|date|The date the Device or supply was removed from use.|
|device_exposure_end_datetime|No|datetime|The date and time the Device or supply was removed from use.|
|device_type_concept_id|Yes|integer|A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Device Exposure recorded. It indicates how the Device Exposure was represented in the source data.|
|unique_device_id |No|varchar(50)|A UDI or equivalent identifying the instance of the Device used in the Person.|
|quantity|No|integer|The number of individual Devices used for the exposure.|
|provider_id|No|integer|A foreign key to the provider in the PROVIDER table who initiated of administered the Device.|
|visit_occurrence_id|No|integer|A foreign key to the visit in the VISIT_OCCURRENCE table during which the device was used.|
|visit_detail_id|No|integer|A foreign key to the visit detail in the VISIT_DETAIL table during which the Drug Exposure was initiated.|
|device_source_value|No|varchar(50)|The source code for the Device as it appears in the source data. This code is mapped to a standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.|
|device_source_concept_id|No|integer|A foreign key to a Device Concept that refers to the code used in the source.|
| device_exposure_id | Yes | bigint | A system-generated unique identifier for each Device Exposure. |
| person_id | Yes | bigint | A foreign key identifier to the Person who is subjected to the Device. The demographic details of that Person are stored in the PERSON table. |
| device_concept_id | Yes | integer | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies belonging to the 'Device' domain. |
| device_exposure_start_date | Yes | date | The date the Device or supply was applied or used. |
| device_exposure_start_datetime| No | datetime | The date and time the Device or supply was applied or used. |
| device_exposure_end_date | No | date | The date use of the Device or supply was ceased. |
| device_exposure_end_datetime | No | datetime | The date and time use of the Device or supply was ceased. |
| device_type_concept_id | Yes | integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Device Exposure recorded. It indicates how the Device Exposure was represented in the source data.|
| unique_device_id | No | varchar(50)| A UDI or equivalent identifying the instance of the Device used in the Person. |
| quantity | No | integer | The number of individual Devices used in the exposure. |
| provider_id | No | integer | A foreign key to the provider in the PROVIDER table who initiated or administered the Device. |
| visit_occurrence_id | No | integer | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Device was used. |
| visit_detail_id | No | integer | A foreign key to the visit detail record in the VISIT_DETAIL table during which the Device was used. |
| device_source_value | No | varchar(50)| The source code for the Device as it appears in the source data. This code is mapped to a Standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.|
| device_source_concept_id | No | integer | A foreign key to a Device Concept that refers to the code used in the source.|
### Conventions
* The distinction between Devices or supplies and procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.
* For medical devices that are regulated by the FDA, if a Unique Device Identification (UDI) is provided if available in the data source, and is recorded in the unique_device_id field.
* Valid Device Concepts belong to the "Device" domain. The Concepts of this domain are derived from the DI portion of a UDI or based on other source vocabularies, like HCPCS.
* A Device Type is assigned to each Device Exposure to track from what source the information was drawn or inferred. The valid domain_id for these Concepts is "Device Type".
* The Visit during which the Device was first used is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
* The Visit Detail during which the Device was first used is recorded through a reference to the VISIT_DETAIL table. This information is not always available.
* The Provider exposing the patient to the Device is recorded through a reference to the PROVIDER table. This information is not always available.
* For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field.
* Valid Device Concepts belong to the 'Device' domain. The Concepts of this domain are derived from the DI portion of a UDI or based on other source vocabularies, like HCPCS.
* A Device Type is assigned to each Device Exposure to track from what source the information was drawn or inferred. The valid vocabulary for these Concepts is 'Device Type'.
* The Visit during which the Device was first used is recorded through a reference to the VISIT_OCCURRENCE table.
* The Visit Detail during which the Device was first used is recorded through a reference to the VISIT_DETAIL table.
* The Provider exposing the patient to the Device is recorded through a reference to the PROVIDER table.
* When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are:
* Same Device
* Same DEVICE_EXPOSURE_START_DATETIME
* Same Visit Occurrence or Visit Detail
* Same Provider
* If a Device Exposure has a quantity of '0' in the source, this should default to '1' in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once.

56
Documentation/CommonDataModel_Wiki_Files/StandardizedClinicalDataTables/DRUG_EXPOSURE.md
View File

@ -1,41 +1,41 @@
The drug exposure domain captures records about the utilization of a Drug when ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain physiological effect. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.
The 'Drug' domain captures records about the utilization of a Drug when ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain physiological effect. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.
Drug Exposure is inferred from clinical events associated with orders, prescriptions written, pharmacy dispensings, procedural administrations, and other patient-reported information, for example:
* The "Prescription" section of an EHR captures prescriptions written by physicians or from electronic ordering systems
* The "Medication list" section of an EHR for both non-prescription products and medications prescribed by other providers
* The 'Prescription' section of an EHR captures prescriptions written by physicians or from electronic ordering systems
* The 'Medication list' section of an EHR for both non-prescription products and medications prescribed by other providers
* Prescriptions filled at dispensing providers such as pharmacies, and then captured in reimbursement claim systems
* Drugs administered as part of a Procedure, such as chemotherapy or vaccines.
Field|Required|Type|Description
:------------------------------|:--------|:------------|:------------------------------------------------
|drug_exposure_id|Yes|integer|A system-generated unique identifier for each Drug utilization event.|
|person_id|Yes|integer|A foreign key identifier to the person who is subjected to the Drug. The demographic details of that person are stored in the person table.|
|drug_concept_id|Yes|integer|A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the Drug concept.|
|drug_exposure_start_date|Yes|date|The start date for the current instance of Drug utilization. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration procedure was recorded.|
|drug_exposure_start_datetime|No|datetime|The start date and time for the current instance of Drug utilization. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration procedure was recorded.|
|drug_exposure_end_date|Yes|date|The end date for the current instance of Drug utilization. It is not available from all sources.|
|drug_exposure_end_datetime|No|datetime|The end date and time for the current instance of Drug utilization. It is not available from all sources.|
|verbatim_end_date|No|date|The known end date of a drug_exposure as provided by the source|
|drug_type_concept_id|Yes|integer| A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Drug Exposure recorded. It indicates how the Drug Exposure was represented in the source data.|
|stop_reason|No|varchar(20)|The reason the Drug was stopped. Reasons include regimen completed, changed, removed, etc.|
|refills|No|integer|The number of refills after the initial prescription. The initial prescription is not counted, values start with null.|
|quantity |No|float|The quantity of drug as recorded in the original prescription or dispensing record.|
|days_supply|No|integer|The number of days of supply of the medication as recorded in the original prescription or dispensing record.|
|sig|No|varchar(MAX)|The directions ("signetur") on the Drug prescription as recorded in the original prescription (and printed on the container) or dispensing record.|
|route_concept_id|No|integer|A foreign key to a predefined concept in the Standardized Vocabularies reflecting the route of administration.|
|lot_number|No|varchar(50)|An identifier assigned to a particular quantity or lot of Drug product from the manufacturer.|
|provider_id|No|integer|A foreign key to the provider in the PROVIDER table who initiated (prescribed or administered) the Drug Exposure.|
|visit_occurrence_id|No|integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Drug Exposure was initiated.|
|visit_detail_id|No|integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Drug Exposure was initiated.|
|drug_source_value|No|varchar(50)|The source code for the Drug as it appears in the source data. This code is mapped to a Standard Drug concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|drug_source_concept_id|No|integer|A foreign key to a Drug Concept that refers to the code used in the source.|
|route_source_value|No|varchar(50)|The information about the route of administration as detailed in the source.|
|dose_unit_source_value|No|varchar(50)|The information about the dose unit as detailed in the source.|
| drug_exposure_id | Yes | bigint | A system-generated unique identifier for each Drug utilization event. |
|person_id |Yes |bigint |A foreign key identifier to the Person who is subjected to the Drug. The demographic details of that Person are stored in the PERSON table. |
|drug_concept_id |Yes |integer |A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies belonging to the 'Drug' domain. |
|drug_exposure_start_date |No |date |The start date for the current instance of Drug utilization. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration procedure was recorded.|
|drug_exposure_start_datetime |Yes |datetime |The start date and time for the current instance of Drug utilization. Valid entries include a start datetime of a prescription, the date and time a prescription was filled, or the date and time on which a Drug administration procedure was recorded.|
|drug_exposure_end_date |No |date |The end date for the current instance of Drug utilization. Depending on different sources, it could be a known or an inferred date and denotes the last day at which the patient was still exposed to Drug. |
|drug_exposure_end_datetime |No |datetime |The end date and time for the current instance of Drug utilization. Depending on different sources, it could be a known or an inferred date and time and denotes the last day at which the patient was still exposed to Drug. |
|verbatim_end_date |No |date |The known end date of a drug_exposure as provided by the source. |
|drug_type_concept_id |Yes |integer | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Drug Exposure recorded. It indicates how the Drug Exposure was represented in the source data.|
|stop_reason |No |varchar(20)|The reason the Drug was stopped. Reasons include regimen completed, changed, removed, etc. |
|refills |No |integer |The number of refills after the initial prescription. The initial prescription is not counted, values start with null. |
|quantity |No |float |The quantity of drug as recorded in the original prescription or dispensing record. |
|days_supply |No |integer |The number of days of supply of the medication as prescribed. This reflects the intention of the provider for the length of exposure. |
|sig |No |varchar(MAX)|The directions ("signetur") on the Drug prescription as recorded in the original prescription (and printed on the container) or dispensing record. |
|route_concept_id |No |integer |A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies reflecting the route of administration and belonging to the 'Route' domain. |
|lot_number |No |varchar(50)|An identifier assigned to a particular quantity or lot of Drug product from the manufacturer. |
|provider_id |No |integer|A foreign key to the provider in the PROVIDER table who initiated (prescribed or administered) the Drug Exposure.|
|visit_occurrence_id |No |integer|A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Drug Exposure was initiated.|
|visit_detail_id |No |integer|A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Drug Exposure was initiated.|
|drug_source_value |No |varchar(50)|The source code for the Drug as it appears in the source data. This code is mapped to a Standard Drug concept in the Standardized Vocabularies and the original code is, stored here for reference.|
|drug_source_concept_id |No |integer|A foreign key to a Drug Concept that refers to the code used in the source.|
|route_source_value |No |varchar(50)|The information about the route of administration as detailed in the source.|
|dose_unit_source_value |No |varchar(50)|The information about the dose unit as detailed in the source.|
### Conventions
* Valid Concepts for the drug_concept_id field belong to the "Drug" domain. Most Concepts in the Drug domain are based on RxNorm, but some may come from other sources. Concepts are members of the Clinical Drug or Pack, Branded Drug or Pack, Drug Component or Ingredient classes.
* Valid Concepts for the DRUG_CONCEPT_ID field belong to the 'Drug' domain. Most Concepts in the Drug domain are based on RxNorm, but some may come from other sources. Concepts are members of the Clinical Drug or Pack, Branded Drug or Pack, Drug Component or Ingredient classes.
* Source drug identifiers, including NDC codes, Generic Product Identifiers, etc. are mapped to Standard Drug Concepts in the Standardized Vocabularies (e.g., based on RxNorm). When the Drug Source Value of the code cannot be translated into standard Drug Concept IDs, a Drug exposure 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 should contain 0.
* A Drug Type is assigned to each Drug Exposure to track from what source the information was drawn or inferred from. The valid concept_class_id for these Concepts is "Drug Type".
@ -45,3 +45,5 @@ Field|Required|Type|Description
* If possible, the visit in which the drug was prescribed or delivered is recorded in the visit_occurrence_id field through a reference to the visit table.
* If possible, the prescribing or administering provider (physician or nurse) is recorded in the provider_id field through a reference to the provider table.
* The drug_exposure_end_date denotes the day the drug exposure ended for the patient. This could be that the duration of drug_supply was reached (in which case drug_exposure_end_date = drug_exposure_start_date + days_supply -1), or because the exposure was stopped (medication changed, medication discontinued, etc.)
* Valid Condition Occurrence Type Concepts belong to the 'Condition Type' vocabulary in the 'Type Concept' domain.