Jerome Carter, MD  December 13, 2015

Part IV: Intended Use and the Level of Detail
In most healthcare organizations, clinical workflow analysis (CWFA) is done to assist with software selection and/or implementation.  As a result, outside of these two functions, CWFA is rarely used as a tool for understanding clinical care or clinical systems.  Perhaps, the utility of CWFA is underappreciated because many analyses are modeled using flowcharts and swim-lane diagrams, which are not the best tools for capturing the full range of information that makes up any clinical workflow.

Clinical workflows consist of steps that use resources and consume and produce information.  Appreciating the complexity of clinical workflows requires the ability to capture all of their details in an organized, contextual manner.  This level of information capture requires new modeling tools and new ways of deconstructing workflows.  Fortunately, most of the needed tools already exist.  However, before discussing the tools, it is best to understand how the intended use of a workflow analysis determines tool choice.  Let’s start with the usual suspects.

Software selection
No one wants software that hinders his/her work or disrupts the usual way of doing things.   CWFA can be used to get an idea of how software works, either for or against you.  Modeling current workflows  helps to identify processes and information needs. For example, if a clinician writes many prescriptions each day, the time it takes to create one electronically is critical.  Watching  demos or writing one or two prescriptions on a demo system will not give one an idea of how the system will perform in day-to-day practice.   That knowledge can only be obtained from a realistic simulation—a test script.   

Test scripts are developed from workflow models.  First, one models the pre-software workflow sequence in order to determine every feature the software must have in order to support the workflow.     For example, many prescription writers are not designed for pediatric patients.   Even when systems say they support pediatric patients, they may not do so well.    Test scripts that focus on writing pediatric prescriptions would help to ferret out inappropriate systems. 

Test scripts require detailed data, and ideally, should use real patient data (e.g., diagnoses, meds, notes, etc.) so that feature use and data entry closely match real-world activities.  Since test scripts usually involve one person interacting with software, flow charts are fine to document the workflow (test data sets are best kept separately). 

Software implementation
Software implementation requires that clinicians change their habits to match how the software works.  Test scripts can help one chose the best fit, but additional changes will be necessary.  Software implementation changes not only personal work habits, but also group work interactions.  Workflow models have to account for these changes.   


Models must account for interactions between job roles as well as resources (e.g., EKG machine or IV pumps).  Specific software functions may be added to the workflow model if desired. Otherwise, generic functions (e.g., select patient, save note) without details concerning information movements will work fine.  Swim-lanes are fine here as they allow for actors and control-flow sequences.

Clinical decision support
Decision support requires provision of information to clinicians at the steps at which they are making decisions.  Thus, decision support requires step-level detail concerning information needs in addition to control-flow, job roles, and resources.  Since control-flow may be more complex (e.g., branching, iterations, parallel paths), a better way of describing control-flow is required.  
Workflow patterns provide the concepts and terminology to capture intricate control-flow scenarios.    Decision support workflows could benefit from formal workflow languages such as YAWL or BPMN. Both languages support workflow patterns, including information movements and resource use.

Software design
Designing software to support clinical work requires that one have an intimate understanding of clinical processes.  Clinical software design is really a more general case of CDS design—every clinical software system supports decision-making and clinical work at some level.  Obviously, if the goal is an entire system rather than a limited tool, the design challenge is greater. 

From a workflow analysis perspective, however, the problems are the same.   Fortunately, object-oriented software design has its own type of workflow tool in the form of use cases.  Use cases describe the interaction between system and user, so they describe workflows.   Use cases are a form of workflow model, albeit a very general version (see Use Case, Requirements, and Workflows--Clinical Swift Series, IV).  The important thing is that OOD&A has a workflow method that can be adapted to a workflow language such as BPMN or YAWL.   The availability of BPM software that can be used to create or support clinical application development makes the use of BPMN for use cases even more attractive.   Unfortunately, workflow technology is rare in clinical care, and few traditional software developers are familiar with BPMN.   For clinical software, melding CWFA with use cases seems like a great way to create clinical care systems that support clinical processes. 


Understanding clinical work
What do clinicians do when interacting with patients?  How should results management work optimally?  Answering these questions requires studying real-world clinical care.   Of course, researchers study clinical systems all the time, but rarely as a collection of processes.  CWFA offers a means of intimately studying clinical care and modeling it in a way that can be shared and analyzed. 

BPMN and YAWL are visual languages that can be used to create executable models.  Workflows can also be expressed as graphs, allowing for the use of mathematics to understand clinical care processes.  Human factors experts have studied clinical care using techniques such as cognitive task analysis, but they do not take the next step of building mathematical models.   When done at the correct level of detail and with the proper modeling method, CWFA could prove to be a powerful tool for studying clinical care and the outcomes it produces.  Care coordination and collaboration are additional examples of clinical work that might benefit from formal workflow modeling.

Clinical workflow analysis can be used to create robust models of clinical care that can be used for everything from software selection to planning for a new service or designing clinical care software.  Given its utility, CWFA receives much less attention than it deserves.  I hope this series has helped to demonstrate that clinical workflow analysis really is more useful than you thought!