Maturing RIS/PACS systems create replacement issues
PACS vendors have matured but become less flexible, Wiggins said. That makes data migration a big challenge. And, only removable media has to meet DICOM standards. Wiggins found migration downtime to be very variable. Data migration is a task that “is not to be undertaken lightly,” he said. A database is usually proprietary. Be aware that when you sign with vendors, they have your data and control of it, he said.
To prepare for a new PACS and data migration, consider future changes to your data. If you are planning on implementing 64- or 128-slice CT, for example, that will dramatically change your data storage needs. You also should plan for about 5 to 10 percent institutional growth per year.
There are options for migrating your data. One is doing it yourself. This often takes 33 to 50 percent of the time it took to originally acquire the data. That indicates a significant amount of time, if you consider an example of 250,000 studies a year for 8 years. That’s two million studies which can take close to a minute each to migrate. Another concern is whether you are still under warranty. If something happens to the data during migration, what will you do and what role does the vendor play?
You can ask either your old vendor or your new vendor to do the migration but both will have motivational issues. Another option is hiring a third party. That can cost more but they will have more experience and probably can more easily communicate with both the old and new vendors.
PACS purchasing is different today than it was when many facilities were buying their first solution several years ago. With the shift to enterprise-wide systems, the purchase is no longer just for the radiology department. Also, purchasers have gotten smarter and are demanding more from vendors, Wiggins said. There has been change from “turnkey” systems to much more customized PACS.
Replacing your PACS can be just as time-consuming as the original deployment, Wiggins said. When his facility began shopping for a new PACS, criteria included a well-established company with a low risk of a buyout, a single-vendor solution, cutting-edge technology and compliance with HL7 and DICOM standards.
Transitioning a database without redundancy and backup is risky, Wiggins pointed out. If you try to migrate during busier times, the migration process will slow down everything. Unexpected problems will probably arise as well. During his migration, he found that all patient names were in a nonstandard format so he and other users were wasting time trying several formats to call up data.
Wiggins said that his lessons learned include the following:
When choosing a replacement RIS, Wiggins said that the key was to involve everyone. Different groups have very different needs, including techs and schedulers. So, Wiggins had everyone create ordering scenarios that they could give vendors who could then offer their solutions. Everyone contributed questions for the vendors to help ensure objective evaluation. They created vendor profiles based on the scenarios and questions to help fairly evaluate and compare the vendors.
Frederick Behlen, PhD, officer and director of Laboratory Automation, discussed several reasons for not keeping an old PACS archive. Maintaining an old archive is a complex venture, both administratively and technically. There are economic issues with maintaining the archive, including space, power and cooling expenses. Reliability is another concern—older archives are less likely to meet regulatory compliance requirements.
Meanwhile, legacy vendor support is uncertain. Supporting legacy systems is not a key business goal of any vendor, Behlen said. With more and more hardware aging, migration is becoming the standard of practice. However, migration can take a very long time, there are inevitably errors to manage, the DICOM interface might not export all the desired information, and some data may need to be updated to current DICOM standards.
A do-it-yourself migration can be done with a DICOM workstation. Fetch studies from the source archive, then store the studies to the target archive and repeat, said Behlen. This is a good method for a smaller database and if you’re happy with the data but it can be an arduous process. He called this a “noninvasive” method and said that you don’t need inside knowledge of the source PACS. Plus, a single design serves a broad range of source systems.
Another option is writing and running your own command files by downloading a DICOM C-MOVE client program. This requires, Behlen said, good in-house PACS and IT skills.
If you decide to use an outside firm, providing them with the version history, the make, model and software number is very helpful, along with the number of terabytes stored. Outside firms usually offer additional options for data enhancement including capture of proprietary grey scale settings which are often stored in the database rather than the image, and capture of proprietary key image selections.
However you decide to do your current data migration, start preparing now for your next PACS changeover, Behlen recommended. Get commitments from the new vendor on how fast they can migrate, the cost and required outbound migration specifications.
To prepare for a new PACS and data migration, consider future changes to your data. If you are planning on implementing 64- or 128-slice CT, for example, that will dramatically change your data storage needs. You also should plan for about 5 to 10 percent institutional growth per year.
There are options for migrating your data. One is doing it yourself. This often takes 33 to 50 percent of the time it took to originally acquire the data. That indicates a significant amount of time, if you consider an example of 250,000 studies a year for 8 years. That’s two million studies which can take close to a minute each to migrate. Another concern is whether you are still under warranty. If something happens to the data during migration, what will you do and what role does the vendor play?
You can ask either your old vendor or your new vendor to do the migration but both will have motivational issues. Another option is hiring a third party. That can cost more but they will have more experience and probably can more easily communicate with both the old and new vendors.
PACS purchasing is different today than it was when many facilities were buying their first solution several years ago. With the shift to enterprise-wide systems, the purchase is no longer just for the radiology department. Also, purchasers have gotten smarter and are demanding more from vendors, Wiggins said. There has been change from “turnkey” systems to much more customized PACS.
Replacing your PACS can be just as time-consuming as the original deployment, Wiggins said. When his facility began shopping for a new PACS, criteria included a well-established company with a low risk of a buyout, a single-vendor solution, cutting-edge technology and compliance with HL7 and DICOM standards.
Transitioning a database without redundancy and backup is risky, Wiggins pointed out. If you try to migrate during busier times, the migration process will slow down everything. Unexpected problems will probably arise as well. During his migration, he found that all patient names were in a nonstandard format so he and other users were wasting time trying several formats to call up data.
Wiggins said that his lessons learned include the following:
- legacy data is vital;
- you can perform data migration in stages; and
- migration has a big financial impact.
When choosing a replacement RIS, Wiggins said that the key was to involve everyone. Different groups have very different needs, including techs and schedulers. So, Wiggins had everyone create ordering scenarios that they could give vendors who could then offer their solutions. Everyone contributed questions for the vendors to help ensure objective evaluation. They created vendor profiles based on the scenarios and questions to help fairly evaluate and compare the vendors.
Frederick Behlen, PhD, officer and director of Laboratory Automation, discussed several reasons for not keeping an old PACS archive. Maintaining an old archive is a complex venture, both administratively and technically. There are economic issues with maintaining the archive, including space, power and cooling expenses. Reliability is another concern—older archives are less likely to meet regulatory compliance requirements.
Meanwhile, legacy vendor support is uncertain. Supporting legacy systems is not a key business goal of any vendor, Behlen said. With more and more hardware aging, migration is becoming the standard of practice. However, migration can take a very long time, there are inevitably errors to manage, the DICOM interface might not export all the desired information, and some data may need to be updated to current DICOM standards.
A do-it-yourself migration can be done with a DICOM workstation. Fetch studies from the source archive, then store the studies to the target archive and repeat, said Behlen. This is a good method for a smaller database and if you’re happy with the data but it can be an arduous process. He called this a “noninvasive” method and said that you don’t need inside knowledge of the source PACS. Plus, a single design serves a broad range of source systems.
Another option is writing and running your own command files by downloading a DICOM C-MOVE client program. This requires, Behlen said, good in-house PACS and IT skills.
If you decide to use an outside firm, providing them with the version history, the make, model and software number is very helpful, along with the number of terabytes stored. Outside firms usually offer additional options for data enhancement including capture of proprietary grey scale settings which are often stored in the database rather than the image, and capture of proprietary key image selections.
However you decide to do your current data migration, start preparing now for your next PACS changeover, Behlen recommended. Get commitments from the new vendor on how fast they can migrate, the cost and required outbound migration specifications.