OIPA Release Notes

Oracle Insurance Policy Administration

Oracle Insurance Policy Administration (OIPA) is a next-generation, flexible, rules-based insurance solution for life and annuities that supports policy processing across multiple lines of business. OIPA greatly enhances the ease of use and speed for business analysts, actuaries and others involved in the product configuration process. Robust navigation also makes it easy for users, including CSRs, to locate policy information and drill down into a granular level of customer detail. This allows insurers to respond more rapidly to customer inquiries, reduce call times and improve customer service.

These release notes contain the enhancements made to Oracle Insurance Policy Administration GA release 11.3.0.0.

Customer Support

If you have any questions about the installation or use of our products, please visit the My Oracle Support website: https://support.oracle.com or call (800) 223-1711.

Oracle customers have access to electronic support through My Oracle Support. For information, visit:

http://www.oracle.com/us/corporate/accessibility/support/index.html#info or http://www.oracle.com/us/corporate/accessibility/support/index.html#trs if you are hearing impaired.

Oracle Insurance Policy Administration

This section describes configuration, features and technology specific enhancements for GA release 11.3.0.0. OIPA now supports the following functionality:

Funds and Valuation Enhancements

Ability to have Funds with Negative Values

This feature allows Fixed Funds to contain negative cash values and negative deposits in the valuation processing. The enhancement provides a provision to the configuror whether to allow negative fund values using a definition element. When the Removals from a fund are larger than the fund's value, OIPA represents this deficiency as a negative fund value. The daily interest, expense, and costs are accumulated as additional deficiencies to this negative fund value. A negative interest accumulates a negative cash value and further decreases the value of the fund. Negative cash values accumulate negative interest at the same rate as they did for positive values along with the rate changes, and generate different accounting entries in OIPA.

For more information, refer Configure Negative Fund Values

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

Tables Modified

  • AsPolicyValue
  • AsPlanFund
  • AsProductFund

Redesign Data Storage for PIT

The data records that are generated for a policy activity's valuation are being consolidated to a more space-efficient design that may decrease overall space consumption by approximately half, thereby improving performance. The system now stores beginning and ending valuation values for deposits, funds, and policies by eliminating the options that allowed other choices. Configuration has one record to access for an activity's beginning and ending values for each deposit, fund, and policy.

Point in Time (PIT) valuation generates data that provides valuation at the start of an activity and at the end of an activity when money has been added, removed, or moved around the investment options. This data occupied two separate records for each of the fund's deposits with:

  • Deposits summarized up to the fund at start and end of activity
  • Each fund summarized to the policy at start and end of activity

This improvement combines the data into one record for each of the entities; deposits, funds, and policy. For example, if the system valued 3 existing deposits in each of 4 different funds, the system has been recording 24 records for the deposits, 8 summarizing to the funds and 2 summarizing to the policy; a total of 34 records. The improvement reduces the volume to 12 records for the deposits, 4 records for the funds and 1 record for the policy; a total of 17 records. Other scenarios result in a less profound difference, but the overall expected space savings are somewhere less than but close to 50%.

In the past, customers had a choice to record ending valuation records only where money moved or for every fund, deposit, or both. This feature eliminates the former option and all ending valuation data is now stored regardless of money movement affecting the fund's/deposit's value. In addition, the system allowed optional storage at the start of an activity. That option has been removed and valuation at the start of an activity is always recorded. This enhances valuation performance. With this feature, an activity's beginning valuation always starts with the ending valuation of the prior activity. When that ending valuation was recorded, OIPA was required to search all of the valuation history to pick up significant ending fund values.

For more information, refer Point_In_Time_Overview

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

Rules Deprecated

  • PointInTimeValuation

New Tables Added

  • AsFundValue
  • AsDepositValue
  • AsPolicyValue

Correct PIT Valuation Issues when Activity is in G/L Pending Status

