qMRI-BIDS: an extension to the brain imaging data structure for quantitative magnetic resonance imaging data

A new BIDS common principle: entity-linked file collections

The majority of qMRI methods necessitate the grouping of a set of similar images where specific acquisition parameters are carefully varied. Furthermore, the images that are collected for qMRI application do not usually have a clear “weighting” description (e.g., T1w, T2w), like conventional structural images. The novel concept of file collections decouples the semantics of logical group identification from contrast weighting labels or acquisition sequence names that are not originally developed for qMRI (e.g., FLASH). Instead, suffixes for such logical units may indicate a generic MRI readout type (e.g., multi-echo gradient echo: MEGRE), a qMRI sequence name (e.g, magnetization prepared two rapid gradient echoes, MP2RAGE) or a qMRI data collection framework (e.g., variable flip angle, VFA). Table-1 lists file collection suffixes for various qMRI and fieldmap data, and the quantitative parameters they can derive. These suffixes span a wide range of qMRI applications including relaxometry, MT imaging, multiparametric mapping, and RF field mapping. Application scope can be extended without necessarily adding more suffixes. The BIDS qMRI appendix presents a set of rules and suggestions to add new qMRI suffixes to the specification (https://bids-specification.readthedocs.io/en/stable/99-appendices/11-qmri.html).

Note that the use of file collections is not exclusive to qMRI, anatomy imaging data, or even MRI. Any imaging modality calling for a file grouping logic to define a quantitative or qualitative application can benefit from this principle by specifying a descriptive suffix and filename entity. Such changes would require additional BIDS extensions to create a valid file collection.

To distinguish individual files of a file collection, we introduced filename entities that are associated with commonly altered acquisition parameters (e.g., flip angle) or with inherent components of the same data (e.g., phase information), hence the name “entity-linked file collection” (Table-2).

It is important to highlight that these entities cannot store acquisition parameter values in the filename, but can only index or categorize them. Respective parameter values are stored in so-called “sidecar JSON”-files. Requirement level of these entities in relation to file collections are presented in the BIDS entity table appendix (https://bids-specification.readthedocs.io/en/stable/99-appendices/04-entity-table.html).

Data organization for qMRI file collections and quantitative parametric maps

By combining entities in the filename that represent different acquisition parameters (Table-2) with entity-linked file collection suffixes (Table-1), BEP001 provides an intuitive way to organize filenames of most existing qMRI data. For example, raw data from MP2RAGE acquisitions comprises both magnitude and phase reconstructed images, acquired at two successive inversion times (Fig-1a). The respective file collection for MP2RAGE (Fig-1c) clearly defines these components via part and inv-components, which are required for the MP2RAGE file collection. Note how the BIDS inheritance-rules do allow for using a single JSON-file to describe both phase- and magnitude-images, since these have identical acquisition parameters. In addition, the same collection suffix can be extended to specify its multi-echo variant⁴⁵ using the echo entity, which is made optional to MP2RAGE. For clarity, these specific use cases are defined in the BIDS qMRI appendix.

• Download figure
• Open in new tab

Figure-1

a) Schematic of BIDS formatted raw quantitative MRI (qMRI) data representing MP2RAGE (anat) and TB1DAM (fmap) file collections, for which entity-linked metadata fields are highlighted for the InversionTime (yellow), the FlipAngle (purple) and for the reconstructed image type (cyan). b) Derivatives of MP2RAGE and TB1DAM file collections generated by using pymp2rage and qMRLab to calculate T1 and B1+ maps, respectively, including a vendor-native derivative of UNIT1 images. c) File organization of raw qMRI data for MP2RAGE and TB1DAM file collections, where respective linking entities are highlighted for the inv entity (yellow, InversionTime), the flip entity (purple, FlipAngle) and the part entity (cyan, magnitude/phase). d) File organization of qMRI derivatives indicating how sidecar JSON files of quantitative maps generated by open-source software keeps a log of the input files (the BasedOn field) and associated acquisition parameters (FlipAngle in TB1map and InversionTime in B1map).

The same logic applies to the raw images of double-angle B1+ mapping, identified by the TB1DAM suffix (Fig-1c). In this case, the maximum value of the flip entity indicates that the data is collected over two flip angles. We recognize that an alternative approach to organize such data is stacking images at each flip angle into the 4th dimension of a Nifti-file, and storing the corresponding metadata in vector form using a single JSONfile. This approach offers a less crowded file list for this particular example. However, indexing acquisition parameter dependent variations across additional dimensions is less favorable for comprehensive qMRI methods. For example, MPM collects raw data at different echo times, flip angles and MT preparations with the option of phase reconstruction. After extended debates that took more than a year, the qMRI-BIDS extension group ultimately concluded that this approach is less favourable for human-readability of qMRI datasets, especially for multiparametric acquisition methods where the number of images per protocol can go into the dozens.

