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.

He'Brew, The Chosen Beer

Just found this at World Market. It's pretty good, and you have to love the name!

More Wagging

I haven't had this many responses on any other post, and I am really honored that the authors of the piece I originally quoted have taken the time to enter into a dialogue with me. This is the way progress is made, although I'm playing a miniscule part. (There are other very eloquent comments as well which I would urge you to read.) Here is what the authors had to say:

Jonathan Mates said...
Hi. I'm one of the other authors of the piece, and I thought I would chime in, as well.As someone who was at UPMC at the time we wrote the article, but has since moved on to a less progressive center, I understand your points about depending on industry to "do the job." Not everyone has the resources that UPMC has in terms of programmers. And I also agree that radiologists should not be expected to design and create their own add-ons. We were not suggesting this. What we were suggesting was that industry admit to being unable to customize their applications sufficiently to meet all their customers' needs (as others have echoed in your blog comments), but instead create the hooks and access that allow others to create their own solutions. Some vendors are doing this now, but many are not. At the same time, the mind set of radiology departments and institutions must change so that they see themselves as customizers (value innovators) rather than just purchasers of solutions. The state of coding has reached the point where you don't have to buy an expensive, high-powered coder in order to make effective solutions. I've even heard of places using motivated high school students to create some of their add-ons. But the institutions themselves and the people who hold the purse strings have to see the value in this kind of work and fund the efforts appropriately. But before they do that, they have to at least see that they have a choice in the matter - they can choose to be innovators, or they can continue to be dependent upon vendors for their solutions.As far as how many add-ons are necessary to customize something to one's liking, I think it depends on how complicated the radiology workflow is. If you have multiple different applications that have to be run at once (e.g. sub-EMRs, each with various bits of information), if you are covering large geographic areas, or other complicating factors (outside night coverage, residents, etc.), there can be quite a bit of customization necessary to make things run smoothly. As Matt said, this is more in the area of workflow than in basic functions of the PACS to view images. It also depends on your definition of "running smoothly." Someone used to walking everywhere would be ecstatic over a the improvements provided by a bicycle, but if they only knew that cars existed, they might not be so easily satisfied. For my part, having worked at UPMC, my standards for customization are likely to be higher than the average PACS user.And, of course, there will always understandably be radiologists in "the boonies" so to speak, who can't participate in development either because of lack of resources or lack of willingness to dedicate those resources. I would rather those become the exception, though, rather than the rule.

Matt Morgan said...
Of course I find this topic very interesting (despite the fact I wasn’t lucky enough to profit in any way from the sale of Stentor), so I hope you won't mind a few additional comments. :)It is definitely true that "the expertise required to even to add these optional extensions onto a PACS just doesn't exist at most places." This statement reinforces our point and call to action (remember it is a paradigm shift, which has yet to catch on). My question is, “Why not?” I believe it is simply because it has not been possible to do what we are proposing until now (for all of the reasons I state in the paper). Hence, there is no institutional structure (or vision) in place (i.e. department of informatics with a director, project manager, developers, etc.). But, you may say, “It would cost too much to pay for those people.” To this I say, “How much does it cost you in frustration, lost productivity, and worst of all, suboptimal patient care when the information systems and workflows are complex, isolated, and prone to error?” While these numbers are notoriously hard to pin down, I can say that my experience at UPMC has shown that by boosting information throughput and minimizing complexity and hassle, the department has been extremely productive and profitable. To be sure, there are economies of scale involved, so while smaller institutions will have the same frustrations, they will likely have a harder time justifying cost and ROI (perhaps this is where consultants come in?)One more point (for now). It’s not really just about the PACS anymore; it’s about streamlining the whole radiology “story” from order to final report (PACS 2.0 anyone?). Each institution is going to want to do this in their own “appropriately idiosyncratic” way, so we are suggesting that vendors design their products with this in mind, and then let the local expertise create the value innovation “at the edges.” Separate the user interface from the content—like a personalized Google homepage—you get to decide what and how to piece it all together. Radiology departments should have the same flexibility of organizing and displaying their workflow and plugging in “best of breed” solutions—not on the individual level, but as a department. For all the vendors out there, two words: web services.

