Stream: genomics
Topic: DNA change type
Patrick Werner (Jul 17 2019 at 19:15):
Unfortunately the LOINC answer list (https://s.details.loinc.org/LOINC/48019-4.html?sections=Comprehensive) has missing concepts like copy number variation.
GF#16264 adresses some/all? missing concepts but these weren't applied to LOINC and won't make it into the LOINC list in time for our release.
Patrick Werner (Jul 18 2019 at 09:40):
quick solution: create our own DNA change type valueSet with concepts from SO
Patrick Werner (Jul 18 2019 at 15:14):
could look like this: https://github.com/HL7/genomics-reporting/blob/master/src/resources/valueset-dna-change-type.json
Patrick Werner (Jul 18 2019 at 15:15):
This includes all concepts below sequence_comparison which is more than the LOINC list but includes everything from the LOINC list
Patrick Werner (Jul 18 2019 at 15:25):
this is the mapping: https://docs.google.com/spreadsheets/d/1IZYGLR18hYwKMhNJxG_NO-JhSS1ZxTJ5RviqDx8iBe0/edit?usp=sharing
Kevin Power (Jul 19 2019 at 13:48):
So, does this meet your requirements for "Variant Type" as well?
Patrick Werner (Jul 22 2019 at 15:01):
No, DNA change type would be everything under sequence_comparison: http://www.sequenceontology.org/browser/current_release/term/SO:0002072
Patrick Werner (Jul 22 2019 at 15:04):
the functional annotation would be either everything under: sequence_variant http://www.sequenceontology.org/browser/current_release/term/SO:0001060 or more likely only terms under structural variant: http://www.sequenceontology.org/browser/current_release/term/SO:0001537
Bret H (Jul 29 2019 at 15:00):
Adding the question here: There was good discussion and contribution from many folks last week. With regards to the value set for DNA change type, I think we should reconsider the value set from LOINC codes that we offer. Sequence Ontology is an ontology for the specific concepts we would want to use here. In general, LOINC answer lists are examples to provide a better understanding of the LOINC code which refers to the answer list. Given that SO's purview is molecular concepts for DNA/RNA and amino acids, it is likely that SO will remain ahead of LOINC, in terms of completeness of the concepts used as values for the LOINC term. I recommend we take another look at SO versus LA codes here. I can't recall the specific argument to use LA codes in our value set. But , if we use a value set of SO terms and mark the value element with 'extensible,' we will guide systems into using SO and allow for systems that use LA codes. To sum up, I think we should consider changing the value set for the component 'DNA change type' to SO with the value set as extensible (http://build.fhir.org/ig/HL7/genomics-reporting/obs-variant-definitions.html#Observation.component:dna-chg-type). Anyone agree? Thoughts? Comments?
Patrick Werner (Jul 29 2019 at 15:26):
as stated last weeks monday: the LOINC AnswerList is incomplete and misses some already agreed on and voted on concepts. So we would need to extend the LOINC AnswerList which implies creating our own ValueSet. Also LOINC doesn't allow us to check if one concept subsumes another.
Patrick Werner (Jul 29 2019 at 15:26):
Therefore i proposed this resolution one week ago:
Updated Proposal:
Update DNA-change type (48019-4) preferred binding to SO (anything under SO:0002072)
Provide concept map to LOINC (code systems appendix??) (based on this)
Add slice for Coding with system = loinc.org
Add variant annotation (TBD) bound to SO (anything under SO:0001537)
Get feedback
Patrick Werner (Jul 29 2019 at 15:28):
open question: binding strength
Patrick Werner (Jul 29 2019 at 15:30):
I would almost go with required. LOINC is easily mappable to SO, other CS as well
Patrick Werner (Jul 29 2019 at 15:31):
The extra coding slice system=loinc binding would be to show people how they can send Loinc codes as well
Bret H (Jul 29 2019 at 15:32):
for now, I'd go with binding: extensible. If folks really find SO useful and complete then I have faith in the pragmatism of implementers to use the list from SO as we provide. I don't think you need to go all the way to a LOINC answer list slice (pretty technically cool). As I recall, alternative codes from codesets can be provided in a valueset profile
Patrick Werner (Jul 29 2019 at 15:42):
I would slice coding, and set the system to Loinc. But yes it would complicate our profile and would be only a technical way of saying: "you can send alternative Codings as well, but you have to send SO"
Patrick Werner (Jul 29 2019 at 15:45):
To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
So with extensible i can't come up with an example where this would be useful.
Bret H (Jul 29 2019 at 16:02):
that's why I have faith that pragmatic developers would stick with SO codes
Kevin Power (Jul 29 2019 at 19:40):
I am good with @Patrick Werner 's proposal above - I would probably set the binding to Required. I would like to think everyone could map to SO, but of course we could open up later if needed.
Bret H (Feb 16 2022 at 17:46):
Patrick Werner said:
Therefore i proposed this resolution one week ago:
Updated Proposal:
Update DNA-change type (48019-4) preferred binding to SO (anything under SO:0002072)
Provide concept map to LOINC (code systems appendix??) (based on this)
Add slice for Coding with system = loinc.org
Add variant annotation (TBD) bound to SO (anything under SO:0001537)
Get feedback
Jamie Jones (Feb 17 2022 at 18:54):
Hoping folks can consider the sublist of SO:0001537 used by Ensembl VEP: https://useast.ensembl.org/info/genome/variation/prediction/predicted_data.html
Bret H (Feb 17 2022 at 20:39):
This is for the coding-change-type component. 0001537 would be in the molecular-consequence component, right? @Jamie Jones
Last updated: Apr 12 2022 at 19:14 UTC
