Skip to content
Megan Stachura edited this page May 14, 2026 · 49 revisions

Purpose of this document

The process of converting data to the OMOP CDM is thoroughly outlined in book.ohdsi.org and precise instructions are given at ohdsi.github.io/CommonDataModel. While all standard rules still apply to cancer data, there are several additional instructions and conventions to be followed to ensure high-quality cancer real world data (RWD).

-> This document provides a summary of these standards for the ETL developer.

A corresponding guide exists for researchers: Instructions for Analysts.

Difference between ETLing general patient and cancer data.

Oncology is a branch of medicine that focuses on cancer, or malignant neoplasm, which is a disease in which some of the body's cells grow uncontrollably and can spread to other parts of the body.

-> This guideline does not apply to benign tumors (those which do not invade other tissue or spread) or borderline tumors.

While the OMOP CDM aims to model the whole patient experience during illness and interactions with the healthcare system, studying cancer demands an even higher level of standardization, including:

  • Accurate cancer diagnoses
  • Disease progression (disease dynamic attributes)
  • Diagnostic findings
  • Specific cancer treatments
  • Treatment outcomes

While not part of cancer data directly, risk factors and comorbidities are also essential for cancer research and require a high quality of capture.

The first part of this document explains how you should represent data in the OMOP CDM, serving as a guide to the target model. The second part covers some common situations found in source data.

General instructions

This guide builds on the general instructions of how to build an OMOP CDM Version 5.4, and all rules apply. But you must make special additional considerations for the CONDITION_OCCURRENCE, MEASUREMENT, PROCEDURE_OCCURRENCE and EPISODE tables.

For each table, only fields requiring further attention are discussed. Do not interpret that any fields not discussed in this guide can be omitted from the model. Cancer is a dynamic disease, but relevant time frames are days, weeks and months, not minutes and hours. Therefore, fill the generic datetime with the equivalent of date fields.

Type Concepts are discussed in Section Data Sources. Generally, refrain from writing records with flavors of NULL (e.g. "N/A", "Not recorded", "Unknown"). If you are not sure about a particular record contact oncology@ohdsi.org or inquire through a post in the OHDSI Forum.

Conditions

Generally, conditions are fully pre-coordinated concepts of the Condition domain, combining different attributes such as signs, symptoms, cause, severity, temporal context (acute or chronic), pathological process, finding site etc. In cancer, conditions must be diagnosis concepts with two attributes only:

-> Conditions are precoordinated combinations of histology and primary topography.

Histology is also called "morphology", and topography is also called "finding site" or "topology".

-> Not all combinations of histology and topography are biologically possible.

When cancers spread (metastasize), they can manifest in many different topographies, usually called metastases or secondary malignant neoplasms.

-> Condition topographies are only those of the primary cancer.

For the correct representation of metastases see below.

Vocabularies

-> Cancer conditions must be expressed in ICDO3 or SNOMED.

ICDO3 concepts have a higher level of granularity. SNOMED concepts are the hierarchical ancestors of ICDO3 concepts.

SNOMED has a cancer hierarchy with two main branches: carcinoma in situ (the cancer has not yet grown or spread, ancestors Carcinoma in situ, Adenocarcinoma in situ of esophagus, Adenocarcinoma in situ of cervix, Lentigo maligna and Melanoma in situ) and Malignant neoplastic disease (full-fledged cancer, ancestor Malignant neoplastic disease). SNOMED often, but not always, makes the distinction between malignant neoplasms and primary malignant neoplasms, with the latter being the descendant of the former.

Proper standard SNOMED cancer condition concepts have "Has asso morph" relationships to standard concepts of domain "Observation" and concept class "Morph Abnormality" representing the histology, and "Has finding site" relationships to concepts of domain "Spec Anatomic Site" and concept class "Body Structure", representing the topography (see section "Observations").

Some cancer conditions lacking the topography relationship; these are called "one-legged" cancer conditions. They often, but not always, have the same concept name as the corresponding histology concept (e.g. Condition Squamous cell carcinoma and Histology Squamous cell carcinoma). These are permitted, but should be avoided and if possible used to generate fully defined concepts by combining them with topography concepts from the data (see below). In hematological cancers, the topography is less relevant, and is either given as Bone marrow structure or omitted entirely.

Similarly, SNOMED contains concepts where a topography is combined with a trivial histology component (usually "malignant neoplasm" in e.g. Malignant neoplasm of uterus), called "shallow cancer conditions". These, too, should be upgraded by combining them with more detailed histology concepts if available in the data (see below).

ICDO3 also makes a distinction between cancers and carcinomas in situ, as well as covers benign and borderline tumors. They have no hierarchical relationships to each other, only to their SNOMED ancestors. ICDO3 contains three classes: "ICDO Condition", "ICDO Histology" and "ICDO Topography". Only the latter two are sourced from the WHO, the ICDO Conditions are OHDSI-generated pre-coordinated combinations to be used as cancer conditions. ICDO3 Histology concepts contain a behavior code: /0 (benign), /1 (borderline/undefined behavior), /2 (in-situ), and /3 (malignant). ICDO3 topography concepts mostly have the same concept code as the equivalent cancer condition concepts of ICD10, which tend to be shallow concepts. For example, "C25.1" stands for ICDO Topography concept Body of pancreas as well as ICD10 Malignant neoplasm: Body of pancreas.

Proper standard ICDO3 Condition concepts have the above relationships to SNOMED histology and topography concepts, and "Has Histology ICDO" relationships to concepts of domain "Observation" and concept class "ICDO Histology", representing the histology, and "Has Topography ICDO" relationships to concepts of domain "Spec Anatomic Site" and concept class "ICDO Topography", representing the topography (see section "Observations").

ICDO3 also contains one-legged or shallow concepts. The one-legged have concept names starting with "Neoplasm defined only by histology" and "NULL" in the topography component of the concept code, while the shallows start with "Neoplasm defined only by topography" and "NULL" as the histology component of the concept code. Hematological cancers usually have Bone marrow, Blood, Reticuloendothelial system or Spleen as topography, unless they are leukemic infiltrations to some organ, which is rare.

ETL guideline for Conditions

When writing CONDITION_OCCURRENCE records, you will come across the following mapping scenarios for the condition_concept_id field:

