Structural Variant normalization and Representation

[davmlaw]

Split out of #54 Structural Variant - copy number variation

It seems to be possible to write the same underlying genetic mutation in different ways using VCF files:

Say you have the same contig/position/ref base but the ALT is different:

alt=<del>FORMAT={GT: 0/1} # 1 copy of deletion
alt=<CNV> FORMAT={FC: 0.5} # 0.5 fold change is 1 copy deleted

The downside of is that there is no representation in HGVS. Maybe it's possible via ISCN?

I dont' think you can represent it as SPDI unless you just use pure numbers for the last 2

Would it be a good idea to convert the <CNV> to a <del> if FC < 1 and a <DUP> if FC > 1?

The do NOT annotate the same, ie the DEL is impact=HIGH wile the CNV is impact=MODIFIER

chr13   32890596        .       A       <CNV>   1       PASS    CN=2;EVENT=CNV_47;SVTYPE=BND;VARTYPE=copy_number_variation;END=32972909;ANT=BRCA2       FC      0.5
chr13   32890596        .       A       <DEL>   1       PASS    CN=2;EVENT=CNV_47;SVTYPE=DEL;VARTYPE=copy_number_variation;END=32972909;ANT=BRCA2       FC      0.5

Advantages of leaving it are:

• Multi-sample entries from the same VCF will be against the same variant - ie you can see that some patients had loss, some had gain at the same site.

Advantages of normalizing it are:

• CNVs from different VCFs (represented in diff ways) are linked together in the database
• If you convert from <CNV> to <DEL/DUP> then you can represent as HGVS

I guess it comes down to whether you think a deletion or dup at the same site are the same - I would say not?

TODO: We should check how <CNV> vs <DEL> vs <DUP> are handled as VEP annotation - does it matter?

Does it make sense to call it a DUP if there are say 4 copies now? Is that just homozygous for a DUP?

gnomAD structural variants include CNV (as well as INS/DUP etc)

1	46000	nssv15780791	T	<CNV>	.	.	DBVARID=nssv15780791;SVTYPE=CNV;END=111250;EXPERIMENT=1;SAMPLESET=1;REGIONID=nsv4514092;AC=977;AFR_AC=161;AMR_AC=84;EAS_AC=5;EUR_AC=716;OTH_AC=11;AF=0.09479;AFR_AF=0.035439;AMR_AF=0.114286;EAS_AF=0.004139;EUR_AF=0.192163;OTH_AF=0.115789;AN=10307;AFR_AN=4543;AMR_AN=735;EAS_AN=1208;EUR_AN=3726;OTH_AN=95

[davmlaw]

VT (abandoned?) and bcftools don't normalize symbolic variants - raised issue samtools/bcftools#1919

I think this means we may need to convert symbolic variants to explicit ref/alt then normalize them and then convert back.

An issue would be how to make sure we re-load a dup as a dup rather than an ins (keep track of old allele in INFO?)

[davmlaw]

END

Should end be max(len(ref), len(alt))) or abs(len(ref) - len(alt))? If you are looking at overlaps - the max seems better?
Make sure our calc from ref/alt is same as END=XXX or length=XXX

HISTORICAL

If > 1kb then describe as a CNV - should we go through historical data and convert variants to CNVs?

Can find long ones via Sequence.objects.order_by("-length").first().variant_set.all().get().pk

NORMALIZATION

We should convert CNV to DUP
Need to also convert indels to raw strings (but what max size??) so they are properly normalized by VT or bcftools (eg NC_000003.11:g.128204049_128206714del)

—-------

NC_000003.11:g.128204049_128206714del

As it is > 1kb - it should be represented in the DB as
But when we create it, we need to normalize - which means writing it out as a normal variant, and then running it through VT etc

We need to do this when creating a variant -

if length >= settings.VARIANT_STRUCTURAL_SIZE:
ref = ref[0]
if hgvs_name.mutation_type in ('del', 'dup', 'ins'):
alt = f"<{hgvs_name.mutation_type.upper()}>"
else:
raise ValueError(f"Don't know how to handle symbolic variant of type {hgvs_name.mutation_type}")

We’ll then run this VCF through VT (do anyway?) so it will get normalized

Normalize CNVs

May have to explicitly write out the ref/alt - run through VT
Then load in, convert to CNV inside the VCF loader?

When we are calling write_vcf_from_tuples - I think we actually want to write the proper ref-alt as

write_vcf_from_tuples

—---------------

Search for “chrom, position, ref”

get_results_from_variant_tuples

NC_000003.11:g.128204049_128206714del - can’t create as error needs end

Variant = 3:128204042 > T

In [11]: name.get_vcf_coords()
Out[11]: ('NC_000003.11', 128204048, 128206714)

Example large CNV normalization

NC_000003.11:g.128204049_128206714del' resolved to 3:128204042 TCT...GCC>T

ClinGen allele registry agrees also normalizes to same start

"hgvs":["NC_000003.11:g.128204049_128206714del","CM000665.1:g.128204049_128206714del"],
"chromosome":"3",
"coordinates":[{"end":128206708,
"start":128204042,

SPDI

NC_000003.12:128481050:GG:TT
NC_000003.12:128481050:1:TT

NC_000003.11:128204048:2666: see REST API call

{
  "data": {
    "hgvs": "NC_000003.11:g.128204049_128206714del"
  }
}

However HGVS call doesn't appear to normalize: it has inserted sequence "CTCCCG" but same prefix on deleted sequence

[GracePendlebury]

Found some things that sounded useful:
https://docs.cbioportal.org/user-guide/faq/#dna-mutations-copy-number--fusions
https://docs.cbioportal.org/user-guide/oql/

[EmmaTudini]

@davmlaw Just found this slide deck- https://drive.google.com/file/d/1w4uIdBJX6duSDni8XlOc84tF4h1CbMa_/view
Seems as though clingen allele registry is now accepting CNVs? Might be something to look into

[davmlaw]

We use CAR for unique IDs, unfortunately they say:

Unlike smaller variants supported by the core Registry functionality, CNVs are not canonicalized

We'd also have to use their own invented format as well, strangely it supports this:

GRCh37 (chr7:132348499-132359000)x1

But not this:

NC_000007.13:g.132348499_132359000del

Gives: VariationTooLong

[davmlaw]

Converting CNV to DUP (which we need to do for TSO500) is handled in issue https://github.com/SACGF/variantgrid_sapath/issues/304

The other variant normalization etc is now handled in #1014