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

What is FEEL?

FEEL (Friendly Enough Expression Language) is a powerful and flexible standard expression language developed by the OMG® (Object Management Group) as part of the Decision Model and Notation (DMN™) international standard.

Request a demo

Low-code/No-Code/Pro-Code

It is a valuable tool for modeling and managing decision logic in many domains, including healthcare, finance, insurance, and supply chain management. FEEL is designed specifically for decision modeling and execution and to be human-readable to business users, while still maintaining the expressive power needed for complex decision-making. Its simplicity, expressiveness, domain-agnostic functionality, strong typing, extensibility, and standardization make FEEL a valuable tool for representing and executing complex decision logic in a clear and efficient manner. Organizations using FEEL enjoy better collaboration, increased productivity, and more accurate decision-making.

What Are Expression Languages?

FEEL is a low-code expression language, but what is the difference between Expression Languages, Scripting Languages, and Programming Languages. They are all different types of languages used to write code, but they have distinct characteristics and uses.

Expression Languages

Expression languages are primarily designed for data manipulation and configuration purposes. They are focused on evaluating expressions rather than providing full-fledged programming capabilities. Expression languages are normally functional in nature, meaning that at execution the expression will be replaced by the resulting value. What makes them attractive to both citizen developers and professional developers is that they are usually simpler and have a more limited syntax compared to general-purpose programming languages and/or scripting languages. Due to their simplicity, expression languages are often more readable and easier to use for non-programmers or users who don’t have an extensive coding background. FEEL is a standard expression language.

Scripting Languages

Scripting languages provide abstractions and higher-level constructs that make programming using them easier and more concise than programming languages. They are usually interpreted rather than compiled, meaning that the code is executed line-by-line by an interpreter rather than being transformed into machine code before execution. Popular examples of scripting languages are Python, JavaScript, and Ruby.

Programming Languages

Programming languages are general-purpose computer languages designed to express algorithms and instructions to perform a wide range of tasks and create applications. They offer extensive features and capabilities for developing complex algorithms, data structures, and user interfaces. They offer better performance compared to scripting languages due to the possibility of compiling code directly into machine code. Examples of programming languages include C++, Java, and C#.

Is FEEL Like Microsoft Power FX (Excel Formula Language)?

FEEL and Power FX are both expression languages used for data, business rules, and expressions, but in different contexts. Power FX is a low-code programming language based on Excel Formula Language, tailored for Microsoft Power Platform, with some limitations in handling complex decision logic. As soon as the business logic gets a bit tricky, Power FX expressions tend to become highly complex to read and maintain. On the other hand, FEEL is a human-readable decision modeling language, designed for business analysts and domain experts, offering a rich set of features for defining decision logic, including support for data transformations, nested decision structures, and iteration. FEEL provides clear logic and data separation, making it easier to understand and maintain complex decision models.

While Power FX has a visual development environment in the Microsoft Power Platform, FEEL is primarily used within business rules and decision management systems supporting DMN and process orchestration platforms. FEEL is a language standard across multiple BPM and decision management platforms, providing interoperability, while Power FX is tightly integrated with Microsoft Power Platform services. For further comparison, Bruce Silver’s articles FEEL versus Excel Formulas and Translating Excel Examples into DMN Logic.

FEEL Benefits for Technical people and for Business people.

Technical Benefits of FEEL

Decision focus language

FEEL is designed specifically for decision modeling and business rules. It provides a rich set of built-in functions and operators that are tailored for common decision-making tasks. This decision focus nature makes FEEL highly expressive and efficient for modeling complex business logic.

Expressiveness

FEEL supports common mathematical operations, string manipulation, date and time functions, temporal logic and more. This expressiveness enables the representation of complex decision rules in a concise and intuitive manner.

Decision Table Support

FEEL has native support for decision tables, which are a popular technique for representing decision logic. Decision tables provide a tabular representation of rules and outcomes, making it easy to understand and maintain complex decision logic.

Strong typing and type inference

FEEL is a strongly typed language, which means it enforces strict type checking. This feature helps prevent common programming errors by ensuring that values and operations are compatible.

Boxed Expression Support for FEEL

Boxed expressions allow FEEL expressions and statements to be structured visually including:

  • If, then, else statements
  • For, in, return statements
  • List membership statements
  • … and more.

These visual constructs, along with autocomplete make creating, reading, and understanding complex expressions easy to model and debug.

Flexibility and modularity

FEEL supports modular rule definitions and reusable expressions, promoting code reuse and maintainability. It allows the creation of decision models and rule sets that can be easily extended, modified, and updated as business requirements change. This flexibility ensures agility in decision-making processes.

Testing and Debugging

FEEL expressions can be tested and debugged independently of the larger application or system. This enables users to validate and verify decision logic before deployment, ensuring accuracy and reliability. FEEL also provides error handling and exception mechanisms that help identify and resolve issues in decision models.

Execution efficiency

FEEL expressions are designed to be executed efficiently, providing fast and scalable performance. FEEL engines often use optimized evaluation algorithms and data structures to ensure high-speed execution of decision logic, even for complex rule sets.

Integration FEEL

can be easily integrated with other programming languages and platforms. Many decision management systems and business rules engines provide support for executing FEEL expressions alongside other code or as part of a larger application. This enables seamless integration of decision logic via services into existing IT architectures and workflows.

Extensibility

FEEL can be extended with domain-specific functions and operators to cater to specific industries or business domains. These extensions can be defined to encapsulate common calculations, business rules, or industry-specific logic, enabling greater reusability and modularity.

Interoperability

FEEL also enables the sharing and reuse of decision models across different organizations and applications.

Business Benefits of FEEL

Standardization and Vendor-neutrality

FEEL is a standardized language within the OMG DMN standard, which means it has a well-defined specification and is supported by various software tools and platforms. Standardization ensures interoperability, as FEEL expressions can be used across different DMN-compliant systems without compatibility issues. FEEL is designed to be portable across different platforms and implementations.

Business-Friendly

FEEL focuses on capturing business rules and decision logic in a way that is intuitive and natural for business users. This allows subject matter experts and domain specialists to directly participate in the decision modeling process, reducing the dependency on IT teams and accelerating the development cycle.

Simplicity and Readability

FEEL has a syntax that is easy to read and understand – even for non-technical users like subject matter experts and citizen developers. It uses natural language constructs including spaces in names and common mathematical notation. This simplicity enhances collaboration between technical and non-technical stakeholders, facilitating the development of effective decision models.

Ease of Use

FEEL is supported by various decision management tools and platforms. These tools provide visual modeling capabilities, debugging, testing, and other features that enhance productivity and ease of use. The availability of modeling and automation tooling support simplifies the adoption and usage of FEEL.

Decision Traceability

FEEL expressions support the capture of decision traceability, allowing users to track and document the underlying logic behind decision-making processes. This traceability enhances transparency and auditability, making it easier to understand and justify the decisions made within an organization.

Decision Automation

FEEL has well-defined semantics that support the execution of decision models. It allows the evaluation of expressions and decision tables, enabling the automated execution of decision logic. This executable semantics ensures that the decision models defined in FEEL can be deployed and executed in a runtime environment with other programs and systems.

Compliance and Governance

FEEL supports the definition of decision logic in a structured and auditable manner. This helps businesses ensure compliance with regulatory requirements and internal policies. FEEL’s ability to express decision rules transparently allows organizations to track and document decision-making processes, facilitating regulatory audits and internal governance practices. FEEL includes several features specifically tailored for decision modeling and rule evaluation. It supports concepts like ranges, intervals, and temporal reasoning, allowing for precise specification of conditions and constraints. These domain-specific features make FEEL particularly suitable for industries where decision-making based on rules and constraints is critical, such as healthcare, finance, insurance, and compliance.

Decision Analytics

FEEL provides the foundation for decision analytics and reporting. By expressing decision logic in FEEL, organizations can capture data and insights related to decision-making processes. This data can be leveraged for analysis, optimization, and continuous improvement of decision models. FEEL’s expressive capabilities allow for the integration of decision analytics tools and techniques, enabling businesses to gain deeper insights into their decision-making processes.

Trisotech FEEL Support

Most comprehensive FEEL implementation

Trisotech provides the industry’s most comprehensive modeling and automation tools for DMN including support for the full syntax, grammar, and functions of the FEEL expression language. To learn more about basic types, logical operators, arithmetic operators, intervals, statements, extraction and filters supported by Trisotech see the FEEL Poster.

FEEL Boxed Expressions

Boxed Expressions are visual depictions of the decisions’ logic. Trisotech’s visual editor makes the creation of Boxed Expressions and FEEL expressions easy and accessible to non-programmers and professional programmers alike.

FEEL Functions

FEEL’s entire set of built-in functions are documented and menu selectable in the editor. The visual editor also offers supports for the Trisotech-provided custom FEEL functions including functions for Automation, Finance, Healthcare, and other categories.

Autocompletion

The Trisotech FEEL autocompletion feature proposes variable and function names including qualified names as you type when editing expressions thus saving time and improving accuracy.

FEEL as a Universal Expression Language

Trisotech has also expanded the availability of the international standard FEEL expression language to its Workflow (BPMN) and Case Management (CMMN) visual modelers. For example, FEEL expressions can be used for providing Gateway logic in BPMN and If Part Condition expressions on sentries in CMMN.

FEEL Validation and Debugging

Trisotech provides validation for FEEL and real-time full-featured debugging capabilities. To learn more about testing and debugging read the blog Trisotech Debuggers.

Additional Presentations and Blogs

You can also watch a presentation by Denis Gagne on using FEEL as a standards-based low-code development tool and read a blog by Bruce Silver about how using FEEL in DMN along with BPMN™ is the key to standards-based Low-Code Business Automation.

OMG®, BPMN™ (Business Process Model and Notation™), DMN™ (Decision Model and Notation™), CMMN™, (Case Management Model and Notation™), FIBO®, and BPM+ Health™ are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

Trisotech

the
Pioneer

View all

BPM+ Virtual Coffee
5 min Intro to CMMN

A short introduction to the Case Management Model and Notation (CMMN)

Presented by

Denis Gagne, CEO & CTO at Trisotech

Good day and welcome to our BPM+ virtual coffee. I am Denis Gagne CEO and CTO of Trisotech, and this is a five-minute introduction to CMMN.

Some of the motivations or characteristics behind Case Management, as opposed to process management, was that we wanted to deal with business processes where the sequence of activities is not well defined. Contexts in which activities may happen in all kinds of different orders and we must deal with these evolving circumstances. We also wanted to make sure that the evolution of the Case depended on decisions made by the Knowledge Worker. The Knowledge Worker is front and center to the notion of Case Management. It is all about managing a particular context, which is the Case. To support the performance of the Knowledge Worker required that we had a great deal of flexibility due to the dynamic nature of the work. You can think of it as your input box being your Case File, a manifold where different data comes into it, and you must react to this new information and progress with the work needed by the Case. This requires a lot of adaptability to the information context where this context of information is really the Case File. We also wanted to leave to the Knowledge Worker complete control over what to do next, for him to figure out what’s the next best action. But we also wanted to provide some scaffolding to the Knowledge Worker by also providing ideas of what could be done next. These ideas of what co be done next is where the Case Plan Model comes into play.

CMMN stands for the Case Management Model of Notation, and it is an open standard produced by OMG. The spec is available at the URL here. I invite you to go and consult this specification document.

Fundamentally CMMN is about managing a context to achieve a desired outcome where the context is a Case File. A Case in CMMN consists of a Case File and a Case Plan Model. The Case Plan Model is there to help the Knowledge Worker to figure out what possible next action would be ideal in the current context, but the activities to be carried out are really decided by the Knowledge Worker. This provides a lot of flexibility where everything is decided at runtime rather than pre-defined at design time as in the case of BPMN.

CMMN is as easy as one-two-three because CMMN uses an Event-Condition-Action (ECA) semantic. This means basically that when a particular Event happens, if a condition is met, then a possible an action is available. CMMN offers all the variations of ECA. We can have Event-Condition-action or just Condition-Action or just Action. You therefore have the full flexibility of defining the needed activities.

Now looking at the CMMN notation, the folder shape depicts your context. This gives you the information context of the Case File in which you are working. We then have different symbols to capture the notions of Event, Condition and Actions. Events can be actual Event Listeners, like for example Timer Events or User Events but it can also be Case File Events. For example, a new Case File Item being provided into the Case File, or a particular information item is updated, or a document is done or updated. We use these events as triggers, and we verify whether a particular condition is met. An Entry Criterion will be a condition for entering into this element and an Exit Criterion will be the Criterion for terminating the work. We then have our actions. In this ECA depicted here we have a Timer Event trigger, so when this Event happens, if the Condition is met then I can do this Task. We also have the notion of Discretionary Tasks. The Planning Table is a way to turn on and off, and controlling, which Discretionary Tasks are available. A Planning Table at the top of the folder is managing basically the floating Discretionary Tasks within the Case context and a Planning Table on a Task is managing the Discretionary Tasks that are attached to this particular Task. We then have that when the Event happens, if the Condition is met, while I am in this Task, there are other Discretionary Tasks that I can take on. Then we have the notion of Stages, where you can structure your Plan Items and mostly helping you to create some kind of the life cycle for accomplishing the desired outcome of the Case. We also have the notion of Milestones and different triggers.

So, this is a very quick and broad review of CMMN. There is book on CMMN that I highly recommend you read. It is the CMMN Method and Style from Bruce Silver. You can go and read that book. It will give you an intro to CMMN and provide you with some Style and Method on how to do a good CMMN models.

That was our five-minute introduction to CMMN.

View the slides

Videos

Recorded webinars

View all videos
Attend a live webinar

Sandy Kemsley's Vlog - Design tips for combining BPMN, CMMN and DMN models
Sandy Kemsley
Vlog

Design tips for combining BPMN, CMMN and DMN models

By Sandy Kemsley

Video Time: 5 Minutes

Hi, I’m Sandy Kemsley of column2.com. I’m here today for the Trisotech blog with some practical design tips for when you’re combining process and decision models.

let’s start with the big three modeling standards for processes and decisions. There’s BPMN for structured processes, CMMN for case management and DMN for decisions. The standards tell you how to combine the models and you can look at graphical versions like Trisotech Triple Crown infographic to see how this works. Basically, process models and case models can call each other, and then either of them can call a decision model. Now what the standards don’t show is why you would use a particular model type to model different parts of your operations? Now, this might seem like a really silly question. If you have a process, you model it using BPMN, if you have a case structure, you use CMMN and if you have a decision you use DMN. But the real world is not that simple. In any sort of business, operation, any sort of complex business operation, you’re going to have a combination of process, case, and decision logic. And you need to be able to use more than one model type together. Now when you start doing modeling, you’ll find that process people and rules people come at these business models from different directions: if you’re a process person, like me, then you’ll tend to start with a BPMN or a CMMN model and that’s going to show the overall flow, and then you’re going to add in decision tasks where you need to call out to more complex decision models and then build the DMN models that are called from there. Now, on the other hand, a rule specialist will start by modeling the key decisions in the business operation and then they’re going to add processes to tie those decisions together.

Watch this short video for more…

Follow Sandy on her personal blog Column 2.

Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ blog

View all

Sandy Kemsley's Blog - Case Management Work Patterns
Sandy Kemsley
Blog

Case Management Work Patterns

By Sandy Kemsley

Read Time: 6 Minutes

My last post on process, rules and content has me thinking about the style of application where they all come together: case management. Not about when or whether to use the Case Management Model and Notation (CMMN) versus the Business Process Model and Notation (BPMN) versus the Decision Model and Notation (DMN), which I covered in a post on this “triple crown” of modeling standards, but the business requirements for different styles of processes including case management.

For business analysts, the distinction between work patterns is important, since different patterns lend themselves to different types of user interfaces, use cases, systems and levels of automation. And yes, they need to be modeled differently, possibly using different modeling notations, but first it’s necessary to identify the work patterns in order to classify them. There are some types of work that are so unpredictable that it’s difficult to model them at all, but let’s stick with the broad array of work that can be modeled in some way: we know a bit about the goals of the work, or the steps required to achieve the goals, or the information that is being used, or the rules that must be followed along the way.

At one end of the spectrum is transactional workflow, where most of the process is known: the order of the steps, the rules that dictate when things move from one step to another, and the step that defines when the process has been completed. These processes are often codified in BPM systems or line-of-business systems, and are partially or even fully automated.

