OHDSI Home | Forums | Wiki | Github

Oncology extension


(Melanie Philofsky) #1

The instructions for the Oncology extension are unclear. When the MEASUREMENT.modifier_of_event_id references the Episode table, what does the MEASUREMENT.modifier_field_concept_id reference? The EPISODE.episode_concept_id or EPISODE.episode_object_concept_id or?

@Christian_Reich, @Dymshyts, @mgurley


(Dmytry Dymshyts) #2

EPISODE.Episode_id.
Or I just don’t understand your question:)
Because it seems to be the very easy answer - EPISODE.Episode_id is even said in the table above.


(Philip Solovyev) #3

Agree, here the measurement record modifies the episode record, so modifier_of_event_id will be populated with the id of the episode (episode.episode_id) and to give instructions where (what table and field) to look for that id, modifier_field_concept_id is populated with the concept referencing episode.episode_id, i.e., 35225441.


(Qi Yang) #4

This maybe another topic but I will address it here anyway.

The answer to this question is actually a little bit more complicated. The modifier can be a modifier of either episode table or other clinical event tables, such as condition_occurrence table. As a matter of fact, when @mgurley designed the NAACCR ETL, the same modifier in the measurement table has been duplicated and linked to both episode and condition_occurrence tables. This seems to be redundant but it serves analytical purposes. Please see picture below and pay attention to the lines that link tables.


(Dermot Doyle) #5

@QI_omop - Fantastic Graphic! Could I post that on LinkedIn? Whom could I attribute it to?


(Qi Yang) #6

@Dermot_Doyle

Attribute to the Oncology Work Group team. I am not sure if this can be posted on LinkedIn. It is a question for @Christian_Reich @rimma @mgurley.


(Dermot Doyle) #7

Okay, I wait on permission. My interest is that it’s an interesting way to represent health data discovery, and can be a nice plug for OHDSI as well:grin:


(Melanie Philofsky) #8

Thank you @Dymshyts and @Philip_Solovyev,

‘TBD’ in my screenshot should have concept_id = 35225441

When I look this up in Athena, I see it is for OMOP CDM Version 6.0.2

I am working with CDM v.5.3.1 with the Onco extension. Is it ok to break the designation of V6.0.2? Or is there a more appropriate concept_id to use? If 35225441 is used for all versions of the CDM with Onco extension, would someone add it to the documentation to replace “TBD”?

Thanks, @QI_omop, for your answer. My question is specific to Measurement:Episode linkage.


(Michael Gurley) #9

@Dermot_Doyle @QI_omop

Yes no problem using the graphic. Everything is open source.


(Dmytry Dymshyts) #10

It’s OK to use this one, with version 6.02. The onco-extension meant to be a part of version 6. Since, a lot of people still uses V5.3 it becomes an extension.
@Christian_Reich can you please remind me what was the point of adding those links to a CDM version?


(Melanie Philofsky) #11

Yes, I agree, this is definitely redundant :slight_smile: Denormalizing data isn’t something done in the CDM. And is quite prone to error. What’s the “analytical purpose”?


(Michael Gurley) #12

@MPhilofsky

The oncology extension is trying to reflect the course of a patient’s cancer disease and the treatments employed to address the disease. Thus, there should be one and only one entry representing the beginning of the disease and each subsequent change in disease extent (Confined Disease, Regional Invasive Disease, Distant Metastatic Disease) and disease dynamic (Stable Disease, Remission, Partial Remission, Complete Remission). Each phase of the disease will have cancer modifiers that further refine the characterization of the disease phase. For example, ‘TNM Staging Group’, ‘Biomarkers’ and ‘Lymphatic Invasion’. These are the entries in the MEASUREMENT table that point to the EPISODE via the new polymorphic fields: modifier_of_event_id/ modifier_of_field_concept_id.

Likewise, for treatments. There should be one and only entry representing each therapeutic/diagnostic intervention attempting to address a cancer disease. Represented at a level of abstraction that is in sync with common clinical sense. For example, ‘External beam radiotherapy’ or ‘Hormonal Therapy’ or ‘Bevacizumab and Rituximab’ or ‘Prostatectomy’. Each treatment may have modifiers that further refine the characterization of the treatment. Like ‘Total Dose cGy’ or ‘Gross Total Resection’. These are the entries in the MEASUREMENT table that point to the EPISODE via the new fields: modifier_of_event_id/ modifier_of_field_concept_id.

Traditional OMOP has a different purpose: to represent the data collected during the course of the delivery and administration of clinical care. Thus, the same diagnosis may appear in CONDITION_OCCURRENCE multiple times not because it necessarily represents a clinically meaningfully change in the course of a patient’s disease bur rather an operationally meaningfully event for the healthcare institution. The OMOP Oncology extension is attempting to carve out a space within OMOP for the representation of the clinical course and treatment of a cancer diagnosis that rises above the transactional clutter of vanilla OMOP.

Now when we begin to ingest sources like tumor registry data, as in the NAACCR ETL, the challenge is that tumor registries are tracking data at the exact same level as the Oncology Extension. At the EPISODE level. Tumor registries do not have secondary workflow, transactional and financial purposes. Their one and only purpose is to track the clinical evolution and treatment of a patient’s cancer diagnosis. The NAACCR ETL could have skipped the insertion of any data into the traditional OMOP clinical event tables: CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE and DRUG_EXPOSURE. But instead we decided to enter data at both levels: the traditional clinical event tables and the EPISODE tables. This was because we did not want to dictate to a user of the NAACCR ETL what level of analysis they should operate on. If a user wants to ingest NAACCR data into the cacophony of the existing OMOP clinical event tables, interspersed with EHR/claims data, then they can perform an analysis at the traditional level. But at the same time the NAACCR ETL will also insert into the EPISODE level a less cluttered representation of the patient’s clinical course.

I do agree that duplicating entries in the MEASUREMENT table does cause problems because the entries are living at both levels. The traditional OMOP clinical events level and the EPISODE level. If we had used a linking table to connect MESUREMENT entries to EPISODE entries instead of the polymorphic modifier_of_event_id/ modifier_of_field_concept_id, we could have avoided this duplication. Maybe that decision could be revisited, as the extension has not been officially released on CDM 6.1 yet. I will bring it up as an issue to discuss.


t