We at Innowave are remotely manning couple of Radiology Workflow solution for Hospital and Diagnostic centers in Singapore, Middle East and India.
A 300 bed hospital in South India gave us an opportunity to implement Radiology workflow Solution. The workflow covers the entire workflow starting from Radiology Registration, Modality work-list integration, Image Storage, Local and Remote viewing, Reporting and Physician access. Without going much into details, we had forced with a challenge to migrate the old studies. One of our key unique selling points was to view prior studies.
After few hours of Google search, we found migration solutions are expensive and time-consuming. Our team started to dig the existing PACS solution and found a best, easy and reliable way to migrate all studies.
Plan for Migration, is to export all studies from the old Linux based DCM4CHEE PACS on to a new Windows based DCM4CHEE PACS.
- LAN Speed: The site had a very old network infrastructure, complete hospital is wired on CAT 5 cables, and the max network bandwidth is @ 80 Mbps. During busy working hours the bandwidth drops down to 5 Mbps.
- Hardware: The existing PACS hardware was relatively low powered and almost reached its “end of life”.
- Zero Downtime: This site is already film-less, customer was very particular on Zero downtime, means a single study should go unreported. So the only best time we had to work is after 10:00 pm till 8:00 am in the morning.
- Knowledge on Linux and DCM4Chee Software: The existing PACS were on Ubuntu, we had zero experience on using Linux systems.
- Migration: Data integrity is the key issue. Don’t want to lose even an Image.
- Existing PACS Server: The old server is an Intel Dual Core with 2 GB of DDR2 RAM, 2TB Single hard disk, (No redundancy), Ubuntu 64-bit Operating System.
- LAN: CAT 5 Network, the hospital was reluctant to upgrade the network as it would cost a bomb.
- New PACS Server: Intel Xeon 6 Core, 8 GB DDR3 RAM, 5.7 TB of RAID 5 Storage, Windows Server 2012.
- Database: We decided to retain the same MySQL database as back-end even though MsSQL Server was our default choice, reason – for reliable migration.
Migration Data Size:
- 2 Years of Patient Data.
- Modalities : 1 Multi slice CT, 1 .35T MRI, 2 X-ray units with a CR and 2 Ultrasound systems. All systems are DICOM compatible.
- Approximately One TB of J2K Lossless compressed data. The potential raw data size could be above 2.5 TB.
- Approximately 70,000 Patients with over 1.2 million images.
- Database File Size is 900 MB.
Why moving to Windows Platform from a very stable & affordable Linux box.
There is a limitation running DCM4Chee on a Windows 64 bit platform using Image Compression. The Java Image IO will support only 32 bit JDK, this results in maximum accessible memory up to 2 GB per process. Even though the Hardware has 8 GB of RAM but DCM4Chee can max utilize 2 GB of memory.
In spite of this huge limitation, why we wanted to migrate out of Linux, the key was easy support and maintenance of the entire solution. Hospital IT staffs are familiar only with Windows Server environment, all other HIS, CMS, Payroll and Accounting solutions run on Windows Server environment. So the natural choice is Windows.
We also did a peak load analysis. DCM4Chee never consumes more than 1.5 GB of memory. We use only pure DICOM Services C_Store, C_Find and C_Move. Occasionally we use WADO for Physician access. Images are Jpeg 2000 compressed on the Fly during C_Store and archived to Storage location.
Why MySQL Database
The old database is MySQL, it makes sense to export and re-import the same database into the windows box. This will clear many data integrity checks. There is also an option that we did evaluate MsSql Express 2012. But we decided to go for MySQL for compatibility with old data.
Steps followed for DCM4Chee migration.
1. Install DCM4Chee on the New Server.
For a novice to implement DCM4Chee PACS is quite a task, we had failed few times before we can succeed. We followed the steps explained in this link .
- These are the components we used for this setup. (Download link)
- JDK 32 bit (jdk-7u25-windows-i586 ) as we are using J2k compression.
- If you are installing on a Windows 64 bit and would like to compress the archive, then install 32bit JDK.
- Make the necessary changes suggested in section (8. Mac OSX and Windows x64 specific changes for the WADO service), in the Installation manual.
After some basic test as suggested in section (16. Test DICOM storage & 17. Test object retrieval) sections of installation link. Now the system is ready for Data Migration.
2. Migrate Images
Find the old archive location for the Online Storage.
- Identify the Archive location. Lucky in old server there was only one Online storage location.
- Open JBoss console http://localhost/jmx-console, login and under dcm4chee.archive select ‘group = ONLINE_STORAGE.service = FileSystemMgt’.
- Below click on listAllFileSystems(), this will list the list of file systems and their absolute path.
- The output should look similar to this “FileSystem[pk=1, X:\Freedom_Pacs\Studies, groupID=ONLINE_STORAGE, aet=FREEDOM_PACS, ONLINE, RW+, userinfo=null, next=]”
- “X:\Freedom_Pacs\Studies” is the root folder for the Images.
Share Archive folder.
- The best way to copy these images are by creating a Read only Network share. Do not allow everyone access, restrict access with a user rights.
Copy the contents of Old Archive folder to the new PACS Archive location.
- We had challenge in copying these files over the network, the data transfer was clocking 4 MBps, which could have resulted close to 2 days of copying as there are over 1.2 million folders and files.
- Since both the server had Gigabit network cards we tried a network cross cable, using this we copying speed hit 40 – 70 MBps / Second.
- We decided to copy the images to a RAID 5 storage location for data redundancy.
- Once the copying was done we check the no of files and folder copied and their storage size to verify all images and folders are copied. Right Click on the root folder and select Properties to get this stats.
This completes the Image Data migration.
3. Migrate Database
Install SQLWorkbench in both server.
- MySql WorkBench 6.0 is an excellent tool for creating and managing MySql database. This tool can be downloaded from this link.
Export DCM4Chee Database
- Execute WorkBench and select the localhost as your database to operate.
- click on Management section and then on Navigator section. Select Data Export option, this will popup the list of database in the DB Server.
- Select “PACSDB” from the list, select the export location and click on Start Export.
- This will take couple of minutes to export the Schema and the data to the designated location. The time to copy is based on the database size.
Copy the folder to the new server.
- Using the same network share created to copy images, now copy the Exported DB Sql dump to the new Server.
Import DCM4Chee Database
- In the new PACS server, Execute WorkBench and select the localhost server as you database to operate
- Click on Management section and then on the Navigator section. Select Import / Restore Option.
- Select the option “Import from the Project Folder”, choose the folder recently copied to the new PACS Server.
- This will display the “PACSDB” database in the list “Select Database objects to import”.
- Select “PACSDB” from the list and click on Start Import.
- This will take couple of minutes to export the Schema and the data to the designated location. The time taken is based on the database size.
Tip : This takes 3x more time then export, could be because of inserting the records and Write speed. But what also makes us bizzar it is resetting the AE title to DCM4Chee. This completely disarrays the Database linking. The last section will deal how to fix this.
This completes the Database migration.
4. Assign Images and Database to the New Server.
By migrating the database and copying the Image archive, the new PACS server is all set for coupling the database and Image folder to the new PACS Server. Start DCM4Chee in the new server and follow the instructions below.
Assigning the Database to the DCM4Chee.
- If you have not changed the Default Name of the database “PACSDB”, then the database is intact to fire the worklist. You can check this by login as user http://localhost/dcm4chee-web3
Assigning the Images to the DCM4Chee.
The next is to link up the images. I read a lot about in DCM4Chee forums to modify the archive storage location and none had worked. So decided to debug the database. Followed these steps to update the archive root folder.
- Open MySql Workbench 6.0.
- Select the localhost server as you database to operate.
- In the Navigator section, select schemas and PACSDB from the database list.
- Expand this tree node until you see the list of tables.
- Select FileSystem table, this holds the list of Archive locations and their absolute path.
- Browse the data, by Right click and select top 1000 records.
- Ideally you should have one record with pk value = 1, change the directory path column as your Archive root folder eg X:\Freedom_Pacs\Studies.
- This path is the root path, under this you will have the folder that holds the images at the Year level. Lets say 2012, 2013, etc…
- The relationship between the table “file” and table “filesystem” plays a major role is identifying the image location.
- Actually speaking, the previous step should end the migration, but for some weird reason during the import phase, the AE Title is reset back to DCM4CHEE instead of the old FREEDOM_PACS.
- It is highly recommended to retain the old AE title, IP address and the Port No for the new PACS. Why, it saves lots a lot of time to reconfigure any modality or workstation as it add less misery to any PACS migration.
Technically this ends the complete migration, but to our surprise during Database import the script resets the AE title of the Study, Series and Images (Files) to the default DCM4Chee. If we do any DICOM communication, the client will report a Peer DICOM rejection error – invalid AE Title. The worst is, “during this time any WADO query can crash the entire DCM4CHEE service”.
This issue almost made us to abandon this migration plan, thanks to my team’s fighting energy- they found a work around and that is listed below.
To change the AE title back to FREEDOM_PACS we, followed these steps.
- Open JBoss console http://localhost/jmx-console, login and under dcm4chee.archive select ‘service=AE’.
- Scroll down till void updateAETitle(), enter ‘DCM4CHEE’ in prevAET and ‘FREEDOM_PACS’ or the AE title of the old PACS in newAET.
- Now click on Invoke, this took close to 20 minutes to complete its execution.
- Post this we have the complete solution working.
We tried this for couple of times to ensure that we have migrated all the data, our engineers could finish the migrating in less that 3 hours, though the first attempt with a huge learning took us close to 3 weeks. We have successfully migrated all studies and did some random test to confirm clean migration.
We wanted to document this so that, the 3 weeks of effort could be saved by fellow users in near future. Please write to me if you have any clarification or corrections.