Many institutions are about to upgrade or replace their PACS, and in many cases this will be done with a product from a different vendor. Many of these institutions are in for a rude awakening--the images and related information in their archives will have to be migrated to meet their new vendor's data formats. This process can be expensive; for the best case scenario, the cost will be as much as half a million dollars and will take months to accomplish.
This sad truth of data "portability" has created a burgeoning market in data migration, companies who are expert in the various image encodings and formatting. Some of the image related information such as overlays, measurements, key images, and notes may even have been stored in a proprietary manner in the image header or database and will be lost when migrating the data to the new archive. The worst case scenarios will cost more and take longer.
It is amazing that many vendors still “mess” with the data integrity of the information trusted to their archive. During our training class in Asia, I had one user tell me that his nuclear medicine images could not be processed after they were archived by the PACS and subsequently retrieved back at the modalities. Another user shared their frustration that a vendor’s workstation could not reformat CT images--also after they were archived and retrieved.
These types of problems are forcing users to come up with their own solutions to mitigate the issues caused by proprietary archive formats. Many believe that the best answer is the “vendor-neutral” archive.
The most common implementation is to use an archive solution, often from a different vendor, that interfaces with the PACS front-end using open standards. Initial attempts are somewhat encouraging; however, many have found that there is much more happening between a PACS archive and front-end (database-image manager and workflow manager) than they were aware was going on. Also, PACS vendors are somewhat hesitant to let go of that part of their system. But many institutions, especially those who want to share an archive between multiple institutions with different PACS products, are pushing for this type of solution.
I believe that the vendor-neutral archive is the right way to go. I expect that there will be some resistance from established PACS vendors to let others enter their turf, and there will be integration issues. However, PACS archives must be able to be easily replaced and be able to be upgraded separately from other PACS components. As such, the clear trend is toward commoditization of this PACS domain. Users must have management and control of their data, and they should not be expected to jump through data and dollar hoops to move this data each time a new PACS vendor is selected.