# How to read structural variant VCF?

The IGSR has a sample for encoding structural variants in the VCF 4.0 format.

An example from the site (the first record):

#CHROM  POS   ID  REF ALT   QUAL  FILTER  INFO  FORMAT  NA00001
1 2827693   . CCGTGGATGCGGGGACCCGCATCCCCTCTCCCTTCACAGCTGAGTGACCCACATCCCCTCTCCCCTCGCA  C . PASS  SVTYPE=DEL;END=2827680;BKPTID=Pindel_LCS_D1099159;HOMLEN=1;HOMSEQ=C;SVLEN=-66 GT:GQ 1/1:13.9


How to read it? From what I can see:

• This is a deletion (SVTYPE=DEL)
• The end position of the variant comes before the starting position (reverse strand?)
• The reference starts from 2827693 to 2827680 (13 bases on the reverse strand)
• The difference between reference and alternative is 66 bases (SVLEN=-66)

This doesn't sound right to me. For instance, I don't see where exactly the deletion starts. The SVLEN field says 66 bases deleted, but where? 2827693 to 2827680 only has 13 bases between.

Q: How to read the deletion correctly from this structural VCF record? Where is the missing 66-13=53 bases?

• I'm pretty sure the END value is simply wrong in that example. Maybe send the info@ email address a note regarding this so they can fix it. May 29 '17 at 6:49
• This line is wrong in several aspects. VCF4.0 is something like 5 years old and has long been deprecated. Its spec has also been moved to github. You should read the latest spec instead. The SV example there is correct. May 29 '17 at 13:40
• This was fixed in the maintained VCF specifications in 2015 upon being reported as <github.com/samtools/hts-specs/issues/84>. May 7 '19 at 11:43

I just received a reply from 1000Genomes regarding this. I'll post it in its entirety below:

Looking at the example you mention, I find it difficult to come up with an interpretation of the information whereby the stated end seems to be correct, so believe that this may indeed be an error.

Since the v4.0 was created, however, new versions of VCF have been introduced, improving and correcting the specification. The current version is v4.3 (http://samtools.github.io/hts-specs/). I believe the first record shown on page 11 provides an accurate example of this type of deletion.

I will update the web page to include this information.

So we can take this as official confirmation that we were all correct in suspecting the example was just wrong.

• that was an amazing follow up! :) Jun 6 '17 at 14:15

So, first off, as others have pointed out, I'm pretty sure that example is just wrong. At least, the numbers don't match as you've pointed out.

That said, it is impossible to be sure without showing us the header of the VCF file as well. The INFO field (the 5th field of a VCF file) is very, very variable and depends entirely on the header lines. Each program (or human) implementing a VCF is free to choose to have whatever they feel like in the INFO field. However, each IDENTIFIER= needs to have an associated INFO line at the beginning of the file.

So, the SVTYPE, SVLEN, HOMLEN etc will have commented (start with a #) lines at the beginning of the file explaining what these values are. So check those, even though they're relatively standard, you never know, the obvious reading you used might be wrong despite its seeming so reasonable.

Here's a newer example of a VCF line for an SV taken from the current VCF specification:

##fileformat=VCFv4.1
##fileDate=20100501
##reference=1000GenomesPilot-NCBI36
##assembly=ftp://ftp-trace.ncbi.nih.gov/1000genomes/ftp/release/sv/breakpoint_assemblies.fasta
##INFO=<ID=BKPTID,Number=.,Type=String,Description="ID of the assembled alternate allele in the assembly file">
##INFO=<ID=CIEND,Number=2,Type=Integer,Description="Confidence interval around END for imprecise variants">
##INFO=<ID=CIPOS,Number=2,Type=Integer,Description="Confidence interval around POS for imprecise variants">
##INFO=<ID=END,Number=1,Type=Integer,Description="End position of the variant described in this record">
##INFO=<ID=HOMLEN,Number=.,Type=Integer,Description="Length of base pair identical micro-homology at event breakpoints">
##INFO=<ID=HOMSEQ,Number=.,Type=String,Description="Sequence of base pair identical micro-homology at event breakpoints">
##INFO=<ID=SVLEN,Number=.,Type=Integer,Description="Difference in length between REF and ALT alleles">
##INFO=<ID=SVTYPE,Number=1,Type=String,Description="Type of structural variant">
##ALT=<ID=DEL,Description="Deletion">
##ALT=<ID=DEL:ME:ALU,Description="Deletion of ALU element">
##ALT=<ID=DEL:ME:L1,Description="Deletion of L1 element">
##ALT=<ID=DUP,Description="Duplication">
##ALT=<ID=DUP:TANDEM,Description="Tandem Duplication">
##ALT=<ID=INS,Description="Insertion of novel sequence">
##ALT=<ID=INS:ME:ALU,Description="Insertion of ALU element">
##ALT=<ID=INS:ME:L1,Description="Insertion of L1 element">
##ALT=<ID=INV,Description="Inversion">
##ALT=<ID=CNV,Description="Copy number variable region">
##FORMAT=<ID=GT,Number=1,Type=String,Description="Genotype">
##FORMAT=<ID=GQ,Number=1,Type=Float,Description="Genotype quality">
##FORMAT=<ID=CN,Number=1,Type=Integer,Description="Copy number genotype for imprecise events">
##FORMAT=<ID=CNQ,Number=1,Type=Float,Description="Copy number genotype quality for imprecise events">
#CHROM POS     ID        REF             ALT QUAL FILTER INFO                                               FORMAT NA00001
1      2827694 rs2376870 CGTGGATGCGGGGAC C   .    PASS   SVTYPE=DEL;END=2827708;HOMLEN=1;HOMSEQ=G;SVLEN=-14 GT:GQ  1/1:13.9


Note how the numbers do match and also note how each of the subfields in the INFO field is explained with an ##INFO line.