Overview

 Introduction

Although formally called “Framework”, Yarra is rather a collection of software tools to support the development and clinical translation of novel reconstruction techniques for magnetic resonance imaging (MRI). These tools can be used synergistically together, but it’s also possible use only individual components in a stand-alone manner.

The functional scope ranges from automatic collection of clinical raw-data (as needed when developing new algorithms), management and anonymization of raw-data (as needed when collecting large amounts of raw-data), clinical integration of reconstruction prototypes (as needed when evaluating new techniques clinically), and distribution of reconstruction algorithms (as needed when disseminating new techniques for multi-institutional evaluation). Moreover, Yarra provides powerful functions for clinical workflow monitoring and analysis (as needed when validating the clinical efficiency of a new technique).

Currently, support is limited to Siemens MRI systems, but we hope to extend the support to other vendors in the future. Yarra is free to use and based only on open-source software libraries. A central component of Yarra is its Offline Reconstruction Pipeline, which has enabled us in our research work to evaluate computationally demanding compressed-sensing algorithms on a large scale in routine clinical practice.

 Offline-Reconstruction Pipeline

Prerequisites

To use the Yarra for automating offline reconstructions, it is necessary to install a powerful Linux reconstruction server that runs the YarraServer software. The required system configuration depends mainly on the individual reconstruction technique that should be employed. The only requirement from the Yarra-side is that the server needs to run the Ubuntu 16.04 or 18.04 operating system, which has been defined as common platform (it might run on other Linux distributions as well, but has not been tested). In our lab, we run YarraServers on 32-core Intel Xeon servers with 256 GB RAM, but the framework runs also on less powerful servers or on virtual machines. The server needs to be connected to the same network as the host computers of the MRI systems, so that a network connection can be established from the MRI system to the server. Furthermore, it is necessary to install the Yarra client software on all MRI systems where offline reconstructions should be scheduled.

Reconstruction Modes

Each scan (i.e. “Twix” raw-data file) that should be reconstructed needs to be assigned to a Reconstruction Mode. The reconstruction mode defines what reconstruction technique should be used to process the data (i.e. which reconstruction module should be executed, e.g. GRASP), and it also defines the reconstruction parameters. In addition, it can define:

• Optional pre- and post-processing steps, executed before/after calling the reconstruction module
• What should be done with the reconstructed images (e.g., send to PACS)
• A list of people that should be notified on completion or errors
• Additional options, e.g. if the submitted data file should be kept after the reconstruction

Reconstruction modes are centrally defined on the Yarra server. The list of available reconstruction modes is read by the Yarra client when the client is launched. Usually, a separate reconstruction mode is defined for each clinical application (e.g., GRASP prostate scan, GRASP liver scan, etc.). Sometimes, it is necessary to define separate reconstruction modes also for different MRI scanners if the reconstruction parameters depend on the type of scanners (e.g., due to different field strength, different coil configuration etc.).

Mode Assignment

The reconstruction mode for a scan is defined when the scan data is submitted to the server by the Yarra client software (the Yarra client internally creates a .task file for this purpose that contains the selected mode). To simplify the workflow, the Yarra client tries to automatically select the correct reconstruction mode based on the name of the scan protocol that was used to acquire the data. To enable this assignment, each reconstruction mode must define a unique Protocol Tag. The protocol tag is a short string of several characters, e.g. _YGP for a GRASP prostate scan. If the client finds this string in the protocol name (e.g. “DYNAMIC AXIAL_YGP”), it will assign “GRASP prostate” as reconstruction mode. The YarraServer will then launch the GRASP reconstruction module with the parameters that were defined in the reconstruction-mode file. If a scan has been performed with missing or incorrect protocol tag, it is possible to overwrite the automatic assignment and to manually select the desired reconstruction mode.

Task Processing

Reconstruction tasks that are submitted to the server are queued according to the submission time and processed sequentially on a first-come first-served basis (it is also possible to assign high or low priority to individual tasks). Only one reconstruction will be performed at the same time in order to keep the development of reconstruction modules simple. Thus, reconstruction modules are requested to make best use of all available hardware resources of the server and to process the task in fastest possible time.

A reconstruction mode can include one or multiple (up to 20) pre-processing steps, the reconstruction itself, one or multiple post-processing steps (up to 20), and finally a transfer step. What modules are executed for each of these processing steps is defined in the mode file on the YarraServer. Reconstruction modules are expected to read the measurement data from the provided TWIX file (Siemens raw data format) and to create images preferably in the DICOM format. However, it is not a strict requirement that the created images need to be in the DICOM format. Typically, the reconstructed images are in the end either send to PACS or stored on a drive/network share. Because the destination for the storage of the results is defined in the mode file, varying settings can be selected for the different reconstruction modes (e.g., one mode can send the images to a PACS whereas another mode might send the images to a DICOM workstation).

Notifications and WebGUI

Yarra has a notification system that informs users who submitted a reconstruction task on the completion or failure of the task. Notifications are sent via email. In case of a failure notification, the email contains the log file of the task in the attachment, which makes it easy to identify the error cause. Notifications can be requested during submission of tasks in the Yarra client or can also be defined permanently in the configuration file of the reconstruction mode (e.g., to inform project managers about the case volume etc.). It is also possible to define global recipients for all error notifications (e.g., to inform system administrators).

To support the monitoring of tasks and server activity and to control the server, Yarra provides a web-based graphical user interface, which can be installed on the YarraServer as optional module. The Yarra WebGUI has a login-system with different user levels. Users with the lowest access level can only view the queue of scheduled tasks. Users with mid access level can also modify or cancel reconstruction tasks, and they can restart tasks that previously failed. Users with highest access level can additionally start and stop the server and make changes to the YarraServer configuration (the latter can also be disabled).