The Decision

The decision in this example is to determine a Health Risk Score based on a number of factors:

Figure 1 Health Risk Assessment Factors


The Business Object Model

These are the business objects and the relationships between them that we will need to model in Corticon

The Risk_Factor object corresponds to the 13 factors listed in figure 1

The participant will fill out the Health Risk Asssessment form which will gather Participant data along with the Family_History and Medical_Problems. The rules will then determine which Risk_Factors are present.

Each Risk_Factor will then be analyzed in more detail to determine a risk score.

Finally these Risk_Factors will be ranked  in order of importance

The Vocabulary

The four business objects will be modeled in the Corticon vocabulary like this.

Figure 2 Business Objects

The detailed attributes for each object need to be specified. In this case study these attributes are determined by reading the written specification of the rules (see appendix B)

The Risk Factor Object

Figure 3 The Risk Factor Object

This contains the name of the risk factor, the risk score and some other identifying information.

Risk factor objects will only be created by the rules if the participant meets certain criteria (Appendix B)


The Medical Problem Object

Figure 4 Medical Problem Object

Each medical problem that the participant lists on the HRA form will be represented as on medical problem object  since the participant may have any number of medical conditions (there are at least 1500 ICD9 codes identifying distinct medical conditions – though only a few are used in this application).

The object contains the name of the condition (eg Diabetes, Asthma etc), the status (eg have currently, in the past, etc), the treatment (eg under care, taking medication, none) and the type (eg major, minor).

The type will be determined by the rules.

Family History

Data is also gathered in the HRA about family medical problems.

Figure 5 Family History Object

In this case we have chosen to model this with distinct named attributes in a single family history object. But we could also have modeled it with a repeating object similar to the way we handled the medical problems. In this example we only need yes/no answers to each of the specified conditions so the simple structure will work. But if we needed to know additional information about each condition then a repeating structure would be more flexible.



The participant object is the biggest since it contains the answers to most of the HRA questions:


Figure 6 Participant Object


The relationships between the Participant and the other objects are represented like this in Corticon using the association editor:

Figure 7 Relationships between the Objects

So there is one family history per participant, zero or more medical problems and zero or more risk factors.

Rule Modeling

The first step in the rules is to identify which risk factors the participant has.

These are defined by this table:

Figure 8 Identification of Risk Factors

The first part of modeling these rules is to identify the rule statements:

Figure 9 Rule Statements for Risk Factor Identification

Then the conditions and actions can be completed.

First we might represent the rules in natural language:

Here is a small section of the actual rulesheet:

Figure 10 Natural Language Rulesheet for Risk Identification

Then we can model the actual Corticon expression that implements each of these statements:

Figure 11 Corticon Expressions for Risk Identification

At this point we have set the risk score for each factor to a default of zero.

Once these risk factors have been determined more detailed rulesheets will evaluate all the relevant data and update the risk score


Blood Pressure Risk Factor

Figure 12 Specification of the High Blood Pressure Rules


Now we can start looking at the rules.

Figure 13 Status and Treatment of Blood Pressure



Based on the description in the rules we can see there are two aspects of High Blood Pressure:

The status (have currently or in the past) and the treatment (under care or taking medication or something else)

So we’ll model it that way:


A Rulesheet

The first step is to copy/paste the rule into the Corticon Rule Statement section:

Figure 14 The Rule Statements

Then by dragging and dropping we can complete the condition section at the top of the rulesheet.

Based on the rules we are given it will look like this

Figure 15 The Rules As Specified



Checking the Rules

At this point it’s a good idea to use the completeness checker to make sure we’ve covered all the possible rules.


The completeness checker will tell us:

Figure 16 Completeness Checker Message

Corticon has identified some missing combinations of conditions and it adds them to the decision table

Figure 17 Missing Rules Added to Rulesheet

Corticon is not smart enough to know whether these conditions are important to the risk score or what value should be assigned. The business expert must do that.

Let’s assume for this example that rule 4 has risk score of 3.

Also rule 5 represents a case where they have never had high blood pressure. We could simply leave the action blank or we could put a risk score of 0.

We should also add rule statements that correspond to the newly added rules

Now the final state of the rulesheet will look like this:

Figure 18 The Complete Rulesheet


We might also want to use the conflict checker to make sure that our rules are consistent and contain no ambiguities. The checker will tell us:


Testing the Rules

After checking the rules for logical correctness we still have to prove they produce the answer we want.

To do this we set up test cases with expected results:

Figure 19 A Test Case with Expected Results

After running the test case we should see the output score has been changed to 4 and the appropriate rule statement explaining why is displayed below.

Figure 20 A Complete Test Case that Matches the Expected Results

If our test results did not match the expected results we would see something like this:

Figure 21 A Test Case with Discrepancies Highlighted

