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.