Release Notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.22.2.0.10
This document contains the release notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.22.2.0.10.
| 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. |
Enhancements
| ID | Summary | Patch |
|---|---|---|
AUT-2744 |
Improved memory management The Application Health Check status 429, informs the load-balancer or client programs that no new requests should be sent anymore, when the free memory goes below the threshold limit as set by the system properties. When the memory state becomes low, lower, or critical, then depending on the state either no new background processing tasks are started, or they are rejected, or terminated. |
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 |
|---|---|---|---|---|
35432125 |
3-33132676711 |
POL-12883 |
BP |
Parameterize forward billing for Get Calculation Cycles for a Policy IP |
Description: |
Changed default behavior from forward billing to current billing. Added parameter "billingCycle" to be able to switch to Forward, or Immediate Billing. Existing periods are not included, but replaced if applicable. Note: This replacement of periods is not persisted, just like the new, generated, periods. |
|||
Resolution: |
Changed default behavior from forward billing to current billing. |
|||
35397058 |
3-33021191541 |
POL-12810 |
BP |
In group client event login name is displayed in username field instead of display name |
Description: |
When group client events are created using the pre-defined method addGroupClientEvent, the username attribute is filled with login name instead of display name. |
|||
Resolution: |
Changed setting the attribute username in pre-defined method addGroupClientEvent: it is using the display name. Also a conversion script is added to update group client events that have login name as username: those are updated to display name of the user. |
|||
35453021 |
3-33219559511 |
POL-12915 |
BP |
Generate CatchUp Policy Calculation Periods along with the first regular cycle |
Description: |
A CatchUp Policy Calculation Periods can be seen as a Policy Calculation Period that starts before the Span Reference Date of the Policy Collection Setting, which is generated because the Policy Collection Setting is starting before the Span Reference Date. The catchUp periods are generated before the start of the Policy Collection Setting, as of the configuration of the Advance Length and Span Reference Date. When there are multiple consecutive Policy Collection Settings, this results in Policy Calculation Periods being generated for a consecutive Collection Setting, whereas Policy Calculation Periods for the previous Collection Setting are not generated yet and this causing gaps. |
|||
Resolution: |
CatchUp periods will be generated along with the Policy Calculation Periods of the first regular cycle, which starts on the Span Reference Date. This changes the calculation date and the pay date of the catchUp periods, as those are based on the first regular cycle. |
|||
35451928 |
3-33221232811 |
POL-12912 |
BP |
Apply Registrations Activity doesn’t select premiums as of reference field on schedule definition |
Description: |
The correct reference date is not picked on schedule definitions. The reason why this happened is because the segment dynamic logic was not executed for ApplyRegistration executed through activities, regardless the value of the ohi.policies.calculate.calculationperiods.dynamiclogic property |
|||
Resolution: |
The segment dynamic logic is now considered for ApplyRegistration executed through activities. |
|||
35432138 |
3-33132676711 |
POL-12885 |
BP |
Pay date was not always in sync with cycle when using forward billing |
Description: |
Consider the next scenario: Collection setting: Span reference date = 25/5/23 Collection setting start date = 24/5/23 Advance length = 1M Collection method with offset for calculation date -1, no offset for pay date Execute next calculation cycles (using forward billing) with calculation input date 2023-06-26, calculation date was set to next cycle: 2023-07-25, but pay date was not: 2023-06-26. This was caused by the fact that calculation date was before the generate up to date (because of the offset of -1), so it moved to the next cycle. Pay date was on the generate up to date (no offset), so it was not moved to the next cycle. This is not according to specs: the calculation date should used whether to determine to go the next cycle or not: "if the calculation date is before the generate up to date, the calculate date and pay date are set to the dates of the subsequent billing cycle which has the calculation date on or after the generate up to date." |
|||
Resolution: |
The determination of the next cycle of pay date is based on the calculation date on or after the generate up to date. |
|||
35433307 |
POL-12891 |
BP |
Not able to update Flex code Definition record |
|
Description: |
Go to Flex Code definition page and click on Edit. Even if no changes are made to the selected record, clicking on Save is not working and getting console error. |
|||
Resolution: |
Able to create and update the Flex code usages in the flex code definition page with no console errors. |
|||