CLI option to link a panel to multiple institutes

[Jakob37]

We work with "validation" and "production" institutes, which means we often want to have the same panel linked to these two institutes.

It would be useful to be able to assign a list of institutes both when loading and and when updating the panel.

Right now, we have been assigning lists of institutes directly in mongodb it seems (which seems to be working OK, hopefully it is not a misuse of Scout's db..).

This could be done safer and more conveniently directly at the command line:

scout load panel --institute "Institute A" "Institute B"
scout update panel --update-institute "Institute A" "Institute B"

Does this make sense? I could take a look at this if you think so.

[northwestwitch]

I feel like this has been discussed before but I can't find where. Perhaps it was some meeting.. A workaround would be updating the users that are supposed to update the panel to be collaborating with both institutes. Then they can be assigned as panel maintainers. The drawback is that these users would have access to the cases of both institutes. But if this is fine then this could be a solution?

Right now, we have been assigning lists of institutes directly in mongodb it seems (which seems to be working OK, hopefully it is not a misuse of Scout's db..).

How are you doing this, by turning the institute field into an array of strings instead of a string? Seems dangerous to me, but cool if it works, I guess.

[dnil]

Same here, but I also couldn't find it. The issue for us was research institutes wanting to have easier access to the clinical panels. I think the wooden clog solution became this: https://github.com/Clinical-Genomics/scout/issues/3822, where it's somewhat easy for the user to copy (and modify) a panel between institutes as needed.

In general, both this issue and #4665 reflect how we use a staging instance for testing and validation. Then it is less of an issue to delete test institutes or share panels in validation and production. You could even purge the whole staging instance and start fresh, or copy the prod one/selected parts onto it.

[Jakob37]

I feel like this has been discussed before but I can't find where. Perhaps it was some meeting.. A workaround would be updating the users that are supposed to update the panel to be collaborating with both institutes. Then they can be assigned as panel maintainers. The drawback is that these users would have access to the cases of both institutes. But if this is fine then this could be a solution?

OK I see! Thank you for the context. I'll bring that to discussion here.

Right now, we have been assigning lists of institutes directly in mongodb it seems (which seems to be working OK, hopefully it is not a misuse of Scout's db..).

How are you doing this, by turning the institute field into an array of strings instead of a string? Seems dangerous to me, but cool if it works, I guess.

Yes, it is indeed how it seems we are doing. I am unaware of the history of this though, and asking around noone knew for sure how to do this, just that it was tricky when they set this up once in a time. Looking in the panel page, it appears as expected.

> db.gene_panel.findOne({}, {"institute": 1})
{
        "_id" : ObjectId("<ID>"),
        "institute" : [
                "klingen",
                "CMD"
        ]
}

But interesting and slightly concerning that it isn't intended as a feature. Might it screw things up somewhere else?

[Jakob37]

Same here, but I also couldn't find it. The issue for us was research institutes wanting to have easier access to the clinical panels. I think the wooden clog solution became this: #3822, where it's somewhat easy for the user to copy (and modify) a panel between institutes as needed.

OK I see! Yes, it seems convenient to load a new panel with the same genes. Maybe that is fine for us as well.

In general, both this issue and #4665 reflect how we use a staging instance for testing and validation. Then it is less of an issue to delete test institutes or share panels in validation and production. You could even purge the whole staging instance and start fresh, or copy the prod one/selected parts onto it.

Aha, yes, that makes sense. It seems like a more clean way to do things.

These two issues are not something pressing here, just points of convenience (at least at the moment). Thanks for enlightening me. I'll bring it to discussion here locally.

[northwestwitch]

> db.gene_panel.findOne({}, {"institute": 1})
{
        "_id" : ObjectId("<ID>"),
        "institute" : [
                "klingen",
                "CMD"
        ]
}

But interesting and slightly concerning that it isn't intended as a feature. Might it screw things up somewhere else?

It has the potential, but if the application hasn't crashed yet then you are probably fine 😄

[Jakob37]

As this one seems "off the map" right now, I'm closing.