With modeling tools, you can define complex processes such as clinical guidelines. In theory these models can be automated. In practice it may be wise not to automate everything. The decision to automate depends on several factors, such as your goals and the problems that you need to solve. Automation is not without costs, and you need to consider the return on your investment (ROI).

The Decision to Automate

Certain processes or decisions are more attractive to automate than others. To identify these, you may ask some questions:

• Is it “high” value (high frequency, repetitive, something not to be overlooked)?
• Do users view automation of the process as something that would be helpful?
• Does the process or decision have a certain level of stability?
• Does it have reasonable data requirements?

How much data that the models require and how easy it is to obtain are key issues. If the automated process constantly interrupts the user or requires a large amount of data, then it may bring little value to the organization. One solution may be to have standing orders in place that will guarantee that the required data is always collected and available when it is needed.

The Emergency Department is an excellent example of practice setting which can be a challenge to automate. The environment can be chaotic, and some patients require dynamic care that is determined on the fly. Such tasks are a challenge to automate. However, even in the ED there are other processes where automation can relieve staff from drudgery and free them up for patient care.

One issue to consider relates to patient complexity. If most patients are straightforward while only a small subset are clinical challenges, then the complex patients can be triaged to a clinician while the remainder handled by an automated process. This improves overall efficiency and use of manpower.

Microservices

Even if a guideline is not fully automatable, it often contains elements that are. These can be encapsulated in microservices that are triggered when a certain set of conditions are met.

These are attractive since they often need a limited amount of data. They are easier to create and maintain. On the other hand, many of these services may be needed, which can introduce another set of challenges.

Some people checking out process modelling ask the same questions over and over again. “Why can’t I use Visio instead?” “Why do I need to spend more money on software?” These are valid questions – no one wants to spend money these days on something unnecessarily. However, before reaching a decision, you should understand the implications of your choice.

Confusion arises because process modeling software such as the Trisotech Digital Enterprise Suite (DES) and drawing programs such as Visio share similar BPMN shapes. The images in drawing programs are simple and two dimensional. In process modeling each BPMN icon is the tip of an iceberg, overlying a complex infrastructure that allows for a low-code programming environment. So, while they look to be the same, they are as different as night and day.

Two Main Reasons to Model

There are 2 main reasons why people look at process modeling for capturing clinical guidelines. One is to document and describe, to better understand, or to communicate details about a guideline. This reason is referred to as “notional” modeling. The second reason is to automate the guideline.

Notional Models

Simple drawing programs work just fine for simple problems. However, what works well on a simple problem may fail with a more complex one. Implementing a clinical guideline may require orchestration of over 50 separate models and over 250 data inputs. This is a level of complexity that can be challenging to represent, and simple Visio models may not be able to carry this load.

Why does an organization spend extra money to buy process modelling software?

There are several reasons why an organization gets process modeling software. This is a goal-oriented decision to achieve a return on the investment.

First, the organization has complex guideline processes that may have failed previous attempts at quick-and-dirty solutions. Something that looks good on paper may be incomplete when put into practice – the devil is in the details. It is common when drawing an initial guideline process to underestimate the required complexity. This may even pass review by several individuals. When building a guideline process model, it is easier to be sure that the process is complete because you can recognize gaps while building.

Second, the organization needs to make sure that the models are correct. When using a drawing program anything pretty much goes, which can lead to failure. Just because you can draw something does not always mean that it will work. For example, this diagram has multiple BPMN errors that would prevent execution.

case study

Biopharmaceutical

Process Discovery and Modeling Help Create Supply Chain Real-Time Release of Raw Materials Interoperability Standard

The biopharmaceutical industry produces vaccines, gene therapies, and other products that save and improve lives. The manufacturing processes are sophisticated, but with room for improvement.

With both improvement and standardization in mind, the National Institute of Standards and Technology (NIST) funded a project between a leading biopharmaceutical company, OAGi (originally Open Applications Group Inc.), and NIST to create supply chain interoperability resources for improving a key business process – the real-time release of raw materials.

