When people are in the market for an onsite or cloud-based picture archiving and communications system (PACS) solution, they usually focus on all the shiny new features that they'll be getting. It's often only after they've decided on a solution that they consider how they might be able to migrate their legacy medical data into their new PACS.
Having both older and new medical imaging studies together in the same PACS isn't just convenient; it also helps you provide better healthcare to your patients, as physicians will likely want or need access to patients' prior studies to perform comparisons and understand changes over time.
If you're about to upgrade to a cloud-based PACS, you should think a step ahead by considering how you'll handle your legacy medical data. To do so there are several things you should consider in advance of making your final PACS decision.
Migrating to an Onsite PACS
If you've chosen an onsite PACS solution, either you or the vendor you're working with will need to take the time to migrate your legacy data onto your new equipment. However, it isn't always as simple as connecting the old and new systems and letting the data flow between them.
Medical Imaging Assessment: Complete Our Free Assessment to See if Your Solution is Right for You.
The legacy data stored in your prior solution may not be in standard DICOM format. That means, in order to move it from one onsite PACS solution to another, you will need to convert that data into DICOM format. Converting your legacy data to comply with the DICOM standard can be an extremely painful task and may require a dedicated programmer who's familiar with different medical record formats and can write customized code.
For instance, one of our past clients had millions of medical images that were stored in a proprietary format. To make matters worse, the client was unaware of this fact until they contacted us. The situation required us to run each image through a time-consuming and complicated conversion process to decrypt the images from their proprietary format before we were able to migrate the data. While we were successful in cracking the proprietary format in this case, you might not always be so lucky.
You also need to consider the magnitude of your legacy data when determining the amount of storage required by your new PACS solution. That storage will need to be sufficient not only for the new medical images that you'll be creating but also the legacy data that you'll be moving over, as well.
Put another way, you want to make sure the virtual house you're moving into has enough room for all of the data you're bringing with you.
Migrating to a Cloud PACS
With a cloud-based PACS solution, having sufficient storage space for your legacy images is generally not an obstacle. However, if you've chosen a cloud-based PACS solution, then you also need to consider the cost of housing your legacy data. There is no industry-fixed cost, as it depends on a number of factors, including how the cloud vendor you've chosen prices their services. Often your per study legacy data cost will be significantly cheaper than new images you add on a monthly basis.
With either a cloud-based or onsite PACS you should be sure you understand all of the issues associated with what will be required to migrate your legacy data well before the migration occurs. Make sure you understand both: the processes required and the cost which will be incurred. When determining the cost, be sure you understand the difference between new studies and the legacy studies you will be bringing along.
Whatever the answer may be, you should understand from your vendor exactly what is involved and what the entire process will cost before you decide on a solution.
Unfortunately, many practices often make decisions about their new PACS solution before they realize what the implications will be for their legacy data, including the cost of the move itself.
Do your research before you sign anything and evaluate how complex your legacy data migration will be, the costs associated with it, and how capable your vendor is of performing the migration. Otherwise, you run the risk of incurring surprise time delays and costs.