Impax 6.0 Upgrade...The Good, The Bad, and the Ugly

Well, after much anticipation, trepidation, anxiety, and delay, our Impax 5.2 PACS was upgraded to Impax 6.0. I am told that ours is the largest enterprise to date that has undergone this transition, and it was not without some trouble. Fortunately, we seem to be past most of the pain, and now we have clear sailing into the Six-y future.

Let's start with the Bad, some problems with functionality, then move on to the Good, and close with the Ugly, the problems with the actual upgrade.

The Bad isn't much worse than I have already reported, but there were a few unsuspected little problems. First and foremost is the fact that worklists and window/level settings are class-wide, and not individual. By that I mean that all users of any class, say, radiologists, have to share worklists and window presets, and probably some other stuff I haven't discovered yet. The worklists are indeed highly customizable, but now, I have to depend on our PACS people to create them, instead of just doing so myself. And if I don't like one of the window/level presets, that's too bad. Minor problems, true, but still annoyances for a tinkerer like yours truly. In fact, there is a troubling lack of individualization at several points. The Configuration screen, pictured below, gives its user access to EVERY machine in the enterprise. You can see the list of machines on the left. Because of this wide open access, our IT/PACS people won't let lil' ol' me into this area anymore.

Why do I need to be in there? Two reasons. First, Impax 6.0 is a RAM-hog, or it will be if you don't change its default settings. It will sequester the majority of RAM available on your computer. That's OK if you aren't doing anything but running Impax 6.0, but at home, I need to run Amicas as well, for the other hospital system, and I need to have some memory, or I'll have to just shut off one program when I activate the other. There is a control within the Configuration screen that lets one adjust how much RAM is available for other (obviously unimportant) programs. Monitor configuration is a little problematic, too, and it is also controled from the Configuration screen. To make a long story short, 6.0 just doesn't work right with a four-Barco monitor setup. We tried it, and it sucks. Impax 6.0 is very, very dependent upon the text/list screen. However, monitor setup requires that you tell the program which screen gets the text, where the images are to start, and whether you want the images on one, two, or four monitors. Note that three wasn't included. Attempting to use all four Barco's for images resulted in tons of toggling between text and images for the first monitor, and also yielded some very strange glitches such as duplication of the study on monitor 1 over to monitor 3, and blanking of monitor 2. It just doesn't work. So, Dr. Dalai, in a rare blast of intuition, suggested making these four-bangers act like three-bangers, in other words, use the first monitor for text, the middle two for images, and shut off the fourth. I had to beg our IT folks to do this, but they did with the express understanding that it was my idea, and my fault, and that I made them do it. Well, it worked quite well, and my partners prefer it for the time being. We eagerly anticipate the arrival of a fifth monitor and bracket thereof for the four-bangers, which will again allow images on all four Barcos. (For some reason, it took over a month to decide what bracket to use, and they still haven't been ordered...seems we need to go through all the proper channels to cut a P.O.)

Other problems include the lack of migration of older reports to the system (it's now brokerless, so I guess the reports have to go to the Mitra context server?), lack of retrieval of the proper prior (e.g., old hand radiograph is displayed to match new chest radiograph), and a rather annoying but transient flash of the "Available Series" bar into the middle of the screen when changing studies. Also, the "cine viewer" control keeps popping up inappropriately. Unlike the Amicas RealTime Worklist, which updates instantly, the Impax 6.0 worklists update only periodically. Ours is set to go every 5 minutes, but I'm convinced it doesn't cycle anywhere near that often.

Now, some good news. Without citing numerous specifics, I have to tell you that Impax 6.0 really does work, and once some of the glitches are fixed, it will work better than Impax 5.2. The toggling of windows is still disorienting, but I'll get used to it.

And now, the ugly. A major upgrade such as this is never trouble-free, and ours was definately no exception. The procedure was done over a weekend to lessen the, um, impact, although our weekends are about as busy as weekdays. The weekend crew operated from a temporary server which could not be user-customized, and only had 2 weeks of priors. Still, the weekend went OK without major problems. Now, Monday was a different story. I was off for a religious holiday, so I didn't have to participate in the fun, but I sure heard about it. To make a long story short, the whole thing slowed to a crawl, and there were well over 100 exams that couldn't be read. This included at least one positive scan that could not be viewed for over six hours. The culprit was, of all things, a virus scanner on a server. This was removed around midnight, and two additional processors were placed in the Oracle server, and things improved. But on Tuesday, we had more problems that shut everything down. It seems that there was a problem on the database side where a database cleaner didn't activate, but Agfa fixed this and says it won't happen again. Then we had a problem with the IIS (Internet Information Service) on one of our three servers (yes, it took three application servers to make Impax 6.0 run on our fairly large enterprise.) The service sometimes didn't work at first, but would do better if bounced. Agfa thinks they have this one fixed, but they are watching it anyway.

OK, we got through all this, and everything is running well at this point. But, to have 100 studies stuck in ethernet purgatory is to us a disaster. The positive study that languished for six hours is quite literally a disaster. We failed in our mission to provide patient care, and we could have caused harm to the patient. And there may have been more cases like this. This is where sometimes IT just doesn't grasp the mission-criticality of what we do. When I used the word "disaster" to describe Monday's events, I got this response from the IT heirarchy (italics are mine):

Actually, the performance issues have been taken care of and I feel"disaster" is a pretty strong statement. I would call it more of an unexpected set back. Impax 6.0 is functioning extremely well and we are moving forward with the upgrade as planned. If you are receiving feedback today that is not as we have experienced it, please do let us know. Any system upgrade of this magnitude is expected to have some issues,we are just working our way through them. We appreciate all the support and cooperation from the Radiologists staff as we have been working hard to make this a reality for them and (the enterprise).

This came in on Tuesday, just before the other problems became apparent. Now, I do want to congratulate and thank our PACS people, and the Agfa folks, too. They all worked very, very hard to get this upgrade accomplished, and they didn't stop until it was complete. Agfa folks are still around to make sure we are comfortable, as some of my illustrious partners never bothered to go for training, and then they expected to be brought instantly up to speed. But the whole "unexpected setback" thing troubles me greatly. As I have said many times, once a department goes filmless (and paperless, for that matter), the PACS is the department. It dictates what you do, how you do it, and when you do it. If PACS croaks, the entire radiology department is dead, and the hospital has lost critical functionality. Sorry, when we lose PACS as we did Monday night, that's a disaster. Plain and simple.

I posted a poll a while back to see who owns PACS at various places. The results were:

IT------------(7)
Radiology---(15)
Both---------(19)
Other--------(2)

Total votes:--43

I have to think that the majority position is the ideal in this venue. Radiology obviously understands its own workflow, and brings incredibly valuable knowledge to the table. IT, of course, brings tremendous expertise to the picture, because PACS at its essence is a network of computers. IT folks get to play with the shiny new computers with the blinkey lights, and you would think they would be anxious to move ahead as rapidly as possible. But somehow, IT often gets really bogged down in bureaucracy. This may have its rewards, as a disproportionate number of CIO's seem to make it to CEO level. I get the distinct feeling that the IT folks want to protect their computers and networks from us, the Great Unwashed. And, as above, there can be a significant disconnect when it comes to our mission-criticality. A computer is just a computer after all, and if it croaks, you simply replace it. Would that we could do that with patients. (Maybe some could be replaced before they croak? Just kidding!) The bottom line here is that a partnership between Radiology and IT is ideal if not critical for PACS to function properly. Yes, PACS is just a mess of computers and wires and such, but my patients' health (and my livelihood) is at stake if things don't work right (or at all). Everyone needs to be on board.

Sigh. Now that I'm in the PACS business myself, I can see how easy it is NOT to be all things to all people. But as the boss, I get to make sure things work the way I want them to work, and that's a good start. Impax 6.0 won't ever work exactly as I would have specified, but it will do the job. Stay tuned for more reports as we progress with the great experiment.