I'm starting to become a convert to their way of thinking, although I have to sadly reiterate that this sort of thing just is not possible in my shop, nor will we have the expertise in the very near term. But I think there is a compromise position, which I alluded to earlier. We all agree that even the best PACS system may not satisfy the workflow requirements of most places, and that some customization is needed. (My personal ennui lead me to feel that the PACS viewers themselves should not be that customizable, if at all, as I have discussed ad nauseum.) Based on all the comments above, the solution for places like mine is two-fold. First, the vendors need to write their software to allow third-party add-ons. I believe the proper term is to provide hooks that the aftermarket programs can attach to for data-transfer. As I recall, Sectra does this quite well, or at least says that they do, and they allow numerous third party apps to work with their system. Part two is the assembly of a company or task force or whatever to write these add-ons. I still think that there aren't that many ways to skin a cat, and it wouldn't take that many different flavors to give a lot of us a great deal of extra functionality and flexibility. What do you think, everyone? We could call it the Dalai Software company, and I get 10% for having the idea. Seriously, this is the only way I will get this sort of thing at my shop. The bean-counters are not going to understant the need for even a minor level of programming ability, and there would be a lot of political trouble (with IT) at most places before all is said and done. I really think this middle-of-the-road approach has possibilities, now that I finally see the light of the concept.

A User-Driven Approach to Software...Putting the Wag Back in the Dog?

I do hope you are having a happy New Year so far! I am not really at the moment, as I am on call. Oh, well, just six more hours until the call service takes over. No, five hours and 59 minutes...58 minutes...

As a member of SCAR, I mean SIIM, I receive the Journal of Digital Imaging, which has a wealth of PACS information. An article in the September issue, which I finally got around to reading, took my fancy. "Toward a User-Driven Approach to Radiology Software Solutions: Putting the Wag Back in the Dog," written by Matthew Morgan, Jonathan Mates, and Paul Chang, from the University of Pittsburgh, discusses the evolution of the relationship between healthcare providers (that would be me) and the software industry. They note, as I have in my own bumbling round-about way, that it ain't working well anymore, and some new paradigm is needed. They propose a rather revolutionary concept, to accomplish this fix, one I'm not sure I'm ready to accept.

The problem is clear, although much better stated by Morgan, et. al., than I have managed over the years:

The . . . metaphorical reference to the industry "tail" wagging the healthcare "dog" appears justified. While industry is focused on market share, profit margins, and competition-driven engineering, quality healthcare providers and their knowledge workers are interested in customized solutions, optimized workflows, and "data-driven engineering." The result of these misaligned priorities is a gap between the generalized solutions industry is willing to provide and the optimized solutions healthcare providers want—a value innovation gap.

In many ways, this has been the thesis of my blog from day one. The industry gives us what they tell us we want, based upon varying degrees of actually talking to real radiologists out in the field. GEnerally, those attempts don't quite hit the mark. Some companies are convinced that they knows better what we need than we do. Some other companies seem to go back to the same focus group of reference rads again and again and sadly fail to do the job for the rest of us. You have heard me say this before, and lo and behold, the authors of this piece agree:

. . . (F)ocus groups can miss the mark for several reasons. First, vendors often focus on the wrong group. Instead of targeting expert clinicians who experience the real day-to-day pressures of practice, they tend to seek domain experts who are largely biased toward academics and enamored with technology. The result can be a self-resonating panel whose opinions and recommendations may not reflect those of the mainstream, thus guiding the vendors toward solutions that neglect a large contingent of users. Also, focus groups tend to favor consensus over individualization. Yet, healthcare providers are appropriately idiosyncratic, requiring customized— not generalized—solutions. Finally, focus groups assess what customers say they do, not what they actually do. Because there is often a great difference between the two, focus groups can be misleading.