This enhancement ensures that PIT valuation begins correctly with the ending values of the previous valuation and that removals correctly affect deposits in a LIFO/FIFO order. This enhancement removes the update to ActivityGMT when the activity status changes from Gain/Loss Pending to Active. Activity status updates occur as follows:

  • In scenarios where the activity's status moves from Gain/Loss Pending (14) to Active (01), the current activity's ActivityGMT is not updated.
  • ActivityGMT contains the timestamp value when the activity's status changes to 14.
  • In scenarios where the activity moves to Active (01) without stopping in Gain/Loss Pending (14) or the activity attempts execution and errors, the ActivityGMT is updated with the current timestamp.

For more information, refer Activity_Detail_Screen

Allow Calculated or Configured Values Per Fund

This enhancement allows configuration of values for a fund (for example, calculate the fund’s yield) by using a new rule, ValuationFields. The configured values are calculated during valuation processing. Values can be calculated and stored at Deposit, Fund, and Policy levels. This functionality is available only when the fund is used by a Plan that utilizes Point In Time (PIT) valuation processing; if the Plan uses Inception Valuation, the Fund’s ValuationFields business rule is ignored. A user can configure the Fund’s calculated values to display on the Values screen or use in Math (with standard Valuation syntax example: Valuation:Fund:Yield ).

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

Rules Modified

 

None

Fund Categorization and Display for Financial Tracking

This enhancement allows the categorization of funds. A user can use this functionality to track investments by categories for the required tracking purposes. If this feature is configured, funds are listed by category on the policy’s Values screen and the processed activity’s Valuation tab.

A new code name, AsCodePlanFundCategory, is used to define the applicable fund categories. After the categories are entered in the AsCode table, they can be associated to the fund in the Rules Palette. A new column, Category, has been added to the AsPlanFund and AsProductFund tables to store this new value. A new Business Rule, FundCategoryOrder, is configured to define the order in which the Categories are displayed in OIPA. The applicable configured categories are displayed on the Values Screen’s Fund Detail and Policy and Asset Graph Sections and the processed activity’s Valuation tab will display the fund categories in the configured order. If the Rule is not present or configured to "off" the funds display as they currently do, with no mention of a category name.

For more information, refer book_configurefunds

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

 

Tables Modified

  • AsPlanFund
  • AsProductFund

Display Fund Status

This enhancement supports the display on Values screen, processed Activity screen, and Inquiry screen and supports dynamic calculations of funds in Math Valuation even when the balance of the funds is zero. Configuration controls how long a fund is available for display/calculations based on the amount of time the fund balance has been zero. After the configured duration has passed and the fund balance is still zero, the fund no longer displays or allows calculations of dynamic values. This enhancement has no impact on existing customers who do not want to utilize this new functionality. This requirement is specific to the funds with zero value only. This feature does not affect the funds with non-zero value (positive or negative). The Values/Valuation continue to display as-is unless the user want to use this new functionality.

  • This feature supports tracking by fund and by deposit and is only applicable to Point In Time (PIT) valuation. Inception valuation does not support this functionality.
  • A new field, TrailingCalculationDuration, is introduced on the PlanFund in the Rules Palette Admin Explorer. The configuror needs to enter the number of days the fund should appear on the Values screens even when the balance is zero.

For more information, refer Create Parent Level Funds

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • PlanFund

Tables Modified

  • AsPlanFund
  • AsProductFund
  • AsFundValue
  • AsDepositValue

RemoveByFund Assignment Enhancement to Remove the Specified Bucket

This functionality adds the ability to withdraw money from a specific bucket of one or more indexed funds by using the RemoveByFund assignment. The RemoveByFund assignment allows an activity to remove money from one or more funds without the use of an allocation. The activity can use its configured logic to determine which funds and the amount to remove from each fund. The removal can now target a specific indexed fund bucket.

  • In the existing functionality, the RemoveByFund assignment identifies the fund or funds from which to remove money. This is now enhanced by adding a new attribute called BUCKET, which indicates the bucket number from which the money to be removed.
  • In the existing functionality, Removals from deposits, if tracking by deposit, continue in LIFO or FIFO order. This is now enhanced to ensure that the cash value of the bucket is sufficient to cover the removal amount.
Business Rule Changes Database Table Changes

Rules Modified

 

None

Dynamic Allocation Percentages for Model Asset Classes

