Release Notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.21.3.0.5

This document contains the release notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.21.3.0.5.

Enhancements

No enhancements.

Upgrade Steps for Installation

To perform the upgrade, perform the following steps:

  1. Perform any pre-upgrade steps.

  2. Stop all the managed nodes running the .existing version of the application.

  3. Perform any pre-undeploy steps.

  4. Undeploy the existing version of the application.

  5. Back up the database.

  6. Perform any post-undeploy steps.

  7. Unpack the release bundle into a directory that we refer to as OHI_ROOT from now on.

  8. Change Installation Configuration: In <OHI_ROOT>/util/install, make a copy of ohi_install.cfg.template and name it ohi_install.cfg.

  9. Edit ohi_install.cfg to contain your specific database connection data and other configuration settings. The settings are explained in the file itself.

  10. Make sure NO connections are present to the database using the OHI_xxx_USER account (where xxx is the abbreviation of the application)

  11. Run the Upgrade script:

    1. Open a command window and browse to <OHI_ROOT>/util/install.

    2. Run the upgrade by executing ./ohi-update.sh .

  12. Make the required changes to the ohi properties file

  13. Perform any post-upgrade steps

  14. Start WebLogic application server

  15. Deploy the Application

  16. Perform any post-deploy steps

Additional Upgrade Steps for Installation

The following phases are defined:

  1. pre-upgrade: Application is still running

  2. pre-undeploy: Application is stopped, but not undeployed.

  3. post-undeploy: Application is undeployed. Database is backed up

  4. post-upgrade: Released upgrade script has run.

  5. post-deploy: New application is deployed and is up and running.

Stage: pre-upgrade

Action: execute the following query to find future duplicates

select usrs.login_name
,      dupes.alias
from   ohi_users usrs
,      ohi_user_preferences uspr
,      (select uspr_id
        ,      alias
        from   ohi_bookmarks
        group  by uspr_id
        ,      alias
        having count(*) > 1
       ) dupes
where  uspr.id = dupes.uspr_id
and    usrs.id = uspr.usrs_id

This query lists bookmark aliases per user that have more than one occurrence and will violate the new unique contraint. Update the alias of the violations such that there are no more duplicates

Configuration Properties

This section intentionally left blank.

Web Services

Ref Action Subject Description

POL-9539

Modified

AttachedPolicyData API

Customers are allowed to set property 'manual' during creation.

Data Conversion

This section intentionally left blank.

Dynamic Logic

This section intentionally left blank.

UI Changes

This section intentionally left blank.

Deprecated items (to be removed in future release)

This section intentionally left blank.

Breaking Changes

This section intentionally left blank.

Bug Fixes

BugDB SR Internal BP Summary

33568543

3-27562427001

POL-9540

BP

UI : Creating a policy from JET does not update the field 'manual' in attached data.

Description:

When creating a policy from the JET UI, the field 'manual' should be checked as yes. However, the field that is used to distinguish between manual and integration is set to false, indicating the policy was created through the integration.

Resolution:

The property 'manual' on attached policy data can now be set during creation.

33641635

3-27463122071

POL-9664

BP

Removing column URI from OHI_BOOKMARK_UK1

Description:

In 3.21.3.0.0 unique constraint OHI_BOOKMARK_UK1 was created on the combination of user preferences, alias and URI of the bookmark. The URI column should be removed from the constraint.

Resolution:

The attribute URI is removed from the Unique Key on Bookmarks

33657901

3-27944936671

POL-9678

BP

Updating an approved policy through 'POLICY IN DATA FILE SET IMPORT' fails when the policyholder person is matched on relation identifier instead of code

Description:

GEN-TMVL-011 is raised during policy import: The Policyholder with start date 10/01/2021 overlaps in time with a Policyholder that has start date 10/01/2021). This happens when: 1) policyholder is matched by relation identifier in the incoming payload. 2) policy loaded using file based policy import. 3) existing policy in system is APPROVED and the file contains new version of the policy.

Resolution:

The scenario described will no longer lead to the mentioned business rule failure.

Issues that were backported in previous Release / Patch

No backports.