The decision in this example is to determine a Health Risk Score based on a number of factors:
Figure 1 Health Risk Assessment Factors
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 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)
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)
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.
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.
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
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:
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
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:
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
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.
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.
The ruleflow comprising the three rulesheets can now be deployed as a decision service (though it currently only handles part of the overall problem)
Figure 27 RuleFlow Properties
Figure 28 Creating a CDD
Figure 29 CDD Folder
Figure 30 Web Console Login Screen
Figure 31 Web Console Main Menu
Figure 32 Deployed Decision Services List
Figure 33 Decision Service Overview
Figure 34 Setting up Monitored Attributes
To be comprehensive we need to cover all the rules in our rulesheets.
Figure 35 Test Data
Notice how selecting a risk factor highlights the messages that explain how that risk core was calculated.
Figure 36 Test Results in Studio
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
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.
Figure 42 Create SOAP UI Project
Enter the decision service name and data values (Similar to the test handler in Studio)
Figure 43 Simple SOAP UI Request
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)
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
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
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
High Risk Criteria
Had problems with heart condition, cancer, diabetes, bronchitis/emphysema, or past stroke
Greater than 239 mg/dl
Fair or poor
Less than one time per week
Sometimes or almost every day
Current cigarette smoker
Personal life satisfaction
Partly satisfied or not satisfied
Disagree or strongly disagree
Safety belt use
Using seatbelt less than 100% of the time
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).
If High Blood Pressure Intervention
Severity Level Assignment: Total Possible Points = 57
1. HRA High Blood Pressure: Total Points=16
else if UMich Diastolic
2. Co-morbidities: Total Points=9
3. HRA Heart Risk (Score>4 = AT RISK) and/or Diabetes Risk (Score>5 = AT RISK): Total Points=12
4. Conditions/Risks: Total Points = 10 (Risk factors will all be rated equal in terms of potential harm)
Condition/RisksIntensity Level Rule
5+ risk factors
4 risk factors
3 risk factors
2 risk factors
0-1 risk factors
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)
Health Disparities Intensity Level Assignment Rule