STR calls in Trio

[47KW]

Good day Sir/Madam this case shows some strange calls of STR ATXN8OS from the individuals in a trio. Example; 2019-22270-04 has 4 alleles/calls. https://scout.scilifelab.se/cust002/F0028964-2/str/variants?variant_type=clinical#

Found by Helena Malmgren and she would appriciate to be on the issue as well.

Enjoy Wednesday

[47KW]

We can see that there is two different repeats, but the 2019-22270-02 calls are not there at all.....cant be right?

[dnil]

I'm sorry, I dont quite understand the question. I can't confirm four calls for 2019-22270? I can see two calls for in the known pathogenic ATXN8OS plus two for the nearby for 2019-22270-04? Each call is a ./1 or 1/., so valid as each is a potential heterozygote.

I don't know who 2019-22270-02 is - did you mean 2019-05421-02? I agree I would like to have seen a call from that individual. It looks fairly wt on the IGV view, so may just be a no-call, but I can have a look in the ExHu output to make sure!

[47KW]

Yes, It would be helpful to see 2019-05421

Thats essentially what we need, Right Helena?

[dnil]

:+1: Looking into it!

[dnil]

The individual in question is indeed normal (20) for the gene in question. But you should have been able to see that. Something appears to go wrong on loading, possibly because there are multiple entries with size 20 after multi-allelic sites decomposition. Lets keep this issue open, and we'll keep you posted!

[dnil]

Yes, there is an issue here - but not exactly in Scout. When MIP (SVDB) merges individual ExHu runs into a family file, and subsequently MIP splits the multi allelic entries, things go wrong. I'll describe it in some more detail and transfer the issue to MIP. Thanks a whole bunch for noticing! Good job! :+1:

[dnil]

Ok, so we have an issue with multiallelic call splitting and family merging, possibly only in the STR path, but I would be happy if you could check the procedure for at least SVs as well.

In the case at hand, note how the 13_70713515_A_<STR20> is present on two lines with different GT calls. You could say its an issue with vt due to a problem in splitting the multi-allelics after merge - or due to a problem with SVDB not merging them into one mulitallelic line. Your call! :smile:

Having multiple lines for the same variant causes issues downstream.

13      70713515        .       A       <STR20> .       PASS    END=70713560;REF=15;RL=45;RU=CTG;VARID=ATXN8OS_13:70713515-70713560;REPID=ATXN8OS_13:70713515-70713560;STR_STATUS=normal        GT:SO:REPCN:REPCI:ADSP:ADFL:ADIR:LC     0/1:SPANNING/SPANNING:15/20:15-15/20-20:10/4:28/29:0/0:31.6047  ./.:.:.:.:.:.:.:.       ./.:.:.:.:.:.:.:.
13      70713515        .       A       <STR98> .       PASS    END=70713560;REF=15;RL=45;RU=CTG;VARID=ATXN8OS_13:70713515-70713560;REPID=ATXN8OS_13:70713515-70713560;STR_STATUS=full_mutation GT:SO:REPCN:REPCI:ADSP:ADFL:ADIR:LC     ./.:.:.:.:.:.:.:.       0/1:SPANNING/INREPEAT:15/98:15-15/74-118:9/0:19/37:0/16:34.708  ./.:.:.:.:.:.:.:.
13      70713515        .       A       <STR12> .       PASS    END=70713560;REF=15;RL=45;RU=CTG;VARID=ATXN8OS_13:70713515-70713560;REPID=ATXN8OS_13:70713515-70713560;OLD_MULTIALLELIC=13:70713515:A/<STR12>/<STR20>;STR_STATUS=normal GT:SO:REPCN:REPCI:ADSP:ADFL:ADIR:LC     ./.:.:.:.:.:.:.:.       ./.:.:.:.:.:.:.:.       1/.:SPANNING/SPANNING:12/20:12-12/20-20:10/7:13/19:0/0:34.5446
13      70713515        .       A       <STR20> .       PASS    END=70713560;REF=15;RL=45;RU=CTG;VARID=ATXN8OS_13:70713515-70713560;REPID=ATXN8OS_13:70713515-70713560;OLD_MULTIALLELIC=13:70713515:A/<STR12>/<STR20>;STR_STATUS=normal GT:SO:REPCN:REPCI:ADSP:ADFL:ADIR:LC     ./.:.:.:.:.:.:.:.       ./.:.:.:.:.:.:.:.       ./1:SPANNING/SPANNING:12/20:12-12/20-20:10/7:13/19:0/0:34.5446

[jemten]

Having looked at it I would prefer if SVDB could merge them prior to vt. I think @J35P312 said he would drop by tomorrow so we can discuss it then :)

[dnil]

Ok, I think it will actually do that rather well given that we just run vt before merge. Perhaps keep the vt after for good measure, but that is another story. Unless it's modified svdb should not be fed multiallelic calls to merge from several individuals.

[jemten]

Me and @J35P312 looked at it and it should only be a matter of switching the order of vt decompose and svdb merge. Currently we run svdb merge first and then decompose on the STR variants. Switching that order we get:

13  70713515    .   A   <STR20> .   PASS    END=70713560;REF=15;RL=45;RU=CTG;VARID=ATXN8OS_13:70713515-70713560;REPID=ATXN8OS_13:70713515-70713560;OLD_MULTIALLELIC=13:70713515:A/<STR12>/<STR20>   GT:SO:REPCN:REPCI:ADSP:ADFL:ADIR:LC 0/1:SPANNING/SPANNING:15/20:15-15/20-20:10/4:28/29:0/0:31.6047  ./.:.:.:.:.:.:.:.   ./1:SPANNING/SPANNING:12/20:12-12/20-20:10/7:13/19:0/0:34.5446
13  70713515    .   A   <STR98> .   PASS    END=70713560;REF=15;RL=45;RU=CTG;VARID=ATXN8OS_13:70713515-70713560;REPID=ATXN8OS_13:70713515-70713560  GT:SO:REPCN:REPCI:ADSP:ADFL:ADIR:LC ./.:.:.:.:.:.:.:.   0/1:SPANNING/INREPEAT:15/98:15-15/74-118:9/0:19/37:0/16:34.708  ./.:.:.:.:.:.:.:.
13  70713515    .   A   <STR12> .   PASS    END=70713560;REF=15;RL=45;RU=CTG;VARID=ATXN8OS_13:70713515-70713560;REPID=ATXN8OS_13:70713515-70713560;OLD_MULTIALLELIC=13:70713515:A/<STR12>/<STR20>   GT:SO:REPCN:REPCI:ADSP:ADFL:ADIR:LC ./.:.:.:.:.:.:.:.   ./.:.:.:.:.:.:.:.   1/.:SPANNING/SPANNING:12/20:12-12/20-20:10/7:13/19:0/0:34.5446

[jemten]

Done