The project participants used Trisotech’s Digital Enterprise Suite to discover and model the process and OAGi’s connectCenter to create profiles of OAGi’s connectSpec standard. The project’s success resulted in OAGi publishing a “Real-Time Release of Raw Materials” connectKit standard that is available on OAGi’s website for any supply chain participant.

If you need to create a large number of clinical models – either for a new project or to replace outdated software – then you are probably (or should be) feeling a bit overwhelmed. Such a project may take thousands of hours of coding, several informaticians, and many resources. Faced with such a daunting task it is no wonder that so many legacy systems persist for decades. However, there are ways to ease the burden and give you some control.

Working Smart

Sometimes people feel an urge to jump into model building right off the bat. This often results in working hard all through the project. Spending some time to plan and prepare can often to prove to be more efficient in the long run.

When building process or decision models, there are several ways to work smarter, such as:

• standardizing as much as possible
• controlling data and terminology proactively
• making use of patterns
• reusing models as much as possible

Standardization

Standardization is something that many people push back on. There are various reasons for this. Sometimes people feel that their domain is unique, and each solution must be individually crafted. While this attitude has some merits, it also increases the work needed to program your solution. The more that you standardize, the fewer the models that you need to develop and maintain, thereby increasing efficiency.

Sometimes you can standardize almost everything, but there are still a few variations between implementation sites that remain. A solution to this problem is to create what Trisotech calls a model “template”, which allows different versions of a model to be tweaked for a specific site, while leaving most of the overall model otherwise unchanged.

Controlling Data and Terminology Proactively

Proactive control of data and terminology may seem insignificant compared to all the other tasks, However, if you do not have control of terminology and data when you start, then later stages of development can become a nightmare with a lot of wasted effort. For example, if you have multiple informaticians, then you will probably have multiple variable names all pointing to the same data object. Each name is interpreted by the software as being unique, and as such each must be linked to your data source. If you have control on your terminology, then you can reduce your data integration challenges by 50% or more.

Making Use of Patterns

When building clinical models, you may notice that the same tasks appear together over and over again. This is termed a pattern.

To illustrate this, let us look at preauthorization, which has 4 main decision tasks:

• identify any contraindications
• confirm indications of use
• establish any disease activity or severity requirements are met
• determine that alternative therapies have been tried and failed

All of these must be cleared before approval is granted. These tasks can be modeled in BPMN as follows:

Several challenges may be encountered when creating process models in healthcare:

• coping with the clinical variability seen in people and their conditions.
• needing to make adjustments for the patient’s real-time status.
• needing to avoid the over-complexity that can arise when trying to handle all possibilities that may be encountered.
• crafting a model that is viewed with trust, comfort and acceptance by providers, patients, and regulators.

All of these challenges can be addressed using attended tasks.

What is an attended task?

An attended task is a task or decision that has an attribute which:

• temporarily stops the execution of the process.
• allows the user to review the task or decision and make changes to inputs or outputs.

The review, changes, and user are recorded, confirming with timestamp that a person has approved the task or decision results.

In a Trisotech BPMN model, an attended task is indicated by the presence of a small check box in the lower left corner, as shown in Figure 1. This example shows a decision task for the diagnosis of anemia based on criteria from the World Health Organization that uses three data inputs (age, sex, and hemoglobin).

case study

Dana-Farber Cancer Institute

Preemptively managing the side effects of cancer treatment through model-driven clinical decision support

Located in Boston and the surrounding communities, Dana-Farber Cancer Institute brings together world renowned clinicians, innovative researchers and dedicated professionals, allies in the common mission of conquering cancer, HIV/AIDS, and related diseases. Combining extremely talented people with the best technologies in a genuinely positive environment, they provide compassionate and comprehensive care to patients of all ages; they conduct research that advances treatment; they educate tomorrow’s physicians and researchers; they reach out to underserved members of their community; and they work with amazing partners, including other Harvard Medical School-affiliated hospitals.

Cancer care is complex. The treatment landscape is constantly changing, and it will soon become impossible for oncology providers to appropriately manage their patients without decision support. To address this need for a new cancer care delivery model, Dana-Farber launched Dana-Farber Pathways in 2012. This multidisciplinary program brought together a dedicated group of clinicians, informaticists, and analysts with the common goal of developing an electronic roadmap for quality cancer care. To date, Dana-Farber has built a portfolio of over 70 clinical pathways, providing treatment recommendations for almost all solid tumor and hematologic malignancies.

