5 things needed to make EMRs practical

Regarding "Selling the bitter EMR pill" (Article, April 7): I read with some consternation the article on EMR. The proliferation of poor quality, overrated, overpromised software is stunning. In our medical community, we are all struggling with these issues. I find the article's focus on the need to package the introduction and adoption of new software rather offensive.

I have been the physician adviser to committees to adopt new software. I remember well the words of our consultants from a large health plan after we had spent hours at meetings. We had asked them to help us make a good choice on software. They advised us to decide whether we wanted to be a small fish in a large company's pond or a big player in a small company's pond. They were rather nihilistic about the ability of any company to truly evaluate the validity of any software company's claims.

The problems with evaluating new software are legion. A company will show you its wares and promise you the moon. They are, in my experience, always exaggerating what their software can do. You can call people and ask about their experiences, but often you are referred to people who know it well and are very enthusiastic. You can go look at it in action, but rarely can you become competent enough to quickly figure out how it is working and whether it will work for you or not. When you do notice problems, you will hear the mantra of software development, Oh, we know about that, and it will be fixed in our new version. The new version is always six to nine months away (sometimes two years or more) and often does not fix the problem, and you may need to pay a lot more for it.

The end result is that, most often, a new expensive software can be quite a leap of faith. As a busy practicing physician, I am not interested in leaps of faith. When I use a word processor, it works correctly. The learning curve is short. It does not require many patches to work correctly. I expect the same thing from an EMR.

Most software for medical applications seems to have been developed as a means to improve reimbursement. Software seems to be best at "billing-related" issues. Our recent foray into EMR was marked by an offering of free EMR software only if we would pay for the billing software. The problem is that it takes you months to learn to use the billing software. You basically agree to marry yourself to the billing software and trust on faith that the EMR will work well. You later discover that you will have to document and essentially work in a different fashion. You now own about one-third of a computer consultant who is garnering more wages from you than most of your staff put together.

An article that talks more or less about how to handle physicians in the process of implementing new technology is really quite infuriating. The solution is also quite simple. People who develop software should work toward several ends:

First, software should be clinically relevant. The narratives of peoples' lives cannot be lost to the demands of data fields.

Second, software should make the work we do easier.

Third, software must be able to talk to other software.

Fourth, computer programmers must understand that what seems intuitively obvious to them may not be so to the rest of the world. They must learn to develop software that people actually can use intuitively. I spend significant portions of my time figuring out how to explain complex health issues to patients so they can understand them easily; I want the same consideration from my software developer. Please program interfaces that even I can figure out easily.

Fifth, software should emulate the way we work and make it better without bogging it down. A word processor makes me a better writer, my work looks much better, and I get more of it done. An EMR must make me a better doctor, make my work look better, and I will be able get more of my work done with higher quality.

Curtis Climer, MD, Silverton, Ore.

Note: This item originally appeared at http://www.ama-assn.org/amednews/2008/05/12/edlt0512.htm.