Release Notes for Oracle Health Insurance Enterprise Policy Administration Patch 4.23.1.0.8

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

Version compatibility: Oracle Health Insurance Enterprise Policy Administration Release 4.23.1.x is only compatible with other Oracle Health Insurance applications release version 4.23.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	Patch
CPN-3079	Auto purge feature As data volume in Oracle Health Insurance applications continue to grow with the processing of more data, it becomes essential to manage the database efficiently. Oracle Health Insurance applications include various PL/SQL packages for purging processes. However, these processes currently require manual intervention by customer DBAs/AMS team to configure and schedule purge jobs during planned maintenance windows. To streamline this process and automate database maintenance, we are introducing an auto-purge job feature. This feature eliminates the need for manual scheduling of various purge jobs and ensures that data is regularly purged according to predefined criteria. As part of this enhancement, we have a introduced a new PL/SQL package ohi_auto_purge_pkg.purge_all and modified the following functionalities : The structure of the following procedures has been revised, introducing an optional input parameter p_commit_size to enhance flexibility and control over the purging process cla_data_purge_pkg.purge_data ohi_repl_purge_pkg.purge_data Log message purging is now integrated into the auto-purge feature, and as a result, the following HTTP API resources have been made read-only. logeventretentionperiods API loglevelretentionperiods API Purging of PHI logs is now integrated into the auto-purge feature. So, the property ohi.logging.phi.min.retentionperiod is removed The process now integrates purging of all datafile sets into the auto-purge system, eliminating the need for separate scheduled scavenging and purging of incident files. So, the property ohi.incident.datafileset.retentionperiod is removed Oracle recommends frequent and automatic purging of technical data and operational data using the auto-purge job feature. For example, customer DBA/AMS team (in SaaS) can set up auto purge through the use of a DBMS_SCHEDULER job. See the user guide for more details and for a sample SQL script that creates auto purge job using DBMS_SCHEDULER.create_job PL/SQL procedure. Note that the initial purge job might take longer if the volume of the data is very high (for example, if the system has two years of data to purge and if the retention days for technical data are set to 60 days). So, Oracle recommends the DBA/AMS team to set a higher retention period (for example, one year and 11 months) for the initial run (so only 30 days of data is purged in the very first run). The retention days can be reduced gradually until the historical data is purged. Documentation Links: Administration Guide - Purging Data from Technical Tables Administration Guide - Purging Data from Replication Technical Tables Administration Guide - Datafile Set Trace Files Retention Administration Guide - Auto Purge	4.24.1.0.0
POL-12956	Purge data files In Oracle Health Insurance applications, data files generated during various activities (e.g., extract activity, financial messages activity and data files uploaded to initiate long-running operations) remain in the system even after they have been processed/consumed. Currently, there is no mechanism in place to automatically clean up these data files once they have been processed/consumed, leading to inefficiency of the database storage space. This enhancement aims to automate the cleanup process and optimize database storage space. To enable purging data files, we have introduced a new PL/SQL package ohi_purge_datafileset_pkg. Documentation Links: Administration Guide - Purging Data from Data File Sets	4.24.1.0.0
POL-15792	Optimize loading of SVNTV fields into the memory during extracts Currently, the system loads all the Single Value Non-Time Valid(SVNTV) dynamic fields associated with resources into the memory which causes OOM. Only the required SVNTV dynamic fields should be loaded into memory while processing the extracts.	4.23.2.0.9, 4.24.1.0.1
POL-9574	Populating elementId in activity messages (for technical errors) Activity messages have an elementId populated in almost all cases (except for global activities, where, for instance, a message is added, if a parameter is not passed on correctly). That way, it is possible to correlate an error to a policy.	4.24.1.0.0

Summary

Patch

CPN-3079

Auto purge feature

As data volume in Oracle Health Insurance applications continue to grow with the processing of more data, it becomes essential to manage the database efficiently. Oracle Health Insurance applications include various PL/SQL packages for purging processes. However, these processes currently require manual intervention by customer DBAs/AMS team to configure and schedule purge jobs during planned maintenance windows.

To streamline this process and automate database maintenance, we are introducing an auto-purge job feature. This feature eliminates the need for manual scheduling of various purge jobs and ensures that data is regularly purged according to predefined criteria.

As part of this enhancement, we have a introduced a new PL/SQL package ohi_auto_purge_pkg.purge_all and modified the following functionalities :

The structure of the following procedures has been revised, introducing an optional input parameter p_commit_size to enhance flexibility and control over the purging process
- cla_data_purge_pkg.purge_data
- ohi_repl_purge_pkg.purge_data
Log message purging is now integrated into the auto-purge feature, and as a result, the following HTTP API resources have been made read-only.
- logeventretentionperiods API
- loglevelretentionperiods API
Purging of PHI logs is now integrated into the auto-purge feature. So, the property ohi.logging.phi.min.retentionperiod is removed
The process now integrates purging of all datafile sets into the auto-purge system, eliminating the need for separate scheduled scavenging and purging of incident files. So, the property ohi.incident.datafileset.retentionperiod is removed

Oracle recommends frequent and automatic purging of technical data and operational data using the auto-purge job feature. For example, customer DBA/AMS team (in SaaS) can set up auto purge through the use of a DBMS_SCHEDULER job. See the user guide for more details and for a sample SQL script that creates auto purge job using DBMS_SCHEDULER.create_job PL/SQL procedure.

Note that the initial purge job might take longer if the volume of the data is very high (for example, if the system has two years of data to purge and if the retention days for technical data are set to 60 days). So, Oracle recommends the DBA/AMS team to set a higher retention period (for example, one year and 11 months) for the initial run (so only 30 days of data is purged in the very first run). The retention days can be reduced gradually until the historical data is purged.

Documentation Links:
Administration Guide - Purging Data from Technical Tables
Administration Guide - Purging Data from Replication Technical Tables
Administration Guide - Datafile Set Trace Files Retention
Administration Guide - Auto Purge

4.24.1.0.0

POL-12956

Purge data files

In Oracle Health Insurance applications, data files generated during various activities (e.g., extract activity, financial messages activity and data files uploaded to initiate long-running operations) remain in the system even after they have been processed/consumed. Currently, there is no mechanism in place to automatically clean up these data files once they have been processed/consumed, leading to inefficiency of the database storage space.

This enhancement aims to automate the cleanup process and optimize database storage space. To enable purging data files, we have introduced a new PL/SQL package ohi_purge_datafileset_pkg.

Documentation Links:
Administration Guide - Purging Data from Data File Sets

4.24.1.0.0

POL-15792

Optimize loading of SVNTV fields into the memory during extracts

Currently, the system loads all the Single Value Non-Time Valid(SVNTV) dynamic fields associated with resources into the memory which causes OOM. Only the required SVNTV dynamic fields should be loaded into memory while processing the extracts.

4.23.2.0.9, 4.24.1.0.1

POL-9574

Populating elementId in activity messages (for technical errors)

Activity messages have an elementId populated in almost all cases (except for global activities, where, for instance, a message is added, if a parameter is not passed on correctly). That way, it is possible to correlate an error to a policy.

4.24.1.0.0

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 of ohi_install.cfg.template and name it ohi_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:
1. Open a command window and browse to <OHI_ROOT>/util/install.
2. 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

Configuration Properties

Ref	Action	Description
CPN-3079	Removed	ohi.logging.phi.min.retentionperiod Purging of logs is now integrated into the auto-purge feature. So, this property is removed. The default retention for PHI logs with the auto-purge function is 2560 days (7 years) and can be managed through the autopurgemetadata API
CPN-3079	Removed	ohi.incident.datafileset.retentionperiod Purging of all datafile sets is now integrated into the auto-purge system, hence, eliminating the need for separate scheduled scavenging and purging of incident files. So, this property is removed.

Ref

Action

Description

CPN-3079

Removed

ohi.logging.phi.min.retentionperiod

Purging of logs is now integrated into the auto-purge feature. So, this property is removed. The default retention for PHI logs with the auto-purge function is 2560 days (7 years) and can be managed through the autopurgemetadata API

