-
Notifications
You must be signed in to change notification settings - Fork 458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Oncology Treatment Proposal #163
Comments
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….. |
Is there any reason this cannot be used for non-cancer treatments that have some or all of the same requirements/challenges? Seems it has been designed without cancer specificity enough to accommodate others. ? |
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. |
@vojtechhuser 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. |
It would be nice to have same sample data and show all the issues in an example context. |
Agree 100%. Will have to create that. |
I will create some sample data. Sample data will make it concrete how source systems (EHR data and Tumor Registry data) with varying degrees of treatment abstractions natively can ETL into the model. |
closing as this is covered by #216 |
Oncology Treatments
Background
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.
TREATMENT Concept
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:
Proposal
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)
TREATMENT Table
The TREATMENT table contains records aggregating lower-level clinical events (DRUG_EXPOSURE and PROCEDURE_OCCURRENCE) into a higher-level abstraction representing an extended diagnostic or therapeutic intervention for specific patient condition(s). A TREATMENT can be delivered at regular intervals, cycles or fractions. The temporal grouping of clinical events into cycles will only be instantiated if it is available within a source system. TREATMENT cycles will not be algorithmically derived. Pre-made higher-level TREATMENT abstractions present in a source systems will be directly inserted. Alternatively, when not available within any source system, TREATMENT abstractions will be algorithmically derived from lower-level clinical events.
Conventions
TREATMENT_MODIFIER Table
The TREATMENT_MODIFIER table contains records that attribute properties to a treatment. These properties should further refine the description of the treatment. Most often these modifiers will point to a TREATMENT table entry but also possibly a PROCEDURE_OCCURRENCE table entry or a DRUG_EXPOSURE table entry. Some examples: attribution of a known Drug Regimen concept to a Drug Therapy treatment; number of fractions, anatomical target, total dose in cGy for Radiation Therapy treatment.
Conventions
DRUG_EXPOSURE Table
Amendments required to the DRUG_EXPOSURE table are as follows:
Conventions
PROCEDURE_OCCURRENCE Table
Amendments required to the PROCEDURE_OCCURRENCE table are as follows:
Conventions
Tables (Option B)
TREATMENT Table
The TREATMENT table contains records aggregating lower-level clinical events (DRUG_EXPOSURE and PROCEDURE_OCCURRENCE) into a higher-level abstraction representing an extended diagnostic or therapeutic intervention for a specified patient condition. Pre-made higher-level TREATMENT abstractions present in a source systems will be directly inserted. Alternatively, when not available within any source system, TREATMENT abstractions will be algorithmically derived from lower-level clinical events.
Conventions
TREATMENT_MODIFIER Table
The TREATMENT_MODIFIER table contains records that attribute properties to a treatment. These properties should further refine the description of the treatment. Most often these modifiers will point to a TREATMENT table entry but also possibly a TREATMENT_CYCLE table entry, a PROCEDURE_OCCURRENCE table entry or a DRUG_EXPOSURE table entry. Some examples: attribution of a known Drug Regimen concept to a Drug Therapy treatment; number of fractions, anatomical target, total dose in cGy for Radiation Therapy treatment.
Conventions
TREATMENT_CYCLE Table
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.
TREATMENT_EVENT Table
Connect qualifying DRUG_EXPOSURE or PROCEDURE_OCCURRENCE to the appropriate TREATMENT entry by populating the TREATMENT_EVENT table.
Vocabulary
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:
https://hscic.kahootz.com/gf2.ti/f/762498/27839109.1/XLSX/-/NatTarChemoRegList1718.xlsx
And here:
https://hscic.kahootz.com/gf2.ti/f/762498/27838501.1/PDF/-/ChemRegClinCodingStandGuidApl2017.pdf. Entries will be made in the CONCEPT_RELATIONSHIP table using the existing ‘"Maps to" and "Mapped from" relationships to RxNorm ingredients based on the ingredient participation detailed in the National Tariff Chemotherapy Regimens List.
Algorithms
Option A Algorithms
Option B Algorithms
Algorithm Inspiration
Based on an algorithm in paper “Algorithm to Identify Systemic Cancer Therapy Treatment Using Structured Electronic Data”: http://ascopubs.org/doi/pdf/10.1200/CCI.17.00002. Attempts to characterize first-course systemic therapy and all subsequent course systemic therapy. Uses ‘Cancer Therapy Look-up Tables’ maintained by the NCI Cancer Research Network (CRN) listing National Drug Codes (NDCs), procedure codes (CPT4, ICD-9, HCPC) and diagnosis codes (ICD-9) to filter clinical events in a Health Care Systems Research Network (HCSRN) virtual data warehouse (VDW). https://crn.cancer.gov/resources/codes.html
Open Issues
The text was updated successfully, but these errors were encountered: