Australian Adam Addresses Agfa Agony

I posted my article, “I’m Not The Only Critic of Impax 6.0” exactly two months ago. This morning, I received the following comment from Adam, who hails from Canberra, Australia:

This article regarding Impax 6.0 highlights many deficiencies in the product, but also makes obvious the user’s lack of training and/or ability.

Many users of IT software continue with a particular product because of its familiarity. The direct port of the Image Area from previous version of Impax in Impax 6.0 appears to serve a useful purpose – it drastically reduces a radiologist’s learning curve in a version migration. I personally think that the focus of the initial release of Impax 6.0 has been the change in architecture for the benefit of the enterprise, rather than a feature-list change for the benefit of the radiologist. Granted, many of the issues listed are valid and frustrating. However, complaining of series linking difficulties because the images switch size clearly demonstrate that the Lama does not understand Windows Control Panel mouse preferences. Similarly, had the Lama actually had his PACS people show him the Simple Search feature, he might then appreciate the simplicity of searches. Another – understanding the so-called tool toggling – can actually serve a useful purpose if one uses the extended tools attached to the selected tool (such as the variable W/L rate activated through the middle mouse button). The Lama is not the only one unhappy with various features, as would occur with any software. I think, though, that the Lama has focused too much on the effect on the radiologist and not enough on the benefit of his clinical referrers.

OK, let’s examine this carefully. I have used Agfa products since the mid 1990’s, going from Impax 3.0 to 3.5 to 4.5 to 5.2 and now to 6.0. I think I am familiar with how they work. Adam takes the usual defense that if you don’t like my toy, it’s all your fault, and nothing to do with the toy itself. In the process, he disparages me, as well as Nick and Darby, the Agfa trainers who did a great job for us. Anyway, those who have taken similar Agfa journeys know that there was a major change in many functions between 3.x and 4.x, when the toggling and clone windows and so forth were introduced. So, that was not an attempt to cushion the old users, but rather a deployment of new approaches. True, this has been carried lock, stock, and barrel into 6.0. As an aside, Agfa people did agree that the purpose of 6.0 was indeed to move to a different platform rather than change anything for the radiologists. Was this a good idea? I don’t think so, obviously, but Agfa did. I like automotive analogies, and this reminds me a lot of Saab. They are known as rather esoteric, doing amusing things like placing the ignition switch on the center console by the gearshift. They have a loyal following, but the rest of the world is used to doing things in a different manner. You don’t see too many Saab’s out there relative to everything else, and no other company does the center console key.

In his rush to condemn me for having problems with Impax 6.0, Adam has ignored a few things. Agfa gave access to Simple OR Advanced search, and not both. Our IT people chose the latter, to our detriment. The image size thing that Adam alludes to was an acknowledged glitch in Impax. If one allows a double-click to resize an image to 1:1, it will override any other function. This is a poor design, and should be removed. Changing the double-click timing might help, but not much. And don’t even start with me about toggling. I understand why it’s there, but it just bogs me down, and I wish it would go away.

Finally, I just have to sit in amazement at Adam’s last comment that I’ve focused too much on the effects on radiologists. Uh, sonny, I am a radiologist, and my viewpoint is pretty much ingrained. Now, don’t get me wrong, I do understand that clinicians use the system, and I encourage them to do so. I have been in discussions with a very eloquent orthopedic surgeon, orthodr, on AuntMinnie, who is a very well-versed in PACS, and he is making me understand more and more of the clinician’s needs. On the other hand, I’m not going to sacrifice functionality or put up with confusing, unintuitive tools in deference to the clinicians. I would submit that what works well for those that use it 24/7 to do their job should work pretty well for those who use it occasionally. At least the former group has to take precedence. For some reason, that is a controversial viewpoint, but I think it is very valid.

Impax 6.0 is doing a little better. The crashes have all but ceased, but much weird and esoteric behaviour continues. I am most troubled these days by very slow refresh of screens, as well as the propensity for the thing to open an older study when I want to see the patient’s latest. And so on.

I do appreciate Adam’s defense of Impax, although I’m sure Agfa appreciates it more. Sadly, he does fall into that same trap of blaming the user, when it is the product that has problems. There is a very strong current of “I’m from IT and I know far better how this thing works and how you should use it than you do.” There is considerable condescension to radiologists as well, implying that they are unable or unwilling to learn a new platform, and no doubt that describes many of my bretheren. Still, even the least computer-savvy member of my group was able to sit down at an Amicas workstation and be proficient with it within 30 minutes. That should tell you something. Sorry, Adam, but the ultimate purpose of PACS is for radiologists, and clinicians, to care for their patients. This is not a possession of IT, and it cannot be treated as such. The Lama understands that much.

"Take One For The Gang!"…The Agfa Development Team Comes To Town

My previous posts about Impax 6.0 have been the source of much conversation, especially in Waterloo, Ontario, where Impax 6.0 was developed. Due to various complaints, including those posted on here on the blog, and also many from my partners filtered through our IT folks, a high-level group of Agfa developers did indeed come to visit from the far North. They spent two days with me and with my partners, and I think everyone would consider the time well spent.

I think the poor guys were expecting something like Osama bin Dalai to greet them, not the adorable little fuzzball that they found here. I’m pretty benign in person, at least most of the time. Apparently, the team was given a send-off suitable for a departure to Baghdad. “Wear your Agfa condom, and thanks for taking one for the gang!” Nice to know that I’m so feared everywhere but my own backyard, where I’m either ignored, despised, or laughed at. When I asked why they thought I was such an SOB, my very own hospital’s PACS administrator piped up, “It’s because of your blog!!!” Thanks. I never would have guessed that. But, the visit was really productive nonetheless.

Impax 6.0 must have realized that it had more to lose if it made ME look bad than if it made its parents look bad, and like any petulant child, it misbehaved quite badly the moment the Agfa folks walked in the room. My workstation displayed the dreaded error and crashed three times within the first 5 minutes of their visit. I swear I didn’t monkey with anything to cause that. Really. To ice the cake, the whole system went down for about 30 minutes later that afternoon, which I have heard was due to someone putting on a Microsoft patch without checking with Agfa first. Easily fixed. But this all set the tone for the visit. As of yet, we don’t know why the workstations are crashing.

I have openly wondered just how Agfa tested this product, and if there were any real, live radiologists involved. I asked this question again, and again, the answer is yes, and in fact there were about 20 of them. I could not really drill down to whether or not these were Agfa users exclusively, but I rather think they were. That might explain to some degree why the viewer portion is a direct port of that from 5.2, which was a tweaked version from 4.5, which was a tweaked version from 4.1. The differentiation was made, however, between testing like they did, and in-the-field real-life observation, like they were doing with us. The former got them to where we are today, and the latter will get them to fix where we are today, and go forward to a bigger and better system. Well, a better system, anyway. This is probably the take-home lesson for Agfa, and really for ALL PACS companies. There needs to be a great deal more effort toward involving practicing, PACS-savvy radiologists at every step of development. Granted, they won’t agree on everything, but they will ultimately hash out a workable path, and viewing in a production environment will yield multiple clues about functionality. And crashes.

I stated for our guests, the childish, yet profound Dalai philosophy of PACS: The image has to get into my brain via my eyes, and the interpreation has to get out of my brain and into the microphone via my mouth. That’s it! Anything that distracts me from concentrating on the IMAGE is bad, although some interference is necessary, or we’re back to film. (Gee, no buttons, no controls, just hold it up to the light…those were the good old days…) So why does Impax 6.0 have, in their words, “enough controls that you could never use all of them if you changed one every day for a year?” (Can you say, “feature fatigue”?) Ah, but this is a deliberate choice! It is easier, I was told, to simply add a multiple-choice option than to tell user A that this item functions this way because user B wanted it that way and not your way. This example was used: if user A wants it to come in black, and user B wants it to come in anything but black, you need to offer it in black and white at the very least. Multiply that by 200+ variables, each with 2-5 settings, and you have a very large number of permutations. Now, the Agfa folks say they found (and were surprised by the discovery) that radiologists have somewhat of the tinkering spirit, and that they all want these variables. My group must be a bunch of primitives, because we all really prefer the simplicity and limited control set of a certain competitor. I think there is a fundamental philosophical difference here. Agfa (and quite frankly Amicas too) is listening to the voices of the buyers on the showroom floor, who are totally enamoured with the 39,000 bells and whistles available on a product which they haven’t actually tried in a production setting. Once you take the toy out of the box, you might find that the bells and whistles are so frustrating, it’s more fun to play with the box. Feature fatigue, folks, it’s a real phenomenon.

Let’s deal with some of the issues on my doo-doo list, and see where we are. I am happy to report that a number of those issues were instantly solved by changes in user profile settings. In particular, the problem with the measurement tools disappearing if you click too rapidly turned out to be due to the activation of the 1:1 tool. It assumed that a rapid double-click meant that you want to enlarge a small image to fill the whole screen. Actually, I do like to do that on occasion, but I do NOT like having my ruler disappear in mid-measurement. So, we shut off the 1:1 thing, and my ruler works properly. Why this design was left in place, I don’t know.