Cancer treatment has side effects. Regardless of their diagnosis, all cancer patients have the potential to experience a wide range of symptoms related to therapy or the progression of their disease. Given that the current approach to symptom management is often fragmented and reactive, Dana-Farber Cancer Institute has launched an innovative initiative to preemptively manage the side effects of cancer therapy by leveraging digital technologies. This includes the development of a portfolio of symptom management pathways by Dana-Farber Pathways. By implementing decision support at point of care, Dana-Farber hopes to:

Generative AI is spreading fast and constantly becoming more powerful. Its uses and roles in healthcare are still uncertain. Although it will be disruptive, it is unclear what it will change or what will be replaced as the technology evolves.

The use of Generative AI poses several challenges, at least for now. In some respects, it behaves like a black box. It may be unable to give the sources for what it produces, so it is hard to judge the reliability of its sources. It can be hard to validate depending on how it is used. These factors may make doctors, patients, and regulators nervous about its use in a sensitive area like healthcare. If a claim of malpractice is made involving it, then it may be hard to defend its mysterious behavior.

Generative AI and Business Process Models

A business process model can access Generative AI simply by adding a connector to a task, which is done by a simple drag and drop. Because it is now part of a process, you can control when and how it is called.

Since there may be several possible paths through the model, you can have different calls that are appropriate for each path. Orchestrating the output provides an opportunity to give an individualized solution for a specific situation. Orchestration of Generative AI can make it less of a black box.

Since the calls to Generative AI can be tightly constrained and since you know exactly where it is being used and what the inputs are, the appropriateness of its explanation can be judged in context. This can make validation a bit less daunting.

Illustrative Example

A common problem in healthcare is the need to communicate health information to patients. Not only may the patient and family not understand what the provider is saying, but also the provider may misunderstand the patient. The need to communicate better has created a need for access to human translators around the clock. This raises other problems, as the translator may not understand the nuances of medical terms. It can also be quite expensive since you need to have multiple translators on call.

In Figure 1 there is a portion of a BPMN model for the diagnosis of anemia. A DMN decision model first determines whether a patient has anemia, and, if so, its severity. It may be desirable to inform the patient quickly and easily about these findings. The problem of translation can be approached by taking the outputs of the decision and sending them as inputs to Generative AI (in this case OpenAI, indicated by the icon in the top left corner), along with the patient’s preferred language and education level. The Generative AI then takes these inputs and instructions and generates a letter tailored to the patient.

Welcome to the third installment of this three-part series providing an overview of the resources and steps required to achieve success when automating your first clinical guideline 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 and standardizing your approach to deal with the various pitfalls you may encounter in doing so. Now we will delve more into the details of how to develop an automated guideline. While the Trisotech modeling tools provide low-code programming that is easily comprehended by novices, there are many details “under the hood” that need to be specified to achieve automation.

Stages of Development

The entire process of automating a guideline starts from a written guideline and proceeds through a sequence of stages to the final automated clinical model, as outlined in the following diagram. There is some flexibility in the process; however, it is not recommended to complete a stage without completing preceding one.

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.

Welcome to the first installment of this informative three-part series providing an overview of the resources and the success factors required to develop innovative, interoperable healthcare workflow and decision applications using the BPM+ family of open standards. This series will unravel the complexities and necessities for achieving success with your first clinical guideline automation project. Part I focuses on how long it will take you to reach cruising speed for creating BPM+ visual models.

When starting something new, people often ask some common questions. One is how long will it take to learn the new skills required. This impacts how long it will take to complete a project and therefore costs. Learning something new can also be somewhat painful when we are set in our old ways.

Asking such questions is important, since there is often a disconnect between what is promoted online and the reality. I can give my perspective based on using the Trisotech tools for several years, starting essentially from scratch.

How long does it take to learn?

