Building Clinical Care Software Systems, Part IV: Process Information

Clinical work consists of processes. Supporting clinical work with software requires support for processes. Process support can be passive or active. Paper charts are examples of passive support. Electronic resources may be passive as well. For example, an online textbook is a passive support. Over the course of training and subsequent work experiences, clinical professionals develop ways of performing care processes.* Any electronic system that seeks to actively support care processes must do so in a way that does not interfere with work habits or result in lower productivity or care quality. EHR systems are intended to be active by providing alerts, care guidance, or even simply templates to aid data capture. Determining how to best apply workflow technology to clinical work is a major software design challenge.

Effective utilization of workflow technology requires more than just workflow-capable software. It also requires organizations that are comfortable with process-oriented thinking and software that has configurable workflow capability. Unfortunately, where clinical work processes are concerned, software support for configurable workflows is rare, and most organizations are just beginning to adopt process-oriented thinking. Thus, we are dealing with two problems: 1) how to help organizations move to process-oriented thinking for clinical work, and 2) how to help software designers incorporate process awareness into their products. Let’s look at the current landscape to get a feel for the issues faced by software designers and healthcare organizations when adopting workflow technology.

Lack of standard terms and concepts for clinical processes and workflowsFlow charts and swim lane diagrams are the most commonly used modeling tools for clinical workflows. There is no standard set of terms or concepts that every modeler uses to capture workflows. Thus, workflow models are not easily shared or compared between either modelers or organizations. For example, a registration process consists of a series of tasks and requires data collections and validations. However, there is no standard for what each task or data collection is called. Even clinical work (patient interview, physical exam, obtaining vitals, etc.), which has terminologies such as SNOMED, does not have a standard way of representing these actions when collecting workflow information or creating workflow models.

Lack of standardization keeps knowledge local and impedes the growth of clinical workflow analysis as a discipline. Without standards, every software designer hoping to build clinical systems must roll his or her own models, terms, and concepts. And, of course, working with different organizations means learning the local conventions.

Thankfully, workflow patterns have provided a basic set of standard terms and concepts that can be adapted for clinical work (see Clinical Workflow Analysis Using Workflow Patterns ). Even so, that still leaves much to be done. For example one type of OR-split workflow pattern is the Multi-Choice. Multi-Choice splits allow for decisions where one may choose any combination (or none) of the available selections. The Structured Synchronizing Merge resolves Multi-Choice selections and moves the workflow to the next task. Mapping clinical processes onto these to patterns requires an intimate knowledge of both the clinical process and the pattern, which brings me to the issue of process analyst training.

Training analystsWorkflow patterns are the key to understanding how workflow models become executable algorithms. They are based in mathematics and have been rendered in colored Petri nets. Current workflow management tools support the most important patterns, so there is practical value in knowing them. Obviously, if workflow management tools support patterns and patterns can be used to describe clinical work, then patterns are applicable along the entire continuum from analysis to software design. Flowcharts and swim lanes may be fine for discussing and modeling workflows that are intended solely for human consumption; however, when the goal is computerization of workflows, better tools are required. Analyst training must become more rigorous and include mastery of formal workflow concepts and better modeling tools (see YAWL and Clinical Process Modeling).

Patients are not productsUnlike managing an insurance claim, replenishing inventory, or processing a loan application, clinical work must be adapted on the fly to the patient at-hand. Therefore, clinical workflow technology cannot insist on a one-size-fits-all approach. Local conditions must be considered, such as staffing, information needs, patient types, etc. This requires configurable workflows that can be adapted as needed. It also requires an organization with the skills and knowledge present to make the needed adjustments. Software with workflow capability in the hands of someone who does not know how to use it properly could cause more harm than good.

Clinical work consists of both group and individual workflows.
An outpatient visit consists of both group and individual workflows. Group workflows pass work from person-to-person: Registration->vitals->provider exam->lab. The provider exam is an example of an individual workflow. During a patient encounter, the provider will need access to patient information, knowledge resources, and educational materials. How these resources are accessed depends on the patient and the provider’s knowledge and work habits. Group workflows are easier to standardize because hand-off conditions can be set by policies and procedures then reflected in software. However, individual workflows require more flexibility. Workflow analyses and software designs must recognize these two types of workflows.

The process information component
Each of the issues outlined above represents a problem that anyone desiring to effectively use workflow technology must deal with. The clinical systems architecture recognizes that applying workflow technology, whether within an organization or for software design, presents significant challenges. Analysts familiar with workflow patterns and supporting modeling tools must be in charge of gathering process information to manage this component.

In small practices where the number of potential workflows is limited, the knowledge required to analyze and use workflow technology may be commensurately less. Workflow technology may be integrated into clinical care systems in a manner that is transparent to users, but readily accessed–for example, through a configuration utility or similar means. The ability to tweak workflow functions within the system may be all the workflow expertise required for effective use in these settings.

Workflow technology is the key to supporting clinical work. It undergirds both usability and clinical decision support. Active support for clinical work requires workflow technology.

___________________________

* There are myriad definitions for the terms workflow and process. Here, a process is a series of tasks, and a workflow is the specific sequence of tasks (including data and resources) performed to complete a process.