Newsletters
Abstract
This article focuses on the details for creation of an ODM rule application.
Content
In addition to the input and output signatures, the generated ODM ruleset project also contain a rule flow that is used to define the rule processing order for the various rules within this ruleset. That could be as simple as a straight-through flow that executes all rules in whatever order ODM determines, or it could be a synchronized coordination of rules based within or across packages and individual rules. For example, a simple rule flow might look like the following diagram:
Note that this article uses the ICFM detection tooling, which eliminates multiple manual steps required for integration. Thus, to follow these steps, the ICFM detection toolkit is required; however, the basic steps and the resulting artifacts are the same even when using different tooling.
The ICFM Detection Toolkit is an Eclipse plug-in that supports an ICFM project within the Eclipse ecosystem. The toolkit is comprised of a custom perspective, view, navigator, as well as a variety of menu options to support the creation of the orchestration, models, rules, and other artifacts that comprise a fraud detection package.
Creating a Detection Rule Project
The ICFM Detection Toolkit supports the Eclipse new action that launches a project creation wizard, which prompts for the necessary information required to determine the intent for this detection. Based on that intent, the tooling generates the necessary artifacts required to implement the fraud detection.
This article shows you how to create a set of rules that will be evaluated against a medical provider. We will be using a previously created business (logical) object called Provider_Pedigree. For this example, our provider is a medical provider, so the ICFM project is named Medical_Provider_Fraud_Rules,where rules will be built based on the provider's risk indicators defined as the "pedigree."
Using the standard Eclipse new project gestures (such as CTRL+N), select to create a Counter Fraud Deterministic Rules project. Note that you can also create a detection project that is rule focused, which results in a slightly different process through the creation wizard; regardless, the end results are the same.
A dialog appears where the data that will be used in the analysis is specified. In this example, the logical object has already been registered, so it was just chosen from the list.
When a detection project is created that is comprised of rules, the toolkit generates two primary artifacts; an ODM ruleset project and an analysis flow (implemented either as an IIB communication flow or a Java MDB project). When the "implement rules against ICFM" option is chosen in the wizard, it will further request information on the data that you are going to use. The information on data is used to know what query to perform to obtain the data that will be sent to ODM, and for creation of the artifact representing this data (necessary to generate the proper ODM rule application signature).
As a reminder the Provider Pedigree logical object definition is shown:
Implementing the rules
Note that not all individual tasks are specified, such as the defining the variables. These will be obvious ODM steps, so for the complete implementation source, refer to the MPF rule source provided in the MPF archive file.
When a deterministic ruleset project is created in ICFM, the structure is similar to:
When the RuleSetitem is opened, the toolkit automatically switches to the ODM Rule Designer perspective, and opens the rule project. The structure is similar to:
The ICFM Detection Toolkit generates the ODM ruleset with the input and output signatures of that rule application. The input signature is based on the data type specified at type of creation; for instance, it may be a native ICFM type, such as a transaction or party object, or it may be a business (logical) object, such as a medical procedure invoice, or an account balance for certain types of accounts. Depending on the data specified, the toolkit will generate a XSD schema file, if necessary. This schema is used when the toolkit generates the ODM ruleset project. The input schema always expects an array of these objects; thus, in this example, we will have an array of Provider_Pedigree logical objects, which is defined as InputData in the provider_pedigree_wodm_io package.
The output schema data type is specified as the ICFM AssessmentResults XSD, which supports multiple assessments generally corresponding to the input sequence related object. The ODM ruleset project would then look similar to:
Remember that the InputDatais an array of Provider_Pedigreeobjects, so the rule flow has to cycle through those objects, as shown above. This rule flow executes a set of rules, called medical_provider_checks, for each provider individually.
In addition to the InputData, and corresponding OutputData, rule applications often define local variables.
Local variables, such as Provider, providerIndex,and providerScore are used internally within the rule application, but are never exposed externally. These represent the current provider from the list, the current index into the list (aka array), and that provider's numerical score, respectively.
The rules can be implemented using decision tables, action rules, and various other rule patterns. The rules are written for a single provider, thus the above variable Provider represents the current provider (on which the rules will execute). Right-clicking on the rules folder allows the creation of the package structure and individual rules. In this example, let's create a set of action rules that are similar to those shown:
In these examples, each rule is a simple conditional, such as seen in the above "special interest person" indicator, and in the below example that checks two indicators at once. All rules add to the combined score for that individual provider.
Note that the vocabulary used in the rules is dependent on the name of the logical object and the names of the fields within that logical object. The vocabulary can be changed, as necessary.
Convenience methods for handling arrays
Note that at the time of this writing, there are two methods that must be implemented for array processing. A future version of the toolkit will generate these methods.
As previously stated, the input and output of the rule application is a set of arrays; an array of Provider Pedigree objects as input, and a corresponding set of AssessmentResults that are sent as an output response. This is seen clearly in the rule flow, which explicitly shows the loop. However, to make it easier to process arrays, there are a couple convenience methods that do some of the array manipulation.
Input Array Processing
As seen in the rule flow, there are two action tasks that are used to process the array handling necessary. As previously stated, the input array contains the list of provider data and, as seen below, the action assigns the current Provider the value based on the array index. This means that the Provider variable contains the provider on which all rules will be executed against.
The method obtainNextProvider has the contents as seen below. The obtainNextProvider method is used to obtain the next provider in the array and assign it as the current provider, which the rules will then operate on.
NOTE: Each of the actions in the flow have a corresponding method; thus, the action body is just the name of the method.
Output Array Processing
As seen with the incoming list of logical objects, the output is a list of AssessmentResults. The rule flow action for the output would call a method createAssessmentForProvidr, which is used to assign an assessment against the current logical object, or the provider in this example. The purpose of this method is to add an AssessmentResult 'record' for the corresponding input 'record' (or array element). This means that for each input element, there is a corresponding output element.
Convenience Methods
The steps in the flow have the corresponding method implementation:
obtainNextProvider is added to the project at the root level (not in the BOM).
providerIndex = providerIndex + 1;
if (providerIndex >= InputData.Provider_PedigreeList.size())
{
provider = null;
return;
}
provider = (Provider_Pedigree)InputData.Provider_PedigreeList.get(providerIndex);
providerScore = 0;
createAssessmentForProvider, is performed at the completion of the rules, and creates the assessment for that input array "record."
- // Create Assessment
AssessmentResult ar = new AssessmentResult();
if (ar == null) return;
ar.score = providerScore;
ObjectRef focalObjectRef = new ObjectRef();
focalObjectRef.objectID = provider.OBJECT_ID;
focalObjectRef.objectType = "party";
ar.focalObjectRef = focalObjectRef;
ar.context = InputData.context;
// add to list
OutputData.resultDataList.add(ar);
initialization, is defined at the root of the rules project (not in the BOM)
- providerScore = 0;
providerIndex = -1;
OutputData = new OutputData();
Deploying the Rule Application
The rule application can be deployed using the IBM Detection Toolkit deploy option, or natively from the Rule Designer (the Rule perspective). In this example, the ICFM toolkit deploy operation is shown:
For testing purposes, the rule application can be deployed directly to the Rule Execution Server. For deployment on a non-development environment, the rule application becomes part of the Counter Fraud archive.
Testing the Rule Application
An easy way to test the rules is to use SoapUI as the execution client. To do this, obtain the WSDL from the ODM Rule Execution Server by using the Explorer tab to drill from the RuleApp into the RuleSet. When the ruleset is displayed, use the Retrieve HTDS Description File (upper right corner of the following screen shot) to obtain the WSDL file.
After the WSDL is obtained, create a SoapUI Test project, using the WSDL as the definition and allowing SoapUI to generate a test harness. The following screen capture shows the SoapUI project being created.
Create a new request or modify one that was created, providing contents similar to what is shown in the following screen capture. The source of a request for this ruleApp is:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:med="http://www.ibm.com/rules/decisionservice/Medical_Provider_Fraud_RuleApp/Medical_Provider_Fraud_Rules_RuleSet" xmlns:par="http://www.ibm.com/rules/decisionservice/Medical_Provider_Fraud_RuleApp/Medical_Provider_Fraud_Rules_RuleSet/param" xmlns:prov="Provider_Pedigree-wodm-io">
<soapenv:Header/>
<soapenv:Body>
<med:Medical_Provider_Fraud_Rules_RuleSetRequest>
<!--Optional:-->
<med:DecisionID>1</med:DecisionID>
<par:InputData>
<prov:inputData>
<!--Zero or more repetitions:-->
<Provider_Pedigree>
<OBJECT_ID>1</OBJECT_ID>
<PARTY_NAME>Foo Bar</PARTY_NAME>
<PARTY_ASSESSED_VALUE>888</PARTY_ASSESSED_VALUE>
<INDIVIDUAL_BIRTH_DATE>1960-01-01</INDIVIDUAL_BIRTH_DATE>
<INDIVIDUAL_DEATH_DATE>2099-12-12T00:00:00</INDIVIDUAL_DEATH_DATE>
<HAS_PEP_FAMILY_MEMBER>1</HAS_PEP_FAMILY_MEMBER>
<HAS_RCA>1</HAS_RCA>
<HAS_SIP>0</HAS_SIP>
<LAW_ENFORCEMENT_ALERT_COUNT>10</LAW_ENFORCEMENT_ALERT_COUNT>
<PRIOR_DECLINES_COUNT>2</PRIOR_DECLINES_COUNT>
<PRIOR_TXN_ALERT_COUNT>3</PRIOR_TXN_ALERT_COUNT>
<COUNT_OF_PARTY_ALIASES>5</COUNT_OF_PARTY_ALIASES>
</Provider_Pedigree>
</prov:inputData>
</par:InputData>
</med:Medical_Provider_Fraud_Rules_RuleSetRequest>
</soapenv:Body>
</soapenv:Envelope>
Within SoapUI, the project now looks similar to:
On execution of the rule application with the provided input, a result similar to the following is produced:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ds="http://www.ibm.com/rules/decisionservice/Medical_Provider_Fraud_RuleApp/Medical_Provider_Fraud_Rules_RuleSet">
<soapenv:Body>
<Medical_Provider_Fraud_Rules_RuleSetResponse xmlns="http://www.ibm.com/rules/decisionservice/Medical_Provider_Fraud_RuleApp/Medical_Provider_Fraud_Rules_RuleSet">
<DecisionID>1</DecisionID>
<OutputData xmlns="http://www.ibm.com/rules/decisionservice/Medical_Provider_Fraud_RuleApp/Medical_Provider_Fraud_Rules_RuleSet/param">
<ns0:outputData xmlns:ns0="Provider_Pedigree-wodm-io" xmlns:ns1="http://com.ibm.cf.CFCommonTypes/CFCommonTypes">
<resultData xmlns="">
<focalObjectRef objectType="party" objectID="1"/>
<score>100.0</score>
<context>default</context>
</resultData>
</ns0:outputData>
</OutputData>
</Medical_Provider_Fraud_Rules_RuleSetResponse>
</soapenv:Body>
</soapenv:Envelope>
Related Information
Was this topic helpful?
Document Information
Modified date:
26 September 2022
UID
swg27049815