Key Takeaways

• The cost of replacing a PACS or a VNA is significant and it is driven by the data volume that needs to be moved
• The cost can be significantly diminished (made neutral) by deploying an Application Independent Data-Architecture

As stated in the previous blog “Disaster Recovery in the Cloud?”, Disaster Recovery plans and implementations change with the change of vendors managing the data. That aspect is generally overlooked, being taken as a “given” by most. Generally speaking – that’s not surprising nor too punishing, when talking about applications that manage relatively small amounts of data.

But in imaging, changing from one PACS/VNA to another implies a migration of tens, hundreds or thousands of TB of data from the old system into the new one. And then, disaster recovery needs to be supplied for that new data, in that new format.

The larger the data to migrate, the larger the timeline to migrate it and, consequently, the cost of migrating it! Migrations are not cheap – and there is a good reason for that. The complexity of migrating large amounts of data grows exponentially with the volume and impose significantly on all the actors involved in the patient healthcare act.

Further, one might think that you do not need to implement disaster recovery for your replacement system until it is live. But since we are talking about massive amounts of data, the time to put that data back into the new system in the event of a disaster is a significant cost generator. Strictly speaking, from a DR perspective, if a disaster hits your new implementation while still being hydrated, you are covered by your existing system. But you will need to go migrating AGAIN all that data that was acquired in months, maybe years prior to your originally projected Go-Live. And then spend AGAIN many months and maybe years in hydrating that system again along with all the associated, exacerbated costs.

A simplified view of the additional costs of replacing an imaging system can consider the following factors:

1. The cost of migrating the data
2. The replacement storage cost.
3. The cost of DR-ing the migrated data into the new location
4. The cost of keeping the existing system live until the new system can “go live”.

Achieving system’s replacement cost neutrality would mean zeroing out (or near-zeroing out) these components. Can that be achieved?

• Can one really have no cost in migrating the data into a new system?
• Can one really replace a system managing a mountain of data without replacing the storage, or without the need of acquiring an equal amount of storage for the new data to be migrated into?
• Can one really have disaster protection already in place at the beginning of the system replacement?
• Can one really move swiftly to the new implementation, at a short time (say three months?) after standing up the new system?

All these questions had no answer up to this point. Some might call promoters of such a possibility – dreamers, ignorant or decoupled from reality.

Well, we’re not afraid of such labeling. After all, disruptive changes are met with significant resistance from the market. It is only natural to be so.

ENTER

Application Independent Data-Architecture

What is it, again, that which prevents you from achieving system replacement cost neutrality in medical imaging archiving?

It is really the time needed to make the data available to the new archiving system (PACS or VNA). The data is not readily available to be ingested by the new systems and there needs to be a migration from an existing system to the new one.

One needs to fetch the data from the existing system, apply various transformations to it and then send it to the new system – and all that is being done one image at the time, for tens, hundreds and thousands of millions of images (there are already several cases around the world of institutions amassing in excess of 10 Billion – with a B! – images), each going through the full application stacks of the source system, the migration manager and the target system.

Institutions are therefore left frustrated, captive between two extremes:

1. Storage vendors, who advertise transfer speeds of 200GB per second – which would allow a 5PB migration to be executed in less than a day!
2. PACS and VNA vendors – who must tell their customers that they can’t do a DICOM migration of more than 500GB a day without impacting clinical operations.

Our next blog will show how the distance between the two realities shown above can be reduced, introducing a new concept – Application Independent Data-Architecture. The new concept is built on top of existing standards and allows for full decoupling of application from the data it manages, allowing to reach the point of system replacement cost neutrality.

Until then, check out these blogs, which outline the basis of our approach along with some food for thought supporting this angle:

• Harry Solomon’s series on a new DICOM Storage Standard proposal
  1. Part 1 – Why DICOM must address data migration
  2. Part 2 – Separation of apps and data – the DICOM media interface
  3. Part 3 – The Enhanced DICOM DIR
  4. Part 4 – Journaling updates in the Enhanced DICOMDIRs
• Fred Behlen’s blog “Who owns patient data”
• Doug Sluis’s blog “Upgrading PACS or VNA Data when Upgrading PACS or VNA”

 

Author Razvan Costea-Barlutiu MBA, is Laitek’s Chief Technical Officer and is responsible for software development, innovation, data migration technology and thought leadership. He leads Laitek’s development and system engineering teams with a focus on developing high-performance PACS components and overseeing the technical aspects of Laitek migrations. Razvan originally worked with Dr. Behlen in Rossman Labs at University of Chicago on the National Digital Mammography archive and developed the first tools that performed a full round-trip conversion from DICOM to XML.