Part II:
Getting Started

Welcome to the second installment of this three-part series providing an overview of the resources, steps and the success factors required to achieve success with your first clinical guideline automation project using the BPM+ family of open standards on the Trisotech platform. In Part I we discussed how long it will take you to reach cruising speed for creating BPM+ visual models. In Part II, we discuss the critical step of grasping the knowledge presented in the guideline under study and standardizing your approach to deal with the various pitfalls you may encounter in doing so.

A common project for someone starting with BPM+ for Healthcare is the implementation of a clinical guideline (or similar structured knowledge). Guidelines are commonly accepted as an authority and “source of truth”. Guidelines vary in their complexity and no two are exactly alike. To implement a guideline requires a methodical approach. There are no rigid rules on how to do this, but there are best practices that can be followed.

Prep Work

The process of implementing a guideline starts with becoming intimately familiar with its contents and to gather the important source documents. Once the guideline is understood you can then start to dissect it apart. One approach is to identify the decisions that are being made in the guideline and the decision tools being used to achieve them. Once these are identified, then the different task flows are identified, as these will be the basis for process models. It is important during this phase to identify those decisions and processes that are high value to clinicians and outcomes. Identifying processes that follow a common pattern (triage, staging, etc) can help to speed later development.

Problems with Clinical Guidelines

When you start to dissect guidelines, you will often find that most guidelines have problems, some minor and some major. Anything put together by a committee may have hidden biases, and many guidelines have some form of baggage. The fact that two societies can publish conflicting recommendations on the same topic indicates that the process is not perfect.

Most guidelines do a good job of discussing the core topics, but they often become blurry around the edges. For example, a surgical guideline may provide only cursory details on topics like nutritional support or handling of complications. These may seem minor to a casual reader but still need to be handled when modeling the guideline for some automation. As an aside, using BPM+ models to capture and deliver a guideline is a great way to identify problems that otherwise be masked.

Standardizing Your Personal Approach

Since there are many sources of variation, it is important to determine your goals and to standardize your approach to building models. Do you rigidly adhere to the guideline verbatim, or do you allow flexibility? If you favor flexibility, can you demonstrate that the changes do not negatively impact outcomes? Does everyone on the team share the same philosophy, or is everyone doing their own thing with little coordination?

One of the foundations of BPM+ modelling is the use of standards-based languages such as BPMN, DMN and CMMN. If a team is uncoordinated when developing the guideline BPM+ models, then personal variation creeps in. A common problem is the naming and constraining of entities such as data inputs. If two programmers use the same name for data inputs constrained differently, then software will merge them. This can negatively affect any models using these as inputs.

Narrative Elicitation

To analyze and structure information and knowledge from existing evidence-based guidelines, I recommend using the Knowledge Entity Modeler (KEM) to get control on terminology from the start. The KEM can be used to create a central repository of terms, definitions, clinical codes, and rules as presented in the guideline narrative. If properly built, it can capture the core knowledge of the guideline, providing a valuable resource for documenting the models later. It provides a solid foundation and helps to orient people to the information being used. I find that it takes me about a month working for a couple hours a day to build a complete KEM model for a moderately complex topic.

In the next part of this series, we will discuss how to proceed from here to a series of notional models and then on to automation.