Hey oncoanalyser team! 👋 Thanks for such a wonderful tool! 🌟 I'm a bioinformatician part of Clinical Genomics Stockholm, and I've been looking into the SVs in the Purple VCF. We're aware that the SVs have a bit of an unconventional format required for Linx downstream, but to make it work for our downstream tools we've made some scripts to adapt the format, and it seems to be working quite well. The only thing left to handle is that the variants are represented as 2 different records for the same variant (which we're only used to seeing for BNDs), and we're thinking to add another script to merge the second record into the first, basically removing it and adding information to the INFO field of the first. But before proceeding with this, do you see any obvious issues with doing this what we should consider? 🤔

Hey Mathias, are you trying to make those changes in the PURPLE before LINX and the subsequent tasks run ? or just extract PURPLE output for you to process outside oncoanalyser ? If the latter, you're free to do whatever you wish 🙂

Hi! Thanks for the response! 🌟 We're post-processing the purple output outside Oncoanalyser. I don't see any obvious issue myself with what we're doing but I'm checking just in case you're aware of any technical issues with merging the two records for the variants that I might have missed 🙏 From what I've seen the two records are joined by the SVID in the INFO field, and my plan was just to just make new INFO fields in the first variant record to add the fields from the INFO for the second variant record, along with the sample column as well from the second variant record. Then just remove the second record. (But leaving BND variants as they are)

Keen to hear how this goes 🙂

@Rayan Hassaïne do you know what’s the reasoning behind having the 2 records in the purple sv vcf file (on the Hartwig side)? Is there a plan to make this vcf more conventional?

While I am not affiliated with HMF, I think I can offer some context with that choice which is intentionally designed to address the unique complexities of cancer genomes. It's also based on the underlying philosophy of GRIDSS, which used to feed into the WIGTIS ecosystem. They explain the BND here: github.com/PapenfussLab/gridss#… While flattening breakends (BNDs) into single records (e.g., DEL, DUP, INV) may work for isolated, simple structural variants, it introduces risks for interpretation in complex somatic genomes. In highly rearranged cancer genomes (featuring chromothripsis, chromoplexy, complex templated insertions, etc.), traditional structural variant classifications (DEL, DUP, INV) do not function. BNDs strictly define the precise novel adjacency between two genomic loci without imposing an assumed, and often incorrect, simple structural mechanism. Also, classifying an event as a "DEL" or "DUP" based solely on breakend orientation is prone to interpretation errors. A "deletion-like" orientation in a breakend does not guarantee a loss of genetic material. True event classification requires integrating the breakend information with local copy number (CN) changes. Leaving the variants as BNDs preserves the adjacency data and delegates the higher-level biological interpretation to downstream tools (like LINX), which can synthesize both BND and CN data. While this format feels unconventional compared to others SV callers, it is actually strictly compliant with the VCF specification (v4.5, Section 5.4). The VCF spec specifically utilizes the BND notation to account for the exact type of arbitrary rearrangements seen in cancer that cannot be accurately represented by a single

<DEL>

or

<DUP>

line. We also made the same design choice when developing SAVANA for nanopore wgs data. Merging the second record into the INFO field of the first is certainly feasible for your internal pipelines, but be aware that doing so risks masking complex, multi-breakend rearrangements by forcing them into the framework of simple, independent events. Sorry for the long text.

Thanks for the great explanation! I was thinking along similar lines but didn't have it so concrete in my head, super helpful! 🌟 To add a little more info, we are also retrieving the final clinical interpretation that exist in the Linx output, and adding it as annotations to the SVs from Purple. But yeah, it's hard to describe all of these complex variants in a simple VCF row but I think we're forced to do our best for now 😄

@Mathias Johansson just want to shout out @valleinclan for the excellent explanation and say this is indeed the reasoning and why we remain committed to the BND approach. It would be interesting to hear what the eaxct use case is you're doing this reformatting for, in orange (and downstream oncoact) we're able to represent the events in a clinically relevant and (we think) clear way. would be interesting to hear what you are missing/trying to do so we can point people to it if we get similar requests from other users

Some additional context on why we are finding problems with SV vcf files: the downstream interpretation software that it’s used here requires SVs in vcf format, annotated with Ensembl VEP. This downstream tool is used for further technical inspection and clinical interpretration of SVs. We do find that the current sv vcf file created by purple does not get properly annotated by ensembl vep (issue 1). Then the second issue is that expectations on how to interpret these SV vcf files is quite different compared to how the current pipeline (not OA) works as they report aberrations in different ways

Thanks for clarifying Eva, we encourage you to report the first problem with VEP directly, as Jose points out the files are definitely VCF spec and as such VEP should handle them as they state to be compatible.

Hi! Thanks for the continued response 🙏 It's hard to rule out that there's not a setting in VEP that we could tweak to make it work. But I think the issue was that variants like DEL had the second breakend coordinate in the ALT column instead of the SVTYPE like DEL, and also then had the second issue of missing an END in the INFO field. We could make these variants become annotated via VEP by changing the SVTYPE from DEL to a BND, because then it was mimicking the structure of a BND with the "N[12:58877476[" type of format in the ALT column. But then we're not getting them annotated along the whole length of the DEL but only surrounding the BND. So basically for the first issue that's what we did: Cut the genomic position out of the alt column and created a new END field for the DUP / DEL / INS / INV, and added the SVTYPE in the ALT column instead. This made the first record annotate correctly with VEP. Then we still have the second record left, which is the remaining questionmark. I checked the VEP format specification here and it seems that they're expecting a certain format. But maybe you're right and this does not support the current VCF format, and should be updated. jun2026.archive.ensembl.org/info/…/vep_formats.html#…

worth flagging with VEP in that case, even if just for them to be specific about which specs they take or not

I could be wrong, maybe Eva can correct me. But we need a VCF to upload to our local variant interpretation platform which the clinicians are using, and we thought starting from the Purple VCF was a good way to get started. (We discussed today the possibility of making a VCF file out of the Linx tsvs, but haven't fully explored this yet) Then the reason we're using VEP to annotate with is I think because were at the moment mainly trying to replicate what we were doing with our old analysis, to make the transition a bit smoother, and not change too many things at once. Then work towards improving it. Also, I think Linx annotations are based on the DriverGenePanel list, and we don't know all the genes our users are interested in, whereas VEP will annotate everything, so we have it to fall back on. But I've gotten some things to think about 🤔