A Role for Workflow Tech in User-Centered Design?

Change is always a challenge, and how much more so when software is involved.   Software implementation brings headaches from the software itself (installation, configuration, training) as well as the necessary adaptations in workflows (how work is accomplished) and work habits (how individuals do their jobs).   One assumption underlying nearly all implementations of clinical systems is the immutability of the software.   Software workflows are usually impossible to change, so people take it on the chin.

Complex software, such as an EHR, changes many workflows at once. Software systems that are considered limited in scope, for instance a disease registry, also change workflows and work habits significantly, though for fewer people. One way of lessening the impact of an implementation is by use of a staging system (i.e., a copy of the production system that users can access before go-live).   Staging systems can lessen the ultimate workflow shock by spreading it over a longer period and making the worst disruptions known before actual go-live. However, if the system has static workflows, disruptions will still occur because users will always have to adjust to the system’s way of doing things.

User-centered design (UCD) is gaining mindshare as the best means of creating systems that do not disrupt workflows.   The assumption behind UCD is that getting users involved during software design should result in systems that are more attuned to user workflows, thereby decreasing workflow disruptions and making implementation and optimization easier. Unfortunately, if the UCD process produces systems with static, hard-coded workflows, the problem has been ameliorated for a while, but not solved. If real-world processes change and different workflows are required, either the software will have to be rewritten, or disruptions will appear. What is needed is software that can easily adapt to the user.

Implementation of software systems with static workflows, and software creation using standard software development methods (some form of objected-oriented analysis and design [OOA&D]), share a common and very much ignored failing—neither offers explicit, mutable models of user workflows that can be readily altered after go-live.   Software with static workflows has no “knowledge” of what users do, and even worse, no way to change its own workflows without significant programming.   OOA&D can capture user workflows, but if the final system makes them implicit and ties them to object behavior, the ability to examine and change those workflows in the final system disappears.   Without making workflows explicit and mutable, UCD cannot solve all (likely not even most) workflow disruption problems. In fact, the more complex a clinical process is in the real world, the more unlikely it is that a static software system can be designed that would be equally supportive of all user workflows in all settings—that is simply too much to ask.

Now that I am working with business process management and iOS development on a daily basis, the problem of marrying BPM methods to OOA&D thinking has gone from an interesting question to a business issue.   The outcome, thus far, has been a deeper investigation of prototyping and requirements gathering using BPM tools.

BPM systems are quite flexible in how quickly they allow one to create a process model (workflow) including data/variables and run it. Since entire suites can be downloaded to a local server or provisioned in the cloud, it is relatively easy to create an application that can be accessed by whomever one chooses.   The big difference here is that, unlike use cases or activity diagrams, changing BPM process models changes the actual application!

Once the initial process model has been developed, refining it can be done quickly. As a bonus, there is a visual representation of the process that users can view, critique, and interact with.   In real-world terms, this means one can design a workflow for managing patient calls, create a BPM process model, deploy the application, and decide, based on actual use, what features the system should have! Such an approach could be helpful for determining requirements even if that specific system is never put into production.   I’m thinking that BPM prototyping is a better way of doing use cases (or a least a very helpful adjunct).

Because it is possible to model real-world workflows that one can interact with, reengineering efforts that precede implementations also seem like good candidates for BPM prototyping.   BPM systems have user interface design capabilities that allow one to design forms and screens so prototypes can have good fidelity to pre-existing information artifacts.

Having sung the praises of working with BPM tools, I must say that I have come to appreciate the sophistication of iOS’ MVC implementation. BPM tools still seem to be in the Visual Basic 6.0 era in terms of how forms and screens work–forms/screens seem to be tightly-coupled to the underlying data.

The big money question, at least for me, is how to arrive at the best blend of iOS and BPM in terms of software development and supporting users in their daily work.   I am discovering that one thing that is really needed is a much better way of decomposing clinical processes into information movements and control-flow, and then representing those properties in some standard way.   Along with standard process representations, it would be nice to have user interface guidelines that are process-focused instead of data-focused. For example, instead of a chart heading such as “problem list” and what should be seen on the screen for a problem list, there would an item called “initiate work-up” or “review problem status” that offered assistance or feedback for managing a problem/diagnosis. (BTW anyone with suggestions for EHR functions or behaviors, please feel free to send suggestions).

It is still early in my exploration of process-aware clinical systems, and I like they way things are going. Every day it becomes clearer that supporting clinical work can be done with less complex (internally) systems that are more process-centric, and made of up components accessing a common platform. Such systems would be easier to deploy, could be sold based on the specific functionality desired by the user, and likely, less expensive to build or purchase. We shall see…

In any case, I think both UCD and implementation planning would benefit significantly from prototyping and simulations using explicit process models.   After all, if the goal is supporting user processes, why not use methods that make those processes explicit, mutable, and transparent?


Leave a Reply

Your email address will not be published. Required fields are marked *