Complicated, Complex, Labyrinthine?

An introduction to the ambulatory EMR as a Hyper-Complex system

The difference between complicated systems and complex systems is well explored.  A complicated system has many components, and the behavior of each individual component is predictable.  This means that the system behavior as a whole can be known, and controlled, by knowing and controlling the starting conditions.  In contrast, a complex system is one in which the individual components interact with each other, react to outside influences or otherwise introduce variability.  This means the entire system is difficult, or even impossible, to predict, model or control.  A good explanation of this principle from the Shoremount website, with examples:  Human Orgs: complex vs. complicated systems

This principle can be applied to the analysis of user-driven software.  An example of complicated software might be that used by a bank teller.  At the banking window, a real-life customer interaction has a finite number of pathways: she might present a cash deposit, ask about a balance, or request a money transfer, for example.  The teller's workflow, in software, will parallel these real-life events.  The workflow may be complicated and have many branch points, but software developers can take this into account at design time.

An example of complex user-driven software might be a suite of office programs, like email, calendar apps and so forth.  The number of options in office software at any moment is finite, but huge, and user actions are relatively unpredictable.  Combinations of actions interact with each other: reading a message, composing a reply, scheduling a meeting, updating a contact, defining a task… taken in combination, these steps result in countless states and outputs.  We can define a user scenario, and include the user's role, their goal and their starting conditions, but we still can't predict the steps they will take to complete a task.

The complicated banking software and complex office software are quite different, but still have something in common: the users' principle tasks are carried out on, and through, the computer.  Some tasks are software-centric, like writing email.  Others relate to real world events, like scheduling a meeting or moving money, but the relationship is straightforward: a sequence of events in real life is paralleled by a sequence of actions in software.  This lends itself to design tools like workflow analysis.

In workflow analysis, developers study users and their work to learn which actions typically follow which, and why.  A user action, taken in context, suggests a range of likely next actions.  Workflow-based design can be very powerful, especially when combined with machine learning, even in the face of significant system complexity.  The resulting systems can allow users to forge their own path for completing a task (within certain constraints), as software lights the way with data, suggestions and opportunities to facilitate their work.

In EMR design, this is a solid approach for frequently repeated workflows, and those of an administrative or support nature.  Any clinical user can cite examples where their EMR efficiently facilitates work and anticipates their needs for a particular task.  But for a user whose path is less predictable, like a primary care clinician in a busy team setting, the workflow approach to design quickly falters.  Not only are the clinician's actions rife with variability at every step, but a step often seems disconnected, out of sequence, or random.  The primary cause is that although clinicians use the EMR constantly, their primary work is not carried out on, or through, the computer.  Their primary inputs are patient-oriented, their primary activity is decision making, and their primary outputs involve human interactions – which are only partially carried out in software, and only sometimes reflected in the EMR.

The boundary between software and the physical world is easily overlooked.  Whenever a user crosses this boundary, there is a disconnect.  The disconnect may be almost invisible, such as when a bank teller looks up to ask the customer a question, then goes back to the computer to choose a software option based on the answer.  Other disconnects are quite disjunctive, and we see this constantly in primary care.

Example: A clinician is typing a patient's story, in the HPI of their encounter.  Something the patient says makes them stop, and review the active medication list instead (e.g. the patient's symptoms have changed).  As the clinician considers adjusting a med dosage, they switch over to their future schedule, because they realize they can't make that particular adjustment without close follow-up.  From there, they glance at the vital signs, then at the most recent lab results, as these both need to be monitored.  They place an appropriate lab order, send a scheduling message their staff, and jump to their final Assessment & Plan to write a prescription and start the documentation, to be completed later.  Finally, they return to the HPI and continue where they left off.  This type of thing happens constantly.  It might take only two minutes, and is often done while talking with the patient at the same time.  Every extra click, every pause, every discontinuity in the software experience interrupts their conversation, their attention, and the care they are providing.

When an EMR is designed only to support workflows, it trails woefully behind as the clinician jumps from place to place, doing seemingly random things, that barely seem to constitute a workflow at all.  Compared to the complicated and even complex software systems, the primary care EMR flow appears labyrinthine; perhaps "hyper-complex" is a better term.  The experience will feel interruptive, awkward, repetitive, and disorienting to the clinician as well, as they abandon tasks, change gears, retrace their steps and click through meaningless sequences before getting what they need and back to where they started.  

The core problem is that the PCP's next actions cannot be adequately predicted from their previous actions.  Even so, the steps they take are intimately connected by the very thing that primary care clinicians do most often, and do best: make decisions.  It's what they do all day long, big decisions and small decisions.  Data to make decisions comes from the real world, and from the computer.  Actions resulting from decisions are carried out in the real world, and in the EMR.  We need a whole new approach in order to analyze clinical behaviors in this light.

Imagine that the issue in our clinical example is hypertension.  If an intelligent, human assistant knew a clinician was considering a change in blood pressure treatment, they would know right away what data is needed: blood pressure history and trends, doses of current BP meds, most recent lab results (like a metabolic panel), the treatment plan from last visit, and any related medical issues like heart or kidney disease.  They would prepare the common orders and follow-up for the clinician to select and confirm.  These elements may be widely separated from each other in the EMR, in terms of where they are stored, how they look on the screen and how they are used, but they are closely connected by the clinician's decision process.

Replacing workflow analysis with decision analysis is a huge proposition; arranging data and controls dynamically by functional criteria is a huge part of that, and these will be discussed at length in other writings.  But I put forth for consideration that the next step in EMR evolution will include software that can:

1.       Continuously follow the gestures and actions of the clinician to intuit what they are thinking about, and what decision they are making

2.       Collect and present functional data to the clinician at every step, targeted to increase their state of readiness to make their next decision

3.       Surface predictive opportunities, to help the clinician carry out the most common software actions resulting from the decision at hand

The long term goal of this channel is to present the definitions, analytic methods and iterative design techniques that can help lead to such a system.  But before we get there, further exploration is needed into factors that hold the industry back.

The Functional EMR Guy: This channel offers a view of ambulatory EMR technology from my experience as a clinician, clinical informaticist and software engineer.  My driving vision is a practical approach to functional analysis and design, to help clinicians help patients by creating better EMR systems. Please subscribe! I won’t send spam or share your info.