Gene Fusions

[davmlaw]

Some labs report on somatic gene fusions. We are currently ignoring these.

The problem is, classifications are very "variant centric" - or "allele centric" at least. VariantGrid is about variants... It would be a large amount of work to pull the variants out of classifications. It is probably least disruptive to keep it VCF/variant-like, so we can run through the VCF import pipelines, export as VCF etc

A fusion is inherently a two-locus event, while we make a lot of assumptions about single-locus. It may be possible to represent a gene fusion as a breakend (BND) notation specifically for structural variants, including fusions. A fusion is modelled as a pair of breakends one on each partner gene:

# Chromosome 9, BCR breakend
9   133729451   bnd_1   N   N]22:23632600]   .   PASS   SVTYPE=BND;MATEID=bnd_2

# Chromosome 22, ABL1 breakend
22  23632600    bnd_2   N   ]9:133729451]N   .   PASS   SVTYPE=BND;MATEID=bnd_1

The bracket notation encodes the orientation/strand of each side of the join. So a fusion is essentially two linked variant records.

At the moment we don't have breakends, and it has to be 1 variant / allele per classification (this would need to link 2)

The other alternative is a bit of a hack where we just insert against 1 end and keep track of the fusion etc via INFO fields or whatever. In some ways, if we can resolve 2 fusions to the same "variant" that's all that matters for discordance. Any range/overlap code would need to take this into account and ignore these.

The gene fusions listed are like GENEA-GENEB - do they even have base-level coordinates? If some are base level and some aren't - how do we check if they are discodant? Need to even define what "are 2 gene fusions the same" means

[davmlaw]

🤖 Written by Claude.

Analysis: Gene Fusions Design

After examining the Variant, Allele, and Classification code, here are my thoughts on the best approach.

Why the BND Route Is More Disruptive Than It Appears

The issue suggests BND notation might be "least disruptive" by keeping a VCF-like model. In practice, BND causes serious structural problems:

• One classification per allele is a core invariant. A BND fusion requires two VCF records (two variants, two alleles). Creating two classifications per fusion is wrong semantically. Creating one classification linked to two alleles would require changing Classification.allele_info, ClinicalContext.allele, DiscordanceReport, and the discordance detection chain.
• Identity is still gene-based. Even with coordinates, "are these the same fusion?" is not a coordinate equality check. Caller A might put BCR-ABL1 breakpoint at chr9:133,729,451 and caller B at 133,729,453 due to soft-clipping. Labs define fusion identity by gene pair, not precise coordinate.
• Gene-level fusions can't be BND. If a lab submits "BCR-ABL1" with no coordinates, there is nothing to put in VCF. We need to handle this case regardless.
• No ClinGen support. The ClinGen Allele Registry does not handle fusions. We'd be creating bare Alleles with no external ID anyway.

Recommended Design

Create a GeneFusion model with a canonical gene pair (5′ partner + 3′ partner) plus a one-to-one bare Allele:

class GeneFusion(models.Model):
    gene_symbol_5prime = models.ForeignKey(GeneSymbol, on_delete=CASCADE, related_name='+')
    gene_symbol_3prime = models.ForeignKey(GeneSymbol, on_delete=CASCADE, related_name='+')
    allele = models.OneToOneField(Allele, on_delete=CASCADE)
    # allele has no ClinGenAllele, no VariantAllele — exists purely as the grouping key

    class Meta:
        unique_together = ('gene_symbol_5prime', 'gene_symbol_3prime')

The bare Allele has no ClinGenAllele and no VariantAllele entries — it exists purely as a grouping key. This means the entire existing discordance infrastructure (ClinicalContext.allele, DiscordanceReport, discordance status calculation) works without any changes.

Extend ImportedAlleleInfo with a gene_fusion FK and a short-circuit path that bypasses HGVS resolution entirely. When gene_fusion is set: skip the Celery resolution task, set allele = gene_fusion.allele immediately, set status = MATCHED_ALL_BUILDS.

What Does NOT Need to Change

• ClinicalContext model — no changes
• DiscordanceReport model — no changes
• VCF import/export pipeline — fusions bypass it entirely (no VariantAllele rows)
• Annotation pipeline — skip fusion alleles (no Variant to annotate)
• ClinGen API calls — skip for fusion alleles
• HGVS resolution — skipped for fusions

Range/overlap queries just add .filter(genefusion__isnull=True) to exclude fusion alleles naturally.

Identity: "Are Two Fusions the Same?"

The canonical gene pair is the identity. Two fusions are the same if they resolve to the same GeneFusion row.

• Accept multiple notations: "BCR-ABL1", "BCR::ABL1", "BCR/ABL1"
• Resolve gene names via the GeneSymbol model (handles aliases and capitalisation)
• If orientation is known, record as (5prime, 3prime)
• If orientation unknown, sort alphabetically — same as how different HGVS notations resolve to the same Allele

Somatic fusions already hit MULTIPLE_RECORDS_DISCORDANCE_NOT_SUPPORTED automatically, so no discordance work is needed in Phase 1.

Discordance

Currently somatic classifications use MULTIPLE_RECORDS_DISCORDANCE_NOT_SUPPORTED. Fusions are somatic, so they get this status automatically. When somatic discordance is eventually implemented, fusions benefit automatically because they share the same ClinicalContext/discordance infrastructure. No changes needed in Phase 1.

Phased Implementation

Phase 1 (MVP): GeneFusion model + bare Allele on demand, ImportedAlleleInfo.gene_fusion FK + short-circuit resolution, fusion identifier parsing (common notation forms), range query exclusions, basic UI grouping by fusion name.

Phase 2 (optional): GeneFusionBreakend model storing breakpoint coordinates per genome build for labs that provide them — doesn't affect identity or discordance matching.

Phase 3 (optional): VCF round-trip export as BND pairs for fusions with known breakpoints.

[EmmaTudini]

Discussed 02/04/26 - would be good for molecular oncology so that they can store all classifications. Shariant user group has stated need. But very difficult to implement, needs more thinking (and likely more resourcing). Uncertainty with what should be classed as an overlap, and it is context dependent. Likely a research level project.