CPN-3079

Removed

ohi.incident.datafileset.retentionperiod

Purging of all datafile sets is now integrated into the auto-purge system, hence, eliminating the need for separate scheduled scavenging and purging of incident files. So, this property is removed.

Web Services

Ref	Action	Description
CPN-3079	Added	autopurgemetadata API Added a new autopurgemetadata API
CPN-3079	Removed	logeventretentionperiods API logeventretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported
CPN-3079	Removed	loglevelretentionperiods API loglevelretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported

Ref

Action

Description

CPN-3079

Added

autopurgemetadata API

Added a new autopurgemetadata API

CPN-3079

Removed

logeventretentionperiods API

logeventretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported

CPN-3079

Removed

loglevelretentionperiods API

loglevelretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported

Data Conversion

This section intentionally left blank.

Dynamic Logic

This section intentionally left blank.

UI Changes

This section intentionally left blank.

Breaking Changes

Ref	Action	Description
CPN-3079	Removed	logeventretentionperiods API logeventretentionperiods API support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature
CPN-3079	Removed	loglevelretentionperiods API loglevelretentionperiods support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature

Ref

Action

Description

CPN-3079

Removed

logeventretentionperiods API

logeventretentionperiods API support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature

CPN-3079

Removed

loglevelretentionperiods API

loglevelretentionperiods support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature

Bug Fixes

BugDB	SR	Internal	Summary
37039410		POL-15807	Include stand alone catchUp periods when running APPLY_REGISTRATIONS activity
Description:	During the APPLY_REGISTRATIONS activity, periods are (re)generated and used to apply registrations. CatchUp periods are defined as periods that start before the reference input date. When the system generates periods, the catchUp periods are only generated in combination with the first regular cycle, which is the period starting on the reference date. If the first regular cycle is not generated, neither are the catchUp periods, causing gaps when the first regular cycle is never generated (for example when the reference date is after the end date of the collection setting).
Resolution:	The Apply Registrations activity does not make a distinction between catchUp periods and regular periods so registrations can be applied to catchUp periods only.
37082016		POL-15910	Global Activities page taking lot of time to retrieve results.
Description:	When a query is performed without any filters on the global activities page, it takes a lot of time to load the search results.
Resolution:	Updated the search criteria for the page to load results only when filters are applied.
37038210		POL-15756	Batch jobs consisting extracts fails when OHI Extract purge runs concurrently
Description:	Policies daily exchange batch job fails when OHI policies extract data file purge is triggered concurrently because foreign key index for foreign key constraint on extract table was missing.
Resolution:	This issue was resolved by adding a foreign key index for the foreign key constraint on the extract table.
37093056		POL-15948	Parameter Amount Value is saved With Default Value instead of zero
Description:	Parameter Amount Value is saved With Default Value when value zero is sent.
Resolution:	Parameter Amount Value is saved with value zero instead of default value
37146964	3-36913840401	POL-16004	Extract requests can have a limited number of characters in the condition
Description:	Extract request with a large query fails with activity message "ORA-06502: PL/SQL: numeric or value error ORA-06512: at line 1". This is because the selection is stored in a variable with a maximum of 32000 characters.
Resolution:	Selection is now stored as a clob of which the maximum size depends on environment settings: (4 GB - 1) * DB_BLOCK_SIZE initialization parameter (8 TB to 128 TB). Contact database administrator for more details if needed. This change allows for a more extensive query in the extract request and a lesser chance of running into the ORA-06502 error.
36943702	3-37715853681	POL-15681	ID of single value flex code is returned as "null" (String) in the generic API response
Description:	ID of single value flex code is returned as "null" (String) in the generic API response.
Resolution:	ID attribute of single value flex code is now excluded from the generic API response
37156542	3-38290956121	POL-16038	Activity remains in IP status as the technical flag for submission isn’t cleared on TE activities
Description:	The activities remain stuck in IP status as the technical flag for submission (TEC_IND_SUBMISSION) flag was not cleared for the parent activities with status TE. These TE activities occupy the entire submission bucket, the size of which is determined by the property ohi.processing.max.concurrentparentactivities.size, which has a default value of 8. If the bucket is full, the newly submitted activity will remain in IP.
Resolution:	The query to fetch the count of currently submitted activity was modified to fix the issue.
37204953		POL-16140	Anomaly in generic patch operation for Time Valid dynamic records
Description:	When performing generic patch operation for a time valid dynamic record to update the endDate, the operation fails, getting a time valid error thrown. In some instances, when updating both startDate and endDate, other dynamic records are getting affected.
Resolution:	Generic patch operation on all resources is isolated from policies in IP patch operation. Apart from this a time validity check is added per dynamic records per resource which resolves the issue.

