The focus on design for health IT at the HxRefactored conference on March 31 raised several tough questions about the hazard-strewn path app developers must travel in that field. My sampling of introductory workshops and afternoon sessions (I unfortunately had the chance to attend only the first day of the two-day conference) brought up many fine design principles, but most of the presenters were general-purpose designers having limited experience in health care. Still, some important distinctions to recognize when entering health IT came up.
One factor making design is so difficult in health care is the vast variety of tasks health care professionals perform. If you’re designing an app to reserve a restaurant table or buy a sweater, how many pathways can a user take? Probably at most a dozen or two. Now think of a hospital ward: one patient whose heart has to be monitored constantly, another who needs regular injections, and yet another whose medication has put her in a delirium that leads her to jump out of bed and wander. Truly, the pathways that a doctor or nurse can take through the health care application verges on the infinite.
When a designer can narrow the focus of a health care intervention, design becomes more feasible. One success story was presented by Tobias Hauner of athenahealth, whose team created a connected health app to keep patients in touch with their care teams and treatment plans. Certainly, there were many elements of workflow, because a care coordinator had to work with the patient, the patient needed reminders and educational material about her own care, and the members of the care team had to regularly update and work together around the care plan. But it seems that athenahealth could find a reasonable set of use cases for each interaction.
Hauner said that the very first task in the system, patient identification and enrollment, already sprouted complexities because there were so many ways patients got referred to the system. Insurance was another complication. But these were tamed and adapted to the app.
Nurses who acted as care managers had many ways to assess patients and develop plans, but these were assimilated into the app so that it could guide them to ask the right questions at the right time, and even suggest a list of common answers. Vital signs could be presented in two different ways to nurses: a wide range of vital signs for a single patient, or an overview of patients with a couple key statistics for each.
So athenahealth apparently got their arms around this unruly application and helped settle it down. But many other aspects of health care bring in even more dimensions of care.
Perhaps this is why EHRs are constantly criticized by users as rigid and unresponsive to their needs. The alerts and recommendations get in the way more often than they contributed to care. A solution to this complexity is hard to imagine, but it probably involves a degree of customizability that can be offered only by open source software. A health app or EHR must be a learning system as part of a learning health care system. Users must be able to change it as they understand their own workflows better.
This leads to a second difficulty in designing health care apps: the variety of users, all of whom are too busy to spend many hours over a long period of time prototyping apps. In one of the HxRefactored workshops, the question came up of how to recruit users for usability testing when the key target for the app (for instance, doctors) were too busy. The consensus was that there’s no point to doing usability testing with the wrong kind of user. The presenter said that if they designers couldn’t recruit enough doctors, they should scrap testing and just get a senior designer to step through the app.
But I think the highest hurdle raised by health care apps is their integration with real life. Most apps just take a user through an online experience, such as shopping or checking traffic. But a nurse can’t deliver a shot just by filling out the correct form in an EHR. He must alternate constantly between interacting with the software and interacting with a living human being.
At its most basic, this problem illustrates why so many doctors lose their focus on the patient’s needs while trying to satisfy the EHR, and why so many patients complain about their doctors’ single-minded focus on the screen. (Medical scribes can free up doctors, at a tremendous cost, but the split between what’s in the software and what’s sitting in front of them on the examination table remains.) But there are deeper impacts on design as well.
Essentially, a designer who concentrates on a satisfying and efficient workflow within an app is missing more than half of the context. The app must not only be unobtrusive, but must support the clinician’s interaction with the patient. I believe this is the big unsolved problem in design for health IT, and we will need many more conferences to get our arms around it.
Andy Oram is an editor with O’Reilly.
It seems as if you are trying to make an app that would follow a housewife-homemaker around the house recording everything she does so that she may 1. bill her husband 2. get real time advice on how to fix the faucet, etc. 3. organize what she has done so that she can become more efficient herself and describe her work for a temp to come in on vacations.4. stay safe 5. not get fined by county building codes by converting a garage. 6.record her work without the recording effort itself becoming too much of her work. 7. receive aproval from her local women’s rights group.
Thanks, Bobby and Dr. Carter, for your comments. And thanks especially, Dr. Carter, for the pointers to your articles on EHRs and workflow. I think all EHR vendors at least pay lip service to supporting workflows (and not all workflows are good ones, either–some need to be replace). Let me see you and raise you one: an EHR should be split into two parts. The back end is just a data respository, as you mentioned in one article. But an open one with a simple and completely accessble API such as SMART. The front end is no single EHR, but a whole third-party market place of apps to solve different needs.
Agree. Split the functions and allow all to be optimized independently– data/semantics, EHR/records/billing, workflow engine, and clinical work interface. This post describes a possible architecture with this separation: http://ehrscience.com/2014/07/14/building-clinical-care-software-systems-part-i-issues-and-challenges/.
Andy, you make some insightful observations. The design metaphor for systems that assist clinician professionals must be clinical work. Clinical work consists of an array of tasks that overlap and change from minute to minute. Thus, modeling clinical work is a good place to start when designing clinical care systems.
This is not to say the electronic health record is a bad idea. The design metaphor for current EHR systems is the paper chart. There is a need for chart functionality, but that functionality is not identical to that required to support clinical work. Acceptance of this distinction would go a long way to creating better software for clinicians.
“Essentially, a designer who concentrates on a satisfying and efficient workflow within an app is missing more than half of the context. The app must not only be unobtrusive, but must support the clinician’s interaction with the patient. I believe this is the big unsolved problem in design for health IT”
Yes. This is Jerome Carter MD 101 over at his excellent EHR Science.