Stream: genomics
Topic: Variant Origin - 'NOT' ?
Kevin Power (Jan 06 2020 at 23:06):
Had an interesting question today. Use Case: Sequence child + 1 parent (let's say Mom). Find variant in child, but same variant is not found in Mom. We don't know if it is is paternal or perhaps de novo? Is there a way, using our component for Variant Origin, to indicate NOT 'maternal_variant'? I don't know how to do it, but maybe I am missing something. I know 'negation' in general is a hairy topic, but this seems like a reasonable use case to consider.
Kevin Power (Jan 07 2020 at 19:46):
How about this as a pointed question - Does anyone have an opinion on if this is a value set question (we ask SO to add "not_maternal" and "not_paternal" as codes) or a FHIR Observation question (do we need an extension/other option available on Observation.component[] to allow a 'negation' of the given concept?
Jamie Jones (Jan 07 2020 at 19:57):
would prefer adding the negations to the list and increasing the cardinality of our component to 0..* with our current model.
Jamie Jones (Jan 07 2020 at 19:57):
we did mark it as extensible, so could do that already (but better to get it added to the list)
Jamie Jones (Jan 07 2020 at 19:59):
I'm still not sold having this as a component and not a separate Observation is the right choice though, as the 'method' becomes unclear
Kevin Power (Jan 07 2020 at 20:02):
Yea, but I think you could make the same argument about many of our components. I think that falls into the 'slippery slope' category.
Jamie Jones (Jan 17 2020 at 18:11):
I heard Sequence Ontology altered codes in the past for us, is anyone aware of the procedure/contacts?
Kevin Power (Jan 17 2020 at 18:26):
The "Issues" link on their home page takes you here: https://github.com/The-Sequence-Ontology/SO-Ontologies/issues - seems like a good place to start?
Jamie Jones (Jan 17 2020 at 18:27):
115 open issues!! Might be years without a contact haha
Jamie Jones (Jan 17 2020 at 18:29):
apparently they are "...working to update how we handle issues, so more changes to this repository are coming soon."
Bob Freimuth (Feb 25 2020 at 12:36):
In general, I'm not a fan of pre-coordinated terms. I also think we should keep the terms in our value sets mutually exclusive (disjoint). If an observed variant is de novo, it is also not_maternal and not_paternal. I don't think we should rely on implementations to enumerate all valid terms in a non-disjoint set, and we're guaranteed to have variability in how overlapping terms would be reported.
Jamie Jones (Feb 25 2020 at 12:41):
That's good perspective, thanks! We don't have the structure of a grammar in our codes, so combinations of items aren't well defined... I think that means we should enumerate all relevant possibilities in the list, however, so we may need to add multiple items.
Jamie Jones (Feb 25 2020 at 12:49):
We should be fine to do this with a local list for now, but a strategy to get issues like this resolved with SO would be super
Bret H (Mar 03 2020 at 16:14):
are we talking about the component with the new LOINC code? we do have a code for indicating that the variant is from a parent but without giving a parent. HOWEVER, if all you know is that the variant is not in mother, you're kinda stuck. Might be better to say unknown and send the mother's genetic information at the position....I think we should focus on the use case here. Is the information needed for research? how is the information expected to be used?
Patrick Werner (Mar 03 2020 at 17:11):
Bob Freimuth said:
In general, I'm not a fan of pre-coordinated terms. I also think we should keep the terms in our value sets mutually exclusive (disjoint). If an observed variant is de novo, it is also not_maternal and not_paternal. I don't think we should rely on implementations to enumerate all valid terms in a non-disjoint set, and we're guaranteed to have variability in how overlapping terms would be reported.
as component only allows for a key-value representation of data we have to use pre-coordinated terms. Also pre-coordinated is easier to validate.
Jamie Jones (Mar 03 2020 at 20:21):
where we do point to extensible or required lists to act as 'values' in a (pre-coordinated) concept, I agree they should definitely be disjoint--we may even want to add that to our list of "design principles."
I think I understand several arguments against pre-coordinated answer lists, but I personally feel erring towards not binding the answer lists (or only providing example lists) requires very good guidance around the concept definition and multiple, varied examples. We have to weigh implementers needing to support identified lists/systems vs employing subject matter experts to analyze and make a decision for what systems to use for each field (which they then still need to interface locally)... a separate discussion at this point.
We should circle back to this with the LOINC concept Bret chased down for us.
Bret H (Mar 15 2020 at 16:05):
There's a place to give a data absent reason. There it can be reported why the value is unknown etc...perhaps this can be considered in options
Last updated: Apr 12 2022 at 19:14 UTC
