How to deal with swapped alleles

[mirgin01]

Hi,

We are implementing bcftools liftover in an allele frequency browser, with the goal of translating variants between genome assemblies on the fly.

After testing several liftover tools, we decided to use bcftools because it appears to provide the most accurate results and includes very useful information in the output.

One aspect that is particularly important for our project is the detection of REF/ALT swaps. In the local tool, the VCF output indicates when the reference allele has changed, which is essential for us. However, in the web version (https://github.com/broadinstitute/liftover), only the positions appear to be lifted, and the query does not seem to take or return the nucleotide information. As a result, allele swaps would not be detected.

Could you clarify what strategy the local tool uses to identify swapped alleles? Also, is there any way for the web version to accept and return REF/ALT allele information, rather than only genomic coordinates?

Thank you very much.

[freeseek]

The way I understand it, the web version simply runs BCFtools/liftover in the background (see here) and then extracts information from the VCF output. You can often hint that a swap happened:

input: chr22:16876216 A>G
output: chr22:16395490 G>A

But with A/T and C/G SNPs it would not be clear if a swap or a flip took place. Do you need to use the web version rather than just running BCFtools/liftover?

[mirgin01]

Thanks again for your quick response.
I work at the European Genome-Phenome Archive (EGA), within the Beacon project. We are developing an API to query allele frequencies across datasets stored at EGA (https://af-beacon.ega-archive.org/), and one of our goals is to support liftover during the search itself.
For example, if a user searches for 21-19653341-AT-A in GRCh37, the AF Beacon should return hits not only from GRCh37 datasets, but also from GRCh38 datasets by querying the lifted variant.
To achieve this, we wanted to avoid storing the same datasets twice, once per assembly. That is why we were interested in understanding the strategy used by your API.
Following your suggestion, I considered creating a temporary VCF containing only the queried variant, running the tool, and then reading chr-pos-ref-alt from the output VCF. The downside is that this would require making both reference FASTAs and both chain files available on the web service side, and we are still evaluating whether that is feasible.
Do you think this is the best approach, or would you recommend a more efficient way to implement this use case?
Again, thank you very much for your support. I really appreciate it.
Best,
Mireia

[freeseek]

I think that is a sensible strategy. You can use BCFtools/query to extract the information from the output VCF. The chain files do not take too much space. If you want to save space storing the FASTA files, you could compile BCFtools with support for streaming VCF files and then the background command could only stream the part of the FASTA files required. However, this might slow down how quickly the result is generated. How many FASTA files would this tool need to be able to access?

[mirgin01]

Finally, we decided to build our own API using the score software. This way, nucleotides are always checked against the reference sequences and REF/ALT swaps are consistently detected, while avoiding the need to load reference and chain files.
Of course, we will cite your tool on our website as soon as the implementation is online.
Thank you very much for all the help.
Best regards,
Mireia