We actually could not reproduce the situation wherein the wrong prior is selected, so perhaps that was fixed by increasing the number of priors pre-fetched from near-line storage. Whatever. The series bar will be docked at the top of the screen with smaller images, I think. It will work better than it does now in that configuration. Refresh problems may be due to the individual workstation hardware.

The Search problems will be solved in a forthcoming update by making the Simple Search available with Advanced Search afterall. Why wasn’t it there before? Well, somebody assumed that clinicians would be the only ones who would want to do simple searches, and that rads would want to do advanced searches, so they made it an either/or proposition. The Agfa folks were rather surprised to learn that the vast majority of my searches are simply by patient name. Just ask me, I’ll tell you!

Hanging protocols became an interesting topic on many fronts. I pointed out that the new and improved hanging protocol setup was still impossible to use by the average rad, like me. There was considerable surprise that I would want to do my own hanging protocols. With a bit of frustration, I demonstrated how Amicas does it (I don’t think I violated any NDA’s….), which is basically drag the series to where you want them, and save this as a named hanging protocol. Wow, what a concept. As it turns out, one of my partners had a similar conversation, and the Agfa guys actually set up a protocol for him. But, once he logged out, and in again, it was gone, something we have seen with some of the other settings. No clue what’s wrong here, although there was suspicion on some of the other items that the settings are not circulating between our three parallel production servers. Now, that’s another interesting point, if I may digress. I was assured that the whole enterprise could run very nicely on one production server, with one more for testing, and one for fail-over. That’s how Amicas does it. No one seems to be quite sure why we went with the belt, suspenders, and staple-gun approach to keeping our pants, I mean our PACS up.

Getting back to a study you have lost is a problem, especially if the machine crashed, because you lose some changes that were made before the crash, or if you use the master “exit” button for that matter. There is a list of the last several studies that you have marked as dictated, which you can access if you happen to know that right-clicking over a particular black spot at the bottom of the viewer will get you there. Rather like playing Doom. Hopefully, there will be some sort of indicator placed here for the unintuitive like me.

The Voxar re-re-re-deployment problem would be helped markedly if the cursor at least showed some indication that Voxar was selected, and I’m told that is an easy fix.

Clone windows and tool toggling are here to stay. The concept of any series in any viewport just didn’t seem to impress anyone.

One of the biggest problems we are having is one I neglected to mention in my list, that of multiple people accessing one study. Amicas and even (gasp) Centricity solve this logically: If you touched it first, it’s yours, and if someone else tries to get in, they can look, but they can’t touch. Not so with Impax. I can be reading happily along with the dicatation status button clicked to “Dictation Started”, which should knock the study off of my partners’ lists, but it doesn’t always, mainly due, I think, to the fact that the worklist hasn’t refreshed yet. But instead of telling him to get out of my study, it tells me that he’s in it and would I like to give it up? Totally backwards. Add to that, my partner could accidentally click the dicatation button again, and mark the study as dictated, when he just intended to start on it. Try as I might, I could not seem to get the concept across that this was really, really bad for us and needs to be changed ASAP. I finally just said, “I want you to do it like Amicas does it. Period.” It seems, that some of Agfa’s academic customers want the ability for a resident to start a dictation, and an attending to finish it, so they don’t want to lock out this function. Well, I was just told that the easiest way to keep your customers happy is to give them all the options they want. Fine. I absolutely want to be able to lock down a study in the manner described above. Please make that happen. And by all means, give the academs what they want, too, but let me turn it off.

And so, I’m back to where I started. I really need to say that Impax 6.x is a monumental achievement, despite it’s flaws. To port a huge program from C++ over to .NET and to make it web-deployable ain’t easy. (I say that like I’ve done it 17 times last week….) The Agfa team should be very proud of what it has accomplished. Now, let’s build on what we started this week. Impax 6 was developed somewhat in a vacuum, that is, there was not adequate influence from users of other products, and there was not adequate testing in a production environment. What we did this week should be absolutely mandatory for all new PACS products: have the programmers and such sit next to a radiologist while he uses the system, and get instant feedback for improvement. Do this with at least 100 rads, and not only will you iron out the bugs, but you will discover newer and better ways to do things. And you may find out that toggling of buttons, and text screens, and cloning of windows just isn’t the best solution.

