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.
Even ScImage has a colorful worklist, based on this image from an ad about their version 3.0:
