Rule Modeling Case Study

Step 1 - Review and clarify the rule statements

When a patient comes into the emergency department (E.D), the patient information gets captured.

Today we have an ETL that executes every 4 hours and get this captured information into a SQL Server database.  A program then executes that scores the risk factor of these patients based on certain parameters like blood glucose levels etc.  The patient is given a risk score from 1 to 10. Where 1 being patient with least amount of risk and 10 being the high risk.

A care navigator is assigned to a patient. Care navigators can have many patients under them. Using an UI the care navigator can create lists of patients based on their risk factors. A patient can be added or removed from a list based on their risk score.

For patients who are kept on high risk list, a workflow needs to be executed. The workflow steps could be:

  1. Call the patient
  2. Make appointment for the patient
  3. Order  medications and other diabetic testing supplies for the patient

Let’s assume for now that the actual rules as specified by the business users are as follows:

R1: If age > 80 then diabetes risk is High

R2: If HbA1C less than 7% then diabetes risk is Low 

Step 2 - Determine the Data Model and Vocabulary

A very simple vocabulary that will support the rules is as follows:

Step 3 - Determine the Decisions and Sub-Decisions

At the moment we only need one decision. To construct the decision service we drag the sheet on to the rule flow diagram and specify some additional parameters such as the version and effective dates.

Figure 1 Rule Flow Diagram

Step 4 - Identify the rule sheets

The project folder might look something like this:

Figure 2 Project Folder Structure and Rule Sheets 

Step 5 - Copy the relevant rule statements into the appropriate rule sheet

These rule statements might possibly begin their life in a product such as RuleXpress

There are two rules that define whether a patient is high or low risk

Figure 3 Rule Statements

Step 6 - Model the Formal Rule Expression.

Figure 4 Formal Rule Expressions

Step 7 - Verify the Rules

We could try to verify the rules using test data:

Figure 5 Testing the Rules As Specified

We can see that not all the results are what we expected.

Harry was classified as ‘low’ risk when he should have been ‘high’ (because of his age)

Jenny was not classified at all.

If we run the ambiguity checker we will discover the following:

Figure 6 Ambiguity checker finds conflicting rules

We can resolve the ambiguity by making rule 2 more specific. Probably what it should have said was:

R2: If HbA1C less than 7% then diabetes risk is Low (for people 80 or under)

The modified rule sheet now looks like this:

Figure 7 Rule Sheet with ambiguity resolved.

If we run the completeness checker we get:

Figure 8 Completeness Checker finds missing rule

This was the missing case that resulted in Jenny not getting classified.

We can add an appropriate rule statement for this:

R3: if age is 80 or less and HbA1C is not over 7 then diabetes risk is low.

So after fixing this we end up with:

Figure 9 Complete and Consistent Rule Sheet

Which is both complete and consistent.

Step 8 - Add Natural Language Statements

These help make the rules easier to read for those people who are not regular users of Corticon Studio.

Figure 10 Adding Natural Language Statements

Step 9 - Deploy the Decision

Decisions may be deployed in two ways:

  1. As web services
  2. As in-process execution

In this case study we’ll use Web Services Deployment

When the Corticon Execution Environment (Server) is installed (under Tomcat, Websphere, Weblogic etc) you can publish decision services in a number of ways

  1. Publish option in Studio
  2. Use the deployment console
  3. Use the Web Console
  4. Use the deployment APIs from java or .net

For this case study we’ll use the Studio publish option.

A decision service in Corticon is defined by a Rule Flow.

To deploy a rule flow (Decision Service) you can use the publish option:

Figure 11 Publishing from within Studio

The first step is to select the server that you want to deploy to:

Figure 12 Selecting the Server to Publish to

We’ll use localhost. This brings up a list of the decisions that are available for deployment:

Select the one you want. You can rename it if you like.

Figure 13 Choosing the Rule Flow

You should then see the decision listed in the console browser window:

Figure 14 Viewing the Decision in the Web Console

Notice that the execution count and average execution time columns have some values (28 for version 1.1 and 14 for version 2.1)

You can also see some other decisions on the server.

You can inspect the properties of the decision by clicking on its name:

Figure 15 Overview of the Decision Properties

You can use this screen to configure the decision service:

Figure 16 Configuring the Decision Service

You can see we have indicated three attributes to be monitored by the Corticon Server.

Now we are ready to execute this decision.

In a production environment we might write a java program that makes a SOAP call to the rule engine, or we might use a Business Process Engine that can invoke a web service as one of its tasks.

Before we get to that point however, we can test the web service call from within Studio.

This is done in the tester.


To do this we just select the Corticon Server URL (rather than a rule flow or rule sheet inside Studio):

Figure 17 Select the Deployed Decision Service for Testing in Studio

The test subject will change accordingly:

Figure 18 The Decision Service URL

Incidentally this is the URL you would use to call the decision service from other applications (such as Rollbase)

Now we can run the test (say 10 times)

We should get some results back like this:

Figure 19 Test Results

Now if we go back to the Web Console we’ll see that the execution count has been updated:

Figure 20 Execution Statistics

The distribution chart shows how the results were broken down.

If you click on the execution count you will see the monitored attribute charts:

Step 10 - Check in The project

At this point we might want to check in the project to our repository for safe keeping.

Because Corticon’s rule assets are all simple files (XML) any content management system can be used for controlling the assets.

In this case study we’ll use the TEAM plugin from Roundtable Tugboat (A Progress partner) to manage our assets.

This project (not the Diabetes Monitoring project) has already been configured to use TEAM:

Figure 21 Project Structure with Change Decorations

You can see some of the assets are flagged with * (they have been modified since the last checkin) and some of them are flagged with + (they are new). The rest haven’t changed.

The TEAM checkin is performed here:

Figure 22 Checking In a Project

We can record some suitable commentary about the changes we are checking in:

Figure 23 Documenting the Changes

If we go to the history tab we can see the history of changes made to this project (and who made the changes):

Figure 24 The Complete History of Changes

If you select a specific change you can see all of the assets that we modified as part of that change:

Figure 25 Details of a Specific Change

If you select two assets you can compare them:

Figure 26 Comparing Assets

You can also compare two changes:

Figure 27 Comparing Changes

This will bring up a structure compare diagram:

Figure 28 The Change Structure Diagram

Selecting an item will bring up a detailed compare screen:

Figure 29 Comparing Changes

Step 11 - Connect the Rules to an Application

Eventually the rules will be used by a real application. This might be a batch processing job that sends many records to the rules for evaluation or it might be a web based application that handles a single record at a time.

For this case study we’ll examine the use of Rollbase, one of Progress’s Pacific software products that enables the rapid development and deployment of web based applications.

Main Patient List

Detail for one Patient

The risk classification is determined by the decision service we looked at earlier.

Whenever a change is made to the patient information, the decision service is invoked and the display is updated with any new information.