Scout: Decide to keep or not the dismissed variants upon reruns

[northwestwitch]

This was a topic of discussion but I had the impression we didn't reach an agreement during today's meeting. Any ideas?

[henrikstranneheim]

I think we should postpone this one until next meeting and bring it up again - preferably with a suggestion solution.

[northwestwitch]

Ok, let's close it and we can reopen it any time later

[4WGH]

we need to be able to save the dismissed variants when there is an upload of rthe case that has nothing to with us asking a re-run.
See what has appened nw with the re-load due to the CLinVar issue. Hours of work lost......
if Chiara can still see the comments on the database, could we have them put back?

[dnil]

I'm sorry (and more than a little frustrated) about this. The cases were supposed to be re-uploaded without reseting the dismiss status, but apparently there was some over-eagerness or a miss in communication somewhere along the lines. We'll see what we can do with the present db state and db backups. Again, apologies, we had considered that, but out of routine operation is complex. Don't dispair over all the work just yet.

[4WGH]

I know it was not meant. I've written the comment to re-open this issue as suggested by Chiara
So we can re-think about it. Now we have experienced the consequences of this and are more aware how we are affected.
Trying to keep positive!

[northwestwitch]

I was thinking that this could be fixed in the variantS page.
Whenever the user clicks on variantS (of any type) we could show a notification that some variants were dismissed in a previous run and ask if the user is interested in turning the same variants from the new run into dismissed again.
This might be the simplest way to handle the situation, just one check in the variant events and a new function activated by the user.

[northwestwitch]

Or maybe at the case level?

[northwestwitch]

Ok, I don't think this will be so difficult so I could start writing some code today. I'll let you know how it goes!

[dnil]

Unless you actually had a day off.. 😜

It would contextually fit well with rerun requests. It is a pretty fun problem, but not super simple. I suppose you will have to play back the whole event log on the case to make sure that events that have since been countered manually (e.g. revoke dismiss, remove comment, etc) - even several times - are at a good final state?

[northwestwitch]

It's OK, I'm a busy later around lunch but I have some time now

[henrikstranneheim]

Is this not 2 user cases:

1. We need to reload cases due to an unforseen error. All work previously done for a case should be kept. I guess this would be a option on the CLI when reloading set by operator at Clinical Genomics.
2. The investigator orders a rerun to reanalyse a case and wants to start fresh. Then we do not want to keep the previous info

[northwestwitch]

Yes, it is those 2 cases, but I was thinking about the actual situation, where we can't undo the variant uploading and the previous work is lost (well, not really, because of old variant database events). What do you suggest @henrikstranneheim ?

[henrikstranneheim]

Ok, then I understand this is a separate problem from the user cases. I think you should proceed as you suggested but do it at a case level if possible. Then the user only have to make a decision once to reinstate the previous work.

[northwestwitch]

case level if possible. Then the user only have to make a decision once to reinstate the previous work.

I agree!

[northwestwitch]

Mm I've just realized that we can't automatically dismiss variants based on the previous events because in the previous events database collection there is only written the variant that was dismissed but not the reason(s) why it was dismissed.. Any suggestion here?

[dnil]

Did the variant dump go through last week?

[northwestwitch]

Did the variant dump go through last week?

You mean if we have a database backup updated? I don't know!

[dnil]

Precisely! @henrikstranneheim ?

[henrikstranneheim]

I have not been involved. We should ask @moonso

[northwestwitch]

Hi @4WGH, I know it's not the same thing, but I could give you a list of all dismissed variants for the cases re-uploaded for your institute. Would that be useful?

[4WGH]

we found a solution, thanks!

Let's work on a good solution for the future :)

Michela

---

Från: Chiara Rasi [e-mail]
Skickat: den 18 mars 2020 07:25
Till: Clinical-Genomics/scout [e-mail]
Kopia: Michela Barbaro [e-mail]; Mention [e-mail]
Ämne: Re: [Clinical-Genomics/scout] Decide to keep or not the dismissed variants upon reruns (#1649)

Hi @4WGHhttps://github.com/4WGH, I know it's not the same thing, but I could give you a list of all dismissed variants for the cases re-uploaded for your institute. Would that be useful?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Clinical-Genomics/scout/issues/1649#issuecomment-600446729, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AC7R5EL4CWZPXP4E4WIXT3LRIBSMNANCNFSM4KKC7FQA.

[northwestwitch]

we found a solution, thanks! Let's work on a good solution for the future :) Michela

👍

Can I ask you the favor to open a ticket in our support system asking specifically for this list? That is a secure channel to exchange this type of information!

Thanks! :)

[dnil]

You mean the return of data on caesar is secure, right? Emails are public, but at least one degree less so than these pages. :+1:

[northwestwitch]

I think emails exchanged there are more secure than me sending a personal email to her personal email 🤔

[dnil]

Absolutely more correct, I'd say, but not more secure. They are all a) very cleartext readable enroute b) documents that are in principle in the KI or KTH diarium, and subject to release if someone asks for them. Requests are fine though, but delivery is best on caesar or by some other encrypted service - and services that can be considered work documents. 😊

[northwestwitch]

Request via support system and delivery on caesar sounds great!! Thanks @dnil !

[northwestwitch]

We have just reached an agreement with @4WGH that the dismissed list is no longer needed, because they saved all the needed info just before the case re-upload. But we should work on the re-upload routine so that it will ask in any case if this type of info (dismissed variants and other tags) will be kept or not upon variants upload.