You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
⚠️ Important: Please avoid sharing any sensitive or personal information, including text or images, in this issue.
Is your feature request related to a problem in the current program to new available techology or software? Please describe and add links/citations if appropriate.
In the next release of balsamic we're planning to enable soft-filtering of SNVs present in the matched normal (the current matched normal filters will be unchanged but will not be hard-filtered), and as a result variants will be uploaded to Scout with a couple of new filters. See issue in MTP-BALSAMIC: https://github.com/Clinical-Genomics/MTP-BALSAMIC/issues/1
At the moment we have 2 filters which are both used to filter out variants based on presence in the normal. There is "germline_risk" from TNscope, and a custom bcftools filter which used to be called "high_normal_tumor_af_frac" but which we will rename in balsamic v17.0.0 to "in_normal".
This was requested by some customers mainly due to the risk of filtering out clinically relevant variants with a high presence in the normal, but will cause some institutes in Scout to receive variants they are not used to seeing, and which they likely do not wish to see, and to avoid this it would be nice to have easy option to filtering out these "high normal" variants by default for these institutes by applying the balsamic soft-filters.
Describe the solution you'd like
We discussed adding another checkbox here:
Which can be set to default removing the soft filtered normal variants on an institute level. But I trust in the scout-devs to figure out the best solution! 🙏
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This feature is planned to be activated on the balsamic side in release 17.0.0, for all T+N matched panel analyses, which will increase the number of variants uploaded to Scout for this analysis type. But as the common germline variants are mostly filtered out by population databases the increase shouldn't be that massive. They will in essence in terms of number of variants become like tumor only analyses, which based on what I have seen would roughly increase the number of variants from 2k to 4k, but it varies on the panel.
To get a sense of what this will mean for the total number of variants uploaded from balsamic I counted the current number of tumor only cases in the production directory to 187, and the number of tumor normal cases to 19. Which means that roughly for every 10 tumor only case there's a tumor normal. As a very rough guesstimate the total number of variants from balsamic should with this feature increase by roughly 5%.
But together with new filters planned to be added in 17.0.0 probably the net variants will actually decrease. It could also be looked into how this feature could be selectively implemented for certain institutes / or optionally per order.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem in the current program to new available techology or software? Please describe and add links/citations if appropriate.
In the next release of balsamic we're planning to enable soft-filtering of SNVs present in the matched normal (the current matched normal filters will be unchanged but will not be hard-filtered), and as a result variants will be uploaded to Scout with a couple of new filters. See issue in MTP-BALSAMIC: https://github.com/Clinical-Genomics/MTP-BALSAMIC/issues/1
At the moment we have 2 filters which are both used to filter out variants based on presence in the normal. There is "germline_risk" from TNscope, and a custom bcftools filter which used to be called "high_normal_tumor_af_frac" but which we will rename in balsamic v17.0.0 to "in_normal".
This was requested by some customers mainly due to the risk of filtering out clinically relevant variants with a high presence in the normal, but will cause some institutes in Scout to receive variants they are not used to seeing, and which they likely do not wish to see, and to avoid this it would be nice to have easy option to filtering out these "high normal" variants by default for these institutes by applying the balsamic soft-filters.
Describe the solution you'd like
We discussed adding another checkbox here:
Which can be set to default removing the soft filtered normal variants on an institute level. But I trust in the scout-devs to figure out the best solution! 🙏
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
This feature is planned to be activated on the balsamic side in release 17.0.0, for all T+N matched panel analyses, which will increase the number of variants uploaded to Scout for this analysis type. But as the common germline variants are mostly filtered out by population databases the increase shouldn't be that massive. They will in essence in terms of number of variants become like tumor only analyses, which based on what I have seen would roughly increase the number of variants from 2k to 4k, but it varies on the panel.
To get a sense of what this will mean for the total number of variants uploaded from balsamic I counted the current number of tumor only cases in the production directory to 187, and the number of tumor normal cases to 19. Which means that roughly for every 10 tumor only case there's a tumor normal. As a very rough guesstimate the total number of variants from balsamic should with this feature increase by roughly 5%.
But together with new filters planned to be added in 17.0.0 probably the net variants will actually decrease. It could also be looked into how this feature could be selectively implemented for certain institutes / or optionally per order.
The text was updated successfully, but these errors were encountered: