Deletion not reported in scout due to erroneous calls manta calls in reference db?

[alieden]

We recently had a relatively rare ~1,4 Mb deletion (coordinates approx chr13:23,510,002-24,920,001 in vcf2cytosure) that wasn't reported in scout (F0064472). From what I've understood from discussing this issue with Daniel the explanation might be that the deletion is found by Manta at a high frequency in the reference db? Pasting the info I got from Daniel below.

Since this has could have implications on the calling of other CNVs I'm reporting this as an issue. If there are large CNVs (del/dup) in the reference db that are only supported by Manta I would suggest that these should be removed. Let me know if further info is required or if I can help out in anyway.

---

"13 23487961 SV_99_1 N 50 PASS Annotation=LINC00621,NUS1P2;CSQ=deletion|transcript_ablation|HIGH|SACS|26278|Transcript|NM_014363.6|protein_coding||||||||||||-1||EntrezGene|10519|YES||||NP_055178.3||||||RefSeq|||||||,deletion|transcript_ablation|HIGH|SGCG|ENSG00000102683|Transcript|ENST00000218867|protein_coding||||||||||||1||HGNC|10809|YES|||CCDS9299.1|ENSP00000218867|SGCG_HUMAN||UPI000013C76D|||Ensembl|||||||,deletion|transcript_ablation|HIGH|MIPEP|4285|Transcript|NM_005932.4|protein_coding||||||||||||-1||EntrezGene|7104|YES||||NP_005923.3||||||RefSeq|||||||;CTG=TCTTGATCTATGTCTTTTCATTCTCTTAACAGTGTATTTTGAAGAGTGGAAGTTTTTAATTTTGATGAAATGCATATTATCAATTTGTTCTCTTATGAATTATGCTTTTTATGTTGTATCCAAGGTCACAAAGATCTGACCAATCCAAATGTTCATCTGGGCTCACTGCAATCTCCGCCTCCCAGGTTCACGACATTCTCCTGCCTCAGCCTCCCGAGTAGCTGAGACTACAGGCTCCCGCCACCACGCCCGGCTATTTTTTTTTTTTCTGTATTTTTAGTAGA;Compounds=wholecrayfish:13_23487960_A_DUPTANDEM>-3.0;CompoundsNormalized=wholecrayfish:13_23487960_A_DUPTANDEM>0.5081967213114754;END=24902222;FOUNDBY=1;GeneticModels=wholecrayfish:AD|AR_comp;LFA=18,8;LFB=18,7;LTE=17,7;REGIONA=23487961,23488258;REGIONB=24902013,24902222;RankResult=-12|0|10|0|3|0|3|0;RankScore=wholecrayfish:-2.0;RankScoreMinMax=wholecrayfish:-17.0:44.0;RankScoreNormalized=wholecrayfish:0.2459016393442623;SUPP_VEC=001;SVLEN=1414261;SVTYPE=DEL;clinical_genomics_loqusFrq=8e-05;clinical_genomics_loqusObs=1;clinical_genomics_mipAF=0.1019;clinical_genomics_mipOCC=226;clinvar_non_pathogenicFrq=1;clinvar_non_pathogenicOcc=1;decipherAF=0.00118343;decipherOCC=1;most_severe_consequence=10519:deletion|transcript_ablation,10809:deletion|transcript_ablation,7104:deletion|transcript_ablation;set=tiddit;svdb_origin=tiddit;swegenAF=0.23393;swegenOCC=222;tiddit_CHROM=SV_99_1|13;tiddit_FILTERS=SV_99_1|PASS;tiddit_INFO=SV_99_1|SVTYPE:DEL|SVLEN:1414261|END:24902222|REGIONA:23487961:23488258|REGIONB:24902013:24902222|LFA:18:8|LFB:18:7|LTE:17:7|CTG:TCTTGATCTATGTCTTTTCATTCTCTTAACAGTGTATTTTGAAGAGTGGAAGTTTTTAATTTTGATGAAATGCATATTATCAATTTGTTCTCTTATGAATTATGCTTTTTATGTTGTATCCAAGGTCACAAAGATCTGACCAATCCAAATGTTCATCTGGGCTCACTGCAATCTCCGCCTCCCAGGTTCACGACATTCTCCTGCCTCAGCCTCCCGAGTAGCTGAGACTACAGGCTCCCGCCACCACGCCCGGCTATTTTTTTTTTTTCTGTATTTTTAGTAGA|SUPP_VEC:1;tiddit_POS=SV_99_1|23487961;tiddit_QUAL=SV_99_1|50;tiddit_SAMPLE=SV_99_1;wholecrayfish_tiddit_ACC15802A7_CHROM=SV_99_1|13;wholecrayfish_tiddit_ACC15802A7_FILTERS=SV_99_1|PASS;wholecrayfish_tiddit_ACC15802A7_INFO=SV_99_1|SVTYPE:DEL|SVLEN:1414261|END:24902222|REGIONA:23487961:23488258|REGIONB:24902013:24902222|LFA:18:8|LFB:18:7|LTE:17:7|CTG:TCTTGATCTATGTCTTTTCATTCTCTTAACAGTGTATTTTGAAGAGTGGAAGTTTTTAATTTTGATGAAATGCATATTATCAATTTGTTCTCTTATGAATTATGCTTTTTATGTTGTATCCAAGGTCACAAAGATCTGACCAATCCAAATGTTCATCTGGGCTCACTGCAATCTCCGCCTCCCAGGTTCACGACATTCTCCTGCCTCAGCCTCCCGAGTAGCTGAGACTACAGGCTCCCGCCACCACGCCCGGCTATTTTTTTTTTTTCTGTATTTTTAGTAGA;wholecrayfish_tiddit_ACC15802A7_POS=SV_99_1|23487961;wholecrayfish_tiddit_ACC15802A7_QUAL=SV_99_1|50;wholecrayfish_tiddit_ACC15802A7_SAMPLE=SV_99_1|ACC15802A7|GT:0/1|CN:1|COV:34:17.837919817079904:36|DV:17|RV:7|LQ:0.0:0.0|RR:9:6|DR:15:12 GT:CN:COV:DV:RV:LQ:RR:DR 0/1:1:34,17.8379,36:17:7:0,0:9,6:15,12"
13:23'487'961 - 24'902'222

