Software should make one’s life better. Otherwise, why use it? Clinical software should make completing clinical processes more efficient and productive. Unfortunately, the complexity of clinical processes, even those considered simple by most people, is often underestimated. Clinical processes require thought and action. Thus, any given workflow must account for one or more of the following:
- Information movements (creation, use, production)
- Control and flow of actions (sequences, parallel paths, merges, splits, cancellations, iterations, etc.)
- Resource use (equipment, reagents, supplies, etc.)
- People (participants – those performing actions, recipients – targets of actions)
UI design is hard because user interfaces must manage workflow complexity while supporting clinical work in a manner that is intuitive and unobtrusive. Current EHR systems have hard-coded, implicit workflow support (i.e., they make assumptions about the four aspects of workflows then embed them in programming code). As a result, changes in processes can easily require changes in programming code. Even worse, there is no such thing as individual adaptations for personal work habits—it is simply impossible. Thus, the first step toward better EHR user interfaces is breaking up the components of clinical software systems so that the UI can be optimized for each user. MVC architecture is an example of this approach. So, how do we use loosely-coupled, highly-cohesive components to build better UIs? We start by thinking in terms of processes and workflows.
Getting to clinical process basics
When clinical work support is approached from a purely data-centric view, the result is a UI that is filled with data without regard for priority. Clinicians have to find the data needed as they work. Moving to process-aware interfaces requires gathering information about what work is being done, the information needed, the resources used, and the people involved. What does a medical ICU nurse do hundreds of times each day versus only once? What information is required, and what is optional? What does a primary care doctor do for every patient, and what is done only for patients with diabetes? What should be done for every new physical therapy patient, and what is to be done only for those with knee replacements? There is much more to clinical workflow analysis than figuring out the steps.
UI design also requires that workflow analysts and software developers account for the differences between group and personal workflows (see Preventing Your EHR from Working Against You: Personal Workflow Analysis). Most examples of workflow analyses are biased toward group workflows. Group workflows tend to emphasize patient movements. For example, a typical workflow diagram of an office visit will show how the patient moves from check-in, to nurse, to doctor, to lab, etc. Patient movements within group workflow diagrams capture the outcomes of interactions with staff members and clinicians (e.g., registered, vitals done, exam completed, labs drawn, and checked-out are the results of interactions). However, for UI design, one needs workflow analyses that capture what participants (clinicians and staff) are doing along with patient movements.
Typical questions for personal workflows should ask what is done before, during, and after a patient interaction. Here are a few examples:
- What steps, information, or resources, are required to initiate the process?
- What job role is responsible for managing the process?
- What information must the patient provide?
- What information should appear on the computer screen to support the process?
- Are there sub-groups of patients? If so, how do they affect the process?
- What steps, information, or resources, are required to complete the process?
Without answers to questions like those above, creating a UI that supports clinical work is difficult. However, answers alone are not enough. User-centered design processes must be in place that allow adjustments to the UI using real-world feedback. Even so, UCD is best for designing for UIs for groups of users; individual adjustments require widgets.
Widgets and clinical care system architecture
Providing the ability for each user to adjust the UI as needed must start deep within the system. And, since we are talking workflow and data adjustments, that means a mechanism is required to permit users to modify the data presented and the process steps, but ONLY for themselves. This is where widgets come in handy.
Below is an architecture that accommodates widgets (update to 5/12/14 Clinical Care System Architecture. EHR component not shown). It consists of six main components: patient data, process data, information manager, algorithms, workflow engine, and user interface.
Patient Data – contains all patient-related information.
Process Data – contains the data related to the four aspects of workflows/processes.
Information Manager – provides semantic references for patient data. What a CBC is, is stored in the Information Manager while the labels and values of a CBC are stored in Patient Data.
Algorithms – stores software code and clinical rules for managing patient data. An abnormal CBC result would be flagged here and that message would be passed to Patient Data and to the Workflow Manager.
Workflow Manager – provides tools to define and execute workflows. It requests clinical information through Algorithms and passes results to back to the UI. Manages process execution: control-flow, information, resources, and people.
User Interface – a collection of widgets.
Widget – a UI component that presents data in concert with workflow steps. Standard widgets match common chart sections — problem list, medication list, vital signs, etc. Each widget provides a “settings” feature that allows for adjustments in color, layout, fonts, and screen position as well as workflow steps. A widget library would provide access to permitted widgets by job role.
Many assume that workflow support necessarily means a computer telling them what to do. If a protocol has been programmed into an EHR, then, yes, it might be pushy. But that is not an absolute feature of workflow support. Assistive support can provide help in context. At times, both may be employed. Since we are talking about personal workflows and UI design, the focus here is on assistive.
Let’s assume that a system offers a problem list widget. The basic functions are there (add, save, sort). Configurable workflow support could be offered in a number of ways. For example, if an infection problem is added to the list, say otitis media, the widget might offer additional work support that could be activated and configured by the user – pop-up of suggested medications, recent microbe data, review article link, tracking/alert support (e.g., an alert when microbiology report is available). If there were a clinical rule for otitis media that all providers had to follow follow, the widget would receive that information via the workflow manager as well.
Widget support need not be limited to standard chart functions. Any clinical process would benefit from the flexibility provided. If the UI is a collection of widgets, it can be easily redefined. Thus, different clinical processes could have specialized UIs simply by selecting from a library of possible widgets.
Preventive care and results management are two common clinical activities that could benefit from special interfaces. The combo of widgets, along with the proposed architecture, would make functionality that now often requires separate applications attainable within a single environment. Creating support for a new process would be straightforward: Add clinical rules to Algorithms and process information to the Workflow Manager, then build/alter widgets as needed.
Flexible architectures allow clinical software to offer a level of functionality beyond that of current systems. Productivity, safety, usability, and decision support converge in the user interface, which means the UI should be a first-class citizen in any clinical software system. Outmoded client/server designs stymie innovation by making some problems harder to solve than necessary. We have the tools required to create modern, process-based user interfaces — why not use them?