Atul Gawande has published a great piece in The New Yorker on why doctors hate their computers. The reason? Poorly designed software. Specifically, several of the examples in the story point to information architecture issues in the system. These include ambiguous distinctions between parts of the information environment and taxonomies that can be edited globally:
Each patient has a “problem list” with his or her active medical issues, such as difficult-to-control diabetes, early signs of dementia, a chronic heart-valve problem. The list is intended to tell clinicians at a glance what they have to consider when seeing a patient. [Dr. Susan Sadoughi] used to keep the list carefully updated—deleting problems that were no longer relevant, adding details about ones that were. But now everyone across the organization can modify the list, and, she said, “it has become utterly useless.” Three people will list the same diagnosis three different ways. Or an orthopedist will list the same generic symptom for every patient (“pain in leg”), which is sufficient for billing purposes but not useful to colleagues who need to know the specific diagnosis (e.g., “osteoarthritis in the right knee”). Or someone will add “anemia” to the problem list but not have the expertise to record the relevant details; Sadoughi needs to know that it’s “anemia due to iron deficiency, last colonoscopy 2017.” The problem lists have become a hoarder’s stash.
The bottom line? Software is too rigid, too inflexible; it reifies structures (and power dynamics) in ways that slow down already overburdened clinicians. Some problem domains are so complex that trying to design a comprehensive system from the top-down is likely to result in an overly complex, overly rigid system that misses important things and doesn’t meet anybody’s needs well.
In the case of medicine (not an atypical one) the users of the system have a degree of expertise and nuance that can’t easily be articulated as a design program. Creating effective information environments to serve these domains calls for more of a bottom-up approach, one that allows the system’s structure to evolve and adapt to fit the needs of its users:
Medicine is a complex adaptive system: it is made up of many interconnected, multilayered parts, and it is meant to evolve with time and changing conditions. Software is not. It is complex, but it does not adapt. That is the heart of the problem for its users, us humans.
Adaptation requires two things: mutation and selection. Mutation produces variety and deviation; selection kills off the least functional mutations. Our old, craft-based, pre-computer system of professional practice—in medicine and in other fields—was all mutation and no selection. There was plenty of room for individuals to do things differently from the norm; everyone could be an innovator. But there was no real mechanism for weeding out bad ideas or practices.
Computerization, by contrast, is all selection and no mutation. Leaders install a monolith, and the smallest changes require a committee decision, plus weeks of testing and debugging to make sure that fixing the daylight-saving-time problem, say, doesn’t wreck some other, distant part of the system.
My take is there’s nothing inherent in software that would keep it from being more adaptive. (The notion of information architectures that are more adaptive and emergent is one of the core ideas in Living in Information.) It’s a problem of design — and information architecture in particular — rather than technology. This article points to the need for designers to think about the object of their work as systems that continuously evolve towards better fitness-to-purpose, and not as monolithic constructs that aim to “get it right” from the start.