“When I’m asked if changing information system vendors is as bad as it sounds, my answer is ‘yes, it’s going to be as bad, or worse, than it sounds’,” Steven C. Horii, MD, director of medical informatics in the department of radiology at the Hospital of the University of Pennsylvania, said at RSNA 2015.
Whether the change is because the company you worked with is leaving the business, the product can no longer support what your practice does, it can’t be expanded to the enterprise needs, or due to corporate decisions, Horii assured the audience that it would be painful.
He offered some insight and background about his own department’s recent information system change to make the process hurt a little less.
In Horii’s case, his hospital had a mini PACS they used for ultrasound. The company was leaving the business and couldn’t find anyone to take it over, so they were forced to find another vendor. His department also had a migration to the electronic medical record (EMR) system that grew into an enterprise electronic health record system, causing his department, per the vendor’s suggestion, to change their RIS to the one that’s built into the EMR.
“My IT guys had a lot of sleepless nights,” Horii said.
The most painful, Horii explained, was accessing the multiple terabytes of data that was in their present database.
“It’s the one that’s going to take the most time and probably give you the most headaches,” he said. “It’s much more complicated often than what the vendors will tell you.”
Horii suggested data migration be looked at as far in advance as possible. It may not seem difficult, most radiologists look in their PACS, put DICOM images in and get DICOM images out.
“The dirty little secret of PACS is a lot of vendors store the DICOM attributes in their own proprietary database tables and then reassemble DICOM objects when you ask for it,” Horii said.
There isn’t anything wrong with this, he said. “The DICOM police, of which there are none, don’t say you can’t do this, as long as you can ingest DICOM and give it back in its proper form according to your conformance statement, they don’t care what you do with it once it’s inside your PACS, for the most part.”
Another important factor in data migration is discrepancies in patient name and demographics and general data inconsistencies. Horii’s examples included name changes from marriage or divorce or children who share a name with their parent and therefore only have different birth dates, he also mentioned a head CT study that actually contains the head, chest, abdomen, and pelvis.
“We’ve got a trauma patient, we scan him from head to toe, all those things show up as one,” he said. “There might be four different orders for that, but typically the stuff gets dumped into one order and one accession number and the PACS worklist only lists one study with 5,000 images in it.”
Also problematic are studies that have incorrect order request numbers, read-only memory, and images with annotations and measurements that are in DICOM private elements.
“This is no secret, [vendors] will tell you right up front that they do this because they can process it better if it’s in their own DICOM private elements,” he said.
Most practices are probably not even aware of how many of these problems exist in their database, Horii said. Horii’s department did a data migration 10 years ago and expected to see a couple thousand inconsistencies, there turned out to be over 20,000. And that was with much less data than is archived now.
“During the migration process, everyone one of these problems is either going to be manual intervention or some sort of processing through additional software,” he said.
Horii suggested understanding how migration software reacts to errors, some software may automatically correct inconsistences in patient names, for example, but pay attention to what would happen if it got stuck.
In Horii’s experience, the software got to a case that it couldn’t fix and sat there, locking up the entire migration process, rather than acknowledging it as a problem case and moving on to the next one.
Determine who is going to do the database cleanup while negotiating the new contract, he said. If it’s your department that will do the cleanup, consider negotiating a chargeback rate.
Another problem Horii’s department encountered was with interfaces.
Between the HIS and RIS, there were well over 100 interfaces that needed to be tested.
“These things touch a lot of stuff and the whole idea behind enterprise integration is the reduction of the number of interfaces by integrating everything,” Horii said.
Watch out for decisions based on running in a test system, he said. While a test system is better than no system, no test system can fully replicate the live system.
When their new vendor estimated how long it would take to migrate the database in Horii’s department, they assumed they could use the servers 100% of the time.
“You’re doing clinical work every day, you can’t give them those archives 100% of the time, you have to pull stuff from them,” Horii said.
Make a realistic migration schedule, he said, and consider contingency plans if you miss the dates, including who pays for the old system if the changeover date is missed.
Horii’s department had to keep the old system running because it was in clinical use. However, the old system vendor was no longer under contract for service and the new system vendor didn’t want to pay for maintenance of a system they were replacing.
“It took several months of negotiating with both vendors to get the situation resolved,” he said. “The new vendor wound up having to pay the old vendor to keep the system running.”
In this particular case, the new vendor underestimated the migration time so it was technically the vendor’s fault that the old system had to be in use longer than expected, Horii explained.
Horii said to get a prenuptial agreement with your PACS vendor. It should include guaranteed access to the old database, and if the vendor is going out of business, you want access to their database schema (which will mean something to your IT folks, Horii said).
You also need details of all the intersystem interfaces: DICOM, HL7 messages and what they contain/do, and where they go. Also consider the option to continue service contracts on a month-by-month basis with some cost constraints.
“Tell the old vendor that until you migrate, you need to keep running the old stuff, you’re no longer under full contract so you can try to negotiate a month-to-month or week-to-week contract,” Horii said. “Often, vendors aren’t happy so they are going to jack up the price, so you might want to put some cost constraints on there.”
The continued service should be on the same terms you had when you had the vendor on a full contract.
Ask for guaranteed engineering support for the transition, which includes working with the new vendors and negotiate a schedule of charges for the engineering support.
When considering a HIS or RIS replacement, vendors complete comprehensive surveys to determine your workflow and how it can be accommodated by the new system.
Horii’s recommendation: “Everything that you do on your current system, ask the vendor how to do it on the new system…don’t just say ‘we can do it, show me you can do it’.”
Customizations and changes to make the product fit the requirement should be determined up front, and you should note which requirements are absolute and which are flexible, he said.
Watch out for survey teams that only talk to supervisors, it’s the people in the trenches that are doing work every day and have figured out the short-cuts and workarounds. Make sure they talk to the right people, Horii said.
Changing information system vendors is going to be painful, Horii said. There are some things you can do to give yourself some analgesia for the pain, though.