Jerome Carter, MD  December 7, 2015

Part Three: What to Analyze and Why
Workflow analysis requires details. Therefore, the goal of every analysis is discovering and documenting the details of the tasks, steps, roles and information that make up a workflow.  Flowcharts and swim-lane diagrams can easily capture tasks, steps, and roles, but information is more complex.  Unfortunately, there is no standard method for collecting or analyzing workflow data.  Even though there are standard notations, such as BPMN or flowcharts, there are no agreed on rules/methods for capturing clinical workflow concepts. Thus, every analyst has his/her own way of capturing workflows. 

 The table below contains the most basic questions that have to be answered for any workflow.   These questions are offered as the beginning of a structured process for conducting clinical workflow analyses.  

What job role is responsible for managing the process? 
What information or resources are required to initiate the process?
What steps occur during the process?
Does each step depend on one or more than one job role?
Are there sub-groups of patients? If so, how do they affect the process?
What information or resources are required to complete the process?

Table 1.  Initial workflow analysis questions 

Assuming a clinical process has been selected for study, each of the above questions should be pursued in the order given.   

When conducting an analysis, it is often difficult to know where to begin.  If the process under study has been around for a while, the policy/procedure manual may provide some idea of how the process should play out.   While the manual and what actually happens on a day-to-day basis may be different, the manual will provide information on why the process exists, what it should accomplish, and who is responsible.  The first two pieces of information can point one towards forms that support the process.  Knowing the job role responsible tells you who to interview.  Once job roles are known, it is time to start gathering process-specific information.

What information or resources are required to initiate the process?
Every process has a beginning and an end.  The first analysis step then is demarcating these two boundaries.  Let’s use Patient Registration, a generic and widely-replicated process, as an example.  When patients enter a facility, they gain access to the services by registering and making it known they are present.  Registration, in this case, begins when the patient appears at the registration desk.  Answering this first question requires that one determine what the patient MUST do in order to successfully register.  Is there a form? What information is absolutely required to prevent being turned away?  What staffing level is required to register at least one person?  Is there a different process or are there different requirements for initial versus subsequent visits?   Once these questions are answered, initiation requirements will be more clear. Next, individual process steps are teased out.

What steps occur during the process?
This is usually the most challenging part of an analysis.   More often than not, if more than one person is responsible for a process, then there will be more than one way of performing the process. If multiple people are involved, save time and headaches by interviewing them as a group.   Group interviews help both interviewers and interviewees because they bring variations that are seldom noticed to everyone’s attention.   

Flowcharts (or some form of boxes and arrows model) are great for visually capturing the control-flow of a process during group interviews. Everyone understands them, and most can create them with limited training.  There is no need to be exact during an initial interview; the goal is capturing a decent process overview. Do be mindful to capture meaningful variations. Variations could be important workarounds that point to unknown process issues. Once all involved cannot find any new steps or variations, version 1.0 of the control-flow is done. 

Does each step depend on one or more than one job role?
The visual control-flow diagram contains the process’ steps.  If multiple roles are involved, the control- flow diagram can be updated to a swim-lane diagram.  The swim-lane can be done by the analyst and reviewed by those involved in the process later.   (Role data can be easily annotated on the CF diagram as it is being created.)   Once the swim-lane is agreed on, specific steps can be analyzed.

For each step, one needs to determine what information is needed or produced by the step.  Here BPMN is better than any other diagramming method I have used except YAWL.  Step-based  information movements, which I refer to as “information metabolism” (see definitions), can be complex, and each analyst has to create his/her own notation scheme.  The ultimate utility of the notation chosen will be determined by the model’s intended use and the amount of detail the notation can handle.  Creating software requirements to build a system is a different problem than determining how to get rid of workarounds.    Information metabolism is possibly the most challenging aspect of a clinical workflow analysis.

Are there sub-groups of patients? If so, how do they affect the process?
Once a control-flow model is available, it can be used to delve deeper into the process.   Variations are a great way to test a model for real-world fidelity.    

Variations may exist because people performing the process inadvertently create them or because they are really needed.  In clinical workflows, patient sub-groups can be an appropriate source of process variation, and looking for proper variations is easier once a model is in hand.   One can proceed by applying the questions discussed in this post for each potential subgroup.  The two most obvious groups are “initial visit” and “subsequent visit.”  Obviously, age or diagnoses could account for subgroups that have different registration requirements as well.  By analyzing how the process affects each group, it might be possible to spot process variations that are helpful and need to be formalized or harmful and need to be eliminated.  

What information or resources are required to complete the process?
When a process terminates, specific, measurable outcomes should be evident.   When Patient Registration terminates, all required information should be present, whether from the patient or third-parties (e.g., approvals).   In addition, someone should be responsible for providing the final "OK" for a completed process. 

In the next article in this series, we will look at how the intended use of a workflow analysis determines the level of detail required and the modeling tool used.