Skip to main content
Skip table of contents

XNAT Workshop 2022 Hackathon Projects

This page is meant to be editable by workshop attendees. Log in to edit this page.

If you have registered for this workshop but do not have a login, please contact

This page is being used to propose hackathon projects and get interested people on board to contribute to them. If you would like to join a project, please add your name to the contributors list. If you would like to propose a project, feel free to do so, using the "Heading 2" format for your project title so it will show up in the project list at the top of this page.

Project List

Sample Project 1

Proposed by Will Horton, XNAT Team (Flywheel)

DescriptionType (Plugin, Script, External App)Contributors

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


XNAT with alternate storage backends

Proposed by Simon Doran, Institute of Cancer Research, NCITA

DescriptionType (Plugin, Script, External App)Contributors

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?
Changes to core XNAT

XNAT federation

Proposed by Simon Doran, Institute of Cancer Research, NCITA

DescriptionType (Plugin, Script, External App)Contributors

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

XNAT management dashboard

Proposed by Simon Doran, Institute of Cancer Research, NCITA

DescriptionType (Plugin, Script, External App)Contributors

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:

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?


External tool in ecosystem?

XNAT-OHIF viewer development

Proposed by Simon Doran, Institute of Cancer Research, NCITA

DescriptionType (Plugin, Script, External App)Contributors

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)
  • 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)


@a user

Establishing a UK XNAT user group

Proposed by Simon Doran, Institute of Cancer Research, NCITA

DescriptionType (Plugin, Script, External App)Contributors

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. 


XNAT / Jupyter Hub Playground

Proposed by Will Horton, XNAT Team (Flywheel)

DescriptionType (Plugin, Script, External App)Contributors

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.

Integration, ML

Container Construction for XNAT

DescriptionType (Plugin, Script, External App)Contributors

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.

Container Service

Schema for raw MR and PET data

Proposed by Christoph Kolbitsch

DescriptionType (Plugin, Script, External App)Contributors

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 ( In a second step we will focus on PET raw data and how to create a schema to support the interfile raw data format (

Datatype Plugin

XNATpy roadmap and collaboration

Proposed by Hakim Achterberg (Erasmus MC)

DescriptionType (Plugin, Script, External App)Contributors

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.

External Library

Contactless QA

Proposed by John McLean, NHS GGC

DescriptionType (Plugin, Script, External App)Contributors

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


Datastructure definition format of derived data

Proposed by @a user, Erasmus University Medical Center, The Netherlands

DescriptionType (Plugin, Script, External App)Contributors

Storing data that is derived from a raw DICOM image (e.g. nifti's, segmentations, registrations, classifications, etc.) is almost always done in an unorderd fashion, or when there is some organization, it is done according to a locally developed data structure. XNAT of course has a lot of flexibility on how to store derived data, which has the downside that projects vary on how they store this data. Specifically, within collaborations, we would like to define a (meta-)data model or data structure to make sure data collections are searchable. For this we need to define a set of guidelines and a datastructure definition model so you can understand the organization of data set at first glance and it should be machine readable so it can be part of a larger eco-system. With the Imaging Community of  the Dutch Health Research Infrastructure (Health-RI) we are starting develop some guidelines/recommendations on how this organization should look like to allow an even further degree of interoperability and standardization. As such this would bring us closer to actual Findability and Interoperability of the data.

What: In this session we would like to have a discussion (next to a whiteboard preferrably) on how such a datastructure definition would look like.

Scope: Data structure description (file) describing how derived data is organized. 

Goal: Further development of a common data structure definition and make sure we don't reinvent the wheel 😉

As a starting point we will define a prototype of a data structure definition which adheres to the following:

Structure definition:  

  • For every data collection on XNAT (e.g., project): 
    • Project resource: STRUCTURE/definitions_{timestamp/version?}.yaml 
    • What type of scans are in the project (T1, T2, etc.) 
    • derived data: describe the path structure of how to store derived data in this project: 
      • e.g., {experiment}/{resource_name}/{derive_method__name}_{project_ref}_{isodate}.{ext} 
      • Describe the content of the file (e.g. name and description processing used, potentially extra fields to indicate exact pipeline/template/etc used) 
      • Optional: provenance or lineage records 
      • Add field for required/expected to help with data status validation? 

Here is an example yaml file defining the structure

Here is an example notebook

XNAT impact: There are a couple of areas in XNAT that can be looked at for improvements →

  • Integration in the web interface → showing rich descriptions of the data structure
  • Data structure end-points in the API (e.g. Fair Data Point)
  • Built-in validation of data structure adherance
  • Enrichment of scan-type cleanup

Data model, Core XNAT or Plugin, FAIR

Persistent Identifiers using an Identifier Resolution Service

Proposed by @a user, Erasmus University Medical Center, The Netherlands

DescriptionType (Plugin, Script, External App)Contributors

For reliably referencing data on an XNAT instance from external sources, like a catalog or a publication or other data repositories in case we are dealing with linked data, we need to have globally unique, resolvable and persistent identifiers. When following the FAIR principles data and metadata need be referred to with a globally unique, resolvable and persistent identifiers anyway 😉. One of the ways to implement this, is by using an Identifier Resolution Service like or (Something like a DOI).

What: Discussion on how to implement a way to tie persistent identifiers to XNAT resources using a ID resolution service

Goal: To formulate a way/guidelines/roadmap to make data persistently identifiable on XNAT.

Possible XNAT impact:

  • Integration in the web interface
    • showing a persistent URI to the resources shown in the UI
    • Request a persistent URI to a resource
  • Request Persistent URI generation on a resource in the API
  • Ideally per project: configuration of Identifier Resolution service

Plugin, FAIR

Resource Usage Accounting

Proposed by @a user, Erasmus University Medical Center, The Netherlands

DescriptionType (Plugin, Script, External App)Contributors

When maintaining and running storage services using XNAT, accounting the resource usage is a hassle when you have multiple "customers"  on your XNAT instance. Usually the biggest resource consumption is storage (if you are not heavily using the container service to train AI models), but under the hood, the way the data is stored on disk is not organized in such a way that you can distinguish users from each other. Therefore we want to propose to implement a mechanism that will keep track of resource usage per: user, PI and project. Since XNAT is a data management platform, this opens up the possibility to add some key functionality like: billing overview, usage reporting, a quota system, etc.

There is a possible link or merge opportunity with XNAT management dashboard (What do you think @a user ?)

From @a user: I think this also overlaps some with the XNAT with alternate storage backends above.

What: Discussion on resource usage account in XNAT

Goal: To investigate how to implement a resource usaging accounting system in XNAT

Possible XNAT impact:

  • Integration in the web interface
    • Showing how much resources are used to the user
    • Showing an overview of the used resources by users, PI's and projects to site admins
  • Make the usage reports available via the API

Core XNAT or Plugin

DICOM Supplement 217 support in XNAT

Proposed by James Bowden, Department of Medical Informatics at the University Medical Center Göttingen

DescriptionType (Plugin, Script, External App)Contributors

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

XNAT Study Hall

Proposed by @a user, UCL

DescriptionType (Plugin, Script, External App)Contributors

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. 


XNAT Roadmap

Roadmap feedback form

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.