Physician Guidance for EHR Success

I want to take a look at the complaint I hear over and over and over again when it comes to EHR software. I’ve heard this comment said about every single EHR vendor out there. I’ve also heard it from doctors in every specialty and from every size organization. It comes in a few different forms, but all communicates the same idea. This is the doctor complaint I’m talking about:

Did the EHR vendor even talk to a practicing doctor when they developed this EHR?

Yes, the complaint is usually voiced as a question, but the question is lathered up with an unbelievable shock that an EHR vendor could misunderstand a doctor’s workflow needs so terribly. Plus, it’s reinforced with the belief that if the EHR vendor had somehow just talked to a doctor, any doctor, that this wouldn’t be the result.

Of course, the situation is much more complicated than that statement supposes. In fact, there’s a great thread on the HIMSS LinkedIn group that has a bunch of deep discussion on how to create a healthy partnership between providers and EHR companies.

One key to understanding this relationship is first that every single EHR company has consulted doctors (usually many many doctors) in the development of their EHR software.

Many doctors will then wonder how they could have an experience like the one I described above if the EHR vendor consulted a practicing doctor (and I assure you many many doctors have had the experience above). The answer to that question has multiple layers. The first layer that most practicing doctors see is that “most doctors that consult EHR companies aren’t really practicing doctors.” In many cases, this is definitely the case. Many Chief Medical Officers at EHR companies have made EHR their full time job and no longer practice medicine. Many physician founded EHR companies have a physician leading the company that no longer practices medicine. Certainly some portion of the EHR workflow disconnect could be related to non-practicing providers driving the EHR development process, but that’s just one layer.

The second layer is that in every case I’ve seen there’s always been practicing providers involved in the EHR development process as well. They are active in user groups. They sit in focus groups. EHR vendors go to the practicing physician’s office to learn from them first hand. Most EHR companies really do make a sincere effort to understand the practicing physicians and not just try and guess at what the practicing physicians want.

Another layer to this problem is translating what the practicing physician requests into the EHR workflow. Now imagine that two practicing physicians request the polar opposite feature (yes, this happens a lot too). How then do you translate that feature into something that’s going to satisfy both physicians. That’s not an easy thing to accomplish.

The next challenge to consider is that many physicians aren’t technically astute enough to know what they want. When this is the case, they don’t know what they should even be asking for. I’m sure many doctors will scoff at this idea, but it’s the same concept for programmers. Many programmers aren’t technically astute enough to understand the medical world well enough to develop what the doctor wants. It’s a two way street and is why it’s so important for EHR companies to create an amazing collaboration between the right doctors and the right programmers. That’s a special breed of person that is not easily found.

Of course, I haven’t even mentioned the specialty layer. A technically astute practicing physician in cardiology will likely do a terrible job designing an EHR workflow that works well for pediatrics, OB, and general medicine. If you thought it was hard creating an EHR workflow that works for all the doctors in one specialty, now try and do that across 40+ medical specialties.

If you remember back to the paper chart world (which many of you are still living in), how come we didn’t have a standard paper form that every doctor used to document the visit? In fact, it was pretty rare that any 2 non-affiliated clinics used the same form at all. Sure, some forms were exchanged at the medical societies, but in most cases each clinic wanted to modify the form to fit their own clinic’s needs and desires. This happens in the EMR world to some extent, but it takes more training and skill to modify an EHR workflow than the Word document you got from your colleague. Plus, many don’t want to invest the time to make those modifications.

I’m not trying to put the blame for this on anyone in particular. Plus, I don’t want to make this sound like an excuse for EHR vendors to be lazy in how they approach their EHR development. We can be sure that some of the issues I describe above aren’t because the doctors didn’t provide good requirements and not because the programmer didn’t know how to meet those requirements. Some of the problems we see have to do with a combination of rushed release times or lazy programming (which are related). When this is the case, EHR vendors should take it on the chin and deal with the issues rather than trying to blame someone else.

With that said, hopefully I’ve made clear that it’s not enough for an EHR vendor to just consult a practicing physician. If that was the case, then all 300+ EHR companies would have beautifully designed EHRs that physicians’ love. Instead, I think the fact that so many of the 300+ EHR vendors have this issue, it illustrates how hard it is to get a technically astute practicing physician that can get programmers to make a beautiful interface that applies across all specialties.

From now on, I hope to hear physicians who have this problem change their question to, “Did the EHR vendor even talk to a technically astute practicing doctor in my specialty that works the way I like to work and practices medicine the way I like to practice medicine and bills the way I bill and in the region I live when they developed this EHR?” Then, we’ll all be able to easily answer “No, it seems like not.