EHR Usability: Is There a Right Path?

The following is a guest post by Carl Bergman from EHR Selector.

Earlier this fall, the AMA sponsored a Rand Corporation study on physician’s professional satisfaction. Based on interviews with physicians in 30 practices, the study covers a variety of topics from workplace setting to quality of care, EHRs and health reform, etc. At the time, the report generated discussion about dissatisfaction in general with EHRs and MU in particular.

Usability, Part of MU?
Overlooked in the discussion was a new and important recommendation on usability. Here’s what is says:

Physicians look forward to future EHRs that will solve current problems of data entry, difficult user interfaces, and information overload. Specific steps to hasten these technological advances are beyond the scope of this report. However, as a general principle, our findings suggest including improved EHR usability as a precondition for federal EHR certification. (Factors Affecting Physician Professional Satisfaction and Their Implications for Patient Care, Health Systems, and Health Policy, p.142) Emphasis added.

It would be overkill to say that this represents adopted AMA policy, however, it’s not overkill to say that the recommendation is part of a project that the AMA initiated and supports. As such, it is most significant that it recognizes the need to bring some coherence to EHR usability and that the MU system is the logical place to put it.

Changing the Vendor – User Relationship
One commentator who did notice the recommendation was EHR Intelligence’s Robert Green. In his review, Green took a different tack. While agreeing that usability needs improvement, he saw a different way to get change:

Usability remains an enigma in many clinic-EHR vendor relationships because it hasn’t been nearly as important in the recent years’ dialogue as “meaningful use.” But among the competing priorities, usability among physicians and their EHR vendor is a real opportunity to develop shared expectations for a new user experience.

As a patient, I would rather not see the delegation of the “usability” dialogue of EHR to those in the roles of meaningful use certification. Instead, physicians who have spent many years of their lives learning how to “take care of patients” could seize the moment to define their own expectations with their EHR vendor of choice within and beyond their practice. (How connected is EHR user satisfaction to vendor choice?) Emphasis added.

I think these two different paths put the question squarely. They agree that usability needs increased action. Users have gotten their message across with alacrity: all systems fail users in some aspect. Some fail catastrophically. Though some vendors take usability to heart, the industry’s response has been uneven and sporadic.

Where these two approaches differ is tactics. Rand looks at usability, and sees an analog to MU functions. It opts for adding usability to MU’s tests. Green sees it as part of the dialogue between user and vendor.

As a project manager and analyst, my heart is with Green. Indeed, helping users find a system that’s a best fit is why we started the Selector.

Marketplace Practicalities
Nevertheless, relying on a physician – vendor dialogue is, at best, limited and at worst unworkable. It won’t work for several reasons:

  • Nature of the Market. There’s not just one EHR market place where vendors contend for user dollars, there are several. The basic divide is between ambulatory and in patient types. In each of these there are many subdivisions depending on practice size and specialty. Though a vendor may place the same product name on its offerings in these areas, their structure, features and target groups differ greatly. What this means is that practices find themselves in small sellers’ markets and that they have little leverage for requesting mods.
  • Resources. Neither vendors nor practices have the resources needed to tailor each installation’s interface and workflow. Asking a vendor, under the best of circumstances, to change their product to suit a particular practice’s interface approach not only would be expensive, but also would create a support nightmare.
  • Cloud Computing. For vendors, putting their product in the cloud has the major advantage of supporting only one, live application. Supporting a variety of versions is something vendors want to avoid. Similarly, users don’t want to hear that a feature is available, but not to them.
  • More Chaos. Having each practice define usability could lead to no agreement on any basics leaving users even worse off. It’s bad enough now. For example as Ross Koppel points out, EHRs record blood pressure in dozens of different ways. Letting a thousand EHRs blossom, as it were, would make matters worse.

ONC as Facilitator Not Developer
If the vendor – buyer relationship won’t work, here’s a way the MU process could work. ONC would use an existing usability protocol and report on compliance.