So, what do I say now to potential buyers? Frankly, I think you need to wait, although I am very confident that our crashes will be fixed, and that the repairs and upgrades outlined above will happen in a very timely manner. I will let you know as soon as this occurs. In the meantime, Happy Thanksgiving, eh?

I’m Not The Only Critic…of Impax 6.0

We crusaders (read that as whiners) are often met with the following response: “Everyone else is happy/satisfied/pleased with X, so we don’t know what you are complaining about.” Thus, it’s always nice to get some support from unexpected quarters.

This morning, I received the following comment on my “Good, Bad, And Ugly” post:

I just want you to know that your problems are not isolated. I have been watching an Impax 6.0 rollout since last summer at another institution and have not exactly like what I have seen. To me (an IT/business person) Impax 6.0 is a shiny new wrapper on the old Agfa PACS. Yes there is a new front end and yes there is the ability to tie into the system using webservices, but I am not sure any of that matters. Many of the radiologists do not like and want the old version back. To me AGFA really needed to hit a homerun with this version. Anything short would not be enough. I just don’t think that they did.

Wow. This is what I have been saying for a while now. Agfa ported the viewer pretty much in toto from Impax 5.2. Some of my partners are showing some nostalgia for 5.2, but in the end, I don’t think Agfa changed a lot overall. Sadly, they brought forward most of the bad as well as the good.

My whining may have had some effect, although our hospital’s chief PACS administrator really wielded the heavy club for us, and I am forever grateful for her efforts since she finally realized just how much trouble we are having. I don’t know all that was said to Agfa, but I can guess, and as a result we will be visited by some of my good friends from Waterloo this coming week. (If nothing else, they will enjoy the weather down here.) I’m very glad they are coming, and what I hear of the composition of the group, they will actually have the power to do something about some of our problems. Personally, I hope they have the ability to do a near-complete rewrite of the system, because that may well be necessary. Sitting here, on call on an otherwise lovely Saturday morning, pounding away at Impax 6.0, it is pitifully obvious that Agfa did NOT test this program in any sort of high-production environment with rads that were familiar with other products. Agfa has told me differenly, but I just can’t believe it based on what came out the other end. (And that is a deliberate allusion.) Here is a partial “doo doo” list (hey, this is a family blog!) that I hope to see addressed:

  1. Crashes, crashes, crashes. We have found one or two things that will trigger a crash, but for the most part they happen randomly. I thought CRL and .NET were so very much more stable than JAVA…..
  2. As often as not, the wrong study among a series of new and old studies will be selected for on-stage status. More often than not, the wrong comparison will be selected. I spent 10 minutes with a clinician poring over a mass that had apparently grown rapidly, only to find that Impax 6.0 had brought up a much older comparison. Egg on my face, and on Agfa.
  3. Series bar…a very poor implementation indeed. The series bar holds thumbnails for a study that has several different series, such as an MRI. The bar has inconsistent behaviour, usually pops up over what you want to see, gives unintuitive control over distributing the series, etc. This needs a big revamp.
  4. Things like rulers and elipses may not stay active long enough to actually use them. There is nothing so frustrating as placing the measurement cursor over a nodule, clicking, and having the whole ruler revert back to the window/level tool or something before the measurement is placed.
  5. TOGGLING….Please tell me who approved of the “toggle” concept, and I’ll make them listen to my poetry until they beg for mercy. This, of all the Agfa approaches, is the one that makes me tear my hair out. It leads to lots of other problems, probably including number 4 above, as well as constant re-deployment of Voxar 3D in an otherwise excellent integration. By toggling, I mean that if you click a button, it is still active until you unclick it. This leads to a ton of problems, trust me, and Agfa is, to my knowledge, the only company doing this. It needs to be ditched, and brought back to the way everyone else does things, that being only one tool at a time. If I click window/level, my tool should stay that way until I click something else. Actually, the window/level tool may have been the impetus for the design in the first place: Click the tool, then click in the image, then manipulate the window without another click until you like what you have. But why not just do the click-and-hold thing that EVERYBODY else does? Yes, getting rid of this is a major rewrite, but you guys really should have thought of that before inflicting it on us.
  6. Window Toggling is another major problem. The color or outboard monitor shows a state-dependant display, geared to which exam is selected in the viewer. Even after several months, it is still disorienting, and it can lead to problems like those in number 2 above.
  7. If two studies or exams are displayed, tools will only work on the one in the leftmost monitor. Applying a tool such as window/level to a study or series may cause it to shift to another monitor.
  8. The screen is rather slow to refresh or repaint when moving to a new study or series. If reading from a worklist, and for some reason, you didn’t read the first study, that first study flashes briefly on the screen before the next study in line loads.
  9. The “Search” function is a complete disaster. Either a simple search (which I have never seen) or an “Advanced Search” is available, but NOT both. Really shortsighted move, boys and girls. What do I search for about 95% of the time? A patient’s name, and to get to that on the advanced search, I have to scroll half-way down a list of two dozen possibilities, then set up a search. This was probably the brainchild of a brilliant engineer, who had absolutely no idea of how we actually do things. It is incredibly powerful, but incredibly frustrating the vast majority of the time. Please just give us the simple search in addition to the advanced extravaganza, not instead of.
  10. There is no easy way to get back to a study you have bombed out of, say due to a crash, unless you happen to remember the patient’s name. Even 5.2 had the old bookmark that held the name of the last viewed patient.
  11. The concept of clone windows as opposed to being able to drag any series to any viewport is a pain. How about doing what the other folks do?
  12. Hanging protocols are still unusable by the average doc. There has been an improvement in their set up, in that one no longer needs to understand machine language, but the new and improved drop-down interface is still going to be the domain of programmers. Sorry, we need something we can actually operate at the user level.
  13. Table position linking works fairly well, although I much prefer the Amicas method wherein you press one button and that’s it. Sadly, Impax 6.0 has a very nasty tendancy to, ahem, toggle back and forth between one-on-one and multiple windows at just the wrong time, such as when I’m trying to link two windows. There seems to be some sort of a mouse click timer issue here. Please fix it! I’ve almost smashed my mouse five times in disgust over this one just this morning.
  14. Hot-key programming seems to be retained only intermittently. I’m wondering if there is a problem transferring the settings between our THREE application servers.
  15. “Sticky” window settings, column resizing, and the like, is not always, well, “sticky”. Perhaps this relates to 14 above. Possibly related is the fact that sometimes window/level changes will apply to the whole series, and sometimes not, requiring the reactivation of the series-wide control. Why doesn’t it just stay put!
  16. As noted in previous posts, we have been thrown for a loop by the fact that things that were supposed to be individualized are not in the production model. Having items such as window/level presets, precanned comments, etc. set up as global for a user-class, i.e., radiologists, has led our own PACS people to take the control away from us, leading to more problems. In particular, the button to add precans still exists, but because we can’t use it, it bombs the program. Give me back my individuality!
  17. The measurement tool works differently than any other in the business, mainly because it places the measurement right in the middle of the line you have just drawn. Now there is a little handle to grab to move the number out of the way, but if you are measuring a small item, that handle is impossible to access, and the number is left to obscure the lesion. How about throwing that number off to the side? Even ScImage does that!
  18. And lest I forget, there is no workable spine-labelling tool.

