Going with the flow: interaction design for healthcare

Healthcare is a target-rich environment for design. Discussing even the smallest design challenge quickly exposes the hacked-together systems and processes that somehow function to help us stay healthy. Designers must understand the context in which they work, yet confronting the complexity of healthcare can be paralyzing. It seems impossible, for example, to discuss the viability of mobile devices at the point of care without discussing the Byzantine network of roles, regulations, and workflows that the device touches: nurse assistants, the lab, the patient, receptionists, regulatory bodies, HIPAA, hospital and lab information systems, IT departments, point-of-care coordinators, ADT systems, and so on.

While it’s important to understand the knotty context of a healthcare design problem, it’s just as important to know when to reach for the sword of methodology to cut through it. To illustrate this point, I’ll discuss some healthcare design challenges I’ve seen during my research and design work and the methods I’ve used to tame the complexity.

Software helps radiologists get work done

We’re all familiar with the archetypal X-Ray reading room; there are lightboxes mounted on the wall, doctors conferring in near-darkness, and sheets of film with cryptic wax-pencil markings. In reality, the archetype is quickly being outmoded. Most hospitals have replaced their lightboxes with PCs and now use Picture Archiving and Communication Systems (PACS) to annotate their images and publish their reports.

If you watch ER on television you’ll notice that the Radiology Department looks like it’s tucked in the corner of the basement, requiring the impatient Dr. Weaver to trek across the hospital in order to demand information from the radiologist: “Is it a tumor or not?!” In reality, Dr. Weaver would go to her PC, log into the PACS, and look at the report online: “No evidence of mass in the area of radiographic concern.” (Not exactly rich with possibilities for prime-time drama.)

PACS help radiologists quickly access, read, and annotate images, and then publish their findings for the Dr. Weavers of the world. This allows the radiologists to interpret more images, which saves physicians long walks across hospitals and helps expedite treatment of their patients. Everybody wins. PACS succeed because they support a distinct set of workflow needs by helping two key groups of practitioners focus on their work.

Nevertheless, software could do a lot more to support radiologists

While one of the great potential advantages of the PACS is the replacement of the film library with a file server, most PACS interfaces make it excessively difficult to find relevant prior exams, effectively binding and gagging the librarian and stranding the radiologist amidst the stacks. Instead of sifting through long, undifferentiated lists of prior exams, many radiologists simply order additional imagery. For the patient, this means another visit to the hospital, more time in the waiting room, and, in all likelihood, more concern and worry.

In order to get to a solution for this problem, we asked some pretty basic questions: When does a radiologist look for priors? Why? How?

We found that radiologists use relevant priors for a few basic reasons:

  • At a high level, to understand the patient’s medical history
  • At a more detailed level, to examine the progress of a particular ailment
  • In more complex cases, to closely examine a particular area of the body from a particular orientation

A quick examination of radiologists’ use of the PACS uncovered some fairly basic problems:

  • Radiologists didn’t trust the relevancy rules that created the list of “relevant” priors
  • The table of prior exams was inflexible and contained extraneous information, making it hard to scan and correlate information

During my research into this problem, I found that this was a relatively small interface problem with drastic effects on many people. The inordinate amount of work involved in sifting through old exams created more work for three already busy people: receptionists who schedule exams, technologists who perform exams, and patients. By flexibly looking at tables of exam information, the entire radiology workflow can be streamlined. In short, focus on the goals driving workflows.

What people mean when they talk about “workflow” in healthcare

The term “workflow” describes slightly different concepts in different domains. In the business process world, a workflow is a series of tasks that fulfills a business transaction. In some cases, a workflow is carried out by an individual, but more often it involves a number of people carrying out tasks that result in a unit of work. A single task, such as completing a purchase order, can feed into multiple workflows, such as ordering parts of a bill of materials and arranging payment to a supplier.

Healthcare workflows have “transactional” elements, such as admitting a patient or taking a blood glucose measurement, but focusing on individual transactions obfuscates the most important element of healthcare workflows—the need to flexibly promote and maintain the highest possible standard of care for patients. Too often, design solutions are so focused on transactional challenges that they create cascades of bigger problems downstream. And in the case of safety-critical products, these problems could have grave consequences.

My research once took me to an ER department that labored under a draconian admissions system. To admit a patient, the receptionist needed to create a profile with a name, address, insurance information, and the results of a questionnaire. Once she recorded this information, she could print out a barcoded bracelet and send the patient on her way. This was meant to ensure that the right information got in the system. Unfortunately, some patients arrive at the ER unconscious and therefore unable to provide that information, or else they are conscious but in need of immediate care and so are whisked past the reception desk. In these cases, as well as others, environmental circumstances undermine workflows put in place by narrowly-focused organizational objectives.

