Maintaining schedule can be a significant challenge in a migration to a replacement PACS or VNA. A delay of the planned go-live also delays productivity benefits that motivate the purchase of the new systems. Delays also consume staff effort to re-plan and coordinate activities. Extending support and maintenance beyond the planned decommission date may exceed what was budgeted. Until verifying integrity and completeness of migrated data, it is not safe to decommission the product. For products near end-of-live, the urgency to decommission is acute. Planning is key to completing a migration successfully and on time. Because things rarely go exactly as planned, consider risks and ways to mitigate them.

An understanding of the data flow, the rate limiting processes, and what can interrupt them is essential. A typical migration dataflow has three stages: 1) the input process from the source; 2) subsequent processes to fix, reconcile, transform, and upgrade (see Upgrading PACS or VNA Data when Upgrading PACS or VNA); and 3) the final output to the target. A dominant factor in the duration of the migration is the rate limiting process. The cumulative flow diagram below is a conceptual illustration comparing two scenarios: rate limited into target vs. rate limited from the source.

The charts show the progress over the course of the migration. At start, no data has been read from the source (yellow); data is read from the source into the migration buffer (gray); and finally, data is sent to the replacement PACS (blue). On the left, the rate limiting process is sending to the target (R_T) as evidenced by the large slope (increasing gray area). On the right, reading from the source (R_S) is slower, limiting the downstream process of sending Studies to the rate of reading from the source.

Of course, the scenario on the left is advantageous. It is quicker overall. The site can go-live prior to all Studies completing migration. Generally, the goal for go-live is to complete two to three years of the most recent Studies and 100% of high demand data such as mammography. Migration can then proceed in the background with a high priority prefetch queue for studies triggered by worklist. Decommissioning the source product can occur as soon as the acquisition modalities begin sending to the replacement product.

Input from source system is the furthest upstream process. PACS and VNA products must meet clinical workflow demand but may not perform much beyond that. DICOM Query-Retrieve (Q/R) services can be relatively slow, with Study-per-hour rates ranging from two to four digits. Moreover, these services load the source system (CPU and database) degrading clinical workflow. This exacerbates the rate problem as it then becomes necessary to limit migration to nonworking hours to maintain usability. For a migration of significant size, the input rate from the source system using DICOM services is nearly always the bottleneck. Downstream rates cannot exceed that rate.

However, with direct access to storage and the database the input rate is limited by network or storage bandwidth. System load is negligible. The rate of directly reading Studies is usually orders of magnitude faster than using conventional DICOM services provided there is sufficient network bandwidth, the site has read-only credentials to storage and database.

It is important to note that after images are sent from the acquisition modality, post-processing system, or QA station, the PACS may apply changes or additions to the tags to the DICOM data. Often, such changes are stored in the database but not in the files on the storage system. Therefore, the migration software must apply the changes stored in the database, and comprehensively verify that the resulting images are equivalent to their DICOM Q/R equivalent. (A 2019 work item proposal to DICOM for an Enhanced DICOMDIR intends to provide a standardized alternative to database connection).

The speed benefit gained by direct access scales with the size of the migration. Small migrations may not warrant direct access unless the motivation is to migrate proprietary information not available with DICOM.

The output rate to replacement system is nearly always the rate limiting process when using the rapid, direct access approach. For large migrations of many millions of Studies, daily Study rates of hundreds of thousands are desirable, however PACS performance requirements aim for clinical use and don’t sustain rates that high. As Studies enter the new system, the PACS queues database operations and other tasks as part of its ingestion process, consuming significant CPU resources and database bandwidth. The queue can grow so large that migration into the replacement PACS must stop to allow the system to catch up and reduce the backlog. The replacement system must be provisioned well enough to meet the schedule.

Consult with a PACS and VNA vendor to learn the ingestion rate and test early if possible. Post-go-live rates must sustain input from modalities, plus rates from the migration server. The migration system can send Studies with prefetch triggered by modality worklist.

Pauses and interruptions are often key factors that prolong migration. The earlier illustration is a simplified picture. The illustration below shows stalling due to various conditions, some of which are discussed below.

Intermediate processing steps involve exception handling and data upgrades. Some processing steps require human supervision, including validation that the various image SOP Classes and presentation state display as they should. Other cases involve resolving exceptions such as missing images, conflicting tag values in the Patient, Study, or Series Information Entity, or missing entries in metadata crosswalks (mapping tables). Yet others involve dependencies on other inputs such as ADT, orders, and reports to update Study metadata, or to satisfy sequence constraints such as when the target PACS requires patient identity or the order prior to the images of the Study.

Until the processing steps complete, migration blocks the affected Studies. Blocked Studies consume space in migration storage, reducing the effective size of the buffer. As long as the migration buffer has unblocked Studies to send, migration can proceed; Studies sent and verified are deleted to make room for more input from the source. If the quantity of blocked Studies fills the buffer, migration becomes deadlocked.

Storage limitations increase risk of interruptions reading from the source PACS thereby adding risk to decommissioning the source on plan. The risk to go-live also increases, especially when the rate of reading from the source is the rate limiting process. Therefore, it is important to not to underestimate the amount of storage needed. Starting the migration on time to move data to the replacement product reduces risk, as does consultation with the migration experts to understand, anticipate, and prepare to resolve blocking conditions as timely as possible.

When the effort to resolve block conditions is large, another option is to hold the problem data and migrate it only as needed, on demand. Laitek provides a Semperdatau00ae Atrium solution that allows users to search, fix, and send needed priors. The effort to retrieve on demand, when the patient is available, may be relatively small and lower cost. Other features can be added to this solution, such as Study Importer of external priors and conversion of proprietary Hologic 3D mammography to DICOM Standard Digital Breast Tomosynthesis.

Author Doug Sluis, PhD is a consultant on Quality & Interoperability for Laitek Inc. His experience includes software development, systems engineering, test automation, interoperability, industry standards for electronic medical records, and quality and regulatory compliance. Doug has spent decades developing and applying Standards (DICOM, IHE, coding systems) to enhance products and clinical information continuity within clinical workflow.