Stream: genomics
Topic: slides PGx CG IG use and proposal components versus profiles
Bret H (Dec 02 2019 at 16:13):
Dear CG'rs, The attached are slides that provide information on suggested use of current profiles and is for discussion of 'simplifying' the current PGx implication profiles. The slides provide some suggested guidance on using the current profiles, the 'simplification' to components and a plain-text example.
Please take a moment and review the ppt. Feedback would be greatly appreciated. FHIRpgxV1.01.pdf
Bret H (Dec 02 2019 at 16:14):
(deleted)
Jamie Jones (Dec 02 2019 at 17:12):
Thanks for the upload! I think somatic-predictive should be included here as well (but likely not the other somatic use cases). If anyone wants, I can draw up some diagrams/an example or two describing what's in this proposal to help people see the differences.
Kevin Power (Dec 02 2019 at 17:13):
We can use the branch in GitHub I setup? (this is one reason I don't like putting names on GitHub branches, but it seems to be done)
Kevin Power (Dec 02 2019 at 17:56):
I think somatic-predictive should be included here as well (but likely not the other somatic use cases).
So, you mean the "Medication Implication" profile would have a another item in the Observation.valueCodeableConcept answer list called something like "predictive" as well as a component to deliver what we have as the answer list for somatic-predictive today (which is unbound but shows examples like this:
Resistant, Responsive, Not-Responsive, Sensitive, Reduced-Sensitivity, Adverse Response
If so, this is very similar to the answer list for what is delivered in the current "Medication Efficacy" profile today (also unbound but shows examples like this):
Resistant | Responsive | Presumed resistant | Presumed responsive | Unknown significance | Non-Responsive | Presumed non-responsive
So it seems that this should just be a single thing: * Observation.code = "Medication Implication" * Observation.valueCodeableConcept = <predictive/efficacy/other?> * Observation.component[].code = <predictive/efficacy/other?> * Observation.component[].valueCodeableConcept = <union of the above answer lists?>
Jamie Jones (Dec 02 2019 at 17:58):
I think we could add an associated-cancer component and get the full functionality of the somatic-predictive profile here too
Kevin Power (Dec 02 2019 at 18:06):
Probably, yea? Maybe even adding that component to the 'inherited disease' profile to speak about germline findings that related to cancer prediction? Unless we would argue that if the inherited implication happens to be about a cancer, you would still use the 'associated-phenotype' component?
Jamie Jones (Dec 02 2019 at 18:09):
That sounds more like a consideration for the somatic-diagnostic side of things
Jamie Jones (Dec 02 2019 at 18:10):
Rather than splitting the implications by source class, could suggest splitting them by use case
Kevin Power (Dec 02 2019 at 18:13):
And the use cases would be ... ?
Bret H (Dec 03 2019 at 17:02):
@Bob Dolin questioned the necessity of Transporter efficacy implication on the call. It is worth discussing as we retool whether or not to support transporter. Certainly one could add a slice to component to support it if it was something they wanted. Perhaps our IG should stick with components that represent 80% use case. It is a universal IG.
Bob Dolin (Dec 03 2019 at 17:04):
Hi @Bret H . To clarify, I questioned two things: [1] Do we need a Medication Transporter Implication; [2] Can we revisit the Medication Efficacy Implication answer list (https://loinc.org/loinc/LL539-8/)
Jamie Jones (Dec 03 2019 at 17:05):
I agree it may be more detail than is needed, a detected variant in those transport genes would still affect the efficacy of the drug, just need to ensure the list and definitions for drug efficacy are clear and complete
Bret H (Dec 03 2019 at 17:06):
only there because of CPIC. but again, if we don't include it, one could create a derived profile with a slice on component to put it in;
Jamie Jones (Dec 03 2019 at 17:07):
@Bob Dolin if you can propose a list you think covers it, I can get it into a branch of the IG later this week along with the profile>>component change for people to see in action
Bret H (Dec 03 2019 at 17:09):
Clem McDonald brought up a question on Oberservation.value - it is potentially redundant. also, it precludes populating multiple types of implication components. Consider changing it to a value set of 'present' I would say that not-present would need discussion
Jamie Jones (Dec 03 2019 at 17:12):
Our Observation.value fields need reconsidering across all profiles... I'll draw up a proposal ;)
Bob Dolin (Dec 03 2019 at 17:19):
@Jamie Jones , one consideration would be to remove Medication Transporter Implication and change the answer list for Medication Efficacy Implication to a simple ordinal list (such as 'increased function', 'normal function', 'decreased function', 'absent function')
Bret H (Dec 07 2019 at 22:16):
Before this group gets too excited I would like to have a clear project timeline and clear milestones. Such as version 2 is targeted for release in 2023.
Kevin Power (Dec 07 2019 at 22:35):
I don’t think the group ever decided on a specific timeline? Where did you get 2023? I would be very surprised if we wait that long for a another release, but I think @Gil Alterovitz was considering what a longer term plan would look like for the IG.
Lloyd McKenzie (Dec 07 2019 at 22:52):
Max period for an STU without an extension is 2 years.
Bret H (Dec 07 2019 at 23:20):
@Kevin Power to keep my comment from the distraction of a specific date : ^ ) Before this group gets too excited I would like to have a clear project timeline and clear milestones. Such as version 2 is targeted for release in <some_date>. Such and such is considered most likely to be updated. X is seen as fairly mature.
Bret H (Dec 10 2019 at 17:02):
@ Bob Milius made a suggestion that lead to removal of observation.value value set of types. Consider cardinality zero, or present/absent.
Bret H (Dec 10 2019 at 17:04):
Do we have enough information to move forward? What are the action items? do we need a jira?
Kevin Power (Dec 10 2019 at 18:09):
The idea (well, my idea here anyway) was to use this branch to build a proposal, then document it fully in a JIRA, and have the group vote on it before making officially making the change in the 'master.' So yes, we will need a JIRA eventually.
Regarding Observation.value, it seems the consensus on the call today was 0..0
Last updated: Apr 12 2022 at 19:14 UTC