1. Map to cancer condition

If your data have source codes or unstructured free text fields, try mapping them to proper cancer conditions (those with histology and topography), before you revert to one-legged or shallow concepts. If you must choose between a malignant and a primary malignant concept of the same histology and topography pick the malignant and ignore the primary malignant version. If different records of the same cancer contain concepts of different granularity depth (e.g. sometimes as Acinar cell carcinoma of body of pancreas and sometimes as Malignant tumor of pancreas) don't worry and don't try to harmonize.

2. Combine histology and topography concepts to proper cancer condition

In many source data, histology and topography records are provided separately and no proper cancer diagnosis is given. Alternatively, histology concepts are given as one-legged conditions, and topography concepts are provided as shallow concepts, or a combination of the above. In these cases, it is up to you to generate the condition concepts by combining the components. Often time, they are not recorded on the same day, so you must create a time corridor to find the histology/topography pairs. Combine them as follows:

  • If you have ICDO3 histology and topography records only, you can just concatenate their concept codes with a dash and look up the condition concept. For example, you have histology concept Acinar cell carcinoma with concept code "8550/3" and topography concept Body of pancreas with concept code "C25.1" in the same patient within a corridor of, say, a month, you create a combined concept code "8550/3-C25.1" and look up Acinar cell carcinoma of body of pancreas. If you have ICDO3 condition concepts with a "NULL" in the concept code, extract only the histology or topography component and do as above.

  • If you have a mixture of SNOMED and ICDO3 or only SNOMED concepts, you can use the combination table made available here.

  • If you cannot find concepts using the ICDO3 or SNOMED method even though the histology and topography concepts exist, such combination is likely biologically not valid, and nothing should be written out.

3. Split extra attributes from conditions beyond histology and topography

Many source data contain condition concepts or free diagnosis text listing more attributes than histology and topography. You must split them off and write only the proper cancer condition concept. For example, PUVA therapy-associated squamous cell carcinoma should be recorded as a condition concept Squamous cell carcinoma, Kaposi's sarcoma with AIDS as Kaposi's sarcoma and AIDS, and Local recurrence of malignant tumor of gallbladder as Malignant tumor of gallbladder. The superfluous attributes must be written as Cancer Modifiers, Episodes or other Conditions (see below). In future OHDSI Standardized Vocabulary releases, all these will be non-standard with correct "Maps to" relationships, but for now you can use the table available here.

Observations

Observations have no special relevance to cancer, except that they contain concepts denoting histology and topography (see above).

Topography of cancers are often defined from surgical specimen, which can be recorded in the SPECIMEN table. For recording topography information, do not use this mechanism.

Vocabularies

-> Histology and Topography concepts must be recorded in the SNOMED or ICDO3 vocabularies.

Histology concepts have domain "Observation" and concept classes "Morph Abnormality" and "ICDO Histology", respectively. Topography concepts have domain "Spec Anat Site" and concept classes "Body Structure" and "ICDO Topography", respectively.

ETL guideline for Observations

In your source data, you will find histology or topography information:

  • As a direct histology or topography record,
  • As part of the cancer condition record,
  • Inside some unstructured text containing a surgery, imaging or pathology report.

-> Do not derive histology and topography information from Cancer Condition records in the source

However, if you have this information in the source duplication with Condition is no problem.

Map histology and topography information to the most granular concepts and record it in the OBSERVATION table.

-> Do not record topography information in the SPECIMEN table.

Measurements

Cancers are not a single disease. They are very different with respect to prognosis, treatment and outcomes, which all depend on their attributes called "cancer modifiers". These must be recorded in the MEASUREMENT table.

Cancer modifiers are often documented during diagnostic processes (such as imaging, pathology, or biomarker tests) and may be recorded separately from the primary cancer diagnosis. While linking this information can be useful, source data may not always provide such direct connection. This is rarely a problem since patients tend not to have multiple active primary cancers simultaneously. If it does happen, preserving the links is crucial.

-> A link between a cancer modifier and its primary condition record is optional.

Metastases

Metastasis refers to the spread of cancer; once it is discovered, it becomes the main factor affecting both the treatment approach and disease prognosis. Metastases are also crucial in assessing response to treatment, since successful therapy should either shrink or eliminate them. Due to these two use cases, prior to initial detection metastasis records adhere to the Closed-World assumption - only positive findings are worth documenting, and the absence of records denotes no metastasis so far. Following detection, however, the Open-World assumption applies, requiring explicit documentation of negative findings.

-> Do not record absence of metastasis until the first occurrence. Do record absence of metastases after the first occurrence.

Metastases can be recorded as specific concepts, or as part of a stage (see below). This can lead to contradictions (e.g. a metastasis record but an M0 stage designation).

-> Do not infer Metastasis records from Stages. Do not resolve contradictions between Metastasis and Stage records.

Only use information from the source data.

Vocabularies

-> Metastases must be recorded in the Cancer Modifier vocabulary.

They all have concept class "Metastasis". Typically, they are called "Metastasis to" followed by some topography. But there are atypical concepts such as Circulating tumor cells or Malignant ascites. Together, they form a simple hierarchy based on their topography with Metastasis as their ancestor.

ETL guideline for Metastases

In your source data, you will find metastasis information:

  • As a direct metastasis record,
  • As a separate diagnosis record, typically starting with "Secondary malignant neoplasm of ...",
  • Inside some unstructured text containing a surgery, imaging or pathology report,
  • As part of a complex cancer diagnosis. You will have to split this into the proper cancer diagnosis with histology and topography (see above), and the metastatic status. For example, diagnoses could be defined as "Metastatic adenocarcinoma of the lung" or "Adenocarcinoma of the lung with metastasis to the bone".

