NEW ORLEANS - Any computer user who has wrestled with plug-and-play hardware that wasn't knows that adding peripherals can be frustrating. When it comes to bringing a PET/CT onto a PACS network, system administrators often face integration gymnastics worthy of an Olympic athlete, according to a poster presentation at the Society of Nuclear Medicine meeting.
In the study, Technical Considerations Integrating PET/CT into a Traditional PACS Environment, written by Jeffrey Leal and Dr. Richard Wahl of the Johns Hopkins Medical Institute in Baltimore, the authors detailed PACS integration efforts with a GE Medical Systems (Waukesha, WI) Discovery LS PET/CT scanner.
"Interoperability of PET/CT image data between different vendor’s equipment was less than desirable even though all systems were DICOM 3.0-compliant," the researchers wrote.
Their first system evaluation was with the department’s current enterprise PACS configuration by Siemens Medical Solutions of Malvern, PA. They reported configuration issues with their MagicStore archive due to differing DICOM settings that the vendors chose for their systems. They also noted a performance barrier with the archive in that it only allowed four simultaneous connections, which limited bandwidth.
"We found that requesting a PET/CT study from the archive was equivalent to requesting three or more studies, depending on the protocol," they wrote.
Leal and Wahl added that the archive queue was configured to distribute the load between requests, which resulted in times during the day when an ad hoc request for PET/CT images could take 30 minutes or more to complete. Archive performance problems were not the only issue the researchers faced: their Siemens MagicView workstations failed to properly load and display the GE PET/CT images.
"First we learned that it expected a different DICOM field to interpret image order with respect to PET data than the GE PET/CT system encoded," they wrote. "This led to an interesting phenomenon where images were displayed in the order they came off the reconstruction engine rather than their order in the spatial domain. In addition, the MagicView did not properly decode image pixels, apparently ignoring the DICOM fields rescale intercept <0028, 1052> and rescale slope <0028, 1053> when interpreting these values."
The pair then set out to modify a GE Entegra PET/CT workstation (the primary clinical review and analysis workstation for the Discovery LS) to be a server-class machine to handle archiving tasks for the PET/CT images. They created a dual-processor configuration (2 866 Mhz Intel Pentium III processors) with 2 GB of RAM and 360 GB of RAID Level 5 near-term storage. The system worked well, but problems with the software architecture of the core workstation and the DICOM and communication subsystems prevented it from being used for a long-term solution, they wrote.
"Neither subsystem was optimized for multiuser operations. While the multiprocessor hardware systems provided some relief for these core systems (by distributing the different processes between processors), we discovered that if four or more concurrent requests for data transfer were initiated by our users that system integrity would become unstable," they reported.
The third system solution Leal and Wahl attempted was with a GE Radworks archive and workstation. They wrote that the same initial configuration issues that plagued the MagicView archive were present in the GE Radworks archive.
They noted that the Radworks archive was configurable for multiple simultaneous DICOM connections (which permitted multiple simultaneous users) and that it accepted parallel simultaneous DICOM associations with a single client (permitting multiple simultaneous requests from a single user). However, all was not sanguine with PET/CT data on the GE archive.
"There are two system features that are less than optimal for PET/CT data sets," they wrote. "First, each client registered workstation can be individually configured for optimal network performance. Unfortunately, this configuration may be different depending on the modality (PET or CT) being transferred at any one time. Second, autorouting works on the study level and not the series level. A typical PET/CT study might have multiple CT series and PET series dependent on the protocol."
The Radworks workstation, like the MagicView workstation, did not interpret the PET/CT data in a manner acceptable to the researchers.
"The Radworks workstation handled PET data only slightly better than the Siemens MagicView. While it loaded and displayed PET data in the proper spatial sequence, like the MagicView, it failed to properly interpret the image pixels," wrote Leal and Wahl.
Fusion imaging, with its multimodality datasets, poses a challenge for PACS designers used to creating slice-based storage architecture. PET/CT data, with its multiple slice data sets used to visualize each tomographic plane, can strain archive resources. And clear interpretation of these data sets at a conventional PACS workstation needs to take place to bring the modality fully onto the enterprise system.
But before work on new software architecture can begin, a standard needs to be in place, noted Leal and Wahl.
"The lack of an appropriate DICOM specification for PET/CT image sets inhibits the production of a general-purpose PACS workstation which has adequate fusion imaging clinical review functionality," they wrote.
By Jonathan S. Batchelor
AuntMinnie.com staff writer
June 25, 2003
Related Reading
Smoothing the transition to filmless, June 16, 2003
Switching PACS vendors tricky, but doable, June 12, 2003
RIS/PACS integration -- what is it and what are its benefits?, June 6, 2003
Copyright © 2003 AuntMinnie.com
