XNAT Workshop 2022 Hackathon Projects

This is a description of an example group project. It should have an interest

ing feature set that adds something novel to the XNAT universe, while being constrained enough in scope that a two-day hackathon can produce a meaningful minimally viable product to demonstrate. You might propose an estimate of how many man-hours or why type of core expertise you think will be necessary, to help you recruit team members

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, contrast used 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?

This will be a guided session, led by members of the OHIF team

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

@a user

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? 

This likely can be done over a short session (or even lunch/dinner). People still register their interest here, but it is unlikely to be a full-fledged hackathon project. 

Organisational

This will be a guided session, led by members of the XNATpy and XNAT Team who have been working on Jupyter Hub integration.

A free-form, open-ended exercise with guided instruction available. Build a cohort of data in XNAT, and then port that data to a Jupyter Notebook and perform exploratory data mining, or bring your own computation into this environment. Once you develop outputs, discover ways to port those outputs back into your XNAT project.

This will be a guided session, led by members of the XNAT team who have developed the container service

Get hands-on guidance on building a container from an executable script of your choice, and learn how to write XNAT-enabling Command JSON scripts that enable you to run those containers from a variety of data contexts within XNAT.

We are using XNAT to carry out image reconstruction (currently MR but PET is also in the pipeline) within XNAT using Docker.

In order to fully support raw data within XNAT we would like to define new schemas for raw data. We will start with a new schema for MR raw data based on MRD (previously called ISMRMRD) - the open-source data format for MR raw data (https://ismrmrd.readthedocs.io/en/latest/index.html). In a second step we will focus on PET raw data and how to create a schema to support the interfile raw data format (https://stir.sourceforge.net/links/petinterfile03.pdf).

We would like the outcome of this conference workshop session to be an updated roadmap for XNATpy and help increase the number of people that will be contributing to the code. We could add small features together and plan how to make bigger additions in the future collaboratively. Things we already thinking about are:

• Adding better support for site administration
• Adding support for searching in XNATpy (this is already in progress)
• Adding a CLI for XNATpy
• Other features to improve federated learning?
• Better integration with the Jupyter Hub on XNAT
• Support for container services
• MONAI integration?

Everyone will be encouraged to give their input on this.

Can we create a 'contactless' rule for dicom routing for defined projects in our XNAT instance. By contactless, i mean, no technologist or radiographer input/editing of the dicom tags will be required. My initial thought was to label a protocol with project and subject information in a dicom tag that will not change and then to use a custom rule for the session label, ideally using the date and timestamp (or a derivative of these) to form the session id. The idea behind this is to make acquiring longitudinal MR QA data as simple and error free as possible. I would also be keen to know if there are existing tools / plugins for displaying / interacting with longitudinal QA results accessed via a dashboard type format. If not, then maybes that’s a hackathon project in its own right

We would like to use XNAT to store polysomnography data . We have previously been using a custom plugin designed to work with EDF+ files. However DICOM Working Group 32 has introduced DICOM Suppliment 217 for Neurophysiology Waveforms.

Their press releases say the following:

• This Supplement introduces a number of Services Classes for Storage of Neurophysiology Waveforms by adding the related Neurophysiology IODs and the necessary Neurophysiology Waveform Context Groups.
• It adds a SOP Class to store routine (clinic) electroencephalography (EEG) data recording the electrical activity of the brain collected on the skull surface using electrode positions of the international 10/10 or 10/20 localization scheme.
• It adds a SOP Class to store electromyography (EMG) data recording the electrical activity of skeletal muscles.
• It adds a SOP Class to store electrooculography (EOG) data collected near the eyes recording eye movement.
• It adds a SOP Class to store generic neurophysiology signals.

We would like ideally to add support for this schema to the XNAT core or if it develop an XNAT plugin that would allow us to store these kind of DICOM files.

Core XNAT Data type or

Data type provided via plugin

This will be a guided session, led by members of the XNAT team

If you are relatively new to XNAT, and you are looking to understand some of the core elements a bit better, then these sessions will allow you to dig into the details of various aspects of XNAT and ask some of the experts in-depth questions about how XNAT works and how to make it work for your applications.