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

Added article on how to download the ddls.

This commit is contained in:
clairblacketer 2020-10-16 15:26:46 -04:00
parent 32d0cb9a0a
commit ccea723163
5 changed files with 130 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -1,7 +1,7 @@
Common Data Model v6.0 Common Data Model v6.0
================= =================
See full CDM specification file on our github [wiki](https://github.com/OHDSI/CommonDataModel/wiki) or in the [CDM V6.0 PDF](https://github.com/OHDSI/CommonDataModel/blob/master/OMOP_CDM_v6_0.pdf) See full CDM specifications on our [website](https://ohdsi.github.io/CommonDataModel/index.html).
Release Notes for v6.0 Release Notes for v6.0

139
docs/cdm531.html
View File

@ -474,8 +474,8 @@ div.tocify {
</div> </div>
<div id="cdm-v5.3.1" class="section level1"> <div id="omop-cdm-v5.3.1" class="section level1">
<h1><strong>CDM v5.3.1</strong></h1> <h1><strong>OMOP CDM v5.3.1</strong></h1>
<p>Below is the specification document for the OMOP Common Data Model, v5.3.1. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p> <p>Below is the specification document for the OMOP Common Data Model, v5.3.1. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p>
<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p> <p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p>
<div id="clinical-data-tables" class="section level2"> <div id="clinical-data-tables" class="section level2">
@ -748,7 +748,7 @@ location_id
The location refers to the physical address of the person. This field should capture the last known location of the person. The location refers to the physical address of the person. This field should capture the last known location of the person.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Put the location_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a> table here that represents the most granular location information for the person. This could represent anything from postal code or parts thereof, state, or county for example. Since many databases contain deindentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location. Put the location_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a> table here that represents the most granular location information for the person. This could represent anything from postal code or parts thereof, state, or county for example. Since many databases contain deidentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -1025,7 +1025,7 @@ CONCEPT
<p><strong>User Guide</strong></p> <p><strong>User Guide</strong></p>
<p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p> <p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p>
<p><strong>ETL Conventions</strong></p> <p><strong>ETL Conventions</strong></p>
<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should be represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrolment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p> <p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrollment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;"> <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
<thead> <thead>
<tr> <tr>
@ -1208,7 +1208,7 @@ Type Concept
<ul> <ul>
<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER follwed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER followed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li>
@ -1696,7 +1696,7 @@ No
preceding_visit_occurrence_id preceding_visit_occurrence_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Use this field to find the visit that occured for the person prior to the given visit. There could be a few days or a few years in between. Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a “following_visit_id”. This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
@ -1962,7 +1962,7 @@ Use this field to understand the provenance of the visit detail record, or where
Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Integer integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -2182,7 +2182,7 @@ Use this field to determine where the patient was discharged to after a visit de
If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Integer integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -2205,13 +2205,13 @@ Visit
preceding_visit_detail_id preceding_visit_detail_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Use this field to find the visit detail that occured for the person prior to the given visit detail record. There could be a few days or a few years in between. Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a “following_visit_id”. The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Integer integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -2239,7 +2239,7 @@ Use this field to find the visit detail that subsumes the given visit detail rec
If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship. If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Integer integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -2267,7 +2267,7 @@ Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE.
Put the VISIT_OCCURRENCE_ID that subsumes the VISIT_DETAIL record here. Put the VISIT_OCCURRENCE_ID that subsumes the VISIT_DETAIL record here.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Integer integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -2292,7 +2292,7 @@ VISIT_OCCURRENCE
<p><strong>Table Description</strong></p> <p><strong>Table Description</strong></p>
<p>This table contains records of Events 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.</p> <p>This table contains records of Events 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.</p>
<p><strong>User Guide</strong></p> <p><strong>User Guide</strong></p>
<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype defintions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p> <p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
<p><strong>ETL Conventions</strong></p> <p><strong>ETL Conventions</strong></p>
<p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p> <p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p>
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;"> <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
@ -2638,7 +2638,7 @@ visit_occurrence_id
The visit during which the condition occurred. The visit during which the condition occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record. Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_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 CONDITION_OCCURRENCE record.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -2778,7 +2778,7 @@ No
<p><strong>User Guide</strong></p> <p><strong>User Guide</strong></p>
<p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p> <p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p>
<p><strong>ETL Conventions</strong></p> <p><strong>ETL Conventions</strong></p>
<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs adminstered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p> <p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;"> <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
<thead> <thead>
<tr> <tr>
@ -2823,7 +2823,7 @@ The unique key given to records of drug dispensings or administrations for a per
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. 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.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -2849,7 +2849,7 @@ The PERSON_ID of the PERSON for whom the drug dispensing or administration is re
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -2956,7 +2956,7 @@ drug_exposure_end_date
The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient. The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 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) /concentation (20mg/mL) 200*5/20 = 50 days. SHOW EXAMPLES BY DOSE FORM If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 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. <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples by dose form</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
date date
@ -3117,7 +3117,7 @@ quantity
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the drug_strength table the quantity should be converted to the correct unit given in drug_strength. Clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similiar to clinical drugs. To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is ‘Has dose form’. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to calculate drug dose</a> for more information.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
float float
@ -3253,7 +3253,7 @@ The Provider associated with drug record, e.g. the provider who wrote the presc
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 ordering vs administering physician on an EHR record. 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 ordering vs administering physician on an EHR record.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -3281,7 +3281,7 @@ The Visit during which the drug was prescribed, administered or dispensed.
To populate this field drug exposures must be explicitly initiated in the visit. To populate this field drug exposures must be explicitly initiated in the visit.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -3309,7 +3309,7 @@ The VISIT_DETAIL record during which the drug exposure occurred. For example, if
Same rules apply as for the VISIT_OCCURRENCE_ID. Same rules apply as for the VISIT_OCCURRENCE_ID.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -3735,7 +3735,7 @@ visit_occurrence_id
The visit during which the procedure occurred. The visit during which the procedure occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record. Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_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 PROCEDURE_OCCURRENCE record.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -3919,7 +3919,7 @@ The unique key given to records a person’s exposure to a foreign physical obje
Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key. Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -3944,7 +3944,7 @@ person_id
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -4188,7 +4188,7 @@ The Provider associated with device record, e.g. the provider who wrote the pre
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. 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.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -4216,7 +4216,7 @@ The Visit during which the device was prescribed or given.
To populate this field device exposures must be explicitly initiated in the visit. To populate this field device exposures must be explicitly initiated in the visit.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -4244,7 +4244,7 @@ The Visit Detail during which the device was prescribed or given.
To populate this field device exposures must be explicitly initiated in the visit detail record. To populate this field device exposures must be explicitly initiated in the visit detail record.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -4753,7 +4753,7 @@ visit_occurrence_id
The visit during which the Measurement occurred. The visit during which the Measurement occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
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 explictly 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. 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.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -5016,7 +5016,7 @@ observation_concept_id
The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domans MUST go to the corresponding table. The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -5291,7 +5291,7 @@ visit_occurrence_id
The visit during which the Observation occurred. The visit during which the Observation occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
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 explictly 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. 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.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -5868,7 +5868,7 @@ note_class_concept_id
A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note. A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">Accepte Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note). Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -5976,7 +5976,7 @@ language_concept_id
The language of the note. The language of the note.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Use Concepts that are decendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages). Use Concepts that are descendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6149,6 +6149,7 @@ FK Domain
note_nlp_id note_nlp_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
A unique identifier for the NLP record.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6174,6 +6175,7 @@ No
note_id note_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is the NOTE_ID for the NOTE record the NLP record is associated to.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6201,6 +6203,7 @@ section_concept_id
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship ‘Subsumes’ to CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6225,6 +6228,7 @@ CONCEPT
snippet snippet
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
A small window of text surrounding the term
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6250,6 +6254,7 @@ No
offset offset
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Character offset of the extracted term in the input note
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6275,6 +6280,7 @@ No
lexical_variant lexical_variant
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Raw text extracted from the NLP tool.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6354,6 +6360,7 @@ nlp_system
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Name and version of the NLP system that extracted the term. Useful for data provenance.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(250) varchar(250)
@ -6377,6 +6384,7 @@ No
nlp_date nlp_date
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The date of the note processing.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6402,6 +6410,7 @@ No
nlp_datetime nlp_datetime
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The date and time of the note processing.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6455,7 +6464,7 @@ term_temporal
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Term_temporal is to indicate if a condition is <EFBFBD>present<EFBFBD> or just in the <EFBFBD>past<EFBFBD>. The following would be past: History = true Concept_date = anything before the time of the report Term_temporal is to indicate if a condition is present or just in the past. The following would be past:<br><br> - History = true - Concept_date = anything before the time of the report
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(50) varchar(50)
@ -6481,7 +6490,7 @@ term_modifiers
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
For the modifiers that are there, they would have to have these values: Negation = false Subject = patient Conditional = false Rule_out = false Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers. A list of allowable modifiers (e.g., signature for medications) and their possible values will be standardized later. For the modifiers that are there, they would have to have these values:<br><br> - Negation = false - Subject = patient - Conditional = false - Rule_out = false - Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(2000) varchar(2000)
@ -6547,6 +6556,7 @@ FK Domain
specimen_id specimen_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Unique identifier for each specimen.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6572,6 +6582,7 @@ No
person_id person_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The person from whom the specimen is collected.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6600,6 +6611,7 @@ specimen_concept_id
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6626,6 +6638,7 @@ specimen_type_concept_id
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Put the source of the specimen record, as in an EHR system. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6651,6 +6664,7 @@ Type Concept
specimen_date specimen_date
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The date the specimen was collected.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6701,6 +6715,7 @@ No
quantity quantity
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The amount of specimen collected from the person.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6726,8 +6741,10 @@ No
unit_concept_id unit_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The unit for the quantity of the specimen.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6752,8 +6769,10 @@ CONCEPT
anatomic_site_concept_id anatomic_site_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is the site on the body where the specimen is from.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec Anatomic Site domain. This should be coded at the lowest level of granularity <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted Concepts</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6804,6 +6823,7 @@ CONCEPT
specimen_source_id specimen_source_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is the identifier for the specimen from the source system.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6856,6 +6876,7 @@ unit_source_value
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
This unit for the quantity of the specimen, as represented in the source.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(50) varchar(50)
@ -6881,6 +6902,7 @@ anatomic_site_source_value
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
This is the site on the body where the specimen was taken from, as represented in the source.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(50) varchar(50)
@ -7862,7 +7884,7 @@ No
specialty_source_concept_id specialty_source_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is often zero as many sites use propietary codes to store physician speciality. This is often zero as many sites use proprietary codes to store physician speciality.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here. If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.
@ -7917,7 +7939,7 @@ No
gender_source_concept_id gender_source_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is often zero as many sites use propietary codes to store provider gender. This is often zero as many sites use proprietary codes to store provider gender.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here. If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here.
@ -8497,7 +8519,7 @@ cost_id
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
INTEGER integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -8522,7 +8544,7 @@ cost_event_id
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
INTEGER integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -8547,7 +8569,7 @@ cost_domain_id
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
VARCHAR(20) varchar(20)
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes Yes
@ -8625,7 +8647,7 @@ total_charge
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8650,7 +8672,7 @@ total_cost
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8675,7 +8697,7 @@ total_paid
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8700,7 +8722,7 @@ paid_by_payer
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8725,7 +8747,7 @@ paid_by_patient
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8750,7 +8772,7 @@ paid_patient_copay
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8759,10 +8781,9 @@ No
No No
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes No
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
CONCEPT
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
</td> </td>
@ -8776,7 +8797,7 @@ paid_patient_coinsurance
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8801,7 +8822,7 @@ paid_patient_deductible
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8826,7 +8847,7 @@ paid_by_primary
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8851,7 +8872,7 @@ paid_ingredient_cost
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8876,7 +8897,7 @@ paid_dispensing_fee
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8901,7 +8922,7 @@ payer_plan_period_id
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
INTEGER integer
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8926,7 +8947,7 @@ amount_allowed
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
FLOAT float
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -8978,7 +8999,7 @@ Revenue codes are a method to charge for a class of procedures and conditions in
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
VARCHAR(50) varchar(50)
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -9030,7 +9051,7 @@ Diagnosis Related Groups are US codes used to classify hospital cases into one o
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
VARCHAR(3) varchar(3)
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
No No
@ -10404,7 +10425,7 @@ CONCEPT_CLASS
standard_concept standard_concept
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowables values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL. This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -12132,7 +12153,7 @@ CONCEPT
box_size box_size
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The number of units of Clinical Branded Drug or Quanitified Clinical or Branded Drug contained in a box as dispensed to the patient. The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>

