SMN CN page pin button

[Jakob37]

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.

Our local geneticists are looking into using the SMN CN module in their clinical routine, and raised some points for discussion. I'll open issues for their discussion points to discuss.

Describe the solution you'd like

On other variant pages there are buttons "Pin" at the top. Would it be possible to add this?

[dnil]

Right, we've discussed this a few times. We were sort of hoping there would be a bit of development on the caller side to add more variant calls etc. But it would seem they are prioritising similar callers for other genes, which is also very useful of course.

We did add a case tag for SMN that can be used as a case status. If it is added before marking the case "solved", e.g. in conjunction with "technical attention" or "medical attention" statuses as needed it would serve as a form of poor mans pin.

I'm very open to suggestions about the best way to handle callers that do not explicitly make variant calls. One way that I considered before landing on the current is parsing the tabs into variants, making it more like the VCF parser, adding specific variants to the SMN1 and SMN2 genes, eg DELs and DUPs with CN status. We did something along these lines with the new OMICS variants, although there we at least only have one variant per TSV line. The advantage of introducing hard variants is they could be commented, pinned, marked causative etc as per usual variants.

My ideal way to handle it would be to have the pipeline translate non-standard caller output into a standard call format, such as VCF/BCF, and add INFO fields or what not describing any annotation that is not just the genomics variant itself. What I did feel then, and am still not quite comfortable with, is that we should try to keep Scout as generic as possible both from a maintenance perspective and from a MTP perspective. If we incorporate medical/biological considerations into the parsing and viewing, we are very much in the MTP line of work.

See also e.g. regarding auditing such variants https://github.com/Clinical-Genomics/scout/issues/4727.

[dnil]

Maybe we should set up a small joint project to parse difficult region stuff into standardised variant calls? It could read SMNCopyNumberCaller and Gauchian TSVs, Paraphase JSONs etc and print VCF/BCF with annotation. Ping @jemten and @fellen31...

[Jakob37]

One way that I considered before landing on the current is parsing the tabs into variants, making it more like the VCF parser, adding specific variants to the SMN1 and SMN2 genes, eg DELs and DUPs with CN status. We did something along these lines with the new OMICS variants, although there we at least only have one variant per TSV line. The advantage of introducing hard variants is they could be commented, pinned, marked causative etc as per usual variants.

Yes, I think it intuitively makes sense to treat the calls in the SMN1 and SMN2 genes as concrete variants. This is probably how a user thinks about it. Right now the feeling seems to be that the whole page is an SMN1 call, and thus (according to that feeling) ought to have variant specific functionality.

My ideal way to handle it would be to have the pipeline translate non-standard caller output into a standard call format, such as VCF/BCF, and add INFO fields or what not describing any annotation that is not just the genomics variant itself. What I did feel then, and am still not quite comfortable with, is that we should try to keep Scout as generic as possible both from a maintenance perspective and from a MTP perspective. If we incorporate medical/biological considerations into the parsing and viewing, we are very much in the MTP line of work.

I understand the concern about doing too much hard-coding around user issues. Still, I guess the way to go (which you seem to be considering) is how to with minimal intrusion into Scout allow handling non-standard data types. Makes sense to me as well to treat the SMN1 and SMN2 as to SVs somehow, and probably makes sense to parse them into at a VCF-like format at some point (or parse VCF and these into a common data structure).

Maybe we should set up a small joint project to parse difficult region stuff into standardised variant calls? It could read SMNCopyNumberCaller and Gauchian TSVs, Paraphase JSONs etc and print VCF/BCF with annotation. Ping @jemten and @fellen31...

Sounds like a good idea!