Use of a thin-section archive and enterprise 3-dimensional software for long-term storage of thin-slice CT data sets-a reviewers' response.

Current developments in storage solutions, PACS, and client-server systems allow for 3D imaging at the desktop. This can be achieved together with full storage into PACS of all slices, including the very large thin-section CT datasets. This paper describes a possible setup, which has been in operation for several years now, in response to an article by Meenan et al. previously published in this journal (1).

INTRODUCTION

In the article entitled Use of a Thin-Section Archive and Enterprise 3D Software for Long-Term Storage of Thin-Slice CT Datasets in a previous issue of the Journal of Digital Imaging,1 the authors describe their view of a set-up in which a separate thin-section archive is located at the 3-dimensional server.

The crippling effect on current Picture Archiving and Communication System (PACS) of the vast increase of data produced by the latest generation Computed Tomography (CT) devices is one of their major concerns. They state that many institutions were forced to devise strategies for handling thin-slice CT data besides their normal data flow. In their solution they also use this concept and only store the thin-slice data on a separate server with limited storage capacity.

The phased introduction of thin-slice CT data the authors propose is very interesting and provides a sound solution. At the University Medical Center Groningen, Groningen in the Netherlands, an approach has been adopted from the start right after the first multidetector CT (MDCT) was placed including one large PACS containing all data including the thin-slice CT data sets, a fully integrated 3D-server-based rendering system, and an enterprise webserver containing limited and nonpermanent data. This shows that phase 3 as stated by Meenan et al.1 could very well be the first step when one is able to employ the right tools.

OUR CURRENT SETUP

In one step, we went to full usage and storage of all available thin-slice data from our CT systems, which would correspond with phase 3 as proposed by Meenan et al.1 This means that every image acquired and reconstructed is actually stored on the PACS for review including all thin slices.

Currently, a ROX5 Picture Archiving and Communication System (PACS) (Rogan Delft, Veenendaal, The Netherlands) is installed at our department. This is an Everything On-Line (EOL) PACS with 21 TB of harddisk storage and 20 TB of near-line backup storage on two DVD jukeboxes. Remaining DVDs are now stored off-line, but transition to Ultra Density Optical (UDO) disks will be made soon providing a fully available near-line storage again. The EOL concept provides all data, including thin slices, on the direct available storage of the PACS. The near-line storage on DVD is purely for backup and security reasons and will not be accessed for retrieval in normal working conditions of the PACS.

Our 3D Server is an AquariusNET server (Tera-Recon, San Mateo, CA) with 0.7 TB of storage and two VolPro rendering boards and allows the 3D rendering of a maximum of 3,500 CT slices at once.

For distribution of patient image data throughout the hospital, an enterprise webserver is installed (Web-1000, Agfa, Belgium) with a short-term storage of 2 TB.

All CT modalities are configured such that they automatically reconstruct and store both thin-slice and thick-slice data sets and push them to the PACS.

Our router (RogROUTER, Rogan Delft, Veenendaal, The Netherlands) will automatically route the incoming data to different locations such as the institutional webserver. Only a series of less than 300 slices are stored in the institutional webserver, whereas all data, including thin-slices, are sent to the PACS (Fig. 1).

Fig 1

Data acquired by the CT scanner, including thin slices, are sent to the PACS through the ROUTER. All data are stored in the PACS and the near-line backup DVD. Through the AquariusNET, all this data are available. The institution-wide webserver only receives series below the threshold of 300 images per series.

PACS Viewer

Our PACS Viewer (HyperVIEW Pro, Rogan Delft, Veenendaal, The Netherlands) is a basic viewer, which has only functionality to visualize and manipulate images, either acquired or reconstructed results (secondary captures). No 3D reconstructions or reformations of the data are possible.

Post Processing Software Package

The thin-client post processing software used for integration into the radiological work stations is called AquariusNET (TeraRecon, San Mateo, CA). This is a commercially available, server-based solution, which brings interactive 3D rendering and manipulation to the physician’s desktop without the requirement of specialized hardware. The rendering is performed on the processing server: all data remain at the server (no transmission of large data sets throughout the hospital) and only the rendered and “manipulated” images are displayed in the client software at the radiological work station (Fig. 2). The central server can be managed and controlled locally through a secure, password protected webpage. After login to the server webpage, full control of the system is possible, even allowing a remote restart of the entire system.

Fig. 2

Schematic drawing of the set-up. At the work station two applications are running. The PACS viewer is used to access images, which are retrieved to the work station from the PACS using digital imaging and communication in medicine (DICOM) Query/Retrieve. The Thin-client postprocessing software thin-client application provides series information and user commands to the Thin-client postprocessing software server, which actively queries the PACS and renders the data. Only resulting images are transferred to the work station and results can be stored into the PACS as DICOM secondary capture. The interaction between the PACS viewer and the Thin-client postprocessing software thin-client application is established and information about the series, which should be retrieved, is communicated.

