search

biocommons / hgvs

Python library to parse, format, validate, normalize, and map sequence variants. `pip install hgvs`
https://hgvs.readthedocs.io/
Apache License 2.0
233 stars 94 forks source link

c_to_p at intron/exon boundary where splice region is preserved #714

Open b0d0nne11 opened 6 months ago

b0d0nne11 commented 6 months ago

We have a number of ins or dup variants at the intron/exon or exon/intron boundary that return no protein change that we believe should be treated as coding because the splice site & region remain completely intact. This is related to issue #655. There we handled variants that occur at boundary but here we're concerned with variants that span the boundary. We chose to treat these as separate issues because we can't rely only on the offset positions for these variants so our approach needs to be different.

For example:

In [1]: var_c = parse('NM_004119.2:c.1837+21_1837+22insCGAGAGAATATGAATATGATCTCAAATGGGAGTTTCCAAGAGAAAATTTAGAGTTTGGTAAGAATGGAATGTGCCAAA')
In [2]: c_to_p(var_c)
Out[2]: SequenceVariant(ac=NP_004110.2, type=p, posedit=None, gene=None)

We expect this to map to NP_004110.2:p.(Lys614_Val615insAsnGlyMetCysGlnThrArgGluTyrGluTyrAspLeuLysTrpGluPheProArgGluAsnLeuGluPheGlyLys)

To fix, when calculating c_to_p if you end up with no protein change try shifting the var_g (negative_normalizer if strand==1, normalizer if strand==-1) and then sending the shifted mutation through the g_to_c and c_to_p to see if it gets a protein change. If it gets a protein change, report this change as hgvs_p.

For example:

In [3]: var_c = parse('NM_004119.2:c.1837+21_1837+22insCGAGAGAATATGAATATGATCTCAAATGGGAGTTTCCAAGAGAAAATTTAGAGTTTGGTAAGAATGGAATGTGCCAAA')
In [4]: import hgvs
In [5]: normalizer = hgvs.normalizer.Normalizer(hdp, shuffle_direction=3)
In [6]: var_g = normalizer.normalize(c_to_g(var_c))
In [7]: var_c = g_to_c(var_g, var_c.ac)
In [8]: c_to_p(var_c)
Out[8]: SequenceVariant(ac=NP_004110.2, type=p, posedit=(Lys614_Val615insAsnGlyMetCysGlnThrArgGluTyrGluTyrAspLeuLysTrpGluPheProArgGluAsnLeuGluPheGlyLys), gene=None)
b0d0nne11 commented 6 months ago

I am working on a fix for this. I expect to have it ready to submit a PR shortly after PR #709 is merged.

reece commented 4 months ago

As with #715, please elaborate on why you think an intronic insert results in NP_004110.2:p.(Lys614_Val615insAsnGlyMetCysGlnThrArgGluTyrGluTyrAspLeuLysTrpGluPheProArgGluAsnLeuGluPheGlyLys).

This might be biologically justified, but I'm also thinking about what the HGVS Nomenclature says/doesn't say, and how to reconcile this.

github-actions[bot] commented 4 weeks ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.