The other day, PACS guru Mike Gray wrote an interesting post on disaster recovery. Between the HIPAA security requirements and Sarbanes-Oxley, hospitals have little choice but to archive data and store a copy off site. Mike takes the concept of backing up data a step farther:

So here is something to consider. Given that you are mandated by HIPAA
to create a reasonable Disaster Recovery solution, why make that second
copy a duplicate of the semi, not really 100% DICOM-compliant version
of the study data created by your existing PACS? Why not avoid the
"disaster" of data migration and make that second copy a 100%
DICOM-conformant copy of your study data? What I am suggesting is that
you redirect your Disaster Recovery dollars into an second, standalone
"archive" solution, most likely from a different vendor, who can
demonstrate/guarantee that this second copy is accessible to both the
current PACS and the next PACS, and the one after that. There would be
no need to migrate the data, when you change PACS!

Make your Disaster Recovery solution a PACS-neutral solution, and avoid the very predictable disaster of data migration.

In the diagnostic imaging world, DICOM provides a reasonably high level of interoperability between vendors' imaging modalities and PACS. However the vast majority of PACS make extensive use of what DICOM calls "private" tags and other non standard ways to represent data. This makes migrating data from your old PACS to a new PACS from a different vendor problematic. This pernicious form of vendor lock-in represents a hidden cost that is born by providers when they replace systems. It can cost between one quarter and a third of the cost of your new PACS to migrate the data from your old system. The migration process takes months which frequently delays new system deployments. Yikes.

Now think about data migration and your EMR or CPOE system. Could you implement a new clinical system without access to data that was in the old system? Sadly there is no DICOM equivalent for non-image oriented clinical information systems, so migrations can be much more complex. Migration is not the kind of thing usually asked about by providers during a vendor selection process (let alone needs assessment). And don't count on vendors volunteering to raise the subject.