I just love it when people agree with me! And on this point as well:

Another limitation of the industry-driven model is provider/vendor incentive misalignment. A good example of this is the value innovation gap—the misalignment between the customized solutions a healthcare provider wants and the generalized products that a vendor is willing to provide. Where healthcare providers want optimized solutions for their unique workflow and business models, vendors are looking to produce universal solutions for a mass market.

Again, this is more or less what I have documented. Remember how the Agfa folks said that to accommodate folks that want A when others want B, they just throw in a switch to give us both A and B. Universal solution indeed.

As a competitor in a free-market economy, the vendor’s goal is to maximize sales and market share. Consequently, it takes a "lowest common denominator" approach to software engineering, focusing its efforts on developing generalized solutions to satisfy the needs of the average customer. This economic strategy allows industry to maximize its sales and minimize its costs. Because multiple customized versions of a product are costly to support and maintain, once the software is purchased and has thereby met the vendor’s needs, any vendor promises of extensive customization after purchase are rarely fulfilled.

Well, in my Agfa example, it's more like a "Greatest Common Multiple" approach rather than a least common denominator, but you get the idea. One size fits all.

So, what's the answer to this dilemma? Having great respect for big companies, my thought is to work with them, still giving them the lion's share of development responsibilities, but demanding that they listen to their customer's input properly before writing a line of code. However, the authors of the article above have a rather different approach:

Healthcare providers must shed the self-perception that they are passive recipients of industry software. The expertise and innovation needed to solve the most challenging problems is found within the institution. Remember, the problem is not building software; it’s optimizing workflow. Fortunately, with today’s advanced technology and plentiful, talented programmers, the power to drive software development is finally within reach of the healthcare provider (i.e., the end-user). For most organizations, "build vs. buy" is a false dilemma. The most robust and flexible solutions will be a combination of both vendor and in-house products. To take advantage of this potential synergy, the healthcare provider needs not only skilled developers, but also the leadership and vision to guide them. Just as construction projects are prone to failures if contractors are used without architects, information systems are at risk without the leadership and strategy provided by trained informaticists. Local clinicians who are skilled and/or formally trained in Informatics are best positioned see the bigger picture and to "architect" this process.

Now this is a mighty bold statement. Basically, the authors are saying that the software companies need to provide a framework for computer-savvy docs and other healthcare informatics types to customize at each individual hospital. Hmmmm. It's a nice idea, but.... In many ways this goes against my principles, in particular my fear of "feature fatigue". They are advocating the ultimate in "Lego PACS", one which you actually have to assemble from the bricks on up. This is an incredible idea, and a fantastic opportunity for those who would want to participate in such a venture (me) AND who have time to do so (not me). Then you get into the questions of who is to decide how to do what. At some places, where IT rules, this approach would lead to the IT folks doing the design and assembly; maybe they would ask the rads what they want, and maybe they wouldn't. And even if there is a nerdy rad like me hanging around who could participate in this venture, we aren't guaranteed that he knows how the rest of the gang wants their GUI. I also have to ask the practical question of whether the tools even exist to do such "building-block" programming for PACS. Having seen many of my requests for changes go unanswered because of the difficulty of recoding the program, I have some significant doubts about this. Even if possible, I would assume that each vendor would add their own flavor to the framework and building blocks, and then we are back to the same bell-and-whistle race I feared originally, but if anything, it would be worse, with the addition of a zillion programming tools on top of everything else.

Perhaps the biggest unanswered question is this: Do we really need this degree of customization? Do various shops really read their studies in such different manners that we have to redesign the entire software production paradigm to accommodate them all? I think you all know my personal answer to that: No. Most people's eyes are bigger that their stomachs, especially when it comes to PACS features. Those wonderful bells and whistles that you just have to have to the exclusion of products that don't offer them often turn out to be unused once you get the darn thing home and running. But, what I've been saying is that the big PACS software companies need to listen more to what we the end users want and need. Where I differ with the authors above is that I just can't see doing individual development at every site. That would take a prohibitive amount of time, and I wouldn't vouch for the results out of some places. But participate we should. Here, the vendors need to reform their ways, those that led to this novel idea in the first place. As the authors state in their conclusion:

Innovation in these critical areas demands that knowledge(able) users take a more active role in driving the software development process.

With this I agree completely. But I just can't see creating and recreating and rerererecreating similar software at each site. The truth is, I think, that if not one, then a small number of sizes can fit all. When you go to the shoe store (OK, just checked my wife's closet, and that's a bad example, but whatever), you pick your size and the type of shoe you want. What would happen if you could custom make your shoes there on the spot? As it turns out, Nike lets you do just that. I let my son design himself a pair of individualized classics to the tune of $150. He wore them exactly 5 times and got tired of them. Lesson learned.

ADDENDUM

One of the authors (Matt Morgan) actually read my post, and responded as follows (although he didn't leave any contact information):

Nice to hear that someone read our article. I appreciate you points. In response, rather than full customization or "Lego PACS" as you call it, we are advocating something more akin to Firefox with extensions. You don't get to change the basics of the way the browser works, but you can extend it's functionality. We advocate this because we have had great success with this model. For example, using the open API of Stentor, we have created customized worklists not only for our divisions in radiology, but for our clinicians. We have extended the PACS with our own web-based radiology assessment tool that contains the patient history and technical information that has allowed us to go paperless throughout the enterprise. Also, for more efficient, asynchronous communication with the ED, we have extended the PACS with a web-based form for entering preliminary notes or "wet reads" that automatically launch when the study is opened and are immediately available for viewing throughout the system.In other words the "in house" customization has more to do with workflow enhancements and integration with other systems and less to do with PACS "featuritis" or deciding what color the button is.If you want more clarification, I'd be happy to add more.

Matt Morgan University of Pittsburgh Medical Center

Dan Braga, from Proscan, adds this:

Nice writeup. At Proscan Imaging, we take a very similar approach. Our PACS is used for viewing images and all workflow around it is done with custom applications. Because our PACS vendor (Intelerad) has a nice API, we are able to do this quite nicely. All worklists and RIS information are done in one application that controls the viewing application from Intelerad. In addition, we also build custom applications for other "workflows" such as outside entities sending us CD's as well as referring physicians viewing images.

This all puts things in a slightly different light, but.... My read of the article itself seemed to suggest a more radical revamping than what Matt and Dan indicate. I will certainly defer to the author himself as to what he meant, and it makes more sense in the end. Still, the expertise required to even to add these optional extentions onto a PACS (or even onto Firefox) just doesn't exist at most places. We have to keep in mind that the authors were instrumental in the development of Stentor iSite, which they sold to Philips for a significant sum (and I'm not sure why they still dabble in PACS anyway) and they certainly have the wherewithal to create these add-on programs at will. Likely the same for Proscan. But what do we do out here in the boonies? This is somewhat of a parallel to the focus-group problem. The solution proposed by Morgan, et. al., and validated by Dan Braga is indeed elegant, but how do we apply it here without their level of programming knowledge? I still insist that the state of coding has not reached the point where the average Joe Radiologist, even with a fair bit of computer experience (i.e., me) can sit down and easily construct an add-on app in a reasonable amount of time. I still have to depend on my pals in the industry to do the job. I just don't see much way around that.

Well, maybe there is one. We all agree that there is no perfect PACS out there, for whatever reason. I still maintain that there are not that many more add-ons that are necessary (or should be necessary, anyway) to customize the system to one's liking. How about if Matt and friends, maybe with the help of Dan and those at his level, establish a company or repository or something to design and sell, or better (for me) distribute these modules? In other words, if the PACS industry won't fulfill these extra needs, maybe a third-party can. Just a thought. I'll take 10% for my efforts.