OMOP Common Data Model Oncology Extension Documentation

This documentation details the ratified proposal of adding an oncology extension to the OMOP CDM. These tables and fields will become part of the next release (v6.1) of the Common Data Model. Below are their descriptions; showing additions to the model only. For example, two fields were added to the MEASUREMENT table as part of this extension so only those two fields are listed below for MEASUREMENT instead of the entire table. For more information, please see the OMOP Oncology wiki site.

The DDLs for these tables are located on the Oncology github, as detailed in the installation instructions.

## Warning in read.table(file = file, header = header, sep = sep, quote = quote, : incomplete final line found by readTableHeader on '../inst/csv/
## OMOP_CDM_Oncology_Ex_Table_Level.csv'

EPISODE

Table Description

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 FK Class
episode_id A unique identifier for each Episode. bigint Yes Yes No
person_id The PERSON_ID of the PERSON for whom the episode is recorded. bigint 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 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
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. bigint 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. 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

Table Description

The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode.

User Guide

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 FK Class
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. bigint 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. bigint 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

MEASUREMENT

Table Description

The MEASUREMENT table contains records of Measurement, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc. Measurements are stored as attribute value pairs, with the attribute as the Measurement Concept and the value representing the result. The value can be a Concept (stored in VALUE_AS_CONCEPT), or a numerical value (VALUE_AS_NUMBER) with a Unit (UNIT_CONCEPT_ID).

User Guide

Measurements differ from Observations in that they require a standardized test or some other activity to generate a quantitative or qualitative result.

CDM Field User Guide ETL Conventions Datatype Required Primary Key Foreign Key FK Table FK Domain FK Class
modifier_of_event_id If the Measurement 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 No No No
modifier_of_field_concept_id If the Measurement 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 MODIFIER_OF_EVENT_ID came from. Accepted Concepts integer No No Yes CONCEPT Metadata