Scout: Allow the use of arbitrary gene panels as gene lists for case filtering.

[hassanfa]

I created a new gene panel, and added to the institute: "trusight1". Now I want to show it in the filters of all those cases for that institute. It only shows HPO and The Panel, but not Trusight. Should I re-upload with that gene panel name specified, or is there an alternative way?

Here is the panel:

But in case variant view I can't find TruSight:

[northwestwitch]

I'm afraid that the panels are case-based, so yes, you should re-upload the case. But maybe we could fix it to work differently in the future?

[dnil]

Yes! I remember missing that sorely when switching from puzzle.. 😄

[dnil]

The thing is it docks into the way the analysis / clinical test is partitioned and versioned. The idea with locking the panels is to ensure that the analysis has really been completed on those regions. I would welcome some good ideas / brainstorming on this though. Given eg the complete research level analysis and fine grained loading controls it is surely not impossible.

[hassanfa]

I'll reupload them, it's no big deal.

Readily applying a list of genes to a case can be useful. This question came up when going through some validation samples. With a gene list from Illumina's TruSight, to see if we pick up those genes.

[dnil]

Ok. If you ever need to do that live, there is a roundabout through the upload-gene panel on the variants query page. And on the HPO-panel on the case page, one can also add genes "manually" to the dynamic panel, which allows things like chanjo coverage queries and setting as a query preset.

[hassanfa]

Is it possible to have those new HPO-panel genes across multiple cases?

[dnil]

Nope. Not without copy & paste.

[northwestwitch]

I don't think so, because these genes are added on the fly from from the case page. Of you want to use a panel in different cases then it's best if you create it and load the cases with it

[northwestwitch]

Yeah, @dnil answered already

[dnil]

Agreed. The alternative would be to reuse the same text file and re-upload it for searching on the variant page. But not so attractive either. The design is really that if you want to do more than a small thing for one case, you should make a proper panel, export it, run the analysis for it and reimport the case.

[hassanfa]

It is also important to not to have a default gene panel, even if a gene panel is set. As I see in the code:

https://github.com/Clinical-Genomics/scout/blob/62594fc353c09041793ec5d64a56738c534ad5a7/scout/parse/case.py#L87-L92

If gene_panel is set, there has to be a default_gene_panel. This is an intentional behavior, but it would be great to consider cases where multiple gene panels without any preselected gene panel can be used. Again, an example rose today to review ~16 cases with various gene panels __after__ reviewing variants without any panel.

Do you think this is a niche feature and redundant with HPO-panels?

[dnil]

Are you working with ET? :wink:
This is I suppose a developer / research vs clinical use case thing. The clinical case would suppose that someone has decided on default panels prior to ordering the test. On the RD side we kind of like to keep track of our case by means of the (currently selected) default_panel. Typically different teams handle an NMD vs SKD. I don't quite see a reason this would not catch on on the cancer side as well - ppl tend to be good at different subtypes.
Then again, if it is useful it would certainly not be impossible to allow default-less cases.

[hassanfa]

Awesome! thanks for the feedback. For now I'm adding a default gene panel for these cases.

No, not with ET. These are none solid tumors :)

[dnil]

Ah, I see. Good luck - but lets meet and chat about this sometime. We may be able to come up with a good way to add some research/devel-level flexibility without sacrificing what is good about the rigidity surrounding the final clinical test.

[bjhall]

Going back to the original issue of this issue: This is something that is highly requested by our clincal users here in Lund.

I think we don't really use gene panels the same way as you, and it has been mostly an annoyance that gene panels have to be statically added at load time. For instance, often cases are loaded into Scout months before anyone looks at them, and then gene panels are already out of date and new ones are missing etc.

One suggestion would be to allow some thing like (in the case yaml):

gene_panels: "dynamic"

Which would allow the use of the latest version of every panel associated to the institute of the case. I am not sure if this is easily implemented or requires refactoring of the gene panel code, though...

It would be nice if we could discuss this, because I think I will soon be forced to implement this somehow, and I really want to avoid our fork to diverge.

[dnil]

Ok! Do you always load every (highly ranked) variant from every case then?

I tend to lean towards wanting to do at least a re-annotation if the case is several months old - and typically at least a partial re-run to get the newest goodies. But, that does not mean we have to enforce it. The possibility to apply panels more pragmatically like gene lists woult fit well with our research cases, where we load (most) variants. It wouldn't have to be so difficult, especially if we still treat the "panels" slightly different from the

Lets' talk about it! Are any/both of you going to Stallet/associated GMS meet-ups next week?

[hassanfa]

I am not attending that GMS meetup next week. That's the GMCK-RD right?

[bjhall]

Yes, we almost always load all highly ranked variants.

We typically do new releases of our pipelines quite infrequently (like once every 3-6 months). Then we will typically fully reanalyze all lingering cases. But it is really the standard case for us that it takes at least 1-3 months before anyone looks at the data. Hopefully this will improve in the future, but we'll have to live with it at the moment...

Another use case is that we will soon start running very rare indications (currently they are sent to a commercial lab), where we typically won't have gene panels beforehand. Our users have requested that they should then be able to create gene panels retrospectively.

Unfortunately I won't be at Stallet either this year.

[dnil]

@hassanfa Yes, it seems to be GMS-RD.
@bjhall I'd highly recommend dynamic HPO-panels and custom gene list panels for these, but if they are not super rare - rather panels in the making - then saving a list in the system makes sense. Also, our users would like the option to be able to save a completed gene list for later reference directly on the system rather than in separate text files as well. I think we are converging on implementing something like that, but it won't happen this week. Feel free to PR, any of you, but otherwise we will get to it eventually!