[ensembl-dev] [VEP] Allele representation leading to strange annotation

[Will McLaren]

Hi Konrad,

Thanks for finding this.

We'll look into a solution, though as it will involve significant code
refactoring, it won't be available until (at the earliest) the next
VEP/Ensembl release (80, due some time next month).

In the short term you could break out the variant onto separate VCF lines,
though I appreciate that introduces difficulties with individual-level data.

Regards

Will

On 16 April 2015 at 05:30, Konrad Karczewski <konradk at broadinstitute.org>
wrote:

> Hi Will, VEP folk,
>
> Unfortunately, allele representation has bit us once again. We have the
> following variant:
>
> 1       3394415 .       CGCCTCCCGGCTCTGTCCCCCCAGTCCCTCCCACTGATCTCT
>  TGCCTCCCGGCTCTGTCCCCCCAGTCCCTCCCACTGATCTCT,C    9533.30 PASS
>
> Which is really a SNV that overlaps a larger deletion. VEP reads this
> as CGCCTCCCGGCTCTGTCCCCCCAGTCCCTCCCACTGATCTCT-> TGCCTCCCGGCTCTGTCCCCCCAGTCCCTCCCACTGATCTCT
> and since that sequence overlaps a splice acceptor (e.g. ENST00000378373),
> it marks it as a splice_acceptor_variant (even though it doesn't change the
> acceptor site - just tried VEP v79 on GRCh37 and same issue). Ideally, we'd
> put this through minimal representation (as we have implemented here:
> https://github.com/ericminikel/minimal_representation which nicely cuts
> the alleles down), but unfortunately inside a multi-sample VCF, this
> doesn't really work. Is there a way for this to happen inside VEP/is there
> a fix to this?
>
> Thanks!
> -Konrad
>
> _______________________________________________
> 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/20150416/75b4792a/attachment.html>