This is not a story about second marriages or kids. One marriage is more than enough for most people, and grandkids are a lot more fun than raising your own. Yet just as reading about raising a child and actually doing it are totally different, so, too, is replacing your PACS or RIS vendor.
 |
| PACS consultant Michael J. Cannavo. |
The concept is great, but what you'll face is totally different, just as two kids can be completely different.
I have done several PACS migrations, yet my most recent experience was as different as night from day compared to prior ones. It was nothing we did or didn't do that made it different, but just a perfect storm of different vendors and file formats, database structures that no one had ever seen before, and much more.
With that in mind, here are the lessons I learned.
One man's DICOM is not another's
You would think that DICOM is DICOM, but as I have said time and again, DICOM is the most nonstandard standard ever developed. While there are mandatory fields that all vendors must adhere to, things like grayscale presentation states (GSPSs -- basically, the window/level settings that accompany how a particular image was read), annotations, and a host of other areas are often stored in a proprietary manner by the vendor.
The number of supported service object pair (SOP) classes and unique identifiers (UIDs) also vary from vendor to vendor. Things like DICOM modality worklist (MW) and modality performed procedure step (MPPS) are modality-dependent. All this means that replacing one vendor with another isn't as much "plug-and-play" as "plug-and-pray," and it often significantly increases the time projected to perform defined tasks.
You may also need to factor in time and engineering costs for unanticipated "gotchas." That is why you should always provide the migration team with as much information as possible, as the software version for which they have performed migrations may differ from what you have. That is also why it's crucial that you choose a company with the resources available to do the engineering work required to make the migration a success.
DICOM is not the same as vendor-neutral
Most vendors say they can export images in a DICOM file format, and nearly all can. Just as one company's support of DICOM varies from the other, nearly all vendors have things in the way they store their images that are proprietary. That does not make them vendor-neutral.
True, one vendor should be able to read another vendor's DICOM Part X image file, but in a PACS you also have to deal with the database, which, just like the image, is often proprietary as well. DICOM and vendor-neutral are not synonymous terms.
Vendors have no legal requirement to provide end users with data in a usable form
Believe it or not, nearly every PACS contract indicates that a vendor's only requirement is to provide the end user with data at the end of the contract term. Nowhere in the contract does it say the data have to be readable by anyone but the providing vendor.
Some vendors might say they will provide data in DICOM Part X format. But because there are so many format variants, Part X alone is pretty much worthless. Also keep in mind you need the database information as well, and few, if any, vendors will allow third-party access to the database.
In fact, most vendors will not even allow a third-party provider access to what they consider "their" data at all. This recently spurred a rather interesting conversation between me, the vendor, and my client, in which I used the words "being held hostage."
Needless to say, the vendor took exception to this comment, claiming that "everyone does it this way." What's sad is that I can't disagree, although I did so want to ask that momism: "If everyone else jumped off a bridge ..."
Most end users have felt for years that simply asking for images in a DICOM file format was to be the equalizer they needed to preserve the investment they had in a system. Obviously, it wasn't.
Frankly, I was duped as well, never expecting that vendors either have so many proprietary components in their systems or cling to proprietary approaches for so long. Even now, merely talking about a vendor's long-term plans for a vendor-neutral archive (a development that should be blasted from the rafters by their marketing and PR departments) requires signing a nondisclosure agreement. Why is anyone's guess.
Vendor-neutral archives are also not the only solution. Managed service providers also offer solid solutions, as do some of the cloud-based vendors. Still, the name of the game is getting away from proprietary archives and into a vendor-neutral environment as soon as possible.
It's important to have a rudimentary understanding of the U.S. government's meaningful use requirements for its IT incentive program to understand the importance of standardized data. Meaningful use has three stages beginning in 2011. PACS and RIS fall into stage 2, which takes place in the 2013-2014 time frame and is designed to encourage "the use of health IT for continuous quality improvement at the point of care and the exchange of information in the most structured format possible." The last six words say it all: in the most structured format possible.
PACS end users who allows their PACS vendor to continue to use proprietary file formats in their archive and proprietary databases is actually hurting any chance they have to recover some of the $78 billion allotted for this program. Those looking to replace existing systems this year or next should automatically consider a vendor-neutral archive, managed service provider, or cloud-based solution versus the vendor-provided archive that comes standard with each PACS.
Just keep in mind few, if any, vendors will provide any form of discount for not using the archive software in their system. Those in long-term application service provider-style contracts should also consider migrating data over now, even though they still may have several years left on their contracts.
This is because the dollars for this program are slated to go away in 2015, and the sooner you start, the more money you can recover -- more than $100,000 between Medicare and Medicaid. The biggest challenge is finding a vendor who will work with you sooner rather than later, as most are just now laying out their vendor-neutral archive connectivity plans.
It's never as easy or as quick as it looks
The data migration we worked on was supposed to take about 10 days to transfer 40,000 studies. Three weeks later, we were still migrating data. Much of this delay had to do with the way the replaced vendor stored the data in DICOM -- an extra character here or there that the receiving vendor could not understand.
Every time something "funky" would come across, everything would grind to a screeching halt. It really was no one's fault -- just the unexpected -- so plan on at least double the time projected to do the migration.
Data migration involves a lot of radiologist time
Radiologists need to do quality control on all the images coming across. Typically, there are many images that need to be matched, deleted, or identified further before being migrated.
You need to make sure the reports match the images and the images match the database. All too often, they do not match, leaving you with "orphans" that need to be manually addressed. Any study editing that needs to be done here, from patient demographics to study tags to study descriptors, can and is usually done here. To that end, RIS reconciliation should also be considered mandatory, even though it can easily double the migration cost. It's worth every penny.
Reusing hardware isn't always a good idea
Given the state of the economy and lack of available capital funds, every facility is looking for ways to cut corners. Many do it by trying to reuse PACS hardware -- or at least the workstations. In theory, this is great, but it is fraught with practical considerations.
Most vendors do not allow third-party software they haven't provided on their workstations without it voiding the warranty. Most vendors also won't allow an end user to reuse a workstation without both certifying the configuration and condition of the machine, as well as addressing things like software licensing.
Nearly every PACS vendor will also exclude any uptime guarantee without its having provided the hardware and software. Realistically, though, most uptime guarantees have no teeth behind them or are fraught with so many exceptions that they are rendered practically worthless, anyway.
More pragmatically, there is really no easy way to test the new system with the old if you have two sets of applications software that reside on a single workstation. Not only would you have to change applications constantly, but having two versions of the software on a workstation may degrade the performance of the workstation.
Finally, no vendor will allow you to reuse the system server hardware; there are just too many variables to consider, from the operating system on down.
You need to run parallel systems for a while
Consider that a replacement PACS is like getting remarried when you still share kids with the ex, although the plus with PACS is you only have to deal with it for months instead of years. Like it or not, the ex is going to be involved as long as the kids are around, so it's best to maintain a good relationship there.
Understand that you can't just unplug one PACS and plug in the other one. You almost always need to run both systems in parallel while testing the new PACS in a clinical environment. Putting the new PACS through its paces also takes time. A smart organization will keep the old PACS operational until the new system is clinically accepted, and only then pull the plug on it.
Due diligence can only show you so much
You review the literature, do in-house demos, go on site visits, talk to end users, and maybe even get back a detailed request-for-proposal (RFP) response. Now you pick the vendor.
That is the extent of most end user's due diligence. But when you add it all up, you maybe have the equivalent of five dinner dates before you say, "I do," and then wonder why the system doesn't meet your every expectation.
It's crucial to set realistic expectations for the system and, above all, know what you both want and need from it. Having a checklist is a good start, from both a workstation and functional/operational standpoint, but you also have to be willing to accept the shortcomings that you didn't have time to test for, along with all the positives for which you initially selected the system.
The definition of insanity ...
... is doing the same thing and expecting the outcome to be different. Each day I see end users advancing to second- and even third-generation PACS using the same outdated RFP, taking the same outmoded approach, using many of the same team members, and then expecting to get different results. It's only when things get tough that they call me in, and by then it takes twice as long to extricate them from the mess they have gotten into.
Questions that need to be asked often aren't, or if they are, the answers given by the vendor weren't properly interpreted. "Can" is different than "does"; "should" is different than "will." A misinterpretation can be costly in so many ways.
Most hospital attorneys also don't know how to read a PACS contract, yet they have the hospital sign on the dotted line without having a clue what they are having their facility sign for. Without sounding too self-serving, even if you plan on doing everything in the evaluation process internally, at the very least have someone who really understands PACS contracts review the contract before you sign it. You would be amazed what you will find.
Every vendor has its own idiosyncrasies
The last time I checked, nearly 90% of buyers buying second-generation PACS bought one from a different vendor. The end user almost always expects it will be different with a different vendor, and while it is different, it's usually different in different ways.
If you believe statistics, nearly 50% of all first marriages and 67% of all second marriages fail. Why is the second marriage failure rate so high, when it's hoped that we all learn from our mistakes? Because the marrying party brings the same baggage into the second marriage as they did the first and does things the exact same way.
Just as marital counseling can help save a second marriage, so, too, can PACS counseling, asking very pointed, direct questions. These include things like: What did we like? What didn't we like? What are we looking for that is different? What was in and out of our control? What do we both need to do differently? I nearly always have my clients ask these questions, and the answers are eye-openers.
Cooperation and coordination between all vendors is a must
Whenever you are doing a transition, there needs to be a neutral third party coordinating the efforts between the vendors. We had three separate vendors in this implementation -- one each for the RIS, PACS, and data migration -- yet all worked incredibly well with each other with no finger pointing, largely because there was someone involved who oversaw the implementation.
Cooperation with the outgoing vendor can sometimes be a problem -- after all, they are being shown the door -- but this can typically be worked out Most vendors are usually cooperative to the level they need to be, especially if a service agreement is still in effect and the system is still being clinically used. Despite the cynic in me, I still believe that every vendor wants what is best for the end user and vice versa.
There are a plethora of other lessons learned, but these are the main points. Knowing what areas to address and what to look for it makes it a lot easier the second time around.
By Michael J. Cannavo
AuntMinnie.com contributing writer
August 16, 2010
Michael J. Cannavo is a leading PACS consultant and has authored nearly 300 articles on PACS technology in the past 16 years. He can be reached via e-mail at [email protected].
The comments and observations expressed herein do not necessarily reflect the opinions of AuntMinnie.com, nor should they be construed as an endorsement or admonishment of any particular vendor, analyst, industry consultant, or consulting group. Rather, they should be taken as the personal observations of a guy who has, by his own account, been in this industry way too long.
Related Reading
Building a Better PACS: Part 5 -- Vendor-neutral archives, February 8, 2010
The 2009 PACSman Awards: Red, black ... or both? December 3, 2009
Building a Better PACS: Part 4 -- Warranties and liability, September 15, 2009
Building a Better PACS: Part 3 -- Look before you leap, July 2, 2009
The DRA and PACS: One hospital's story, April 14, 2009
Copyright © 2010 AuntMinnie.com
