Part 1 – Why DICOM must address data migration

In 2018, we celebrated a quarter-century of the DICOM standard. Virtually every radiology and cardiology imaging exam, worldwide, is now recorded in DICOM format. It is perhaps the most widely deployed interoperability standard in healthcare.

DICOM has been extraordinarily successful, in no small part due to its conservative approach to selecting which areas it will standardize, and which not. In particular, DICOM has had a policy to avoid addressing any implementation details behind the network interface, in particular PACS storage implementation. But I will argue that the time has come for an evolution in that policy, and the creation of a DICOM standard for PACS media storage.

DICOM has always focused on providing solutions for the efficient operation of the imaging department. Initially, this meant simply being able to exchange and store images over a local area network; but as needs changed, it evolved to include media-based exchange, workflow management, structured reporting, and recently, web services to support nontraditional and remote applications. In the past few years, a new operational problem has arisen for imaging department managers – PACS migration, and it is critical that DICOM address this issue now.

User organizations will typically replace their PACS approximately every 12-15 years, often with a change of vendor. Also, as healthcare provider organizations merge, there is a need to consolidate disparate PACSs. Such replacements and consolidations require migrating historical data to a new system. Vendor neutral archives (VNAs) may mitigate the problem somewhat, but they also face a replacement lifecycle that will eventually require migrating data. And VNAs may ultimately be replaced by some new systems architecture, much as they replaced the architecture of data storage solely within the PACS.

The realization of the need to address data migration for healthcare IT systems in general (not just PACS) has become increasingly urgent. For instance, U.S. regulators are taking the first steps toward requiring portability of patient data to support EHR replacement. Dealing with system end of life transitions is now recognized as a critical aspect of sustainable healthcare IT operations.

So, what’s the problem with migrating PACS/VNA data? It’s all in DICOM format, isn’t it? Yes, and the simplistic approach would be to just do data moves using the DICOM protocol from the legacy system to the target system. The issue is one of data volume and system bandwidth – after a decade and more of operations, even small PACS systems will have hundreds of thousands of studies, and large systems will have tens of millions, with potentially over a billion image objects. The sending of each object involves one to four database reads, a filesystem read of 0.25 – 8 MB, and a multitude of DICOM network packet writes, plus corresponding network, database, and filesystem input/output operations on the receiving side. Even with an I/O operation taking only a few milliseconds, when you are dealing with millions of objects, the aggregate delays and load on the system becomes quite significant. Given that either the legacy system or the target, or both, are in clinical use, which must be prioritized over migration, migration using the simplistic approach might take well over a year – if everything runs smoothly!

However, if the image data is stored in DICOM format files in a network file system (as is common), the data may not need to be moved at all during a PACS migration. The next blog post will explore this in more detail.

Author Harry Solomon is an interoperability consultant for Laitek, Inc., and past Co-Chair of the DICOM Standards Committee. He has been involved in the development of DICOM since 1993, and has taught graduate courses in healthcare interoperability and standards at Northwestern University and at Oregon Health & Science University.