This is only a partial list…my partners are helping me put together a much longer and more extensive tome. I have high hopes for the impending Agfa/Mitra visit. I just wish they had come by to see how an average group operates BEFORE they wrote Impax 6.0. But they didn’t. So, we are in a jam. We have a system that is no better, and in many ways worse than the old one it replaces. The only real improvement is web-access, and that is indeed a step up from good old Web1000. Still, we are left with few choices. We can suffer through these problems, waiting for Agfa to fix them at their leisure, we can demand to revert back to Impax 5.2, or we can insist on a forklift replacement and go with another PACS. At this point, none of those are really acceptable. I can only hope that the Agfa/Mitra team is committed and empowered to fix this thing, although I’m not too optimistic given the fact that it took over three years of development to get it to this point! Still, if things are not going to be fixed in a very timely manner, option three starts to look better and better.

In the meantime, patience on the part of prospective buyers is still advised.


My friend quoted above sent the following comment about the above post:

Hi Dalai,I will take issue with your first point about .net/CLR stability. So Agfa picked a good infrastructure to use. But just because they did does not excuse them from writing good code, which in my estimation the code quality is probably poor. There are many rock solid .net applications out there. Impax just isn’t one of them.You mention testing and I really agree. But it isn’t just an Agfa problem. The development practices of PACS software run a gamut from good to bad, but most lean towards bad. I have observed issues that should have been caught in testing. If there is an extensive test plan in place and these issues are still being had then something needs to change internally.Let us know what happens.

Rather a harsh indictment of the programmers, but…. I certainly agree about the testing aspect. Note to vendors: Get a wide range of users to beta-test your latest and greatest. You might learn a great deal. Note to buyers: Do whatever you can to test your intended PACS product in a production environment. The more you live with it, the more you will come to know its good and bad points. Simple advice that no one follows until it’s too late.

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:


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.