Jorge walked us through a demo of the ChRIS admin panel to register plugins to ChRIS from the ChRIS store.

This panel uses an admin tool built into Django. It's part of a larger workflow we need to support for the hackathon:

1. Create plugin
2. Add plugin to the ChRIS store
3. Register plugin to a ChRIS server
4. Run plugin on data in ChRIS

This admin panel is what would be used to register a plugin already added to the ChRIS store into the ChRIS server the panel is running on.

We had a discussion around the layout of the form for adding plugins as well as the interface for modifying how already-registered plugins are configured.

Add plugin interface

Some confusion that came up about this form was the environment around it:

• Is there only 1 ChRIS store?
• Could there be more than one ChRIS store you might want to register a plugin from?

Currently ChRIS can only register to one ChRIS store, but there isn't any reason why it shouldn't be able to register to multiple ChRIS stores. There could be a multitude of stores - for example, a given institution may want to stand up their own store of content curated specifically for their staff's usage rather than allowing anything on the public store to be registered to their ChRIS.

Each plugin in a ChRIS store has a unique id that is unique to that ChRIS store. Each plugin+version has an id. So for example:

• some-plugin v 1.0 could be id == 1
• some-plugin v 1.1 could be id == 2

The way the ChRIS store works, it doesn't treat different versions of the same plugin any differently than other plugins.

The issue here is that an ID number of 1 on ChRIS Store A is likely not the same plugin with id #1 on ChRIS store B. If a given ChRIS instance could be registered to multiple ChRIS stores, we need to ensure there's clarity about which specific plugin the user intends to register to their ChRIS. We talked about two potential solutions to this issue:

1. There could be an order of precedence across the ChRIS stores your ChRIS server is registered to, kind of like how there is for package repos on a Linux system, when it can't find a package in repo #1 it falls back to repo #2, so on and so forth.
2. We could have a unique ID of some sort that would encode both the ChRIS plugin + the ChRIS store it resides on

The first option, it was pointed out that for researchers trying to reproduce results with the exact same image as preivously used, this might not be precise enough a mechanism. The latter might be a better solution since it is very clear the exact plugin source and version needed. Using the plugin's URL was suggested as an easy unique ID, or having a dropdown to indicate which ChRIS Store.

After the meeting, Jorge and Mo discussed this and came up with this mockup:

One issue Jorge pointed out - what happens if the user fills both sides of the form? Mo suggested a javascript that greys out the vertical half of the form that is not in focus so it's clear the in focus side would be submitted.

Modify already registered plugins in admin interface

The other piece Jorge demoed was a list of plugins registered to the ChRIS server in the admin panel:

It was suggested the list be put into alphabetical order and allow for searching of specific plugins so it's less overwhelming to find what you're looking for.

Mo Status

Mo showed a work-in-progress mockup that translates Rudolph's PACS search application as a tool embedded into the main ChRIS UI.

One question that came up - would we build custom UIs like this for other data sources, or how would those be handled? We talked about having a separate 'Reference' section of the library which would be a single place multiple 'collections' of data could be plugged into in a generic / standardized way, not requiring custom UI: