Skip to content
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

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

Open
b0d0nne11 opened this issue Dec 19, 2023 · 3 comments · May be fixed by #719
Open

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

b0d0nne11 opened this issue Dec 19, 2023 · 3 comments · May be fixed by #719
Labels
keep alive exempt issue from staleness checks

Comments

@b0d0nne11
Copy link
Contributor

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
Copy link
Contributor Author

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

@b0d0nne11 b0d0nne11 linked a pull request Jan 23, 2024 that will close this issue
@reece
Copy link
Member

reece commented Mar 5, 2024

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.

Copy link

github-actions bot commented Jun 4, 2024

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.

@github-actions github-actions bot added the stale Issue is stale and subject to automatic closing label Jun 4, 2024
@jsstevenson jsstevenson added keep alive exempt issue from staleness checks and removed stale Issue is stale and subject to automatic closing labels Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
keep alive exempt issue from staleness checks
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants