Purge Policies

Oracle Health Insurance applications store a significant amount of information. This page describes the integration point that enables the user to purge data from the operational policies tables. The two primary scenarios to use this integration point are to purge information beyond its retention period in a production environment and to reduce the size of non-production environments.

This integration point removes policies and all related details, taking several criteria to control the scope of the purge process. Policies that match on all specified criteria are purged.

Policies that have the Exempt from Purging indicator as Yes on the related attached policy data records are exempt from purging. They do not purge even if they match the specified parameters.

This operation completely removes policies that match the criteria and all of their details from the system. These details include mutations, policy accounts, calculation results, and financial transactions. It doesn’t create reversal transactions, and it doesn’t delete or correct financial messages in which transactions of the deleted policies are included.

The operation supports the deletion of the person’s enrollment from that policy, but it does not remove the person. The same applies to the policyholder; the operation removes the fact that a particular person is (or was) the policyholder of a policy, but it doesn’t remove that person.

The operation described here is long-running. The progress of this operation can be monitored via the links provided in the response returned when the operation is successfully initiated. They are the hypermedia link with rel="monitor" and rel="operator".

See Long-Running Operations section for more information.

Request

This process can initiate with a POST request to the URI:

http://[hostName]:[portNumber]/[api-context-root]/api/purge/policies

This process is a long-running operation initiated through a RESTful web service. The payload for this request contains the selection criteria for the policies to be purged.

The request message has the following structure:

{
    "periodUom": "",
    "periodLength": "",
    "purgeGroupClient": "",
    "groupClientCode": "",
    "groupAccountCode": "",
    "brandCode": "",
    "lineOfBusinessCode": "",
    "commitSize": "",
    "currentDate": ""
}

Table 1. Explanation of Elements in the Request
Parameter	Description
periodUom	This required parameter, together with the period length, specifies the retention period. Specify the unit of measure as D (days), M (months), or Y (years).
periodLength	Required parameter that specifies the length of the retention period.
purgeGroupClient	The `purgeGroupClient` parameter is a boolean parameter that specifies whether to also purge the group client. The system purges the group client only if no policies are associated with any group account that belongs to that group client.
groupClientCode	This optional parameter specifies the group client. Only Policies in the specified group client purge.
groupAccountCode	This optional parameter specifies a group account. If the value unspecified is keyed in (not available in the pick list), the purge only picks up individual policies. Specifying a group client with an unspecified group account value results in no policies being selected. Specifying a group client alongside a group account that is not part of the group client will also result in no policies being selected.
brandCode	This optional parameter specifies the brand. Only Policies with the specified brand (excludes Policies without a specified brand) are purge.
lineOfBusinessCode	This optional parameter specifies the line of business. Only Policies with the specified line of business (excludes Policies without a specified line of business) are purge.
commitSize	This is an optional parameter. A larger commit size improves the performance of the purge long-running operation at the cost of requiring more computing resources and a larger undo tablespace. If unspecified, each table is purged after 5000 statements per table, followed by a commit per table.
currentDate	This is an optional parameter. Use it in test environments only. Calculate the retention period as if today is `currentDate` instead of the system date. This enables purging recent records in test situations.

To optimize performance, purge policies for one group client at a time or purge individual policies separately.

Retention Period

The retention period is derived from the system date. The age of a policy is determined by the latest policy enrollment product end date on the policy. The retention period is at least 30 days.

For example, a retention period of 10 years purges all Policies where the last policy enrollment product is ended 10 years as of the day the user calls this integration point.

Example

The following example purges all policies for the group account GA010 in the group client GC001 that are older than 10 years.

{
    "periodUom": "Y",
    "periodLength": "10",
    "groupClientCode": "GC001",
    "groupAccountCode": "GA010"
}

Response Messages

This service can respond with the following messages:

Table 2. Response Messages
Code	Message
POL-IP-PUPO-001	Invalid number of days: {0}, it should be 30 or more.
POL-IP-PUPO-002	Period length must be a positive number.
POL-IP-PUPO-003	The request must include both Period UoM and Period Length.
POL-IP-PUPO-004	Group Client Code {0} is unknown.
POL-IP-PUPO-005	Group Account Code {0} is unknown.
POL-IP-PUPO-006	Brand Code {0} is unknown.
POL-IP-PUPO-007	Line of Business Code {0}{Code} is unknown.

The system responds with HTTP 201 (Created) and a location header for the policies purge.

Optional: Purge Notification

The purge integration point provides a callback feature to a pre-configured endpoint. This feature provides the following response to the configurable endpoint once the purge triggered by an external system through IP has concluded. The notification structure is as follows. If the endpoint is not configured (generic or specific), the notification is not sent.

Response

<notification correlationId="" workId="{workId}" status="Success/Failure" >
  <links>
    ...
  </links>
</notification>

The generic notification endpoint can be configured via the ohi.purge.notification.endpoint property in the Oracle Health Insurance application’s properties file. The notification endpoint can be overridden for specific purge types, for example, specify property ohi.purge.notification.endpoint.Policies to have the system deliver all notifications for a policies purge to a specific endpoint.

If the notification endpoint is configured using a generic property, all other properties are fetched using the generic PurgeNotificationClient code.

See Outbound Restful Service Invocations for the process and more properties.

Policies Operational Purging

The policy operational purge job is included in Auto Purge (disabled by default). The auto purge process deletes all policies, that meet the configured retention period. The auto-purge process calls the following procedure:

POL_PURGE_POLI_PKG.AUTO_PURGE_POLICIES

The user must manually enable this job to be included in the auto-purge process by changing the enabled attribute through the autopurgemetadata generic API.

Authorization

A user authorization configuration requires access to this feature. The relevant access restriction is purgePolicies IP.