To be complete we need to add a test case corresponding to each rule column in our rulesheet 

Modeling UMich07

Figure 22 UMich07 Rule Specification

Why is there an “else” in this rule?

Does this mean that the Diastolic pressure is only considered if there is no Systolic pressure?

Let’s assume we consider both of these factors

Modeled as specified the Systolic rule would look like this:

Figure 23 Rules As Specified

But is it correct?

If we run the completeness checker we will find that Corticon discovers some missing rules:

Figure 24 Missing Rules Identified

Systolic <=0 does not make sense and could be flagged as an error. And the null condition shows up in case we need to have a rule when there is no value of systolic supplied. In this example since the data is being gathered in a questionnaire let’s assume the value is mandatory.

This can be indicated in the vocabulary:

And the null won’t appear when we do completeness checking.

If we cannot be sure that the incoming data will all be present in the payload we might choose to create an initial data validation rulesheet that checks to make sure all the values are present and that they are within the appropriate limits.

If the input data payload contains errors then the rules can be entirely bypassed and an error message returned to the calling application.

Unless you are absolutely certain that the incoming data will be correct it’s a good idea to put such a validation rulesheet at the front.

And even if the production data is guaranteed to be correct that validation sheet will help you identify any errors in your own test data (miss-spellings, forgotten values, bad values).

In fact this will often help find discrepancies in the rule specifications when different terms are used for the same concept.


Creating a Ruleflow

We can now combine these rulesheets into a Ruleflow:

Figure 25 A Ruleflow

This can be the subject of a test sheet:

Figure 26 A Test Sheet

So now we see the effects of three rulesheets on the overall risk score for blood pressure.

Deploying  the Rules

The ruleflow comprising the three rulesheets can now be deployed as a decision service (though it currently only handles part of the overall problem)

Step 1 - Set the Ruleflow properties

Figure 27 RuleFlow Properties

Step 2 - Start the Deployment Console

Figure 28 Creating a CDD

Step 3 - Save the CDD

Figure 29 CDD Folder

Step 4 - Start the Corticon Server

Step 5 - Login to the Server Console

Figure 30 Web Console Login Screen

Use admin/admin

Figure 31 Web Console Main Menu

Step 6 - View the list of deployed decision services

Figure 32 Deployed Decision Services List

Step 7 - Configure the HRA Decision Service

Figure 33 Decision Service Overview

Step 8 - Specify Attributes to be monitored

Figure 34 Setting up Monitored Attributes

Invoking the Rules

Using Studio as a Client

Step 1 - Select Decision Service

Step 2 - Build a more comprehensive set of test cases

To be comprehensive we need to cover all the rules in our rulesheets.

Figure 35 Test Data

Step 3 - Run the test cases

Notice how selecting a risk factor highlights the messages that explain how that risk core was calculated.

Figure 36 Test Results in Studio

Step 4 - View the results in the Web Console

Number of executions now shows as one (although this actually represents 5 transactions)

Figure 37 List  of Deployed Decision Services

Details of the attributes can be viewed

Figure 38 Risk Score Pie Graph

Figure 39 Blood Pressure Status Pie Graphs

Figure 40 Blood Pressure Pie Graphs



As A Web Service

Any client application that can invoke a web service can be used to execute the decision service.

We saw above how Corticon Studio itself executed the decision service as a web service – it was able to do this easily because it already understands the data structure that needs to be passed in to the rules – it’s defined by the vocabulary.

But a non-Corticon client application will not have this information and so we need to supply it.

This is done by creating WSDL (Web Service Definition Language) using the Deployment Console:

Figure 41 Generate WSDL

This WSDL file can be saved and then imported by the client application.

We’ll take a look at how this is done using SOAP UI - a free general purpose web services client application that can be used for performance testing.

SOAP UI as a Corticon Decision Services Client Application

Step 1 - Import the WSDL

Figure 42 Create SOAP UI Project

Step 2 - Set up the SOAP Request

Enter the decision service name and data values (Similar to the test handler in Studio)

Figure 43 Simple SOAP UI Request

Step 3 - Run the Test (click the little green arrow)

The response will display like this

Figure 44 SOAP UI Response

You can see the calculate risk score (13) and the rule statements (just like in the Corticon Studio tester)

Step 4 - Set up a Larger Performance Test

Figure 45 SOAP UI Performance Test

We can set the test case to loop continuously

Figure 46 SOAP UI Loop Continuously

And in about 30 seconds, the Corticon Web Console will show something like this:

Figure 47 Execution Statistics

Now this is submitting one transaction per web service call. We can make this process more efficient by batching many transactions in each web services call. So we’ll duplicate our Studio test case in SOAP UI like this:

Figure 48 SOAP UI Request

And then to simulate a large batch we’ll replicate these transactions 10 times so that the total batch size is 50 records each time we make the web services call.

