The hurdle of migrating PACS data can be cleared by PACS users with appropriate preplanning, according to Dr. Steven Horii from the University of Pennsylvania Medical Center in Philadelphia.
"Changing PACS vendors and the storage migration associated with it is one of the most difficult scenarios a facility can face," Horii said. "The key to minimizing the effects of this is planning for it in advance."
Horii spoke during a talk at PACS 2005: The Expanding Integrated Digital Healthcare Enterprise, a conference sponsored by the University of Rochester School of Medicine & Dentistry in Rochester, NY.
PACS users may need to migrate data for a variety of reasons, including a vendor's decision to exit the market or plans for a system update. In addition, the vendor might no longer be meeting the institution's needs, Horii said. Or, administration may decide to move to a different vendor for all information systems.
Storage and data formats
Electronic storage consists of two components: the database and the files; migration involves the entire database and all files, Horii said. It's important to be aware that that storage media have physical lifetimes usually in excess of their practical lifetimes; if archival storage is on media more than 10 years old, it may be on media no longer supported at a reasonable cost, he said.
Data migration is complicated by the use of proprietary storage techniques by vendors. Even if images are stored as DICOM files, many vendors "take apart" the DICOM, and actual storage formats are proprietary, Horii said. Because of the proprietary nature of the storage, access to the data in a nonproprietary form may only be possible through a DICOM query/retrieve process, he said.
"Remember, DICOM is not a database definition. It was designed for communication," he said.
If information is stored as DICOM objects using DICOM media formats, however, at least they don't have to be reconstructed from proprietary database tables, Horii said. It's also helpful to know the database schema that runs on top of the DICOM archive.
Migration issues to consider
In planning a data migration process, institutions need to keep in mind that the task will require access to the same database and archive used by the working PACS network, and that running the migration application may slow down clinical PACS operations, Horii said.
He suggests running the migration application in hours of low clinical activity.
Adaptive migration software can look for and predict times of low use, and slot in migration events during those times, Horii said.
"If access to the database is the problem, though, you might consider replicating the database on a separate machine," he said.
Parallel systems may need to be run for a while, so additional interfaces to other information systems will be needed, as will additional network drops and furniture for the PACS hardware. Personnel will need to be trained on the new system, and reading room and computer room space will be required for the new hardware, he said.
Also be aware that "problem" entries can occur in the database. These can include duplicate names, different name representations, two MRNs for one patient, missing request numbers, unverified studies, and incorrect name-examination association, Horii explained.
Another potential roadblock to PACS migration could be reluctance by administration to pay for conversion costs.
"Make sure administration knows the potential costs and impacts of moving to a different PACS vendor," he said.
Data migration should be part of the PACS acquisition process, and some aspects should be in the RFP, Horii said. If it wasn't included in the RFP, though, customers will have to negotiate an agreement between their new vendor and the previous one.
"Strongly consider getting third-party help that's neutral to both vendors," he said.
A third party can serve as a buffer between the vendors. A migration vendor can perform a database assessment for problems, and may even be useful before a PACS is purchased to help include appropriate items in the RFP, Horii said.
Prenuptial agreement
Horii recommends including a number of provisions in a type of "prenuptial" agreement with your PACS vendor, covering who owns the data and how extensive access to the database will be. For example, will the customer be entitled to the database schema, and under what circumstances? And if the client replicates the database, will there be additional license fees?
It's also important to determine who will bear the cost of the conversion.
"This may be difficult to predict, so it may be useful to define how this will be negotiated," he said.
In addition, the amount of data that will be converted should be covered in the agreement. Horii suggests an 80% or 90% model, which will convert enough data to cover 80% to 90% of requests for prior studies, with the rest converted on an ad hoc basis.
An option to use a migration vendor should also be included, either directly in the agreement or based on certain triggers. A volume-based migration time target, such as number of hours per gigabyte or weeks per terabyte, should be delineated, he said.
"Include remedies/penalties based on the reasons for changing vendors," Horii said.
Migration agreement
If, like most institutions, a "prenuptial" or migration agreement was not included in your RFP, a migration or conversion agreement is recommended. Similar to the "prenuptial" agreement, a migration agreement should ensure that all parties know the magnitude of the migration problem, including data volume, database size, how many problem studies there are, and bandwidth limits, Horii said.
"Strongly consider either doing a survey of your archive for problems or having it done," he said. "Performance benchmarks should be negotiated and appropriate bonuses/penalties defined."
The migration agreement should also address how to limit impact on clinical work. If migration would impact storage bandwidth, off-hours operation should be considered, Horii said.
"If migration processes cause operational system crashes, these are high-priority fixes before you allow the process to continue," he said.
Database problems should also be fixed as part of the migration, Horii said.
By Erik L. Ridley
AuntMinnie.com staff writer
March 21, 2005
Related Reading
PACS improves care, builds interhospital relationships, March 14, 2005
PACS administrator role requires planning, vigilance, March 11, 2005
Web-based workflow and reporting systems keep imaging on track, March 10, 2005
Preparation eases PACS' impact on technologists, March 1, 2005
PACS succeeds clinically, financially for IDNs, February 15, 2005
Copyright © 2005 AuntMinnie.com
