Correct handling of deletions spanning the stop codon?

[Peter-J-Freeman]

Hi,

We have identified the following variant and are struggling to determine the proper protein nomenclature:

NM_001005242.3(PKP2):c.2510_*1del
chr12:32792422 CCTCAGT > C

This is a 6 bp deletion that results in the loss of the last amino acid in the protein (Asp837), loss of the termination codon, and extension by two amino acids (Gly-Lys) before a new termination codon. The Variant Validator program is unable to provide a protein nomenclature (just p.?) and the Mutalyzer 3 program returns p.(Asp837GlyfsTer3). I at first thought Mutalyzer to be incorrect as my understanding was that the extension should be prioritized - but reading a previous thread on this forum (https://groups.google.com/g/hgvs-nomenclature/c/2S9Jdcquk_Y/m/wVer8TpCBgAJ [groups.google.com]) seems to imply that my variant type is not technically an extension because the last amino acid is changed. Nomenclature that only describes the extension doesn't quite seem correct, as it does not also describe loss of Asp837. The closest I could come up with would be p.(Asp837delextTer2), but I've not seen a variant described like this before. Perhaps Mutalyzer is correct? Thank you for any help you can provide!

--
You received this message because you are subscribed to the Google Groups "HGVS Nomenclature" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hgvs-nomenclature+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hgvs-nomenclature/76ce0541-48bc-41e6-a55f-da08bcbc15c7n%40googlegroups.com [groups.google.com].

[Peter-J-Freeman]

@leicray @ifokkema any thoughts on the correct output before we go on?

p.(Asp837GlyfsTer3) seems incorrect as a 6bp del is not a frameshift. To me something like a delins of the Asp837andTer then insertion of the GlyfsTer3 sees most likely

[Peter-J-Freeman]

a quick bypass of an over zelous if statemtnt produces NP_001005242.2:p.(Asp837delinsGlyLys) from

ref_translation
MAAPGAPAEYGYIRTVLGQQILGQLDSSSLALPSEAKLKLAGSSGRGGQTVKSLRIQEQVQQTLARKGRSSVGNGNLHRTSSVPEYVYNLHLVENDFVGGRSPVPKTYDMLKAGTTATYEGRWGRGTAQYSSQKSVEERSLRHPLRRLEISPDSSPERAHYTHSDYQYSQRSQAGHTLHHQESRRAALLVPPRYARSEIVGVSRAGTTSRQRHFDTYHRQYQHGSVSDTVFDSIPANPALLTYPRPGTSRSMGNLLEKENYLTAGLTVGQVRPLVPLQPVTQNRASRSSWHQSSFHSTRTLREAGPSVAVDSSGRRAHLTVGQAAAGGSGNLLTERSTFTDSQLGNADMEMTLERAVSMLEADHMLPSRISAAATFIQHECFQKSEARKRVNQLRGILKLLQLLKVQNEDVQRAVCGALRNLVFEDNDNKLEVAELNGVPRLLQVLKQTRDLETKKQITGLLWNLSSNDKLKNLMITEALLTLTENIIIPFSGWPEGDYPKANGLLDFDIFYNVTGCLRNMSSAGADGRKAMRRCDGLIDSLVHYVRGTIADYQPDDKATENCVCILHNLSYQLEAELPEKYSQNIYIQNRNIQTDNNKSIGCFGSRSRKVKEQYQDVPMPEEKSNPKGVEWLWHSIVIRMYLSLIAKSVRNYTQEASLGALQNLTAGSGPMPTSVAQTVVQKESGLQHTRKMLHVGDPSVKKTAISLLRNLSRNLSLQNEIAKETLPDLVSIIPDTVPSTDLLIETTASACYTLNNIIQNSYQNARDLLNTGGIQKIMAISAGDAYASNKASKAASVLLYSLWAHTELHHAYKKAQFKKTDFVNSRTAKAYHSLKD*
var_translation
MAAPGAPAEYGYIRTVLGQQILGQLDSSSLALPSEAKLKLAGSSGRGGQTVKSLRIQEQVQQTLARKGRSSVGNGNLHRTSSVPEYVYNLHLVENDFVGGRSPVPKTYDMLKAGTTATYEGRWGRGTAQYSSQKSVEERSLRHPLRRLEISPDSSPERAHYTHSDYQYSQRSQAGHTLHHQESRRAALLVPPRYARSEIVGVSRAGTTSRQRHFDTYHRQYQHGSVSDTVFDSIPANPALLTYPRPGTSRSMGNLLEKENYLTAGLTVGQVRPLVPLQPVTQNRASRSSWHQSSFHSTRTLREAGPSVAVDSSGRRAHLTVGQAAAGGSGNLLTERSTFTDSQLGNADMEMTLERAVSMLEADHMLPSRISAAATFIQHECFQKSEARKRVNQLRGILKLLQLLKVQNEDVQRAVCGALRNLVFEDNDNKLEVAELNGVPRLLQVLKQTRDLETKKQITGLLWNLSSNDKLKNLMITEALLTLTENIIIPFSGWPEGDYPKANGLLDFDIFYNVTGCLRNMSSAGADGRKAMRRCDGLIDSLVHYVRGTIADYQPDDKATENCVCILHNLSYQLEAELPEKYSQNIYIQNRNIQTDNNKSIGCFGSRSRKVKEQYQDVPMPEEKSNPKGVEWLWHSIVIRMYLSLIAKSVRNYTQEASLGALQNLTAGSGPMPTSVAQTVVQKESGLQHTRKMLHVGDPSVKKTAISLLRNLSRNLSLQNEIAKETLPDLVSIIPDTVPSTDLLIETTASACYTLNNIIQNSYQNARDLLNTGGIQKIMAISAGDAYASNKASKAASVLLYSLWAHTELHHAYKKAQFKKTDFVNSRTAKAYHSLKGK*

It seems reasonable to me ???

[Peter-J-Freeman]

also seeing

NM_001005242.3:c.2510_*1inv > NP_001005242.2:p.(Asp837_Ter838delinsAlaGlnTer)

NM_001005242.3:c.2510_*1delinsAAA > NP_001005242.2:p.(Asp837delinsGluArgLys)

@ifokkema , do you have a bunch of c. variants that affect the stop codon *1 to *3 that we can build tests from pls. Need some balanced indels, and some fs

[Peter-J-Freeman]

Good news, some existing tests broke

NM_000088.3:c.4392_*5inv now becomes NP_000079.2:p.(Ter1465GluextTer27)

NM_000088.3:c.4390_*7inv now becomes NP_000079.2:p.(Leu1464_Ter1465delinsArgGluPheThrAlaIleProThrTrpLeuProProThrGlnProThrPheProProThrArgLysGlnThrSerAsnProAsnTer)

In all these cases I am not saying VV is getting it right. Need input from @leicray and @ifokkema but it used to simply be p.? ans at least the outputs are now closer to correct

[Peter-J-Freeman]

NM_001005242.3:c.2514_*1del > NP_001005242.2:p.(Ter838TrpextTer42)
NM_001005242.3(PKP2):c.2513_*1del > NP_001005242.2:p.(Ter838=) where I guess the deletion resotres a Ter at the same position

[ifokkema]

The HGVS Nomenclature website states:

deletions starting 5' of and including the translation termination (stop) codon are described as frameshift.

So, p.(Asp837GlyfsTer3) sounds correct (although I didn't check the sequence).

On the Extension page I read:

prioritisation: (1) extension, (2) frameshift or deletion-insertion.

It's not an extension as that requires the original amino acid code to not change, but it has changed. So also that page suggests we should use a frameshift.

I remain annoyed with this total disregard for the "name each level as observed, independent of the DNA level" rule... but according to what I'm reading, we should use a frameshift.

I'll see if I have some more examples for you.

[Peter-J-Freeman]

deletions starting 5' of and including the translation termination (stop) codon are described as frameshift.

Why though? A deletion of 6 bases is not a shifted frame. A frame shift is a change of the Open Reading Frame, the frame had not shifted. Makes no sense.

Also, this is misleading. When folks see Fram Shift they immediately look at LOF and potential NMD. In this case thoug, it is a single amino acid delins. NP_001005242.2:p.(Asp837delinsGlyLys) which removed 1 amino acid and adds 2 in before terminating.

Does this also apply to variants spanning the stop codon entirely.

What about delins, what about inv, what about dups?

I think the HGVS need to review this. In my opinion, calling these frame shifts are the most misleading way in which you could possibly describe such variants

[Peter-J-Freeman]

OK, consistent in delins via https://hgvs-nomenclature.org/stable/recommendations/protein/delins/ also says frameshift

insertions should likely not be considered as if they affect the stop codon, they will be within it, before it or after it and the inserted position is effectively at the zero-based position.

in duplication page we see "duplications on the DNA or RNA level, starting N-terminal of and including the translation termination (stop) codon usually have no (predicted) effect on the protein level." https://hgvs-nomenclature.org/stable/recommendations/protein/duplication/. Again, why? We can perform the translation. This is inconsistent with the del and delins scenario.

Why under the Protein drop down where we find this guidance is there no page covering inversions? Are these treated like delins?

When we read, deletions starting 5' of and including the translation termination (stop) codon are described as frameshift, does this mean ending within the stop codon or spanning the codon as well.

So my questions.

Why frameshift for in frame dels, indels and likely if we apply the same rules, inversions (which are always in frame).
In practical terms

• Do I apply to all dels, delins and invs where the stop codon is spanned?
• What do I do with dups. We will of course make an accurate translation and give some sort of output.
• I assume ins can just be left alone?

[ifokkema]

deletions starting 5' of and including the translation termination (stop) codon are described as frameshift.

Why though? A deletion of 6 bases is not a shifted frame. A frame shift is a change of the Open Reading Frame, the frame had not shifted. Makes no sense.

I assume because the length of the deletion doesn't matter; you've entered the UTR, and you're getting nonsense translated. But yeah, the protein level is a mess. Insertions with a length non-divisible by three are not a frameshift when the inserted sequence itself already contains a Ter. That's also kinda confusing.

Also, this is misleading. When folks see Fram Shift they immediately look at LOF and potential NMD. In this case thoug, it is a single amino acid delins. NP_001005242.2:p.(Asp837delinsGlyLys) which removed 1 amino acid and adds 2 in before terminating.

Any frameshift has this problem... also if a single base is removed from the last codon before the Ter. It would be a frameshift following any logic, but it has the same issue that you highlight here. A deletion-insertion description would solve this problem, and may allow us to finally solve the messed-up protein-level descriptions.

Does this also apply to variants spanning the stop codon entirely.

If only the Ter is affected, it's an extension. If the deletion affects any amino acid from the reference sequence, it's a frameshift.

What about delins, what about inv, what about dups?

As always, the Nomenclature pages hide rules across various pages. For delins, it depends on whether the inserted sequence contains the new Ter. If yes, delins. If not, frameshift. Inversions don't exist on protein level, so I assume the delins rule is followed. The inversion page states: "Depending on the (predicted) consequences of an inversion on protein level, changes are usually described as either a delins or a frameshift". Dups follow the same rules, but the page notes: "duplications on the DNA or RNA level, starting N-terminal of and including the translation termination (stop) codon usually have no (predicted) effect on the protein level".

I think the HGVS need to review this. In my opinion, calling these frame shifts are the most misleading way in which you could possibly describe such variants

See also: HGVSnomenclature/hgvs-nomenclature#240
Feel free to take part, and/or add your points. If you want, you can get me and perhaps Jeroen on board to submit a proposal. I'm already running a few initiatives (Jeroen, too), so we'll need you to push it, but we (well, at least I) can support you in the committee. I'm just assuming that Jeroen thinks this is annoying, too.

For other examples (the third protein change seems invalid to me):

Transcript	DNA	Protein
NM_000074.2	c.782_*2del	p.(Leu261GlnfsTer50)
NM_015474.3	c.1273_*2del	p.(Asn425ValfsTer48)
NM_000330.3	c.658_*7del	p.(Val220_Ala224delinsLeuSerSerAlaProAlaArgGly)
NM_000280.3	c.1268_*1dup	p.(=)
NM_001130144.2	c.3910_*6dup	p.(=)
NM_144573.3	c.2026_*1del	p.(Ter676HisextTer8)
NM_000277.1	c.1357_*2del	p.(Ter453ProextTer33)

[ifokkema]

insertions should likely not be considered as if they affect the stop codon, they will be within it, before it or after it and the inserted position is effectively at the zero-based position.

I'm not sure if I fully follow; insertions on DNA level are on protein level either insertions, duplications, extensions, or frameshifts.

in duplication page we see "duplications on the DNA or RNA level, starting N-terminal of and including the translation termination (stop) codon usually have no (predicted) effect on the protein level." https://hgvs-nomenclature.org/stable/recommendations/protein/duplication/. Again, why? We can perform the translation. This is inconsistent with the del and delins scenario.

Why? If you translate the sequence, you can see that nothing happens.

Why under the Protein drop down where we find this guidance is there no page covering inversions? Are these treated like delins?

Nowhere there; I found it on the DNA page of inversions as protein inversions do not exist. It's messy, really...

When we read, deletions starting 5' of and including the translation termination (stop) codon are described as frameshift, does this mean ending within the stop codon or spanning the codon as well.

Anywhere in the codon. But do note that a substitution to Ter is also possible, if that is the first changed amino acid.

Why frameshift for in frame dels, indels and likely if we apply the same rules, inversions (which are always in frame). In practical terms

• Do I apply to all dels, delins and invs where the stop codon is spanned?
• What do I do with dups. We will of course make an accurate translation and give some sort of output.
• I assume ins can just be left alone?

I hope the above will already answer these questions. If you're still stuck, let me know, and maybe we can create a proper decision tree that we can present to the committee as well (unless we want to burn the fs syntax completely, then that should maybe be the proposal).

[Peter-J-Freeman]

NM_000330.3	c.658_*7del	p.(Val220_Ala224delinsLeuSerSerAlaProAlaArgGly)

Think this should actuall be a fs NP_000321.1:p.Val220LeufsTer9

[Peter-J-Freeman]

NM_000280.3	c.1268_*1dup	p.(=)

is actually NM_000280.3:c.*19_*21dup I think and we would give it currently p.?

[Peter-J-Freeman]

NM_001130144.2	c.3910_*6dup	p.(=)

bit of a pain

    "validation_warnings": [
        "Failed to find NP_001123616.1 in our sequence store: This may mean that the sequence has been mistyped, or it may be missing from our data, possibly due to being either deprecated or yet to be added.",

also

    "validation_warnings": [
        "Failed to find NP_000271.1 in our sequence store: This may mean that the sequence has been mistyped, or it may be missing from our data, possibly due to being either deprecated or yet to be added.",

one to check on the update of the dbs @John-F-Wagstaff

[Peter-J-Freeman]

Tests that are now passing from @ifokkema

Transcript	DNA	Protein
NM_000074.2	c.782_*2del	p.(Leu261GlnfsTer50)
NM_015474.3	c.1273_*2del	p.(Asn425ValfsTer48)
NM_000330.3	c.658_*7del	p.Val220LeufsTer9
NM_144573.3	c.2026_*1del	p.(Ter676HisextTer8)
NM_000277.1	c.1357_*2del	p.(Ter453ProextTer33)

The also the original test in here
NM_001005242.3:c.2510_*1del > NP_001005242.2:p.(Asp837GlyfsTer3) also passing

So, we have tested some dels and invs. Need a few delins.

[Peter-J-Freeman]

For NM_001005242.3:c.2510_*1delinsTT, we get NP_001005242.2:p.(Asp837ValfsTer49) but Mutalyzer is showing NM_001005242.3(NP_001005242.2):p.(Asp837delinsValGluAsnAspLysValPheSerAlaAlaLysIleProLysGlyLysHisLeuPhePheTyrTyrProAlaGlnGluThrSerLysAlaCysLeuValSerIleLeuLeuTyrPheArgGlyProLeuAsnProGluAsnLys). We are mostly aligned with them in the tests I have, but to me, they are wrong here given the above rules. Last codonaffected > Frameshift