Reluctance to put ONC in charge of usability standards is understandable. It’s no secret that the MU standards aren’t a hands down hit. All three MU stages have spawned much criticism. The criticism, however, is not that there are standards so much as individual ONC’s standards are too arcane, vague or difficult to meet. ONC doesn’t need to develop what already exists. The National Institutes of Standards and Technology usability protocols were openly developed, drawing from many sources. They are respected and are not seen as captured by any one faction. (See NISTIR 7804. And see EMRandEHR.com, June 14, 2012.)

As I’ve written elsewhere, NIST’s protocols aren’t perfect, but they give vendors and users a solid standard for measuring EHR usability. Using them, ONC could require that each vendor run a series of tests and compare the results to the NIST protocols. The tool to do this, TURF, already exists.

Rather than rate each product’s on a pass – fail basis, ONC would publish each product’s test results. Buyers could rate product against their needs. Vendors whose products tested poorly would have a strong incentive to change.

EHRs make sense in theory. They also need to work in practice, but don’t. The AMA –Rand study is a call for ONC to step up and takes a usability leadership role. Practice needs to match promise.

About the author

Carl Bergman

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com.For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manager doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst, a role he recently repeated for a Council member.

14 Comments

  • What I find fascinating is “Neither vendors nor practices have the resources needed to tailor each installation’s interface and workflow. Asking a vendor, under the best of circumstances, to change their product to suit a particular practice’s interface approach not only would be expensive, but also would create a support nightmare.”

    All of my customers have their own tailored workflow for the simple reason that the software environment accommodates it. If a user can draw a flowgraph by hand, little additional effort is needed to do it in the EHR mapping environment and one mouse click rolls out a new/updated workflow.

    The fact that users can design, build and own their own “best practices” workflows does not mean they have to do it. Many times, a customer will designate a super-user to attend to this, or call in an outside facilitator but it is not “expensive” and they do not have to go back to the vendor.

    A simple analogy exists to make my point. You would not consider calling Microsoft and asking them to customize MS Word each time you undertake to write new/different type of letter. MS Word has a standard user interface (basically a blank screen or a template, plus facilities for designing new templates.

    I have a paper that details a script for a live demo we give to anyone interesting in learning about agility in the design of healthcare flowgraphs.

    It runs 29 pages but most of the content consists of screenshots. You can get a download link by messaging me at kwkeirstead@civerex.com. Ask for “Clinical Demo Script”. No sales reps will call you.

    Optionally, we can set up a GoToMeeting where you watch us build a small but representative workflow on the fly. Again, no sales reps will call after the web session.

    When performing resources are able to use their workflows and their forms, satisfaction with EHRs increases dramatically. No longer does an agency get complaints re the user interface, workflows, forms or the way data fields are organized on forms.

  • I thought you were precisely on point “current problems of data entry, difficult user interfaces, and information overload”.

    My comment was about workflows because nothing else becomes important unless/until an organization is using it’s own “best practices”, but the UI is what makes or breaks the implementation.

    If you cannot get users on board and keep them on board, the initiative fails.

    I just published an article “eCase – The UI makes or breaks it” at
    http://wp.me/pzzpB-tt if anyone at this discussion cares to take a look.

  • This post and its comments raise three important questions:

    1. Why is it so difficult to customize EHR user interfaces and workflows to users’ needs and preferences?

    2. Should EHR usability be a precondition for federal EHR certification?

    3. If usability cannot be forced on EHRs by regulatory bodies, and users cannot customize EHRs into more usable configurations, what CAN be done to improve EHR usability?

    First of all, distinctions between user interfaces and their workflows are mostly spurious. They are two sides of the same coin. Lousy UIs cause lousy workflows. Lousy workflows are reflected in lousy UIs.

    Second, putting well-meaning bureaucrats in charge of usability will result in the same sort of Byzantine workflows as one sees in departments of motor vehicles and income tax return forms.

    Finally, EHR usability IS EHR workflow. Period. Workflow is a series of tasks, consuming resources, achieving goals. There is no use of an EHR that does not fall under this definition of workflow.

    EHRs and health IT in general will not efficiently & effectively optimize & integrate healthcare workflow unless & until adopting modern workflow tech. Until they do, EHR usability will be continue to be an (un)popular topic.

    I encourage interested readers toward my recent InformationWeek column on The Mismatch Between Healthcare Software, Healthcare People:

    http://www.informationweek.com/healthcare/electronic-health-records/the-mismatch-between-healthcare-software-healthcare-people/d/d-id/898883

    Happy Holidays to All!

    Chuck

  • Chuck,

    Thanks. I agree that ONC should not develop its own standards, which is why I suggested the NIST protocols. NIST is unusual in that it acts as a catalyst working with industry and users to develop standards.

    I did get a chuckle out of the comment about DMVs. If ever there were a stereotype in the public mind of a hassle that’s it. Oddly, where I live, DC, ours works quite well and it has to do not only what your state’s does, but also the city and county.

  • @Dr Webster, very useful post. . .

    1. It’s relatively easy to configure EHR user interfaces and workflows.

    Difficult, as you say to customize.

    Solution: Don’t buy a EHR system that is not configurable.

    Configuration can be done without programming, customization is expensive, time consuming and puts the customer on a slippery slope with the vendor. The vendors love it.

    2. Well-meaning, yes, but many have never set foot in a clinic, let alone your practice, so the no-surprise result is “one size fits none”.

    3. Agree it’s all about workflow.

    Since we have had workflow management systems since the mid 1950s that are highly efficient and effective across multiple areas except, for some incomprehensible reason to me, in healthcare, why do people keep saying healthcare is “special” (i.e. launching a space vehicle is also “special”)?

    A workflow is made up of nodes with connecting arts. End of. How they are connected, what forms are needed, what skill attributes are needed is all at the discretion of the end user in a particular industry as part of configuration.

    There is no secret to design of a good UI. We all come in each day, attend to our fixed time commitments, then in between these we work on to-do tasks. Solution: one screen (not 300 of these), with a calendar on one side and a task list on the other. Plus a button to get to the eHx. Of course the devil is in the details, but it’s not much more complicated that this.

    Mismatch, absolutely..

    And, sad do say, no fix in sight, so long as everyone wears blinders.

    How many clinics are making “meaningful use” (by their standards) of “Meaningful Use” software?

  • Thanks!

    I live in DC, have attended all NIST EHR usability workshops to date and written about them…

    NIST EMR / EHR Usability Workshop: A Highly Annotated Tweetstream

    http://chuckwebster.com/2011/06/usability/nist-emr-ehr-usability-workshop-a-highly-annotated-tweetstream

    The issue is not creating usability standards. I’m fine with NIST or the ONC doing so. The issue is enforcing standards (with either sticks or carrots) through non-market driven approaches.

    Efficient and Moral Market-driven EMR and EHR Usability Innovation

    http://chuckwebster.com/2011/11/usability/efficient-moral-market-driven-emr-ehr-usability-innovation

    Regarding why workflow tech has been slow to gain popularity in healthcare, here are my ten reasons.

    Top Ten Reasons EHR-BPM Tech Is Not (Yet) Widely Deployed in Healthcare

    http://chuckwebster.com/2012/10/healthcare-bpm/top-ten-reasons-ehr-bpm-tech-is-not-yet-widely-deployed-in-healthcare

    All of that said, stipulated, and acknowledged, I’m seeing many, many signs the long process-aware drought in healthcare is finally over. And discussions like this one are playing an important role in planting seeds and watering the sprouts.

  • “Second, putting well-meaning bureaucrats in charge of usability will result in the same sort of Byzantine workflows as one sees in departments of motor vehicles and income tax return forms.”

    Having government bureaucrats design EHRs is very different than having government expect certain, measurable performance of the stuff that it (i.e. taxpayers) buy or subsidize. It’s worked well for the military and lots of other federal domains. There’s no reason it couldn’t work for EHRs and other health IT (at least that purchase / built internally).

    So what performance should the government expect? Well, perhaps it should start with the systems being free of the sort of human factors issues that can result in users being induced to make decisions (or NOT make decision) that can harm or kill patients.

    Unfortunately the state of maturity among EHR vendors is such that they aren’t routinely or rigorously doing this kind of analysis themselves. In fact, they’re actively arguing that it’s a waste of time.

    Unfortunately, those who purchase EHRs are similarly immature. Asking for the results of prospective vendor EHR Usability Evaluation Results (per NISTIR 7804 guidelines) could go a long way in assessing which vendors have established expertise and human factors as an important part of their development and deployment processes and those that have not. Very, very few know or care, however.

    Ron

  • Yes – Throughout the past four decades, the U.S. Government has systematically increased incorporation of human factors analysis, evaluation and testing requirements for complex systems.

    Appendix A of NISTIR 7804 is a good summary: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909701

    Throughout the past four decades, the U.S. Government has systematically increased incorporation of human factors analysis, evaluation and testing requirements for complex systems. Consistent application of human factors and usability validation exists for commercial aviation and nuclear power
    industry systems; perhaps the most sustained of these efforts has been directed towards military system development and procurement requirements. This process has been labeled Human-System Integration
    (HSI) and covers several individual program efforts by the armed services. We briefly summarize the history and effectiveness of these programs below to provide examples of human factors and usability
    evaluation and validation processes that resulted in positive impacts on safety and effective use of systems.

  • I am familiar with government successes (and failures) in engineering complex systems, including the human factors component. I’ve an MS in Industrial Engineering and spent a year working in aviation human factors.

    I’ve written extensively about what EHR workflow and usability design can learn from aviation, most of which would not be known without government initiatives.

    EHR/EMR Workflow System Usability–Roots in Aviation Human Factors

    http://chuckwebster.com/2009/08/ehr-workflow/pediatric-emr-workflow-system-usability-roots-in-aviation-human-factors

    What Kind of EHR Would Sully Design?

    http://chuckwebster.com/2010/06/ehr-workflow/what-kind-of-emrs-ehrs-and-clinical-groupware-would-captain-sullenberg-design-intuitive-usable-and-safe

    Government Best Practices in System Usability: Brief History & Status

    http://chuckwebster.com/2011/06/usability/nist-emr-ehr-usability-workshop-a-highly-annotated-tweetstream#government

    As a graduate student I worked on numerous government and military-funded programs investigating a wide variety of user interface issues.

    I was at the NIST EHR usability workshop held with respect to the document you mention.

    And I’ll repeat what I said (quoting Clay Shirky, in an open letter to Jacob Nielsen) in my post on leveraging market-driven means to improve EHR usability:

    “There is a dream dreamed by engineers and designers everywhere that they will someday be put in charge, and that their rigorous vision for the world will finally overcome the mediocrity around them once and for all. Resist this idea – the world does not work that way, and the dream of centralized control is only pleasant for the dreamer.”

  • Again, I’ll contrast the difference between the federal government controlling design of EHRs (or their workflows) and that of establishing human performance measurement guidelines.

    NIST made great efforts to produce guidelines (like NISTIR 7804 and others) where none existed and are badly needed. Guidelines are different than standards. The response from industry has largely been rejection of human factors as a valid domain (let alone industry collaboration on building on or otherwise improving or expanding the guidance) and resistance to efforts to make human performance test results available to inform the marketplace. Not that purchasers are even asking.

    Sully wants an NTSB for healthcare (and health IT): http://www.amednews.com/article/20120514/profession/305149947/2/

    Most won’t even admit that health IT can cause harm.

  • So *again* I’ll say…

    “The issue is not creating usability standards [or “guidelines” if you prefer]. I’m fine with NIST or the ONC doing so. The issue is enforcing standards (with either sticks or carrots) through non-market driven approaches.”

  • I fear that non-market driven approaches (i.e. government regulation) will only occur after a series of high-profile health IT-related harms or deaths.

Click here to post a comment
   

Categories