Readers Write: Requirements Versus User Experience: The MU Design Impact on Today’s EHR Applications
Requirements Versus User Experience: The MU Design Impact on Today’s EHR Applications
By Tom Giannulli, MD, MS
Since the first electronic health record (EHR) applications, the federal government has been looking for ways to leverage EHR technology to improve the quality and cost of healthcare delivery. A decade ago, President George W. Bush declared that every American should have an electronic health record within 10 years. While we’ve come a long way, almost half of all medical providers are currently searching for an EHR, installing one now, or looking to switch out the one they have in place.
This is an eye-opening situation given the investment of billions of dollars in EHR technology by healthcare providers, technology suppliers, and the government via incentive programs. Why is this? One contributing factor is that the government incentive programs have excessively focused on features over user experience and outcomes.
When the current EHR incentive programs emerged in 2009, EHR suppliers with existing products were faced with the challenge of meeting Meaningful Use (MU) requirements. It’s not easy to retrofit new functional requirements into an existing product, and it’s commonly understood many suppliers had to focus on achieving functionality requirements however possible given the potential impact of government incentives. The time-bound goal was simply to get X feature programmed in Y weeks so that version update or hot fix could be applied to meet customer certification timelines.
Function ruled over form, often resulting in degraded user experience and sub-optimized workflows. In hindsight, it may have been better to have fewer incentive program requirements with broader definitions and simpler tests to validate compliance.
For example, assume a general requirement for physicians to be able to share standardized clinical documents with basic tests of compliance. With this more general goal, technology suppliers would have greater freedom around how to solve the requirement resulting in a greater range of solutions—some of which likely would have superior usability. The market would then reward the company that best met both the requirement and the associated usability and user satisfaction.
The overall goals of MU are sound; it’s simply that in practice the extent and specificity of the requirements often overemphasize feature content and prescribed usage at the expense of user experience and the innovation that comes with flexibility. A doctor on HIStalk a few weeks ago highlighted this reality:
“When you’re used to using very clean designs—a MacBook, an iPhone, Twitter, Facebook—and you sit down on an EMR (electronic medical record system), it’s like stepping back in time 15 or 20 years.”
I had the opportunity to build an EHR after MU Stage 1 had been established. This allowed us to take a more comprehensive approach in terms of meeting our overall design goals, including usability, as well as MU requirements. We wanted to make it possible for the physician to use the application to chart patient visits and the required data and reporting were generated as an by-product of normal use.
Now, we are facing changes for MU Stage 2, integrating those into an existing product, tying them to user needs in a way that makes sense. We have developed a process that uses a lot of user feedback and testing and we try to iterate quickly with releases at least monthly.
But the fact is that the specificity of MU and the rigorous testing don’t provide for the best user experience. Ironically, these really specific requirements—a number of which dictate the user experience to a large degree—are supposed to be creating improved usability when in fact they are detracting from user-friendless and improved workflow.
I believe that without MU, many EHR features would be similar, but there would be notable differences resulting from the focus on user feedback versus government direction. As a physician and an EHR designer, I would still want to track health maintenance and have tools to manage people’s care. The big change would be the ability to focus on some market-driven elements that we haven’t been able to spend as much time on because they aren’t MU requirements.
We would be spending more time looking at how we could use the practice data to highlight workflow problems or areas where the practice isn’t using best practices. By leveraging our large pool of operational and clinical data, we could generate more recommendations for practice optimization and patient care. These are very high level concepts that we are exploring, but are at a lower priority given the resources required to implement MU2 in a way that is well integrated and results in a positive user experience.
In a perfect world, current MU2 requirements would be replaced with just few high-impact goals related to interoperation and communication. Current MU2 requirements have added little new incremental value while creating a significant burden for vendors and end users. This situation is even more challenging in that the requirements are becoming more specific and dictate user interaction in some cases. The structure is in place to capture discrete data, measure quality, and communicate standardized data.
At this point, I believe the market should drive the process of advancing features and expand-on the valued features outlined by the MU requirements.
Tom Giannulli, MD, MS is chief medical information officer at Kareo.