Because many of the devices in that ER required a scanned barcode to proceed with a test, the nurses created a bunch of John and Jane Doe profiles in the system. This meant that crucial patient information was associated with dummy profiles, requiring additional work to sift through the database and rectify these mistakes. By ignoring a common scenario, the system failed everyone who used it.

Clearly, mistakes were made, and fingers could be pointed at lots of different parties—the committee who chose the system, the regulators who demand accurate information, the vendor who claimed that the system could smoothly handle exceptions, the trainers who failed to show an essential aspect of functionality. But one could argue that good design can often compensate for the failings of systems, committees, and regulatory bodies. The fact that the system would be implemented in a STAT environment means the system should have accommodated the special workflows and re-ordering of priorities. It didn’t, though. Did this oversight compromise standards of care? Probably not, because nurses and doctors will scrap the system if it begins to infringe on their ability to care for patients. In the end, the system broke down because it ignored the healthcare workers’ single-minded focus on maintaining the highest possible standard of care.

Seeing the beach from the smallest sandboxes

Staying focused on goals and motivations helps designers see beyond the most immediate workflow challenges. Just because the design initiative has a relatively tight scope doesn’t mean that a designer’s outlook on the broader environment needs to be similarly narrow.

As hospitals move toward electronic medical records, they often look for the most expedient way to digitize every bit of information. Consequently, user interfaces throughout hospitals have been optimized for getting stuff into clinical information systems. Many practitioners within a hospital—attending physicians, nurses, nurse assistants—work in a frenetic, often open-ended way. They are interrupted constantly. They’re required to track all sorts of information. Critical data is communicated verbally, recorded on scraps of paper, or simply filed away in someone’s memory.

Input is useless if the output stinks

The biggest problem with clinical information systems—one of them, anyway—is that they’re all focused on getting information in, rather than getting it out. If clinical information systems supported the goals of healthcare users in the presence of their patients, the product would be equally inflected towards the retrieval of information. Nurses and doctors could then use handheld devices, tablets, and PCs without the excessive cognitive gear-shifting required when logging in, creating complex queries to get relatively simple information, and navigating hierarchies.

Too many interfaces require too much work to retrieve information, which reduces the incentive to put information in. And on top of it all, most system interactions take the focus away from patients and provide little in return. Software that supports healthcare practitioners would remove work and stress from their lives. It would respond to requests like: “Tell me when my patients need medication,” “Show me the trend leading to this glucose measurement,” and “Tell me which patient most critically needs to see me right now.”

Of course, the ideal form for the delivery of the information is probably not possible within the constraints of governmental regulations, the budgets of hospitals, your client’s development timeline, and the laws of physics. But it’s crucial to keep the big-picture ideal in mind when considering the small-scale solution.

In conclusion

While many domains can be considered proving grounds for workflow automation, healthcare is more accurately described as a battleground. At the most general level, effective design for healthcare anticipates the needs inherent in the workflows of doctors, nurses, and other practitioners. The same can be said in many other domains, but healthcare workflows are characterized by a unique constellation of challenges stemming from the usage environment, constraints of regulations, and the ever-present pressure on practitioners to maintain the highest standard of care.

Focusing on the motivations and goals behind the behaviors in the workflows keep designers from getting bogged down in the complexity of the problem, paving the way for the delivery of solutions that enable practitioners to deliver the best care possible.

1 Comment

The correct asenwr is it depends. It depends on a number of factors, like the business objectives of the solution, licensing, infrastructure available, capability to develop and maintain and alignment of the solution with the technology that has the features that compliment it or provided out of box. Long and short of it, use both. Howerver this does raise a good question to debate. It’s too easy or high level to say SharePoint is great at unstructured data but not great at structured data. Talking about data at all in relation to SharePoint shows here the easy misconception. SharePoint is not only about data and therefore not designed to be good at structure or unstructured data. SharePoint is a platform that can be used to bring together people, process and information. Information in a variety of formats (html, word, powerpoint, excel, pdf), structures (unstructured, semi structured, structured) and locations (other LOB systems). People from a variety of origins and processes that fit for purpose. Plus it also has pretty handy WCM and Search capabilities. My suggestion is to chose the right horse for the right course. For some things it will be CRM, others SharePoint and for many more both and a whole lot more goodness.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment