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...
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:
I just love it when people agree with me! And on this point as well:
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:
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:
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.
One of the authors (Matt Morgan) actually read my post, and responded as follows (although he didn't leave any contact information):
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 StentoriSite, 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.