Unfortunately, I can't disagree with anything you wrote. It is important that they get this right for so many reasons,…
I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).
I wrote this piece in April 2009.
It seems that everyone (other than software vendors) is talking about software usability these days. A long-delayed light bulb finally went off somewhere that suggested, “Say, these systems we have are cryptic, ill-suited to match real-life work flows, and maybe should have had some human factors review before they were shipped prematurely as usual.”
Usability is a hot topic mostly for ambulatory EMRs. It’s a logical (or, some would say, convenient) reason that doctors don’t use them. The problem vendors have is that those private doctors actually have a choice, unlike their hospital counterparts who have IT people making EMR decisions without their input (except maybe the rubber stamp approval of the gadget-happy, CIO-reporting, doc-turned-CMIO who hasn’t practiced in years.)
Hospitals are willing EMR buyers (although inconsistent EMR users.) Vendors in that market sell to the C-level who are wowed by a “cue the music, the future is now” video, a visit or two from top vendor suits, and maybe a promise of extra-special hospital representation on vendor committees or to provide allegedly welcome input on how to make the marginally useful product marginally better (meaning: sign here and we’re out of this hick burg for good.)
That’s the dilemma of PM/EMR vendors. Doctors who are mostly an annoyance in hospital sales (critical, interrupting know-it-alls who check their watches constantly) are the people who actually make the “buy” decision in practices. They have to actually use the product, so they are as critical as anybody would be when it comes to the tools of their trade. Poor design can’t be glossed over. There’s no big-picture visionary willing to ignore product realities and make a decision based on a futuristic video.
Hospitals are so intent to buy that they’ll just pick the best of the worst and live with it. Doctors in practice will hold their ground and buy nothing (which they have, in droves.)
Government payola will probably get a bunch of those unwanted systems sold, but not necessarily used beyond the “minimum necessary” to get a check. The government subsidy will be long spent, but the product will live on and be cursed frequently. Users will get used to the irrational design like they do in hospitals, although their productivity may never recover to the level it was using paper.
The problem with usability is that you can’t just bolt it on after the fact. It’s part of design, not last-minute touchup. The ARRA gold rush will be a faint memory by the time a system launched today would ever reach the market.
None of that matters anyway. When’s the last time you saw a new, built-from-scratch clinical or practice EMR system? You don’t take a 1985 MUMPS-based system and suddenly embrace modern usability concepts. It’s not an iPhone that will not only steal market share but create its own market. Healthcare software has a limited market, limited competition, and product lifecycles that span generations.
Here’s what will happen with software usability discussions. People will gripe about how bad current products are. Vendors will do a little bit of pig-lipsticking so that products at least look more usable in demos, even when they aren’t. Private doctors will, like their hospital counterparts, be enticed or forced by higher authorities to use the admittedly non-usability centered products and they will learn to work around their quirks.
Usability, for all the passionate discourse, is a lost cause that will have minimal impact on the stodgy healthcare IT market.