I work for a company doing genetic analyses, and we also support annotating client-provided VCF files. We sometimes get input files that contain lines like:
chr5 1271126 . T . 51.85 PASS AC=1;AF=0.5;AN=2;DP=106;FS=1.676;MQ=250;MQRankSum=8.261;QD=0.49;ReadPosRankSum=4.391;SOR=0.525;FractionInformativeReads=0.99;NOTES=pathogenic-frameshift_deletion_promoter-CGC-TERT-Pathogenic_promoter GT:AD:AF:DP:F1R2:F2R1:GQ:PL:GP:PRI:SB:MB:PS 0|1:35,67:0.6569:102:17,31:18,36:46:87,0,45:51.848,9.8095e-05,47.944:0,34.77,37.78:15,20,32,35:25,10,34,33:19179872
Or, removing the extra info for clarity:
chr5 1271126 . T . 51.85 PASS . GT 0|1
Is this a deletion or is it an invariant site, a place where we have no variant? The VCF specs are a bit confusing. Version 4.2, section "1.6.1 Fixed fields" states:
In all cases, missing values are specified with a dot (‘.’). [...]
[...]
- ALT — alternate base(s): Comma-separated list of alternate non-reference alleles. [...] Options are base Strings made up of the bases A,C,G,T,N,* [...] If there are no alternative alleles, then the missing value should be used.
This _could_ be interpreted as suggesting that in the case of deletion, if one considers a deletion as a simple removal of residues, the standard allows using . in the ALT field as because we are only removing, there is no alternative allele. This is isn't correct, since we always have an alternative allele, but I can see how it could be understood that way. In the example above, if we had a C before the T that was deleted, then we should express that as
chr5 1271125 . CT C 51.85 PASS
So, n-1 position, plus the previous residue, then only the previous shown in the ALT. The new version of the VCF standard is clearer:
- ALT — alternate base(s): Comma-separated list of alternate non-reference alleles. [...] Options are base Strings made up of the bases A,C,G,T,N (case insensitive) or the ‘*’ symbol (allele missing due to overlapping deletion) or a MISSING value ‘.’ (no variant) [...]
Here, it clearly states that the MISSING value should be used to indicate "no variant", not just "no alternate allele" so I imagine the maintainers made this change to remove precisely the possible confusion I mentioned above.
Also, in both versions, the section about deletions does show them with <previous_residue><deleted_residue> as the REF and <previous_residue> as the ALT (e.g. CT C). But is this a requirement or is the T . format also understood?
So, is this an _update_ to the standard or was it always supposed to be this way? Should I allow vcf files that are version <=4.2 to have . in the ALT field to indicate deletions? Or can I safely remove these lines from my users' input files because these are describing positions that did not change, i.e., not a variant? Are there known tools out there that produce VCF files using T . for deletions instead of CT C?
Cross-posted to Bioinformatics.se: https://bioinformatics.stackexchange.com/q/23622/298
An answer on the version of this question I had cross-posted to Bioinformatics Stack Exchange pointed out something I had missed in the VCF specs, which define the REF field as:
For simple insertions and deletions in which either the REF or one of the ALT alleles would otherwise be null/empty, the REF and ALT Strings must include the base before the variant (which must be reflected in the POS field), unless the variant occurs at position 1 on the contig in which case it must include the base after the variant...
As that states that the REf field "must" include the base before the variant, that is already enough to make the VCF line I have in my question non-compliant with the standard.
So no, a . cannot be used as the ALT field for a deletion in a CNV file and, if any software produces files that do this, then those files can be considered non-compliant VCFs.
Yes, unfortunately, invalid VCF files are very common - the format itself feels overly complicated and difficult to proofread, no wonder invalid VCF files abound. Thanks for following up with an answer.
Log in to answer this question.
what variant caller was doing this?
I don't know, unfortunately. I've asked my user but haven't heard back yet. For all I know, this was the result of editing the file manually or a local user's pipeline.