Create Metastasis records as following:

  • Map this information to the most granular Cancer Modifier concept of concept class "Metastasis" you can find and record it in the measurement_concept_id field of the Measurement table. If you have no information where the metastasis is located or the mapping was unsuccessful record Metastasis.

  • For measurement_date, use the earliest plausible date if you have more than one, which typically is the date of the surgery or the imaging procedure.

  • The use of value_as_concept_id must be Positive, Negative or, rarely so, Equivocal. Do not leave it at NULL. The first record in the patient must be a Positive. Don't write negative or equivocal Metastasis records for a patient before you have written a positive one on a prior day (switch from Closed to Open World assumption).

  • The value_as_number is only needed if your source has either the number of metastases (write one record for that) or their dimensions (size or weight, write one record for each metastasis). The distinction is made through the unit_concept_id, which should contain NULL (means number of metastases) or one out of millimeter, centimeter, milligram or gram. Avoid any reference to the "largest" of these, as their dimension will speak for itself. A value of 0 in value_as_number indicating absence of metastases must be accompanied with a value_as_concept_id of Negative, a value>0 must have a Positive. Make sure not to write a record of value_as_number=0 before you have written some kind of positive record for that patient on a prior day.

  • If you have relative dimensions, (e.g. something like "metastasis greater than 10 mm") you must place the <, <=, > or >= operators in operator_concept_id. The use of = is optional.

  • If your source has information about the corresponding primary cancer, or you obtained it by splitting it from a condition record, place the condition_occurrence_id of that record in the measurement_event_id field and concept condition_occurrence_id in the meas_event_field_concept_id field.

Stages and Grades

Cancer staging is the system used to describe the growth and spread to lymph nodes or distant organs, determining prognosis and guides treatment. Cancer grades are histopathologic categories of the degree of cellular differentiation and proliferative activity, determined primarily by microscopic evaluation of tumor architecture, cytologic atypia, and mitotic index.

There are three types of stages:

  • Main cancer stages I-IV by the AJCC/UICC, SEER, and CoC
  • The TNM system with T (tumor size), N (affected lymph nodes) and M (metastasis), also by the AJCC and UICC
  • Cancer type specific stages, like the Lugano system for lymphomas and the FIGO staging for gynecological cancers

AJCC and UICC stages are regularly published as versions.

Grades are also published by the AJCC/UICC and other professional organizations.

-> Do not infer Stage records from Metastasis, Node or Dimension records.

Only use information from the source.

Vocabularies

-> Stages and Grades must be recorded in the Cancer Modifier vocabulary.

There are concepts for most generally used Stage or Grade systems available: AJCC and UICC, Ann Arbor, BCLC, Binet, COG, Dukes, Durie/Salmon, Enneking, ENSAT, Evans, FIGO, INRG, INSS, IRSG, IRS-modified, ISS, Lugano, Masaoka-Koga, POG, PRETEXT, Rai and modified Rai, Reese-Ellsworth RISS, SIOP/COG/NWTSG, FIGO, Deauville, Gleason, Nottingham.

All these concepts have concept class "Staging/Grading". They are fully pre-coordinated from up to five components, forming a hierarchy going from fewer to more components:

  • Name of the Staging/Grading system (usually the publishing organization)
  • Version or year (FIGO)
  • Determination by a clinical or pathological assessment
  • In case of the TNM system one of the three subcategories T, N or M
  • Value of the stage

Each of them forms their own hierarchy. For example, the AJCC/UICC goes from ancestor AJCC/UICC finding to leaves AJCC/UICC 6th clinical Stage 1A1 (main cancer staging system) or AJCC/UICC 6th clinical M1b Category (TNM system). Ancestor FIGO finding has descendants FIGO Stage 4 or FIGO grade 1.

ETL guideline for Stages and Grades

In your source data, you will find stage/grade information:

  • As a direct stage or grade record,
  • Inside some unstructured text containing a surgery, imaging or pathology report,
  • As part of a complex cancer diagnosis. You will have to split this into the proper cancer diagnosis with histology and topography (see above), and the stage or grade. For example, a diagnosis could be given as "Stage 4b adenocarcinoma of the lung".

Create Stage/Grade records as following:

  • Map this information to the most granular Cancer Modifier concept of concept class "Staging/Grading" you can find and record it in the measurement_concept_id field of the Measurement table. Do not use concepts from other vocabularies (LOINC, SNOMED, NAACCR etc.), even if they contain standard concepts (they will be phased out over time).

  • For measurement_date, use the earliest plausible date, which typically is the date of the surgery or the imaging procedure.

  • The fields value_as_concept_id and value_as_number must be set to NULL.

-> Do not use the value fields for encoding stage or grade values.

  • If your source data have information about the corresponding primary cancer, or you obtained it by splitting it from a condition record, place the condition_occurrence_id of that record in the measurement_event_id field and concept condition_occurrence_id in the meas_event_field_concept_id field.

Nodes

Lymph node involvement is another predictor of cancer prognosis and a potential factor in determining treatment choice. Similarly to metastases, the detection of an affected lymph node means the disease has begun to spread beyond the primary tumor. And like metastases (see above), cancerous lymph node lesions can be used to assess response to cancer treatment. Therefore, the same rules apply to nodes:

-> Do not record absence of nodes until the first occurrence of an involved node. Do record the absence of nodes (whether previously recorded as present or not) after the first occurrence of involved nodes.

-> Do not infer Nodes records from Stages. Do not resolve contradictions between Node and Stage records.

Only use information from the source data.

Vocabularies

-> Nodes must be recorded in the Cancer Modifier vocabulary.

They all have concept class "Nodes". Typically, they contain a topography followed by "Lymph Nodes", like in Pelvic Lymph Nodes. But there are atypical concepts such as Regional spread to lymph node or Extranodal Extension (ENE). There is no hierarchical system of nodes, except that Distant spread to lymph node is a descendant to Metastasis and Regional spread to lymph node and Distant spread to lymph node are descendants to the generic and unspecific Spread to lymph node.

ETL guideline for Nodes

In your source data, you will find node information:

  • As a direct node record,
  • Inside some unstructured text containing a surgery, imaging or pathology report,
  • As part of a complex cancer diagnosis. You will have to split this into the proper cancer diagnosis with histology and topography (see above), and the node status. For example, diagnoses could be defined as "Squamous cell carcinoma involving inguinal lymph nodes".