Metadata requirements for file collections and quantitative parametric maps

For the file collections, linking entities (Table-2) indicate a requirement for the respective acquisition parameters that are subject to change from image-to-image. Therefore, the entity table appendix lists such parameters as required in relation to the corresponding file collection suffix based on the descriptions made in the BIDS schema. Note that not all the parameters that change across file collection images are captured by a linking entity, but may still be required for data fitting. For example, the value of the FlipAngle parameter might (but does not necessarily) covary with that of InversionTime between MP2RAGE file pairs; however, the filenames are distinguished solely by the inv entity (since that is the crucial parameter that is swept over, whereas the flip angle could in principle remain the same). In addition, certain parameters that are constant across file collection images may be required as well. For example, RepetitionTimeExcitation and RepetitionTimePreparation are required metadata for an MP2RAGE acquisition. Such parameters are required when they are strictly necessary to calculate the qMRI-maps that a specific acquisition scheme was designed to obtain; e.g., a T1-map in case of MP2RAGE. BEP001 added an array of new metadata fields that may be required for certain file collections (e.g. MTState, specifying whether an MT preparation is enabled in an MPM acquisition, associated with the mt linking entity) or provide supporting information (e.g., SpoilingRFPhaseIncrement, specifying the amount of incrementation applied to the phase of an excitation pulse). The complete list of metadata fields and their requirement levels for all the qMRI file-collections are included in the BIDS release v1.5.0 and later. Currently, metadata conversions for some of these required fields have been implemented in dcm2niix⁴⁶, a commonly used DICOM to NIfTI converter to create BIDS-compatible datasets.

Certain quantitative parameters cannot be interpreted in absence of fundamental scanner specifications. For example, to interpret relaxometry maps (e.g., T1map), the magnetic field strength must be known. The BEP001 ensures that such requirements are met (again, see the qMRI Appendix in BIDS release v1.5.0 and later). Moreover, sidecar JSON files of quantitative maps contain all the metadata values involved in the fitting by representing varying parameters in vector form and inheriting the constant ones from the raw images. To supplement the provenance recording of parameter estimation process with software-relevant details, the derived dataset and pipeline rules are respected as outlined in the modality agnostic files section of the main specification.

Finally, the units and range of the fitted parameters have been standardized by BEP001 to define interchangeable qMRI maps. For relaxometry-based parameters (e.g., T1map or T2map), the time is described in seconds and the rate in reciprocal seconds or Hz. Wherever applicable, unitless ratio maps are described in percentage (e.g., MTRmap or MWFmap). For quantitative susceptibility maps (i.e., Chimap) the local magnetic susceptibility is represented in parts per million. The RF transmit maps (i.e., TB1map) are specified in relative percentage units, where 100% denotes the ideal case (i.e., measured flip angle equals the nominal value). Any deviations from 100% convey proportional deviations from the intended field strength. Please note that certain quantitative parameters are described in arbitrary units, where the acceptable range of values vary based on the target anatomy (e.g., MTsat).

Community software and the role of BIDS in standardizing qMRI