Unlocked Asset Class based models now support dynamically weighing the asset classes themselves in addition to just the funds. The overall Asset Class allocation can be based on the sum of all the funds within the class. When using Asset Class based models in OIPA, even if the funds are unlocked for editing of allocation percentages, the Asset Classes are not editable. The system now supports dynamic Asset Class allocations in addition to dynamic Fund allocations. When creating the model in the Rules Palette, the Asset Class can be left empty or zero and when used within OIPA, the system automatically calculates the Asset Class allocation based on the fund entries.

AsCode Changes: A new system code has been introduced to AsCodeModelType with a code value of “03” and description of Unlocked Asset Class. If a model is defined as a typecode “03,” the system allows individual funds to be unlocked and the asset class allocations are not predefined.

For more information, refer:

Allocation Models

Configure Allocations Using Models

Group Customer Enhancements

DI Batch Processing in Parallel for the same Group Customer and Profile

This enhancement allows batch records to process in parallel for the same group customer and same profile where the records contained in that batch are identified as ”Independent.”

An Independent record has no dependency between the primary member and its members. If the file is identified as containing “Independent” records, then the files can be processed in parallel. If the file is identified as containing ”Dependent” records, then the files are processed sequentially. To identify whether a file contains “Independent” or “Dependent” records, a new tag is added to the file header record in which Yes/No values can be specified. The default value for the new column “Independent” is 'No.'

For more information, refer Intake Profile Definition

Requirements Enhancements

Elements in AddRequirements Resolves the Values from Math Variables and Fields

This enhancement adds flexibility to the AddRequirements business rule to retrieve the requirement name, initial status, and allowance for duplication from the activity's math variables or fields. This can replace complicated logic that determines the requirements to generate into the activity's math section. It allows the AddRequirements business rule configuration to be a boilerplate across multiple transaction configuration provided by activity math and fields. These factors are likely to reduce the scale of maintenance tasks associated to the rule's configuration.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

 

None

Add Support for CopyBook Use in Requirements

Previously, any CopyBook configuration present in the Requirement rules were ignored by the system. CopyBooks and Functions are now supported in all three Requirements sections, Source, Definitions and Results. In addition, all of the Requirements attached Rules support the CopyBooks.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

  • RequirementDetail
  • RequirementDefinition
  • RequirementResults
  • AddRequirements
  • AddImpairments
  • CopyToRequirementResultFields
  • CopyToPolicyFields
  • CopyToClientFields
  • CopyToRequirementFields
  • CopyToImpairmentFields
  • MatchRequirementResult
  • ProcessActivities
  • SpawnActivities
  • StatusChange
  • UpdateImpairmentStatus

 

None

Add Client Level Requirements

OIPA now supports Client Level Requirements (without policy/application context). Requirements can be added to a Client by using the Client/Requirement screen or by a client level activity. A new attribute is added to the ClientScreen business rule to indicate whether Client Level Requirements are allowed. The default is No. If set to Yes, and if the appropriate security exists, the Requirement node is available on the Client screen’s left navigation pane. For more information, refer Create_Requirements

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

Rules Modified

  • ClientScreen
  • RequirmentDetail (override level)
  • RequirementDefinition (override level)
  • RequirementSource (override level)

 

None

Workflow Enhancements

Create a Workflow when the User Processes a Transaction

In the previous releases, the Workflow Task generation was limited to automated processes of cycle, DI, and AsFile post insert processors. This implementation allows user-initiated activity execution to generate Workflow Tasks if additional configuration is provided. The earlier functionality is maintained as the default.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

 

None

Generate Workflow at Client Level

This enhancement supports the creation of workflow tasks at the Client level. Now, the Workflow tasks are generated through Client-level activities when those activities are run by Cycle, DI, AsFile, or user initiated from the UI.

For more information, refer Workflow Role_Queue_Task Definition

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

 

None

Segments Enhancement

Specify the Segment using a Unique Identifier

The CreatePolicy rule has multiple purposes. When the specific purpose of an activity with this rule is to copy coverages from a source policy, additional identification is needed to be certain the correct segment data are copied. This enhancement adds the ability to identify the source segment by its unique identifier. This allows a source policy with one or more segments that have the same name (same segment definition) to identify the source segments that may be copied to the new policy.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

 

