In the last article in this series, Clinical Process Management - The Patient in the Age of Processes, the idea of taking a holistic view of clinical processes was introduced as a means of dealing with complexity in clinical care software systems and real-world care delivery. Now it is time to take a closer look at clinical process management (CPM) and how it might work. First, we need a better understanding of clinical processes, what they are, and why they exist.

Clinical care processes may be divided into two broad categories: direct and indirect. Direct care processes are those that occur as a result of patient care activities (e.g., taking a history, writing a prescription, ordering labs, examining a patient). Direct care processes are what clinicians do (i.e., clinical work). Indirect care processes are those that make direct care processes possible (e.g., registration, appointment scheduling, billing) and are often administrative in nature. Information systems intended to support clinical care MUST support both direct and indirect care processes. Of course, this is easier said than done -- patients vary, clinicians vary, locations vary.

Currently, most HIT is data-centric; that is, current systems focus on data capture and re-presentation and are not geared to explicitly support care processes. Building software that can explicitly support clinical processes requires an intimate understanding of what those processes are and what their outcomes should be. Analogous to business process management (BPM), CPM describes the range of activities -- discovery, modeling, analysis, measurement, reengineering— that an organization might use to optimize direct and indirect care processes.

In order to manage clinical processes, one must understand their properties. The most basic property of any process is its expected outcome. The expected outcome of a registration process is a patient who may be seen in a facility. The expected outcome of a physical exam is an understanding of the patient’s current state, and exam findings are recorded in the system. Information is an outcome. Processes have specific starting points, consume information, use resources, and may be conducted by one or more people.

Anyone attempting to create a framework for management of clinical processes will quickly run into a few issues. First, there is no list of standard clinical processes. As such, there is no agreed-on list of expected outcomes, roles, information inputs/outputs, resource consumption, or starting points. Likewise, there is no standard terminology or taxonomy available for clinical processes. Every organization, more or less, creates its own process list. Further, there is no standard modeling notation or analytic approach to guide would-be clinical process managers. Fortunately, much of what has been done in the realm of BPM can be adapted for clinical purposes.

Building on the BPM methods, one can begin doing CPM by identifying important direct and indirect care processes. Here is an outline of a possible approach.

1. Identify current processes
2. Determine if they are necessary (based on expected outcome)
3. If they are necessary, determine if they are safe, effective, and efficient
4. Determine what humans MUST do
5. Determine who (roles) should participate
6. Delineate resources needed
7. Decide how to monitor a process (outcomes, resource use, person-hours, etc.)

The role of clinical workflow analysis
Processes happen one step at a time. (BPM folks would say one activity/task at a time. I find “step” easier to objectively define and quantify, but that is another article.) A workflow is the series of steps along with their flow and control determinants as well as the resources, people, and information consumed and produced. Clinical workflow analysis is the means by which one moves from a high-level view of a process to teasing out exactly what must happen to achieve the desired outcome (see Clinical Workflow Analysis—More Useful than You Thought). Importantly, the greater control one desires over processes, the greater the level of workflow detail that must be captured. Clinical workflows comprise complex interactions between clinical and non-clinical staff, between staff and patients, information movements, and resource usage. When done properly, clinical workflow analysis provides the information needed to determine when processes are working well, when they can be improved, and whether HIT can aid in the improvement.

Clinical process management and HIT
As mentioned earlier, current HIT is comprised mainly of data-centric systems. Data-centric systems are process-oblivious. They have no idea what step a nurse might perform next or what a dietician would find most helpful when interacting with a patient. Of course, one can build some degree of process support (implicit) into a data-centric system, but that in itself is a problem. When process support is hardcoded into a system, changing process behavior requires changing the system, which can, and usually does, require programming). BPM suites (AKA workflow technology: application development tools that allow one to create process-aware applications) can make it much simpler and more cost-effective to provide explicit process support. However, that raises another issue: how to determine when explicit process support is required. There are no hard and fast rules. However, my explorations to-date suggest the following criteria. (These are based on clinical work support needs; I have no idea if they apply to inventory management at a department store.)

Criteria for deciding when a clinical care system should use workflow technology
If a clinical care process has the following traits, then a workflow technology-based application would likely provide better process support than a data-centric system (see Clinical Software Design Principles).

Clinical Care Process Traits

  1. Collaboration/communication intensive (care coordination, PCMH)
  2. Process relies on complex decisions
    1. Many branches/alternate path (diagnostic decision tree)
    2. Many variables for a given decision (treatment plans)
    3. Quantifiable dependencies (time, critical health outcome)
  3. High volume processes with recurring decisions (i.e., results management, drug interactions)

Software support for processes that meet these criteria has to overcome significant software development hurdles. One of the most important hurdles is developing the requirements for process-aware systems. Turning workflow analyses into software requirements is not a straightforward process. The usual modeling tools for clinical workflows -- flowcharts and swimlanes -- are not well-suited to capturing the level of detail required to produce requirements for a robust information system. For that, one needs a notation and modeling language that can be turned into requirements, or in the case of BPMN or YAWL, into a working application.

The focus of workflow analyses also shifts if the goal is software development. For example, a workflow analysis must determine the extent to which any process step is executable using HIT (i.e., steps performed by human vs. non-humans must be explicit). For any step deemed executable, the information required to complete the step must be known as well as any mandatory outputs. Further, the rules for step changes and workflow progression must be exact enough to be encoded in an algorithm.

Clinical care consists of a series of intertwined/interacting processes. The limitations of data-centric systems in terms of decision support, care coordination, and everyday clinical work, such as taking notes or ordering medications (e.g., alert fatigue) has become well-known and documented. Organizations looking to benefit from information technology must try a new way of supporting clinical work and clinical processes. The most promising approach currently available is adapting the many tools available for business process management for clinical settings. For that, a more suitable modeling notation is required. The first candidate, Business Process Model and Notation (BPMN), will be the focus of the next four articles.