At the other end of the spectrum is case management: a work style for goal-oriented scenarios that don’t have a predefined method of resolution. This is commonly used for problem resolution, but is also for work that doesn’t have a defined order of steps, such as claims management or legal cases. A case may be initiated directly by someone – a customer, or an internal worker – as a standalone piece of work, or a case may be triggered by a transactional workflow to handle an exception or resolve a problem before returning to the predefined process.

As more and more routine tasks within transactional processes become fully automated, more workers are engaged in doing knowledge work within case management. The goals and metrics for this type of work are very different from transactional processes: since cases are often related to resolving problems, case management metrics such as customer satisfaction can be a key competitive differentiator. Case management workers need a much richer informational context in order to do their job, and very different tools than workers engaged in routine tasks within transaction processes.

In my practice, I often help organizations to understand the different work patterns within their operational areas. They may not even recognize some of these as definable work patterns, just “the way that we do it.” Let’s look at identifying case management work patterns:

I use the following diagram to visualize all the components that may involved in case management:

What do the three characteristics of case management that I list above mean for the business architects and analysts involved in defining and implementing these processes?

First of all, these are goal-oriented processes, and the metrics need to reflect that. For example, the success of a case isn’t tied to how fast it is completed, or how few resources were consumed, although those may be secondary metrics: it’s primarily about whether the issue was resolved satisfactorily. That might be a customer satisfaction measurement, or a legal or regulatory measure, depending on the goal of the case. Business analysts need to identify the goals for each type of case, and ensure that those are the metrics that are being captured. If more traditional process metrics are used, you could end up with cases being resolved very quickly but a lot of unhappy customers or lost sales.

Second, these are content-rich processes, and there must be robust content management as well as the type of content governance that I discussed in my previous post. Since many different types of people may participate in completing a case, you need to be sure that people are seeing all of the content that they need to do their work, but not parts of the case folder that they should not have access to.

Lastly, these are knowledge processes that require people to look at information and make decisions. That means that they need a rich informational context in order to make the right decisions: the right content from the case folder at the right time, but also information from other systems, organized in a fashion that requires a minimum amount of searching. Currently, a lot of case management work is performed with an ad hoc assortment of methods and applications – including spreadsheets, email and external applications – often without support from IT-supported systems; this makes it difficult for the case workers to be sure that they are looking at the right information to support the decision that they’re making.

Once you’ve identified work that looks like case management based on these characteristics – even if it has some predefined processes tucked into part of it – you’re ready to start into the detailed analysis. This is where you will likely use CMMN (and possibly BPMN and DMN) to model how the cases will work, but don’t lose sight of the human side of case management: making decisions in a content-rich environment to reach a specified goal.

Follow Sandy on her personal blog Column 2.

Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ blog

View all

What is CMMN?

Case Management Model and Notation™ (CMMN™) is an international standard modeling language and graphical notation for case management.

What is case management?
Case management is used for capturing and automating work methods and information to handle unstructured and adhoc processes requiring activities that may be performed in an unpredictable order in response to evolving situations. The CMMN notation combined with an automation engine provides a low-code worldwide standard solution for managing cases in diverse business settings. While using CMMN is easy enough for business people to understand and depict case handling procedures, it is also expressive enough to allow CMMN models to become software process components that can be automated. CMMN has an easy-to-use flowchart-like graphical notation that is independent of any specific implementation environment.

OMG Logo

The CMMN standard is published and supported by OMG, an international, open membership, not-for-profit technology standards consortium.

Learn More

BPMN™ (Business Process Model and Notation), DMN™ (Decision Model and Notation™), and CMMN notation are all OMG visual modeling standards that can each be used independently yet were designed to be complementary. BPMN workflows can be embedded directly as process tasks in CMMN models and CMMN can also invoke DMN models to automate business decisions and create or change case file item values.

The CMMN standard utilizes visual models which are standardized, verifiable, and where the model can serve as both the documentation and as the executable source for case management automation engines. A CMMN case can be automated directly from the visual model into case management engines without any translation from IT. CMMN diagrams can be programmatically validated and can be created and maintained by subject matter experts (SMEs) and IT professionals thus eliminating business-to-technical specification handoff issues and errors.

When comparing structured processes versus unstructured processes, we are in fact describing the difference between BPMN and CMMN. Unlike BPMN process management models, adaptive processes are unstructured, so CMMN does not use sequential control flows to describe case activities. A case contains a Case File that holds Case File Items (the case data and information) and is described by a Case Plan, the CMMN model. In CMMN, a model (diagram) could have multiple cases with each case described by a Case Plan. CMMN Case Plan models use a descriptive event-condition-action (ECA) paradigm. That is, when an event occurs, if the condition(s) for the task are fulfilled, the task action is carried out.

The Case Plan is visually captured as a collection of activities (Tasks) that may occur in an unpredictable order where events or workers determine how the case work progresses. Due to how cases are typically managed, not all work that happens during a case is actually modeled in the Case Plan. For example, the interaction of case workers with the Case Plan and Case File Items may not be modeled or be only partially modeled. Typically, how the Case File Items actually get into the Case Plan isn’t modeled. Case data can be added, removed, modified or simply viewed by the case workers at any time during the processing of a case without the need for these data interaction to be modeled specifically.

Adaptive case management uses documents and contextual information to determine the flow of the case at runtime reacting to events and directed by knowledge workers. To facilitate this dynamic case management, the Case Plan can also contain discretionary items modeled to be used only when the case worker decides they are appropriate and needed. Additionally, manually activated Tasks and Stages in a case may have all the conditions met for execution but still will only be executed if the case worker chooses to do so.

A Case File Item can represent information of any kind, both unstructured or structured, and from simple items to complex data structures. Typically, Case File Items represent documents, because organizations usually interact via documents like PDFs and word processor documents, spreadsheets, presentations, images, videos, and other recordings. Usually, these are kept in common file types that are supported by most operating systems and browsers (think PDF, PowerPoint, Word, .png, .jpeg, .gif, .MP3, etc.) The ability to view, add, change, or delete data (Case File Items) from a case at any time while the case instance is active is a main feature of CMMN and causes many of the events that trigger actions like additional Tasks becoming active (the ECA paradigm.)

CMMN gives case workers access to all the relevant case information associated with a case and gives them empowering control to decide how a case evolves while still providing a reusable organizational frame of reference via a non-proprietary international standard modeling notation.

Who Uses CMMN?

Since CMMN is a non-proprietary and software vendor neutral language, it lends itself to solutions in every type of organization. A CMMN Case Plan can provide a reusable organizational frame of reference for resolving cases in a wide range of business situations. CMMN examples include, government services, loan applications, insurance claims, customer complaints, and patient cases in healthcare. CMMN is also being used to manage legal cases, investigate fraudulent activities, administer social programs and other non-profit case activities like charities. CMMN models are also used for specific problem solving that requires human decision making in addition to automation such as automobile roadside assistance, financial planning, compliance tracking, facilities management, and contract management.

Because CMMN supports defining case diagrams at different levels of abstraction, it can be used in different ways to meet varying organizational needs. CMMN can be used to create only a graphical depiction that visualizes and documents case activities. Adding more details to models enable their use as the source code of an automation engine to create case applications. Using the Trisotech case management system, models can be created by non-IT personnel and enriched for execution by subject matter experts, power users, or IT.

According to OMG, Quote Applications of Case management include licensing and permitting in government, application and claim processing in insurance, patient care and medical diagnosis in healthcare, mortgage processing in banking, problem resolution in call centers, sales and operations planning, invoice discrepancy handling, maintenance and repair of machines and equipment, and engineering of made-to-order products.Unquote

Not many tool vendors fully support the CMMN standard, known as “Complete Conformance.” For example, most tools do not support the full compliance infrastructure required to automate cases or interact with BPMN and DMN.

Case Management Model and Notation in Financial Services

CMMN in Financial Services

In addition to an ever-increasing demand for mobile and online banking services, financial services organizations including retail and commercial banking, insurance, mortgage, investments, etc. need to constantly re-engineer existing business processes.

More info on Finance

Process agility and continuous improvement are required to stay competitive so nearly every financial services business uses various forms of process automation. More and more of these organizations are turning to case management to improve activities where human decision making must often supplement or replace procedural workflows. This is especially true with customer-facing activities where a customer-centric human touch adds value. Using CMMN modeling software and automation engine, one can document, track, and orchestrate the activities of administrators, users, systems, and customers while allowing human judgement to control the pace and path of interactions.

Standards play a big part in the financial services world. Using an international standard like CMMN is supported through multiple CMMN modeling tools and makes finding modeling and automation workers easier as the talent pool of trained and certified staff is globally available.

CMMN is being used to document and automate the management of hundreds of financial case types including:

Case Management Model and Notation in Healthcare Services

CMMN in Healthcare

On the adoption of CMMN (as well as BPMN and DMN) as a standard at Mayo Clinic from the press release for Field Guide to Shareable Clinical Pathways:

More info on Healthcare

Quote
Mayo Clinic is committed to managing clinical knowledge as a strategic asset. The use of OMG process standards plays an important role in faithfully representing and sharing clinical knowledge to enable the rapid dissemination and adoption of best practices.
Unquote

Healthcare is one of the fastest-growing sectors in the world economy and many healthcare organizations are undergoing one or more digital transformation initiatives. As part of these transformations, there is an increased need for technology innovation and increased reliance on evidence-based medicine. Healthcare automation needs have become so critical and pervasive that to address these concerns head-on, a community of practice, BPM+ Health, has been created. BPM+ Health was established based on the use of open standards-based notations including CMMN (case management) and other open IT standards which allows for all types of health organizations, professional societies, and vendors to document their care pathways, cases, and workflows, so they are sharable, discoverable, and automatable. By applying standard CMMN to healthcare practice patterns, the information becomes computer-consumable and automatable, giving doctors and clinicians evidence-based information at the point of care.

According to members of BPM+ Health and the OMG Healthcare Domain Task Force who publish the Field Guide to Shareable Clinical Pathways, Quote Certain clinical pathways and activities can be prescribed (deterministic) at design time – during the process of designing the model, such as making a doctor’s appointment for the flu – but other processes are more ad hoc and non-deterministic. These ad hoc processes may be due to sudden and unexpected events that occur in the real world or due to known events that are unpredictable in their timing. Often the environment requires care providers to adapt to unexpected, emerging and/or changing environmental conditions (e.g., no fetal heartbeat is observed during a regular prenatal care exam). As such, the traditional method of representing clinical pathways using BPMN is difficult at best. An agile ad hoc environment cannot be easily represented with BPMN and requires an adaptive “case management” style of representation. This is the role of CMMN: specifying clinical responses to ad hoc events based on the state of the particular case. CMMN allows real-time response to the unfolding of sudden and unforeseen events in the form of flexible choices/selection of activities as the care provider determines necessary.Unquote

Today, most healthcare organizations use textual descriptions, diagrams, and flow charts to document clinical processes. CMMN is a proven international standard and as part of many transformation efforts, CMMN is being used to create automatable graphical representations of healthcare cases and clinical pathways. CMMN case diagrams are visual, unambiguous, intuitive, and easily understood by both providers and IT professionals thus making them superior to text documents.

Well designed and documented CMMN case models are also easy to maintain which is important in healthcare where constantly changing regulations, rapid advances in medications and treatment, and frequently changing policies all contribute to high-volume and constant maintenance.

According to Wikipedia, The American Case Management Association (ACMA), a non-profit professional membership organization supporting the practice of hospital case management through education, networking, publications, bench-marking, and research describes a hospital Case Manager’s responsibilities to include the following functions:

  • Advocacy & Education – ensuring the patient has an advocate for needed services and any needed education.
  • Clinical Care Coordination/Facilitation – coordinating multiple aspects of care to ensure the patient progresses.
  • Continuity/Transition Management – transitioning of the patient to the appropriate level of care needed.
  • Utilization/Financial Management – managing resource utilization and reimbursement for services.
  • Performance & Outcomes Management – monitoring, and if needed, intervening to achieve desired goals and outcomes for both the patient and the hospital.
  • Psychosocial Management – assessing and addressing psychosocial needs including individual, familial, environmental, etc.
  • Research & Practice Development – Identifying practice improvements and using evidence-based data to influence needed practice changes.

CMMN can be used to create healthcare-case models and automation in hundreds of ways. Here are some representative CMMN examples:

Trisotech and CMMN

Digital Enterprise Suite

Trisotech is a world leader in business automation solutions and an active contributor to the CMMN standard. Trisotech’s Case Modeler is known as the reference implementation for CMMN modeling tools and supports all CMMN symbols (shapes) ,a.k.a. “Complete Conformance.” Trisotech also supports and integrates the BPMN and DMN standards into its Case Modeler and in the Trisotech Case Management Automation Engine for automating CMMN models.

CMMN model creation, administration, and management as well as automation, library management, administration, configuration, debugging, simulation, and audit logging are all visual and browser based and can be hosted in public or private clouds – making Trisotech’s offering a complete case management and automation solution.

Trisotech provides free case management tools through self-service trial subscriptions and Visio templates.

Trisotech
CMMN in Financial Services

Trisotech also provides CMMN extended modeling support in the form of drag-and-drop “Accelerators” for the MISMO™ and FIBO® (Financial Industry Business Ontology®) standard data structures that can be assigned as Case File Items in CMMN case models. Trisotech financial clients include governments, insurance organizations, mortgage finance organizations, loan originators, retail and commercial banks, stock trading exchanges, credit card organizations, real estate brokers, investment brokerage houses and more.

Trisotech
CMMN in Healthcare

Trisotech is a founding member of BPM+ Health which promotes usage of CMMN, as well as BPMN and DMN, as an integral standards technology. Trisotech healthcare clientele include international and U.S. acute care hospitals, healthcare insurance organizations, HMOs, renowned teaching hospitals, PPOs, and healthcare professional organizations.

The Trisotech extends the Case Modeler (CMMN) with healthcare-specific additions. Through a combination of features and functions, healthcare organizations can now access FHIR® data structures and APQC Health Care Provider tasks, in their modeling and automation of CMMN cases. Predefined FHIR Data types (simple, complex, and special purpose) are provided as reusable drag and drop data structures that can be assigned as Case File Items in CMMN case models and APQC Health Care Provider tasks from the APQC Health Care Provider accelerator can be used as tasks in CMMN models.

1,000
free pre-built evidence-based workflow and decision models

As part of its Healthcare Feature Set (HFS), Trisotech also provides nearly 1,000 free pre-built evidence-based workflow and decision models including care pathways, clinical guidelines, and healthcare calculators in the BPM+ Health standard (CMMN, BPMN and DMN). These models are human-readable, machine automatable, and embeddable in most medical encounter systems. Healthcare organizations can use these models, created under the direction of Trisotech CMIO John Svirbely, MD, as they are, or quickly and easily modify them to fit the exact nature of their organization’s policies and procedures. Healthcare organizations can also create their case models from scratch with the easily understood CMMN visual modeler that can be shared by practitioners, IT, SMEs, and business people.

Trisotech
Case Modeler Differentiators

Trisotech’s adaptive case management software is a CMMN-based business automation architecture built upon SaaS cloud technologies including API-first design which allows for the invocation of cases from practically any programming language in mobile, cloud, and on-premise server environments. These automated CMMN case models are scalable high-performance services. The automated case (Case Management) services and case automation engine are also structured to provide full support for today’s complex availability needs including containerization and docker technologies. The Trisotech CMMN offering, including modeling and automation, is completely browser based and can be run in any modern browser environment including Chrome, Edge, Safari, Firefox, etc. Automation servers can be hosted by Trisotech, or Clients including on-premise and public/private clouds like AWS, Azure, Google, etc. Advanced configurations allow for 24 X 7 operation, concurrent geographic dispersion and failover, and containerization operating environments.

The Trisotech Case Modeler offers many features other CMMN modelers do not. These include:

OMG®, BPMN™, (Business Process Model and Notation™), Decision Model and Notation™, (DMN™), CMMN™, (Case Management Model and Notation™), BPM+ Health™, and FIBO®, (Financial Industry Business Ontology®) are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries. MISMO™ is a registered trademark of Mortgage Industry Standards Maintenance Organization, Inc.

Trisotech is an active contributor to the CMMN standard.

Trisotech Case Modeler and Automation are known as the reference implementations for CMMN.

Ask for a free Trial
CMMN logo
Resources

Related to CMMN

Trisotech

