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?
1 Like
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.
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.
1 Like
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.
1 Like
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:
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.
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?
1 Like
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.
1 Like
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.
2 Likes
Hello
@mgurley have you clarified the vision of EPISODE modifiers ?
Plus, in CDM v5.4 there is two polymporphic fields in the MEASUREMENT table :
- measurement_event_id
- meas_event_field_concept_id
while in the oncology extension, the two fields added are : - modifier_of_event_id
- modifier_of_field_concept_id
My assumption is that it is the same thing (correct me if Iâm wrong) but what name should we use ?
Sincerely
Nicolas
@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:
NOTE
note_event_id
note_event_field_concept_id
OBSERVATION
observation_event_id
obs_event_field_concept_id
EPISODE_EVENT
event_id
episode_event_field_concept_id
MEASUREMENT
measurement_event_id
meas_event_field_concept_id
The one outlier is COST:
COST
cost_event_id
cost_domain_id
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.