From 9ae24a61973cb9ec970a7d51227ec54d648ddd4a Mon Sep 17 00:00:00 2001 From: Clair Blacketer Date: Tue, 26 Jul 2022 12:58:15 -0400 Subject: [PATCH] Fixed broken links --- docs/background.html | 32 +- docs/cdm30.html | 32 +- docs/cdm53.html | 11878 +------------- docs/cdm531.html | 32 +- docs/cdm54.html | 12933 +--------------- docs/cdm54Changes.html | 32 +- docs/cdm60.html | 12730 +-------------- docs/cdmDecisionTree.html | 6 +- docs/cdmPrivacy.html | 32 +- docs/cdmRPackage.html | 32 +- docs/contribute.html | 32 +- docs/dataModelConventions.html | 32 +- docs/download.html | 32 +- docs/drug_dose.html | 32 +- docs/ehrObsPeriods.html | 32 +- docs/faq.html | 8 +- docs/index.html | 10 +- docs/indices-primary-foreign.html | 32 +- docs/networkUseCase.html | 469 + docs/oncology.html | 673 +- docs/queries.html | 32 +- docs/reviewProposals.html | 32 +- .../header-attrs-2.11/header-attrs.js | 12 - docs/sqlScripts.html | 10 +- docs/vocabulary.html | 32 +- rmd/.Rapp.history | 2 - rmd/cdmDecisionTree.Rmd | 6 +- rmd/networkUseCase.Rmd | 10 + rmd/oncology.Rmd | 12 +- 29 files changed, 871 insertions(+), 38368 deletions(-) create mode 100644 docs/networkUseCase.html delete mode 100644 docs/site_libs/header-attrs-2.11/header-attrs.js create mode 100644 rmd/networkUseCase.Rmd diff --git a/docs/background.html b/docs/background.html index dd2e97f..56faaba 100644 --- a/docs/background.html +++ b/docs/background.html @@ -13,7 +13,7 @@ background.knit - + @@ -63,6 +63,7 @@ if (window.hljs) { + @@ -88,6 +89,9 @@ button.code-folding-btn:focus { summary { display: list-item; } +details > summary > p:only-child { + display: inline; +} pre code { padding: 0; } @@ -312,7 +316,7 @@ div.tocify {
@@ -7985,498 +673,6 @@ CONCEPT

The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.

User Guide

A Person can have multiple, overlapping, Payer_Plan_Periods in this table. For example, medical and drug coverage in the US can be represented by two Payer_Plan_Periods. The details of the benefit structure of the Plan is rarely known, the idea is just to identify that the Plans are different.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-payer_plan_period_id - -A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. - - -integer - -Yes - -Yes - -No - - -
-person_id - -The Person covered by the Plan. - -A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records - -integer - -Yes - -No - -Yes - -PERSON - -
-payer_plan_period_start_date - -Start date of Plan coverage. - - -date - -Yes - -No - -No - - -
-payer_plan_period_end_date - -End date of Plan coverage. - - -date - -Yes - -No - -No - - -
-payer_concept_id - -This field represents the organization who reimburses the provider which administers care to the Person. - -Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-payer_source_value - -This is the Payer as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-payer_source_concept_id - - -If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -
-plan_concept_id - -This field represents the specific health benefit Plan the Person is enrolled in. - -Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-plan_source_value - -This is the health benefit Plan of the Person as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-plan_source_concept_id - - -If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -
-sponsor_concept_id - -This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan. - -Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-sponsor_source_value - -The Plan sponsor as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-sponsor_source_concept_id - - -If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -
-family_source_value - -The common identifier for all people (often a family) that covered by the same policy. - -Often these are the common digits of the enrollment id of the policy members. - -varchar(50) - -No - -No - -No - - -
-stop_reason_concept_id - -This field represents the reason the Person left the Plan, if known. - -Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-stop_reason_source_value - -The Plan stop reason as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-stop_reason_source_concept_id - - -If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -

COST

@@ -8487,598 +683,6 @@ CONCEPT

When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio.

ETL Conventions

One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cost_id - - - -integer - -Yes - -Yes - -No - - -
-cost_event_id - - - -integer - -Yes - -No - -No - - -
-cost_domain_id - - - -varchar(20) - -Yes - -No - -Yes - -DOMAIN - -
-cost_type_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-currency_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-total_charge - - - -float - -No - -No - -No - - -
-total_cost - - - -float - -No - -No - -No - - -
-total_paid - - - -float - -No - -No - -No - - -
-paid_by_payer - - - -float - -No - -No - -No - - -
-paid_by_patient - - - -float - -No - -No - -No - - -
-paid_patient_copay - - - -float - -No - -No - -No - - -
-paid_patient_coinsurance - - - -float - -No - -No - -No - - -
-paid_patient_deductible - - - -float - -No - -No - -No - - -
-paid_by_primary - - - -float - -No - -No - -No - - -
-paid_ingredient_cost - - - -float - -No - -No - -No - - -
-paid_dispensing_fee - - - -float - -No - -No - -No - - -
-payer_plan_period_id - - - -integer - -No - -No - -No - - -
-amount_allowed - - - -float - -No - -No - -No - - -
-revenue_code_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-revenue_code_source_value - -Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. - - -varchar(50) - -No - -No - -No - - -
-drg_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-drg_source_value - -Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. - - -varchar(3) - -No - -No - -No - - -
@@ -9089,223 +693,6 @@ No

A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras.

ETL Conventions

The SQL script for generating DRUG_ERA records can be found here.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-drug_era_id - - - -integer - -Yes - -Yes - -No - - -
-person_id - - - -integer - -Yes - -No - -Yes - -PERSON - -
-drug_concept_id - -The Concept Id representing the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Drug -
-drug_era_start_date - - -The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure. - -date - -Yes - -No - -No - - -
-drug_era_end_date - - -The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era. - -date - -Yes - -No - -No - - -
-drug_exposure_count - - - -integer - -No - -No - -No - - -
-gap_days - - -The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are “not stockpiled” by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling. - -integer - -No - -No - -No - - -

DOSE_ERA

@@ -9313,226 +700,6 @@ No

A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.

ETL Conventions

Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-dose_era_id - - - -integer - -Yes - -Yes - -No - - -
-person_id - - - -integer - -Yes - -No - -Yes - -PERSON - -
-drug_concept_id - -The Concept Id representing the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Drug -
-unit_concept_id - -The Concept Id representing the unit of the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Unit -
-dose_value - -The numeric value of the dosage of the drug_ingredient. - - -float - -Yes - -No - -No - - -
-dose_era_start_date - -The date the Person started on the specific dosage, with at least 31 days since any prior exposure. - - -date - -Yes - -No - -No - - -
-dose_era_end_date - - -The date the Person was no longer exposed to the dosage of the specific drug ingredient. An era is ended if there are 31 days or more between dosage records. - -date - -Yes - -No - -No - - -

CONDITION_ERA

@@ -9544,198 +711,6 @@ No

ETL Conventions

Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval. The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers. The SQl Script for generating CONDITION_ERA records can be found here The Condition Era Start Date is the start date of the first Condition Occurrence. The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-condition_era_id - - - -integer - -Yes - -Yes - -No - - -
-person_id - - - -integer - -Yes - -No - -No - -PERSON - -
-condition_concept_id - -The Concept Id representing the Condition. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Condition -
-condition_era_start_date - -The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition with at least 31 days since any prior record of the same Condition. - - -date - -Yes - -No - -No - - -
-condition_era_end_date - -The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition. - - -date - -Yes - -No - -No - - -
-condition_occurrence_count - -The number of individual Condition Occurrences used to construct the condition era. - - -integer - -No - -No - -No - - -
@@ -9744,516 +719,11 @@ No

METADATA

Table Description

The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-metadata_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-metadata_type_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-name - - - -varchar(250) - -Yes - -No - -No - - -
-value_as_string - - - -varchar(250) - -No - -No - -No - - -
-value_as_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-metadata_date - - - -date - -No - -No - -No - - -
-metadata_datetime - - - -datetime - -No - -No - -No - - -

CDM_SOURCE

Table Description

The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cdm_source_name - -The name of the CDM instance. - - -varchar(255) - -Yes - -No - -No - - -
-cdm_source_abbreviation - -The abbreviation of the CDM instance. - - -varchar(25) - -No - -No - -No - - -
-cdm_holder - -The holder of the CDM instance. - - -varchar(255) - -No - -No - -No - - -
-source_description - -The description of the CDM instance. - - -varchar(MAX) - -No - -No - -No - - -
-source_documentation_reference - - - -varchar(255) - -No - -No - -No - - -
-cdm_etl_reference - - -Put the link to the CDM version used. - -varchar(255) - -No - -No - -No - - -
-source_release_date - -The release date of the source data. - - -date - -No - -No - -No - - -
-cdm_release_date - -The release data of the CDM instance. - - -date - -No - -No - -No - - -
-cdm_version - - - -varchar(10) - -No - -No - -No - - -
-vocabulary_version - - - -varchar(20) - -No - -No - -No - - -
@@ -10264,2396 +734,62 @@ No

The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.

Concepts can represent broad categories (like ‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’) or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.).

Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id - -A unique identifier for each Concept across all domains. - - -integer - -Yes - -Yes - -No - - -
-concept_name - -An unambiguous, meaningful and descriptive name for the Concept. - - -varchar(255) - -Yes - -No - -No - - -
-domain_id - -A foreign key to the DOMAIN table the Concept belongs to. - - -varchar(20) - -Yes - -No - -Yes - -DOMAIN - -
-vocabulary_id - -A foreign key to the VOCABULARY table indicating from which source the Concept has been adapted. - - -varchar(20) - -Yes - -No - -Yes - -VOCABULARY - -
-concept_class_id - -The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. - - -varchar(20) - -Yes - -No - -Yes - -CONCEPT_CLASS - -
-standard_concept - -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. - - -varchar(1) - -No - -No - -No - - -
-concept_code - -The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies. - - -varchar(50) - -Yes - -No - -No - - -
-valid_start_date - -The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

VOCABULARY

Table Description

The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-vocabulary_id - -A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. - - -varchar(20) - -Yes - -Yes - -No - - -
-vocabulary_name - -The name describing the vocabulary, for example, International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc. - - -varchar(255) - -Yes - -No - -No - - -
-vocabulary_reference - -External reference to documentation or available download of the about the vocabulary. - - -varchar(255) - -Yes - -No - -No - - -
-vocabulary_version - -Version of the Vocabulary as indicated in the source. - - -varchar(255) - -No - -No - -No - - -
-vocabulary_concept_id - -A Concept that represents the Vocabulary the VOCABULARY record belongs to. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

DOMAIN

Table Description

The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the “Condition” Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-domain_id - -A unique key for each domain. - - -varchar(20) - -Yes - -Yes - -No - - -
-domain_name - -The name describing the Domain, e.g. Condition, Procedure, Measurement etc. - - -varchar(255) - -Yes - -No - -No - - -
-domain_concept_id - -A Concept representing the Domain Concept the DOMAIN record belongs to. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_CLASS

Table Description

The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_class_id - -A unique key for each class. - - -varchar(20) - -Yes - -Yes - -No - - -
-concept_class_name - -The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc. - - -varchar(255) - -Yes - -No - -No - - -
-concept_class_concept_id - -A Concept that represents the Concept Class. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_RELATIONSHIP

Table Description

The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id_1 - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-concept_id_2 - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-relationship_id - -The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the Vocabulary Conventions. for more information. - - -varchar(20) - -Yes - -No - -Yes - -RELATIONSHIP - -
-valid_start_date - -The date when the relationship is first recorded. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the relationship is invalidated. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the relationship was invalidated. Possible values are ‘D’ (deleted), ‘U’ (updated) or NULL. - - -varchar(1) - -No - -No - -No - - -

RELATIONSHIP

Table Description

The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-relationship_id - -The type of relationship captured by the relationship record. - - -varchar(20) - -Yes - -Yes - -No - - -
-relationship_name - - - -varchar(255) - -Yes - -No - -No - - -
-is_hierarchical - -Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not. - - -varchar(1) - -Yes - -No - -No - - -
-defines_ancestry - -Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0. - - -varchar(1) - -Yes - -No - -No - - -
-reverse_relationship_id - -The identifier for the relationship used to define the reverse relationship between two concepts. - - -varchar(20) - -Yes - -No - -No - - -
-relationship_concept_id - -A foreign key that refers to an identifier in the CONCEPT table for the unique relationship concept. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_SYNONYM

Table Description

The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-concept_synonym_name - - - -varchar(1000) - -Yes - -No - -No - - -
-language_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_ANCESTOR

Table Description

The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.

This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-ancestor_concept_id - -The Concept Id for the higher-level concept that forms the ancestor in the relationship. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-descendant_concept_id - -The Concept Id for the lower-level concept that forms the descendant in the relationship. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-min_levels_of_separation - -The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. - - -integer - -Yes - -No - -No - - -
-max_levels_of_separation - -The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. - - -integer - -Yes - -No - -No - - -

SOURCE_TO_CONCEPT_MAP

Table Description

The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-source_code - -The source code being translated into a Standard Concept. - - -varchar(50) - -Yes - -No - -No - - -
-source_concept_id - -A foreign key to the Source Concept that is being translated into a Standard Concept. - -This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-source_vocabulary_id - -A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept. - - -varchar(20) - -Yes - -No - -No - - -
-source_code_description - -An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept. - - -varchar(255) - -No - -No - -No - - -
-target_concept_id - -The target Concept to which the source code is being mapped. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-target_vocabulary_id - -The Vocabulary of the target Concept. - - -varchar(20) - -Yes - -No - -Yes - -VOCABULARY - -
-valid_start_date - -The date when the mapping instance was first recorded. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

DRUG_STRENGTH

Table Description

The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-drug_concept_id - -The Concept representing the Branded Drug or Clinical Drug Product. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-ingredient_concept_id - -The Concept representing the active ingredient contained within the drug product. - -Combination Drugs will have more than one record in this table, one for each active Ingredient. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-amount_value - -The numeric value or the amount of active ingredient contained within the drug product. - - -float - -No - -No - -No - - -
-amount_unit_concept_id - -The Concept representing the Unit of measure for the amount of active ingredient contained within the drug product. - - -integer - -No - -No - -Yes - -CONCEPT - -
-numerator_value - -The concentration of the active ingredient contained within the drug product. - - -float - -No - -No - -No - - -
-numerator_unit_concept_id - -The Concept representing the Unit of measure for the concentration of active ingredient. - - -integer - -No - -No - -Yes - -CONCEPT - -
-denominator_value - -The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.). - - -float - -No - -No - -No - - -
-denominator_unit_concept_id - -The Concept representing the denominator unit for the concentration of active ingredient. - - -integer - -No - -No - -Yes - -CONCEPT - -
-box_size - -The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient. - - -integer - -No - -No - -No - - -
-valid_start_date - -The date when the Concept was first recorded. The default value is 1-Jan-1970. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when then Concept became invalid. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

COHORT_DEFINITION

Table Description

The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cohort_definition_id - -This is the identifier given to the cohort, usually by the ATLAS application - - -integer - -Yes - -No - -No - - -
-cohort_definition_name - -A short description of the cohort - - -varchar(255) - -Yes - -No - -No - - -
-cohort_definition_description - -A complete description of the cohort. - - -varchar(MAX) - -No - -No - -No - - -
-definition_type_concept_id - -Type defining what kind of Cohort Definition the record represents and how the syntax may be executed. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-cohort_definition_syntax - -Syntax or code to operationalize the Cohort Definition. - - -varchar(MAX) - -No - -No - -No - - -
-subject_concept_id - -This field contains a Concept that represents the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit). - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-cohort_initiation_date - -A date to indicate when the Cohort was initiated in the COHORT table. - - -date - -No - -No - -No - - -

