From raw data to data-analysis for magnetic resonance spectroscopy--the missing link: jMRUI2XML

Abstract

Background: Magnetic resonance spectroscopy provides metabolic information about living tissues in a non-invasive way. However, there are only few multi-centre clinical studies, mostly performed on a single scanner model or data format, as there is no flexible way of documenting and exchanging processed magnetic resonance spectroscopy data in digital format. This is because the DICOM standard for spectroscopy deals with unprocessed data. This paper proposes a plugin tool developed for jMRUI, namely jMRUI2XML, to tackle the latter limitation. jMRUI is a software tool for magnetic resonance spectroscopy data processing that is widely used in the magnetic resonance spectroscopy community and has evolved into a plugin platform allowing for implementation of novel features.

Results: jMRUI2XML is a Java solution that facilitates common preprocessing of magnetic resonance spectroscopy data across multiple scanners. Its main characteristics are: 1) it automates magnetic resonance spectroscopy preprocessing, and 2) it can be a platform for outputting exchangeable magnetic resonance spectroscopy data. The plugin works with any kind of data that can be opened by jMRUI and outputs in extensible markup language format. Data processing templates can be generated and saved for later use. The output format opens the way for easy data sharing- due to the documentation of the preprocessing parameters and the intrinsic anonymization--for example for performing pattern recognition analysis on multicentre/multi-manufacturer magnetic resonance spectroscopy data.

Conclusions: jMRUI2XML provides a self-contained and self-descriptive format accounting for the most relevant information needed for exchanging magnetic resonance spectroscopy data in digital form, as well as for automating its processing. This allows for tracking the procedures the data has undergone, which makes the proposed tool especially useful when performing pattern recognition analysis. Moreover, this work constitutes a first proposal for a minimum amount of information that should accompany any magnetic resonance processed spectrum, towards the goal of achieving better transferability of magnetic resonance spectroscopy studies.

Fig. 1

The jMRUI2XML interface with the Pre-processing tab in foreground. The users may select which steps to apply to the spectrum by ticking the ones they are interested in. The steps are performed in the order of their roman numbering –the lower numbers get performed first

Fig. 2

Spectra preprocessed using jMRUI2XML (visualized in jMRUI). a An example of a SV spectrum that underwent all the possible steps provided in the jMRUI2XML pipeline (see Fig. 1 for parameters used). b The spectral MV grid (left) and the reference image showing where the MV was recorded (right). The MV grid has undergone the same steps ([11]) as in a)

Fig. 3

The Meta Data tab. Example of usage where the user wants to store that the spectrum was manually phased and multiplied by a scalar (100) available through the jMRUI main menu, after going through the jMRUI2XMLs preprocessing pipeline

Fig. 4

The LabelsMV tab. It is in this tab where each individual voxel can be assigned the desired label. In this case please note that the voxels that are overlaid to the abnormal tissue have been labelled by the user with “t” whereas the rest are left with the default label “***”

Fig. 5

Structure of the DATASET node. The root node, DATASET, has two children: the Preprocessing node and either a Voxel node or a Grid node. The Preprocessing node will encompass the preprocessing history that was performed using jMRUI2XML. The Voxel node contains the actual data, and the Grid node may contain multiple Voxel nodes

Fig. 6

Structure of the Preprocessing node. This node may contain all the preprocessing steps that were performed using jMRUI2XML. The dashed lines mean that a node is optional; absence of a node indicates that the corresponding step was not performed by jMRUI2XML. Note that only the AdditionalInformation node is always required along with the Name and Place sub-nodes

Fig. 7

Structure of the Voxel node. In case of a SV this node holds the preprocessed data, along with various details about it

Fig. 8

Structure of a Grid node. This node will hold MV data and it comprises of multiple Voxel nodes similar to the previous but with three extra attributes. These are meant to account for a voxel’s position in the grid