Short Link: http://j.mp/9bm9Gp
Herbert Simon, a Nobel Prize-winning economist (and fellow alumnus, I never fail to mention) helped found the fields of artificial intelligence and cognitive science. He “was one of the most influential social scientists of the 20th century” (Wikipedia). I attended his lectures at Carnegie Mellon University, where his ideas about attention, bounded rationality, and satisficing provided grist for many research projects and Ph.D. theses.
Herbert Simon’s Autobiography: Models of My Life
Prof. Simon distinguished between well-structured versus ill-structured problem solving, in some ways prefiguring a debate within the business process management (BPM) community about adaptive case management and predictable vs. unpredictable, formal vs. ad-hoc, easily vs. barely repeatable, and structured vs. unstructured work and processes. For some flavor of this debate see my trip report to the recent Process.gov conference, which featured a track on adaptive case management.
Herbert Simon offered his well-structured vs. ill-structured dichotomy in his 1973 paper “The Structure of Ill-Structured Problems” (Artificial Intelligence 4: 181-201., not available on-line, however there is a wealth of online material quoting from Simon and commenting on his ideas). I used Simon’s distinction in the section Informal & Unstructured vs. Formal & Structured Care Coordination in my post Clinical Groupware, Care Coordination, and EMR Workflow Systems: Key Ideas, when I wrote:
“[There is a spectrum] between well-structured and ill-structured cooperative problem solving, and the kinds of groupware needed to facilitate computer-supported cooperative work in healthcare. Both kinds of cooperative problem solving require clinical groupware. EMR workflow systems fare especially well on well-structured care coordination problems. [They] handle both ends of the spectrum well: a workflow engine to handle routine group workflows and an office view to handle non-routine group workflows.” (Clinical Groupware, Care Coordination, and EMR Workflow Systems: Key Ideas)
I’m interested in comparing and contrasting different kinds of clinical groupware. Why? Well, my intuition is that as EMRs and EHRs evolve into, or are replaced by, clinical groupware alternatives, no single kind of clinical groupware will serve every purpose. Well-structured versus ill-structured processing and problem solving seems like a good conceptual spectrum along which to compare different sorts of clinical groupware systems.
In particular, clinical groupware supporting patient-physician encounters in the medical office must help users to deal with both well-structured patient encounter workflows (the thirty-second otitis media encounter) and ill-structured workflows (the more complicated, less routine collections of interacting medical problems).
After the next paragraph are passages from Simon’s 1973 paper, quoted in a chapter on medical artificial intelligence by one of Simon’s Ph.D. students, Harry Pople’s “Heuristic Methods for Imposing Structure on Ill-Structured Problems: The Structuring of Medical Diagnostics.” Chapter 5 in Szolovits, P. (Ed.) Artificial Intelligence in Medicine. Westview Press, Boulder, Colorado. 1982. (I was a research associate in Prof. Pople’s Decision Systems Laboratory at the University of Pittsburgh School of Medicine, home to the INTERNIST-I and CADUCEUS medical expert systems projects.)
Simon described the work of an architect in terms consistent with today’s goals of adaptive case management, to provide tools to support knowledge work. However, Pople quotes Simon in the context of another kind of knowledge work, medical problem solving. The analogy between architect and clinician is intriguing. Used as a verb, “to architect” means “to plan, organize, or structure.” Future EMRs will need to do a better job of helping their physician users to plan, organize, and structure patient care processes. Much of this blog is essentially an argument that EMRs and EHRs must become more like business process management and adaptive case management systems to most effectively accomplish this. But enough about what *I* think, what did Herbert Simon think about well-structured versus ill-structured problem solving?
It will generally be agreed that the work of an architect–in designing a house, say–presents tasks that lie well toward the ill structured end of the problem continuum. Of course this is only true if the architect is trying to be “creative”–if he does not begin the task by taking off his shelf one of a set of standard house designs that he keeps there.
The design task (with this proviso) is ill structured in a number of respects. There is initially no definite criterion to test a proposed solution, much less a mechanizable process to apply the criterion. The problem space is not defined in any meaningful way, for a definition would have to encompass all kinds of structures the architect might at some point consider. … even if we were to argue that the problem space can really be defined–since anything the architect thinks of must somehow be generated from or dredged from, his resources of memory or his reference library–some of this information only shows up in late stages of the design process after large amounts of search; and some of it shows up, when it does, almost accidentally. Hence, the problem is even less well defined when considered from the standpoint of what is actually known at any point in time than when considered from the standpoint of what is knowable, eventually and in principle.
We can imagine a design process that proceeds according to the following general scheme. Taking the initial goals and constraints, the architect begins to derive some global specifications from them-perhaps the square footage or cubic footage of the house among them. But the task itself, “designing a house,” evokes from his long-term memory a list of other attributes that will have to be specified at an early stage of the design: characteristics of the lot on which the house is to be built, its general style, whether it is to be on a single level or multi-storied, type of frame, types of structural materials and of sheathing materials, and so on. … Design alternatives can also be evoked in component-by-component fashion. The subgoal of designing the heating system may lead the architect to consider various fuels and various distribution systems. Again, the source of these generators of alternatives is to be found in his long-term memory and reference facilities (including his access to specialists for helping design some of the component systems).
The whole design, then, begins to acquire structure by being decomposed into various problems of component design, and by evoking, as the design progresses, all kinds of requirements to be applied in testing the design of its components. During any given short period of time, the architect will find himself working on a problem which, perhaps beginning in an ill structured state, soon converts itself through evocation from memory into a well structured problem.
Herbert Simon’s last line is key. Ill-structured problems can become well-structured problems. If there are, indeed, two different kinds of clinical groupware, one for ill-structured, ad-hoc, creative cooperative problem solving and one for well-structured, formal, routine cooperative problem solving, then they need to work together well.
Consider an analogy. Prior to the automatic transmission, driving a car was physically and cognitively (due to distraction) demanding. Cars that automatically adapted to changes in terrain were easier to drive and needed less skill. Similarly, today, EMRs should speed along well-structured workflows in high gear. When encountering a sandy hill of ill-structuredness, they should, gracefully, without driver distraction, shift into low gear–then back to high gear and high speed at the next stretch of level and smooth pavement. High speed/high gear corresponds to executing process models that offer the right screen with the right data or order entry options to the right person at the right time in the workflow. How? Though execution of a BPM-style process model of routine, predictable workflows. Low speed/low gear corresponds to falling back on adaptive case management-style tools for dealing with unexpected, and therefore not modeled, circumstances.
Of course, analogies are like cars; they break down if driven too far.
I thought about titling this post “What Would Herbert Simon Say about BPM and Adaptive Case Management” or “What Would Herbert Simon Write about the Need for Different Kinds of Clinical Groupware” or even “What Would Herbert Simon Tweet….” Ultimately his thoughts on these specific topics are unknowable. However, Herbert Simon’s comments about problem solving and structure are even more relevant today than in 1973.
We are the verge of creating automated environments to partner with clinicians in managing and solving ill-, and well-, structured patient care processes and medical problems. Our degree of success will directly determine the usability of the EMRs, EHRs, and clinical groupware and therefore the success of the entire EMR, EHR, and clinical groupware adoption enterprise.