Readers Write: EHR Usability – Whose Job Is It?

EHR Usability – Whose Job Is It?
By Michael Burger

Near misses, good catches, or serious reportable events – how many of these could be a design flaw of the EHR used? This was an underlying question in an article published recently entitled, “Poor Prescription documentation in EHR jeopardizes patient safety at VA hospital.” This article caught my eye because I thought perhaps there would be information on a design flaw that might need to be addressed in ePrescribing software.

The article referred to a Department of Veterans Affairs Office of Inspector General report from December that cited a variety of documentation lapses regarding opioid prescriptions at the VA Medical Center in San Francisco. The EHR was a factor in the report primarily because the EHR is the place from which the documentation was missing.

From the headline of this article, the reader assumes that the EHR figures prominently in the patient safety hazard. In all probability, the same lapse in documentation would have occurred in a paper chart environment. The report found that 53 percent of opioid renewals didn’t have documentation of a provider’s assessment. I’d lay a sizable wager that the percentage would be the same or higher were the hospital to be using paper charts versus an EHR.

It seems to be sport these days to throw daggers at (dare I say beleaguered) EHRs and EHR vendors. Studies are published showing the levels of dissatisfaction with EHRs. ONC responds by introducing EHR usability requirements in the Meaningful Use standards and certification criteria. Inevitably, the focus of these activities centers on the notion that vendors purposely build EHRs that aren’t usable, are inept at training, and are uncooperative (or even sinister) about working together.

In reality, vendors are anything but purposefully uncooperative, inept, or builders of unusable products. Logically, how could a vendor stay in business if they weren’t cooperative, sold things that didn’t work, and were failures at teaching people how to use their products? In the world of EHRs, there are forces at play that help to explain these perceptions.

EHR vendors, like creators of any other product, build software features based upon demand. The limitations to a development budget are time, scope, and resources. While any feature could be built, priorities must be set as to what to build and in what order, given the limitations.

Meaningful Use has disrupted this prioritization process by inserting requirements that have become high priority because they are necessary to pass the certification test but for which there is little or no customer demand. For example, no EHR user is asking for a way to document patient ethnicity. But there are plenty of requests for workflows that don’t require dozens of clicks. The challenge vendors face is that Meaningful Use requires focus on marginally useful features, such as tracking patient ethnicity, and doesn’t leave bandwidth to eliminate clicks in the workflow.

Ineptitude in training is an interesting claim. One very successful vendor is renowned for their “our way or the highway” mentality when it comes to training. Very effective to be certain, though not a lot of fun for those receiving the training. But this method does set an appropriate expectation that workflow modification is required for successful EHR adoption. Other vendors are renowned for their mostly failed attempts to “make the software accommodate your workflow so you won’t have to change a thing.” The reality is that it’s not possible to insert a computer into a manual process like clinical workflow and expect not to have to change a thing. It’s not that a failing vendor is inept, it’s that expectations aren’t being set correctly.

Meaningful Use has inserted a perverse twist into this already unpleasant reality by forcing vendors to train clients to perform workflows that are out of context of what doctors would typically do but are now required to be able to attest.

The uncooperative accusation is the most laughable of all. Interfaces have been around since before there were EHRs – HL7 was founded in 1987. It’s a question of supply and demand. When customers demand an ability to connect disparate systems, vendors build interfaces. It’s true that vendors have built products using proprietary architectures, because till now no one was asking for common standards. Even today, with the availability and mandated use of common standards, less than 30 percent of doctors regularly access HIE data. There’s not a lot of demand for all of that external data. It’s not that vendors don’t build interfaces because they’re being uncooperative; it’s because providers aren’t asking for it.

The principal of supply and demand is a fundamental market driver. It’s disappointing that Meaningful Use has sidetracked the natural evolution of the market by creating artificial demand for EHR functions that aren’t being asked for by actual consumers. MU has had the unintended consequence of stifling innovation of the functionality being asked for by users, which would have spurred widespread organic adoption. We’ve not (yet) seen the iPod of electronic health records because vendors have been too busy writing code to pass the MU test.

Rather than introducing a voluntary 2015 Edition EHR certification, CMS and ONC should give vendors the year that the start of MU Stage 3 has been deferred to innovate features the customers really want, rather than adding more features and another certification to continue a harsh cycle. 

Michael Burger is senior consultant with Point-of-Care Partners of Coral Springs, FL.