By ANDY ORAM

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.