Home » Readers Write » Currently Reading:

Readers Write: EHR Usability – Whose Job Is It?

May 16, 2014 Readers Write 4 Comments

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.

HIStalk Featured Sponsors


Currently there are "4 comments" on this Article:

  1. The running joke with our EHR vendor is that if we want any functionality or enhancements added to the program it has to be a MU requirement. Then it’ll get added.

  2. Thank you. I could not agree more, especially regarding Meaningful Use. There is little meaningful about it. Not only is there the solution looking for a problem aspect that you describe, you can check the box without truly adding any value for anyone. When you call CMS to ask if your plan truly meets the requirement, they tend to have no idea – they simply read the requirement back. This is like many things in healthcare today where we start with honorable intentions but in the end spend an enormous amount of time and money chasing things that do little to truly improve care or provide value, especially when implemented to meet the letter of the requirement, not the spirit of the requirement.

  3. “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.”

    I’d assume that the motivations for ONC to include Safety-Enhanced Design in Certification requirements were related to recommendations from the IOM to improve safety and usability of EHR:
    – “The IOM recommended that “[t]he Secretary of HHS should specify the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability.”
    – “We proposed that a significant first step toward improving overall usability would be to focus on the process of user-centered design (UCD).”

    The Safety Enhanced Design Certification requirement simply provides some transparency around what EHR vendors should already be doing: conducting usability testing on risky functions (like those associated with medication management) and recording the results in a standard way.

    This allows prospective purchasers to see who’s doing a good job on incorporating user-centered design into their development processes and who’s not.

    Would this have been more useful a few years back? Absolutely.


  4. Mike, I enjoyed reading your article and you make excellent points. It’s a vendors responsibility to make use of an EHR easy and quick. It’s the role of the industry to make certain the healthcare entities automate and capture relevant data. When government gets involved in setting policies, regulation, and guidelines, we can expect – well, typical government bureaucracy. The efficiencies and the knowledge that can be gleaned from captured health information in a reportable format available in seconds. We all benefit when it’s done right.

Text Ads


  1. My former former employer (that's 2 jobs ago) initially embraced remote work. It made sense -- they're a major telecom…

  2. Veradigm delisted: That's a shame for a company who went from a widely reconized name to a semi-intelligible moniker. Maybe…

  3. https://www.cityofmadison.com/metro/routes-schedules/route-55 https://www.cityofmadison.com/metro/routes-schedules/route-75

  4. Gurley sounds like a B.S'er. And he's in the VC business so that tracks. Here's the setup. You want investor…

Founding Sponsors


Platinum Sponsors















































Gold Sponsors