Looking for best way to store ROIs and corresponding clinical data

[Christoph Haarburger]

Dear XNAT community,

I am new to xnat and we are considering it for storing MR images, tumor ROIs and corresponding clinical data. So far, our images are saved as DICOM frames, ROIs as Nifti files and clinical data is stored in an excel/csv file.

I am currently trying to figure out the best way to transfer our current data into our running XNAT installation. However, I am a bit overwhelmed by the XNATs flexibility and huge choice of options..

1. What is the best representation for ROIs? I’ve seen people upload Nifti files as resources in XNAT, which consumes a lot of space. Does XNAT support DICOM Segmentation IOD such as created in this example [1] ?
   
2. What is the best way to store clinical information that corresponds to ROIs (histological information from biopsies corresponding to tumor ROIs; represented as strings, integers, floats). Potentially, we have multiple instances of these per Scan. Should we create a new XML xsd schema file similar to [2] or is this functionality already covered by built-in data types? 
3. Under "Administer" -> "Setup additional data type" I can choose from dozens of data types. Where can I find a documentation for these?

Thank you in advance!

Chris

[1] https://pieper.github.io/dcmjs/examples/createSegmentation/index.html

[2] https://bitbucket.org/hcp/new-radiology-read-plugin/src/master/src/main/resources/schemas/newRadRead/newRadRead.xsd

[Simon Doran]

Hi Chris,

  The team at the Institute of Cancer Research, London has been working for some time on a coherent method of representing regions-of-interest within XNAT. This was a project that we brought forward at the Rotterdam XNAT Developer Workshop last year and we have since been collaborating closely with Dan's group at WashU. The work is also tightly coupled with our work in integrating the OHIF viewer into XNAT, and James Petts in my team is playing a very active role in the OHIF open-source development group.

  Regarding your specific questions:

1. ROIs can, as you have noted, be represented using many different formats. Possibly the biggest distinction is between formats that are contour-based and those that represent the ROI via a mask or label-map. The first category is very suited to ROIs that are obtained by observers manually drawing round tumours, for example, and also fits very well with radiotherapy workflows that use DICOM RT-STRUCT files to store ROIs. By contrast, mask-based formats are better suited for discontinuous regions of the sort that are often produced by machine-learning segmentations. These ROIs are typically stored as NIFTI or DICOM-SEG files. We aim to support both of these classes of ROI within XNAT.

Because ROIs are the result of processing that has been performed on images, there is a strong argument that (even if they are DICOM files and imported into XNAT at the same time as raw data, say using XNAT's DICOM receiver), they should not be treated in the same way as other DICOM images (i.e., they aren't "scan data" in XNAT parlance). Instead, our framework will treat ROIs as XNAT assessors. When a user uploads ROI data to XNAT, the system will create an assessor, associated with an imaging session, with the original data file as one of its resources.

Assessors are elements in the XNAT schema and, as such, their metadata is captured in XNAT's Postgres database. This means that one will be able to search for ROIs in the same way as for other elements of the schema (subjects, imaging sessions, scans, etc.).

Our beta software (which will be delivered via an XNAT 1.7 plugin) currently deals with contour-based ROIs, for which we have an uploader that supports RT-STRUCT and NCI's Annotation and Image Markup (AIM) standard. We are currently working on support for mask-based formats, explicitly including DICOM-SEG and NIFTI. The plugin also includes a new-style XNAT 1.7 REST API (xapi), which will provide server-side code accessed via REST calls to upload ROIs and convert between different formats. Thus, end users will be able to use their favourite toolkits (scripts, Python, Java, C++, etc.) to automate upload, querying and download of ROIs within the XNAT ecosystem.

2. A second aspect of the work that we are planning to deliver is the facility to save annotations created within the viewer and to add relevant clinical information. Our proposed route is to create more complex XNAT assessors that map to annotation specifications created with the AIM Template Builder. This work hasn't yet got underway formally, but we need to deliver this for a grant that has just started and our roadmap is to try and get this out by the end of the year.

3. Regarding the documentation of the various datatypes, I'll refer you to the team at WashU. I'm not sure whether there is a web page listing everything in exactly the way you are looking for. However, there is quite a bit of information out there if you have the time to Google for it systematically.

  Best wishes,

Simon 

  

[Christoph Haarburger]

Hi Simon,

thank you for your detailed and helpful answer! 

We decided to save ROIs as NFITI files (XNAT resources) and individual lesions as assessors. That's probably not exactly how assessors are meant to be used but suits our needs for now. Your software sounds indeed very interesting for our use case. Do you have a specific release date planned? I'd be very interested to test it.

Best regards,

Chris

[Simon Doran]

Hi Chris,

  A relatively recent version of the beta software is already "out there" as open-source code to browse. The idea is to install both of these plugins, because the parts of the viewer that handle ROIs use modifications to the XNAT schema and the REST API that are introduced by the ROI plugin.

https://github.com/JamesAPetts/ohif-viewer-XNAT-plugin

https://bitbucket.org/icrimaginginformatics/xnat-roi-plugin

  However, I would strongly recommend waiting a few more months before testing, because this code is in active development and we are introducing new features on a weekly basis. We would also strongly advise that you don't install these plugins on production instances of XNAT until we announce a formal release.

  Note: the new software works only on XNAT 1.7 and upwards that support the new plugin architecture.

  Best wishes,

Simon

[Bing Zhu]

Thanks Chris and Simon for discussion thread.

I have been running two segmentation algorithms as pipelines for brain tumor and spine tumor in the XNAT instance here and have also been facing the same design/integration questions. 

The output of the programs is in NIFTI format and, for each session, the result ROIs are not just for a single frame but for a cluster of images. In this case, segmentation results are stored as a new resource(s) for each session as the session/study level annotation. There are other data elements (computed results such as tumor volume) that I wish to store as metadata in the session/study level. Your idea of using assessors is excellent.

Regards,

Bing Zhu

UCLA