Faulty right-shifting of deletions for protein annotations

[roland-ewald]

Summary

It seems that AminoAcidChangeNormalizer#normalizeDeletion currently does not correctly right-shift protein sequences, introducing erroneous protein change HGVS annotations. Other kinds of variants (besides deletions) may be affected as well.

Problem

The current code addresses the problems with deletions introducing frameshifts by avoiding right-shifting in those cases altogether, by checking change.getAlt().length() != 0.
This may be wrong if the frame-shifted sequence introduces the same amino acid(s) that would have followed in the wild type as well. It also does not address the following corner case:

• consider a deletion coinciding with the start of a codon, so that changeBeginPos.getFrameshift() == 0
  in the calling code (DeletionAnnotationBuilder), which means that insAA will be empty and thus normalization will be attempted by AminoAcidChangeNormalizer#normalizeDeletion
• assume the length of the deletion is not divisible by three, so it will itself introduce a frameshift, so that varAASeq (the AA sequence containing the variant) will differ significantly from from wtAASeq (the wildtype AA sequence) at the position of the deletion (and downstream)
• since AminoAcidChangeNormalizer#normalizeDeletion only operates on the wildtype AA sequence (wtAASeq), this goes unnoticed, and in case the sequence of deleted amino acids starts with the same amino acid(s) as those after the deletion in the wild type, the variant will be erroneously right-shifted on that wild-type sequence (the right-shifting currently does not consider varAASeq at all)

Example (for corner case, see above)

Consider the following deletion (from a unit test in the PR attempting to fix this issue).

Wildtype AA sequence:      H | T | G | E | K | P |fs F| E | C |
                     GGAAACAT|ACT|GGG|GAG|AAA|CCC| TTT|GAG|TGT|CCCAAATGTGGGAAGTGTTACTTTCGGAAGGAGA..
                     GGAAACAT|ACT|GGG|---|---|---|-TTG|AGT|GTC|CCAAATGT..
                                                 |  L | S | V |

Before AminoAcidChangeNormalizer#normalizeDeletion gets called, AminoAcidChange will be 'EKPF'>''. However, due to the above problem this will be right-shifted to KPFE>'' (as the first E in the wildtype sequence gets compared to the second E in the wildtype in the above example; afterwards K will be compared to C, which is wrong, so that shift = 1).

This approach leads to a wrong position and a wrong AA displayed in the variant's protein change HGVS annotation. In this example, the protein change should be p.(Glu316Leufs*25) (in one-letter codes, p.(E316Lfs*25)) but is erroneously changed to p.(Lys317Serfs*24) (p.(K317Sfs*24)).

Solution: more general approach for right-shifting

In contrast to the current right-shifting code for nucleotides, it seems a better approach here would be to simply compare both wild-type and variant AA sequence, as they already have been computed by the AminoAcidChangeNormalizer anyhow. This approach has been implemented and tested in the accompanying PR (#499).

Now, right-shifting also happens in case a deletion does not coincide with a codon start (i.e. insAA is non-empty, as checked by the previous code to avoid normalization). This is necessary because the resulting sequence in the variant AA sequence (varAASeq) could still continue with the same amino acids as the wild type sequence would have, even for deletions that do not coincide with the beginning of a codon. For example:

Wildtype AA sequence:      H | T | G | E | K | P | F | E | C |
                     GGAAACAT|ACT|GGG|GAG|AAA|CCC|TTT|GAG|TGT|CCCAAATGTGGGAAGTGTTACTTTCGGAAGGAGA..
                     GGAAACAT|ACT|GG-|--G|AAA|CCC|TTT|AGT|GTC|CCAAATGT..
                                     | G | K | P |

This deletion would not have been normalized before, although the deletion results in the varant AA sequence continuing with the same AA (G) and thus the variant needs to be right-shifted by one.

Related issues

• it seems HGVS protein annotation error for deletions (may impact other mutation types e.g. ins) #481 may be related to this issue
• if the above reasoning is correct, the code on which InsertionAnnotationBuilder relies for protein sequence normalization may need to be changed correspondingly (happy to help here).