The Usability Problem

Part 1: What the EMR Market Can Learn From Twitter

As Meaningful Use marches on and providers are deploying their newly-minted EMRs (electronic medical records), the ONC has been receiving complaints that the user interfaces of many EMRs are frustrating and poorly-designed. Dr. Farzad Mostashari, the head of the ONC, put it well last October in an interview on HIStalk:

The only problem is that providers consistently say, “I didn’t know what I bought until three months after I bought it. I didn’t know what the usability of the system was really going to be, because all I saw was these demos I had from people who knew their way around the system and knew spots to avoid.”

To help prevent these horror stories from happening to other providers, the ONC and NIST are strongly encouraging EMR vendors to include formal usability testing results when submitting their products for certification. The thinking is that if usability scores are publicly available, providers will be able to comparatively shop around for the best experiences, thus encouraging all vendors to improve their products.

While I applaud the ONC and Dr. Mostashari for their efforts, I believe that this initiative misunderstands the systemic nature of the usability problem. Contrary to popular belief, the usability problem is not directly the fault of the EMR vendors. There are fundamental technological and market forces that disincentivize EMR vendors from creating truly great user experiences. These forces must be disrupted before the EMR industry will begin to produce satisfying end-user experiences. A change in certification criteria is woefully inadequate to the task.

Before going further, I should clarify my terms. What goes by the name “usability” in most EMR discussions is actually a blend of related concepts: safety, beauty, ease-of-use, etc. What these concepts all share is the notion that EMRs should be safe, fast, easy-to-use, and pleasant. Rather than get lost in the weeds of specialized terminology, I will follow the common practice of referring to all these domains under the umbrella term “usability.” I humbly beg usability experts to forgive me this injustice.

Because many “usability” complaints exceed the scope of the formal definition of usability, it is clear on this basis alone that the ONC’s initiative is not enough. Formal usability testing is a tool used to prove the safety and efficiency of a given task, but providers are frustrated with the entire EMR experience, with the way that all tasks are bound together into clumsy, dissatisfying products. Formal usability testing can refine an innovation, but it cannot inspire it. Innovation must be inspired by a profound shift in priorities.

The reason that EMR vendors have yet to produce innovative user experiences has nothing to do with a lack of money or talent; they have healthy revenues flowing in from one of the largest and fastest growing markets; they have many bright employees; there’s no lack of technical or design expertise. If a vendor wanted to make an EMR with a show-stopping user-interface, there would be few internal obstacles in their path. So why don’t they want to do so?

The answer is that the current EMR market doesn’t really prioritize usability. EMR purchasers are not end users; their purchasing decisions are driven by other priorities. They are responsible for ensuring that meaningful use criteria are met in a timely and cost-effective manner. Every purchase must be a part of a long-term strategy of going paperless even as future changes in reimbursement will potentially threaten their bottom line. The basis of competition for these customers is essentially an arms race of features and functions. Usability is one concern among many. The vendors that offer the most features and functions are valued the highest.

Before Meaningful Use, only a small fraction of institutions were using EMRs. Most of the ones that had EMRs were using them in a limited fashion: labs, eMARs, etc. Less than one percent were fully electronic. To go from this state to a fully-electronic system presents an enormous task for managers. It also presents an enormous task for vendors.

There are few technological standards for EMR integration. Even HL7 is just a messaging protocol, with dozens of specs, all of which are haphazardly implemented in practice. There is an HL7 segment called the Z segment, which is a kind of wildcard that can be used for anything not covered in the official spec by another segment. It was intended to be used only rarely. An integration engineer I know estimates that 90% of HL7 messages are now sent via the Z segment.

When a major vendor released a disappointing iPhone app recently, I had the pleasure of speaking with the lead developer on the project about my disappointment. He acknowledged its flaws, but explained the difficulty they are having in integrating iOS applications with their core products:

This app is a small step as we continue to decouple complex logic embedded in the Windows platform and expose as services.

Translation: “We’re having a difficult time extending an API, even to ourselves. Our software was not architected for agnostic interoperability with other platforms.”

There are perfectly valid reasons for this difficulty. Since the industry has never produced true interoperability standards, EMR vendors have been left to themselves to create and maintain their own internal standards. Because of the scale and complexity of an EMR, these internal standards are full of proprietary fine-tuning and optimizations. Front-end applications were not designed to be hot-swappable.

