LucasFeedback from readers is the lifeblood of any publication. Medical Imaging is no different, which is why I’m thanking you for writing to us. It really is great to hear your comments and questions.

I take all of your communication seriously and strive to answer everyone. I plan to do so in future issues with more in-depth coverage—such as tackling Robert Ward’s recent email about eBay adding medical imaging equipment to the auction block (a piece covered in the “News Watch” section of our April issue). Ward, who is a service manager for Simons X-Ray Corp (Salt Lake City), is concerned that these new listings will be taking money away from service companies rather than creating additional business. This topic is definitely worthy of further investigation.

Some of your letters, however, I’ll address right here, starting with an email I received from Karen Worlidge, MRT(R), a senior technologist of systems at Halton Healthcare Services Corp (Oakville, Ontario). She was inspired to write after reading “Slice by Slice,” an article in our April issue highlighting the latest advances in multislice CT—specifically 64-slice technology, which was recently cleared by the FDA for both Siemens Medical Solutions and GE Healthcare. Worlidge had several interesting questions about 64-slice CT, which, along with a few of my own, I asked of Professor Werner Bautz, MD, the director of the Institute of Diagnostic Radiology at the Friedrich-Alexander University Erlangen-Nuremberg in Germany. The Institute is the first site to receive a Somatom Sensation 64, which was installed in April. It’s a precommercial version of the system, since shipments to customers don’t begin until November.

I asked Bautz about the size of data sets that will be handled with 64 slices, and he explained that two aspects must be considered—the acquisition of the finest scan data itself and the actual generation of diagnostic images. “The combination of the 0.4 submillimeter imaging and 0.37 seconds rotation time allows us to routinely use high resolution, even for large scan ranges, resulting in more raw data,” he said. “The scanner’s software allows us to generate images in any desired planes. Similar to MR, as part of the standard scan protocol, we can generate sagittal, coronal, or double-oblique diagnostic images with full resolution without the need to store thin-slice data. The scanner allows us to use 64-slice capabilities of increased detail with the finest 0.4-mm isotropic voxels while decreasing the axial data set size compared to a 16-slice CT.”

Along the same lines, what effect will there be on PACS with 64 slices? Bautz said that the immediate availability of images in a desired slice plane reduces the amount of individual data produced by up to a factor of 10, and the facility has integrated multiplane images into its standard routine. “Instead of archiving all thin-slice axial images in our PACS, we are starting to store MPR [multiplanar reformation] slices and thick axial slice reconstructions that are necessary for diagnosis,” he said. “Compared to our 16-slice CT scanner, we’ve observed no increase in data stored in our PACS.”

Finally, I asked Bautz about productivity efficiencies that have been gained since the installation, and his answer was nothing but positive. “Last week, we examined a patient with chest pain of unclear origin,” he said. “It was possible to examine both the heart and lung in one scan for exclusion of pulmonary embolism or aortic dissection and in search for coronary artery stenosis. The patient needed to hold his breath just once for less than 20 seconds. This short time was sufficient for an ECG-gated scan of the complete thorax. After the acquisition, we could analyze the scanned data for several possible causes of chest pain.”

To Worlidge, I thank you for your questions and wish you the best on your upcoming PACS implementation and CT scanner acquisition. And to the rest of you, keep those letters coming. As the editor of Medical Imaging, I endeavor to keep you informed in this profession, even beyond each month’s issue.

d_lucas_sig.gif (1723 bytes)