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:
I just love it when people agree with me! And on this point as well:
. . . (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.
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.
10 comments :
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 PCAS "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
Nice writeup. At Proscan Imaging, we take a very similiar 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.
Interesting piece & comments. Maybe helping radiologists to be more effective is simply about helping them access a wider choice of software products and at a lower cost?
Traditionally, radiologists' access to advanced imaging software involved a large capital investment in the software for their workstations. I believe what's innovative about Medicexchange.com is that it's aiming to supply these solutions in a low-cost, on-demand and digitally-downloadable format for the individual radiologist.
An extremely thought provoking argument. As a health care service provider, my conversations with radiologists and vendors tells me that this discussion is long overdue.
Only a few of the traditional vendors have listened to what we have to say. Most of their sales tactics are based on trying to convince you that their product does everything you need. The pretend to listen to what you say you need and then run through the usual features. I want to shout YOU'RE NOT LISTENING. I very nearly did once.
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.
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.
P.S. Since you inquired about contact info, my email is mbmrad at gmail dot com.
The first thing we should think about is our love affair with the acronym PACS. I think it reflects outmoded challenges- storage and comms.
Matt,
I also read the journal of digital imaging article. you have a great point in suggesting that an open platform could breed more innovations at the edges. As a software developer, I am trying to understand what is the level of control that would provide 3rd party developers the most value - a balance of providing fine-grained control while hiding the complexity from the user.
One of the most active plug-in community in the pacs world that I see is Osirix. The Osirix extensions seem to be more image processing algorithm focused than the workflow examples that you had cited at UPMC. So it would be helpful if you could elaborate on the software interfaces that you would want to enable more customized workflows. Thanks.
Dalai,
as far as your concern about not having the resources to develop customized extensions, perhaps the pacs vendor could establish a rich user community that promotes sharing of the mashups/extensions developed based on the vendor api of individual institutions much like what Matt had described with the firefox community. Or the vendor could actively collaborate with the user community to productize some of the extensions created by the user community.
Dalai,
Another similar approach to that discussed so far, is for the healthcare provider to fund open source projects. At the risk of sounding like I'm just promoting myself, the company I help run, ClearCanvas Inc., is an open source healthcare IT developer. We are currently partnered with the University Health Network in Toronto, Canada, who funds us to build a "next-generation" system for image and workflow management starting in radiology. Because the project is open source, and is designed with extensibility through a framework and API, anyone can extend, customize and integrate this system into their particular workflow.
Post a Comment