When EHR design is a 'what not to do'
Among the healthcare developers workshopping better approaches to technology design at HxRefactored in Brooklyn next week will be Stephen Buck, who'll offer some "lessons learned" from looking closely at leading EHRs – specifically, how not to design a user interface.
HxRefactored, which represents a coming-together of Health 2.0’s Health:Refactored and Mad*Pow’s Healthcare Experience Design conferences, will take place May 13-14 at the New York Marriott at the Brooklyn Bridge. There, 500 or so designers and developers will gather to explore new and innovative ways to improve healthcare experience for patients and physicians alike.
Buck leads the mobile health product management team for Danbury, Conn.-based health IT firm IMS Health. This past December, IMS launched a SaaS-based app prescribing platform called AppScript, which corrals more than 40,000 downloadable iOS and Android apps, categorizing them and evaluating them -- based on functionality, peer and patient reviews, certifications and more -- to help physicians know which ones would do best for their patients.
As IMS worked to develop AppScript, seeking the best way to present all that information and smoothly integrate app prescribing in clinical workflow, there was an "evolution" in their process before finally "(getting) to the to the design we landed on," says Buck.
Physicians were interested in making better use of apps, he said. But "initially, because apps were so new, we heard physicians saying, 'It's so confusing, I don't know which app to prescribe, I need a taxonomy, I need to understand what apps do what.' There were a lot of demands, in terms of information."
At the same time, Buck realized there were some insights to be gleaned by the news reports he'd seen calling 2013 "the year of the great EHR vendor switch."
[See also: EHR users unhappy, many switching]
"So many people who had just adopted a system hated their system," he says.
They were too clunky, too busy, too confusing, too ungainly in their presentation of data, too counterintuitive -- altogether too overwhelming. The features docs wanted easy access to were often hard to find, while they had to whack their way through brambles of less necessary data fields to get to what they needed.
"That influenced our design of AppScript," said Buck. "We had an initial design that was a lot more complicated – there were little badges for each app: 'This app is really good at security,' or, 'This app is really focused on recording patient information, and this one connects to Facebook.'
"But all this extraneous detail was in the way of what was the primary purpose of this software, which was that, in 20 seconds or less, a physician asks, 'What's your phone number, what type of phone are you using? I'm gonna prescribe you an app.'
"We realized quickly that physicians weren't going to be prescribing 100 apps; they were going to be prescribing probably five that they know and rely upon and trust," says Buck.
"They don't need to be presented with a lot of information," he adds. "They need to be able to tab over to another window or have this on their phone where they hit a big blue prescribe button. From a design perspective, we did a lot of research into how we take the other information doctors want and put it into the software in a way that's out of the way."
That "easy, simple, don't-even-have-to-think about it" approach is "such a contrast" to what he often sees when he's in the doctor's office, says Buck.
Just the other day, he recalls, his daughter's physician was "fumbling through" the many data fields of an Epic EHR and still, despite more than one clarification, managed to put a prescription through to the wrong location of the local pharmacy.
Another time, Buck recalls a doc asking him to remind him of a particular medication he'd been prescribed before: "'Can you tell me the name of that drug?'
In fairness, most vendors would counter that the sheer number or operational capabilities they have to supply – not to mention regulatory boxes they must check off to be meaningful use certified – means that their products will necessarily be busily designed.
Buck suspects there's another phenomenon at work as well.
On some developer teams, "if you come up with a simplistic design, it's almost like you haven't done your job," he says. "That you didn't think about this, or you didn't think about that. It's this funny game I've seen in corporate cultures – almost a game of CYA, in terms of design: If you throw the kitchen sink at it, no one can claim you didn't think of all the things you could possibly need."
It can be hard to resist that notion, says Buck. "I believe you have to fight for simplicity sometimes."