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.“
Physicians are a double-edged sword in EHR development. You need them for workflow, best practices, etc, but the more that are involved in an advisory capacity, the more scope creep. At this time, anyone not developing to meet the Stage 2 core requirements is probably going to be in a world of hurt, as the “nice to have” capabilities can be added on later, without the need to re-certify the base system.
Having said that, specialists have a valid complaint. If you’re a radiologist or a dentist trying to implement an out-of-the-box solution, it’s going to be painful. The MU requirements were written for GP’s and hospitals, and have little application to their practices (tough to record vitals if you never see a patient). I think the task today is to meet Stage 2. The companies that cater to specialists should be able to clean up if they produce a quality “add-on” that meets their needs after.
Let’s hope developers and doctors can agree on one fundamental principle: The primary goal of an EHR is help facilitate the delivery of healthcare to our patients. Honestly, if we can just refocus that as a starting point, everything else should fall into place.
There are a few basic requirements that all doctors can agree upon. We want the EHR to improve our efficiency, not hamper it. We want to spend more time looking at our patients, than looking at computer screens. We don’t want wade through clunky interfaces to complete simple documentation tasks (i.e. 17 clicks to add one problem to an Epic outpatient encounter and note??!!). We don’t want to click buttons mindlessly to prove to our overlords that we are looking at data. We don’t want to wade through pages of irrelevant junk to find one important lab value.
Developers absolutely must talk to caregivers. We’re only a “double edged sword” if developers make the mistake of trying to eliminate everyone’s quirky pet peeve. Give us something that just doesn’t make us scream and we’ll be thrilled.
Edward J Schloss MD
@EJSMD
Cincinnati, OH
Matt,
Thanks for reminding me how sick it makes me to think how many development cycles are focused on meaningful use instead of users (physician) needs. Even just managing the MU/certification requirements in the context of what Dr. Schloss says in his comment is really an impossible task. Is there anything in MU that matches with the needs and desires that Dr. Schloss describes? I can certainly point out many MU requirements that support the opposite of what he wants.
Very well articulated. Stakeholder identification and stakeholder expectation management are two major process that many EHR projects overlook. This always leads to a scope creep or user dissatisfaction. Additionally, most of the practitioners either are not keen to participate in the early stage of the EMR development or assume the vendor/developer knows everything they want. And worst in when the developer thinks they knows what the client wants, too many assumptions lead to a huge gap.
Dr. Schloss,
I certainly meant no offense by the ‘double-edged sword’ remark. My only point was that, in the less than ideal circumstances that now exist, with Stage 2 deadlines right around the corner, vendors have to focus on certification. The strategy we’re taking with our partners is to make the product modular, so that the bulk of the developers can build to the MU requirements, while we’re gathering the wish-lists from our providers, and will be able to layer modules, specific to the needs of their specialty, on top of the core system.
You also make a very good point about usability. My wife and I just had a baby, and I got to watch Epic being used. What you said about more screen time than patient time is exactly spot on, and shows a disconnect between caregiver workflow in the real world, and what the vendor thought should work. I do find it difficult to understand why that gap doesn’t seem to get bridged in the healthcare sector. I did a project with a large retailer a few years ago, and we found around 3,000 applications that had simply been orphaned, up and running, but never used. Mostly because they simply provided nothing of value to the end user. You see it in healthcare, too. Providers who spend a great deal of money on an EHR, and are back to paper in a matter of weeks.
John,
I’m not sure how you square Stage 2 with the user’s specific needs, other than the two-pronged approach I described above. One size definitely does not fit all, especially when you get into various specialties. It kind of lays bare the flawed approach that was taken with MU. Much like the complaints about NCLB and teachers having to teach to the test. Physicians should be able to practice the best medicine for their patients, not, as Dr. Schloss says, to satisfy the overlords.
Matt,
I took no offense at your comment. I’ve sat in many meeting with other doctors and shared the experience that it is nearly impossible to get us all to agree on anything. I’ve heard us described as a “herd of cats” and would not argue a bit with that sentiment. I don’t envy anyone that is charged with satisfying a bunch of self-serving leaderless know-it-alls like us doctors (my words).
That said, it sure seems that some EHR implementations don’t take into account the common struggles we face, and I tried to articulate that in the last comment. What’s really sad and ironic, is that the very processes that healthcare reform is implementing in IT sure sound like they represent an impediment to the delivery of healthcare.
More than ever, developers and doctors need to talk. Developers just need to learn the art of knowing how to shut us up when we get going.
Edward J. Schloss MD
@EJSMD
We have heard this objection several times, even though we are a custom shop. That was one of the main guiding principles to our system design and philosophy. You can design a system in a completely custom manner from the ground up for a particular physician – and then show it to another physician *in the same specialty* – and they will look at you like you have three heads.
The truth is everyone is an individual, and everyone has a different opinion on the best way to practice medicine. The kicker is that each one of them is correct, for the most part. Although some clinics have instituted poor workflows, for the most each clinic has a workflow that suits them. We try to accommodate that as much as possible. Unfortunately, though no two physicians seem to agree on what is best.
Dr. Schloss comment about us all agreeing that “17 clicks to add one problem to an Epic outpatient encounter and note??!!” is too many has stuck with me. I have mixed feelings on the subject for a number of reasons. First, we can all agree that fewer clicks to accomplish the same task is better. Why can’t all EHR vendors understand this and at least incrementally minimize the clicks? Seems obvious no?
Although, when I think about number of mouseclicks I’m also reminded of a post I did about Comparing Mouseclicks to Piano Keys. The crux of the post is that a lot of clicks can be fine if you get instant response from a click and are well trained. I just clicked a lot of keys to type out this comment, but because I’m well trained at typing and the response of my keyboard is instant, it’s not a pain at all.
I’m loving the frank discussion and particularly the herding cats comment. So right, but EHR vendors can do a lot better than they’re doing in most cases.
The number of clicks is not as important as whether the clicks take away your working memory. A click that does not seem to be related to the task at hand is far worse than two or three clicks that make sense. (Meditech, for example, has a hard-stop question, “save signature?” that no one I’ve talked to knows what it means, even Meditech.) Any doctor has 5-10 things he or she is thinking of at any moment. The way a family member looked menacing, the slightly abnormal bilirubin, the way a syncopal event was described, etc. You take one of those away with a counter-intuitive click and you might be killing somebody.
Another problem is a lot of these systems were baked a long time ago. They have a lot of poured concrete to overcome to make any changes. And once you introduce a feature, you can’t take it away because somewhere there is someone who now absolutely requires it.
There are some new companies out there doing things dramatically different. But meaningful use means hospitals can’t justify taking a chance on them. They’d rather put in truly bad software that doctors and nurses hate and accept productivity losses just to have some assurance they will painfully squeak through meaningful use like their peers. Why would you do the same thing over and over again and expect a different result?