XNAT Workshop 2022 Hackathon Projects

There are numerous reasons why it might be helpful for XNAT to work with a data storage backend where the archive structure is different from the way things are currently. Here are three examples:

• DICOM files zipped at scan, session or subject level: Backup systems are inefficient when dealing with large numbers (millions or billions) of small files. Filesystems can "run out of inodes". Although multi-frame DICOM was introduced partly to deal with this situation, many clinical sites turn off the facility to export data in this way, because many systems are still not equipped to handle this type of data. Hence, it is still very common for DICOM series to be stored with one file per image slice. Can XNAT be modified to zip these files automatically and index the zip files in a way that makes it transparent to extract the data.
  
  
• S3: Would cloud storage of XNAT data be more straightforward if there were a seamless method of specifying S3 as a storage backend?
  
  
• VNA: Can we imagine a situation where XNAT becomes a "research overlay" onto a PACS, such that we do not have to duplicate data when we import studies into XNAT?

The XNAT team has long supported the goals of FAIR research – making data findable, accessible, interoperable, and reusable. There is widespread recognition that "federation" of XNAT systems, that is, creating some mechanism for sharing of either catalogue data or actual data between different XNAT instances is an important development that could play a part in this process, but, to date, there has not been widespread community discussion of exactly what this might look like. Here are two example projects that are currently ongoing:

• Neurobridge is a project based at WashU. A recent call on the XNAT discussion Google Group invited participation of interested parties and there is a collaboration home page here.
  
  
• NCITA has created a federation plugin and associated support consisting of the following features:
  • creation of user pool on AWS Cognito, which supports dual-factor authentication and sign-in via different identity providers
  • XNAT admin can configure an arbitrary number of trusted Cognito user pools, permitting a single XNAT instance to be federated to multiple different groups
  • from an authenticated XNAT session, an XNAT user can join one of the configured federation user pools
  • a single user on Cognito can have profiles on an arbitrary number of separate XNAT instances
  • single sign-in to Cognito enables simultaneous authentication via OpenID to multiple XNAT instances, allowing cross-platform searching to build cohorts from studies domiciled in different locations

Monitoring XNAT instances is an important management task. In other applications, such features are often provided by "dashboards". Some examples of what one might want to monitor are listed below:

• Hardware/VM status
• Software status: Java, Tomcat, etc.
• Recent data archivals
• Logged on users
• Running containers / processes (e.g., ML training)
• Project stats (number of subjects, sessions, users, data types, etc.)
  Note that end users may also be interested in this element of dashboard functionality, where it may overlap with cohort selection/discovery (see the IDC exploration page for an example).

Currently, XNAT monitoring provision is split over a number of different parts of the webapp and external tools:

• Java Melody tools: Administer → Site Administration → Miscellaneous → Monitoring
• Recent uploads side panel on Home Screen
• Administer → Users
• XNAT machine learning project dashboard
• Python-based XNAT dashboard: video demo and GitLab repository

This potential project asks the question: should we, as a community, try to unify this work and provide a more coherent/common interface? Answering this may also link into the whole discussion of "XNAT 2.0": what do we want XNAT to look like in the future?

Core XNAT?

Plugin?

External tool in ecosystem?

The ICR and NCITA teams have been very grateful to the community for the positive reception of our development of the XNAT-OHIF viewer integration and to the WashU and Flywheel teams for all their support. We propose a project to set priorities for future viewer development and would like to canvass the community for ideas and a wish-list. It's likely that we do not have the coding resource to implement everything, but we would like to capture as many different requirements as possible.

Areas of need already identified are:

• integration of "core OHIF" measurements panel (currently in beta)
• form.io-based annotation side-panel to complement currently-in-development work in core XNAT (currently in alpha)
• enhanced support for MONAI-label (in active discussion / alpha)
• version control for ROIs, ROI visibility for multiple users, etc.
• further DICOM-RT support (e.g., RT-DOSE, multiplanar contour view)
• performance enhancement (currently exploring ideas)
• transition to OHIF 3 core framework
• improved display for multidimensional data (e.g., multi-echo T2, DWI, cardiac phases)

Plugin

Use of XNAT within the UK is growing fast, with many universities, hospitals and other organisations adopting XNAT as a platform. Should there be a more formal grouping / structure to bring us together to share experiences? If so, what form should this take and what should we do as a UK community? 

Organisational