Closed mgurley closed 5 years ago
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. ?
@ColinOrr2008 @shawndo
Thanks for the feedback.
@ColinOrr2008
EAV: We are proposing the TREATMENT_MODIFIER structure/domain instead of using references to OBSERVATION/MEASUREMENT via FACT_RELATIONSHIP 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, OBSERVATION is a "garbage can". We are just trying to organize our garbage cans. Like separating into compost, waste, paper, aluminum/plastic.
Add treatment_id to VISIT_OCCURRENCE Good idea. We will bring this idea to the Oncology Workgroup for inclusion.
I am confused by Option A statements on derivation. see blue text (start and end)
If we ingest into OMOP Vocab NCI CRN ‘Cancer Therapy Look-up Tables, we should think of non-US contries. The knowledge base is in "non-standard" CPT codes.
see these examples from here https://crn.cancer.gov/resources/Radiation%20Therapy%20Codes_Procedures.csv
If we formulate smart constructs in OMOP Vocab, we should not do it off copyrighted CPT4 codes.
@vojtechhuser Regarding your comment: "I am confused by Option A statements on derivation. see blue text (start and end)"
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:
Add support for a TREATMENT concept
I think we mean, TREATMENT domain. i.e. just like we have Visit domain, condition domain.
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.
Could you please clarify - 'treatment cycles will not be algorithmically derived' vs. 'Treatment abstractions will be algorithmically derived'
Treatment table
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?
treatment_cycle_number an ordinal enumeration of treatment cycles. Each representation of a treatment cycle should refer to the parent Treatment by the parent id column.
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?
table contains records aggregating lower-level clinical events Treatment_modifier.treatment_modifier_domain_id Treatment_modifier.treatment_modifier_event_id
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 )
TREATMENT_MODIFER
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? Can the attributes in the TREATMENTMODIFIER table be considered measurements? It has value, unit_
@vojtechhuser
If we formulate smart constructs in OMOP Vocab, we should not do it off copyrighted CPT4 codes.
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. Since CPT4 is not a standard procedure vocabulary within OMOP (because of licensing), our ingestion of the 'NCI CRN ‘Cancer Therapy Look-up Tables' would likely need to enrich the native mappings to include all standard procedure concepts mappable from CPT4.
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.
@gowthamrao
I think we mean, TREATMENT domain. i.e. just like we have Visit domain, condition domain.
You are right. Changed it.
Could you please clarify - 'treatment cycles will not be algorithmically derived' vs. 'Treatment abstractions will be algorithmically derived'
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.
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?
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.
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?
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.
The treatment_parent_id (in Option A) is always the treatment that encompasses all six chemoRx cycles. (Option B makes this relationship more explicit, which is why I prefer it, the table structure being more isomorphic with reality). Right now the model does not allow for tracking planned versus executed cycles. To allow for this, perhaps we should add a treatment_cycle_status_concept_id field. What do you think?
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 )
Sounds good. We should follow the emerging OMOP/OHDSI standards. I will change the proposal to adhere to the proposal you pointed to.
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? Can the attributes in the TREATMENTMODIFIER table be considered measurements? It has value, unit_
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.
@vojtechhuser @cgreich
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