Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Oncology Treatment Proposal #163
We want to represent oncology treatments within the OMOP CDM. Perhaps there is no problem. Why not use DRUG_EXPOSURE and PROCEDURE_OCCURRENCE? Because oncology treatments often create a clinical event welter that thwarts many analytic use cases. Instead, we want a concept that aggregates lower-level clinical events into a higher-level abstraction. Some examples of clinical event welter:
Radiation Therapy Treatment Welter
This treatment spawns 72 entries using 11 CPT codes in the PROCEDURE_OCCURRENCE table covering the radiation therapy treatment lifecycle: radiation therapy management, radiation therapy simulation, radiation therapy planning and radiation therapy delivery:
Drug Therapy Treatment Welter
This treatment spawns 22 entries using 5 CPT codes in the PROCEDURE_OCCURRENCE table and 50 entries using 13 RxNorm codes in DRUG_EXPOSURE table.
In the oncology community there is a widely shared TREATMENT concept: tumor registries, practice guidelines, clinical trials databases and oncology analytic platforms all employ the concept of a TREATMENT. The TREATMENT concept aggregates lower-level clinical events into a higher-level abstraction. But we still want this higher-level abstraction TREATMENT concept to connect to lower-level clinical events.
Can we have both the benefit of a higher-level oncology TREATMENT abstraction and connection to lower-level clinical events? Can we find a place for pre-made oncology TREATMENT abstractions connected to lower-level clinical events? Conversely, can we derive higher-level oncology TREATMENTs from lower-level clinical events ? Finally, can we attach unconnected available pre-made oncology TREATMENT abstractions to lower-level clinical events?
Making room for a TREATMENT concept in the OMOP CDM will afford a number of benefits:
Add support for a TREATMENT domain within the OMOP CDM.
We will out outline two possible implementation options. Option A and Option B.
Tables (Option A)
Tables (Option B)
A TREATMENT can be delivered at regular intervals, fractions or cycles. This temporal grouping of clinical events will only be instantiated if it is available within a source system. A TREATMENT_CYCLE will not be algorithmically derived.
Connect qualifying DRUG_EXPOSURE or PROCEDURE_OCCURRENCE to the appropriate TREATMENT entry by populating the TREATMENT_EVENT table.
TREATMENT table columns demanding new concepts are as follows:
The Treatment Concept domain is partially based on the NCI CRN ‘Cancer Therapy Look-up Tables’.) https://crn.cancer.gov/resources/codes.html. Entries will be made in the CONCEPT_RELATIONSHIP table using the existing ‘"Maps to" and "Mapped from" relationships based on the NCI CRN ‘Cancer Therapy Look-up Tables’ that link National Drug Codes (NDCs), procedure codes (CPT4, ICD-9, HCPC) and diagnosis codes (ICD-9) to Treatment Concepts.
The Treatment Type vocabulary:
The Treatment Intent vocabulary:
The Treatment Status vocabulary:
TREATMENT_MODIFIER table columns demanding new concepts are as follows:
The Treatment Modifier domain:
The Treatment Modifier Value domain:
The Drug Regimen Value domain is based on National Tariff Chemotherapy Regimens List. See here:
Option A Algorithms
Option B Algorithms
Good proposal. As per my forum message on tracking patient treatments I have a similar requirement to store treatment level data related to various cancer treatment methods. And as the proposal suggests there a bunch of data that relates to the overall course of treatment that has no natural location within OMOP today that is easily / efficiently accessible. Option A of the proposal is the most appropriate approach from the perspective of my use cases anyway. My use cases at present all relate to cancer treatment but the approach suggested can be used for any chronic condition where there is a course of treatment. I image that CNS conditions would benefit from such a construct.
The TREATMENT domain in conjunction with the TREATMENT_MODIFIER would support all of the my requirements. I have a whole series of “modifiers” that I need to capture at a treatment level such as “whether it was completed or not” or specific side effects and their date of occurrence. These “modifiers” could also easily be considered OBSERVATIONS and I believe in my case all of the data that would be collected as part of a TREATMENT could just as easily be stored in the OBSERVATION table. In which case the OBSERVATION table should also have a TREATMENT_ID column added in to relate them to a specific treatment.
The proposal of adding a TREATMENT ID to the DRUG_EXPOSURE and PROCEDURE_OCCURRENCE table to link these events to a specific treatment I suggest should also be extended to the VISIT_OCCURRENCE table. This would allow for any events related to a patient visit whether they are related to a specific procedure, drug exposure or otherwise to be linked back to a treatment where the visit is part of a specific treatment.
Just a few thoughts…..
Thanks for the feedback.
If we ingest into OMOP Vocab NCI CRN ‘Cancer Therapy Look-up Tables, we should think of non-US contries.
see these examples from here
If we formulate smart constructs in OMOP Vocab, we should not do it off copyrighted CPT4 codes.
One of the main issues this proposal is trying accomodate is the varying levels of grouping/abstraction of lower-level clinical events available within various source systems. Sometimes:
I think we mean, TREATMENT domain. i.e. just like we have Visit domain, condition domain.
Could you please clarify - 'treatment cycles will not be algorithmically derived' vs. 'Treatment abstractions will be algorithmically derived'
Can the person have different treatment_id's with the same or overlapping treatment start date and treatment end date? (I think the answer is yes). Could you please give some examples?
can you please elaborate this field with an example. E.g. if this is the third chemoRx cycle of a planned treatment of 6 cycles, what value would be in treatment_cycle_number. I think it is proposed to be increment count - e.g. in this case, it would treatment_cycle_number = 3? What is a 'parent Treatment' in this case - maybe the treatment that encompasses all six chemoRx cycles? How can the analyst know for example -- 6 chemoRx were planned, and only 3 were done so far?
To identify if the table is procedure_occurrence, condition_occurrence, visit_occurrence etc., I think it is best if we support this proposal (use table_concept_id instead of ambiguous domain_concept_id )
This table seems like a detail of the TREATMENT table. For every record in the TREATMENT table there may 0 or more records in TREATMENT_MODIFIER table?
We need to find a mapping from vocabulary codes used to represent oncology treatment low-level clinical events to a high-level typing of oncology treatments. This is what NCI CRN ‘Cancer Therapy Look-up Tables' provides. For radiation therapy, it maps 'CPT4', 'HCPC' and 'ICD9' codes. This was based on the actual codes present in the VDW instance upon which it was developed.
On related note, The NCI has recently released a parallel effort called the 'Observational Research in Oncology Toolbox'. See here: https://seer.cancer.gov/oncologytoolbox/. This effort similarly maps vocabulary codes used to represent oncology treatment low-level clinical events to a high-level typing of oncology treatments. A very attractive feature of the 'Observational Research in Oncology Toolbox' is that its high-level typing of oncology treatments is based on and can be connected to tumor registry NAACCR/SEER treatment variables. So far the 'Observational Research in Oncology Toolbox' has only released a mapping for Oncology Drugs, but it is planning on releasing mappings for radiation therapy and surgical oncology. I will be replacing the 'NCI CRN ‘Cancer Therapy Look-up Tables' within the proposal with the 'Observational Research in Oncology Toolbox'. However, your advice about making sure the mappings do not rely on copyrighted non-standard codes will still hold true.
You are right. Changed it.
See my response to @vojtechhuser first comment. But basically, in the best case neither Treatments nor Treatment Cycles will need to be algorithmically derived if they are present within your source system. However, if Treatments and Treatment Cycles are not present within your source system, I think it will only be possible to derive Treatments and not Treatment Cycles.
Yes, a person could have two Treatments with overlapping start and end dates. For example, my Radiation Therapy Beam IMRT treatment could overlap with my Drug Therapy Hormonal treatment.
The treatment_cycle_number field is supposed to represent the actual number cycle that was executed. So not necessarily incrementing, if for some reason a cycle is skipped.
Sounds good. We should follow the emerging OMOP/OHDSI standards. I will change the proposal to adhere to the proposal you pointed to.
This response is a repeat of what I have said to @ColinOrr2008. We are proposing the TREATMENT_MODIFIER structure/domain instead of using references to OBSERVATION/MEASUREMENT via FACT_RELATIONSHIP or adding foreign keys to them in order move to more tightly-scoped EAV structures/domains. We are doing likewise in a separate Diagnosis Modifier proposal for the myriad oncology diagnosis modifiers: staging, grade, lymphatic invasion, biomarker results, etc. EAV is a necessary evil in healthcare. But there are ways to make it less evil. To quote @cgreich, MEASUREMENT and OBSERVATION are "garbage cans". We are just trying to organize our garbage cans. Like separating into compost, waste, paper, aluminum/plastic.