Scout: Persistent filters, similar to gene panel

[hassanfa]

@dnil 's idea from Scout user meeting actually, right?

I'd like to be able to save filters and have filter maintainers, this is most likely not so hard, right? Or even better, upload filters via CLI. If this happens, we can have filters in the Order similar to what is done for in silico gene panels for rare-disease (MIP).

A second thing I'd like to have, which might be a bit hard is the followin:

To be able to load a filter, click button to pin'em all for the report. e.g. I have used a somatic_filter_ffpe Version 1.0 and I see that only 10 variants are there. And now I want to create a Scout report for these variants with content of the filter used. In other words, I want to see which filter and which version was used to generate this result. This is loosely related to https://github.com/Clinical-Genomics/scout/issues/1915 .

[dnil]

Well, in part, but with some Hassan-esque flair to it! Let's break it down to bullet points!

So for the first part, that aready exists, although we currently set filters by institute, sort of to achieve what you next describe: that you or one of the CLGs from the customer side could create a set of filters that the users, typically perhaps the technicans or CLGs-in-training on the clinic side. This works so-so at the moment, mostly I believe because the "delete filter" button is big, red and accessible to all users from an institute regardless of their current mood. My bullet would be

• [x] allow only filter maintainer to delete a filter (but I'm not quite sure it's time for this yet)

Adding a load filter option to CLI is fun, interesting and very possible. One could easily load a json filter from file. Consider it a request!

• [ ] CLI load filter from json

The second part is also in two parts. For the first, it was envisioned for reports at one point but never implemented. The idea being that one could "check" the filters that had been applied to a case and export that to the report so that one could communicate to the referring doctor that "I analysed the case for both de novo and recessive variants, and this is what I found". If one wanted to use only one filter, that would be what ended up on the report, so compatible with your scenario. I'll add that as a task, but rendering more than say the filter name to the report may be a bit difficult. We don't have filter versions, but an institute could easily just name their filters accordingly, e.g. somatic_filter_ffpe_HF_200917.

• [x] optionally export applied filter names to general report

The last part is pinning multiple variants. I have personally never had the need, but I suppose the same goes for dismissing. We could probably reuse part of the dismiss-multiple-variants from the variants view. Sounds good!

• [ ] pin multiple variants on variants view

[hassanfa]

My idea of persistent filter is also to replay what person A did to come up with variants that were ultimately reported. This might contradict a bit with what Scout is: "an interpretation tool".

Ok, now back to the bullet points. I'll just enumerate them if that's ok 😄

1. Deletion protection is good to have. Or we could have delivery filter vs discovery filters. Delivery is the ultimate one that can make a report, again this is to be able to replay what made the report.

2. Cli and via json is perfect! 👍

3. Discovery vs delivery reports. Or we can call them clinical vs research filter. We can discuss this, I think this might be a big decision.

4. That's good. But pinned list might accidentally get quite large. So a limitation on how many to pin?

[dnil]

My idea of persistent filter is also to replay what person A did to come up with variants that were ultimately reported. This might contradict a bit with what Scout is: "an interpretation tool".

Right, agreed: anything that is completely automatable does not belong in a GUI (or WUI) as it is. Only if it is not clear what needs doing, and human intuition and/or arbitrary choices are needed, should human intervention be encouraged. Don't take a sword to a bow-fight. Exploration and interpretation are still in the visualisation domain.

1. So again, no replaying. No delivery filters. That is another, much easier program. Its basically just bcftools with queries for the variants. Nothing to see there. But protecting filters from the own institute as well is clearly under consideration anyway!

2. 👍

3. I don't see why there would be a difference between clinical and research filters? If so, the names could reflect that if need be?

4. Hm, well, but surely no case would have that many really interesting variants? Sounds like a poor operator, poor ranking or poor pre-filtering?

[hassanfa]

TL;DR: immutable vs mutable filters (clinical vs research).

Right, so how I see discovery filters are those that are a user makes for themself. In other words, a mutable filter. A delivery filter is a filter that is defined through rigorous benchmarking and validation. Values are sourced from publications, known studies, or internal white-papers/SOPs. These filters are immutable.

Also another reason is to be able to name these filters based on source of origin. Example: MSK-IMPACT filter for panel: mskcc_ngs_filter_v1.json, etc. We continuously add annotations, softwares, or ranks according to sources or home-grown knowledge. I don't see why filters wouldn't benefit from that.

[hassanfa]

I tagged cancer to this, cause rare-disease track already benefits from rankmodel.

[dnil]

Yes, sounds very nearly exactly like what we do with the rank model? Convert mskcc_ngs_filter to a mskcc_mps_rank, rank and load. Highest impact according to rank on top, but all vars available?

[dnil]

Filters can now be locked and audited on general report. I bailed on the json load part. Do ping again if it would be really helpful. Also as mentioned above, pinning multiple might hitchhike on the dismiss dialog, but easily becomes a bit much. Lets revisit if there are more requests.

[hassanfa]

Woop woop! 🥳