the
Pioneer

View all

Get started with BPMN, CMMN, and DMN in Visio *

Use the Trisotech Free Visio templates to create visual representations of your operations using the BPMN, CMMN, and DMN notations.

Download Free Templates
Templates

To get you started, these templates include stencils containing all shapes and markers of these three standard notations. You can then utilize all the familiar features of Visio to apply variants and styles to customize your drawings. Simply use these templates to get you started on your journey to become acquainted with the triple crown of process improvement standards.

* Requires that you have a version of Visio.

The triple crown of process improvement standards

The Business Process Model and Notation (BPMN) , the Case Management Model and Notation (CMMN) and the Decision Model Notation (DMN) are powerful and expressive standards published by the Object Management Group (OMG) . This triple crown of process improvement standards offers universally recognized graphical notations in support of organizations seeking efficiency and effectiveness of their operations.

Triple Crown
Digital Enterprise Suite icon

Go beyond just a Visio drawing

Creating Visio drawings describing your operations is a great first step toward Digital Transformation. To fully leverage your existing Visio drawings and take them to the next level, you can import them in the Trisotech’s Digital Enterprise Suite to instantly obtain these benefits:

Start a Free Trial
Trisotech

the
Altruist

View all

Sandy Kemsley's Blog - Understanding the Why, not just the How, of the BPMN-CMMN-DMN Triple Crown
Sandy Kemsley
Blog

Understanding the “Why”, not just the “How”, of the BPMN-CMMN-DMN Triple Crown

By Sandy Kemsley

Read Time: 8 Minutes

Last week was the annual DecisionCAMP conference, where mostly-technical decision management (DM) aficionados gather to talk about the technology, standards and application of DM.

I attended in person last year, but this year was all virtual, and I helped to organize the conference platform using Zoom for live presentations, YouTube for rebroadcast (you can see replays of the presentations there), and Slack for discussion. Although not a replacement for an in-person event, we did manage to capture some of the camaraderie and interactive conversations that would have happened if we had all been in the same room. We even had an after-conference Zoom cocktail hour on the last day!

The great thing about DecisionCAMP is that it’s really a grass roots labour of love by the DM Community site, rather than a for-profit or vendor-sponsored conference. Vendor presenters are requested not to plug their products, so the presentations are a combination of university research, updates and usage of the DMN (Decision Model and Notation) standard, and case studies of practical applications. For a process-centric practitioner/analyst like me, there are always interesting presentations exploring the overlap between decisions and processes. The most noticeable example of this was in a presentation on the “triple crown” of business modeling standards, namely, the Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN) and DMN.

In my post on designing for agility, I mentioned that agility often depends on the design decisions such as the split between process and decision logic – what do you model in as a decision, and what do you model as a process – and went into some detail on when to consider splitting out decision logic from a process. Unsurprisingly, many DM practitioners don’t think first about processes, but suggest that you first focus on determining and modeling your business decisions, then build processes to gather the information and execute the steps required to make those decisions. Within those decisions, however, they often use rule flows, which are really processes that link together individual rules/decisions into larger decisions; this starts to muddy the waters in terms of designing decisions and processes, and may spread your processes over two different model types. To this we add case management (CM), which also provides some process and decision modeling, but may also link to DM and BPM models. Three model types based on three standards: this is the triple crown of process improvement standards.

Triple Crown
Download Infographic

The standards show how to combine the models: use a decision task in a BPMN or CMMN model to call a DMN model; use a case task in a BPMN model to call a CMMN model; or use a process task in a CMMN model to call a BPMN model. What the standards don’t show is why to combine the models, that is, what parts of the business to model using which standard. Technical proponents of the standards talk about applying the three standards to the “core management practices”, as if businesses were aligned along managing processes, cases and decisions, rather than their actual business capabilities and functionality. From a business operations standpoint, processes, cases and decisions are “implementation details”, not management practices.

There are some general guidelines for combining the standards, such as using CMMN for less structured knowledge work and BPMN for more structured processes, and DMN with either of those for repeatable business decisions. If you have ad hoc processes and decisions, that’s most likely to be modeled completely in CMMN, while repeatable processes with repeatable decisions would combine BPMN and DMN. However, many business scenarios aren’t that clear-cut, and contain a combination of ad hoc and repeatable processes, as well as ad hoc and repeatable decisions.

This presents two challenges.

First, business analysts who are tasked with documenting and analyzing business operations not only need to understand how the business works, but also need to decide how to map different parts of the business operation to the appropriate model type. In the absence of guidance on how to do this, business analysts will tend to use the model type and tool with which they are most familiar, and will tend to create a single model rather than multiple model types. This is how we end up with cases and decisions modeled as incomprehensible BPMN models, or processes being modeled as (non-standard) rule flows combined directly with DMN decisions within a DM tool. The solution to this is straightforward, although not necessarily easy: better training, mentoring and support of business analysts on the use of all three standards together. This is why I advocate a combined business automation center of excellence rather than centres for each skill or product: there needs to be a source of knowledge on how to appropriately combine model types (standards) and related technologies when analyzing business operations and making recommendations for improvements. This should include training on the three standards and how they relate to each other, but also specific use cases and examples of why to use one model type over another for a given scenario. For example, a CMMN model may manage the stages of an overall operation, with BPMN models used to drill into specific functional areas, and DMN models invoked from BPMN for repeatable decisions. Or a BPMN model may manage an end-to-end process, and call CMMN models for exception handling or other knowledge work activities.

The second challenge is that of model understandability by the broader business audience within an organization. The triple crown modeling standards are intended to bridge between business and IT by providing graphical representations of business operations that can be understood by business people while being directly executable for automation purposes; although often used by business analysts and developers, in their simpler forms they can be used as documentation and communication of the business operations to everyone from executives to front-line workers. This type of simplified communication is much more difficult when you have multiple interlinked models with three distinct model types. The viewers need to be able to understand enough BPMN to make sense of a process model, including the fact that “case task” symbol means they need to drill into a CMMN case model for that activity; then, they need to understand enough CMMN to make sense of the linked case model. Same goes for linking from a BPMN or CMMN model to DMN via a decision task, or linking from a CMMN model to a BPMN model. If the viewers don’t understand all three model types and how they interlink (much less why to interlink them at any particular point), the models become less useful as a broader communication tool. The solution to this second challenge is much less straightforward. It’s difficult to mandate or even motivate training on these standards for an entire organization: for business analysts, it’s an integral part of their job, but for everyone else, it’s just another thing that they have to learn but may not see the value. The best solution may be for business analysts within an organization, in conjunction with the business automation center of excellence, to create a simplified template for the three model types that they can use for communication purposes. Not perfect, but don’t let perfect be the enemy of good (enough).

Watch Trisotech’s Presentation at DecicionCAMP 2020

Watch now
Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ blog

View all

Bruce Silver's Blog - CMMN Method and Style - Part 2
Bruce Silver
Blog

CMMN Method and Style – Part 2

By Bruce Silver

Read Time: 8 Minutes

Last month I provided a brief overview of the Case Management Model and Notation (CMMN) standard.

As it does for BPMN, Method and Style provides CMMN with additional diagrammatic conventions aimed at making the logic understandable from the printed diagrams alone. These conventions are formulated as “style rules” that can be applied as validation in a CMMN tool, such as Trisotech Case Modeler.  As described in that post, CMMN’s event-condition-action (ECA) style defines through declarative logic flexible patterns of case behavior that can be fully automated on a CMMN engine.  The problem for most modelers is that the detailed logic depends on case variables and conditional expressions that are typically delegated to programmers and in any case do not appear in the case diagram.  Method and Style conventions make them visible.

In CMMN’s ECA style, the triggering event is a lifecycle state transition of a task or stage (e.g., start, complete, exit), milestone (e.g., occur), or file item (e.g., create, update).  The condition is a Boolean expression of case variables (file items).  The action is enablement or termination of a plan item.  In the diagram, enablement is signified by a white diamond shape, called a sentry, on the boundary of the triggered plan item.  The sentry is connected to the triggering item by a dash-dot connector called an ON-part link, labeled with the triggering event, such as complete.  In similar manner, termination is signified by a black sentry.  The condition is called the sentry’s IF-part, an expression of case variables (file items).  The rules of the spec do not describe how the condition – if there is one – is made visible in the diagram, but Method and Style provides a way.  The ON-part determines when the action occurs; the IF-part determines whether it occurs.

