Last time, I spoke about Oracle Policy Automation (OPA), the importance of traceability and how to ensure it in a web service environment [read my last blog here]. This time I will take you on a journey through time: How to make the most of time-based reasoning when using OPA in a web service environment.
Time-based reasoning – say what?
Time-based reasoning, or temporal reasoning, is what Oracle refers to as “[the] ability to reason with rulebase attributes or outcomes whose values change over time. Rules written in Oracle Policy Modeling are thus time-aware, operating simultaneously both at a specific point in time (e.g. the time at which you run an investigation, or some specific point in the past or future), as well as across time periods (e.g. ‘in the last three months’, or ‘until the person’s 18th birthday’).”
So, why would you want to use it? Most organizations dealing with decisions on eligibility and/or entitlements will face the issue of time in their decisions. The main reason to use time-based reasoning is to ensure the right set of rules is applied, regardless of the moment when the decision is made. Two examples are:
- The time between the moment the application is received and the period the application is for: When an application arrives on January 5th 2013, but it concerns the period including November 2012, do we apply the rules that were applicable in 2012 or 2013?
- The period of time that relates to the application: What if we want to determine eligibility for a state pension and we need to review the entire period a person’s has worked? That will mostly be 40 to 50 years in which law and legislation have probably changed.
So how does it work?
Well, say eligibility for a grant depends on the person’s residence, income and work status. Visually, the timeline decision structure will look something like this:
Let’s say the minimum yearly income is €25.000, the person’s country of residence should be The Netherlands and the person’s work status should be either full time, part time, dual or internship. Filled with some example data, the timelines could look like this:
We can see from these timelines that
- The person lives in The Netherlands from 1983 to 2004. This sets the residency conditions to TRUE in that period.
- The person’s work status switches from None, to Full Time (2001), to Part Time (2002), to Dual (2003) which means the person has a relevant work status from 2001 to 2004.
- The person’s yearly income varies over time and meets the conditions 2001 and 2003, but not in 2002.
These three conditions together, mean that the person first becomes eligible for the grant, when work status switches from None to Full Time. However, for the year 2002, eligibility switches to FALSE due to the person’s yearly income being too high.
In XML, timelines look something like the picture below, with ‘change points’ for each date the value of the attribute changes.
So, from this XML we can derive that the attribute “person_eligible” is initially uncertain, false from 1983-07-05, true from 2001-01-01, false again from 2002-01-01, true again from 2003-01-01 and uncertain from 2004-01-01. In other words; true in 2001 and 2003.
Time-based reasoning in a web service environment
Oracle Policy Automation is a very powerful tool for interactive determination. However, in some landscapes it is only used as a web service to reach a conclusion for an automatic process. No end user will ever see the interface of OPA in that situation. This might be the case when a certain workflow environment is used which does not easily integrate interfaces with OPA.
Now, when your system is using a data model structure which does not allow timelines, you might lose certain important information when storing your decisions. To avoid losing information, the timelines from the XML message can be stored in separate instances for each timeframe.
Now, that sounds fairly easy, doesn’t it? Just create instances for the timeframes on the decision timeline and you’re done. However, there’s a catch… The trouble lies in the attributes that cause the decision, that you will want to store as well if you want traceable decisions.
Imagine a decision based on three conditions. Two of the conditions are Boolean attributes, but the third is a text attribute with six possible values. Four of those values will lead to a positive decision, the other two will lead to a negative decision.
Now, the decision remains the same during the timeframe, but the underlying attribute changes during the timeframe. For traceability reasons you would want to store separate decisions for these underlying timeframes, because the decision attributes differ over time (from full time, to part time, to dual). If you were to store the decision as one instance, you would lose information about work statuses that you based your decision upon. You might need this information later on to assure the client or other party that the decisions are made compliant to law and legislation, for example in case of an appeal. Next to that, employees will be aided better in the decision making or reviewing process when the reasons for the decisions that were made are detailed enough.
So, if you make sure your data model supports the decision structure (for details, read my last blog) and the timelines are split up into correct instances, you should be able to integrate OPA into you web service environment very well!