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:
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
A very simple vocabulary that will support the rules is as follows:
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
The project folder might look something like this:
Figure 2 Project Folder Structure and Rule Sheets
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
Figure 4 Formal Rule Expressions
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.
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
Decisions may be deployed in two ways:
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
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:
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
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.
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.