[jemten]

Hello and thanks for reporting!
The variant is called by Tiddit, Manta and CNVnator but get's a very low rank score due to being quite common in our older svdb database export (AF=0.1) as well as in the swegen databases (AF=0.23393), and thus it's not uploaded to scout. In loqusdb we only have one previous observation.

Clinvar has an overlapping deletion in it's list of non-pathogenic structural variants but there is also an overlapping pathogenic sv from clinvar. The variant only gets annotated with the non pathogenic flag, however that annotation is not used in the rankmodel.

non-poathogenic

chr13   23515552    24927971    nssv15125299    1000    .   23515552    24927971    227,142,144 Likely benign   copy number loss

pathogenic:

chr13   23519915    24941516    nssv15153071    1000    .   23519915    24941516    180,3,16    Pathogenic  copy number loss

We have discussed removing some of the older in house AF databases and maybe for structural variants we should remove swegen as well, at least from the rankmodel.

[alieden]

Hi Anders, Seems like a good idea to me but I don't have all the info. I would at least check any reference set for common large CNVs (del/dups) that are not supported by CNVNator since they are likely to be false positive which in turn then could result in a false negative result. Let me know if I can help in anyway. Kr, Agne Från: Anders Jemt ***@***.***> Skickat: den 7 januari 2025 12:29 Till: Clinical-Genomics/MIP ***@***.***> Kopia: Agne Liedén ***@***.***>; Author ***@***.***> Ämne: Re: [Clinical-Genomics/MIP] Deletion not reported in scout due to erroneous calls manta calls in reference db? (Issue #2073) Hello and thanks for reporting! The variant is called by Tiddit, Manta and CNVnator but get's a very low rank score due to being quite common in our older svdb database export (AF=0.1) as well as in the swegen databases (AF=0.23393), and thus it's not uploaded to scout. In loqusdb we only have one previous observation. Clinvar has an overlapping deletion in it's list of non-pathogenic structural variants but there is also an overlapping pathogenic sv from clinvar. The variant only gets annotated with the non pathogenic flag, however that annotation is not used in the rankmodel. non-poathogenic chr13 23515552 24927971 nssv15125299 1000 . 23515552 24927971 227,142,144 Likely benign copy number loss pathogenic: chr13 23519915 24941516 nssv15153071 1000 . 23519915 24941516 180,3,16 Pathogenic copy number loss We have discussed removing some of the older in house AF databases and maybe for structural variants we should remove swegen as well, at least from the rankmodel. - Reply to this email directly, view it on GitHub<#2073 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFNPY7EPHPF773FFYHSQPH32JO3BJAVCNFSM6AAAAABURMSPMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZVGA2TGNRTGQ>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>> När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter<https://ki.se/om-ki/integritetsskyddspolicy>. Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI's processing of personal data here<https://staff.ki.se/data-protection-policy>.

[dnil]

Right, those large manta weirdly labeled calls (or even TIDDIT once in a while 😉) are difficult, especially with recurring positions. One needs to keep in mind that the databases we have are for the purpose of filtering. The idea is to mark or filter the calls from the final variant file, not to have as accurate a db as possible.

Before removing one then has to consider the flow of db generation. A likely explanation for this variant not being common in loqus is that it gets hard filtered due to very high counts in the static svdb sets before upload. So we will need a quick new dump at least after dropping the old ones to make sure we don't get loads of noise out.

Another old idea is to do caller specific annotation and high frequency filtering before moving on to the next step, in order to remove artefacts before merging and scoring.

I also still don't feel I fully understand what happened here, even if we may have some older version calls in those dbs. The variant typing is clearly weird, especially from the manta call which appears to determined as a MantaDUP DUP:TANDEM (263 obs), but the TIDDIT call as DEL also has a hefty 222 obs. I don't quite see any CNVnator call merged with either?

[jemten]

Yeah, you're right @dnil. The reason that we don't have it in loqus is because we only upload filtered calls. If the old export is removed we would start to populate loqus with those calls

[jemten]

We have this call in the unfiltered file which I thought was more or less the same call. Doesn't get merged with the tiddit call though.
13 23508001 CNVnator_del_4:cnvnator|MantaDEL:94201:0:1:0:0:0:manta T <DEL> . PASS END=24930000;SVTYPE=DEL;SVLEN=-1422000;