As of release v1.5.0, the BIDS validator can perform on BEP001-compatible qMRI data at the directory and filename level rules, based on the entity requirement levels specified per file collection suffix. However, metadata-level validation rules have not been implemented yet. This is mainly because multi-vendor extraction of qMRI related metadata fields (e.g., MTState or RepetitionTimePreparation) is not supported by commonly used converters. Recently, we started working with dcm2niix⁴⁶ and BIDSme (https://github.com/CyclotronResearchCentre/bidsme) developers to identify and map vendor-specific header information to BEP001-compatible metadata.

Nevertheless, some metadata entities that are of profound importance to the accuracy of quantitative maps cannot be typically found in the vendor-native DICOM headers. For example, the BIDS fields of RFSpoilingPhaseIncrement and SpoilingGradientMoment are two major determinants of T1 and B1+ estimation accuracy using spoiled gradient echo based applications⁴⁷. Although this information is not provided by vendors, open-source pulse sequence development frameworks such as Pulseq⁴⁸, PyPulseq⁴⁹, Gammastar⁵⁰, TOPPE⁵¹, SequenceTree⁵², ODIN⁵³ and RTHawk⁵⁴ can make a qMRI-tailored metadata annotation possible. An example implementation is qMRPullseq, a collection of publicly available vendor-neutral pulse sequences that are designed to export images in accordance with BEP001 format without hidden acquisition parameters⁵⁵. We highly encourage open-source MRI pulse sequence developers to use and contribute to the qMRI metadata annotations. This simple consensus can remove proprietary roadblocks from disseminating qMRI datasets that incorporate key information on the reproducibility of data acquisition.

Most qMRI methods can benefit from a plethora of BIDS applications⁴ to prepare data for parameter estimation and downstream statistical analyses. There are several open-source tools emerging to perform qMRI fitting at multiple levels, like the hMRI-toolbox⁵⁶, qMRLab⁵⁵, QUIT⁵⁷, PyQMRI⁵⁸, QMRTools⁵⁹, mrQ⁶⁰, Madym⁶¹, MITK-ModelFit ⁶², ROCKETSHIP⁶³, DCEMRI.jl⁶⁴ and DCE@urLAB⁶⁵. Giving these tools the ability to operate on BIDS formatted data is an important step towards establishing interoperable qMRI processing pipelines.

Community-driven development of BEP001

The development history of BEP001 spanned nearly 5 years. This extension was initiated following mailing list discussions about standardizing MP2RAGE³² datasets and including multi-echo MRI acquisitions in late 2016 (https://bit.ly/bids_mailing). These discussions revealed that BIDS was still lacking a generic convention for specifying structural acquisitions yielding multiple contrasts. In the summer of 2018, meeting were held to hear concerns and questions from interested participants and to set an action plan for the development during the annual INCF NeuroInformatics conference in Montréal/Canada (http://www.neuroinformatics2018.org/) and the OHBM meeting in Singapore (https://www.humanbrainmapping.org/i4a/pages/index.cfm?pageID=3821). As a first action, a joint-community meeting was organized between MRI and neuroimaging scientists on 4 October 2018 (https://www.ismrm.org/virtual-meetings/virtual-meetings-archive/), where a consensus decision was made on extending the specification for a variety of qMRI methods. After this meeting, a standard operational procedure was established and followed to advance the proposal, focusing on both transparency and accessibility to other researchers (Fig. 2).

• Download figure
• Open in new tab

Figure-2

Summary of the standard operational procedure for improving BEP001. Outcomes from the monthly meetings (a) are transferred to a central GitHub repository, opened for more elaborate public discussions via issues and merged into the proposal through peer-reviewed pull requests (b). BEP001 is inclusive to all communities who would like to contribute to the proposal or keep themselves up-to-date with the latest developments.

Interim outcomes from the development were presented in the 2020 annual conferences of OHBM⁷¹ and ISMRM⁷² to reach out more neuroimaging and MRI physics researchers, respectively. Following another year of development on the specification, example datasets and applications, BIDS incorporated and released BEP001 as part of their version 1.5.0. The main problems identified and resolved during the development are outlined in the following section, laying out the methodology of how qMRI can be incorporated into BIDS.

Extending an existing standard for new use cases

BIDS traditionally focused on conventional anatomical images that are collected in functional MRI experiments and whose contrast characteristics are well-defined (i.e., mostly T1-weighted images). This posed a challenge for the naming scheme of collections of multimodal images used in qMRI. Unlike conventional structural data, qMRI inputs are usually formed by collections of images where specific acquisition parameters are systematically manipulated. Moreover, the line separating contrast characteristics between these images is blurred. A concrete example: in a multi-echo GRE acquisition with a long TRs, early echoes will be mostly PD- and B1+/B1-signal-weighted, whereas later echoes will be increasingly T2*-weighted. Most echoes will show a contrast that is the result of a mixture of underlying physical properties. This ambiguity disqualifies MRI weightings (e.g., T1w or T2starw) as suffix labels to specify interchangeable qMRI datasets. The use of often proprietary acquisition sequence names like “FLASH’’ (fast low angle shot) or “GRE” (gradient-recalled echo) as a suffix turned out to also be undesirable, because different MRI vendors use different naming conventions and, moreover, one type of sequence can often be used for numerous qMRI applications. To address this problem, BEP001 introduced a new common principle: file collections.

A second challenge that BEP001 addressed pertains to standardizing the data organisation of quantitative parametric maps. One central challenge of such maps is that the calculations on which they are based can be made both by proprietary vendor software run on the scanner system, or offline using open-source workflows. The resultant map can be described as derivative data in either case, yet the former lacks provenance of the whole calculation process and may not export the raw inputs to the calculation.