None

Rates Enhancement

Add More Rate Criteria Columns to Rates

This feature provides the ability to increase the number of rate criteria columns from the default of 10 to the required number of columns based on the business needs. To utilize this feature, an optional system property rateCriteriaConfiguration.enabled is added to the PAS Properties to enable this functionality and provide validation of the database schema against the AsCode table on the newly added columns to ensure they are in sync.

The required number of rate criteria columns are defined in AsCode table of AsCodeRateCriteriaColumns CodeName. It means the AsCodes table defines the maximum number of RateCriteria columns that can exist in the system across all Primary Companies. The system reads this pre-defined CodeValue from the AsCodes table and generates the scripts to create the specified number of rate criteria columns dynamically in the AsRate and AsRateGroup tables when they are executed.

For more information, refer Rate_Groups

Note: Please Note, this script must be run immediately after the AsCode table is modified and the script is generated to ensure there are no mismatch issues, any delay in running the script may result in issues when trying to access Rates.

Client Enhancement

Ability to Identify the Client Screen Context

OIPA screens have the ability to bring the identity of a Client to the screen data. When the user attempts to provide the identity of the client, a Client dialog box is displayed, which enables the user to either find an existing Client or add a new Client. This enhancement provides the Client dialog box and its configuration with additional information about the screen from which the user navigated. This additional information can be used to find an existing client or add a new client and alter its presentation.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

Rules Modified

 

None

Other Enhancements

Name the MultiFields in the Database to Group Fields

Previously, instances of MultiFields were stored in the MultiValueField tables for all objects. When this data was queried from the database, there was no way to know how to group them unless screen rules were read, which was problematic when using APIs. To address this, a new column, GroupName, has been added to the MultiValueField tables. The GroupName column is populated with the Name configured in the MultiField Rule. The Name element in the MultiField rule is now mandatory. For existing customers upgrading to 11.3, the upgrade utility will add the Name element with the value of the MultiField rule name.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

Rules Modified

Tables Modified

  • ASACTIVITYMULTIVALUEFIELD
  • ASADDRESSMULTIVALUEFIELD
  • ASAGREEMENTMULTIVALUEFIELD
  • ASAGREEMENTROLEMVF
  • ASCLASSGROUPMULTIVALUEFIELD
  • ASCLASSMULTIVALUEFIELD
  • ASCLIENTMULTIVALUEFIELD
  • ASCLIENTRELATIONSHIPMVF
  • ASPLANSEGMENTNAMECLASSMVF
  • ASPOLICYMULTIVALUEFIELD
  • ASROLEMULTIVALUEFIELD
  • ASSEGMENTMULTIVALUEFIELD
  • ASSUSPENSEMULTIVALUEFIELD
  • ASPLANSEGMENTNAMEMULTIFIELD
  • ASPROGRAMMULTIFIELD

Create Comments from Activities

This enhancement allows an activity to create, maintain, and update comments for an entity through the attached rules. Prior to this enhancement, a user had to enter the comment in the Comments screen. Now, a comment record can be generated when an activity is processed. Also, the comments created by an activity for multiple entities can be maintained, and the status can be updated by an activity using these new attached rules.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

 

None

Allow Policy Level Activities to Update Disbursement Status

Currently, a disbursement transaction is generated by the system and the status of the activity gets updated to active after the activity is processed. Subsequently, a record for disbursement is generated in the pending status. This enhancement provides the ability to update disbursement status using a policy-level transaction without creating plan or company level transactions. Single or multiple disbursements can be updated.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

 

None

Ability to Access External Application Links from OIPA

OIPA provides the ability to configure third-party links to access third-party client applications, such as Accounting Management Systems, Document Management Systems (DMS), and other external systems that operate outside and independent of OIPA. Currently, OIPA has the ability to present an external URL navigation hyperlink on any screen that supports dynamic field(s) and update external target dynamically using actions/events. This enhancement enable the users to configure links using the newly introduced system rule ExternalLinks at three different levels in OIPA as following:

  • At higher level, in the Admin Menu of the Home Page, users can configure external links access at the Primary Company level.
  • At middle level, in the Left Navigation pane, users can configure links per context such as Client, Case, Suspense, Policy and Group Customer.
  • At lower level, users can configure links in the screens per the business need.

The following table describes the business rules and database table changes as part of this enhancement:

Business Rule Changes Database Table Changes

New Rules Added

 

None

OIPA Screen Changes to Support Accessibility Requirements

To support the Screen Reader requirement for accessibility, the location of the Save and Cancel buttons has been modified for the following screens in OIPA:

  • Case
  • Client Withholding
  • Policy
  • Policy Withholding

Service Layer Enhancements

The following is a list of Service Layer enhancements for 11.3.0.0:

Authentication and Authorization

The current security model of Service Layer only allows authentication and authorization using container based security. Now, the authentication and authorization process of Service Layer API is enhanced as per the industry standards that leverages the delegation security model with-in OIPA framework using the oAuth 2.0 protocol. It establishes data security at a row level and secures the APIs and Data accessed through the Service Layer.

When the Service Layer is registered with the IDP (Identity Provider), CLIENT ID (client_id) and CLIENT SECRET (client_secret) are generated, which can be configured in the Relying Party Server in a secured encrypted file format. The client applications (such as web, mobile) can access the OIPA REST APIs by exchanging the authorization code with authorization server and receiving access token in exchange. The following authorization GRANT types of oAuth 2.0 can be used by different client applications.

  • Client Credential Grant: In machine-2-machine interaction (a client application authenticating another client application) can use client credential grant.

  • Authorization Code Grant: A web application with a server (back-end channel) can use authorization code grant.

  • Password Grant: A native app (mobile native, android, or iOS apps) can use password grant.
  • Implicit Grant: A single web page application (SPA) that is just browser based and has no server can use implicit grant.

POST and PUT Services

This feature enables third-party integration allowing them to seamlessly connect, collaborate, and exchange data within the OIPA ecosystem. The new service endpoints add PUT and POST capabilities to the following entities:

  • Policy
  • Client
  • Case
  • GroupCustomer (only phone and address sub-resources are supported)
  • Segments
  • Roles
  • Requirements
  • Segment Roles

GET Service Enhancements to Include Plan, Product, and Company

Currently, GET capability is supported for Client, Policy, Case, Client Relationship, and Group Customer entities. This enhancement extends GET capability for the following entities:

  • Plan
  • Product
  • Company

Get Service Enhancement to Include Segment Role

Currently, the service layer GET capability for Policies or Segments is limited and does not return any of the Segment Roles. This enhancement extends the GET capability to include the Segment Roles.

Coherence Cache Refresh Service

Whenever there are any changes to the business configuration, such as business rules, transactions, authorization, and so on in the Rules Palette, it does not get reflected in the application unless the server is restarted. A new web service has been implemented (which can be called within OIPA) to clear the cache after any updates in the Rules Palette. This causes all the logged in users to be logged out. When they login again, the cache is refreshed with the latest data and the changes are reflected in the application.

Fetch Business and Non-Business Date from Calendar

A new REST service has been implemented to retrieve calendars using the GET method.

For more information on all the aforementioned Service Layer Enhancements, refer to the Service Layer Documentation.

Admin Console

Admin Console is enhanced with the following features in 11.3.0.0

Improved Overall Navigation of Admin Console System

Previously, Admin Console only supported a Home page and Cycle screen. This release adds new screens and functionality, thus improving the overall navigation of the system.

Read Logging

This feature provides the ability to capture the navigation data for screens that users navigate in OIPA and provides an audit for the screen navigation in the Admin Console. Logging of screen navigation can be set ON or OFF through PAS properties.

For more information, refer Navigation_Audit

User Logs Purging

This enhancement provides users with controls and tools to configure User Logs purging based on certain criteria (for example, by age or last access). A user can run this as a scheduled job or on an ad-hoc basis.

For more information, refer:

User Log Purging Overview

Add Schedules for User Log Purging