Maybe your PACS vendor is going out of business, or the system is so creaky that your vendor no longer offers support. Perhaps your hospital signed an exclusive purchasing agreement that requires a new PACS from a different vendor. Maybe your new department chair just prefers a different system. Any of these causes could conspire to put you in the unenviable position of having to replace your PACS. In the case of Steven Horii, MD, PhD, he’s been there three times.
“How easy does divorce sound?” Horii asked the audience during “Divorce Counseling: Changing PACS,” which he presented on June 5, 2010, in Minneapolis, Minnesota, at the annual meeting of the Society for Imaging Informatics in Medicine. “It will be a major undertaking,” he says.
While a new PACS investment represents a significant cost, the major source of pain is not money, nor is it saying goodbye to the old vendor. Data migration is the number-one problem, and the minute you know you have to change PACS, you should start thinking about migration, according to Horii, professor of radiology and clinical director of medical informatics at the University of Pennsylvania in Philadelphia.
Mismatches will cause the biggest headaches, and all of the following data issues will require either manual intervention or processing through additional software: different names for the same people; head CT studies that actually contain exams of the head, chest, and abdomen; studies that go in with incorrect order numbers; and studies on read-only memory that had attributes on them.
In addition, all PACS interfaces with other information systems and imaging endpoints will have to be tested, which might add to transition costs. Another thorny potential issue is the changeover date: You might miss the target and need to continue using the old PACS, and if your service agreement has expired by then, the jilted vendor is unlikely to be responsive in its support.
To ease future migration efforts, consider a vendor-independent archive, Horii suggests, and store each item as a DICOM object. When you undergo your next transition, you might have to remap some of the mapping tables, but the migration is likely to be easier.
The PACS Prenuptial Agreement
The best defense against unkind (and expensive) surprises is to craft a good prenuptial agreement with the new vendor that anticipates these potential pain points:
- hitting—or missing—the data migration’s target date;
- supporting clinical operations during the changeover;
- who cleans up, and pays for, any data messes; and
- the role of the new vendor in supporting its technology, in the event that it is jilted in the next PACS transition.
Horii recommends addressing 10 particularly important items in any contract with a new PACS vendor. First, insist on realistic, firm changeover dates, and negotiate penalties that will go into effect if the changeover is missed. Second, require access to the database and data if the vendor goes out of business. You want database schemata before the vendor shuts down, as well as the details of all DICOM interfaces.
Third, ask for an option to continue service contracts on month-to-month basis; service during the transition should be provided on the same terms that were in effect during the system’s active life. Fourth, request that the vendor guarantee engineering support in the event that there is a transition to a new vendor. Horii says that this support should not be expected to be free, but negotiating a schedule of charges for engineering support for the old system should be part of cost of a new PACS.
Fifth, when beginning database migration in advance of the changeover (which Horii recommends), set a target for the amount of information to be migrated prior to the changeover. Sixth, insist on sending exams to both old and new systems during the transition: It will cost more because you will have to run parallel systems, but double pitching will reduce the amount of time you spend on migration. Seventh, ask for confirmation that studies are being stored in, and are retrievable from, the new archive.
Eighth, determine who is going to do database cleanup. If it’s your team, negotiate a chargeback labor rate. Ninth, if you do a database survey to estimate mismatches (which Horii recommends), negotiate who will pay for this. Tenth, if you are reusing any of the old system’s equipment in the new system, what will you do during the parallel-systems phase? Consider using loaned