Release Notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.22.1.0.1
This document contains the release notes for Oracle Health Insurance Enterprise Policy Administration Patch 3.22.1.0.1.
Version compatibility: Oracle Health Insurance Enterprise Policy Administration Release 3.22.1.x is only compatible with other Oracle Health Insurance applications release version 3.22.1.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 | Description | Included in Patch |
---|---|---|---|
POL-10396 |
Additional Tier Determination Settings |
Currently, the system determines the policy tier based on the reference date, typically configured to be the 1st of the calendar month. The tier is determined by ever policy enrollment with a policy enrollment product for the tiered product that is active on the 1st. This enhancement introduces more granular settings that support the following use case where Members that were added to the policy on or after a configured day of the month, do not count towards that month’s tier determination Members that were termed on the policy on or before a configured day of the month, do not count towards that months tier determination |
3.21.2.0.10 |
POL-10400 |
Enable Parameters for Multiple Currencies |
This enhancement removes the restriction that all amount parameters, such as co-payments and deductibles, that are linked to an enrollment product, have to be of the same currency. The enrollment product field that controls the currency is removed. |
|
POL-9791 |
Introduced a new create policy mutation flag on registrations which forces the process registration long running process to create a policy mutation of type re-calculation |
Introduce a new control feature for the Process Registrations long running process to force recalculation. This is achieved by: - Adding a new indicator on the registration entity that indicates if a policy mutation is to be created - If the flag is set to Y, create a policy mutation of type recalculation even when the payment is processed for the expected date and for the expected amount |
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.template
and name itohi_install.cfg
. -
Edit
ohi_install.cfg
to 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
Web Services
Ref | Action | Subject | Description |
---|---|---|---|
POL-10396 |
Modified |
Premium Calculation |
Tier detemination |
POL-11021 |
Modified |
sampleprocessandapplyregistrations IP |
Added new optional header parameter "calculationResults" (boolean), default true. |
POL-11029 |
Modified |
Write Policies IP |
In matching persons and policies on identifiers in write policies IP, the check on access restrictions on those identifiers is omitted. |
POL-9791 |
Modified |
Registration Import IP |
Added optional attribute createPolicyMutation to Registration |
POL-9791 |
Modified |
registrations API |
added optional attribute createPolicyMutation |
UI Changes
Ref | Action | Subject | Description |
---|---|---|---|
POL-10400 |
Modified |
Enrollment Product |
Removed parameter currency from Enrollment Product section. Added a dropdown for 'type' in Parameters tab. |
POL-9791 |
Added |
Create Policy Mutation Flag |
Added a field within registrations page dropdown to indicate whether a Policy Mutation will be Created |
Breaking Changes
Ref | Action | Subject | Description |
---|---|---|---|
POL-10400 |
Modified |
Enrollment Product |
Deleted column for parameter currency |
Bug Fixes
BugDB | SR | Internal | BP | Summary |
---|---|---|---|---|
34200860 |
3-29031085021 |
POL-10654 |
BP |
Clearing of a defaulted value is not listing the flex codes again |
Description: |
Currently clearing of a defaulted value is not listing the values again. The list is showing only when we type at least one space. Need to get list when user clears the defaulted value. |
|||
Resolution: |
Clearing a defaulted value from reference type field (lov) will list all the flex codes again. |
|||
34186449 |
3-28415594371 |
POL-10633 |
BP |
Enrollment product is displaying multiple times when the group client has multiple group accounts sharing the same enrollment products |
Description: |
If group client has multiple group accounts sharing the same enrollment product, in bill allocations enrollment product drop down shows the same product multiple times. |
|||
Resolution: |
When a group client is associated with many group accounts sharing same enrollment product, the enrollment product dropdown in Bill Allocations tab of Group Clients page now shows unique products |
|||
34299770 |
3-29961023779 |
POL-10812 |
BP |
In a Change Event Rule on Policy/PolicyEnrollment, old entity sometimes contains wrong time-valid dynamic field values. |
Description: |
When a Change Event Rule (which monitors a dynamic field) is invoked, because of multiple changes to that time-valid dynamic field or record, then, the values of the dynamic fields on the old entity (oldPolicyEnrollment/oldPolicy) are equal to those on the new entity, or otherwise incorrect. |
|||
Resolution: |
The dynamic fields of old and new entities are now correctly initialized in the change event dynamic logic. |
|||
34184175 |
POL-10627 |
BP |
In business event rules page, when we create or edit a new business rule, the value sent for "old value empty" and "new vale empty" is null |
|
Description: |
old value empty and new value empty properties by default should set to false |
|||
Resolution: |
In business event rules page when we create or edit a new business rule, default values are set for "old value empty" and "new value empty" |
|||
34179288 |
POL-10611 |
BP |
If Reference Property has default value set for mandatory field, while saving the record, it throws error. |
|
Description: |
If Reference Property has default value set for mandatory field, while saving the record, it throws error. |
|||
Resolution: |
User can now set default value for Reference Property (LOV) and it displays correctly. On click of save, data is successfully saved. |
|||
34186637 |
POL-10635 |
BP |
In the quick search and advanced search components of tab table, the record searched upon gets cleared off after the display of the results |
|
Description: |
Search term is not retained in quick search and advanced search components of tab table. |
|||
Resolution: |
Search term is now retained in quick search and advanced search of tabs after the display of results |
|||
33854700 |
3-28560523701 |
POL-9996 |
BP |
Reversal of a financial transaction which is sent out and marked mandatory is not being picked up by "RUN CALCULATE AND PRODUCE INVOICE" |
Description: |
Reversal of a financial transaction sent out and marked mandatory is not being picked up by "Run Calculate and Produce Invoice" API. |
|||
Resolution: |
The bulking group of the reversal selected will be copied from the next, non-superseded, non-reversed transaction in set. |
|||
34186574 |
POL-10634 |
BP |
For all extensibility pages, when trying to save record which already exist, receiving same error |
|
Description: |
For record defintion page, if trying to create a record which already exist, while saving, its throws Flex Code System error, rather, it should display 'Record Definition' already exists. |
|||
Resolution: |
||||
34317045 |
POL-10886 |
BP |
Policy Enrollment Insurable class remove and replace operation issues for the End Policy scenario |
|
Description: |
Policy Enrollment Insurable class removes and replace operation are not working properly for the End Policy scenario |
|||
Resolution: |
Policy Enrollment Insurable class is removed or replaced during End Policy Operation work properly. |
|||
34178835 |
3-30242166901 |
POL-10607 |
BP |
BP-Reference Property Defaults Do Not Work When Readonly Is Set To True In Create Mode |
Description: |
Reference Property Defaults Do Not Work When Readonly Is Set To True In Create Mode |
|||
Resolution: |
Reference Property defaults work properly now when readonly is set to true in create mode |
|||
34370274 |
3-30005122390 |
POL-10988 |
BP |
Extract failed with "ORA-30036: UNABLE TO EXTEND SEGMENT BY 8 IN UNDO TABLESPACE 'UNDOTBS1' |
Description: |
If a large amount of rows are extracted it will lead to a large amount of inserts on a technical table, causing this error when running the Select Extract Items activity. |
|||
Resolution: |
Added commit of inserts of the technical table per 100000 rows to reduce the risk of running into the undo table space error. |
|||
34401539 |
3-30069731281 |
POL-11021 |
BP |
Add support to disable showing calculation results in the Sampleprocessandapplyregistrations IP response |
Description: |
In use cases, the response containing the date paid to will be enough. A new, optional, header parameter called "calculationResults" is added (boolean, default value: true). In case it is false, results are not included in the response. |
|||
Resolution: |
||||
34407948 |
POL-11029 |
BP |
When policies are loaded in batch and match is made on identifiers, it should not include the check on access restrictions |
|
Description: |
For both policies and relations: if a match cannot be made on code, it tries to match the identifier the user has access to. But, since write policies IP starts an activity to process the policies, the user will be system user which does not have access restrictions. |
|||
Resolution: |
In matching persons and policies on identifiers in write policies IP, the check on access restrictions on those identifiers is omitted. When multiple identifiers match, please make sure to use the policyIdentifierType in the request payload for the long running operation, to get a proper matching on policy. (and same for persons in the policy in payload, use identifierTypeCode). |
|||
34257239 |
3-30241807411 |
POL-10740 |
BP |
The option to select type of schedule definition while creation, is available only once per user session |
Description: |
The option to select type of schedule definition is shown only for the first time of it’s use. After selecting one type, coming back to the search page does not list all the options that were present initially. |
|||
Resolution: |
The different options for creating schedule definition are present even after a particular type is selected and then search page is accessed again. |
|||
34427717 |
3-30153163811 |
POL-11044 |
BP |
Updates to relation identifiers from relationidentifiers API are not replicated |
Description: |
When making an update to Relation Identifier using the Person In API or Integration Point, this change will create a Source Replication Event, and will be replicated to the target system using the Data Replication mechanism, as expected. However, when updating the relation identifier directly via the relationidentifiers API, no Source Replication Events are created, so this changes won’t be replicated to the target system. |
|||
Resolution: |
Updates to Relation Identifier directly via the generic relationidentifiers API will correctly create Source Replication Events, to replicate data to the target system. |
|||
34389936 |
3-29771901483 |
POL-11011 |
BP |
Accept header too large error for policies page. |
Description: |
Accept header size increases every time you reopen a policy or open a different policy. |
|||
Resolution: |
Accept header size remains the same even if the policy is reopened or a different policy is opened. |
|||
34464017 |
3-30262971031 |
POL-11114 |
BP |
RuntimeException: CANNOT DIVIDE BY 0, is thrown during Premium Calculation |
Description: |
This can occur when the intermediate adjustments deducted the premium amount to zero amount which in turn was used to calculate the next adjustment. |
|||
Resolution: |
No RuntimeException: CANNOT DIVIDE BY 0 is thrown during Premium Calculation |
|||
34322109 |
3-29943391705 |
POL-10911 |
BP |
Calculating Premium with Tiered Premium Schedule results in NoSuchElementException |
Description: |
During policy processing, the system checks all eligible Policy Enrollment Products per Premium Schedule per Calculation Period. If the Partial Period Resolution is set to SplitPeriods, the Policy Enrollment Products that start after the threshold (or end before) are not included for PremiumTier determination. When, for a specific Period, all Policy Enrollment Products start after the threshold, but within the same period, a NoSuchElementException is thrown. The same argument holds when all Policy Enrollment Products end before the threshold, but still within the same period |
|||
Resolution: |
For a specific Calculation Period, if all the Policy Enrollment Products start after the threshold (or end before), the tiered premium schedule is not considered during premium calculation for that period. |
|||
34344146 |
3-29942984031 |
POL-10940 |
BP |
Tier based Premium Calculation with Split Periods takes threshold date based on Calculation Period Segment instead of Calculation Period |
Description: |
For tier based premium calculation, the system determines the threshold date based on the configured threshold. This date indicates a specific moment in a calculation period when an enrollment should be 'active' to be included in tier determination. This threshold date should be determined based on the start date of the Calculation Period, not based on the start date of the Calculation Period Segment. |
|||
Resolution: |
The threshold date is now calculated based on the Calculation Period start date. |