ATTRIBUTE_DEFINITION

Table Description

The ATTRIBUTE_DEFINITION table contains records to define each attribute through an associated description and syntax. Attributes are derived elements that can be selected or calculated for a subject within a cohort. The ATTRIBUTE_DEFINITION table provides a standardized structure for maintaining the rules governing the calculation of covariates for a subject in a cohort, and can store operational programming code to instantiate the attributes for a given cohort within the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-attribute_definition_id - - - -integer - -Yes - -No - -No - - -
-attribute_name - - - -varchar(255) - -Yes - -No - -No - - -
-attribute_description - - - -varchar(MAX) - -No - -No - -No - - -
-attribute_type_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-attribute_syntax - - - -varchar(MAX) - -No - -No - -No - - -
diff --git a/docs/cdm531.html b/docs/cdm531.html index 626a74f..5f57236 100644 --- a/docs/cdm531.html +++ b/docs/cdm531.html @@ -13,7 +13,7 @@ OMOP CDM v5.3.1 - + @@ -63,6 +63,7 @@ if (window.hljs) { + @@ -88,6 +89,9 @@ button.code-folding-btn:focus { summary { display: list-item; } +details > summary > p:only-child { + display: inline; +} pre code { padding: 0; } @@ -312,7 +316,7 @@ div.tocify {
@@ -8549,498 +746,6 @@ CONCEPT

The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.

User Guide

A Person can have multiple, overlapping, Payer_Plan_Periods in this table. For example, medical and drug coverage in the US can be represented by two Payer_Plan_Periods. The details of the benefit structure of the Plan is rarely known, the idea is just to identify that the Plans are different.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-payer_plan_period_id - -A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. - - -integer - -Yes - -Yes - -No - - -
-person_id - -The Person covered by the Plan. - -A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records - -integer - -Yes - -No - -Yes - -PERSON - -
-payer_plan_period_start_date - -Start date of Plan coverage. - - -date - -Yes - -No - -No - - -
-payer_plan_period_end_date - -End date of Plan coverage. - - -date - -Yes - -No - -No - - -
-payer_concept_id - -This field represents the organization who reimburses the provider which administers care to the Person. - -Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-payer_source_value - -This is the Payer as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-payer_source_concept_id - - -If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -
-plan_concept_id - -This field represents the specific health benefit Plan the Person is enrolled in. - -Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-plan_source_value - -This is the health benefit Plan of the Person as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-plan_source_concept_id - - -If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -
-sponsor_concept_id - -This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan. - -Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-sponsor_source_value - -The Plan sponsor as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-sponsor_source_concept_id - - -If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -
-family_source_value - -The common identifier for all people (often a family) that covered by the same policy. - -Often these are the common digits of the enrollment id of the policy members. - -varchar(50) - -No - -No - -No - - -
-stop_reason_concept_id - -This field represents the reason the Person left the Plan, if known. - -Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-stop_reason_source_value - -The Plan stop reason as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-stop_reason_source_concept_id - - -If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -

COST

@@ -9051,598 +756,6 @@ CONCEPT

When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio.

ETL Conventions

One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cost_id - - - -integer - -Yes - -Yes - -No - - -
-cost_event_id - - - -integer - -Yes - -No - -No - - -
-cost_domain_id - - - -varchar(20) - -Yes - -No - -Yes - -DOMAIN - -
-cost_type_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-currency_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-total_charge - - - -float - -No - -No - -No - - -
-total_cost - - - -float - -No - -No - -No - - -
-total_paid - - - -float - -No - -No - -No - - -
-paid_by_payer - - - -float - -No - -No - -No - - -
-paid_by_patient - - - -float - -No - -No - -No - - -
-paid_patient_copay - - - -float - -No - -No - -No - - -
-paid_patient_coinsurance - - - -float - -No - -No - -No - - -
-paid_patient_deductible - - - -float - -No - -No - -No - - -
-paid_by_primary - - - -float - -No - -No - -No - - -
-paid_ingredient_cost - - - -float - -No - -No - -No - - -
-paid_dispensing_fee - - - -float - -No - -No - -No - - -
-payer_plan_period_id - - - -integer - -No - -No - -No - - -
-amount_allowed - - - -float - -No - -No - -No - - -
-revenue_code_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-revenue_code_source_value - -Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. - - -varchar(50) - -No - -No - -No - - -
-drg_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-drg_source_value - -Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. - - -varchar(3) - -No - -No - -No - - -
@@ -9653,223 +766,6 @@ No

A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras.

ETL Conventions

The SQL script for generating DRUG_ERA records can be found here.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-drug_era_id - - - -integer - -Yes - -Yes - -No - - -
-person_id - - - -integer - -Yes - -No - -Yes - -PERSON - -
-drug_concept_id - -The Concept Id representing the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Drug -
-drug_era_start_date - - -The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure. - -date - -Yes - -No - -No - - -
-drug_era_end_date - - -The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era. - -date - -Yes - -No - -No - - -
-drug_exposure_count - - - -integer - -No - -No - -No - - -
-gap_days - - -The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are “not stockpiled” by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling. - -integer - -No - -No - -No - - -

DOSE_ERA

@@ -9877,226 +773,6 @@ No

A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.

ETL Conventions

Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-dose_era_id - - - -integer - -Yes - -Yes - -No - - -
-person_id - - - -integer - -Yes - -No - -Yes - -PERSON - -
-drug_concept_id - -The Concept Id representing the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Drug -
-unit_concept_id - -The Concept Id representing the unit of the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Unit -
-dose_value - -The numeric value of the dosage of the drug_ingredient. - - -float - -Yes - -No - -No - - -
-dose_era_start_date - -The date the Person started on the specific dosage, with at least 31 days since any prior exposure. - - -date - -Yes - -No - -No - - -
-dose_era_end_date - - -The date the Person was no longer exposed to the dosage of the specific drug ingredient. An era is ended if there are 31 days or more between dosage records. - -date - -Yes - -No - -No - - -

CONDITION_ERA

@@ -10108,198 +784,6 @@ No

ETL Conventions

Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval. The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers. The SQl Script for generating CONDITION_ERA records can be found here The Condition Era Start Date is the start date of the first Condition Occurrence. The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-condition_era_id - - - -integer - -Yes - -Yes - -No - - -
-person_id - - - -integer - -Yes - -No - -Yes - -PERSON - -
-condition_concept_id - -The Concept Id representing the Condition. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Condition -
-condition_era_start_date - -The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition with at least 31 days since any prior record of the same Condition. - - -date - -Yes - -No - -No - - -
-condition_era_end_date - -The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition. - - -date - -Yes - -No - -No - - -
-condition_occurrence_count - -The number of individual Condition Occurrences used to construct the condition era. - - -integer - -No - -No - -No - - -

EPISODE

@@ -10307,395 +791,6 @@ No

The EPISODE table aggregates lower-level clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases,outcomes and treatments. The EPISODE_EVENT table connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry. For example cancers including their development over time, their treatment, and final resolution.

User Guide

Valid Episode Concepts belong to the ‘Episode’ domain. For cancer episodes please see [article], for non-cancer episodes please see [article]. If your source data does not have all episodes that are relevant to the therapeutic area, write only those you can easily derive from the data. It is understood that that table is not currently expected to be comprehensive.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-episode_id - -A unique identifier for each Episode. - - -integer - -Yes - -Yes - -No - - -
-person_id - -The PERSON_ID of the PERSON for whom the episode is recorded. - - -integer - -Yes - -No - -Yes - -PERSON - -
-episode_concept_id - -The EPISODE_CONCEPT_ID represents the kind abstraction related to the disease phase, outcome or treatment. - -Choose a concept in the Episode domain that best represents the ongoing disease phase, outcome, or treatment. Please see [article] for cancers and [article] for non-cancers describing how these are defined. Accepted Concepts - -integer - -Yes - -No - -Yes - -CONCEPT - -Episode -
-episode_start_date - -The date when the Episode beings. - -Please see [article] for how to define an Episode start date. - -date - -Yes - -No - -No - - -
-episode_start_datetime - -The date and time when the Episode begins. - - -datetime - -No - -No - -No - - -
-episode_end_date - -The date when the instance of the Episode is considered to have ended. - -Please see [article] for how to define an Episode end date. - -date - -No - -No - -No - - -
-episode_end_datetime - -The date when the instance of the Episode is considered to have ended. - - -datetime - -No - -No - -No - - -
-episode_parent_id - -Use this field to find the Episode that subsumes the given Episode record. This is used in the case that an Episode are nested into each other. - -If there are multiple nested levels to how Episodes are represented, the EPISODE_PARENT_ID can be used to record this relationship. - -integer - -No - -No - -No - - -
-episode_number - -For sequences of episodes, this is used to indicate the order the episodes occurred. For example, lines of treatment could be indicated here. - -Please see [article] for the details of how to count episodes. - -integer - -No - -No - -No - - -
-episode_object_concept_id - -A Standard Concept representing the disease phase, outcome, or other abstraction of which the episode consists. For example, if the EPISODE_CONCEPT_ID is treatment regimen then the EPISODE_OBJECT_CONCEPT_ID should contain the chemotherapy regimen concept, like Afatinib monotherapy. - -Episode entries from the ‘Disease Episode’ concept class should have an episode_object_concept_id that comes from the Condition domain. Episode entries from the ‘Treatment Episode’ concept class should have an episode_object_concept_id that scome from the ‘Procedure’ domain or ‘Regimen’ concept class. - -integer - -Yes - -No - -Yes - -CONCEPT - -Procedure, Regimen -
-episode_type_concept_id - -This field can be used to determine the provenance of the Episode record, as in whether the episode was from an EHR system, insurance claim, registry, or other sources. - -Choose the EPISODE_TYPE_CONCEPT_ID that best represents the provenance of the record. Accepted Concepts. A more detailed explanation of each Type Concept can be found on the vocabulary wiki. - -integer - -Yes - -No - -Yes - -CONCEPT - -Type Concept -
-episode_source_value - -The source code for the Episdoe as it appears in the source data. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. - - -varchar(50) - -No - -No - -No - - -
-episode_source_concept_id - -A foreign key to a Episode Concept that refers to the code used in the source. - -Given that the Episodes are user-defined it is unlikely that there will be a Source Concept available. If that is the case then set this field to zero. - -integer - -No - -No - -Yes - -CONCEPT - -

EPISODE_EVENT

@@ -10705,125 +800,6 @@ CONCEPT

This connecting table is used instead of the FACT_RELATIONSHIP table for linking low-level events to abstracted Episodes.

ETL Conventions

Some episodes may not have links to any underlying clinical events. For such episodes, the EPISODE_EVENT table is not populated.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-episode_id - -Use this field to link the EPISODE_EVENT record to its EPISODE. - -Put the EPISODE_ID that subsumes the EPISODE_EVENT record here. - -integer - -Yes - -No - -Yes - -EPISODE - -
-event_id - -This field is the primary key of the linked record in the database. For example, if the Episode Event is a Condition Occurrence, then the CONDITION_OCCURRENCE_ID of the linked record goes in this field. - -Put the primary key of the linked record here. - -integer - -Yes - -No - -No - - -
-episode_event_field_concept_id - -This field is the CONCEPT_ID that identifies which table the primary key of the linked record came from. - -Put the CONCEPT_ID that identifies which table and field the EVENT_ID came from. Accepted Concepts - -integer - -Yes - -No - -Yes - -CONCEPT - -Metadata -
@@ -10832,598 +808,11 @@ Metadata

METADATA

Table Description

The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-metadata_id - -The unique key given to a Metadata record. - -Attribute value is auto-generated - -integer - -Yes - -Yes - -No - - -
-metadata_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-metadata_type_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-name - - - -varchar(250) - -Yes - -No - -No - - -
-value_as_string - - - -varchar(250) - -No - -No - -No - - -
-value_as_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-value_as_number - -This is the numerical value of the result of the Metadata, if applicable and available. It is not expected that all Metadata will have numeric results, rather, this field is here to house values should they exist. - - -float - -No - -No - -No - - -
-metadata_date - - - -date - -No - -No - -No - - -
-metadata_datetime - - - -datetime - -No - -No - -No - - -

CDM_SOURCE

Table Description

The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cdm_source_name - -The name of the CDM instance. - - -varchar(255) - -Yes - -No - -No - - -
-cdm_source_abbreviation - -The abbreviation of the CDM instance. - - -varchar(25) - -Yes - -No - -No - - -
-cdm_holder - -The holder of the CDM instance. - - -varchar(255) - -Yes - -No - -No - - -
-source_description - -The description of the CDM instance. - - -varchar(MAX) - -No - -No - -No - - -
-source_documentation_reference - - - -varchar(255) - -No - -No - -No - - -
-cdm_etl_reference - - -Put the link to the CDM version used. - -varchar(255) - -No - -No - -No - - -
-source_release_date - -The release date of the source data. - - -date - -Yes - -No - -No - - -
-cdm_release_date - -The release data of the CDM instance. - - -date - -Yes - -No - -No - - -
-cdm_version - - - -varchar(10) - -No - -No - -No - - -
-cdm_version_concept_id - -The Concept Id representing the version of the CDM. - -You can find all concepts that represent the CDM versions using the query: SELECT * FROM CONCEPT WHERE VOCABULARY_ID = ‘CDM’ AND CONCEPT_CLASS = ‘CDM’ - -integer - -Yes - -No - -Yes - -CONCEPT - -
-vocabulary_version - - -You can find the version of your Vocabulary using the query: SELECT vocabulary_version from vocabulary where vocabulary_id = ‘None’ - -varchar(20) - -Yes - -No - -No - - -
@@ -11434,2006 +823,52 @@ No

The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.

Concepts can represent broad categories (like ‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’) or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.).

Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id - -A unique identifier for each Concept across all domains. - - -integer - -Yes - -Yes - -No - - -
-concept_name - -An unambiguous, meaningful and descriptive name for the Concept. - - -varchar(255) - -Yes - -No - -No - - -
-domain_id - -A foreign key to the DOMAIN table the Concept belongs to. - - -varchar(20) - -Yes - -No - -Yes - -DOMAIN - -
-vocabulary_id - -A foreign key to the VOCABULARY table indicating from which source the Concept has been adapted. - - -varchar(20) - -Yes - -No - -Yes - -VOCABULARY - -
-concept_class_id - -The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. - - -varchar(20) - -Yes - -No - -Yes - -CONCEPT_CLASS - -
-standard_concept - -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. - - -varchar(1) - -No - -No - -No - - -
-concept_code - -The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies. - - -varchar(50) - -Yes - -No - -No - - -
-valid_start_date - -The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

VOCABULARY

Table Description

The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-vocabulary_id - -A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. - - -varchar(20) - -Yes - -Yes - -No - - -
-vocabulary_name - -The name describing the vocabulary, for example, International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc. - - -varchar(255) - -Yes - -No - -No - - -
-vocabulary_reference - -External reference to documentation or available download of the about the vocabulary. - - -varchar(255) - -No - -No - -No - - -
-vocabulary_version - -Version of the Vocabulary as indicated in the source. - - -varchar(255) - -No - -No - -No - - -
-vocabulary_concept_id - -A Concept that represents the Vocabulary the VOCABULARY record belongs to. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

DOMAIN

Table Description

The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the “Condition” Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-domain_id - -A unique key for each domain. - - -varchar(20) - -Yes - -Yes - -No - - -
-domain_name - -The name describing the Domain, e.g. Condition, Procedure, Measurement etc. - - -varchar(255) - -Yes - -No - -No - - -
-domain_concept_id - -A Concept representing the Domain Concept the DOMAIN record belongs to. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_CLASS

Table Description

The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_class_id - -A unique key for each class. - - -varchar(20) - -Yes - -Yes - -No - - -
-concept_class_name - -The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc. - - -varchar(255) - -Yes - -No - -No - - -
-concept_class_concept_id - -A Concept that represents the Concept Class. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_RELATIONSHIP

Table Description

The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id_1 - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-concept_id_2 - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-relationship_id - -The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the Vocabulary Conventions. for more information. - - -varchar(20) - -Yes - -No - -Yes - -RELATIONSHIP - -
-valid_start_date - -The date when the relationship is first recorded. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the relationship is invalidated. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the relationship was invalidated. Possible values are ‘D’ (deleted), ‘U’ (updated) or NULL. - - -varchar(1) - -No - -No - -No - - -

RELATIONSHIP

Table Description

The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-relationship_id - -The type of relationship captured by the relationship record. - - -varchar(20) - -Yes - -Yes - -No - - -
-relationship_name - - - -varchar(255) - -Yes - -No - -No - - -
-is_hierarchical - -Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not. - - -varchar(1) - -Yes - -No - -No - - -
-defines_ancestry - -Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0. - - -varchar(1) - -Yes - -No - -No - - -
-reverse_relationship_id - -The identifier for the relationship used to define the reverse relationship between two concepts. - - -varchar(20) - -Yes - -No - -No - - -
-relationship_concept_id - -A foreign key that refers to an identifier in the CONCEPT table for the unique relationship concept. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_SYNONYM

Table Description

The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-concept_synonym_name - - - -varchar(1000) - -Yes - -No - -No - - -
-language_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_ANCESTOR

Table Description

The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.

This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-ancestor_concept_id - -The Concept Id for the higher-level concept that forms the ancestor in the relationship. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-descendant_concept_id - -The Concept Id for the lower-level concept that forms the descendant in the relationship. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-min_levels_of_separation - -The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. - - -integer - -Yes - -No - -No - - -
-max_levels_of_separation - -The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. - - -integer - -Yes - -No - -No - - -

SOURCE_TO_CONCEPT_MAP

Table Description

The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-source_code - -The source code being translated into a Standard Concept. - - -varchar(50) - -Yes - -No - -No - - -
-source_concept_id - -A foreign key to the Source Concept that is being translated into a Standard Concept. - -This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-source_vocabulary_id - -A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept. - - -varchar(20) - -Yes - -No - -No - - -
-source_code_description - -An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept. - - -varchar(255) - -No - -No - -No - - -
-target_concept_id - -The target Concept to which the source code is being mapped. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-target_vocabulary_id - -The Vocabulary of the target Concept. - - -varchar(20) - -Yes - -No - -Yes - -VOCABULARY - -
-valid_start_date - -The date when the mapping instance was first recorded. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

DRUG_STRENGTH

Table Description

The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-drug_concept_id - -The Concept representing the Branded Drug or Clinical Drug Product. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-ingredient_concept_id - -The Concept representing the active ingredient contained within the drug product. - -Combination Drugs will have more than one record in this table, one for each active Ingredient. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-amount_value - -The numeric value or the amount of active ingredient contained within the drug product. - - -float - -No - -No - -No - - -
-amount_unit_concept_id - -The Concept representing the Unit of measure for the amount of active ingredient contained within the drug product. - - -integer - -No - -No - -Yes - -CONCEPT - -
-numerator_value - -The concentration of the active ingredient contained within the drug product. - - -float - -No - -No - -No - - -
-numerator_unit_concept_id - -The Concept representing the Unit of measure for the concentration of active ingredient. - - -integer - -No - -No - -Yes - -CONCEPT - -
-denominator_value - -The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.). - - -float - -No - -No - -No - - -
-denominator_unit_concept_id - -The Concept representing the denominator unit for the concentration of active ingredient. - - -integer - -No - -No - -Yes - -CONCEPT - -
-box_size - -The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient. - - -integer - -No - -No - -No - - -
-valid_start_date - -The date when the Concept was first recorded. The default value is 1-Jan-1970. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when then Concept became invalid. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

COHORT

@@ -13441,365 +876,11 @@ No

The COHORT table contains records of subjects that satisfy a given set of criteria for a duration of time. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINTION tables are kept in a separate schema to alleviate confusion.

ETL Conventions

Cohorts typically include patients diagnosed with a specific condition, patients exposed to a particular drug, but can also be Providers who have performed a specific Procedure. Cohort records must have a Start Date and an End Date, but the End Date may be set to Start Date or could have an applied censor date using the Observation Period Start Date. Cohort records must contain a Subject Id, which can refer to the Person, Provider, Visit record or Care Site though they are most often Person Ids. The Cohort Definition will define the type of subject through the subject concept id. A subject can belong (or not belong) to a cohort at any moment in time. A subject can only have one record in the cohort table for any moment of time, i.e. it is not possible for a person to contain multiple records indicating cohort membership that are overlapping in time

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cohort_definition_id - - - -integer - -Yes - -No - -No - - -
-subject_id - - - -integer - -Yes - -No - -No - - -
-cohort_start_date - - - -date - -Yes - -No - -No - - -
-cohort_end_date - - - -date - -Yes - -No - -No - - -

COHORT_DEFINITION

Table Description

The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cohort_definition_id - -This is the identifier given to the cohort, usually by the ATLAS application - - -integer - -Yes - -No - -No - - -
-cohort_definition_name - -A short description of the cohort - - -varchar(255) - -Yes - -No - -No - - -
-cohort_definition_description - -A complete description of the cohort. - - -varchar(MAX) - -No - -No - -No - - -
-definition_type_concept_id - -Type defining what kind of Cohort Definition the record represents and how the syntax may be executed. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-cohort_definition_syntax - -Syntax or code to operationalize the Cohort Definition. - - -varchar(MAX) - -No - -No - -No - - -
-subject_concept_id - -This field contains a Concept that represents the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit). - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-cohort_initiation_date - -A date to indicate when the Cohort was initiated in the COHORT table. - - -date - -No - -No - -No - - -
diff --git a/docs/cdm54Changes.html b/docs/cdm54Changes.html index 9c3e86a..33bcb80 100644 --- a/docs/cdm54Changes.html +++ b/docs/cdm54Changes.html @@ -13,7 +13,7 @@ Changes by Table - + @@ -63,6 +63,7 @@ if (window.hljs) { + @@ -88,6 +89,9 @@ button.code-folding-btn:focus { summary { display: list-item; } +details > summary > p:only-child { + display: inline; +} pre code { padding: 0; } @@ -312,7 +316,7 @@ div.tocify {
@@ -8863,606 +697,6 @@ CONCEPT

The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table.

User Guide

A Person can have multiple, overlapping, Payer_Plan_Periods in this table. For example, medical and drug coverage in the US can be represented by two Payer_Plan_Periods. The details of the benefit structure of the Plan is rarely known, the idea is just to identify that the Plans are different.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-payer_plan_period_id - -A unique identifier for each unique combination of a Person, Payer, Plan, and Period of time. - - -bigint - -Yes - -Yes - - - -
-person_id - -The Person covered by the Plan. - -A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records - -bigint - -Yes - -No - -Yes - -PERSON - -
-contract_person_id - -The Person who is the primary subscriber/contract owner for Plan. - -This may or may not be the same as the PERSON_ID. For example, if a mother has her son on her plan and the PAYER_PLAN_PERIOD record is the for son, the sons’s PERSON_ID would go in PAYER_PLAN_PERIOD.PERSON_ID and the mother’s PERSON_ID would go in PAYER_PLAN_PERIOD.CONTRACT_PERSON_ID. - -bigint - -No - -No - -Yes - -PERSON - -
-payer_plan_period_start_date - -Start date of Plan coverage. - - -date - -Yes - -No - -No - - -
-payer_plan_period_end_date - -End date of Plan coverage. - - -date - -Yes - -No - -No - - -
-payer_concept_id - -This field represents the organization who reimburses the provider which administers care to the Person. - -Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. If not available, set to 0. Accepted Concepts. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-payer_source_value - -This is the Payer as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-payer_source_concept_id - - -If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-plan_concept_id - -This field represents the specific health benefit Plan the Person is enrolled in. - -Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. If not available, set to 0. Accepted Concepts. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-plan_source_value - -This is the health benefit Plan of the Person as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-plan_source_concept_id - - -If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-contract_concept_id - -This field represents the relationship between the PERSON_ID and CONTRACT_PERSON_ID. It should be read as PERSON_ID is the CONTRACT_CONCEPT_ID of the CONTRACT_PERSON_ID. So if CONTRACT_CONCEPT_ID represents the relationship ‘Stepdaughter’ then the Person for whom PAYER_PLAN_PERIOD record was recorded is the stepdaughter of the CONTRACT_PERSON_ID. - -If available, use this field to represent the relationship between the PERSON_ID and the CONTRACT_PERSON_ID. If the Person for whom the PAYER_PLAN_PERIOD record was recorded is the stepdaughter of the CONTRACT_PERSON_ID then CONTRACT_CONCEPT_ID would be 4330864. If not available, set to 0. Accepted Concepts. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-contract_source_value - -This is the relationship of the PERSON_ID to CONTRACT_PERSON_ID as it appears in the source data. - - -varchar(50) - -Yes - -No - -No - - -
-contract_source_concept_id - - -If the source data codes the relationship between the PERSON_ID and CONTRACT_PERSON_ID in an OMOP supported vocabulary store the concept_id here. If not available, set to 0. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-sponsor_concept_id - -This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan. - -Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. If not available, set to 0. Accepted Concepts. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-sponsor_source_value - -The Plan sponsor as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-sponsor_source_concept_id - - -If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -
-family_source_value - -The common identifier for all people (often a family) that covered by the same policy. - -Often these are the common digits of the enrollment id of the policy members. - -varchar(50) - -No - -No - -No - - -
-stop_reason_concept_id - -This field represents the reason the Person left the Plan, if known. - -Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. Accepted Concepts. - -integer - -No - -No - -Yes - -CONCEPT - -
-stop_reason_source_value - -The Plan stop reason as it appears in the source data. - - -varchar(50) - -No - -No - -No - - -
-stop_reason_source_concept_id - - -If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here. - -integer - -No - -No - -Yes - -CONCEPT - -

COST

@@ -9473,518 +707,6 @@ CONCEPT

When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio.

ETL Conventions

One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cost_id - -A unique identifier for each COST record. - - -bigint - -Yes - -Yes - -No - - -
-person_id - - - -bigint - -Yes - -No - -No - - -
-cost_event_id - -If the Cost record is related to another record in the database, this field is the primary key of the linked record. - -Put the primary key of the linked record, if applicable, here. - -bigint - -Yes - -No - -No - - -
-cost_event_field_concept_id - -If the Cost record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from. - -Put the CONCEPT_ID that identifies which table and field the COST_EVENT_ID came from. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-cost_concept_id - -A foreign key that refers to a Standard Cost Concept identifier in the Standardized Vocabularies belonging to the ‘Cost’ vocabulary. - - -integer - -No - -No - -Yes - -CONCEPT - -
-cost_type_concept_id - -A foreign key identifier to a concept in the CONCEPT table for the provenance or the source of the COST data and belonging to the ‘Type Concept’ vocabulary - - -integer - -No - -No - -Yes - -CONCEPT - -Type Concept -
-cost_source_concept_id - -A foreign key to a Cost Concept that refers to the code used in the source. - - -integer - -No - -No - -Yes - -CONCEPT - -
-cost_source_value - -The source value for the cost as it appears in the source data - - -varchar(50) - -No - -No - -No - - -
-currency_concept_id - -A foreign key identifier to the concept representing the 3-letter code used to delineate international currencies, such as USD for US Dollar. These belong to the ‘Currency’ vocabulary - - -integer - -No - -No - -No - -CONCEPT - -
-cost - -The actual financial cost amount - - -float - -No - -No - -No - - -
-incurred_date - -The first date of service of the clinical event corresponding to the cost as in table capturing the information (e.g. date of visit, date of procedure, date of condition, date of drug etc). - - -date - -No - -No - -No - - -
-billed_date - -The date a bill was generated for a service or encounter - - -date - -No - -No - -No - - -
-paid_date - -The date payment was received for a service or encounter - - -date - -No - -No - -No - - -
-revenue_code_concept_id - -A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes belonging to the ‘Revenue Code’ vocabulary. - - -integer - -No - -No - -Yes - -CONCEPT - -
-drg_concept_id - -A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for DRG codes belonging to the ‘DRG’ vocabulary. - - -integer - -No - -No - -Yes - -CONCEPT - -
-revenue_code_source_value - -The source value for the Revenue code as it appears in the source data, stored here for reference. - - -varchar(50) - -No - -No - -No - - -
-drg_source_value - -The source value for the 3-digit DRG source code as it appears in the source data, stored here for reference. - - -varchar(50) - -No - -No - -No - - -
-payer_plan_period_id - -A foreign key to the PAYER_PLAN_PERIOD table, where the details of the Payer, Plan and Family are stored. Record the payer_plan_id that relates to the payer who contributed to the paid_by_payer field. - - -bigint - -No - -No - -No - - -
@@ -9995,223 +717,6 @@ No

A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras.

ETL Conventions

The SQL script for generating DRUG_ERA records can be found here.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-drug_era_id - - - -bigint - -Yes - -Yes - -No - - -
-person_id - - - -bigint - -Yes - -No - -Yes - -PERSON - -
-drug_concept_id - -The Concept Id representing the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Drug -
-drug_era_start_datetime - - -The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure. - -datetime - -Yes - -No - -No - - -
-drug_era_end_datetime - - -The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era. - -datetime - -Yes - -No - -No - - -
-drug_exposure_count - - - -integer - -No - -No - -No - - -
-gap_days - - -The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are “not stockpiled” by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling. - -integer - -No - -No - -No - - -

DOSE_ERA

@@ -10219,226 +724,6 @@ No

A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.

ETL Conventions

Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-dose_era_id - - - -bigint - -Yes - -Yes - -No - - -
-person_id - - - -bigint - -Yes - -No - -Yes - -PERSON - -
-drug_concept_id - -The Concept Id representing the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Drug -
-unit_concept_id - -The Concept Id representing the unit of the specific drug ingredient. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Unit -
-dose_value - -The numeric value of the dosage of the drug_ingredient. - - -float - -Yes - -No - -No - - -
-dose_era_start_datetime - -The date the Person started on the specific dosage, with at least 31 days since any prior exposure. - - -datetime - -Yes - -No - -No - - -
-dose_era_end_datetime - - -The date the Person was no longer exposed to the dosage of the specific drug ingredient. An era is ended if there are 31 days or more between dosage records. - -datetime - -Yes - -No - -No - - -

CONDITION_ERA

@@ -10450,198 +735,6 @@ No

ETL Conventions

Each Condition Era corresponds to one or many Condition Occurrence records that form a continuous interval. The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers. The SQl Script for generating CONDITION_ERA records can be found here The Condition Era Start Date is the start date of the first Condition Occurrence. The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-condition_era_id - - - -bigint - -Yes - -Yes - -No - - -
-person_id - - - -bigint - -Yes - -No - -No - -PERSON - -
-condition_concept_id - -The Concept Id representing the Condition. - - -integer - -Yes - -No - -Yes - -CONCEPT - -Condition -
-condition_era_start_datetime - -The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition with at least 31 days since any prior record of the same Condition. - - -datetime - -Yes - -No - -No - - -
-condition_era_end_datetime - -The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition. - - -datetime - -Yes - -No - -No - - -
-condition_occurrence_count - -The number of individual Condition Occurrences used to construct the condition era. - - -integer - -No - -No - -No - - -
@@ -10650,516 +743,11 @@ No

METADATA

Table Description

The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-metadata_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-metadata_type_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-name - - - -varchar(250) - -Yes - -No - -No - - -
-value_as_string - - - -varchar(250) - -No - -No - -No - - -
-value_as_concept_id - - - -integer - -No - -No - -Yes - -CONCEPT - -
-metadata_date - - - -date - -No - -No - -No - - -
-metadata_datetime - - - -datetime - -No - -No - -No - - -

CDM_SOURCE

Table Description

The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cdm_source_name - -The name of the CDM instance. - - -varchar(255) - -Yes - -No - -No - - -
-cdm_source_abbreviation - -The abbreviation of the CDM instance. - - -varchar(25) - -No - -No - -No - - -
-cdm_holder - -The holder of the CDM instance. - - -varchar(255) - -No - -No - -No - - -
-source_description - -The description of the CDM instance. - - -varchar(MAX) - -No - -No - -No - - -
-source_documentation_reference - - - -varchar(255) - -No - -No - -No - - -
-cdm_etl_reference - - -Put the link to the CDM version used. - -varchar(255) - -No - -No - -No - - -
-source_release_date - -The release date of the source data. - - -date - -No - -No - -No - - -
-cdm_release_date - -The release data of the CDM instance. - - -date - -No - -No - -No - - -
-cdm_version - - - -varchar(10) - -No - -No - -No - - -
-vocabulary_version - - - -varchar(20) - -No - -No - -No - - -
@@ -11170,2001 +758,52 @@ No

The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.

Concepts can represent broad categories (like ‘Cardiovascular disease’), detailed clinical elements (‘Myocardial infarction of the anterolateral wall’) or modifying characteristics and attributes that define Concepts at various levels of detail (severity of a disease, associated morphology, etc.).

Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id - -A unique identifier for each Concept across all domains. - - -integer - -Yes - -Yes - -No - - -
-concept_name - -An unambiguous, meaningful and descriptive name for the Concept. - - -varchar(255) - -Yes - -No - -No - - -
-domain_id - -A foreign key to the DOMAIN table the Concept belongs to. - - -varchar(20) - -Yes - -No - -Yes - -DOMAIN - -
-vocabulary_id - -A foreign key to the VOCABULARY table indicating from which source the Concept has been adapted. - - -varchar(20) - -Yes - -No - -Yes - -VOCABULARY - -
-concept_class_id - -The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. - - -varchar(20) - -Yes - -No - -Yes - -CONCEPT_CLASS - -
-standard_concept - -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. - - -varchar(1) - -No - -No - -No - - -
-concept_code - -The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies. - - -varchar(50) - -Yes - -No - -No - - -
-valid_start_date - -The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning, the Concept has no (known) date of inception. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning, the Concept is valid until it becomes deprecated. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

VOCABULARY

Table Description

The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-vocabulary_id - -A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. - - -varchar(20) - -Yes - -Yes - -No - - -
-vocabulary_name - -The name describing the vocabulary, for example International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc. - - -varchar(255) - -Yes - -No - -No - - -
-vocabulary_reference - -External reference to documentation or available download of the about the vocabulary. - - -varchar(255) - -Yes - -No - -No - - -
-vocabulary_version - -Version of the Vocabulary as indicated in the source. - - -varchar(255) - -No - -No - -No - - -
-vocabulary_concept_id - -A Concept that represents the Vocabulary the VOCABULARY record belongs to. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

DOMAIN

Table Description

The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the “Condition” Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-domain_id - -A unique key for each domain. - - -varchar(20) - -Yes - -Yes - -No - - -
-domain_name - -The name describing the Domain, e.g. Condition, Procedure, Measurement etc. - - -varchar(255) - -Yes - -No - -No - - -
-domain_concept_id - -A Concept representing the Domain Concept the DOMAIN record belongs to. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_CLASS

Table Description

The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_class_id - -A unique key for each class. - - -varchar(20) - -Yes - -Yes - -No - - -
-concept_class_name - -The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc. - - -varchar(255) - -Yes - -No - -No - - -
-concept_class_concept_id - -A Concept that represents the Concept Class. - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_RELATIONSHIP

Table Description

The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id_1 - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-concept_id_2 - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-relationship_id - -The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the Vocabulary Conventions. for more information. - - -varchar(20) - -Yes - -No - -Yes - -RELATIONSHIP - -
-valid_start_date - -The date when the relationship is first recorded. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the relationship is invalidated. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the relationship was invalidated. Possible values are ‘D’ (deleted), ‘U’ (updated) or NULL. - - -varchar(1) - -No - -No - -No - - -

RELATIONSHIP

Table Description

The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-relationship_id - - - -varchar(20) - -Yes - -Yes - -No - - -
-relationship_name - - - -varchar(255) - -Yes - -No - -No - - -
-is_hierarchical - - - -varchar(1) - -Yes - -No - -No - - -
-defines_ancestry - - - -varchar(1) - -Yes - -No - -No - - -
-reverse_relationship_id - - - -varchar(20) - -Yes - -No - -No - - -
-relationship_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_SYNONYM

Table Description

The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-concept_synonym_name - - - -varchar(1000) - -Yes - -No - -No - - -
-language_concept_id - - - -integer - -Yes - -No - -Yes - -CONCEPT - -

CONCEPT_ANCESTOR

Table Description

The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.

This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-ancestor_concept_id - -The Concept Id for the higher-level concept that forms the ancestor in the relationship. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-descendant_concept_id - -The Concept Id for the lower-level concept that forms the descendant in the relationship. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-min_levels_of_separation - -The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. - - -integer - -Yes - -No - -No - - -
-max_levels_of_separation - -The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. - - -integer - -Yes - -No - -No - - -

SOURCE_TO_CONCEPT_MAP

Table Description

The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-source_code - -The source code being translated into a Standard Concept. - - -varchar(50) - -Yes - -No - -No - - -
-source_concept_id - -A foreign key to the Source Concept that is being translated into a Standard Concept. - -This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-source_vocabulary_id - -A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept. - - -varchar(20) - -Yes - -No - -No - - -
-source_code_description - -An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the concept. - - -varchar(255) - -No - -No - -No - - -
-target_concept_id - -The target Concept to which the source code is being mapped. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-target_vocabulary_id - -The Vocabulary of the target Concept. - - -varchar(20) - -Yes - -No - -Yes - -VOCABULARY - -
-valid_start_date - -The date when the mapping instance was first recorded. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. Default value is 31-Dec-2099. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

DRUG_STRENGTH

Table Description

The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-drug_concept_id - -The Concept representing the Branded Drug or Clinical Drug Product. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-ingredient_concept_id - -The Concept representing the active ingredient contained within the drug product. - -Combination Drugs will have more than one record in this table, one for each active Ingredient. - -integer - -Yes - -No - -Yes - -CONCEPT - -
-amount_value - -The numeric value or the amount of active ingredient contained within the drug product. - - -float - -No - -No - -No - - -
-amount_unit_concept_id - -The Concept representing the Unit of measure for the amount of active ingredient contained within the drug product. - - -integer - -No - -No - -Yes - -CONCEPT - -
-numerator_value - -The concentration of the active ingredient contained within the drug product. - - -float - -No - -No - -No - - -
-numerator_unit_concept_id - -The Concept representing the Unit of measure for the concentration of active ingredient. - - -integer - -No - -No - -Yes - -CONCEPT - -
-denominator_value - -The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.). - - -float - -No - -No - -No - - -
-denominator_unit_concept_id - -The Concept representing the denominator unit for the concentration of active ingredient. - - -integer - -No - -No - -Yes - -CONCEPT - -
-box_size - -The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient. - - -integer - -No - -No - -No - - -
-valid_start_date - -The date when the Concept was first recorded. The default value is 1-Jan-1970. - - -date - -Yes - -No - -No - - -
-valid_end_date - -The date when then Concept became invalid. - - -date - -Yes - -No - -No - - -
-invalid_reason - -Reason the concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. - - -varchar(1) - -No - -No - -No - - -

COHORT

@@ -13172,366 +811,11 @@ No

The COHORT table contains records of subjects that satisfy a given set of criteria for a duration of time. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINTION tables are kept in a separate schema to alleviate confusion.

ETL Conventions

Cohorts typically include patients diagnosed with a specific condition, patients exposed to a particular drug, but can also be Providers who have performed a specific Procedure. Cohort records must have a Start Date and an End Date, but the End Date may be set to Start Date or could have an applied censor date using the Observation Period Start Date. Cohort records must contain a Subject Id, which can refer to the Person, Provider, Visit record or Care Site though they are most often Person Ids. The Cohort Definition will define the type of subject through the subject concept id. A subject can belong (or not belong) to a cohort at any moment in time. A subject can only have one record in the cohort table for any moment of time, i.e. it is not possible for a person to contain multiple records indicating cohort membership that are overlapping in time

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cohort_definition_id - - - -integer - -Yes - -No - -No - - -
-subject_id - - - -integer - -Yes - -No - -No - - -
-cohort_start_date - - - -date - -Yes - -No - -No - - -
-cohort_end_date - - - -date - -Yes - -No - -No - - -

COHORT_DEFINITION

Table Description

The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-CDM Field - -User Guide - -ETL Conventions - -Datatype - -Required - -Primary Key - -Foreign Key - -FK Table - -FK Domain -
-cohort_definition_id - -This is the identifier given to the cohort, usually by the ATLAS application - - -integer - -Yes - -No - -Yes - -COHORT - -
-cohort_definition_name - -A short description of the cohort - - -varchar(255) - -Yes - -No - -No - - -
-cohort_definition_description - -A complete description of the cohort. - - -varchar(MAX) - -No - -No - -No - - -
-definition_type_concept_id - -Type defining what kind of Cohort Definition the record represents and how the syntax may be executed. - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-cohort_definition_syntax - -Syntax or code to operationalize the Cohort Definition. - - -varchar(MAX) - -No - -No - -No - - -
-subject_concept_id - -This field contains a Concept that represents the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit). - - -integer - -Yes - -No - -Yes - -CONCEPT - -
-cohort_initiation_date - -A date to indicate when the Cohort was initiated in the COHORT table. - - -date - -No - -No - -No - - -
diff --git a/docs/cdmDecisionTree.html b/docs/cdmDecisionTree.html index 9feb8c7..9ca3f2e 100644 --- a/docs/cdmDecisionTree.html +++ b/docs/cdmDecisionTree.html @@ -419,9 +419,9 @@ $(document).ready(function () {

If you have arrived to this page then you must be thinking HELP! I have some data that doesn’t fit in the CDM! Never fear as this handy guide will point you in the right direction and all you have to do is answer a few questions.

-

First things first, do you have a documented network use case for this data? This could take the form of an upcoming study or a convention for how to store information. In this scenario, at least two or more collaborators with data to contribute constitute a network need.

-

Yes, I have a network use case

-

No, I do not have a network use case

+

First things first, do you think you will need to change the OMOP Common Data Model itself or are you solely looking for vocabulary support?

+

I think I need to change the OMOP CDM

+

I need vocabulary support

diff --git a/docs/cdmPrivacy.html b/docs/cdmPrivacy.html index 971df68..9c05342 100644 --- a/docs/cdmPrivacy.html +++ b/docs/cdmPrivacy.html @@ -13,7 +13,7 @@ Preserving Privacy in an OMOP CDM Implementation - + @@ -63,6 +63,7 @@ if (window.hljs) { + @@ -88,6 +89,9 @@ button.code-folding-btn:focus { summary { display: list-item; } +details > summary > p:only-child { + display: inline; +} pre code { padding: 0; } @@ -312,7 +316,7 @@ div.tocify { + + + + +

Alright, so you think you might need to change the OMOP Common Data Model. Do you have a documented network use case for this data need? This could take the form of an upcoming study or a convention for how to store information. In this scenario, at least two or more collaborators with data to contribute constitute a network need.

+

Yes, I have a network use case

+

No, I do not have a network use case

+ + + + + + + + + + + + + + + + + + + + diff --git a/docs/oncology.html b/docs/oncology.html index 414af3b..f5f04a4 100644 --- a/docs/oncology.html +++ b/docs/oncology.html @@ -13,7 +13,7 @@ Oncology Extension - + @@ -63,6 +63,7 @@ if (window.hljs) { + @@ -88,6 +89,9 @@ button.code-folding-btn:focus { summary { display: list-item; } +details > summary > p:only-child { + display: inline; +} pre code { padding: 0; } @@ -312,7 +316,7 @@ div.tocify {