With this configuration Corticon was able to process almost 6000 records in under 30 seconds (on a laptop):

Figure 49 Performance Test Results


As A Java Service

Although the web services call is simple to set up and very flexible, there is some overhead associated with making it and so when increased performance is required you have the option of making the call to the Decision Service in-process.

To do this there is no need to have a Corticon Server deployed (under Tomcat or other Application server). You simply import the Corticon execution engine classes into your java program.

Then you can use the rich set of APIs to do everything that you could do with the web server.

You can deploy decision services, you can execute them and you can monitor them

Extensive examples of the use of these APIs is contained here in the Corticon install folder

Figure 50 Location of Sample API Java calls

The first step is to create an instance of the Corticon Execution Engine (the “server”)

Figure 51 API to Create an Instance of the Server

Once you have the reference to iServer you can use any of the other APIs to manage it.

For example to load a decision service into your server you can use this API

Figure 52 API to Load a Decision Service

 (there are several others)

To execute a decision service you can use this API:

Figure 53 API to Execute a Decision Service

Or if you are passing java objects to the rules then you could use this:

Figure 54 API to Execute a Decision Service using Java Objects

How to find out what decision services are deployed:

Figure 55 API to obtain a list of deployed decision services

Appendix A – Methodology Steps

  1. Identify the Business Decision(s) to be made
    - the nature of the business decisions often defines the decomposition into decision services
    - this may start as a Business Process diagram
  2. Collect and Review Rules needed for each decision.
    - Excel spreadsheets, word documents, existing code, flowcharts, Ruletrack, RuleXpress, etc)
  3. If necessary convert the rules into Corticon Rule Statement form
  4. Identify Business Objects (Entities) –
    - UML model perhaps or existing database
  5. Identify Relationships between Objects (1:1, 1:N, N:N)
  6. Identify Attributes
  7. Identify Possible Values
  8. Create Vocabulary (or import it from UML or database)
  9. Create Sample Data
    - Helps to make sure the data model makes sense
  10. Annotate with expected results (or create expected result or parallel business object)
  11. Generate Database (if desired) or map attributes to existing tables
  12. Decide how the rules need to be grouped into Rulesheets
  13. Model Rules
  14. Check for Ambiguity
  15. Check for Completeness
  16. Check for Correctness
  17. Check for Loops
  18. Test against sample data
  19. Deploy Decision Service on Tomcat server (or IIS)
  20. Test using deployed decision service (from Studio)
  21. Test using SOAP tool (eg SoapUI 2.0.2)
  22. Test using application code (java or .NET, or BPM)
  23. Deploy Decision Service on Production Server
  24. Invoke the production rules via the application code (or BPM)
  25. Configure Server Monitoring 


Appendix B – Problem Specification

Step I: Condition/Risk Identification

Participants will be identified according to the following criteria for each condition/risk from the HRA.


High Health Risk Criteria

Selected Measures

High Risk Criteria 

   Medical problems

Had problems with heart condition, cancer, diabetes, bronchitis/emphysema, or past stroke 

   Blood pressure

  • Systolic blood pressure greater than 139 mmHg or
  • Diastolic blood pressure greater than 89 mmHg or
  • Taking blood pressure medication or
  • Self-reported high blood pressure range or
  • Self-reported high blood pressure condition (if available) 


Greater than 239 mg/dl 


<35 mg/dl

   Physical health

Fair or poor 


High stress

   Physical activity

Less than one time per week 

   Drug/medication use

Sometimes or almost every day 

   Body Weight



Current cigarette smoker 

   Personal life satisfaction

Partly satisfied or not satisfied 

   Job satisfaction

Disagree or strongly disagree 

   Safety belt use

Using seatbelt less than 100% of the time 

   Alcohol use

Heavy drinker (>14 drinks/week) 


Step II: Stratification to Severity Level

The following risk/condition hierarchy will be used. Medical problems will be excluded from top risk rankings. Each condition/risk will be assigned a severity score. Conditions/risks will be 1) ranked according to severity scores; 2) the hierarchy will apply in the event of severity score ties; 3) severity score ranking will be adjusted according to readiness to change indications (see Step III).

  1. Medical problems (UMich 37): if medical problems are present (heart problems, diabetes, cancer, chronic bronchitis, or stroke), the information will be provided as a separate section within the profile report. Medical problems will not be ranked among the top three risks.
  2. Blood pressure (UMich 7)
  3. Cholesterol/HDL cholesterol (UMich 8; UMich 9): If either cholesterol or HDL cholesterol risk is indicated, these will be ranked as one risk. The intervention for the two forms of cholesterol are the same and we want to avoid the possibility of three biometrics being listed as the top three risks (i.e., blood pressure, cholesterol and HDL cholesterol)
  4. Perception of health (UMich 27)
  5. Stress (UMich 31)
  6. Physical Activity (UMich 23)
  7. Drug use (UMich 14)
  8. Weight (UMich 5/6)
  9. Smoking  (UMich 10)
  10. Life satisfaction (UMich 24)
  11. Job satisfaction (UMich 25)
  12. Safety belt use (UMich 18)
  13. Alcohol (UMich 15)


 If High Blood Pressure Intervention

Severity Level Assignment: Total Possible Points = 57


1. HRA High Blood Pressure:  Total Points=16

  • if answer to UMich 37 High blood pressure is  (HAVE CURRENTLY) and (UNDER CARE or TAKING MEDICATION), then 2 points
  • else if answer to UMich 37 High blood pressure is  (IN THE PAST) and (UNDER CARE or TAKING MEDICATION), then 2 points
  • if answer to UMich 37 High blood pressure is  (HAVE CURRENTLY) and  NOT (UNDER CARE or TAKING MEDICATION), then 4 points
  • if UMich 7 Systolic
    • >0 and <120      then 0 points
    • 120 -139             then 4 points
    • 140 -159             then 5 points
    • > 160                   then 6 points

else if UMich Diastolic

    • 1= <120              then 0 points
    • 2= 120 -139       then 4 points
    • 3= 140 -159       then 5 points
    • 4= > 160             then 6 points


2. Co-morbidities: Total Points=9

  • Co-morbidity Score
  • If heart problems, diabetes, cancer, chronic bronchitis or stroke, then
    • If 0 conditions, then 0 points
    • If 1 condition, then 2 points
    • If 2 conditions, then 4 points
    • If 3+ conditions, then 6 points
  • Else if allergies, arthritis, asthma, back pain, chronic pain, depression, heartburn, high cholesterol, migraines or osteoporosis, then
    • If 0 conditions, then 0 points
    • If 1 condition, then 1 points
    • If 2 conditions, then 2 points
    • If 3+ conditions, then 3 points


3. HRA Heart Risk (Score>4 = AT RISK) and/or Diabetes Risk (Score>5 = AT RISK): Total Points=12

  • Heart Score Components (possible points=7)
    Conditions identified as risks/conditions (a-e)
    • Weight=1
    • Physical activity=1
    • Blood pressure=1
    • Cholesterol=1
    • Smoking=1
    • Age/gender (Male and >45)=1
    • Family history of heart disease (UMich 36 Heart Problems Yes)=1


  • Diabetes Score Components (possible points=10)
    Conditions identified as risks/conditions (a-f)
    • Weight=1
    • Heart=1
    • Physical activity=1
    • Blood pressure=1
    • Cholesterol=1
    • Smoking=1
    • Age>45=1
    • Family history of diabetes disease (UMich 36 Diabetes Yes)=1
    • Family history of hypertension (UMich 36 High Blood Pressure Yes)=1
    • Race UMich 47 If Black, American Indian or Hispanic=1

  • If either is AT RISK, then 6 points
  • If both are AT RISK then 12 points
  • If neither is AT RISK, then 0 points


4. Conditions/Risks:  Total Points = 10
        (Risk factors will all be rated equal in terms of potential harm)

  • Conditions/Risks:
  • Smoking = 1 point
  • high cholesterol = 1 point
  • obesity = 1 point
  • physical inactivity = 1 point
  • high stress = 1 point
  • poor/fair perception of health= 1  point
  • high drug use = 1 point
  • low life satisfaction = 1 point
  • low job satisfaction = 1 point
  • safety belt use<100% = 1 point
  • high alcohol use = 1 point

Intensity Level Rule

5+ risk factors

10 points

4 risk factors

8 points

3 risk factors

6 points

2 risk factors

4 points

0-1 risk factors

2 points


5. Health Disparities: Total Points = 10
     HRA: Age, Race, Income, Education, Geographic Region (assumes answer is yes to UMich 37 High blood pressure for following to apply)

  • Age:
    •  if 50+ = 3 points
    • 40 - 49 = 2 points
    • < 40 = 1 point
  • Race/Ethnicity:
    • if Black, Native American, or Hispanic = 3 points
  • Income:
    • < $40,000 year = 2 points
    • $40,000 - $75,000 year = 1 point
    • > $75,000 year = 0 points
  • Education level:
    • < 8th grade  = 2 points
    • 8-12 grade  = 1 point
    • > 12 grade   = 0 points
  • Geography:  (from zip code)
    • South region = 2 points
    • Mid-West = 1 point
    • West and Northeast = 0

Health Disparities Intensity Level Assignment Rule

10-12 points

10 points

7-9 points

8 points

5-6 points

6 points

3-4 points

4 points

0-2 points

2 points




Notice how selecting a risk factor highlights the messages that explain how that risk core was calculated.