Stream: genomics
Topic: Themes for STU2
Kevin Power (Nov 05 2019 at 21:38):
Here is a draft of high level themes that we should look to address for STU2. With this list, we can ask for volunteers to help drive the discussion and make recommendations. Here is my list (in no particular order), and of course I welcome feedback/input from everyone:
- Definitional versus Observational - How do we go about defining a set of definitional entities where needed?
- Implications - Can we better harmonize our implication profiles to make them more usable?
- Methodology - How to best represent the methodology behind the test? (this should probably include reevaluating region studied)
- Tooling support for genomic specific code systems (HGNC, HGVS, SO, etc ...)
- LOINC requests for any remaining 'TBD codes'
Other things I considered, but wasn't quite sure they warranted a theme:
- Report Interp/Text - Better guidance on interpretations + the 'snippets of text' that are often important to support those interps.
- Breaking the IG into more specific IGs
- Ensuring our IG is compatible/works nicely with other IGs
-- Please note, there will be overlap among these themes, and I am not sure how to best address that. I doubt we can eliminate it entirely.
Lloyd McKenzie (Nov 05 2019 at 22:05):
Getting more labs involved in looking at the spec (and planning to implement it)?
Larry Babb (Nov 06 2019 at 12:17):
@Kevin Power I might suggest introducing the notion of sharing knowledge statements or variant-centric assertions / evidence to represent or build knowledge in contrast to the Observational subject-centric approach to sharing statements about what was or wasn't observed in a single specimen/subject. By understanding the need to share these variant-centric statements in FHIR, I believe, it would shed significant light on how the definitional data types should be represented so that they could be shared across both subject-centric observations of variants as well as variant-centric statements of knowledge and annotations to provide the evidence and inputs needed to support CDS and other clinical/research use cases in the domain of precision medicine.
Kevin Power (Nov 06 2019 at 12:53):
@Larry Babb - I was thinking that would be part of the Definitional versus Observational theme?
Kevin Power (Nov 11 2019 at 15:38):
I have moved the list to this Google doc - continue to ask for additional feedback please:
https://docs.google.com/document/d/17r-HNm-gyqthepU40gqh39uYK9PV3HmBl1VM-vW6TuY/edit
Jamie Jones (Nov 11 2019 at 16:10):
Added "revisiting DAM use case descriptions" to the miscellaneous section of the list.
Jamie Jones (Nov 11 2019 at 16:12):
I know there's no immediate call for feeding DIM content back into the IG in its entirety, but I believe it should help us in converting topics listed and/or missing from the DAM into usable guidance in the IG
Bret H (Nov 18 2019 at 17:48):
I think we should also make some statement about what will not be changed. As different parts of our spec mature at different paces, we should help implementers know what we consider more 'done.'
Jamie Jones (Nov 18 2019 at 18:09):
@Bret H Do you have a list of any parts of the spec you think are less likely to change? I feel the ideology represented on index.html is solid, but we have open issues with findings, implications, and region-studied so I think it is hard to predict where proposals will solidify. Certainly we will need to maintain a changelog for future versions, outlining changes we do make. Would that satisfy your concern?
Jamie Jones (Nov 18 2019 at 18:12):
If we want to model separate levels of maturity in anything other than text, we may need separate IG-level packages
Jamie Jones (Nov 18 2019 at 22:18):
Realized I don't see phenopackets on here, group seemed very interested in alignment/sponsoring phenopackets-on-fhir IG in Atlanta, and they may have some overall approach that could benefit our implication profiles. (see https://aehrc.github.io/fhir-phenopackets-ig/profiles.html)
Kevin Power (Nov 18 2019 at 22:45):
WOW, that is quite a piece of work. There is so much there that a quick review isn't going to be enough. What specifically did you see that might benefit our implication profiles?
Bret H (Nov 19 2019 at 17:00):
a changelog is something. The question is, will it be visible enough for implementers. We have problems with new implementers not looking at both the snapshot and differential...as well as the implementers being new to FHIR. As a WG adding more on the structured def page would be useful. But we need more wg members to be involved to get that done.'
Kevin Power (Nov 19 2019 at 22:57):
So, wanted to try and keep this conversation moving. Sorry, I have been completely swamped today but here goes.
Given the variety of answer lists we have today, if we continue to move forward with this consolidation approach, we have two ways that I can see we can handle the answer/values that I added to the STU2 Themes document under Implications:
- Use the Observation.valueCodeableConcept to reflect the answers (like what sort of Prediction, what sort of Metabolism effect, etc ...) - we would either need to create a new ValueSet with everything rolled into one, or leave the binding as a open - and provide guidance in text.
- Use the Observation.valueCodeableConcept as something simple (like Present/Absent), and then introduce components to hold the sort of answers I mention above. To Jamie's point, this would be made better by adding some invariants (and probably textual guidance) to help ensure that we help ensure the appropriate component "answer" is sent to match the corresponding Observation.code.
If there are other ideas/thoughts of how this could be done, please share.
Jamie Jones (Nov 20 2019 at 01:32):
Are we sure that diagnostic implications should be lumped into the same profile as others? The use case seems quite different at first glance, and I believe @Alexander Mankovich showed concern here as well
Kevin Power (Nov 20 2019 at 01:50):
At this point, I am not sure of anything :grinning: what were the concerns? What would the right answers be for a diagnostic implication? That often helps me think through how well it aligns.
Jamie Jones (Nov 20 2019 at 01:55):
Well a diagnostic implication would be indicating a potential link to a cancer presence, as opposed to others which I believe assume the cancer is already present as a context for selection/projected outcome (usually of a particular therapy)
Jamie Jones (Nov 20 2019 at 01:58):
The data elements may be similar but systems will have to perform different logic based off the codes
Jamie Jones (Nov 20 2019 at 01:59):
Could potentially split the associated cancer off into "predicted-cancer" vs "cancer-context", for example
Jamie Jones (Nov 20 2019 at 01:59):
This is an example of an overall modeling question that I haven't seen answered yet...
Kevin Power (Nov 20 2019 at 02:15):
Are there other missing data elements?
Jamie Jones (Nov 20 2019 at 02:18):
My question is if different use cases for the same concept warrants it being a different concept
Jamie Jones (Nov 20 2019 at 02:19):
Gets us back to the level of evidence discussion, haha
Kevin Power (Nov 20 2019 at 02:29):
I don’t know the answer to that one but it does feel like we continue to circle back to the same set of questions. If they do need to be defined separately, I sort of wonder about the value of consolidation of the profiles?
Jamie Jones (Nov 20 2019 at 02:31):
Well if we can make good arguments that the elements that look similar in English can be aligned without sacrificing usability it is valuable.
Jamie Jones (Nov 20 2019 at 02:34):
If not, we have better guidance for why they are separate!
Kevin Power (Nov 20 2019 at 02:36):
Agreed that seems to be a key decision to validate. I had assumed that it would be ok when combining :grinning:
Alexander Mankovich (Nov 20 2019 at 18:24):
For context I believe diagnosis for CML requires a positive test for a BCR-ABL gene fusion. There are also numerous examples of genetic associations with particular cancer subtypes such as breast cancer. Still not sure which of your approaches would work best but hope that's informative
Kevin Power (Nov 20 2019 at 19:01):
After a review of some examples in this space, would it make this any clearer if we dropped the name 'implication' and used 'significance' ? I think that would make it clearer that our code/value should represent what sort of significance it is, then the components should support it?
In my head, that feels better - but is it really?
Patrick Werner (Nov 21 2019 at 11:22):
hmmm, i like significance - but had no problem with implication. After thinking a bit about merging profiles i now don't see a benefit of merged profiles with too many invariants compared to different profiles.
Patrick Werner (Nov 21 2019 at 11:24):
But if we can merge some, i'm in for it. Prognostic and Predictive are looking quite similar, so these could be merged? But after reading the paper about the definition of predictive, prognostic and diagnostic i assume our prognostic profile might be wrong?
Bret H (Nov 21 2019 at 11:25):
How so @Patrick Werner ?
Bret H (Nov 21 2019 at 11:25):
Be cautious about dithering on language.
Jamie Jones (Jan 28 2020 at 20:36):
Do we have a topic here for Phenopackets?
Kevin Power (Jan 28 2020 at 20:37):
Not a specific one
Jamie Jones (Mar 04 2020 at 17:40):
Definitional vs observational on Variant feels like it won't be separate structures this time around--but we could and should separate them in our textual representation.
Kevin Power (Mar 04 2020 at 19:52):
I think small strides we can make here will help:
- Consider collapsing some related components (HGVS)
- Appropriately group/sort the components, both within the profile and the diagrams.
- Additional textual documentation on the Sequencing page to help implementors see the connections that are not obvious otherwise.
- Perhaps implement a few invariants?
Jamie Jones (Mar 04 2020 at 20:44):
I'd add to this variant component grouping a "must support" review for the key observational and (at least one) definitional group. The other "nice to have" potentially redundant components could be left out of the must-supports - a much less heavy-handed approach than removing them entirely.
Bret H (Mar 15 2020 at 16:38):
when does this thread expire. I'm interested in a set of specific-binding deliverable targets. A target release date and a plan for timing of future enhancements/upgrades/changes. :grinning: and fhries (its a lot to ask, but a closing date on new topics added to STU2 might be helpful to move the needle)
Jamie Jones (Mar 16 2020 at 14:49):
hoping to give this some screen time today
Last updated: Apr 12 2022 at 19:14 UTC
