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?
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.
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.
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.
@QI_omop - Fantastic Graphic! Could I post that on LinkedIn? Whom could I attribute it to?
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:
‘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.
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?
Yes, I agree, this is definitely redundant Denormalizing data isn’t something done in the CDM. And is quite prone to error. What’s the “analytical purpose”?
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.
This is an excellent explanation, thank you @mgurley!
Edit: Knowing the intent of the Oncology Extension allows me to further grasp the guiding principles for these data.
According to this presentation, modifiers can only relate to the overarching episode. Are you saying that we can link modifiers not only with the overarching episode but with child episodes (extent/dynamic) as well?
By linking table do you mean episode_event table?
Good catch. I will clarify with @rimma and @Christian_Reich their vision of EPISODE modifiers: the overarching episode or child episodes. The NAACCR ETL was written against a prior iteration of the Oncology Extension that did not contain the concept of an ‘Overarching Episode’. So this issue was formerly moot.
My own take is that trying to pile all the modifiers into an overarching episode does not make sense. My original vision of the Oncology Extension was to associate modifiers with each clinically important phase of the disease. So if a patient had a biopsy confirming a Gleason 4+3 prostate cancer, you would associate the Gleason 4+3 modifier with an initial child disease episode. And then if the patient had a prostatectomy confirming a Gleason 4+4 disease, you would create a subsequent disease episode as a child of the first and associate the Gleason 4+4 modifier with the subsequent disease episode.
By linking table I do mean a table like EPISODE_EVENT. And perhaps EPISODE_EVENT could serve this purpose. Letting us actually leave MEASUREMENT alone, unaltered. One that would not require us to create multiple entries in the MEASUREMENT table but just point an entry to multiple clinical event tables.
@mgurley have you clarified the vision of EPISODE modifiers ?
Plus, in CDM v5.4 there is two polymporphic fields in the MEASUREMENT table :
while in the oncology extension, the two fields added are :
My assumption is that it is the same thing (correct me if I’m wrong) but what name should we use ?
@Rosnyni The clarity of the EPISODE modifiers is coming. Sorry for the delay.
Regarding your second question, yes, measurement_event_id and meas_event_field_concept_id are the correct names of the columns that were formerly known as modifier_of_event_id and modifier_of_field_concept_id in the Oncology Extension DDL prior to CDM 5.4. I confirmed with @clairblacketer and the change was made to make the columns in line with naming conventions for polymorphic foreign keys in other 5.4 CDM tables:
The one outlier is COST:
According to @clairblacketer, that table is still being evaluated.
Wired, I don’t receive any notification about your answer
However thank you for your answers.
Of course, I’m still interested in a clear view of EPISODE modifiers.