DICOM Migration Budget: Planning for Success

A DICOM data migration is a complex process that requires careful planning and execution. To ensure a successful migration, it is imperative to define the scope of the project and establish clear success metrics. In this article, we will discuss 8 key topics that need to be considered when creating the project budget.

1. Compare 3 or More Vendors

Creating a Budget for your DICOM migration project is one of the most critical factors that needs to be considered when defining the scope of a DICOM data migration project. The budget will determine the resources that can be allocated to the project, including the cost of hardware, software, and personnel. The budget will also determine the extent of the migration effort, including the number of data sets that can be migrated and the level of data cleansing that can be performed.

Many organizations will base their DICOM data migration budget directly from the vendor’s quote. Therefore, it is best practice to get quotes from at least 3 different vendors.  Each vendor should provide 2-3 recent customer references for similar migrations. Due diligence is key in selecting the right vendor for your DICOM migration. While the vendor quote is one key to the budget, In order to plan for a successful migration, the budget should also include an assessment for each of the following items.

2. Planning for Additional Storage

On the migration server: Each vendor will have a defined strategy and process for migration.  Some migration vendors will migrate on demand and perform a c-move from source to the destination system – this requires no additional storage on the migration server.  This method would work well for a very small migration.  Another vendor may query / retrieve the data to the migration server, perform QC, and forward studies to the destination.  Other vendors will perform a file level copy to the migration server and after performing QC on the data, they will forward the study to the destination.  Vendors who retrieve the study to the migration server, either by Q/R or by file level copy, will require additional storage in order to house the data during the QC process.  This means that during budget planning, the project will need to plan to provide sufficient storage allocation to the migration server cache for the duration of the migration.  This can be a significant amount of storage, often 50 – 100 terabytes.

In the destination system: The amount of storage allocated in the destination system to accommodate the data migration should be analyzed in the planning phase of the data migration.  Often migration engineers encounter situations where the customer has paused a migration for months waiting for additional storage to be allocated to their production environments.  This causes significant delays in the migration project, and can also impact production pacs performance if not monitored.

3. Assigning Resources: Internal Resources & DICOM Migration Consultants

An often-overlooked aspect to planning a DICOM migration project is the lack of availability of the internal PACS team to take on a migration. Ask any radiology IT manager and they will be sure to assess that their PACS team is overburdened with existing work and can’t possibly take on any more projects. Most radiology PACS admins that we work an average of 40 IT systems to manage, upgrade, troubleshoot, and maintain on a daily basis. Due to the existing workload of the PACS team, it is a best practice to contract with migration consultants to perform DICOM data migrations.

A DICOM migration that is properly managed by skilled PACS migration professionals can be an operation boon for years to come. However, a poorly managed migration using inexperienced or overly burdened PACS administrators usually results in a drawn-out migration that can negatively impact radiologist productivity and patient care. Some of the consequences of a poorly managed PACS migration include poor data reconciliation, mismatched studies, duplicate exams, duplicate patients, multiple , Due to the existing workload of the PACS team, it is often essential to hire external resources to perform these DICOM data migrations.

The number of resources needed will depend upon the complexity of the migration. The size and scale of the DICOM dataset, along with the requirements to migrate any non-DICOM data will increase the duration of the migration. Another item to consider is data mapping requirements and data cleansing which increase the complexity and extend the duration of the project timeline. A rule of thumb, the bigger the project, the more resources required to complete it. Large DICOM migration projects such as PACS replacement, VNA implementation, or cloud archiving require multiple resources to run effectively. This migration team includes a project manager, one or more PACS analysts, and technical experts who can manage the data migration process, monitor migration performance, cleanse the data, and perform validation checks.

Due to the complexity of the data and the impact a migration can have on imaging operations, it’s becoming a highly adopted strategy to outsource the daily migration work by using contractors who augment the internal team. An experienced migration engineer will be an advocate for the health system and will direct the migration vendor to ensure a successful and timely completion of the migration. The advantage of using an experienced migration consultant is they have the expertise and the dedicated time to manage and complete the project.

4. Determine What Data Needs to be Migrated (DICOM, non-DICOM)

In order to be successful and to know that your migration project is complete, it is imperative to determine what data is going to be in scope and be migrated. For instance, there may be 20 years of data in the PACS archive. Should all the data be migrated? Most of the time, the consensus is no. Most clients decide to migrate only the data required to meet state and federal mandates. Each state has data retention requirements for medical data. In order to make a migration plan, this determination is often made by committee which takes time and often includes representation from risk management, medical records, the PACS team, and legal teams. An example of a planned radiology migration includes everything from the most recent 7 years, all mammography in the past 11 years, all pediatric studies up to patient age 25.  Defining the data retention requirements will allow the migration team to streamline the migration and improve the timeline.

