Friday Jul 25, 2014

Rule loops in OPA rules

Rob Bradford | OPA Rules Consultant (Europe)

As any experienced rule author will know, OPA automatically runs through a series of logic checks each time a policy model is built. One of these checks is for self-referential rules, or to put it another way rules that are proven by themselves – the logical loop check. In rare situations, usually when writing complex rules involving time based reasoning or multiple entity instances, it may be necessary to implement a controlled logic looping situation.

First introduced in OPA version 10.2, rule loops allow you to overcome the problem of rules which loop back to different instances in the same entity by defining a rule as an allowable loop, allowing the rules to validate past the logical loop check.

Loops using entity instances

The following fictitious example shows an example of a 'valid' rules loop using different entity instances. The source material states:

"a person can be a UK passport holder if they meet the qualifying criteria, or if any of their parents are eligible for a UK passport."

The rules highlighted in the red boxes below cause a logical loop upon build, however in this case the logic is correct.




To implement a rule loop in OPM, first highlight the rule. Then use the Rule Properties Editor (ALT + P) in the Word toolbar, and tick the Rule Loop checkbox:


The policy model now passes validation, and is logically sound. In the following interview, Tom has been identified as Sarah's parent. Tom has been in the UK for 30 years with no criminal record, therefore qualifies. Even though Sarah does not qualify on her own accord due to the length of time spent in the UK, the fact that she has a qualifying parent means she also qualifies.


The decision report within Oracle Web Determinations shows that Sarah qualifies on the basis of her parent, Tom:



You may have realised that the way these rules have been written, even if Tom was not suitable, he may himself have a parent who qualifies - which would make Tom, and therefore Sarah eligible. Following this sequence through, it would mean anyone with a qualifying ancestor would automatically be eligible themselves.

In this example we can assume this is the intended behaviour - but it is essential to consider where the loop could, and should end. This is sometimes referred to as identifying the exit condition.

Loops using temporal reasoning

Loops can also relate to an attribute's value at different points in time, rather than different entity instances. Consider the following logic:

"An applicant will be treated as qualifying for the benefit continuously if they have been out of the country for less than 7 days, and at the time they left the country, they qualified for the benefit"

Again, we are looking at a different instance (this time on the temporal timeline) of the attribute, but OPA will identify 'the applicant qualifies for the benefit' as a loop. Specifying the attribute as a rule loop, using the method shown above can allow the rules author to overcome this.


Consider the following worked example:

  • John's benefit period runs from 1 Jan to 31 Jan 2014 (all dates inclusive). He satisfied the income criteria to qualify for the benefit throughout the month, apart from one period between 18 Jan and 20 Jan, where his income was too high.
  • John was out of the country from 6 Jan to 16 Jan - a total of 11 days. As he continued to meet the income criteria, and qualified for the benefit the day before he left, he was entitled continuously for the first 7 days of his absence.
  • On 13 Jan, John had been out the country for more than 7 days, so became ineligible.
  • When John returned to the country on 16 Jan, he became eligible again - until 18 Jan when he did not satisfy the income criteria.
  • On 19 Jan, John left the country again until 23 Jan. Although the absence was less than 7 days, and he met the income criteria from 20 Jan, he was ineligible throughout the entire absence because he was not eligible the day before he left.
  • When he returned to the UK on 23 Jan, he became eligible again. In total, he was eligible for the benefit for 23 days out of the 31 day period.


Final points

  • Careful consideration should be given before implementing rule loops, as incorrect use can result in rules that can never be proven. If you are not sure, ask an OCS consultant.
  • The logical loop check is there for a reason! You should only use this feature if you are sure there is an exit condition. If the loop is not controlled, then the OPA rules engine will keep going around and around until it eventually stops with an error.
  • It is very important that the rules are tested thoroughly to avoid any unexpected behaviour.
  • If the loop encompasses multiple rules, each individual rule must be configured separately.

This blog is brought to you by Oracle Consulting Services. Further details about OPA enablement, coaching and mentoring services can be obtained by contacting the author.

Tuesday Jul 01, 2014

Allowing Discretion in OPA Rules

Matthew Bickham | OPA Implementation Manager (Europe)

The purpose of a policy model is to make decisions on your behalf, often applying complex sets of rules. A lot of work goes into automating the decision making process so that every decision is fair, consistent and traceable. So why on earth would you want to allow a ‘human’ to over-ride this decision? There are times when some human involvement is desirable because to automate all aspects of the process may not be practical - a policy model can only make a decision if it has all the rules it needs. Examples where some discretion might be required include: medical diagnosis, staff promotion, bonus payment, application for a grant and travel approval.

Allowing discretion in rules must be carefully thought through. A policy model should always be allowed to arrive at a decision itself where it is possible for it to do so. If permitted, the rules must be modelled to clearly state discretion has been applied, and the decision report as a consequence must reflect this.

The following fictitious example provides a simple illustration of how two areas of the rules have been constructed to allow the user (a Deciding Officer) to over-ride the automated decision.

A policy model has been authored to determine whether an applicant has a Centre of Interest in Atlantis based on a number of criteria. A decision can also be based on answers provided by a Deciding Officer. A positive decision will impact an applicant’s ability to receive certain government related payment credits.

Discretion Rules

Rules to provide discretion have been modelled in Sections 1 and 3 as highlighted by the red boxes. If the applicant’s family members are not located in Atlantis, the Deciding Officer is provided with the option to over-ride the decision.

The Deciding Officer is also able to over-ride the overall decision at the end of the assessment using a similar procedure. If the system determines that the applicant’s Centre of Interest is not in Atlantis, then it is possible to over-ride this and add other factors which might be important to the determination.

It is possible to limit the ability to over-ride and use discretion on the rule decision to a limited number of end-users (i.e. Senior Deciding Officers). In this example however, all users are provided with this opportunity. Any reasons for granting discretion must be entered by the Deciding Officer during the assessment, and these are saved as part of the interview. The journey for the user commences with the Summary Screen, which provides an introduction and a link to start the assessment:

Personal details are entered on the next screen and then the user is presented with a series of questions based on the rules to determine the applicant’s Centre of Interest:


If the user answers ‘no’ to the question relating to the close family members, the policy model contains rules to allow for discretion at this point. The Deciding Officer is provided with an option to state whether other factors should be taken into account:

The Deciding Officer is required to enter other factors which they believe should be taken into account for this assessment in a free-text format:

The policy model checks the reasons have been entered, but does not investigate whether specific factors are relevant or valid. Rules can be created to allow the user to select from pre-defined lists of options prior to this to categorise the discretion more tightly. In this example the discretion is more open.The Summary Screen is displayed and the determination is presented:

Whilst the decision is positive for the applicant, the Deciding Officer is reminded that discretion has been applied. Selecting the ‘Why’ link displays the decision report, which shows the decision was made with discretion applied by the Deciding Officer:

A record of the reason for discretion is then stored within the session case file, that is then saved and stored in the host application.If the policy model determines that an applicant does not have a Centre of Interest in Atlantis, the rules will provide an option for the Deciding Officer to use discretion and over-ride this decision as well:

In summary, the ability to over-ride a policy model decision should be treated with care. In some circumstances, factors may impact a decision where it is not feasible to model them in rules.In all cases, allowing the policy model to automate the decision making process should be considered by default. This Blog is brought to you by Oracle Consulting Services. Further details about OPA enablement, coaching and mentoring services can be obtained by contacting the author.

About

Welcome to the OPA blog where Oracle's Policy Automation experts share their views on everything OPA.

Search

Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today