Quick-Start Guide to PACS Data Migration

PACS Data Migration – How to Choose Vendors

Changing PACS systems is a difficult process. It requires advance planning to avoid major issues during the transition.

Since a data migration must take place when switching vendors, some aspects of this process would ideally be included in the PACS replacement RFP. It’s a good idea to consider getting a vendor-neutral third-party to handle the migration. They can act as a buffer between the vendors, perform a database assessment to prevent problems and help to ensure appropriate items are included in the RFP prior to purchasing a new PACS.

It’s advisable that you start with a test migration to be make sure that the actual migration will proceed without difficulty. Some things to look for during a test migration include measuring real data rates for your site so you can plan properly, identifying potential problems, and how to prevent most critical problems.

Be sure that your third-party vendor is capable of migrating DICOM data from any PACS, regardless of vendor, content-type, or size. Their migration should run in the background on a server without the need for supervision. You should be able to specify ranges of data and that the migration may be interrupted and restarted as desired.

At the beginning of the migration, information about the source and target PACS is identified along with start and end dates of the studies to be migrated. If the process is interrupted by an issue, the transfer can be continued after its resolution. Data that has been successfully migrated must be tracked during the migration, as well as any failures, or data still in queue.

Proof of Concept Migration

NHS IT departments need to manage internal expectations and constraints relating to risk profile, the timing of migration, and of course return on investment. To address this, you should make sure to perform a Proof of Concept migration, with all the key elements functioning such as Continuous Data Migration of most recent studies, and an EPR Event Listener against existing RIS to pick up merges and patient name changes.

Migration can be run in batches with different attributes such as date ranges according to needs. The error rate should be monitored at this time and should be in the low single digits. When studies are erroring, the migration service will help you to determine why. When the cause is identified, you can correct the issue and the offending studies can be re-migrated to see if they go through.

Migrating Relevant Priors

Prior to taking your new PACS live, it is recommended to get the last 2 years of studies onto the system. This is quite important! You can always migrate studies that are older than 2 years in the background while the new system is up.

Relevant priors should be made available and online in your new PACS as a result of your migration. Any patient activity should cause that patient’s historical images to be pushed into your new PACS, even if these are older than the current date range being migrated. This means current-patient images will be available for instant access by clinicians even if they have older imaging.

How to Migrate PACS Data

It is best to migrate via standard DICOM services rather than direct file copy. One reason is related to updated entries made to your PACS database (merges, MRN, and name changes) received through ADT/ORM message over the years. They are kept in the PACS database and not written to the DICOM header until queried to pull the images out. This affects data integrity in the header (Metadata) of the image files.

An example of this might be if a patient ID is 1234 and the operator manually corrected the patient ID to 12345 after the scan when the images are transmitted to PACS. The header of the image will have 1234 as a Patient ID, based on DICOM files. Even when you update the PACS with the new patient ID only a reference with the new patient ID is stored in PACS referencing the the file. So PACS knows to update the header to 12345 when responding to a DICOM query, even though the flat file still says 1234 in the header. To get the most up-to-date data you have to DICOM query each study off of the old database.

Call us – click here for details – or enter your details below to request a no-obligation quotation

Ads

You May Also Like

UKRC e-Poster on Performance Tuning of PACS Data Migrations

UK Radiology Congress (UKRC) have published our e-Poster documenting our experience with high performance, ...

DICOM and IP changes for new PACS and VNAs

2013 means new PACS and VNAs for many NHS hospitals, and accordingly we have ...

Heatherwood & Wexham Park data migration to exoPACS VNA

Heatherwood and Wexham Park Hospitals NHS Foundation Trust chose Cypher IT’s exoPACS VNA and ...