For example, in the diagram below, task b is enabled when task a is complete.  Here there is no IF-part, i.e., the condition is true by default.

BPMN Method and Style has the concept of an activity end state, meaning how did the activity end, successfully or in some exception state?  The end state names, typically Adjective or Noun-Adjective, are the labels of the gates on an XOR gateway following the activity.

For example, the BPMN diagram above means that task a has end states “OK”, leading to task b, and “Exception”, leading to task c.  CMMN Method and Style borrows this idea, with the task end state indicated by the sentry label of an entry condition triggered by the complete event of another plan item.

Here, CMMN task a again has end states “OK”, leading to task b, and “Exception”, leading to task c.  In CMMN Method and Style, the end state of a task is captured in an implicit variable [taskname].end, and here the sentry label represents the entry condition’s IF-part expression, a Boolean.  When the ON-part link – the dash-dot connector – from the triggering plan item is labeled with the complete event, the sentry label is visual shorthand for the full IF-part expression,

[triggering task].end = [sentry label]

The expression syntax depends on the expression language employed.  The syntax I use is FEEL, which is the default in the Trisotech tools.

A milestone is a plan item signifying an achieved state of a stage in the case.  Like task end states, milestones are used in Method and Style to signify the end state of a stage, determining what happens next (or what is possible to happen next).  Unlike task end states, which are exclusive, more than one milestone in a stage may be achieved.  In Method and Style, global variable Milestones contains the list of all case milestones that have been achieved, in the format [stagename].[milestone name].  Similarly to the example above, when completion of a stage determines what happens next, a sentry labeled with the name of a milestone in the triggering stage is visual shorthand for the FEEL IF-part expression,

list contains(Milestones, [stagename].[milestone name])

Let’s take a look at a few of the style rules.  From the above examples you see that labels play a key role.  In the spec, executable CMMN references elements by ids, which are not visible, and pays little attention to labels, which are.  Many style rules require labels on CMMN elements and ascribe particular meaning to them, as we saw above with sentry labels signifying the IF-part condition.  The label of a plan item signifies its name, which must be unique in its context.  For example, style rule 0010 checks for this:

In the diagram on the left, the stage and its enclosed task have the same name, Registration.  This is a style error.  The diagram on the right is correct.

In the spec, dotted line connectors called associations are optional annotations with no operational semantics, but Method and Style may require them, in order to make the case logic visible from the diagram.  For example, the trigger of a timer event listener (similar to a timer intermediate event in BPMN) has no official representation in the diagram, so Method and Style uses a directional association labeled with an event of the triggering item.  Without this connector, the trigger is assumed to be activation of the containing stage.  If the connector is present, style rules require the event label:

The diagram above means that Registration Stage is terminated automatically (black sentry) if it is not completed within 7 days of the actual start of task Registration.  The association labeled manual start defines the trigger of the timer.  The timer label defines its duration.  The diagram on the left is missing the event label, and thus is a style error.  If the timer event listener is missing its duration label, that is also a style error.

Other style rules resolve inconsistencies in the CMMN spec.  Style rule 0100, for example, prohibits ON-link connectors from crossing stage boundaries.  In one part of the spec, it says such links are not allowed; in another part it says they are allowed, and in the wild you often see them.  But such links do not work when a stage is rendered collapsed, and a basic principle is that the semantics should not depend on an element’s graphical rendering.  In Method and Style such links are not allowed.  The top diagram below is thus a style error; the bottom diagram is correct.

The diagram above also illustrates how milestones are used as stage end states.  Task Acceptance is enabled when Registration Stage completes in the end state “Registration OK”.  The sentry label is visual shorthand for the FEEL IF-part expression

list contains(Milestones, "Registration Stage.Registration OK")

And note also that the milestone Registration OK is activated when the task Registration completes in the task end state “OK”.

Still other style rules guard against infinite loops.  The hashtag symbol indicates a plan item is Repeatable,  meaning when it completes a new instance becomes Available immediately if its Repetition Rule is true.  Like IF-part expressions, Repetition Rules are Boolean expressions of case variables (file items) that are normally invisible in the diagram.  Method and Style requires a text annotation to reveal the Repetition Rule; otherwise the rule is assumed to be true by default.  Thus if a Repeatable task or stage is not manually activated, has no entry condition, and does not have a text annotation indicating a Repetition Rule, the new Available instance will become Active as soon as the previous one completes, an infinite loop that prevents completion of its containing stage.

In the left diagram above, task Registration is an infinite loop, a style error.  In the center diagram, Registration is ok, since it is manually activated, and task Acceptance is ok as well, since it has an entry condition.  In the right diagram, Registration is ok as well, since it has a Repetition Rule that prevents an infinite loop.

A final style rule example is intended to eliminate deadlocks caused by zombie states, when a stage is completed manually before its expected end state milestones are set.  The rule says that if a stage has multiple milestones tested by the IF-parts of complete links, it should contain a single Required milestone triggered by all those milestones, in order to ensure proper stage completion.  A stage may not be manually completed unless all of its Required elements are Completed.  The example below illustrates:

In the top diagram, Registration Stage has two milestones tested by complete links, and one leading to exit.  Since no plan items are Required, it is possible for a case worker to manually declare Registration Stage complete without achieving any of the milestones, and in that case there is no next step available.  Style rules flag this with a warning.  The bottom diagram is correct.  Here achieving either milestone New registration or Existing registration sets the Required milestone Registration completed.  The stage may not complete unless the Required milestone is achieved, preventing the zombie state.

If all of this looks wildly unfamiliar, that’s because it is!  But help is on the way.  My book CMMN Method and Style explains it all at length, and it is available on Amazon.  You can play around with CMMN by starting a free trial.

Read part 1

Blog Articles

Bruce Silver

View all

All Blog Articles

Read our experts’ blog

View all

Bruce Silver's Blog - CMMN Method and Style - Part 1
Bruce Silver
blog

CMMN Method and Style – Part 1

By Bruce Silver

Read Time: 10 Minutes

Case Management Model and Notation (CMMN) is the poor stepchild of process modeling standards.  It was developed a decade ago, around the same time as BPMN 2.0 and largely as a reaction to it by vendors who believed that “real” business processes were about knowledge workers interpreting documents, not web services orchestration following rigid rules.

In case management, the order of actions typically cannot be precisely defined at design time, and many different things happen concurrently.  The list of available actions changes with the state of the case, and initiation of those actions is typically the result of manual case worker decisions.  Such a different process paradigm demands a different standard.

There is some merit to that thinking, but in the meantime just a few tools have adopted CMMN.  Part of the problem was self-inflicted.  Unlike BPMN, which sought to emulate the familiar look of swimlane flowcharts, CMMN went for a decidedly unfamiliar look.  Unless stakeholders make a modest effort to learn the language, the meaning of a CMMN diagram is utterly lost on them.  Adding to the difficulty is the fact that case logic defined in the model is declarative, not procedural.  That means that each case task and stage (phase) independently defines the conditions under which it is available to start or complete.  That gives the case logic flexibility lacking in BPMN, but at the expense of intuitive visual communication.

I decided to take on this challenge with a new book, CMMN Method and Style, that attempts to make case management diagrams more comprehensible and the standard more widely adopted.  This post provides a very brief introduction.

CMMN Basics

In a CMMN diagram, or case plan, actions are represented by tasks (rounded rectangles).  The head-and-shoulders icon means a human task; other task types invoke a BPMN process, a DMN decision, or a CMMN subcase.  Tasks are contained in stages (rectangles with clipped corners).  The oval shapes are milestones, a type of event signifying some state of the case has been achieved.  Tasks, stages, and milestones collectively are called plan items.  Symbols at the bottom of a plan item indicate additional attributes.  The triangular Play symbol indicates the plan item is manually started.  The hashtag symbol indicates it is repeatable.  The exclamation point indicates it is required, meaning it must be completed in order for its containing stage to complete.

