-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
most severe consequence polypyrimidine stretch #2031
Comments
Thanks for reporting @dnil, Can you clarify a little on what you mean with: Any chances of getting VEP adapt, eg the SO scale? |
Ooh, nice catch - I didn't check what field had the -12! It is a recessive condition with some carriers, so not completely strange to find it among variants found benign on array at some point. I can talk to the array ppl about that part! As for the VEP part, I mean even if this would not have got the 10 I feel it should have for transcript ablation, it would at the very least get its 7 for coding_sequence_variant if that was higher prio for most_severe_consequence than the lower scoring (5) splice_polypyrimidine_tract_variant. We could patch that on our with raising the latter to score 7; which might arguably be consistent. Or by swapping the order for most severe consequence prio, but then it would feel better to also discuss a bit with the VEP/SO folks about it. |
I've contacted the aCGH folks, but if we can't find a simple solution for the db-export to properly cover the zygosity of calls, just ditching the benign aCGH track seems like a good option. We were about to do that for the hg38 migration anyway. It would have helped, but fiddling with a two point difference in score for functional annotation seems moot when we have that huge malus to axe. Since we have a fairly big normal db anyway, we should make do just fine without the aCGH-benign track, possibly leaning towards increasing the penalty for being common locally a bit to compensate the missing benigns then, if a verification is still called for anyway. |
Hmm for the structural variants we do rank coding_sequence_variant as a more severe consequence than the splice_polymeridine_tract one so it should have gotten a 7. I need to look into whats going on here. Let me know if you think we should remove the benign cgh database. But yes this would mean a new validation and thus we would probably do it when we update tiddit and update our loqusDB dump. |
I am leaning that way: this would still be an issue with several recessive disorders with somewhat recurrent het carriers. Agne had some idea about another recurrent CNV file that he and Jesper made - waiting for a confirmation on wether these are still in there. |
Had another discussion with Agne: it was the CNV cluster track they used for collapsing the local aCGH db a bit, and weeded to not include pathogenic calls from said db. The same issue kind of remains, and this is a much smaller set than say loqus or svdb. I think we are still better off with the local data for count/frequency info, and then the pathogenic calls are great to complement the lack of SVs matching from ClinVar. |
Right, so to summarise you would like to not include the benign variants from the cgh array in the rankscore. However, we will still annotate called SV:s using that file. Did I get this right? |
Yes! On a lower prio, there is still something a little funny about the sort order for so term severity and the rank model scores not lining up - can't help but think that can come back and bite, but it would have felt best to correct at the source. |
Describe the bug
We are seeing more issues with the most severe consequence. We recently fixed the clinical filter in scout (Clinical-Genomics/scout#3858) to allow showing these nice little fellows, but that falls a bit short when the variant is not loaded. Currently, they also get a penalty from the rank model for being less clinically important, like this causative one from
pureamoeba
:It's a clear het deletion of several exons, called by all callers, but the most severe consequence becomes
splice_polypyrimidine_tract_variant
.We can update the SV rank score model to also include this as a (potentially) severe consequence for now perhaps?
Any chances of getting VEP adapt, eg the SO scale? I still feel from the textual definition, these warrant a "transcript_ablation" though the entire transcript is not gone.
Other options could include to revert to having coding_sequence_variant higher on the severity tree. It seems to be a fallback that is usually present on this kind of variants.
Software version (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: