Jerome Carter, MD October 18, 2016

Now that we have looked at traits of poorly-performing processes, we turn to the more difficult problem of defining the properties exhibited by properly-performing processes. Often, what is going wrong is obvious, but fixing problems requires that one knows the underlying cause. Even more important is being able to recognize the best solution that is possible with current resources. Fortunately, there is a large body of work on business processes analysis and design that can be adapted for clinical care.

Specific Start and Termination conditions
Processes should be initiated by a specific event or set of conditions. Processes are created to produce one or more specific outcomes. If the expected outcomes occur, the process is considered successful. Thus, two essential features of any good clinical process are the existence of specific Start and End points. A patient appearing in a waiting room starts a visit. Once the objectives of the visit are accomplished, the visit terminates.

When managing patient communications, messages, emails, or calls may initiate interactions with the practice. However, termination is more difficult to generalize. A communication may result in a new test, prescription, a visit, or even a hospital admission. It is up to the practice to categorize communications and determine acceptable termination points and conditions.

Clear, discrete steps
Every process is comprised of steps that : 1) use/produce information and 2) are performed by someone or something. Good processes have unambiguous steps, well-defined data inputs/outputs, and designated performers. At present, there are no objective standards for determining where one step in a process begins and another ends. However, step boundaries usually become clear on analysis. For example, an incoming call has to be answered, the reason for the call solicited, and the call reason recorded, thus answering a call has three apparent steps. Routing the call would consist of acting on the call reason. One could quibble about these divisions (answering vs. routing) and what to call them; however, the basic steps that might occur are limited.

Includes paths for defaults, exceptions, and errors
Process diagrams show the steps required to complete a process. However, many different pathways may exist from Start to End. The expected (default) path is that which occurs in the vast majority of cases—when things go according to plan. Exceptions may occur for any number of reasons. For example, when a patient calls to speak to his/her physician, normally that call would be placed on the doctor’s to-do list or on a sticky note. If the doctor is on vacation or has left the practice, an exception occurs that must be handled. Exceptions are indicators of the need for alternate paths within a process. Since exceptions can usually be anticipated, good process designs include alternate paths from inception. An error is a condition that prevents the process from moving forward. Forgetting to obtain the full name of a patient who called or losing his/her contact information are occurrences that make it impossible to contact the patient and are examples of errors that disrupt the process.

Within the context of this discussion, errors are conditions that are difficult to anticipate (unlike exceptions), and when they occur, they stop the process. Errors are often random, so managing them requires a way of assuring they are addressed as quickly as possible. Workflow systems can generate warnings and assign someone the responsibility for addressing an error.

Assigned job roles and responsibilities
Whether manual or electronic, good processes have clearly assigned job responsibilities. Clear job duties and responsibilities make it easier to determine where glitches occur and where to make adjustments for improvements. Training new employees is also more productive and effective when roles and responsibilities are clear to all.

Well-defined data requirements
Every task may require or produce data. Missing data are one type of error that can disrupt any process by preventing it from starting or stopping a process already underway. When a task or step fails to produce data as expected, downstream steps may halt. Thus, a key part of analyzing any process workflow is determining the specific data requirements for each task and job role. Ideally, data requirements are integrated within the process diagram (i.e., workflow model). Software development requires the same information. Flow charts and activity diagrams do not provide deep support for mapping data requirements for tasks and steps.

Processes should have clear termination conditions, and often those conditions are conveyed via one or more data elements. For example, a quality measure for a patient calling about a new symptom might be the scheduling of an appointment to address the symptom. The appointment date, time, clinician, and location would then be the data elements required to properly terminate the patient communication process for that specific patient.

Variables for monitoring process state
Since processes consist of multiple tasks/steps and something may go wrong at any time, good clinical processes provide a means of monitoring how things are progressing. Monitoring could take the form of confirmation messages (e.g., appointment scheduled, prescription sent), status messages (e.g., patient has not been contacted, clinician not available) or error messages (e.g., incorrect patient contact number, pharmacy closed).

Process state information allows the practice to spot problems before they have been around long enough to cause serious harm. While one can monitor processes in paper-based practices, it is likely less efficient and more time-consuming for staff to do so. In addition, useful electronic capabilities –logging, communication history, data analytics--are not available.

Knowing the traits of problematic and good processes helps when conducting workflow analyses and when designing new or reengineering old clinical processes. In the next post, we will look at techniques for performing clinical workflow analysis.

Up next: Doing the Clinical workflow analysis—Collecting Information