Some health systems opt to reduce the data retention, however, many institutions especially academic medical centers are retaining all of the data in order to monetize the data for research purposes. It is becoming more common for healthcare systems to contract with real world data vendors that curate and market the data to medical imaging research firms.

5. Defining Formats and Data Conversions

By understanding the data that is going to be migrated, the migration team can formulate a framework for the migration plan. It is important to note that medical imaging data migrations often involve the migration of both DICOM and non-DICOM data. While DICOM is the standard format used for medical imaging data, there are other formats that are used to store other clinical data. Some of these objects and formats may include photos in jpeg, scanned docs in tif, doc, pdfs, txt, json, etc. The number of formats encountered may be numerous, so establishing a migration oversight committee will help determine what data is needed.

When defining the scope of a DICOM data migration project, it’s important to consider the formats of the data that need to be migrated and the level of complexity involved in converting data to new formats. For example, many radiology PACS have breast tomosynthesis exams stored in Hologic’s proprietary SCO format. This data works perfectly fine in the SCO format when interpreted on a Hologic Securview™ Diagnostic reading station. However, the Hologic SCO tomo data needs to be converted to standard breast tomosynthesis objects to be displayed in PACS.  Performing an SCO to BTO conversion is recommended during a migration, to ensure the data is useable by standard viewers.  We have additional information regarding Hologic SCO to BTO conversion including use cases and justification for conversion.

Another format that needs to be considered is the Siemens CTO to BTO conversion. Siemens stores breast tomo in CT format and often converting this data into breast tomo objects is the best practice. Having CTO to BTO conversion allows the PACS viewer to leverage display protocols across manufacturers to compare current and prior tomo studies seamlessly.  A CTO to BTO conversion has also been shown to speed up image load times for radiologists, reducing delays in reading.

6. Data Validation Process

Data validation is a critical component of the DICOM data migration process. It’s essential to have a robust validation process in place to ensure the accuracy and completeness of the migrated data. The validation process should include data completeness checks, data consistency checks, and data reconciliation. It’s also important to have a plan in place to address any discrepancies that are identified during the validation process.
A best practice is to assign internal resources to validate the data in the destination system. This should be a straightforward process which entails developing a crosswalk for verification, and scheduling validation review meetings. An example list of DICOM attributes that should be verified in the destination system includes:

• Patient Level Attributes: MRN, Name, DOB, Sex/Gender
• Study Level Attributes: Study Description, Study Date, Image Count, Body Part
• Series Level Attributes: Series Description, Series Number

Despite best efforts, not all data in a migration project will be successfully migrated. It’s important to define acceptable levels of failure and limitations for the migration effort. This includes defining the types of data that can be excluded from the migration effort and setting realistic goals for the project. It’s also important to have contingency plans in place to address any unexpected issues that may arise during the migration process. Worst case scenarios can happen, including the migration server could fail and require reimplementation. Therefore, using a hardware based migration solution is the least desirable deployment.

7. Defined Timelines and Milestones for the Migration

While the overall project timeline has the biggest budget impact, there are several milestones to include in the DICOM migration project scope document. These are important to define both in the project and assign timelines to each: Project Kickoff, Server Implementation, Storage Allocation, Data Inventory, DICOM Data Extraction, Data Cleansing, Enabling the HL7 ADT interface, Migration Testing, Migration Start, Migration Performance Monitoring, Migration Completion, and Project Closure.

As with any mission critical project, timelines and milestones are components that drive the success of a DICOM data migration project. It is important to define realistic timelines for the project and establish milestones that can be used to measure progress. This includes setting deadlines for data cleansing, data migration, and data validation. A best practice is to have a contingencies plan and an escalation plan in place to address any delays or issues that may arise during the project.

8. Closing the DICOM Migration Project

Arguably the most important milestone of any data migration is the project closure. Project closure of a DICOM migration should include clinical acceptance for the closure of the project. This is a formal acceptance by the health system for the completion of all final tasks and setting a resolution path for all incomplete tasks. Sometimes data may not be able to be migrated or matched to an existing patient information from the RIS. Some customers opt to move such data into a separate archive or virtual archive within the PACS or VNA, to keep the data available, but separated from the main PACS data. This allows the data to be accessible, but not typically directly tied to the patient’s verified data.

In conclusion, defining the scope of a DICOM data migration project is a complex process that requires careful planning and execution. To ensure a successful migration, it’s crucial to develop the budget by considering: defining resources, data formats, data validation process, acceptable failure levels, and defined timelines and milestones for the project. By taking these factors into consideration, organizations can increase the likelihood of a successful DICOM data migration and improve the accuracy and completeness of their medical imaging and clinical data.