My PET/CT Experience: Adding a New Modality to PACS

It was a Tuesday afternoon when I received the call. The new PET/CT scanner was installed, and acceptance testing was about to begin, but my medical physicist informed me that PACS was not listed as a destination. The installation team had not configured the scanner to communicate with PACS. Not too concerned, I asked to speak with the modality vendor’s field service engineer (FSE), who was working on-site. A sinking feeling set in as I learned that he was new to the company, and that he did not know how to set up DICOM. The first question posed by the FSE was whether we had purchased the required licenses for the DICOM services that I was requesting. Confidently, I replied, “Yes.” My purchasing agent had called me during the contracting phase to ask what requirements needed to be included for PACS. I provided my typical list: DICOM Modality Image Store, DICOM Print, Modality Worklist, Storage Commitment, and Modality Performed Procedure Step. Unfortunately, there was no Integrating the Healthcare Enterprise (IHE) specification available during the procurement phase, so IHE-compliance statements were not included in the purchasing contract. Next, the FSE asked the standard questions that had already been provided to his preinstallation team via email: “What is the make, model, and software version of your PACS?” That was immediately followed by, “What is the IP address assigned for this scanner?” These questions were answered quickly. I then requested that the Application Entity Title (AET) be defined according to a naming convention that I established as a standard a long time ago. I also asked if the computer’s station name could be named similarly. The FSE called his technical support with the information, and was able to begin work on the DICOM setup later that afternoon. I was told that the computer’s station name cannot be changed. There are other components in the scanner that have been set up using this name and so it must remain as defined. I learned that I must live with s37gikx22789chlmc23 as a station name. The good news was that the AET can be customized, so the AET is set up according to convention. My naming convention includes the general location of the device, a vendor identifier, modality identifier, and a number as a counter (for example, ERVENDRNAMCT3). The modality was configured to communicate with the PACS test server and vice versa. Connectivity testing was performed, and the testing went smoothly. The DICOM syntax was set up to negotiate using DICOM Implicit Little Endian, and soon data were being stored on the test server. A check of the DICOM image header indicated that all the DICOM tags needed for my site’s PACS workflow were filled in, and so these studies should follow established PACS workflow nicely. A check of the image data was unremarkable. The PET/CT scanner was set up to communicate with production PACS. The production DICOM installation went smoothly, and acceptance testing was completed successfully. With applications personnel on-site, training of our technologist staff began. It didn’t take long to notice that the DICOM worklist did not include all of the scheduled patients being examined on the scanner. The worklist had been set up so that only ordered PET/CT studies were listed whenever a worklist query was performed from this scanner. This was not enough. The worklist also needed to include other scheduled studies that were converted from the initial request to a more appropriate PET/CT study. The worklist was modified to include studies that were scheduled on our more generic PET scanners. Acquisition Issues The acquisition procedures developed on a new modality typically start out conservatively. At first, routine procedures are defined using familiar acquisition parameters, with some adjustments made at the recommendation of applications personnel. Once a new modality is familiar to both the technologists and the radiologists, changes in procedure often follow. Most changes are typically accommodated well by our PACS, even as some study sizes have increased to thousands of images per study. Once in a while, however, a new challenge presents itself. The PET/CT scanner had been online for some time, and studies were flowing through our PACS fairly seamlessly (except for the occasional study set of 7,000 or more images). Then a new research protocol was developed. This protocol included the acquisition and storage of PET list mode data, and a request was made to archive these data on PACS or an equivalent storage silo. PET list mode data are essentially a list of registered photon scintillation events. The 3D coordinates of each detected scintillation event are recorded in a file, along with other physiological parameters. This file is then stored in the modality vendor’s local database as a DICOM object. Upon learning of the request to store list mode data onto PACS, a solution was sought that would not affect the PACS user community. The PACS installed at Cedars-Sinai Medical Center, Los Angeles, is a Web-based application with a single database that is available to all users throughout the enterprise. When a study is stored on PACS, it is available to everyone. If PET list mode data were available to the typical user, they would not know what to do with them. In addition, PET list mode data are now averaging three to four gigabytes per file, and each patient has two files per study. Imagine the poor Web user who accidentally tries to open this file on a standard PC. A help-desk call would be sure to follow. Cedars’ PACS has a two-tier architecture that consists of an image server and a long-term archive. The solution seemed to be nested in storing to the long-term archive directly, bypassing the image server. If the list mode data could be stored directly to the long-term archive, then the image server would be bypassed, and the PACS user community would never see these data. It was time to work with both vendors. DICOM Failure After some discussion, it was decided to try a test of concept. The modality and the PACS archive were set up to communicate with each other directly, and a DICOM Modality Store to the long-term archive was attempted. The DICOM association failed immediately. Different DICOM settings were tried on the modality, all without success. It was time to get more serious. A DICOM conformance statement was needed. A search of the vendor’s website presented a list of DICOM conformance statements for other modalities, but none for the newest PET/CT scanner. A conformance statement was requested from the modality vendor. I should mention that there are some robust DICOM validation tools that can be used for just this scenario. Having never used these tools myself, I decided it was time to learn. I download DVTK, an open-source validation toolkit. Before I could use the toolkit, the DICOM conformance statement was received. It only took 20 minutes of reviewing the conformance statement to identify the problem. A key-word search quickly determined that the vendor’s PET list mode data are stored in a private DICOM syntax. The DICOM negotiation was most likely to be failing due to the private nature of these data. A conference call was arranged with the PACS vendor’s DICOM validation team, which confirmed that the PACS vendor does not currently support the private syntax specified in the conformance statement. Another solution needed to be found. Another conference call was arranged with another technical group responsible for the PACS archive, and it was confirmed that the PACS archive can also store non-DICOM data. The approach that was decided upon requires a portion of the archive RAID to be set up as a Samba-based file share. This is how UNIX systems can be set up to look like network file shares to Windows™ systems. The bad news was that my archive was not licensed to store non-DICOM data, and a quote would be forthcoming to cover licensing. Other Realities At this time, the procurement of the PACS license is still in progress. Meanwhile, a Windows network file share has been set up and is working well. I estimate that a one-terabyte volume will hold about six weeks’ list mode data. If necessary, another Windows file share can be added. The one significant shortcoming to this approach is that information available in the DICOM header is not available for indexing in the PACS database. Patient files are basically stored as a collection of files in separate directories. During the conference calls, it was agreed that the best solution would be to validate the modality vendor’s PET list mode data with PACS. Tomorrow, I will call my modality vendor and see whether I can arrange a collaborative effort with my PACS vendor.