Thus, in a market in which customers value feature lists and functionality, the vendors who offer the most features must also be the vendors who are the most technologically integrated. This is why Epic has been taking the lion’s share of the inpatient market. Their all-or-nothing approach with customers is backed by the technological capability of doing so. Epic can guarantee feature lists because it controls its technology stack, soup to nuts. Other vendors boast similar successes to the extent that they are integrated and feature-complete — or not.

What does all this have to do with usability? Since innovation is the fruit of competition, innovation in usability will not occur until usability becomes the basis of competition. This cannot happen while front-end applications and back end systems are still tightly integrated. To understand why, let’s consider the example of Twitter and third-party Twitter apps.

When Twitter was first launched in 2006, it was mainly a text-messaging service. Tweets were limited to 140 characters (well, 140 characters plus a 20 character username) because SMS messages are limited to 160 characters. You would send and receive tweets straight from the text messaging screen on your mobile phone. Twitter also hosted a website which you could use to browse your timeline and send messages.

Behind the scenes, both the website and the SMS service ran on the same underlying back end system. Twitter engineers worked hard to maintain a clear boundary between the front end SMS/web experiences and the back end, linked together by a reliable and robust API.

What Twitter did next with this API was the key to its success and cultural impact: they extended this API to third-party developers. Developers loved that they could build and sell an app to suit their customers’ tastes and needs. As long as they followed the API, the sky was the limit to their creativity. The apps that were produced from this effort — Tweetie, Twitteriffic, TweetDeck, and many others — have come to define the Twitter experience for their users. Customers could try new apps with ease. All that was needed was a username and a password. They could switch from one app to another without worrying about losing their data or being unable to send tweets. The Twitter API guaranteed interoperability.

This competition produced almost every innovation that we now consider essential components of the Twitter experience: hashtags, retweets, photos, shortened links, etc. Even the word “tweet” was coined not by Twitter employees, but by developers at a third-party company, The Icon Factory. Every Twitter client had its own unique user interface, and apps competed for the best experience. Some, like TweetDeck, competed with pro-level features, while others, like Twitteriffic, competed with simplicity and ease-of-use. Client apps that were poorly-designed or hard to use did not succeed in gaining users.

Compare this to Facebook: until relatively recently, if you wanted to use Facebook, you had to visit their official website. The Facebook experience was designed for the lowest-common-denominator, and it showed. Every major attempt to redesign the Facebook site resulted in large numbers of upset users. There is simply no way to satisfy all people with a single, monolithic user interface. Variety is a necessity if the goal is to create satisfying user experiences.

What if EMRs worked more like Twitter? What if there was a clear separation of concerns between reliable back end systems and user-facing client applications, linked together by a robust, universal API? If providers could pick and choose the component pieces of their front end software the same way that Twitter users can swap out Twitter clients, the basis of competition would radically shift towards usability. Smaller vendors would be able to compete with equal footing with the large vendors, at least on an app-by-app basis. This one makes the best CPOE module, this one the best stress-test documentation, this one the best eMAR. Providers could hire developers to write custom in-house apps at relatively little expense and difficulty compared to present circumstances.

Is it even possible for the industry to change in this way? In Part Two of this series, I will discuss the changes that would need to take place for such a scenario to occur. I will also identify the institutions that are the most likely to be able to effect the necessary changes, and whether and how they would be motivated to do so.

|  5 June 2012

→ Dr. Rick on the ONC/NIST Usability Conference

I had the pleasure of meeting Dr. Rick Weinhaus at this years Creating Usable EHR conference in Bethesda, Maryland. I was also fortunate to assist with this, his latest article on HIStalk, in which he reflects on the lessons learned there.

|  4 June 2012

The EMR Nurses Need

Among the litany of complaints about the (un)usability of EMRs, it’s easy to lose sight of the big picture. More than the poor design choices and overall ugliness of existing software, by far the single biggest failure of HIT companies is that none of them has yet to produce an EMR that nurses actually need

There is a huge opportunity being wasted here. Other industries have been able to incorporate computers in such a way that removing them from the workplace would be unthinkable. Photographers and musicians are producing high-quality content in less time and with less money in digital studios. Executives are monitoring every aspect of their businesses, from supply chain logistics to sales, in real time, even while on the go. President Obama made the Blackberry a non-negotiable component of his administration.

We’re not dreaming big enough. The intrinsic value of technology is it’s ability to provide solutions to problems we never knew we had. Remember having to tell the neighbor to get off the party line so you don’t miss an important call? Remember not being able to go out on the weekend because the banks don’t open until Monday and you have no cash? I don’t. A few bright minds solved these problems for me before I ever knew I had them.

