Vol. 19 • Issue 6
• Page 27
You've fallen out of love with your PACS, and you're eager to migrate to a new system. Most likely, you're wondering how long you'll have to wait before you can enjoy a fresh start. Unfortunately, the answer to that question hinges on several factors, including the choices you made during your previous PACS installation. Did you opt for an external, Integrating the Healthcare Enterprise (IHE)-compliant image archive or manager?1 re images stored on the vendor's archive in pure DICOM or a hybrid format?2What form of media do you use-tape, platters or spinning disks?
Below are the most often-encountered-and problematic-migration scenarios as well as a more favorable one.
Classic approach
In the classic scenario, the existing PACS vendor "owns" the archive and stores images in its preferred format. If your old purchasing contract didn't account for image migration, you can try to convince your new PACS vendor to perform migration as part of the new contract. But unless your new vendor has significant experience migrating from the old platform, you probably won't succeed completely without cooperation from your old vendor-which may charge a high fee to compensate for its imminent loss of revenue.
After you resolve this often-unpleasant business, you can begin migration. Your old PACS usually drives the process, chronologically moving images via DICOM "C-STORES" to the new PACS-which learns to recognize the historical exams and mark them as interpreted and available for the clinical viewer. Your migration speed depends on the media involved, the PACS' overhead when converting the private format to DICOM and the new PACS' DICOM receiver performance with "Store-Commit" enabled.
Just-in-time method
The just-in-time scenario permits immediate use of your new PACS but may prolong your need to maintain the old model. This method involves the following basic steps:
1. The new PACS receives orders from the radiology information system (RIS) for tomorrow's patient exams.
2. The new PACS prefetch engine looks for "compares" on its own archive and, failing there, issues a DICOM query to the old PACS to locate all exams for a specific patient.
3. The old PACS responds by storing all patient exams to the new PACS.
A few caveats: This approach may prolong migration and requires a more sophisticated prefetch engine than some PACS possess. And because this method can't tell you when the source PACS will be completely drained, sites often combine the just-in-time method with the classic approach to ensure draining.
External archive
A site with an external image archive can decommission its old PACS immediately,
assuming the new PACS has an intelligent prefetch engine. Unfortunately, the site must pay twice for storage-once in the institutional archive and again in the new PACS archive. At this point, the site would benefit from having the new PACS vendor make the external image archive the primary storage repository and treat the local PACS storage as only a cache.3
Predicting success
Moving images to the new PACS and preserving quality assurance (QA) operations isn't easy. PACS QA operations (e.g., window/level, scaling, rotation and annotations) are often stored in the database, and the PACS usually only attempts to communicate "image presentation state" to external systems at DICOM "export" to external systems. Older PACS are especially primitive regarding what the DICOM image header can communicate. Typically, window/level information and look-up tables (LUTs) are coerced into the image's DICOM header, while annotations, region-of-interest measurements and other graphics must be burned into the image pixels, if they're expressed at all. As a result, images on the new PACS may look as if QA had never been performed.
For second-generation PACS (manufactured from 2000 to 2005), DICOM work groups created so-called Group 6000 overlay tags in the DICOM header.4 verlay tags can either use vectors to express drawn figures or use bit masks of figures. The former capability means the figures scale if the parent image is resized. In both approaches, PACS viewers can turn overlays on/off (as opposed to burning figures into images) since information is stored as overlays in headers. The key problem is the receiving PACS must support the same flavor (vector or bit map) of overlays to view them. Also, scale, rotation and other image information are not communicated in this method, so QA beyond window/level or annotations likely won't be shared with the new PACS.
The methods used by recent PACS (manufactured post-2005) to express their presentation states are worth noting. Since prior tools imperfectly captured the presentation state, the DICOM committees defined the GSPS (grayscale softcopy presentation state) object in 1999.5Deployed in PACS only recently, the GSPS object can capture the totality of the image's appearance at any moment. Some implementations generate multiple GSPS objects that freeze the image appearance as each user leaves it. Whether a viewer can play back all objects or only the most recent object depends on the viewing vendor's implementation. When PACS sources/destinations support GSPS objects, users should have the full QA performed in the old PACS available in the new.
Cost factors
Costs depend on the preceding factors as well as whether you considered migration in your old PACS contract. Also, the longer two systems run in tandem, the longer the site must pay two support contracts and the longer your department consumes precious data center resources.
Storage costs are also a consideration. Does your site have an IHE-compliant image archive? Can you persuade your new PACS vendor to use it as the primary archive? If the answer is yes, the site can avoid paying for storage twice. The new PACS requires only a working cache (which is 30 to 40 days deep at our site). Finally, will the new PACS vendor recycle hardware from the old system? Storage also may be repurposed, particularly if it's on standard disk farms. Small tape units could be useful for backups, and DICOM gateways may be reimaged with software.
Armed with contract tips (see box) and an awareness of common migration scenarios, you're in a position to call the shots and ensure optimal data movement to your new PACS.
References
1. IHE, www.ihe.net/echnical_framework/index.cfm#radiology. Accessed Jan. 21, 2009.
2. DICOM, http://medical.nema.org. Accessed Jan. 21, 2009.
3. Langer, S.G. (2008). Issues surrounding PACS archiving to external, third-party DICOM archives. J Digital Imaging, May 2008 ePub.
4. DICOM 6000. DICOM Part 3, Section C.9 (2008 version).
5. GSPS. DICOM Supplement 33: Grayscale soft-copy presentation state storage, 1999.
Steve Langer, PhD, is associate professor of diagnostic physics and imaging informatics at Mayo Clinic in Rochester, Minn. He is an affiliate faculty member at Arizona State University and the University of Washington-Seattle.
|