Tasks and stages evolve through a sequence of lifecycle states: Available, Enabled (if manually started), Active, Completed or Terminated.  A task or stage becomes Available when its containing stage becomes Active.  (The case plan as a whole – the tabbed folder shape – is considered the outermost stage of the case.)  Each lifecycle state transition generates a standard event that can trigger advancement of the case logic.  Diamond shapes called sentries on the boundary of a task or stage represent entry or exit conditions triggered by a standard event and further controlled by a Boolean expression of case data.  Once it is Available, a manually started task or stage becomes Enabled when its entry condition is satisfied, and then becomes Active when manually started by a case worker.  If not manually started, it becomes Active as soon as the entry condition is satisfied.  A stage may be marked Completed as long as none of its contained plan items are Active and all of them marked required are either Completed or Terminated.

Case data and documents, collectively called the case file, are available to all plan items at any time.  Like plan items, each case file item also progresses through a series of lifecycle states, and those state transitions likewise generate standard events that can trigger plan item entry and exit conditions.  Each file item is assigned a datatype.  In Trisotech, these are modeled as FEEL item definitions as they are in DMN and BPMN models.

All of that is from the CMMN spec.  Method and Style is my own methodology layered on top, aimed at making the logic as clear as possible from the printed case diagram.  It uses milestones and sentry labels – which appear in the diagrams – to signify the end states of stages and tasks, without requiring modelers to explicitly define case variables for them.

Case Modeling Styles

When creating case models in CMMN, there is no single “best” style for representing the logic.  Some modelers may consider progression of the case to be entirely based on the judgment of case workers rather than events and rules specified at design time.  What happens in what order is not revealed by the diagram, even though this permits illogical ordering of tasks.  The case worker is simply assumed to know the correct thing to do next.

Others may take the opposite point of view, describing most case logic explicitly using event-condition-action (ECA) via lifecycle events and sentries.  While intrinsically more flexible than BPMN, CMMN models in this style are similar in that they try to reveal all possibilities of “what happens next” through the diagram.

Scenario: Write a Report

To illustrate, let’s look at the similarities and differences when applied to a very simple case model, writing a report.  Here is the scenario:

  1. The report may or may not require research. If it does, tasks include researching the topic and organizing references.
  2. Preparing the draft is always required. It includes writing the text, also always required, and generating the table of contents.  If the report contains graphics, additional tasks include creating the graphics, integrating them with the text, and generating a list of figures.
  3. Periodically the draft in progress is reviewed. Tasks include seeking comments, discussing possible changes, and verifying spelling and grammar.
  4. When ready, the draft is submitted for approval. The case completes successfully when the report is approved.  It is also possible that the Approver cancels the report.

User-Driven Style

In the purest user-driven style, all choices of what to do when are made by case workers at runtime using their judgment about what needs to happen, as illustrated below.

The stage Do Research is discretionary (dashed border), meaning it occurs in some instances and not in others, as determined by an applicability rule defined in the planning table indicated by the small grid on the case boundary and described in Method and Style using a text annotation on the stage.  If research is required, this stage transitions to Enabled when directed via the applicability rule, awaiting manual start by a case worker.  When it starts (becomes Active), its tasks Research Topic and Organize References become Enabled, awaiting manual start.  As drawn here, whether this stage ends in Completed or Terminated does not affect case completion.

Since it has no entry condition, the stage Prepare Draft is Enabled as soon as the case becomes Active.  Since it is marked Required, the case cannot complete until this stage is Completed or Terminated, and the stage cannot complete until its Required task Write Text is Completed or Terminated.  Other than that, the order in which its contained plan items are performed is determined entirely by the case worker.

The contained stage Add Graphics is discretionary, as it applies only to reports that contain graphics.  Again, the applicability rule is defined in a planning table, here on the containing stage Prepare Draft, and visualized in the diagram by a text annotation on the discretionary stage.  If the applicability rule is true, Add Graphics is Enabled when Prepare Draft becomes Active and must be manually started by a case worker.  Its tasks include Create Graphics, Integrate Graphics, and Generate List of Figures.

Prepare Draft also includes the task Generate ToC, which could be considered “optional” since it is not marked Required.  In practice there is little difference between such an optional task and a non-Required discretionary task.

The case also contains the task Approve report.  It is not enclosed in a stage, meaning it becomes Enabled as soon as the case is Active.  Presumably it would not be started until a draft of the report was complete or nearly so, but this is not required by the case plan model.

The milestone Report Approved is marked Required, meaning the case can end in the Completed state only if this milestone is set manually by a case worker.  Alternatively, a case worker in the role Approver may terminate the case at any time, depicted as a user event listener triggering an exit sentry.

In the diagram above, all the stages and many tasks are marked Repeatable.  Since no entry conditions are specified, that means that after being marked Completed or Terminated a plan item immediately becomes Enabled again.  The effect of Repeatable here is simply protection against a case worker mistakenly completing or terminating a task or stage.  Technically, this creates a new instance of the plan item, as CMMN has no way to “reopen” a completed or terminated plan item, but we assume the artifacts created by the original instance are available as file items to the new instance.

ECA Style

The ECA style, in contrast, represents the allowed order of plan items explicitly as much as possible using lifecycle transitions and sentries.  It allows for a great deal more automated behavior than does the user-driven style, but at the same time may be more difficult for stakeholders on the business side to understand.

The same scenario is illustrated in ECA style in the figure below.  Here the order of case actions is explicit.  Because it is the plan item’s complete event that usually triggers what happens next, this case could probably be modeled more simply and clearly as a BPMN process.  Let’s take a closer look.

When the case first starts, the only plan item enabled is Plan Report, as all the others have entry conditions.  Plan Report creates the file item Plan, indicated by the page symbol with a dotted arrow from the task.  The dotted arrow in the spec is an association, just a diagram annotation, but in Method and Style we say a task that creates or modifies a file item should display this connector. File items are represented in the case diagram when their values or events are used in the case plan logic.  We need something like this to say that Do Research and Create Graphics are only performed under certain conditions.

When Plan Report is Completed, its complete event triggers the sentry on Prepare Draft, making that stage Enabled.  Every entry condition has two components: zero or more ON-parts, dash-dot links to a plan item or file item, labeled with a standard event, signifying when entry occurs; and an IF-part, a Boolean expression of file item values, signifying whether entry occurs.  In Method and Style, the IF-part condition is represented by the label of the diamond shape.  No label means the IF-part condition is satisfied by default.  Here there is no label, so Prepare Draft becomes Enabled when Plan Report completes.  Once Prepare Draft is manually started, it becomes Active and all its contained plan items become Available.

The contained stage Do Research has an entry condition with no ON-part, meaning its IF-part condition is evaluated as soon as its containing stage Prepare Draft becomes Active. Here the IF-part references the Research required component of the file item PlanDo Research is Enabled only if Plan.Research required is true.  Similarly, the task Create Graphics is Enabled only if Plan.Graphics required is true.  Note that the entry condition for Integrate Graphics has two ON-parts, meaning both Write Text and Create Graphics must first be completed.

If Create Graphics is not performed, then Integrate Graphics and Generate List of Figures are not performed, either.  The task Generate ToC has two entry conditions, meaning it is Enabled either when Write Text is Completed and there are no graphics, or when Integrate Graphics is Completed.

None of the plan items of Prepare Draft are Required, meaning the stage may be declared Completed whenever none of its plan items are Active.  This triggers the stage Review draft, which contains tasks Obtain comments, Discuss changes, and Correct Grammar and Spelling, performed in parallel.

A basic concept of BPMN Method and Style is the end state of a process or subprocess, indicated by the end event reached and signifying how did it end, successfully or in some exception state.  CMMN Method and Style uses a similar idea for stages, with milestones playing the role of end events.  Here Review draft has two manually set end state milestones, either Draft complete or Revision required.  Technically a milestone is an event, but Method and Style assumes each milestone in the Completed state is listed in an implicit Milestones file item that can be tested by sentry IF-part expressions.  If the stage ends with Draft complete set, Approve report is triggered.  If it ends with Revision required set, it goes back to Prepare draft.  In order to prevent a “zombie state” in which the stage is manually declared Completed without setting either milestone, we also need to add the Required milestone Review Complete, which depends on setting one of those two end states.

In Method and Style, tasks also have end states, captured in the implicit file item [taskname].endApprove report has task end states “Approved” and “Not approved”, which are tested by sentry IF-parts to trigger either the milestone Report approved or the milestone Changes required.  These milestones act as end states of the case as a whole, although the case can end in the Completed state only when Report approved is set.  Changes required goes back to Review draft and then likely back to Prepare draft for revision.