The simple answer – it depends. A small project can be tackled by a single person quite rapidly. That is how I got started. Major projects using these tools should be approached as team projects rather than something an individual can do. Sure, there are people who can master a wide range of skills, but in general most people are better at some things than others. Focusing on a few things is more productive than trying to do everything. A person can become familiar with the range of tools, but they need to realize that they may only be able to unlock a part of what is needed to automate a clinical guideline.

The roles that need to be filled to automate a clinical guideline with BPM+ include:

1 subject matter expert (SME)

2 medical informaticist

3 visual model builder

4 hospital programmer/system integrator

5 project manager

6 and of course, tester

A team may need to be composed of various people who bring a range of skills and fill various roles. A larger project may need more than one person in some of these roles.

The amount of time needed to bring a subject matter expert (SME) up to speed is relatively short. Most modeling diagrams can be understood and followed after a few days. I personally use a tool called the Knowledge Entity Modeler (KEM) to document domain knowledge; this allows specification of term definitions, clinical coding, concepts maps and rule definitions. The KEM is based on the SVBR standard, but its visual interface makes everything simple to grasp. Other comparable visual tools are available. The time spent is quickly compensated for by greater efficiency in knowledge transfer.

The medical informaticist has a number of essential tasks such as controlling terminology, standardizing data, and assigning code terms. The person must understand the nuances of how clinical data is acquired including FHIR. These services cannot be underestimated since failures here can cause many problems later as the number of models increase or as models from different sources are installed.

The model builder uses the various visual modelling languages (DMN, BPMN, CMMN) according to the processes and decisions specified by the SME. These tools can be learned quickly to some extent, but there are nuances that may take years to master. While some people can teach themselves from books or videos, the benefits of taking a formal course vastly outweigh the cost and time spent. Trsiotech offers eLearning modules that you can learn from at your own pace.

When building models, there is a world of difference between a notional model and one that is automatable. Notional models are good for knowledge capture and transfer. A notional model may look good on paper only to fail when one tries to automate it. The reasons for this will be discussed in Part 3 of this blog series.

The hospital programmer or system integrator is the person who connects the models with the local EHR or FHIR server so that the necessary data is available. Tools based on CDS Hooks or SMART on FHIR can integrate the models into the clinical workflow so that they can be used by clinicians. This person may not need to learn the modeling tools to perform these tasks.

The job of the project manager is primarily standard project management. Some knowledge of the technologies is helpful for understanding the problems that arise. This person’s main task is to orchestrate the entire project so that it keeps focused and on schedule. In addition, the person keeps chief administrators up to date and tries to get adequate resources.

The final player is the tester. Testing prior to release is best done independently of other team members to maintain objectivity. There is potential for liability with any medical software, and these tools are no exception. This person also oversees other quality measures such as bug reports and complaints. Knowing the modeling languages is helpful but understanding how to test software is more important.

My journey

I am a retired pathologist and not a programmer. While having used computers for many years, my career was spent working in community hospitals. When I first encountered the BPM+ standards, it took several months and a lot of prodding before I was convinced to take formal training. I have never regretted that decision and wish that I had taken training sooner.

I started with DMN. On-line training takes about a month. After an additional month I had enough familiarity to become productive. In the following 12 months I was able to generate over 1,000 DMN models while doing many other things. It was not uncommon to generate 4 models in one day.

I learned BPMN next. Training online again took a month. This takes a bit longer to learn because it requires an appreciation of how to design a process so that it executes optimally. Initially a model would take me 2-3 days to complete, but later this dropped to less than a day. Complex models can take longer, especially when multiple people need to be orchestrated and exception handling is introduced.

CMMN, although offering great promise for healthcare, is a tough nut to crack. Training is harder to arrange, and few vendors offer automatable versions. This standard is better saved until the other standards have been mastered.

What are the barriers?

Most of the difficulties that I have encountered have not been related to using the standards. They usually arise from organizational or operational issues. Some common barriers that I have encountered include:

1 lack of clear objectives, or objectives that constantly change.

2 lack of commitment from management, with insufficient resources.

3 unrealistic expectations.

4 rushing into models before adequate preparations are made.

If these can be avoided, then most projects can be completed in a satisfactory manner. How long it takes to implement a clinical guideline will be discussed in the next blog.