[ensembl-dev] [VEP] consequence_term for two AA insertion

[Will McLaren]

Hi Joao,

The reasons for this are clearer if you look at the Amino_acids and Codons
fields in the VEP output.

For your first input, the bases are inserted between the first and second
bases of a codon, disrupting the original codon. The resulted translated
sequence is then "PQM", which shares no sequence with the original
translated codon ("L"), so inframe_insertion is not correct. Since you're
replacing an "L" with a different sequence, the most specific consequence
type VEP can call is protein_altering_variant.

Amino_acids: L/PQM   Codons: ctg/cCCCAAAtg

In your second input, the bases are inserted *between* a pair of codons, so
the original codons are not disrupted and inframe_insertion is valid.

Amino_acids: -/PK    Codons: -/CCCAAA

In the third input, while you are inserting in the same position as the
first input, the translated sequence still includes the original amino acid
as by chance the inserted sequence restores a codon that translates to that
amino acid:

Amino_acids: L/PL    Codons: ctg/cCCCtg

This also holds true for the fourth input, with the degeneracy of the amino
acid code helping out:

Amino_acids: L/LPK   Codons: ctg/ctCCCAAAg

Hope this helps

Will McLaren
Ensembl Variation

On 3 November 2016 at 15:51, João Eiras <joao.eiras at gmail.com> wrote:

> Hi!
>
> I'm building some tests for an application, and I found something
> which is not entirely intelligible for me.
>
> Consider the following VCF variant, and its effect on transcript
> ENSMUST00000086738
>
> #CHROM POS REF ALT
> chr1 99772783 C CCCCAAA
>
> It is annotated with consequence_terms "protein_altering_variant".
>
> However, if I shift the variant left or right, or remove one of the
> AAs, I get as expected an "inframe_insertion".
>
> #CHROM POS REF ALT
> chr1 99772782 A ACCCAAA
> chr1 99772783 C CCCC
> chr1 99772784 T TCCCAAA
>
> Being that, I don't see any other differences in the annotation.
> Why this difference ?
>
> Thank you.
>
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:
> http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20161114/c8e814fe/attachment.html>