Release Notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.22.2.0.4
This document contains the release notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.22.2.0.4.
| Version compatibility: Oracle Health Insurance Enterprise Policy Administration Release 3.22.2.x is only compatible with other Oracle Health Insurance applications release version 3.22.2.x unless explicitly stated otherwise. |
| In accordance with the OHI error correction policy (Document 1494031.1 on My Oracle Support), error correction support will be provided for this release and the previous two releases. |
Upgrade Steps for Installation
To perform the upgrade, perform the following steps:
-
Perform any pre-upgrade steps.
-
Stop all the managed nodes running the .existing version of the application.
-
Perform any pre-undeploy steps.
-
Undeploy the existing version of the application.
-
Back up the database.
-
Perform any post-undeploy steps.
-
Unpack the release bundle into a directory that we refer to as OHI_ROOT from now on.
-
Change Installation Configuration: In
<OHI_ROOT>/util/install, make a copy ofohi_install.cfg.templateand name itohi_install.cfg. -
Edit
ohi_install.cfgto contain your specific database connection data and other configuration settings. The settings are explained in the file itself. -
Make sure NO connections are present to the database using the OHI_xxx_USER account (where xxx is the abbreviation of the application)
-
Run the Upgrade script:
-
Open a command window and browse to
<OHI_ROOT>/util/install. -
Run the upgrade by executing
./ohi-update.sh .
-
-
Make the required changes to the ohi properties file
-
Perform any post-upgrade steps
-
Start WebLogic application server
-
Deploy the Application
-
Perform any post-deploy steps
Bug Fixes
| BugDB | SR | Internal | BP | Summary |
|---|---|---|---|---|
35153666 |
3-32317309991 |
POL-12381 |
BP |
Recovering a failed POLICY_IMPORT activity sometimes gets stuck in 'In Process' status |
Description: |
Recovering a failed POLICY_IMPORT activity sometimes gets stuck in 'In Process' status and does not reach an end status in a multi-node cluster set-up and the error "java.lang.IllegalStateException: Identifier:<IDENTIFIER_OF_THE_ACTIVITY> already exists" is raised |
|||
Resolution: |
java.lang.IllegalStateException (identifier already exists) error is fixed |
|||
35153982 |
3-32001951751 |
POL-12387 |
BP |
When generating policy calculation periods with forward billing, an infinite loop sometimes happens |
Description: |
In a situation where the reference date is later than 28 or 29 of the month and also later than the start date of a collection setting, including a period that contains month February, the method that calculates the next period for the end of February keeps on spinning into the same period causing the determination of forward calculation date to go into an infinite loop. This applies for collection settings that use advanced period Month. For example the period that should be calculated for month 2011-02-28, while the reference date was 2021-06-30: it is returning the period 2011-01-30 - 2011-02-27 over and over again. |
|||
Resolution: |
When calculating spans for the periods to be generated, in case February does not start on the first day of the month, a correction takes place to make sure the length for the next period is determined properly. And in case reference date is later than start date of the next period, another correction takes place to start measuring from one day before the reference date. However, the correction of February month is not taken into account. So the length to determine the next period is not calculated properly. The correction of February month is included to calculate the length of the period in case the reference date is later than the start of the period. For example the period that should be calculated for month 2011-02-28, while the reference date is 2021-06-30: it is returning the period 2011-02-28 - 2011-03-27. |
|||
35182665 |
3-32329590821 |
POL-12457 |
BP |
Applicable Base Amount is not properly calculated for Adjustments with a higher sequence during Premium Calculation |
Description: |
During Premium Calculation, one has the possibility to reconcile the results during the last period. When there are multiple sequences, the Applicable Base Amount is not properly adjusted after the calculation of one of the adjustments during the reconciliation. |
|||
Resolution: |
Applicable Base Amount is adjusted after adjustment calculation and now includes the result of previous adjustments. |
|||
35153724 |
3-32317309991 |
POL-12385 |
BP |
Add diagnostic logging to investigate GEN-HTTP-017 error (missing enrollmentProductCode) to Policy-In batch integration point |
Description: |
Sometimes GEN-HTTP-017 error is raised with the message that the mandatory enrollmentProductCode is missing in the policy-in data file, however the data file contains enrollmentProductCode. It appears that the policy-in request is processed in generic policies API format instead of policy-in IP format. So, added diagnostic logging to help find the root cause if the error surfaces again |
|||
Resolution: |
Added diagnostic logging to investigate GEN-HTTP-017 error (missing enrollmentProductCode) to Policy-In batch integration point |
|||
35215668 |
3-32491637291 |
POL-12504 |
BP |
Policy events created by previous policy versions are not handled when calculating invoice for the latest policy version |
Description: |
Generate mutations for the following integration points is not in line with the Generate Mutations activity: - Run Calculation and Produce Invoice for a Policy - Run Calculation and Produce Sample Invoice for a Policy - Run Calculation and Produce Invoice for a Group Account - Run Calculation and Select in Set for a Group Account. When generating mutations based on policy events of type 'Policy', it should, just like the activity, also include events of previous approved versions of the policy. |
|||
Resolution: |
Whenever mutations are generated, events of event level 'Policy', of previous approved versions of a policy are included. They are also included in the removal of events. |
|||
35153080 |
3-32329663231 |
POL-12375 |
BP |
Bulk update activities are completed with technical error - java.sql.SQLIntegrityConstraintViolationException |
Description: |
In the following scenario the bulk update activity lead to Unique key violations: 1. Bulk update definition has attribute value for versionStatusAfterUpdate: NEW EDIT. 2. Policy 1 Approved → is set to Edit, changes successfully applied Policy 2 Approved → is set to Edit, changes not successful (could be because of some business rule violation or dynamic logic error). Because of that failure of policy 2, everything is roll-backed: except for setting the policy in Edit status. And retried for one policy each. So for policy 1, the policy is set, yet again to Edit status. Causing the Unique key violation which is in turn translated into a java.sql.SQLIntegrityConstraintViolationException.. |
|||
Resolution: |
In case of a retry, when policy is set to Edit, it is first checked if that policy has a new version in the meantime. If that is true, it will not create a new version. |
|||
35111238 |
3-32053398351 |
POL-12313 |
BP |
Status of Group Client is fetched before the Group Client processing activity is finished |
Description: |
When submitting the Group Client through JET UI, it will first submit the Group Client and then check the status of that Group Client. When the Group Client is not fully processed yet, the status check will give a undefined response. |
|||
Resolution: |
The status of a Group Client will give the correct response, even if the Group Client activity is still processing |
|||