BIN
docs/cdm531.pdf Normal file
View File

Binary file not shown.

73
docs/cdm60.html
View File

@ -474,8 +474,8 @@ div.tocify {
</div> </div>
<div id="cdm-v6.0" class="section level1"> <div id="omop-cdm-v6.0" class="section level1">
<h1><strong>CDM v6.0</strong></h1> <h1><strong>OMOP CDM v6.0</strong></h1>
<p>Below is the specification document for the OMOP Common Data Model, v6.0. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p> <p>Below is the specification document for the OMOP Common Data Model, v6.0. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p>
<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p> <p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p>
<div id="changes-in-v6.0" class="section level2"> <div id="changes-in-v6.0" class="section level2">
@ -785,7 +785,7 @@ location_id
The location refers to the physical address of the person. This field should capture the last known location of the person. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table. The location refers to the physical address of the person. This field should capture the last known location of the person. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Put the location_id from the LOCATION table here that represents the most granular location information for the person. This could represent anything from postal code or parts thereof, state, or county for example. Since many databases contain deindentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table. Put the location_id from the LOCATION table here that represents the most granular location information for the person. This could represent anything from postal code or parts thereof, state, or county for example. Since many databases contain deidentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint bigint
@ -1062,7 +1062,7 @@ CONCEPT
<p><strong>User Guide</strong></p> <p><strong>User Guide</strong></p>
<p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p> <p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p>
<p><strong>ETL Conventions</strong></p> <p><strong>ETL Conventions</strong></p>
<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should be represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrolment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p> <p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrollment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;"> <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
<thead> <thead>
<tr> <tr>
@ -1245,7 +1245,7 @@ Type Concept
<ul> <ul>
<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER follwed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER followed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li>
<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li> <li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li>
@ -1733,7 +1733,7 @@ No
preceding_visit_occurrence_id preceding_visit_occurrence_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Use this field to find the visit that occured for the person prior to the given visit. There could be a few days or a few years in between. Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The preceding_visit_id can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a “following_visit_id”. The preceding_visit_id can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
@ -2242,7 +2242,7 @@ Visit
preceding_visit_detail_id preceding_visit_detail_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Use this field to find the visit detail that occured for the person prior to the given visit detail record. There could be a few days or a few years in between. Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a “following_visit_id”. The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a “following_visit_id”.
@ -2329,7 +2329,7 @@ VISIT_OCCURRENCE
<p><strong>Table Description</strong></p> <p><strong>Table Description</strong></p>
<p>This table contains records of Events 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.</p> <p>This table contains records of Events 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.</p>
<p><strong>User Guide</strong></p> <p><strong>User Guide</strong></p>
<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype defintions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p> <p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
<p><strong>ETL Conventions</strong></p> <p><strong>ETL Conventions</strong></p>
<p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p> <p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p>
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;"> <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
@ -2674,7 +2674,7 @@ visit_occurrence_id
The visit during which the condition occurred. The visit during which the condition occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record. Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_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 CONDITION_OCCURRENCE record.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint bigint
@ -2814,7 +2814,7 @@ No
<p><strong>User Guide</strong></p> <p><strong>User Guide</strong></p>
<p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p> <p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p>
<p><strong>ETL Conventions</strong></p> <p><strong>ETL Conventions</strong></p>
<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs adminstered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p> <p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;"> <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
<thead> <thead>
<tr> <tr>
@ -2992,7 +2992,7 @@ drug_exposure_end_date
The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient. The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
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) /concentation (20mg/mL) 200*5/20 = 50 days. SHOW EXAMPLES BY DOSE FORM 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. <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples by dose form</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
date date
@ -3153,7 +3153,7 @@ quantity
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the drug_strength table the quantity should be converted to the correct unit given in drug_strength. Clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similiar to clinical drugs. To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is ‘Has dose form’. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to calculate drug dose</a> for more information.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
float float
@ -3771,7 +3771,7 @@ visit_occurrence_id
The visit during which the procedure occurred. The visit during which the procedure occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record. Depending on the structure of the source data, this may have to be determined based on dates. If a PROCEDURE_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 PROCEDURE_OCCURRENCE record.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint bigint
@ -4789,7 +4789,7 @@ visit_occurrence_id
The visit during which the Measurement occurred. The visit during which the Measurement occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
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 explictly 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. 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.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint bigint
@ -5052,7 +5052,7 @@ observation_concept_id
The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domans MUST go to the corresponding table. The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -5327,7 +5327,7 @@ visit_occurrence_id
The visit during which the Observation occurred. The visit during which the Observation occurred.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
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 explictly 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. 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.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
bigint bigint
@ -5756,7 +5756,7 @@ note_class_concept_id
A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note. A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">Accepte Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note). Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;conceptClass=Doc+Kind&amp;conceptClass=Doc+Role&amp;conceptClass=Doc+Setting&amp;conceptClass=Doc+Subject+Matter&amp;conceptClass=Doc+Type+of+Service&amp;domain=Meas+Value&amp;page=1&amp;pageSize=15&amp;query=">AcceptedConcepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -5864,7 +5864,7 @@ language_concept_id
The language of the note. The language of the note.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Use Concepts that are decendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages). Use Concepts that are descendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6037,6 +6037,7 @@ FK Domain
note_nlp_id note_nlp_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
A unique identifier for the NLP record.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6062,6 +6063,7 @@ No
note_id note_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is the NOTE_ID for the NOTE record the NLP record is associated to.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6089,6 +6091,7 @@ section_concept_id
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship ‘Subsumes’ to CONCEPT_ID <a href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6113,6 +6116,7 @@ CONCEPT
snippet snippet
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
A small window of text surrounding the term
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6138,6 +6142,7 @@ No
offset offset
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Character offset of the extracted term in the input note
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6163,6 +6168,7 @@ No
lexical_variant lexical_variant
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Raw text extracted from the NLP tool.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6242,6 +6248,7 @@ nlp_system
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Name and version of the NLP system that extracted the term. Useful for data provenance.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(250) varchar(250)
@ -6265,6 +6272,7 @@ No
nlp_date nlp_date
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The date of the note processing.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6290,6 +6298,7 @@ No
nlp_datetime nlp_datetime
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The date and time of the note processing.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6343,7 +6352,7 @@ term_temporal
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Term_temporal is to indicate if a condition ispresent or just in the past. The following would be past: History = true Concept_date = anything before the time of the report Term_temporal is to indicate if a condition is present or just in the past. The following would be past:&lt;br&gt;&lt;br&gt; - History = true - Concept_date = anything before the time of the report
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(50) varchar(50)
@ -6369,7 +6378,7 @@ term_modifiers
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
For the modifiers that are there, they would have to have these values: Negation = false Subject = patient Conditional = false Rule_out = false Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers. A list of allowable modifiers (e.g., signature for medications) and their possible values will be standardized later. For the modifiers that are there, they would have to have these values:&lt;br&gt;&lt;br&gt; - Negation = false - Subject = patient - Conditional = false - Rule_out = false - Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(2000) varchar(2000)
@ -6435,6 +6444,7 @@ FK Domain
specimen_id specimen_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
Unique identifier for each specimen.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6460,6 +6470,7 @@ No
person_id person_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The person from whom the specimen is collected.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6488,6 +6499,7 @@ specimen_concept_id
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6514,6 +6526,7 @@ specimen_type_concept_id
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Put the source of the specimen record, as in an EHR system. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6539,6 +6552,7 @@ Type Concept
specimen_date specimen_date
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The date the specimen was collected.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6589,6 +6603,7 @@ No
quantity quantity
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The amount of specimen collected from the person.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6614,8 +6629,10 @@ No
unit_concept_id unit_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The unit for the quantity of the specimen.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted Concepts</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6640,8 +6657,10 @@ CONCEPT
anatomic_site_concept_id anatomic_site_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is the site on the body where the specimen is from.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec Anatomic Site domain. This should be coded at the lowest level of granularity <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Spec+Anatomic+Site&amp;conceptClass=Body+Structure&amp;page=4&amp;pageSize=15&amp;query=">Accepted Concepts</a>
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
integer integer
@ -6692,6 +6711,7 @@ CONCEPT
specimen_source_id specimen_source_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is the identifier for the specimen from the source system.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -6744,6 +6764,7 @@ unit_source_value
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
This unit for the quantity of the specimen, as represented in the source.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(50) varchar(50)
@ -6769,6 +6790,7 @@ anatomic_site_source_value
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
This is the site on the body where the specimen was taken from, as represented in the source.
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
varchar(50) varchar(50)
@ -8686,7 +8708,7 @@ No
specialty_source_concept_id specialty_source_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is often zero as many sites use propietary codes to store physician speciality. This is often zero as many sites use proprietary codes to store physician speciality.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
@ -8741,7 +8763,7 @@ No
gender_source_concept_id gender_source_concept_id
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This is often zero as many sites use propietary codes to store provider gender. This is often zero as many sites use proprietary codes to store provider gender.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
@ -9690,10 +9712,9 @@ No
No No
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
Yes No
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
CONCEPT
</td> </td>
<td style="text-align:left;width: 1in; "> <td style="text-align:left;width: 1in; ">
</td> </td>
@ -11335,7 +11356,7 @@ CONCEPT_CLASS
standard_concept standard_concept
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowables values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL. This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>
@ -13058,7 +13079,7 @@ CONCEPT
box_size box_size
</td> </td>
<td style="text-align:left;width: 3in; "> <td style="text-align:left;width: 3in; ">
The number of units of Clinical Branded Drug or Quanitified Clinical or Branded Drug contained in a box as dispensed to the patient. The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.
</td> </td>
<td style="text-align:left;width: 4in; "> <td style="text-align:left;width: 4in; ">
</td> </td>

3
docs/download.html
View File

@ -475,7 +475,8 @@ div.tocify {
</div> </div>
<p>This article is currently under development. Please check back later for updates.</p> <p>All code for the ddls, constraints and indices are available on our <a href="https://github.com/OHDSI/CommonDataModel">github</a>. Each version of the Common Data Model is denoted by a <a href="https://github.com/OHDSI/CommonDataModel/tags">release</a>. The OHDSI community supports the database management systems (dbms) Sql Server, Postgresql, Oracle, Redshift, Parallel Data Warehouse, BigQuery, Impala, and Netezza. Included in each release is a folder for each dbms. After downloading, choose the folder for your specific system and you will see all necessary files. For example the Sql Server folder has the ddl, primary key constraints, indices, and foreign key constraints. In contrast, the redshift folder only has a ddl.</p>
<p>These sql scripts have been fully tested on Oracle, Sql Server, and Postgresql and the rest are generated using the <a href="https://ohdsi.github.io/SqlRender/">SqlRender package</a>. If run into any problems please let us know by creating an issue on our github.</p>