Purging Claims Data
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 claims tables. The two primary scenarios for using this integration point are to purge information that is beyond its retention period on a production environment, and to reduce the size of non-production environments.
This integration point removes claims and all related details, taking a number of criteria to control the scope of the purge process. Claims that match on all specified criteria are purged.
Claims that have the Exempt from Purging indicator as Yes on the related external Claims data records are exempt from purging. They do not purge even if they match the specified parameters.
Note that claims purge regardless of their status. So, purging is also possible for claims that are not in completed status.
The operation described here is a long-running operation. The progress of this operation can be monitored by the links provided in the response that is returned when the operation is successfully initiated. They are the hypermedia link with rel="monitor" and rel="operator".
Long-running operations are described in the "HTTP API/IP Concepts" chapter of the Developer Guide.
Request
This process is started by making a POST request to the URI:
http://[hostName]:[portNumber]/[api-context-root]/api/purge/claimsThis process is a long-running operation initiated through RESTful web service. The payload for this request contains the selection criteria for the claims to be purged.
| A claim with process category 'Sub-Claim' never gets selected for any selected criteria. Rather when a claim with process category 'Large Claim System' gets selected for any selection criteria, then the system automatically purges all the linked 'Sub-claims'. |
The request message has the following structure:
{
"periodUom" : "",
"periodLength" : "",
"includeFinancialData" : "true or false",
"includeLimitConsumptions" : "true or false",
"formCode" : "",
"formTypeCode" : "",
"brandCode" : "",
"claimDynUsageName1" : "",
"claimDynValue1" : "",
"claimDynUsageName2" : "",
"claimDynValue2" : "",
"claimDynUsageName3" : "",
"claimDynValue3" : "",
"extClaimDataDynUsageName" : "",
"extClaimDataDynValue" : "",
"commitSize" : "",
"currentDate" : ""
}| Parameter | Description |
|---|---|
periodUom |
This required parameter specifies, together witch period length, 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 |
includeFinancialData |
This required parameter controls whether financial data is included in the purge process. Note that the base financial objects that resulted from claims that have been purged earlier are also removed regardless of the retention period if this parameter is true. |
includeLimitConsumptions |
This required parameter controls whether the adjudication limit consumptions and provider limit consumptions are included in the purge process. Note that the consumptions that resulted from claims that have been purged earlier are also removed if this parameter is true. |
formCode |
This optional parameter specifies the claims form. Only Claims with the specified form purge. |
formTypeCode |
This optional parameter specifies the Claim form type. Only Claims with the specified form type purge. |
brandCode |
This optional parameter specifies the brand. Only Claims with the specified brand (excludes Claims without a specified brand) purge. |
claimDynUsageName1 |
|
claimDynValue1 |
|
claimDynUsageName2 |
|
claimDynValue2 |
|
claimDynUsageName3 |
|
claimDynValue3 |
|
extClaimDataDynUsageName |
This optional parameter provides the ability to use a dynamic field that is available on the external Claims data table as parameter for the purging process. Only use single-value dynamic fields as parameters. Specifying a dynamic field usage name and value (specify both) purges only Claims that have the specified value for the specified dynamic field on their external claims data record. |
extClaimDataDynValue |
This optional parameter holds the value for the specified extClaimDataDynUsageName (previous parameter). Use the following format for dynamic fields of type date: |
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, 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 |
Retention Period
The retention period is derived from the system date. The age of a claim is determined by the last updated date on the claim header. The retention period is at least 30 days.
For example, a retention period of ten years purges all Claims that have not been updated in 10 years as of the day the user calls this integration point.
Dynamic fields as Selection Criteria
It is possible to specify up to three single-value dynamic fields on the claims table as criteria for the purging process.
Use the following format for dynamic fields of type date: YYYY-MM-DD.
Example
The following example purges all claims with form type code INST and product line (dynamic field on the claims table) HMO that are older than ten years together with their financial data, adjudication limit, and provider limit consumptions.
{
"periodUom" : "Y",
"periodLength" : "10",
"includeFinancialData" : true,
"includeLimitConsumptions" : true,
"formTypeCode : "INST",
"claimDynUsageName1" : "productLine",
"claimDynValue1" : "HMO"
}Response Messages
This service can respond with the following messages:
| Code | Message |
|---|---|
CLA-IP-PUCL-001 |
Invalid number of days: {0}, it should be 30 or more |
CLA-IP-PUCL-002 |
Period length must be a positive number |
CLA-IP-PUCL-003 |
The request must include both Period UoM and Period Length |
CLA-IP-PUCL-004 |
Claim Form Code is unknown |
CLA-IP-PUCL-005 |
Claim Form Type Code is unknown |
CLA-IP-PUCL-006 |
Brand Code is unknown |
CLA-IP-PUCL-007 |
Dynamic Field Usage Name {0} is unknown for table {1} |
CLA-IP-PUCL-008 |
Dynamic Field Usage Name and Value must both be provided |
CLA-IP-PUCL-009 |
Include financial data and Include limit consumption are required parameters |
The system responds with HTTP 201 (Created) and a location header for the claims purge.
Optional: Purge Notification
The purge integration point provides a call back 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 structure of notification is as under. If the endpoint is not configured (generic or specific), the notification is not sent.
<notification correlationId="" workId="{workId}" status="Success/Failure" >
<links>
...
</links>
</notification>The generic notification endpoint can be configured as property 'ohi.purge.notification.endpoint' in the Oracle Health Insurance application’s properties file. The notification endpoint can be overridden for specific purge types, e.g. specify property 'ohi.purge.notification.endpoint.Claims' to have the system deliver all notifications for a claims purge to a specific endpoint.
If the notification endpoint is configured on the specific type, all other
properties are also fetched based on the type or else defaults are used.
Similarly, if the endpoint for the notification endpoint is configured using
generic property, then all other properties are fetched on a generic uses
code PurgeNotificationClient. Please see section Outbound RESTful
Service Invocations in the Security Guide for the process and more properties.