Part II: Proactive PACS data migration -- A better way to address the inevitable

Jan 3, 2007

AuntMinnie.com presents part II in a two-part series by PACS consultant Michael Gray on effective PACS data migration. For part I, click here.

Being proactive about the inevitable data migration from PACS A to PACS B is an easy concept to grasp. Data migration is inevitable, expensive, and time-consuming. It's a problem growing larger by the day, as study volumes, slice counts, and image matrices expand. Migrating the data from A to B sooner rather than later makes sense.

What doesn't make sense is having to migrate the data from A to B and then again to C. Migrating data from PACS to PACS is particularly disturbing; you will very likely have to live through this data migration process several times over the lifetime of the study data. A growing percentage of studies will have to be kept well beyond the "legal" mandates (simply because today's patients are surviving longer) and well beyond the practical lifetime of a PACS.

If the information life cycle management requirements for a growing percentage of study data are going to surpass several PACS networks and approach 20 years, a key element of any proactive data migration strategy should be to migrate the data once, now, to a long-term archive and never again. It's this "never again" concept that makes the proactive data migration strategy such a sensible thing, but it is also the concept that makes it so complicated.

One key to the "never again" strategy would obviously be to build a DICOM archive with an architecture that would allow it to evolve through software upgrades and hardware refreshes over 20 years. If the current and all successive PACS are as DICOM-conformant as possible, they should be able to interface to this DICOM archive.

Unfortunately, far too many current PACS are not very DICOM-conformant. DICOM archives have been around for at least five years, but rarely serve as the active storage solution for a PACS. They are primarily used as the deep archive or the disaster recovery solution.

The reason for this is simple. Most current PACS are not designed to fully interoperate with a foreign archive.

They may store some of the study objects in their directory database rather than "archive" them with the image data in their data database on the archive. They may not use DICOM operations to communicate with their own archive, much less the foreign archive. In short, many current PACS are effectively "proprietary," and only some of the study data can be exported to a foreign archive. The rest is secreted in the PACS.

There is also the issue of the directory itself. Many PACS vendors refuse to disclose their directory's data dictionary or its schema, the keys to understanding what patients and studies are in the PACS and the file system pointers that describe where the study data is actually stored in the attached storage solutions.

So even if PACS A and PACS B were fully DICOM-conformant, the data would have to be migrated from A to B for PACS B to "learn" all of the patients and studies stored in PACS A, and for PACS B to create its own file system pointers. So whether the study data is stored on the PACS or a combination of a PACS and a foreign archive, data migration will continue to be a requirement every time you change the PACS.

The real key to the "never again" strategy, and the only way to take full ownership of your study data, is what I'm going to call the "paradigm shift."

The concept of a 20-year archive does not work if the archive is placed at the rear end of the data path. The conventional data path of modality to PACS to archive will simply lead to repeated data migrations of increasingly larger data volumes. The only way to break this cycle is to place the archive in the middle of the data path.

The paradigm shift

The real key to the "never again" strategy is to shift the roles of the PACS and the archive. Changing the data path to modality to archive to PACS places the archive in a position where it can manage the data from its very beginning and throughout its life cycle, for as long as 20 years.

In this configuration, the modalities direct the new study data directly to the archive, where the study is reconciled against the order. Once the new study has been approved via quality control, the archive transfers the new study and any relevant priors to the PACS. The PACS remains the support platform for all the user worklists and all the physician display applications.

Once the new study has been interpreted, the new study and any DICOM-based study objects created during the interpretation are transferred back to the archive. The archive would detect any differences between the study data acquired from the modality and the study data returned by the PACS, and store any updates as the "archive copy." The archive would apply user-defined information life cycle management rules to the study data as it ages, using DICOM tags to determine when it should be migrated to new or different media, and when to purge it from the system altogether.

The PACS would continue to store the new study and its priors for a reasonable period of time, to support access by the physicians. The PACS would manage its online data using its conventional storage management schemes, eventually purging the data.

It's worth noting that this specific data flow could be supported by any PACS, since all of these systems are particularly DICOM-conformant on their front end. As for those that are not particularly conformant on their rear end (to the archive), the archive would simply automatically query the PACS every few minutes for any study data whose status was recently changed from unread to read.

For those PACS that do not archive some of the study data objects with the image data, it is interesting to note that many of these very same systems typically do return all data objects as DICOM objects when they respond to an ad hoc DICOM query. So it would seem almost any PACS can become more DICOM-conformant, if they are assigned to the proper place in the data flow -- at the end.

For those who think that I have taken too many technical liberties for the sake of brevity, let me assure you, dear skeptics, that several existing products on the market could meet the requirements described herein. Rather than lay out all of the detailed requirements and start naming names, for surely some vendor will be slighted, it should be just as useful to define the three key categories of requirements that lay one on top of the other. From bottom up they are:

State-of-the-art storage: A hardware platform and architecture conducive to long-term stability and evolution.
Intelligent storage management software: The software layer that provides information life cycle management and flexible administrative tools.
Intelligent and automated DICOM data management: The DICOM-conformant software application that supports the initial data migration, HL7 operations, prefetching of priors, DICOM moves and finds, as well as automated and interventional quality control.

I do not suggest that there is one solution that will fit all situations. I would suggest instead that you initiate a process that will lead you to your own ideal proactive data migration solution. Begin a conversation with a PACS vendor or a storage provider. Discuss the principals and key issues described in this article, and see where those conversations take you. It won't take you long to discover one or more vendors that understand exactly what you're describing, and before long you'll have several proposals to consider.

A great deal can be gained by this paradigm shift. Taking ownership of your data is key among them, but it's also a much better way to manage the life cycle of that data. There is a very real possibility that your total cost of ownership attributable to managing and distributing medical image data over the next 20 years will be considerably lower than would otherwise be the case.

A larger percentage of the costs will be invested in the more stable archive, and an increasingly smaller percentage will be assigned to the PACS, which is likely to be replaced every five to seven years. Of course, significant savings can be had by not having to migrate the data ever again.

I believe that the separation of archive from PACS, and this specific paradigm shift, will result in a significant reduction in the overall cost of ownership; the vendor lock will be eliminated, and that nearly always leads to more competitive pricing. This time around the DICOM archive will be successful.

By Michael Gray
AuntMinnie.com contributing writer
January 4, 2007

Michael Gray is the principal of Gray Consulting and has been providing consulting services related to PACS since 1991. Mr. Gray has recently published a "do-it-yourself" electronic RFP template. Information about "RFP with a Punch" and Gray Consulting can be found at www.graycons.com.

PACS users wise to maintain DICOM object integrity, April 6, 2006

Choose image archiving solutions before data volume grows too large, January 5, 2006

Foresight aids PACS migration, June 4, 2006

Planning mitigates PACS data migration, March 21, 2005