Stream: genomics
Topic: variant Inherited from
Bret H (Sep 23 2019 at 16:01):
The work of Nephi Walton, Clinical Geneticist at Geisenger, to map gnomic reports he is using into our IG, requires a data element for InheritanceOfVariant with values De Novo, Unknown, Father (Paternal), Mother (Maternal). The element is meant to indicate weather the variant was found in the patient's parent. This is typical reported in a TRIO analysis (where the patient's genome is compared to close relatives - typically mother and father). The reports generated from these analysis do not always provide supporting documentation. The value is simply stated as metadata that the Lab has regarding the variant.
My proposal is to create a new component in our IG before publishing to accommodate the element.
Looking in our IG, For sequence phase relationship(http://build.fhir.org/ig/HL7/genomics-reporting/obs-sequence-phase-reltn.html) we use the LOINC code for Allelic Phase ( https://r.details.loinc.org/LOINC/82120-7.html) but with a required value set of cis, trans, indeterminate, unknown. This element is specifically for relating a variant observation with other variant observations. I do not think it applicable to Nephi's requirement as De Novo is not a relationship between variants.
The proposed element provides a place for the lab to state whom the variation was inherited from, not the phase.
Full-term name:Variant Inheritance
Shorthand name: InheritanceOfVariant
Definition: Weather or not the variant was inherited from the patient's mother or father.
Value Set: De Novo, Uknown, Maternal, Paternal
I think a component would be best as this is a property of the variant and has no meaning without being a part of an observation of a variant.
The geforge tracker is: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24853
@Patrick Werner @Bob Freimuth
Jamie Jones (Sep 23 2019 at 16:18):
Slicing on component is currently "open" so additional components are allowed as long as they aren't repurposing one of the codes we've defined a binding to (will throw warnings not errors). Do we have a LOINC code or set to bind here? We could add it to our TBD table if it's something the group thinks needs to be standardized
Bob Milius (Sep 23 2019 at 16:39):
is there a role here for FamilyMemberHistory and the extensions we added for CG to be able to create pedigrees?
Jamie Jones (Sep 23 2019 at 16:41):
Personally, I wonder if the parental link is best represented as a string... reference to a Patient or FamilyMemberHistory might be more useful..
Jamie Jones (Sep 23 2019 at 16:41):
Looks like we had the same idea haha
Jamie Jones (Sep 23 2019 at 16:42):
Can't add references in components currently (or potentially ever, given normative status of Observation) so might have to be an extension or a different structure
Joel Schneider (Sep 23 2019 at 17:06):
Would the ClinGen allele origin GENO value set Larry mentioned in another thread be applicable to this?
https://chat.fhir.org/#narrow/stream/179197-genomics/topic/FYI.20-.20GENO.20value.20sets!
Kevin Power (Sep 23 2019 at 17:18):
@Bret H ^^^ ?
Kevin Power (Sep 23 2019 at 17:20):
FWIW - I think adding FamilyMemberHistory into this might be a bit heavy. I think a new component based on @Joel Schneider 's recommendation above sounds great.
Nephi Walton (Sep 24 2019 at 15:13):
This is not family history this is an important part of the genetic result that drives care. We get that information back on genetic testing reports and it dramatically alters care. Interpretation and use of the result is based on this information.
Kevin Power (Sep 24 2019 at 16:10):
This was discussed on the call today (Sep 24). We should make sure we have a concrete proposal documented on the tracker, and if this is straight forward to apply, we can look to do so next week. Asking @Bret H @Nephi Walton to ensure we have the tracker well documented in the next day or two. Any concerns?
Kevin Power (Sep 24 2019 at 16:10):
As a reminder, here is the tracker: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24853
Bret H (Sep 24 2019 at 18:59):
@Kevin Power does the proposal in the tracker look clear enough? or was a different proposal discussed today? thx!
Kevin Power (Sep 24 2019 at 19:00):
We didn't discuss alternatives - but I didn't see what to use as 'component.code' ?
Bret H (Sep 24 2019 at 20:06):
I submitted a request to LOINC, on my behalf, for a term yesterday. But for now we'd have to use a TBD-LOINC code. I'll add that
Kevin Power (Sep 25 2019 at 15:31):
I have added a proposal in the Resolution field of the tracker - stakeholders please review: @Bret H @Nephi Walton
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=24853
Patrick Werner (Sep 25 2019 at 15:40):
I would prefer https://dataexchange.clinicalgenome.org/interpretation/terminologies/AlleleOriginValueSet.html instead of creating our own CS and VS.
Kevin Power (Sep 25 2019 at 15:44):
That works for me -- @Bret H @Nephi Walton ?
Nephi Walton (Sep 25 2019 at 15:50):
that works for me as well. the only thing missing is if we know it is not inherited from one parent but have now knowledge about the other since this is still informative. I have been trying to find a report that describes this. But what is laid out with the GENO standard is great and will suffice.
Jamie Jones (Sep 25 2019 at 16:00):
@Patrick Werner isn't there additional workflow in pointing to SEPIO/GENO? Adding a row to TBD-codes and an textual example value set seems quicker to update and implement than introducing a new external code system at this point.
Patrick Werner (Sep 25 2019 at 16:10):
we shouldn't add our own CodeSystems just because we think it is faster. Creating a VS for an external CS is really easy. Will do that.
Kevin Power (Sep 25 2019 at 16:20):
Good middle ground :+1:
Kevin Power (Sep 25 2019 at 16:21):
And don't create it yet, we need to vote on this first. @Bret H - Do you mind making that update to the Resolution on the tracker to reflect this?
Patrick Werner (Sep 25 2019 at 16:35):
ok while creating, found this:
http://www.sequenceontology.org/browser/current_release/term/SO:0001762
Patrick Werner (Sep 25 2019 at 16:35):
even better, as we already are using SO
Kevin Power (Sep 25 2019 at 16:39):
So @Nephi Walton - Using the SO list would have some technical advantages, any concerns?
Jamie Jones (Sep 25 2019 at 16:44):
SO appears to be a more complete treatment of the concept. It still has difficulty modeling the "half-unknown" case, however--but it could be done in text
Patrick Werner (Sep 26 2019 at 09:42):
half unkown case?
Dora Walter (Sep 26 2019 at 12:05):
There are two ways Bret's request (proposed: create a new component in our IG before publishing to accommodate the element: Full-term name: Variant Inheritance / Shorthand name: InheritanceOfVariant / Value Set: De Novo, Uknown, Maternal, Paternal)
can be implemented so far, right?
Sequence Ontology (SO) that we are already using on other components in our IG or the new one mentioned above:
Value Set GENO IRI = Name: Allele Origin Value Set (SEPIO:0000392)
GENO:0000878 - maternally inherited
GENO:0000879 - paternally inherited
GENO:0000880 - de novo
GENO:0000881 - Unknown inheritance
GENO:0000888 - Parentally inherited
Value Set SO = Name: variant_origin (SO:0001762)
SO:0001775 - maternal_variant
SO:0001776 - paternal_variant
SO:0001781 - de_novo_variant
N/A - Unknown inheritance
N/A - Parentally inherited
instead of Parentally inherited: SO:0001778 - germline_variant (?)
SO:0001779 - pedigree_specific_variant
SO:0001780 - population_specific_variant
Patrick Werner (Sep 26 2019 at 12:59):
i thought of adding unknown from another CS, but do we really need it? Unknown = don't use this component...
Bret H (Sep 26 2019 at 13:28):
@Nephi Walton okay to not use unknown or parentally inherited? Depends on what those terms mean. Also, Parentally inherited was not in the request (I thought). Using SO would be preferred as we use SO elsewhere. @Patrick Werner you can use multiple code systems if we create a vs, but I'm not sure about using GENO at all. My suggestion is to give the value-codable concept extensible binding use SO for the terms. @Nephi Walton you okay with the absence of 'unknown' and 'parentally inherited' (whatever that is supposed to mean - could be both parents or ? you have pedigree_specific_variant in SO to indicate that the variant comes from genetically related ancestors. if that is what the term is meant to mean) ?
Patrick Werner (Sep 26 2019 at 13:31):
My suggestion is to give the value-codable concept extensible binding use SO for the terms.
I think the concepts here sufficient, would go for required
Bret H (Sep 26 2019 at 13:40):
could be sufficient - if Unknown is not needed. The solution to not report when (provide a null) when the value is unknown leaves it ambiguous weather an attempt to determine a value was made. However, I have argued for years with Lab folks weather or not 'unknown' or 'indeterminate' or 'data absent' (flavors of null) really improve the decision making of man or machine. For some observations, there is a different meaning between 'indeterminate' (some value there, but not a threshold) versus 'data-absent.' In our case of 'variant origin' or 'variant inherited from,' I do not think a computer or person is benefited by 'unknown' being reported. @Nephi Walton If you saw unknown or value-absent on a report would that change your determination?
Nephi Walton (Sep 26 2019 at 15:21):
sorry for coming in late. We have to have unknown, that is a very common finding. Parentally inherited is not needed. neither are pedigree specific variant or population specific variant. Reports do use the term unknown. If its null it is not useful as it is not clear whether it is unknown or unreported. The sequence ontology should be updated.
Nephi Walton (Sep 26 2019 at 15:29):
half unkown case?
Often we send the patients test only with the mothers DNA and in rare cases only the fathers due to the unavailability or unwillingness of the other parent. Knowing it is not in one parent can still be very useful. For example if a mother and a child both have epilepsy and you find a variant of unknown significance that is in the child but not in the mother that is less likely to be pathogenic. This is useful information to have.
Bret H (Sep 27 2019 at 02:38):
@Nephi Walton wouldn't it be useful in the half unknown case to say - Not maternal/Paternal unknown OR Not Paternal/Maternal unknown ? Is there any other values that folks will need? My thinking is to use the parent SO term and request Karen to add the additional terms that are missing. SO is very flexible. If we create a value set based on subsumption from the SO code that will allow us to inherit additions without changing our value set. @Patrick Werner I think for this version we need to use 'preferred' to allow for unanticipated values - but I'm flexible on this point.
Kevin Power (Sep 27 2019 at 18:01):
As a reminder, we need a finalized proposal ASAP so that we can be ready to discuss on Monday, then vote on Tuesday if we want to get this into the first release. @Bret H @Nephi Walton
Bret H (Sep 27 2019 at 18:58):
I'll write one up shortly. Sounds like Nephi is good with SO as long as we get flavors of unknown.
Bret H (Sep 27 2019 at 19:05):
@Kevin Power Should I rewrite what's in the geforge here or just make a comment about the value set in the geforge? How would you like me to propose?
Kevin Power (Sep 27 2019 at 19:22):
We need the final proposal on the tracker
Bret H (Sep 27 2019 at 21:58):
Here's the final proposal as it is in Gforge for Monday September 30, 2019 -- looking forward to Monday
FINAL proposal is to Define a new component on the Variant profile.
- New code in CodeSystem/tdb-codes (LOINC code has been seperatly request from LOINC by Bret Heale)
code: variant-inheritance
display: Variant Inheritance
definition: Indicates if the variant was inherited from the patient's mother or father.
- New ValueSet/variant-inheritance
Value Set SO = Name: variant_origin (SO:0001762)
SO:0001775 - maternal_variant
SO:0001776 - paternal_variant
SO:0001781 - de_novo_variant
N/A - Unknown inheritance (needs to be added - not currently in SO)
N/A - Parentally inherited
instead of Parentally inherited: SO:0001778 - germline_variant (?)
SO:0001779 - pedigree_specific_variant
SO:0001780 - population_specific_variant
*Thank you all very, very much for your attention and discussion.
Kevin Power (Sep 27 2019 at 22:07):
Thanks @Bret H - Some clarifications:
1) Looks like you are saying we need to add 'unknown', but how about these?
-- 'Parentally inherited' ? You didn't call out 'need to add' or anything, so not sure if you feel it needs to be there?
-- 'germline_variant' ? The (?) you left makes it unclear if you feel it needs to be there?
2) I didn't think we needed the last two (pedigree and population)? OK to leave, just wondering.
Jamie Jones (Sep 28 2019 at 01:50):
I believe Nephi was looking to be able to say ~"we know it's not from the mother, have no knowledge if it's from the father or de Novo," for example
Bret H (Sep 28 2019 at 02:51):
Yep that is right. Need to add unknown. Also need to add version of Parentally inherited. Dora suggested germline_variant. Just to make a clear proposition, I'll use germline_variant in the proposition and remove the ? marks.
Bret H (Sep 28 2019 at 02:53):
all done. geforge has no ambiguities in the proposition in the resolution.
Nephi Walton (Sep 30 2019 at 00:31):
the GENO value set makes more sense to me but I am open to either as long as we have unknown included as a value.
In cases where we only have one parents genetic information it would be ideal to indicate that we knew that it was not inherited from that parent.
Jamie Jones (Nov 02 2020 at 17:35):
This list came up on call today, wanted to point folks to the previous discussion and the JIRA version of the published tracker: FHIR#24853
Liz Amos (Nov 03 2020 at 18:56):
@Bret H Looking at the tracker, it seems you may have already requested a LOINC code? Do you know if it was completed?
Rachel Kutner (Nov 09 2020 at 15:34):
Sorry this took me a week to post.
I had looked into how to support this field for our data structure earlier this year, and we use Allelic Phase (https://loinc.org/LL4025-4/) with only the Maternal/Paternal/Unknown/Other answer values and Genomic Source Class (https://loinc.org/48002-0/) which includes De Novo designation.
My concern is that we are re-designing the FHIR spec in ways that are redundant to already existing concepts. De Novo (not inherited, not somatic) vs Germline (inherited) is already able to be designated in Genomic Source Class. I'm not sure what else this new concept provides that isn't in Allelic Phase.
Feedback I got about the values in the existing LOINC code for Allelic Phase:
- The first 5 values are confusing, even to experts in the field. They were concerned users would misuse these values, or misinterpret them. The concepts of cis and trans are relational, but this is attempting to note them in a non-relational manner, which is confusing to experts in both the clinic and the lab.
- The remaining values (Maternal, Paternal, Unknown) relate to the inheritance of the variant. From this, the phase can easily be determined.
My suggestion is as follows:
- Have one concept and LOINC code called "Allele Inheritance" and only include Maternal, Paternal, Unknown values.
- Have one relational concept/LOINC code that includes Cis and Trans values, which can be used to describe relationships between one or more variants. These values must have 2 or more variants attached to make sense.
Jamie Jones (Nov 09 2020 at 15:39):
Awesome! I like your suggestion a lot. We have an open tracker (yours) https://jira.hl7.org/browse/FHIR-27743 that can cover suggestion.1, and I believe a review of the lightweight sequence-phase-relationship profile http://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-sequence-phase-relationship.html should cover suggestion.2 Thoughts?
Jamie Jones (Nov 23 2020 at 17:45):
looking to nail down the 'unknown' aspect of the answer list here for the proposal to FHIR#29780. @Rachel Kutner how do you feel about using the last 4 answers from https://loinc.org/LL4025-4/:
Maternal LA26320-4
Paternal LA26321-2
Unknown. LA4489-6
Other, Please specify: LA46-8
the 'Other' code allows folks to describe the 'known not maternal'/ 'known not paternal' and other niche cases without needing to repeat this component or make the binding extensible. @Patrick Werner, is there an easy way to point to this subset of the LL?
Rachel Kutner (Nov 23 2020 at 19:32):
If this is an extensible binding, is there a benefit to "Please specify" in "Other"?
I'm just thinking that in our documentation of these values, we're trying to codify them as much as possible. We would likely want to map these values to a specific answer list, and add values that make sense as users identify reasonable additional use cases. Placing this as "Other, please specify" encourages use of these concepts in a way that isn't discrete, which can cause issues from a data structure/reporting perspective. It would mean that it is difficult to find all variants that were marked "Not Paternal" for a gene if that is a free text value rather than a codified value.
That can all be changed based on the implementation decisions an individual institution makes when implementing the IG, but thought I'd bring it up in case it is relevant.
Jamie Jones (Nov 23 2020 at 19:41):
I like your argument in favor of extensible over the use of 'Other'. It is also more internally consistent so let's keep it at the first 3 + extensible binding. An exhaustive list would be preferable, but we have yet to identify or define one :).
Patrick Werner (Dec 02 2020 at 09:01):
I can see the argument for extensible here. But extensible bindings can't be validated properly by a machine.
What would be the reason for other? I can inherit my variant from my father or mother, thats it in terms of heredity.
Jamie Jones (Dec 02 2020 at 14:13):
Known not maternal, known not paternal
Patrick Werner (Dec 02 2020 at 17:10):
fair point.
Patrick Werner (Dec 02 2020 at 17:12):
so the VS could be: maternal , paternal, unknown, not inherited
Patrick Werner (Dec 02 2020 at 17:13):
VS as the answer to the question: From which parent was the variant inherited?
Jamie Jones (Dec 02 2020 at 17:39):
to be exhaustive for Nephi's use case we'd want the separate versions of 'not maternal' and 'not paternal' along with 'not inherited'. Can drive care differently
Patrick Werner (Dec 07 2020 at 08:45):
Ah! Didn't catch the meaning: not-paternal --> paternal tested, maternal unknown
Last updated: Apr 12 2022 at 19:14 UTC
