Stream: genomics
Topic: harmonize somatic and PGx profiles
Bret H (Oct 01 2019 at 16:38):
We have a set of profiles to deliver PGx implications and a separate profile to deliver Tumor specific treatment implications. The major difference in these two concepts is that the PGx implications are about how the patient's non-tumor tissue will effect the pharmacodynamics and pharmacokinetics of medications. The somatic profile is about the tumor. Our current mechanism of separation is through pre-coordinating Somatic in the profile name. But one could consider the tumor as a Focal subject. @Alexander Mankovich
Bret H (Oct 01 2019 at 16:39):
from @Patrick Werner
this could be done through a component in the profile which states: tumor/patient origin of the specimen. Theoretically this could be also be described in the Specimen, but i think it would be easier to code this in the Observation profile.
Bret H (Oct 01 2019 at 16:39):
@Alexander Mankovich
Alexander Mankovich (Oct 03 2019 at 17:03):
I think Patrick's approach would be fine. Just to be clear, this proposal would replace somatic prognostic and somatic predictive implication (but not diagnostic) profiles correct? Is there still room to specify the associated-cancer component using the pgx profiles? I'm also wondering how predictive implications would be represented if the therapy was something other than a drug.
Jamie Jones (Oct 03 2019 at 17:20):
It seems the major pre-coordination is in the Observation.code, (eg, "tbd-som-predictive"), which would tell the system what components to expect in that "knowledge observation" and how to interpret it semantically.
The main computational difference in the profiles (medication-implication and obs-som-predictive) is that one requires the medication-assessed component to be present, and the other requires the associated-cancer component.
However, our component slicing is currently "open" so someone could easily send an associated-cancer component on one of our PGx implications currently and vice versa. Similar arguments could be made about associated-therapy, but it gets messy with our current required cardinalities.
In general, we are looking for a balance here between having "too many boxes" (an overwhelming number of profiles not fitting an obvious pattern) and "big leaky buckets" (where a "bucket-like" implication profile would require a system to look at which components were populated to understand how to process it)... I don't have a solution for this yet, except thinking that our recent decision to frame the IG as general guidance instead of targeting specific use cases may suggest we ought to have one "bucket-like" implication to match obs-variant and then smaller use-case specific IGs/sections could derive use-case implications from that profile.
Jamie Jones (Oct 03 2019 at 17:22):
That is, rather than have inherited profiles add components, they could be restricting them from the base implication. Something to consider in the future, in my opinion...
Jamie Jones (Nov 18 2019 at 17:08):
Wanted to bump this thread as came up on call today, in context of going over Kevin's branch to join the 3 somatic profiles (available at http://build.fhir.org/ig/HL7/genomics-reporting/branches/kpower_SomaticImplication/index.html).
Bret H (Nov 18 2019 at 17:13):
@Kevin Power @May Terry please see Alex's comments above. His comments indicate how he was planning to use associated cancer. And Patricks comments on adding an indicator for specimen origin (what has the genetic variation). @James Jones worth considering. The merging that Kevin did fits well with this approach. The main benefit and drawback is that you explicitly remove the ability to mix-match components.
Kevin Power (Nov 18 2019 at 17:16):
The main benefit and drawback is that you explicitly remove the ability to mix-match components.
How so?
Bret H (Nov 18 2019 at 17:16):
I want to highlight the need to indicate weather the target of therapy is a tumor, and weather the problem is with the patient's liver metabolism (pharmacokinetics) versus the tumor's receptiveness to treatment (pharmacodynamics).
Bret H (Nov 18 2019 at 17:16):
@Kevin Power can't have an instance with a non-allowed component. that's all.
Kevin Power (Nov 18 2019 at 17:17):
Kevin Power can't have an instance with a non-allowed component. that's all.
I didn't change anything that would add that restriction?
Kevin Power (Nov 18 2019 at 17:18):
(at least I don't think I did?)
Bret H (Nov 18 2019 at 17:18):
referring to Jaime's suggestion. Not your branch,
Kevin Power (Nov 18 2019 at 17:18):
ahhhhh :slight_smile:
Jamie Jones (Nov 18 2019 at 17:21):
Yes, my top-down inheritance would only work for the use cases we identify. That said, I went to add a component onto a profile that appeared to have open slicing and received an error, but it is likely one from the validator and not specific to our spec.
Jamie Jones (Nov 18 2019 at 17:22):
And I would prefer the fewer boxes in Kevin's approach, I just have to do a bit of homework on the components to make sure we can provide the right guidance for Observation.value, and confirm where this approach may impact other issues we have with the 1.0 Implication profiles in general.
Kevin Power (Nov 18 2019 at 17:24):
That said, I went to add a component onto a profile that appeared to have open slicing and received an error, but it is likely one from the validator and not specific to our spec.
Hmm, an error? I see our examples generating "informational" messages for that situation, but not errors.
Jamie Jones (Nov 18 2019 at 17:24):
I was getting a 'missing expected required component' error on an example that didn't make it into the build
Jamie Jones (Nov 18 2019 at 17:25):
but I think that was just an issue with the validator interpreting open slicing in that case. Seems to work fine on other profiles and I'd have to do some troubleshooting to pin it down further.
Kevin Power (Nov 18 2019 at 17:25):
If I get the time today or tomorrow, I might push up additional changes:
- Try to combine the PGx profiles in a similar way that I did on the Somatic side
- Renaming "Inherited Disease Pathogenicity" to "Inherited Disease Implication" for better alignment.
Jamie Jones (Nov 18 2019 at 17:27):
I like both those bullets, I'll think about how to pursue Observation.value here, if we really can have it subsume the previous value sets in a good way or if it should just be present/absent/etc and the values need their own components.
Kevin Power (Nov 18 2019 at 17:27):
I was getting a 'missing expected required component' error on an example that didn't make it into the build
Oh, well that sounds more like something that I made "required" by make it 1..* where before it might have been 0..* - what component?
Kevin Power (Nov 18 2019 at 17:28):
I'll think about how to pursue Observation.value here, if we really can have it subsume the previous value sets in a good way or if it should just be present/absent/etc and the values need their own components.
Yea, I suppose that would work - then have three different components (for the three different value sets)?
Jamie Jones (Nov 18 2019 at 17:30):
I forget the example, but the component that was being asked for was already present in the profile (and the only one defined). Adding a second component that wasn't defined through a non-sensical error, so I think we can move past it unless we run into it again.
And yeah, I think each concept needs a defined component, I'll have some time this week to fiddle with it
Bret H (Nov 18 2019 at 17:30):
@Kevin Power take care when combining the pgx profiles, the value sets are unique> I'm not a fan of all the diversity that CPIC has in the value sets. There is large overlap. But having the profiles separated allows one to specifically indicate which value set goes with which LOINC code.
Bret H (Nov 18 2019 at 17:35):
the upshot: either the sender does the work (i.e. use the right profile) and the user just puts in the right place. OR the instance comes in and the user has logic to verify that the value is from the correct value set. something like this
Jamie Jones (Nov 18 2019 at 20:48):
I went back into our Domain Analysis Model doc and searched for "impact" (our old term for "implication") and found that we reference https://www.fda.gov/drugs/science-and-research-drugs/table-pharmacogenomic-biomarkers-drug-labeling when introducing PGx. Of note on that table, "Oncology" is quite prominent, reinforcing the idea that germline and somatic PGx implications may not be separate use cases needing individual profiles.
Kevin Power (Nov 18 2019 at 21:10):
Yea, seems like the biggest things differentiating our 3 types of implications today (inherited, somatic, PGx) are:
- some differences in components
- fairly important differences in answer lists
Jamie Jones (Nov 18 2019 at 22:12):
Re: condition vs cancer vs phenotype, any reason we shouldn't be considering HPO (used by phenopackets alongside snomed)
Jamie Jones (Nov 18 2019 at 22:13):
Phenotypic feature: https://mseqdr.org/hpo_browser.php?118;
Kevin Power (Nov 18 2019 at 22:14):
100% should be an option - not sure if it can be the only option though.
Kevin Power (Nov 18 2019 at 23:39):
Also, wanted to note - I am holding off on further changes for now, mostly because of @Bret H great point, which is spot on:
take care when combining the pgx profiles, the value sets are unique> I'm not a fan of all the diversity that CPIC has in the value sets. There is large overlap. But having the profiles separated allows one to specifically indicate which value set goes with which LOINC code.
Jamie Jones (Nov 18 2019 at 23:56):
Pushing the values into components fulfills this as well, but may introduce need for additional invariants on the profile
Kevin Power (Nov 19 2019 at 01:34):
The fact that we need invariants in this case feels like we don’t have something quite right yet. But yes that helps address the desire to flex the answer lists
Bret H (Nov 21 2019 at 12:13):
how often should invariants be used? seems like an attractive new toy in some ways
Last updated: Apr 12 2022 at 19:14 UTC
