Dr. John Svirbely's blog post - Going from Zero to Success using BPM+ for Healthcare. 
                Part I: Learning Modeling and Notation Tools
Dr. John Svirbely, MD
Blog

Going from Zero to Success using BPM+ for Healthcare.

Part I:
Learning Modeling and Notation Tools

By Dr. John Svirbely, MD

Read Time: 3 Minutes

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.

Blog Articles

John Svirbely

View all

All Blog Articles

Read our experts’ blog

View all

Bruce Silver's blog post - Instance Alignment in BPMN
Bruce Silver
Blog

Instance Alignment in BPMN

By Bruce Silver

Read Time: 3 Minutes

One of the most common mistakes beginners make with BPMN stems from lack of clarity as to what exactly BPMN means by a process. A BPMN process is a defined set of sequences of activities, performed repeatedly in the course of business, starting from some triggering event and leading to some final state. The key word here is “repeatedly”. The same process definition is followed by each instance of the process. Not all instances follow the same sequence of activities, but all follow some sequence allowed by the process definition. That’s not Method and Style, that’s from the spec. The spec just doesn’t say that very clearly.

Each process instance has a defined start and end. The start is the triggering event, a BPMN start event. The end occurs when the instance reaches an end state of the process instance, which in Method and Style is an end event. It helps to have a concrete idea of what the process instance represents, but I have found in my BPMN Method and Style training that most students starting out cannot tell you. Actually it’s very easy: It is the handling of the triggering event, which in Method and Style is one of only three kinds: a Message event, representing an external request; a Timer event, representing a scheduled recurring process; or a None start event, representing manual start by an activity performer in the process, which you could call an internal request. Of these three, Message start is by far the most common. That request message could take the form of a loan application, a vacation request, or an alarm sent by some system. The process instance in that case is then essentially the loan application, the vacation request, or the alarm. In Method and Style, it’s the label of the message flow into the process start event. With a Timer start event, the instance is that particular occurrence of the process, as indicated by the label of the start event.

Here is why knowing what the process instance represents is important. The instance of every activity in the process must have one-to-one correspondence with the process instance! Of course, there are a few exceptions, but failure to understand this fundamental point leads to structural errors in your BPMN model. And those structural errors are commonplace in beginner models, because other corners of the BPM universe don’t apply that constraint to what they call “processes”.

Take, for example, the Process Classification Framework of APQC, a well-known BPM Architecture organization. It is a catalog of processes and process activities commonly found in organizations. But these frequently are not what BPMN would call processes. Even those that qualify as BPMN processes may contain activities that are not performed repeatedly on instances or whose instances are not aligned with the process instance. Here is one called Process Expense Reimbursements, listing five activities.

But notice that two of the five (8.6.2.1 and 8.6.2.5) are not activities aligned one-to-one with the process instance. That is, they are not performed once for each expense report. That means that if we were to model 8.6.2 Process Expense Reimbursements in BPMN, activities 8.6.2.1 and 8.6.2.5 could not be BPMN activities in that BPMN process. So where do they go? They need to be modeled in separate processes… if they can be modeled as BPMN processes at all! Take 8.6.2.1Establish and communicate policies and limits. For simplicity, let’s assume that establishing and communicating have one-to-one correspondence, so they could be part of a single process. How does an instance of that process start? It could be a recurring process – that’s Timer start – performed annually. Or it could be triggered occasionally on demand – Message or None start. The point is that 8.6.2.1 needs to be modeled as a process separate from Process Expense Reimbursements. The result of that process, the policy and limits information, is accessible to Process Expense Reimbursements through shared data, such as a datastore.

Activity 8.6.2.5 Manage personal accounts is not a BPMN activity at all. It cannot be a subprocess, because there is no specified set of activity sequences from start to end. To me it is an instance of a case in CMMN, not an activity in this BPMN process.

All this is simply to point out that instance alignment is a problem specific to BPMN because other parts of BPM do not require it.

Since “business processes” in the real world often involve actions that are not one-to-one aligned with the main BPMN process instance, how do we handle them? We’ve already seen one way: Put the non-aligned activity in a separate process – or possibly case. Communication of data and state between the main process and the external process or case is achieved by a combination of messages and shared data.

Repeating activities are another way to achieve instance alignment.

When instance alignment requires two BPMN processes working in concert, it is often helpful to draw the top level of both processes in the same diagram. This can clarify the relationship between the instances as well as the coordination mechanism, a combination of messages and shared data. You can indicate a one-to-N relationship between instances of Process A and Process B by placing a multi-instance marker on the pool of Process B.

An example of this we use in the BPMN Method and Style training is a hiring process. The instance of the main process is a job opening to be filled. It starts when the job is posted and ends when it is filled or the posting is withdrawn. So it qualifies as a BPMN process. But most of the work is dealing with each individual applicant. You don’t know how many applications you will need to process. You want processing of multiple applicants to overlap in time, but they don’t start simultaneously; each starts when the application is received. So repeating activities don’t work here. One possible solution is shown below.

Here there is one instance of Hiring Process for N instances of Evaluate Candidate, so the latter has the multi-participant marker. Hiring Process starts manually when the job is posted and ends when either the job is filled or the posting expires unfilled after three months. Each instance of Evaluate Candidate starts when the application is received, and there are various ways it could end. It could end right at the start if the job is already filled, since before the instance is routed to any person, the process checks a datastore for the current status of the job opening. It could end after Screen and interview if the candidate is rejected. If an offer is extended, it could end if the candidate rejects the offer, or successfully if the offer is accepted. And there is one more way: Each running instance could be terminated in a Message event subprocess upon receiving notice from Hiring Process that the posting is either filled or canceled. While not perfect, this BPMN model illustrates instance alignment between multiple processes working in concert, including how information is communicated between them via messages and shared data.

There is yet another way to do it… all in a single process! It uses a non-interrupting Message event subprocess, and is an exception to the rule that all process activities must align one=to-one with the process instance. It looks like this:

Now instead of being a separate process, Evaluate Applicant is a Message event subprocess. Each Application message creates a new instance of Evaluate Applicant. You don’t know how many will be received, and they can overlap in time. As before, each instance checks the datastore Job status. Since everything is now in one process, we can no longer use messages to communicate between Evaluate Applicant and the main process. Here we have a second datastore, candidates, updated by Evaluate Applicant and queried by Get shortlist to find newly passed applicants. Instead of an interrupting event subprocess to end the instance, we use a Terminate event after notifying all in-process candidates.

If you are just creating descriptive, i.e., non-executable, BPMN models, you may wonder why instance alignment matters. It certainly can make your models more complicated. But even in descriptive models, in order for the process logic to be clear and complete from the printed diagrams alone – the basic Method and Style principle – the BPMN must be structurally correct. If it is not, the other details of the model cannot be trusted. If you want to get your whole team on board with BPMN Method and Style, check out my training. The course includes 60-day use of Trisotech Workflow Modeler, lots of hands-on exercises, and post-class certification.

Follow Bruce Silver on Method & Style.

Blog Articles

Bruce Silver

View all

All Blog Articles

Read our experts’ blog

View all