BugDB

Internal

Summary

37039410

POL-15807

Include stand alone catchUp periods when running APPLY_REGISTRATIONS activity

Description:

During the APPLY_REGISTRATIONS activity, periods are (re)generated and used to apply registrations. CatchUp periods are defined as periods that start before the reference input date. When the system generates periods, the catchUp periods are only generated in combination with the first regular cycle, which is the period starting on the reference date. If the first regular cycle is not generated, neither are the catchUp periods, causing gaps when the first regular cycle is never generated (for example when the reference date is after the end date of the collection setting).

Resolution:

The Apply Registrations activity does not make a distinction between catchUp periods and regular periods so registrations can be applied to catchUp periods only.

37082016

POL-15910

Global Activities page taking lot of time to retrieve results.

Description:

When a query is performed without any filters on the global activities page, it takes a lot of time to load the search results.

Resolution:

Updated the search criteria for the page to load results only when filters are applied.

37038210

POL-15756

Batch jobs consisting extracts fails when OHI Extract purge runs concurrently

Description:

Policies daily exchange batch job fails when OHI policies extract data file purge is triggered concurrently because foreign key index for foreign key constraint on extract table was missing.

Resolution:

This issue was resolved by adding a foreign key index for the foreign key constraint on the extract table.

37093056

POL-15948

Parameter Amount Value is saved With Default Value instead of zero

Description:

Parameter Amount Value is saved With Default Value when value zero is sent.

Resolution:

Parameter Amount Value is saved with value zero instead of default value

37146964

3-36913840401

POL-16004

Extract requests can have a limited number of characters in the condition

Description:

Extract request with a large query fails with activity message "ORA-06502: PL/SQL: numeric or value error ORA-06512: at line 1". This is because the selection is stored in a variable with a maximum of 32000 characters.

Resolution:

Selection is now stored as a clob of which the maximum size depends on environment settings: (4 GB - 1) * DB_BLOCK_SIZE initialization parameter (8 TB to 128 TB). Contact database administrator for more details if needed. This change allows for a more extensive query in the extract request and a lesser chance of running into the ORA-06502 error.

36943702

3-37715853681

POL-15681

ID of single value flex code is returned as "null" (String) in the generic API response

Description:

ID of single value flex code is returned as "null" (String) in the generic API response.

Resolution:

ID attribute of single value flex code is now excluded from the generic API response

37156542

3-38290956121

POL-16038

Activity remains in IP status as the technical flag for submission isn’t cleared on TE activities

Description:

The activities remain stuck in IP status as the technical flag for submission (TEC_IND_SUBMISSION) flag was not cleared for the parent activities with status TE. These TE activities occupy the entire submission bucket, the size of which is determined by the property ohi.processing.max.concurrentparentactivities.size, which has a default value of 8.

If the bucket is full, the newly submitted activity will remain in IP.

Resolution:

The query to fetch the count of currently submitted activity was modified to fix the issue.

37204953

POL-16140

Anomaly in generic patch operation for Time Valid dynamic records

Description:

When performing generic patch operation for a time valid dynamic record to update the endDate, the operation fails, getting a time valid error thrown. In some instances, when updating both startDate and endDate, other dynamic records are getting affected.

Resolution:

Generic patch operation on all resources is isolated from policies in IP patch operation. Apart from this a time validity check is added per dynamic records per resource which resolves the issue.

Issues that were backported in previous Release / Patch

No backports.