ChRIS identity crisis

[jennydaman]

Posts in this discussion are specific considered use cases for ChRIS.

The language used to describe each solution may or may not be implemented. While some use cases overlap, the mindset for how to distinguish one use case from another is in how use cases need to be optimized in different ways from a developer's perspective.

[jennydaman]

Making it easier for researchers to run advanced scientific software.

Problem: scientific analysis software are usually difficult to install and run on HPC.
Solution: ChRIS provides a GUI and CLI for running scientific analysis software on compute resources. Furthermore, ChRIS manages data provenance, which facilitates collaboration and reproducibility. It would be necessary for ChRIS to have good integration with existing workflows, e.g. it should be easy to mix usage of ChRIS with interactive and/or manual out-of-ChRIS steps, and JuPyTer notebooks. ChRIS embraces "best practices" such as version pinning of software and immutable pipelines for better reproducibility.

[jennydaman]

Making it easier for developers to share advanced scientific software.

Problem: Developing scientific software is difficult, then the dissemination of such software is yet another challenge. Most scientific software are not shared. Shared scientific software are still difficult for others to find and use.
Solution: our project provides the ChRIS plugin template, helping developers get started with developing containerized scientific software which can "run anywhere" (that's the goal). It is easy to add (and edit) plugins to ChRIS, as well as copy plugins from one ChRIS to another. ChRIS provides a website where published plugins are publicly listed, helping them be discoverable online.

[jennydaman]

Enabling the hybrid cloud for biomedical research.

Problem: On-prem and public cloud resources differ in terms of cost, performance, and privacy.
Solution: ChRIS provides an architecture and backend for managing computational workflows. Steps of each workflow can be chosen to run on different compute resources, and there is good support for a variety of compute engines such as k8s, OpenShift, and SLURM. Since privacy is a big concern in hospital research, there are safeguards to prevent PHI from being sent to public clouds from internal deployments of ChRIS.

[jennydaman]

Clinical integration of automated research software in radiology.

Problem: research software is often developed for the sake of publication, failing to see the light of day in the clinic. Meanwhile, clinical practice of medicine is often slow to adapt new research and technologies.
Solution: ChRIS integrates with PACS and a radiologist's existing workflow. ChRIS can retrieve imaging data from PACS, and automatically run analysis pipelines on it. The final results are sent back to PACS. It is easy to trace the data lineage to troubleshoot pipelines.

[jennydaman]

Scaling compute to thousands.

Problem: We want to run neuroimaging analysis software on thousands to hundreds of thousands of subjects of data. To do this, the user often needs to write their software in a scalable way and know how to use advanced HPC schedulers such as SLURM job arrays.
Solution: ChRIS makes it easy to run any simply developed containerized application at scale across multiple compute nodes. From the GUI/CLI ChRIS client, the user is able to monitor the entire batch as a whole (e.g. see 110/16000 complete, 80 running, 2 failed) as well as individual runs (check logs, CPU and memory usage, ...)

[jennydaman]

Dataset sharing and management (BLT project).

Problem: researchers want to share neuroimaging datasets (DICOM and/or NIFTI) with each other. The data sharing platform should be secure and the access control should be easy for administrators. It should be easy to search over metadata, e.g. "find all data associated with MRN" or "all MRIs where patient has ventriculomegaly"
Note: historically, ChRIS has always been designed to be "compute-first, not data-first." This design philosophy was intentional and one differentiating approach between ChRIS and its competitors. It is the reason why currently, it is not easy to work with ChRIS as a filesystem or data manager, and why clinical metadata (PatientAge, PatientSex) are not kept with files (besides PACSFiles). Is this design philosophy still relevant today?

[jennydaman]

Neuroimaging data visualization.

Problem: most neuroimaging visualization software such as FSLeyes and freeview can be finicky to install: those two must be installed as part of large (>6GB) software packages. Getting them to run can be challenging as well, as system dependency or compatibility issues are common (Linux distro, glibc version, X or Wayland, OpenGL, mesa).
Solution: The ChRIS_ui provides advanced visualization capabilities for neuroimaging file formats such as NIFTI and DICOM. Using ChRIS_ui, 3D image data can be visualized with different colormaps and contrasts. Multiple images can be superimposed, which is useful for image segmentation. It is easy to add files to ChRIS for visualization.

[jennydaman]

Open, Federated approach to cloud computing

Problem: what is a self-sustaining model for private, open-source computing?
Solution: ChRIS is an open-source platform for computational science. It has features which enable a federated model: (a) ChRIS is easily self-hostable. (b) ChRIS can associate with peer instances. (c) ChRIS can obtain plugins from peer instances. (d) ChRIS can push data to and/or pull data from peers. (e) fun reach goal: implement support for the ActivityPub protocol with ChRIS, so you can share your scientific analyses with Mastodon, Lemmy, ...!