The integration of the standard PACS viewer and the thin-client post processing viewer was developed using a simple executable call from within the PACS viewer. With this call, the InstanceUID of the current series displayed in the PACS viewer is transmitted to the thin-client postprocessing viewer after which the same series is actively requested by the thin-client post processing viewer from the PACS through the post processing server (Fig. 2).

All integrations were established by the vendors of our PACS (RoganDelft, Veenendaal, The Netherlands) and the thin-client post processing software (Terarecon, San Mateo, CA).

Postprocessing results are not archived as a default, but upon request of the radiologist any image or image sequence can be stored in digital imaging and communication in medicine (DICOM) secondary capture format into the PACS system (Fig. 2).

Usage Evaluation

The system was evaluated by presenting a small questionnaire to our CT and MR radiologists. In this questionnaire the following questions were asked:

Are you using AquariusNET?

If yes, for which modality (CT/MR) and how often per day?

Has the use of AquariusNET increased the use of 3D in daily practice when compared with dedicated work stations in terms of

A lower threshold to use 3D

A higher frequency of 3D use

Do you still use dedicated 3D work stations? If yes, for what reason?

Which grade would you give on a 1–10 scale (in which 1 is very bad and 10 is very good) for

Ease of use

Quality of images/rendering

The results of the questionnaire were collected and evaluated using Excel (Microsoft Corporation, Redmond, WA, USA).

RESULTS

The Thin-client postprocessing software’s rendering capabilities are used by our radiologists both for magnetic resonance imaging (MRI) and CT. After the patient data acquisition is complete, the study is available on the main PACS archive within minutes. The radiologist can then retrieve the study from the PACS. Within one patient study, multiple acquisitions (series) can be present. The radiologist selects the series, which should be viewed in the Thin-client postprocessing software viewer in the PACS viewer window and (simply) presses the Thin-client postprocessing software button. Hereafter, the data are actively requested by the Thin-client postprocessing software server from the PACS and transferred. Within a very short time (if available on the Thin-client postprocessing software server <2 sec; if retrieved from the PACS < 2 min) the default 3D rendering and Multi Planar Reformation (MPR) is displayed for the selected data set.

Thirteen radiologists and residents filled out the questionnaire. Of these, 92% (n = 12) uses the postprocessing capabilities frequently and 8% (n = 1) uses it every now and then. Most respondents use it for CT only (69%), whereas the others use it for both CT and MR (31%). The mean of the usage results is 12 times per day, in which five of the respondents indicate that they use it for every CT study they read.

According to 92% (n = 12) of the respondents, the threshold for using 3D is graded lower and the frequency of use higher compared to using dedicated 3D (stand alone) work stations. The one remaining respondent did not fill out this question.

Dedicated 3D work stations are still used frequently by 38% (n = 5), rarely by 15% (n = 2), and never by 46% (n = 6). The main reason for using a dedicated 3D work station is to apply more specialized software packages (eg, MR mammography evaluation) or to use more enhanced capabilities (eg, better and more automated segmentation algorithms).

Both the ease of use and the 3D quality of the Thin-client post processing software were graded very high at 8 out of 10.

DISCUSSION

In the background portion, Meenan et al.1 pose a number of challenges of clinical use of thin-slice data sets.

First, the storage space required and cost-effective storage are mentioned.

In our experience, the storage of all data is easily possible as long as you are capable of purchasing your storage space cost-effectively without high markup of the PACS vendor because of the dedicated use of the storage space.

Second, network requirements are stated.

These requirements are high, but by having a dedicated radiology network segment with a 1-Gb/s network speed the storage of the data and review within radiology is not a problem. For 3D processing, the use of a Thin-client solution effectively decreases the required network bandwidth and the limitation to series with a maximum of 300 slices of the forward to the enterprise web-server further decreases the required bandwidth outside radiology. Furthermore, the transition of PACS viewers from thick to thin client solutions using wavelet compression techniques will further decrease the bandwidth requirements.

Third, workflow strategies for routing the data to the correct location are mentioned. The advantage of using one PACS storage system that includes all available data with a dedicated and fast network eliminates the requirement for workflow strategies. All data are available everywhere at any time with acceptable time to display.

The value of applying 3D rendering techniques to CT and MRI data has been described frequently. Although discussion has started on the integration of these techniques into the normal workflow, the main drawback of most current implementations remains that the rendering is performed on dedicated, stand alone, 3D work stations. Especially with the arrival of digital reporting, rendering must be integrated into the normal radiological workflow.

CONCLUSION

Using this set-up, the availability of thin-slice data sets is transparent to the users. Because all data are stored in one archive permanently and readily available everywhere, only one work station is required for both normal PACS viewing and advanced 3D viewing, and workflow strategies do not have to be implemented.