As in the user-driven model, an Approver also can exit the case at any time.

*                                   *                                 *

Where the User-driven style requires less explanation, the logic of what happens under what conditions is not contained in the model.  It’s entirely inside the heads of the case workers at runtime.  The ECA style makes that logic explicit, but the declarative modeling paradigm takes some getting used to.  In many case models, both styles are used, with User-driven in some stages and ECA in others.  Method and Style adds some extras that put needed logic details in the diagram, where they can be seen by stakeholders other than those who created the model.

As you might expect, there are style rules as well, with style rule validation built into the Trisotech software. 

Read part 2

Blog Articles

Bruce Silver

View all

All Blog Articles

Read our experts’ blog

View all

How a Swiss government uses Case Management and CMMN to keep track of parliamentary interventions

Abstract

The processing of parliamentary interventions in a Swiss state (canton) involves many different parties: Parliamentary Services, Government, Ministries, Commissions, etc. In this jurisdiction, it is lawfully required that the government responds to each intervention within precise delays. Additionally, the government must publish an overview of the progress of answering and executing all interventions on a regular basis.

With multiple actors, varying delays and numerous ongoing instances, the government needed a flexible solution to communicate and deliver services to the citizens.

On these bases, the state administration initiated a project to implement a system for keeping track of parliamentary interventions, from their tabling to their classification by parliament after execution. To be able to communicate the courses of action easily and graphically, it was decided to use a model-driven approach. Not only should the models be understandable by all stakeholders, technical or not, but they also needed to be directly implemented on the state administration’s process engine.

At first sight, the processes might have looked like typical linear processes with several parties involved that can be modeled and implemented using BPMN. When diving into the details, it however became clear that it was a better approach to view the intervention as an object (case file) transitioning from one state to another through the occurrence of events or actions triggered by the different process participants, which corresponds to the CMMN view of a process.

In this webinar, we will demonstrate:

  • How CMMN allows to focus on the activities that the different parties involved can perform on an intervention, depending on its current state;
  • How each of the activities can be analyzed in the context of the current state of the intervention without having to take into account the rest of the process;
  • Why CMMN fits an agile software development approach; and
  • How CMMN can provide the workflow logic behind user-facing software applications.

  • Serge Schiltz
    Serge Schiltz, CEO and founder of processCentric GmbH is the founder of processCentric GmbH, a firm that provides expertise in the field of business process and rules management based in Switzerland and working all over Europe. He has delivered business process analysis, decision management and software development projects for over 25 years. Dr. Schiltz is also an author, university lecturer and instructor in project management, business analysis and BPM. He as published several articles and books in English, German and French.
    Jean-François Gonguet
    Jean-François Gonguet, Senior Solution Architect at adesso Schweiz AG At adesso, Jean-François is in charge of developing partnerships for business process management, containerization and cloud-ready applications with various technology providers. Before that, he spent 28 years at IBM as technical pre-sales architect and has been involved in different projects around BPM and integration for large customers.
    Jean-Christophe Crettenand
    Jean-Christophe Crettenand, Head of Information System, Canton of Valais Government Controlling For fifteen years, Jean-Christophe devoted himself as a PowerBuilder and PL/SQL specialist in the development of an IT solution allowing the management of the State by performance mandate. In 2012, during his master’s degree in Information Systems Management, he discovered BPMN and project management. Since then, he is coordinating inter-agency projects, including ViaParl: “Keeping tracks of parliamentary interventions”.
    Videos

    Recorded webinars

    View all videos
    Attend a live webinar

    Integrating DMN FEEL to BPMN and CMMN

    As presented by:

    Denis Gagné at Decision Camp 2017

    Content

    Presentation

    View all

    Field Guide to Shareable Clinical Pathways Using BPMN, CMMN & DMN in Healthcare

    Recorded on May 23, 2018
    Abstract

    Clinical practice guidelines are systematically developed statements based upon prevailing evidence to assist health practitioner’s in their decisioning making concerning the appropriate care to be provided for a specific clinical circumstance. A guideline is meant to offer concise instructions on how to provide healthcare services. The most important benefits of clinical practice guidelines are their potential to improve both the quality care and patient outcomes, and reduce costs. However, these guidelines are developped and communicated in prose, which often lacks the required specificity to clearly and unambiguously convey the clinical knowledge. These ambiguities can lead to the misapplication of intended therapy, causing at best a reduction in the quality of care and reduce costs, at worst causing harm.

    This presentation will demonstrate the use of three OMG standards, Business Process Model and Notation (BPMN), Case Management Model and Notation (CMMN) & Decision Model and Notation (DMN) to represent clinical guidelines. These methods in tandem provide a means to clearly and unambiguously describe and convey the clinical knowledge. The models can be reviewed, tested and computational verified. Further, since there are clear computation semantics for the standards, the models developed based upon these standards are potentially executable. This promotes the rapid dissemination and uptake of the guidelines in a clinical setting.

    The speakers will provide a brief overview of the three methods, supporting HL7 standards and supporting technologies necessary to make the guideline actionable in a clinical setting. A simple clinical model based upon the standards will be reviewed and finally shown executing. The presentation will show the potential of using these methods to model clinical knowledge and their potential of being directly executable.

    Featured Panelists

    Robert Lario, Enterprise Architect at VHA Health Informatics and Co-chair OMG Healthcare Domain Task Force

    Denis Gagné, CEO & CTO at Trisotech and Chair OMG BPMN Model Interchange Working Group

    Videos

    Recorded webinars

    View all videos
    Attend a live webinar

    Trisotech-mwd-advisors-review-2017

    Download PDF Download the complete research report


    FOR IMMEDIATE RELEASE:

    MWD Advisors publishes favorable in-depth review of Trisotech’s Digital Enterprise Suite

    Montreal, Quebec, Canada, September 15, 2017 — Trisotech (http://trisotech.com) a global leader in digital enterprise transformation software solutions, announced today that MDW Advisors, an independent technology and advisory services firm, has analyzed the Digital Enterprise Suite features and produced an in-depth review of the tool.

    The MWD Advisors’ review concludes that Trisotech offers a “comprehensive set of tools and canvases that provide support to a broad range of users, enabling them to capture reusable models of how the business operates.”

    The review puts an emphasis on the Suite’s Decision Management component: Trisotech’s Decision Modeling and Notation (DMN) Modeler. Derek Miers, Principal Analyst at MWD Advisors and author of the review, points out that “we struggle to think of scenarios where organisations with significant operational decision-making requirements would not want to look seriously at the product.”

    “MWD Advisors is a well-respected analyst firm and we are very pleased that they have great things to say about our Decision Management product,” says George Barlow, Chief Sales Officer at Trisotech. “Mr. Miers also makes the point that the Decision Management product, while available as a stand-alone offering, has even greater customer value when paired with other components of our Digital Enterprise Suite such as our Business Process Modeling, Case Management Modeling and Strategic Planning tools. The Decision Management marketplace is very active right now. Organizations of all types want to take advantage of the OMG international standard – Decision Modeling Notation (DMN) – to replace existing disparate rules systems, coalesce on a standard, and remove embedded decision logic from program code thus making it accessible directly by business users.”

    About Trisotech

    Trisotech is a global leader in digital enterprise transformation solutions, offering innovative and easy-to-use software tools that allow customers to visualize, innovate, transform and improve their digital enterprise processes and business decisions. Trisotech customers use The Digital Enterprise Suite to provide new and revolutionary ways for their knowledge workers to collaborate and succeed in an increasingly global, connected and competitive world. Trisotech products are providing digital transformation help to communications, agriculture, manufacturing, financial, healthcare, insurance, energy, distribution, government, and many other types of organizations.

    Trisotech is a privately held company.

    Website: http://trisotech.com

    ###

    For information

    Jonathan L’Ecuyer
    Marketing Manager
    Trisotech
    jlecuyer@Trisotech.com

    514 990-6639 ext. 501

    All registered trademarks are the property of their respective owners.

    See awards earned by Trisotech for its Digital Enterprise Suite

    Press releases

    In the news

    View all

    BPMN – CMMN – DMN Poster

    Content

    Infographics

    View all

    CMMN Poster

    Content

    Infographics

    View all

    Learn how it works

    Request Demo

    Confirm your budget

    Request Pricing

    Discuss your project

    Request Meeting
    Graph