I think vendors of electronic health record systems (EHRs) are tired of hearing from complaining clinicians. We have written and spoken about why we have trouble using or adopting most EHR software. I think our beefs are justified. But to be effective in bringing about change, we need to engage instead of complain. Here are a few of my ideas for engaging. They have all been done before, and they're all things you can do.

Idea #1: Drop a line

You might be surprised how open EHR software developers are to helpful suggestions – and one helpful suggestion may be all that's needed to initiate a significant improvement. I acknowledge that it may be hard to find an address to write to. We'll come back to that.

I have made numerous suggestions to web developers that made my life easier. Web developers are easier to reach than software developers, granted, and can implement change a lot faster in general. They just rewrite the software code, change it on the main server, and voilà! It's done tomorrow.

Your EHR software vendor has a slower and more winding path to navigate in order to implement change. It takes longer for many good reasons, and a few bad ones. Their software is likely intended to interact with other software in various permutations, all of which have to be tested. It has to work in installations large and small. Finally, upgrades need to be distributed to the customers and installed before a change can be fully rolled out.

How do you find an address to send your suggestions to? Start with your vendor's web site. You might find an appropriate-sounding e-mail address right away. If not, send an e-mail to whatever address the company offers and ask to be put in contact with the usability team. If that doesn't work … you had a sales person, didn't you? If you haven't waited too long (and if your rep hasn't moved on to another job), that person should be able to help you make the right connection. He or she needs your good word-of-mouth and so will probably be motivated to help. Make it clear you don't just want to complain but want to offer constructive feedback and suggestions for improvement “so your product can be successful!”

When you get the e-mail address you need, add it to your e-mail contact list, and start sending suggestions. I've actually had vendors e-mail me their thanks, call me back to ask for details and try to understand better, and even let me argue my case. Sometimes you win, but you always engage.

Idea #2: Offer to help

Someone near you has the power to make your life as an EHR user easier. You can find them, and offer to help.

Offering to help is different from complaining about the software's deficiencies. The latter is perceived as whining – whining by users who weren't trained adequately, fear technology, are stuck in their old workflows, don't want to change, haven't installed the latest upgrades or haven't turned on the available features.

Offering to help is bringing yourself, your experience as a clinician, your experience with your vendor's software, your intention to use an EHR effectively, your experience as a savvy web user, your curiosity, your assertiveness and your optimism to bear on the challenge of making the software more usable. I like to think I am “relieving physician suffering” by offering this kind of help.

Here's what helping looks like:

You ask your salesperson or support person (on the phone or by e-mail, or perhaps even by live chat) how you can get involved in making the software more usable. Ask them to put you in touch with their usability (or “user experience” or “user interface” or “user interaction”) department. That department may only be one person, or not officially organized. It may just be a subculture within the organization. Insist to your listener that there is someone like that at his or her company, and insist that he just go find them.

Then, when you have the usability person's attention, tell him or her that you want to help, and ask what means they currently have for you to participate. If your offer provokes shock or surprise, then you are a trail-blazer. If it doesn't, then you are in good hands.

Alternatively, you might find yourself at a user-group meeting for your vendor. If so, then you have already distinguished yourself as a physician champion, an early adopter or a change-agent. At the meeting, ask to meet the usability team. If they aren't at the user-group meeting, that's a bad sign. They should be there! That's where all the informed, motivated, hurting users are. Once you meet the usability team, tell them you want to get involved, and ask how many options there are. You may not be a good match for every choice, so find the ones that have some appeal to you. If you live nearby, offer to meet periodically in person. If you live farther away, there are many inexpensive ways to collaborate online, as if you were in the room with the software staff.

What are some ways you might actually help make the software more usable? They range from the ridiculous to the sublime.

You might be asked to participate in a focus group. Beware of focus groups, though not all focus groups are bad. A focus group only tells the vendor what users think they want. The reality is, we often don't know what we want, and we would settle for a lot more simplicity and usability, and a lot less complexity and feature bloat.

You might be asked to do a user test, which involves having someone walk you through a trial of some nascent feature of the software. This might take anywhere from five minutes to an hour. It only takes three to five user tests to get the information needed to refine a software design. Sometimes it is done with paper prototypes (sketches on paper). Other times, it might be clickable prototypes or the real thing.

Often, a good user test points out obvious deficiencies that the software developers immediately recognize as a problem. Software writers don't think like users, and really never can. They need us to help them see the obvious.

Then again, our professional expertise brings knowledge that the vendor does not have. They might benefit from your input early in the design stage. You know what a helpful display of a string of blood sugars should look like, having seen so many poor data displays in the handwriting of your well-intentioned patients. A table is easier to read than a string of numbers. A table designed by someone who knows what they are looking for (“fix the fasting blood sugars first”) is more helpful than a table designed by someone who doesn't know what clinical questions to ask.

Idea #3: Buddy up

Quite a few joint ventures and partnerships around the country bring together EHR software developers and clinical entities. Organizations large and small are involved.

This job isn't for everyone, but if you are willing to invest significant time, and the vendor is likewise willing to invest in you with money or other compensation, then the effort can be worthwhile for both parties. The rewards can be many:

• You have a voice in the development of the software you are using every day.

• You can help the vendor avoid mistakes that are obvious to you.

• If you've been in practice for a while, you broaden your horizons and add a fresh aspect to your work.

• You learn some new skills, and learn to appreciate the skills of professionals in new fields.

• If you structure the contract appropriately and share the risk, you can benefit from the financial rewards of creating intellectual property.

• As partners, you might participate in software development in one or several ways. You could be subjects in user testing, once or serially. You could be advisers on clinical content. You could advise on the look and feel, on features to include, on the balance of complexity against simplicity, on visual display needs, on task efficiency or on clinical relevance (sometimes you need a graph, and sometimes it just doesn't help).

Sometimes the pertinent clinical content is strung all over the place, and we need it in one place, now, in the clinic, one or two clicks away. You could become engaged in making clinical decision support algorithms suitable for use at the point of care. Some existing algorithms are so large and detailed you need to spread them out on the kitchen table.

If you work for a larger organization, get involved with the IT (information technology) team. Figure out who on that team has the passion and resources to work with your vendor. Agree on the amount of effort you are willing to invest.

If you are in a smaller organization, like a small family medicine group or solo practice, you may need to find a group of like-minded soloists. See if there is an area user group for your vendor or a national cadre of other family physicians using your product. If you're an AAFP member, you can sign up for the electronic medical records e-mail discussion list or use the “Find a Doctor Like Me” feature of the AAFP's Center for Health IT web site to see who might be willing to work together.

Then go to the user-group meetings for your software vendor or contact them directly, and offer to partner up. They will undoubtedly have some projects needing help from an organization like yours.

Postscript

I'm sure there are other bright ideas out there. Share your ideas with other readers by e-mailing them to fpmedit@aafp.org, and see my blog at http://www.toomanyclicks.com for more. The conversation is just beginning.