If you can’t already recite it in your sleep, be sure you understand how your particular system handles demographic data. Where do your updates come from? How are they entered into the PACS? These are fundamentals you should have a firm grip on so you can fix problems consistently over the years. Another part of this challenge is how exams in the RIS are mapped to studies in the PACS. DICOM doesn’t specify a single way to relate exams to Studies, and different PACS and RIS vendors have different approaches. Your new PACS may have a more restrictive information model than the one you now have, requiring study merges or other transformations. Make sure you know how it’s done in your shop.
Maintain your archive. Avoid the “This Old House” mentality, referring to the old song that goes “Ain’t-a-gonna need this house no longer, I’m gettin’ ready to meet the saints.” It is natural to let the maintenance slide in anticipation of the new PACS, but you are going to need “This Old Archive” until data migration is finished, and it’s going to have to work very hard. So be cautious about letting the service contract expire, and in your migration contracts, make sure everyone understands the service responsibilities. It’s also important, throughout the life of your archive, not to let hardware errors build up. This is especially the case with archive media, such as tape, that wear as they are used. Here’s a scenario: Mr. Jones has a chest x-ray, and the automatic fetch of one of the older prior chest x-rays fails due to a tape read error. You could restore the offending study from a backup tape, but Dr. Smith, the radiologist, says forget it, he doesn’t need it for this particular case. Now, do you go ahead and recover the study from the backup? YES! That study, and likely others near it, is on deteriorating media. Recover the study before the situation get worse.
Also, throw out your trash regularly! To put it roughly, there is all kinds of crud that can build up in your archive. Most modality devices are set to automatically send images when studies are closed, so if you’re not watching, demo, service and test images can accumulate with bogus Patient Names and ID’s. One specific measure you can take is to assign a specific “TEST” Patient and Patient ID, and insist your service engineers use it when testing.
Similarly, if you have any “bad actors” on your network, like an older Nuc Med computer that outputs data that can’t be read on general PACS workstations, keep this item high on your priority list before too much bad data builds up.
What I’m really saying by all of this is “Don’t sweep things under the rug”. Data migration is a moving job, and when you move you take up the rugs.
Look out for proprietary image annotation that will bite you when you try to change systems. You know your referring physicians would love to have reports that show key images, and maybe even have circles and arrows to significant findings. And your current PACS vendor is offering you an upgrade that would make these multimedia reports available to referring physicians on a Web server. Before you buy, just make sure you aren’t going to lose this annotation and image reference if and when you go to another PACS vendor. If it isn’t in DICOM form, it’s probably not portable, although data migration vendors can sometimes convert the proprietary forms. For annotation, DICOM Gray Scale Presentation State (GSPS) objects can store annotation in standard form. Or, annotation can be stored in overlay planes in the image objects themselves. For image references, DICOM defines Key Object Selection (KO) objects that play the role of digital “Post-Its”.
If the radiologists have created the reports properly, and never rely on annotation to describe findings or locations, then preserving annotation in a migration might not be necessary from a medico-legal viewpoint. But it’s not pleasant having to make that argument to referring physicians accustomed to seeing their pictures and arrows.
From the data hygiene issues listed above to the end of the project, you’ll be happiest and most serene if you start early in preparing for data migration. Often timelines are forced on you, and this degree of preparation will not always be possible. But try.
Having everything migrated before go-live is the best. It saves cost and trouble, but can only happen with careful early planning. And of course, it requires sufficient time and migration speed to meet the schedule. We have had only a few clients do this, but the results are thrilling. In one particularly remarkable project, the client was sufficiently prepared and confident that in one night they tore out all the old PACS equipment and resumed clinical services on the new PACS the next morning!
Are you moving orders and reports in addition to images? Do you need enterprise patient IDs inserted in patient demographics? Are you taking this opportunity to update the procedure codes in your charge master? Are you splitting a big pool of image data into local facilities contexts? Or combining multiple facilities into a single archive? Is there a pot of poorly identified image data you need to either clean up or segregate from the “clean” data in your new PACS?
A system transition and data migration is a good time to improve your data. For example, to take best advantage of hanging protocol capabilities of your new PACS, you may want to clean up the procedure codes and descriptions in your Charge Master and update the study descriptions in your legacy data as it is migrated. Migration vendors may be able to help you understand your choices, but the choices are still yours, and some of them require consensus building in your organization that is difficult to rush. And many of them need to be completed before the first image data is moved.
There are a number of migration vendors out there, with different approaches, technologies and track records. Customer experiences are widely varied, and you should make sure the vendor you use has performed well in settings comparable to yours. It is easily possible for data migration to disrupt the operation of your current PACS, even with expectedly harmless operations such as inventories, so the capabilities and experience of your vendor are vital. And, poorly executed migration projects can drag out for years (not an exaggeration).
Most of the new PACS vendors have in-house migration groups they recommend you use, and it is important to vet the in-house migration group independently of your choice of PACS. Customer experience with PACS-vendor migration groups has been widely varied as well.
Stay firm and friendly with the departing vendor, but it is your system and your data, and the vendor wants your business in the future. The fastest migration methods require access to information stored in the files and media of the legacy PACS. If you have a competent and reputable migration vendor, there is no reason the legacy vendor should not provide the required information and access, or require large professional fees for their cooperation. Your departing vendor may be unhappy, but in this small medical imaging market, there is no benefit in alienating a customer whose business they want in the future. This is especially true when the departing vendor is a modality manufacturer! Sometimes you may need to escalate your requests beyond your normal field service contacts, but we have always seen higher management cooperate when confronted with an insistent customer demanding access to his data.
More often than you’d like, replacement PACS sales engineers do not configure the new PACS with enough storage for legacy data. Most PACS use lossless compression for storing image data, but the compression ratios on the legacy and new PACS may differ by as much as 30%. Also, your new PACS may store images in additional formats to facilitate Web access, and these may add another 25% to new PACS storage requirements. If you used lossy compression in your legacy PACS, be very cautious about storage requirements. If both your old and new PACS support storage in the same DICOM Standard lossy compression format, there may not be a net increase in storage on migration. However if the legacy PACS has either a proprietary lossy compression algorithm, or the new PACS does not accept the same DICOM compression format, then the lossy compressed images must be converted to lossless compression in the new PACS, and the new PACS may need 2-5 times the storage space for this data.
The migration project is not over until all the images are viewable on the new PACS or declared as exceptions and discharged accordingly. Plan and execute a validation process. It is not enough to assume that error-free DICOM transmission to the new PACS means the image was successfully migrated. Migration vendors have tools that can query or read back studies to confirm that they are valid and the right numbers of images are in each study in the new PACS. You will also want to “see for yourself”, by selecting a representative sample of studies and viewing them on both the old and new PACS. The manual validation is just a sample, and any errors you detect should be assumed to be present in other studies as well. If you see any differences, have your migration vendor fix them and apply the fix to the entire target archive, and then repeat the manual validation.
Note also that if in your new system you are using PACS-directed workflow, where the radiologist relies on reports in the PACS to determine if a prior exam was performed (regardless of whether there are images available), then it is absolutely necessary that the migration reports be 100% validated.
Author Fred Behlen, PhD is a medical physicist specializing in imaging informatics, Dr. Behlen’s career includes experience in industry, academics and healthcare provider organizations. Fred is a former faculty member of the University of Chicago, he is past co-chair (1999-2010) of the DICOM-HL7 joint working groups (DICOM Working Group 20 / HL7 Imaging Integration SIG). He is also past co-chair of the HL7 Structured Documents Technical Committee and a Co-Editor of the HL7 Clinical Document Architecture Release 2 (CDA).
2024 Hickory Road suite 208, Homewood, IL 60430, USA
10 John Street, London WC1N 2EB, UK
Strada Republicii 87, Cluj-Napoca, Romania