Create Nodes records as following:

  • Map node information to the most granular Cancer Modifier concept of concept class "Nodes" you can find and record it in the measurement_concept_id field of the MEASUREMENT table. If you have no information where the node is located or mapping was unsuccessful record Spread to lymph node.

  • For measurement_date, use the earliest plausible date, which typically is the date of the surgery or the imaging procedure.

  • The use of value_as_concept_id must be Positive, Negative or, rarely so, Equivocal. Do not leave it at NULL. The first record in the patient must be a Positive. Don't write negative or equivocal Node records for a patient before you have written a positive one on a prior day (switch from Closed to Open World assumption).

  • The value_as_number is only needed if your source has either the number of Nodes (write one record for that) or the dimensions (size or weight) of Nodes (write one record for each Node). The distinction is made through the unit_concept_id, which should contain NULL (means number of Nodes) or one out of millimeter, centimeter, milligram or gram. Avoid any reference to the "largest" of these, as their dimension will speak for itself. A value of 0 in value_as_number indicating absence of Nodes must be accompanied with a value_as_concept_id of Negative, a value>0 must have a Positive. Make sure not to write a record of value_as_number=0 before you have written some kind of positive record for that patient on a prior day.

  • If you have relative dimensions (e.g. something like "involved lymph node greater than 10 mm), you must place the <, <=, > or >= operators in operator_concept_id. The use of = is optional.

  • If your source data have information about the corresponding primary cancer, or you obtained it by splitting it from a condition record, place the condition_occurrence_id of that record in the measurement_event_id field and concept condition_occurrence_id in the meas_event_field_concept_id field.

Dimensions

The size or dimension of tumor lesions is a predictor of prognosis and treatment strategy because larger tumors are more likely to have spread, to be biologically more aggressive, and to require more intensive therapy. It is also used to track the effect of treatment to shrink tumors.

The Dimension modifier is used only with the primary cancer.

-> Do not use Dimension to record the dimension of metastases and nodes.

This is despite the fact that there are Dimension concept for those. The size of metastases and nodes should be recorded in the actual record (see above).

-> Do not infer Dimension records from Stages. Do not resolve contradictions between Dimension and Stage records.

Only use information from the source data.

Vocabularies

-> Tumor dimensions must be recorded in the Cancer Modifier vocabulary.

They all have concept class "Dimension". Of the many concepts, which are all derived from path reports, only a few are useful for large scale real-world evidence (RWE).

ETL guideline for Dimension

In your source data, you will find dimension information:

  • As a direct record,
  • Inside some unstructured text containing a surgery, imaging or pathology report.

Create Dimension records as following:

  • Map these to the optimal concept among the Dimension concepts for the provided data and place it into the measurement_concept_id field. Typically, source data don't use concepts to indicate which dimension is measured but use defined fields. Try to limit it to either Dimension of Tumor or Weight of Tumor. If there is more than one cancer lesion or nodule the source has dimension information, create a record for each. Avoid any reference to the "largest" of these, as their dimension record will speak for itself.

-> If mapping was unsuccessful, no record with measurement_concept_id=0 is required.

  • The numerical value goes into value_as_number, and the unit into unit_concept_id, which you must select from millimeter, centimeter, milligram or gram.

  • If you have relative dimensions, (e.g. in NAACCR Residual tumor nodule(s) greater than 1 cm) you must place the <, <=, > or >= operators in operator_concept_id. The use of = is optional.

  • If your source data have information about the corresponding primary cancer place the condition_occurrence_id of that record in the measurement_event_id field and concept condition_occurrence_id in the meas_event_field_concept_id field.

Genomic Biomarkers

Cancer is driven by molecular changes, including DNA, RNA and protein mutations, altered DNA structure, RNA and protein expression, and chromosomal variants, all of which are increasingly important for diagnosis and management of cancer. Both driver (oncogenic) and passenger (non-functional) somatic mutations occur in affected cells, so this guide focuses on somatic mutations. Germ-line mutations also increase cancer risk and are managed similarly to somatic mutations.

-> At present, the data model does not differentiate between somatic and germ-line mutations.

This is a current shortcoming, which however is mitigated by the fact that most mutations are known to be either somatic or germline with just a little overlap.

Genomic biomarkers are often generated through sequencing pipelines or other high-throughput techniques. If they are primarily used for biomarker discovery and association with disease they have an open model that allows the recording of any variant. In the OMOP CDM, only clinically relevant biomarkers are used in epidemiological research like any other data about the disease.

-> The OMOP CDM does not support an open-ended discovery model.

That includes detecting novel biomarkers, dissecting and calculating a patient's details about tumor and healthy tissue specimens, or sequencing and variant calling quality metrics.

-> For an OMOP CDM Extension proposed for discovery research see the G-CDM.

Genomic biomarkers are also cancer modifiers. There are a number of different techniques for detecting genomic biomarkers.

-> At present, the detection techniques for genomic biomarkers are not recorded.

Depending on the detection method, genomic markers follow the Closed World assumption (only detected variants recorded) or an EAV-like Open World assumption (variants are like lab tests and carry a positive or negative result value). Next Generation Sequencing (NGS), karyotyping, FISH, Copy Number Variant (CNV) calling from NGS and peptide sequencing generate findings of aberrant variations only, while RT-PCR, targeted NGS, microarrays, antibody assays and ICH test specific variants and call their absence.

-> Genomic biomarkers can follow the Closed or Open World assumption.

Somatic biomarkers are detected in cancer specimens (biopsies or surgical material).

-> At present, the data model does not associate biomarkers with specimen recorded in the SPECIMEN table.

Intermediate analytes like clones generated from specimen during the detection process are also not captured. Also, complex situation with bone marrow transplants introducing new variants are not covered.

Vocabularies

-> Genomic Biomarkers must be recorded in the OMOP Genomic vocabulary.

There are five different concept classes of variants:

Concept Class Nature of variation Modality Example detection methods
Structural Variant Chromosomal aberration, such as deletion, derivative, dicentric, duplication, isochromosome, insertion, inversion, translocation, monosomy, trisomy, tetrasomy, losses of heterozygosity and microsatellite instability DNA FISH, karyotyping, CNV calling from NGS
Gene DNA Variant Specific small somatic mutation, gene fusion, gene amplification, gene deletion, various exon mutation DNA Targeted NGS, whole genome NGS, RT-PCR, FISH
Gene RNA Variant Specific small mutation RNA, cDNA RNA-seq or exome NGS, SNP-array, targeted NGS
Gene Protein Variant Specific small mutation, protein expression change, cytoplasmic protein expression change, nuclear protein expression change, protein Allred score expression Protein Peptide sequencing, antibody assay, ICH
Gene Variant Not specified Any Any

Structural variants are karyotypes and microsatellite stability measurements. They have no relationship to a specific gene.

Gene DNA, RNA and Protein Variants are concepts that are attributable to a specific gene. If these are small mutations, they specify:

  • The modality (DNA, RNA, protein)
  • An identifier (accession number to one of the genetic databases) of a sequence (genome, chromosome, RNA/cDNA, protein)
  • The location inside the sequence
  • The definition of the mutation (insertion, deletion, substitution) and the affected bases or amino acids.

Unspecific variants with no precise molecular specification are gene fusions, amplifications and deletions (partial or complete) and expression changes.

-> RNA expression changes are currently not supported.

Gene Variants are catch-all concepts that denote any aberration in a gene irrespective of its nature and modality. There is a concept for every gene as defined by the HUGO Gene Nomenclature Committee. The concept name is composed of the HGNC gene symbol, the full gene name in parenthesis and the string "gene variant measurement". The HGNC ID serves as the concept code.

-> With the exception of Gene Variants, OMOP Genomic concept classes are not comprehensive and only cover those that have shown relevance to cancer.

If you believe there is a variant well established as cancer related in your data but missing from OMOP Genomic, contact oncology@ohdsi.org or post it in the OHDSI Forum so it can be added.

genomic_hierarchy

Figure 1: OMOP Genomic concepts are organized in a hierarchical structure.

ETL guideline for Genomic Biomarkers

Genomic data are generated using many different methods (see above) and can be found in a variety of different places in your source data: reports from precision oncology or molecular diagnostics companies, pathology reports, inhouse genomic labs, unstructured reports, etc. Some are also part of complex diagnosis records. In order to identify the correct Genomic Biomarker concept, proceed as following:

  • For Structural Variants, map your source record to the concept name of concepts of the "Structural Variant" class, which except for the microsatellite instabilities strictly follows the International System for Human Cytogenomic Nomenclature (ISCN). Trisomies, tetrasomies and monosomies are spelled out instead of using the + and - notations. In your source, you may find frequent syntax mistakes such as using semicolons instead of commas, incorrect order of elements, using dashes instead of semicolons, misplacing or omitting parentheses, etc.

  • For Gene DNA, RNA or protein small mutation variants, you need information about the modality, the identifier of the sequence, the location coordinates of the base pairs or amino acids and the precise definition of the mutation in HGVS (initially Human Genome Variation Society) notation. Map these to the CONCEPT_SYNONYM records corresponding to concepts of the "Gene DNA Variant", "Gene RNA Variant" or "Gene Protein Variant" classes, depending on what modality your record analyzed. You will find several, but not all possible, valid HGVS synonyms. To support a broader mapping, use Koios, which takes Variant Calling File (VCF) and HGVS formatted input files and maps them to OMOP Genomic concepts. It also knows how to lift over identifiers of different versions and different databases of genomes, chromosomes, RNA, cDNA and protein molecules as well as HUGO gene names as input if the match is unambiguous.

  • For DNA gene amplifications, deletions and various exon variants, map your source information to the HUGO gene symbol and the nature of the variant in the concept name of standard concepts of the "Gene DNA Variant" concept class.

  • For gene fusions, map the two fused gene symbols separated by "::" to the concept name of standard concepts of the "Gene DNA Variant" concept class.

  • For RNA expression changes, OHDSI currently has no standardized way to represent these data. Instead, map it to concepts of the "Gene Variant" concept class (see below).

  • For protein expression changes, map your source information to standard concepts with the HUGO gene symbol followed by "protein expression measurement" and the "Gene Protein Variant" concept class.

  • Place the above matched concepts into the measurement_concept_id field. There are many more variants not relevant to cancer and therefore not in OMOP Genomic. Recording them will overwhelm the system. If you think you have a clinically relevant variant that is not available in OMOP Genomic, contact oncology@ohdsi.org and get it added.

-> If mapping was unsuccessful, you must not record measurement_concept_id=0.

  • For all variants except protein expression variants, the use of value_as_concept_id is optional. Leaving it at NULL indicates the positive fact of the detected variant. But you can write values Positive (same meaning as NULL), Negative or, rarely so, Equivocal into the field value_as_concept_id if the source data indicate such fact.

  • Protein expression records must be either combined with value_as_concept_id of Increased, Decreased or Equivocal, or, if the source data contain quantitative information, a value_as_number and percent in unit_concept_id.

  • Other than for protein expression, there is no use for value_as_number or unit_concept_id.

  • Copy numbers or multiples of expression change are currently not supported.

-> All genomic biomarker records except protein expressions are qualitative.

  • If your source data have information about the corresponding primary cancer, or you obtained it by splitting it from a condition record, place the condition_occurrence_id of that record in the measurement_event_id field and concept condition_occurrence_id in the meas_event_field_concept_id field.

Other Cancer Modifiers

There are a few more Cancer Modifiers, who are not often used in RWE use cases. All of this information is usually provided with pathology lab reports.

  • Extension/Invasion: Defines the local spread of the tumor, both inside an affected organ or into adjacent tissues or organs.

  • Histopattern: Specifies distinct patterns observed in the histological investigation of the tumor beyond the histology information provided through the histology component of the Condition records (see above). These tend to be specific for certain tumor types and can be relevant for prognosis.

  • Topography: These further specifies the precise anatomical structure affected by the tumor growth or its orientation beyond the topography information provided through the topography component of the Condition records (see above). These are specific for certain tumor types and can be relevant for prognosis.

  • Margin: These specify the topography and the content of the surgical resection margins, typically having been assessed during cancer surgery.

Vocabularies

-> All other Cancer Modifiers must be recorded in the Cancer Modifier vocabulary.

Use concepts with the concept classes "Extension/Invasion", "Histopathology", "Topography" or "Margin". Margin concepts are fully pre-coordinated containing the attributes topographical information of the margin (e.g. circumferential, mucosal), orientation of margin with respect to the tumor (e.g. closest, deep), type of surgery (e.g. ampullectomy), additional topography (e.g. bile duct), presence of malignant tissue involved or not involved, type of involvement (e.g. invasive carcinoma), growth pattern of involvement (e.g. focal). The other concepts are simple facts.

ETL guideline for other Cancer Modifiers

In your source data, you will find this information:

  • As a direct structured record,
  • Inside some unstructured text containing a surgery, pathology report or discharge summary,
  • As part of a complex cancer diagnosis. You will have to split this into the proper cancer diagnosis with histology and topography (see above), and this information.

Create Cancer Modifier records as follows:

  • Map this information to a standard Cancer Modifier concept of concept class "Extension/Invasion", "Histopathology", "Topography" or "Margin" and record it in the measurement_concept_id field of the Measurement table. Do not use concepts from other vocabularies (LOINC, SNOMED, NAACCR etc.), even if they contain standard concepts (they will be phased out over time). If mapping was unsuccessful, record measurement_concept_id=0 and place the source concept into measurement_source_concept_id if available.

  • For measurement_date, use the earliest plausible date, which typically is the date of the surgery procedure.

  • Margin records containing distance information should fill the value_as_number and the unit_concept_id fields. The numerical value goes into value_as_number, and the unit into unit_concept_id. For example, say the distance of a sarcoma to the closest margin is given as 0.5 cm, then the values Distance of Sarcoma to Closest Margin, 0.5 and centimeter should be written into these fields, respectively. For the other Cancer Modifiers the fields value_as_concept_id and value_as_number must be set to NULL.

  • If your source data have information about the corresponding primary cancer, or you obtained it by splitting it from a condition record, place the condition_occurrence_id of that record in the measurement_event_id field and the concept condition_occurrence_id in the meas_event_field_concept_id field.

Procedures, including Drug Treatments

Procedures are records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.

-> Diagnostic procedures in cancer are handled no differently than in the general OMOP CDM.

There are several therapeutic procedures, or treatments, in cancer:

  • Cancer Surgery aims at removing the tumor or parts of it with the surrounding tissue, or the entire organ. It isn't one single thing, but an entire ecosystem of surgical approaches, each designed for a different purpose. Typically, they are defined by their target organ, their purpose (curative, preventive, diagnostic, staging, supportive, palliative, reconstructive) and by their technique (open, minimally invasive, robotic, cryosurgery, laser surgery). Some of them are named after their inventors. Bone marrow transplantations also belong into this category, even though not a classical surgery procedure.

-> There is no standard method to infer that a surgery is treating a cancer condition.

  • Radiotherapy is either external beam radiation therapy or brachytherapy (internal radiation).

-> At present, we do not have a system for recording detailed radiation field and dose information.

  • Drug therapy consists of chemotherapy (poisoning fast growing cells), targeted therapy (blocking specific molecular pathways), immunotherapy (inducing the immune system to attack the cancer) and hormone therapy (slowing the cancer by signaling through hormone receptors). These therapies involve the administration of a drug, which is usually recorded in the DRUG_EXPOSURE table, if the precise drug is known. If, however, the data only capture the category of a drug therapy it must be recorded in the PROCEDURE_OCCURRENCE table.

-> Drug classifications must be recorded as Procedures.

  • Investigational therapies: These are given as part of a clinical trial. Many source data contain the fact of a clinical trial, but often without given any detail. For example, the administered drugs might be recorded as "investigational drug". If all treatment information is available, it should be recorded as per OMOP CDM specifications, including drugs in DRUG_EXPOSURE. Otherwise,

-> Treatments administered as part of clinical trials without detail must be recorded as Procedures.

Vocabularies

-> Procedures must be recorded using concepts of the "Procedure" domain, which can come from a variety of vocabularies.

The only exception is Clinical drug trial, which currently is an "Observation" domain concept till a vocabulary update will rectify this situation. Also, there is no comprehensive and hierarchical system of Procedures, and there is also no comprehensive and hierarchical system of cancer surgeries and radiotherapies.

ETL guideline for Procedures

Write Procedure records according to the general OMOP CDM instructions. Special cancer therapy handle as following:

Observation Periods

The rules for Observation Periods do not differ from the general OMOP CDM specifications. The Observation Period defines the span of time during which events are recorded and, more importantly, the absence of records indicates that nothing occurred. However, often time cancer data contain death information from different sources than the rest of the patient history, and when that happens often at a much later time.

-> Observation Periods must not be artificially extended until the time of death.

Episodes

Episodes aggregate lower-level clinical events (Conditions, Drug Exposures, Procedures, Device Exposures) into a higher-level abstraction representing clinically and analytically relevant disease phases, outcomes, and treatments. There are four types of Episodes

  • Disease Episodes
  • Disease Dynamic Episodes (Remission, Complete Remission, Partial Remission, Stable Disease, Progression)
  • Disease Extent Episodes (Metastatic, Invasive, Confined)
  • Treatment Episodes (Treatment Regimen, Treatment Cycle)

Since Episodes refer to and are sometimes derived from Condition, Drug Exposure and Procedure data, they are best written after all other OMOP tables are completed.

Vocabularies

-> Episodes must be recorded in the Episode vocabulary.

Each concept class corresponds to the above four types, with altogether 14 concepts.

Disease Episodes

This is the time interval that spans all events related to a cancer. It starts at the day of the first cancer condition record and ends with the complete healing or the death of the patient. The Disease Episode is the parent for the other Disease (Disease Extent, Disease Dynamic) and Treatment Episodes.

ETL guideline for Disease Episode

Start creating Disease Episodes after having all other OMOP event tables in place. At a minimum you must do the following:

  • Place the concept Disease Episode into episode_concept_id.

  • Copy the condition_start_date field of the first Condition Occurrence of the cancer into episode_start_date and the condition_concept_id into episode_object_concept_id.

  • Connect the first occurrence record to this Episode through a record in the EPISODE_EVENT table: copy the Episode's episode_id, place the condition_occurrence_id of the Condition record in the event_id field and the concept condition_occurrence_id in the episode_event_field_concept_id field.

  • Leave the episode_parent_id and episode_number NULL.

If available in the source data, you can add the following information:

  • Connect other records from any event tables that are relevant to the diagnosis and management of the cancer by creating another EPISODE_EVENT connector record: copy the Episode's episode_id, place the primary key field (ending in _id) of the event table record in the event_id field and the field concept of that primary key field in the episode_event_field_concept_id field.

  • If the patient has died, or if the disease has been resolved and no relapse is expected, place that date into the episode_end_date.

Disease Dynamic Episodes

Disease Dynamic Episodes refer to time frames during which a patient's cancer status remains consistent, outlining the course of the disease. A complete remission is stated either immediately after a curative surgery or following radiation or drug treatments, upon records of resolved metastases or node involvement and absent biomarker levels. If remission is only partial, it's noted accordingly through metastasis or node events reduced in their dimension, or a decrease in the biomarker level. If the changes are inconclusive a mere remission is stated. If there are no signs of change, or if metastases, nodes, and biomarkers show no improvement, the disease is classified as stable. Progression is marked by events such as new or growing metastases or node involvement, a new tumor invasion, rising biomarker levels on lab tests, complications, or the initiation of another treatment.

-> There is currently no commonly accepted set of rules for determining Disease Dynamic Episodes across all cancers.

ETL guideline for Disease Dynamic Episode

-> If the required information is not available in the source data, do not write these Episodes.

Start creating Disease Dynamic Episodes after having all other OMOP event tables and the Disease Episode (see above) in place as follows:

  • Place one of the Disease Dynamic Episode concepts Remission, Complete Remission, Partial Remission, Stable Disease and Progression into episode_concept_id.

  • Copy the start date of the trigger event such as surgery (in case of remission) or metastasis, node, lab test, condition or drug exposures into the episode_start_date. If there is more than one trigger event select the first one.

  • Set the episode_end_date to the day before the episode_start_date of the following Dynamic Episode, when you write that.

-> There must only be one Dynamic Episode active at any period of time, adjacent Episodes must not overlap.

  • Leave the episode_object_concept_id and the episode_number NULL.

  • If available and the source provides a clear association to the Disease Episode, place its episode_id in the episode_parent_id.

  • Connect all trigger event records to this Episode through a record in the EPISODE_EVENT table: copy the Episode's episode_id, place the primary key field (ending in _id) of the trigger event table record in the event_id field and the field concept of that primary key field in the episode_event_field_concept_id field.

Disease Extent Episodes

Disease Extent Episodes refer to how widely cancer has spread. Like Disease Dynamic Episodes, they should be sourced directly from the source or abstractions. Typically, Extent Episodes progress from Confined to Invasive and/or Metastatic, and this process is irreversible. An Invasive Disease Episode begins when there is evidence of invasion or extension outside the primary organ, involvement of a local lymph node, or staging/grading that suggests an invasive disease. Metastatic Disease Episodes begin when a metastasis is detected, a distant lymph node is involved, or staging/grading indicates metastatic disease. If neither invasive nor metastatic indicators are present, or cancer modifiers suggest no evidence of invasion, metastases or lymph node involvement, or the diagnosis is an in-situ Condition, the Disease Episode is considered Confined.

-> There is currently no commonly accepted set of rules for determining Disease Extent Episodes across all cancers.

ETL guideline for Disease Extent Episode

-> If the required information is not available in the source data, do not write these Episodes.

Start creating Disease Extent Episodes after having all other OMOP event tables and the Disease Episode (see above) in place as follows:

  • Place one of the Disease Extent Episode concepts Confined Disease, Invasive Disease or Metastatic Disease into episode_concept_id.

  • Copy the date of the trigger event such as a metastasis, lymph node or staging/grading cancer modifier Measurement event into the episode_start_date. If there is more than one trigger event, select the first one.

  • Set the episode_end_date of a Confined Disease Episode to the day before the episode_start_date of an Invasive or Metastatic Disease Episode, when you write that. Leave the episode_end_date of Invasive and Metastatic Episodes NULL or set it to the death date or episode_end_date of the Disease Episode of the patient.

-> There must only be one Confined, Invasive and Metastatic Disease Episode per patient.

  • Leave the episode_object_concept_id and the episode_number NULL.

  • If available and the source provides a clear association to the Disease Episode, place its episode_id in the episode_parent_id.

  • Connect all trigger event records to this Episode through a record in the EPISODE_EVENT table: copy the Episode's episode_id, place the primary key field (ending in _id) of the trigger event table record in the event_id field and the field concept of that primary key field in the episode_event_field_concept_id field.

Treatment Episodes

Cancer treatment consists of a toolbox of very different strategies that can be combined depending on the cancer, stage, biology, and the patient's goals. The major categories are cancer surgery, radiotherapy and drug therapy.

Radiotherapy and drug therapy are often, but not always, administered in complex protocols of regimens, which is given in repeating cycles. These regimens can combine surgery, radiation and drugs.

-> Not all source data have detailed regimen and cycle information, but it can be inferred from Procedure and Drug data.

Some data have information about actual administrations of regimens, others have treatment plans or intentions. As in other drug records, the administration is preferred.

ETL guideline for Treatment Episode

Start creating Treatment Episodes after having all other OMOP event tables and the Disease Episodes in place, and if needed Artemis run (see below), as follows:

-> Precise Episode start and end dates are very important for many cancer use cases.

  • The content of the episode_object_concept_id depends on the episode_concept_id: For Cancer Surgery, Cancer Radiotherapy and Cancer Drug Treatment Episodes copy the content of the procedure_concept_id field of the PROCEDURE_OCCURRENCE table (see above). For Treatment Regimen and Treatment Cycle Episodes use concepts from the HemOnc vocabulary and Regimen class. These concepts need to be mapped from the source data or inferred using Artemis. Artemis needs to be run on the data with the DRUG_EXPOSURE and PROCEDURE_OCCURRENCE tables in place.

-> Surgery, Radiotherapy and Drug Treatment Episodes can overlap with each other and with Regimen and Cycle Episodes. Regimen Episodes must not overlap with each other.

-> A Regimen must contain all its cycles. There must not be Cycle Episodes free floating or stretching beyond the start and end date of a Regimen Episode.

  • Count the Regimen Treatment Episodes chronologically, and the Treatment Cycle Episodes within a Regimen and place the number in episode_number. For all other Treatment Episodes keep this field at NULL.

  • If available and the source provides a clear association to the Disease Episode, place its episode_id in the episode_parent_id.

  • Connect all Procedure and Drug Exposure event records to this Episode through a record in the EPISODE_EVENT table: copy the Episode's episode_id, place the primary key field (ending in _id) of the event table record in the event_id field and the field concept of that primary key field in the episode_event_field_concept_id field.

Data Sources

Various sources contribute to the generation of real-world cancer data, each presenting distinct advantages and limitations. No single source offers comprehensive coverage of all aspects of cancer patients' disease history or associated risk factors. Therefore, an optimal approach for cancer research involves aggregating multiple data sources for each patient.

Since data can come from different sources, which carry a different level of detail and reliability, choosing the Type Concepts will preserve this provenance.

General EHR

Electronic Health Record (EHR) data comprise both structured and unstructured elements. Structured components are primarily designed to collect information pertinent to billing, whereas unstructured texts, such as discharge summaries, imaging reports, and pathology findings, provide more in-depth clinical details. Due to the challenges involved in extracting data from unstructured records, most EHR databases have limited depth of clinical information. For instance, diagnoses are often coded using ICD-10, which lacks specificity regarding histology ("shallow conditions") and cancer modifiers such as stage, grade, metastasis, and lymph node involvement. However, EHRs generally deliver robust longitudinal data concerning treatments and their outcomes, although they often do not adequately capture complex treatment regimens.

Records obtained from EHR systems should be labeled with the most detailed Type Concept possible: EHR note, EHR order, EHR prescription, EHR administration record, EHR admission note, EHR ancillary report, EHR billing record, EHR chief complaint, EHR discharge record, EHR discharge summary, EHR dispensing record, EHR encounter record, EHR episode record, EHR inpatient note, EHR medication list, EHR nursing report, EHR outpatient note, EHR physical examination, EHR problem list, EHR referral record, EHR emergency room note or EHR prescription issue record, and if these don't fit simply EHR. Lab reports should be labeled Lab. Data from the pathology lab should go under EHR Pathology report, while imaging results under EHR radiology report. Regimens derived from Drug Exposure or Procedure data should be tagged as Standard algorithm from EHR. Data extracted from unstructured notes should be identified as NLP.

Cancer EHR

Cancer-specific EHR systems typically supplement standard institutional EHR platforms. These additions can offer more comprehensive diagnostic details and detailed regimen planning information tailored to oncology patients.

Type Concepts should be used equivalently to general EHR-derived records. Treatment plans should be labeled EHR planned dispensing record.

Specialty Systems in Healthcare

Radiology and pathology departments often use their own specialized systems, which contain comprehensive details about imaging procedures (including both technical specifications and results) as well as information on pathology procedures. Because these systems are not standardized, integrating them into a common framework like the OMOP CDM is challenging.

Tumor Registries

Tumor registries are widely established in numerous countries and compile abstracted information, meaning data is collected, summarized, and standardized by trained abstractors for each individual case. Such registries tend to maintain high-quality standards for coding diagnoses, cancer modifiers, certain risk factors, and screening procedures. Nonetheless, the registry format is often intricate and subject to frequent changes, posing challenges for longitudinal analytics. Additionally, registries generally cease data collection following initial diagnosis and commencement of treatment, which complicates long-term follow-up and outcome studies.

Tumor Registries data are often a mixture of facts about the patients and administrative data and metadata about the process of registry abstraction and reporting. They also contain many flavors of NULL facts records. For purposes of the OMOP CDM, only the former need to be transformed, and flavors of NULL can be omitted entirely.

The Type Concept for Tumor Registries is Registry.

Death Certificates and Death Index Files

Death certificates are standardized legal documents. The information relevant for placing them into Real-World data are demographic information, date and time of death, place of death (e.g., hospital, home, hospice, nursing facility) and cause of death, often structured as immediate cause, underlying cause and contributing conditions. Some government institutions collect these centrally and make them available in Death Index Files, that could be linked to the patients through identifying information.

The Type Concept for these data is Death Certificate (if obtained individually) or US Social Security Death Master File for the large collections.

NGS Sequencing Pipelines

Next Generation Sequencing (NGS) pipelines is a sequence of automated data processing steps that transform raw sequencing data into clinically interpretable genetic variants. The pipelines can be homegrown or commercial products.

DNA (whole genome) or RNA (exome) extracted from a patient's biological material, such as blood or tumor tissue, is first processed by being fragmented, tagged, and run through automated sequencing machines. This produces raw sequencing outputs, typically in FASTQ format. These files undergo base calling and quality control to generate sequence files (usually FASTA), which are then aligned to standard genomic reference sequences (e.g., GRCh38). Through this alignment, the pipeline identifies genetic variants, including SNPs, insertions/deletions, and structural variations. Alignment data are stored in BAM files, while the list of detected variants is captured in VCF files. This process produces roughly 4 million potential mutations, and a few thousand structural aberrations, but only a small subset is clinically relevant. To isolate those, an additional filtering step matches the detected variants against curated databases such as ClinVar and COSMIC.

Most of this information is irrelevant for OMOP, and you only need to capture the mutation information from the VCF files (sequence, location, mutation detail) and the structural variations that exist in the OMOP Genomic vocabulary.

There are currently no Type Concepts for these data.

Molecular Labs

A range of laboratory methods can produce molecular biomarker data for patients, including karyotyping, FISH, copy number variant (CNV) calling from NGS, peptide sequencing, RT-PCR, microarrays, antibody assays, and immunohistochemistry. Some of these techniques are also used in pathology laboratories and may appear within pathology reports. Because the structure, output, and clinical context of these methods vary widely, the ETL process for molecular data is highly dependent on the specific source and lacks a unified standard approach.

There are no Type Concepts for these data.

Molecular Diagnostics Providers

These are commercial vendors that provide data on somatic variants (SNVs, indels, copy-number changes, selected structural variants/fusions), tumor mutational burden or microsatellite instability (MSI). These data are paired with gene-level and pathway-level summaries of the findings and clinical interpretations to their pathogenic or prognostic impact and potential clinical actions. These data are typically provided as PDF, JSON or XML files, and need to be parsed to become input for ETL processes.

There are no Type Concepts for these data.

Clone this wiki locally