Many people in the past have expressed interest in supporting the representation of high-level Drug concepts in the OMOP CDM. For example, storing ATC codes in the DRUG_EXPOSURE table. This interest is normally driven by the desire to ETL into the OMOP CDM a source system that captures drug treatments at a level above RxNorm ingredients. For example: chart abstracted registries. However, as of today, storing higher-level drug treatments in DRUG_EXPOSURE is not supported because ATC concepts are classification concepts. Thus cannot properly live in the drug_concept_id field.
A potential alternative is to store high-level drug concepts in the pending EPISODE table. The EPISODE table has an ‘episode_concept_id’ field, which can represent a ‘Cancer Drug Treatment’ episode and a ‘episode_object_concept_id’ field that can represent Cancer drug regimens from the Regimen domain. Today the Regimen domain is drawn from the Hemonc.org Drug Regimen ontology. The Hemonc.org drug Regimen ontology is a standard for the representation of Cancer drug regimens. For example, ‘Abiraterone and Enzalutamide’ or ‘Carboplatin, Gemcitabine, Bevacizumab’. However, a current limitation of the Hemonc.org drug ontology is that it does not fully support the representation of high-level drug concepts. There is flat group of concepts in the ‘Regimen’ domain with a ‘Concept Class’ of ‘Regimen Modality’ but this list of concepts does not support the required hierarchy of concepts.
However, the Hemonc.org ontology does currently include classification concepts for the Hemonc.org components that comprise its Regimen domain entries. For example the ‘Abiraterone’ Hemonc.org component is encoded as a constituent of the ‘Abiraterone and Enzalutamide’ regimen via an entry in CONCEPT_RELATIONSHIP with the relationship ‘Has antineoplastic - RxNorm (HemOnc)’ . In turn the ‘Abiraterone’ Hemonc.org component has a parent/child entries with ‘Component Class’ classification concepts:
– Endocrine therapeutic (Hemonc.org Component Class)
---- Antiandrogen (Hemonc.org Component Class)
---- Steroid synthesis inhibitor (Hemonc.org Component Class)
------ Abiraterone (Hemonc.org Component)
Thus, a possible solution presents itself to migrate/copy the Heonc.org ‘Compoent Class’ hierarchy into the ‘Regimen’ domain.
Here are the steps I think we need to take.
- Find all entries in the ‘Regimen’ domain with Concept Class= ‘Regimen’
- For each component in each ‘Regimen’ that has a ‘Has antineoplastic (HemOnc)’ or ‘Has immunosuppressor (HemOnc)’ or ‘Has local therapy (HemOnc)’relationship, find the component’s “Component Class’ entries.
- Line item copy (skip ones that are not useful) the component’s ‘Component Class’ hierarchy into the ‘Regimen’ domain with ‘Subsumes/Is a’ relationships to the ‘Regimen’ entry. Allowing that the result would be existing ‘Regimen’ domain entries could have multiple parents.
I believe Hemonc.org broke down the ‘Has antineoplastic (HemOnc)’ relationship into multiple finer-grained relationships in the latest distribution, so that would slightly alter this. Some open issues: should components with the relationship ‘Has immunosuppressor (HemOnc)’ or ‘Has local therapy (HemOnc)’ be included? Deciding what Component Classification concepts should be elevated and which skipped. My assumption is that for sure we should not include components with exclusively a ‘Has supportive medication (HemOnc)’ relationship to its ‘Regimen’.
I definitely believe that looking at specific examples would be helpful. So if the vocab team could show some examples of Regimens/Components today and how the Regimens/Components would look after the transformation, I think that would be very helpful.