Why Is Medical Software So Bad?
(Note: The following represents my own personal opinions and views, not those of my employers or any other person or organization.)
Having grown up spending a bit too much time working with computers, I had many opportunities to work with well designed software, and software that was… well… total crap. As a (part time) software developer, I am painfully aware that making good software is hard. My own programs are far from perfect — which is why all but one of them have basically been free (as in beer) and open-source. I created tools that did what I needed them to do, and shared them for free with others. Since they were given away, I didn’t feel too bad about their imperfections. My commercial products, however, drive me crazy at times as I struggle to polish them to the quality I want (hence the amount of time it is taking me to get MultiMarkdown Composer version 2 ready). But even then, my products are pretty small scale.
Contrast this with the average software product that is sold to hospitals. These products are licensed for exorbitant amounts of money. The recent (well-intentioned, but poorly considered) government mandates to require physicians and hospitals to use electronic medical record software (when there really aren’t any good products out there that I have found) has further contributed to an environment that makes it ridiculously easy to sell half-finished software. Watching various hospitals spend money on this crap, and force physicians and other healthcare workers to use it causes a small piece of me to die inside….
A few signs that your software is really not very good:
It has a web interface that requires Internet Explorer — just go ahead and stop right here.
The GUI looks like something from 1995.
There are rows of poorly drawn, indecipherable icons all over the place.
It’s primary selling point is that it helps practitioners bill more. While this may be true, the rest of the program is almost guaranteed to be useless.
The most prominent technical feature is that the program can save patient data, and then retrieve it again. We’ll just all assume your software should be able to do this — what we really want is to know how your software will help us provide better care for our patients.
“Productivity” change after using your software is measured in how many months or years it takes us to get back to the same workload we used to be able to accomplish before implementing your program.
It requires a two day training program to teach smart, computer-literate how to use your program.
Your inspiration for interface design is MS-DOS rather than Apple, OS X, or iOS.
Sadly, just about every medical application I have used over the last 15 years seems to fail almost every one of the above guidelines….
To any developers working on medical applications — I implore you to work with good user interface people, to rethink your goals, and put the time in to do this right. Get users involved early on who are clinicians that also understand software and development. We’re out there, and we can give you good feedback if you’re actually interested. Despite the wide array of failures out there, it is possible to do this well. A company that takes this to heart could take over the entire market… and win the undying gratitude of hundreds of thousands of healthcare workers. And I’m pretty sure you would would be rewarded financially as well.
Follow me on twitter
Subscribe to atom feed