Advanced Oracle Policy Automation – OPA Context Pattern
Disclaimer: There will be advanced concepts that require the reader to have a firm foundation in OPA.
OPA patterns show up over and over to solve problems such as the need for the shortest interviews, need for wizards, and need for calculators. In this blog post I will discuss what I refer to as my "OPA Context Pattern" used for the need to compare determinations made by different rules.
- Allow analysts, workers, and batch jobs the ability to see how rules impact determinations.
- Provide functionality to tell the business when a retroactive rule has negatively impacted an already-utilized determination.
You need to support policies and data that may change retroactively. The retroactive changes produce ever-growing complexity.
To handle retroactive changes, you must reproduce historical determinations and measure their impact against current and future determinations.
When a retroactive change is made due to a policy change, staff may need to be notified, or other actions may need to be taken. The business needs to know if the change impacts historical, current, or future determinations.
This solution often requires implementing both the OPA Warehouse Pattern and OPA Rule Revision Pattern.
The OPA Warehouse Pattern is needed, because if a history of transactions is not provided, you cannot have OPA reproduce historical decisions. Without reproducing historical decisions, OPA won't to be able to see if the decision was impacted by a more recent rule.
The solution from the OPA Context Pattern is to move goals out of Global and into a context entity. Make the context entity the top-level entity for your substantive rules. Put all entities and attributes used by substantive rules in or under the context entity.
Write rules as normal.
If a rule impact needs to be made, have OPA create more than one context entity and compare the goals in the entities. Each context entity should have different assessment dates and the circumstance dates.
The assessment date for a context entity should set "the current date" for rules within that context. This makes sure only rules as of the assessment date are applied. Be careful in your rulebase to make rule changes temporal (such as per the OPA Rule Revision Pattern.)
Recommendation: Rules only need to be given temporal dates when they change. A rule that is in place from the first ruleset and never changes doesn't need to come into or out of existence.
Recommendation: Don't delete rules from a project until all the data that was determined by the rules no longer exists.
The circumstance date for a context is used to filter system transactions so that only transactions on or before the circumstance date are applied.
How do you know it was a rule that impacted a determination as opposed to a circumstance change impacting the determination?
Because, if the circumstance date is the same between two contexts but the assessment date changes and the determination changes, then it was the rule change that caused the determination change. A determination is a combination of rules and data. If the data didn't change, but a determination at a point in time changed, then the culprit must be a rule change.
If the change was a negative impact, then notify the business; otherwise write a compensating rule to apply.
The final determination reported is the determination at the most current assessment with the most current circumstance after applying any compensating rules. That final determination is copied into Global by non-substantive rules and passed back to the consuming system.
The structure adds six necessary components to a project:
1) The context entity to take the place of Global.
2) An assessment date attribute in the context to apply to rules.
3) A circumstance date attribute in the context to apply to data.
4) Attributes under the context entity that are filtered to only contain data known as of a circumstance date.
5) Temporal settings on rules, so rules are correctly applied as of the assessment date.
6) A rule document to compare results in contexts and to take action.
An eligibility rule is put into place where a person must be over the age of 65 to qualify. However, due to a mistake, the policy analyst puts an age over or equal to 65. Later that month the mistake is noticed and corrected.
The original rules are implemented with a ">= 65" and a rule effective date implemented by checking the calendar date.
In this example, "the person is eligible" is an attribute in the context entity, not in global. So, multiple determinations of the person’s eligibility are possible based on different contexts.
The correction to the rule is implemented.
The calendar date remains the date that the rule goes into effect based on policy. However, the assessment date is the date that assessments start using the corrected rule.
This demonstrates there can be a difference between when a rule is supposed to be enforced and when a rule is actually enforced. These differences are important to arriving at accurate eligibility determinations. OPA can handle the differences as follows:
The problem is now simply a comparison of goals between two different context entities.
Each context entity represents different assessment dates and the exact same data (one date without the correct rule, one date with the correct rule.) For example:
The determination from the primary context is collected and passed back to the client.
[The full example OPA project is being provided in a later blog on recoupment.]
1) Create a context for rule assessments.
2) Migrate all goals and time-sensitive attributes to the context.
3) Use temporal rules where rules can be filtered based on when they were invoked.
4) Use temporal data where data can be filtered based on when it was used.
5) Provide a global location to copy final determinations for passing back to source systems.
Rules of thumb
- Every decision should have a context (the decision as of X rules and as of Y date)
- Every changed rule should be temporal.
- All data that varies over time should be temporal.
This pattern appears truly unique to OPA. It adds a little complexity that requires advanced policy modelers and discipline. If a project isn't set up from day 1 to support this pattern, it can be a hard pattern to implement retroactively. This pattern is especially useful where rates can change retroactively. In particular, if large tables of rates are utilized, mistakes tend to be made in the rates by the business. An ability to find and correct determinations with historical mistakes in rates can pay dividends.
The only other viable options appear to be to run circumstance data through OPA multiple times using different assessment dates, and then let the source system determine impact; or to use data analysis in a data warehouse. In these cases, the policy writers are not as involved in the immediate correction of determinations.
It may be easier to use this pattern with project inclusions that contain large yearly or quarterly rate tables. A master project that processes applications or performs intake can then avoid the complexity added by this pattern. In this manner, a business can explain why an application would be accepted last week, but denied this week given the same data when the rates are the culprit.