Other than billing or records, what problems does an EMR really solve? In their current state, EMRs add nothing of value to our work as nurses. They are tedious chores at best, outright obstacles at worst. They are database portals where we type some numbers and check some boxes, and nothing more.

Meanwhile, our nation’s nurses continue to take and receive shift reports on folded up pieces of printer paper. They place bits of silk tape on door frames to remind them of pending lab draws. They sometimes give scheduled medications late because their iPhones don’t have EMR apps that might take advantage of iOS 4’s support for local notifications and beep them at the proper time. They lug around laptops bolted to enormous rolling carts or wait in line for a free desktop PC because they can’t chart their morning assessments on the iPod Touches in their pockets.

Nursing is a profession of the clock. It is task-oriented. It has a lot of routine. It consumes data as fast as it can produce it. In other words, it is exactly the kind of job that cries out for a technological revolution.

|  23 September 2010

→ Where are All the iPhone EMRs?

EMR & HIPAA Dot Com are putting together a wiki of EMR vendors with information on OS and device compatibility. So far out of the thirty-one they’ve counted, how many are natively supported on MacOS? Nine. How many on iOS devices? Zilch.

|  19 August 2010

→ What the Heck is openEHR ?

Here’s the official description from

The principal challenge for health ICT is to represent the semantics of the sector, which are far more complex than in other industries. Doing this requires a knowledge-oriented computing framework that includes ontologies, terminology and a semantically enabled health computing platform in which complex meaning can be represented and shared.

Huh. Now let’s hear it from

Think of openEHR as the open source health equivalent of the iPod/iPhone platform – a technical framework which will allow any compatible application, organization or provider to share ‘plug and play’ access to standardized data.

Okay, I think I get it. I want one now.

|  16 August 2010

The Doctor’s Inbox

Dr. Wes, a blogspot-blogging physician, posted a follow-up to his post last week on email correspondence between physicians and patients. The majority of emails he receives tend to be for very simple things like checking a lab result.

Current EMRs don’t make reviewing and sharing lab values efficient. Dr. Wes writes:

[O]ur current model of the electronic medical record sending every single result to our inbasket, even though it contains previously read or acted-upon results is creating a “Boy-Who-Cried-Wolf” scenario for doctors suffering from information overload. The electronic medical record must to [sic] a better job of filtering the myriad of tests that end up in our inbasket each day (I’m thinking of EKG final results that I have already read or recurrent INR test results within a therapeutic range, for instance).

And once those results have been read (or reread), patients still have to call or send an email to receive the result.

Read More

|  10 August 2010

→ Top Ten Wishlist for Next Generation EHRs

From an anonymous commenter at Change Doctor:

1.Less configurable. The Demotivators® said it best “When people are free to do as they please, they usually imitate each other”. Every hospital or physician practice is unique — they uniquely solve the exact same problems everyone else is facing.

2.Better designed. End-user input and UI design should be part of the specs, not the pilot.
Amen! Everywhere I go, I find that the consensus opinion of EHR user interface design is on a par with the hot dog buns scene from Father of the Bride.

|  8 August 2010

→ AdvancedMDs CEO on EHR Late Adopters

Eric Morgan, president and CEO of AdvancedMD:

It’s like the person back 10-15 years ago who resisted e-mail. Finally, everybody including Grandma got on e-mail, because if not, they couldn’t stay in touch with their grandkids and it became a problem. I think we’re going to have a similar situation where, regardless of where you are in EMR adoption, you’re going to realize one day that you can’t afford not to do it because you’re going to be off the grid.

(Via HIStalk Practice.)

|  8 August 2010

→ Interview With Randall Oates, MD, Founder of SOAPware

Dr. Oates on the core problem with the state of EHRs:

What is mainly missing is an accurate perception of reality. That is… recognition that it is nothing less than insanity to expect physicians to become data entry clerks! In the future, we are going to look at the current approaches to EMR implementation in the same fashion as we now view the practice of leeching and blood-letting of the past. Data entry should rarely be performed by clinicians! Instead, it should be done via other avenues such as the patient, medical assistants, and data gleaned from information that already exists, but is siloed into some other information system. The EMR technology, as well as changes in the practice workflows, should be used to liberate physicians from most data entry, and not increase that burden.
(Via EMR and HIPAA.)

|  8 August 2010