Unfinalize

A claim with the Finalized status can brought back to Change status, using the unfinalize operation_.

The attribute Process Category on the claims entity categorizes the claim as a Regular Claim, Large Claim System, or Sub-Claim.

  • If the value of the attribute Process Category is`L` or S, the claim is classified as a Large Claim System or Sub-Claim, respectively.

  • If the value of the attribute Process Category is NULL, then the claim is classified as a Regular Claim.

The unfinalize operation works in distinct ways when performed on a Large Claim or Regular/Sub-Claim, as explained in the following section.

Unfinalize Regular Claim or Sub-Claim

Pricing finalized and Finalized claims (process category not set to large claim system) can brought back to the Change status by the synchronous unfinalize operation. The steps to unfinalize are described in Unfinalize Claim.

When a claim is either in the status Finalized or Pricing Finalized and the claim is not settled, an unfinalize link is added to the claim resource:

   ... claim properties ...
 "links": [
    {
      "href": "http://[hostName]:[portNumber]/[api-context-root]/generic/claims/{id}",
      "rel": "self"
    },
    {
      "href": "http://[hostName]:[portNumber]/[api-context-root]/claims/{id}/unfinalize",
      "rel": "claim:unfinalize",
      "httpMethod": "POST"
    }
  ]
}

Clients must send one or more claim unfinalize reasons in the POST payload:

{
  "claimunfinalizeReasonList": [
  {
    "sourceReference": "<source reference value>",
    "unfinalizeReason": {
      "id": "<id of unfinalize reason>"
    }
  },
  {
    "unfinalizeReason": {
      "code": "<code of 2nd unfinalize reason>"
    }
  }  {
    "unfinalizeReason": {
      "id": "<id of 3rd unfinalize reason>"
    }
  }]
}

In the example, two unfinalize reasons are passed as parameters. A minimum of one is necessary, while more are feasible. Without an unfinalize reason, the following response is returned:

HTTP Status 400 (Bad Request) with the message CLA-CLUR-002: "To unfinalize a claim, you must enter at least one unfinalize reason".

  • The unfinalize reasons can be identified by their id or code attribute. If both are specified, the id is used to find the unfinalize reason.

  • This operation also supports the data that is sent for unfinalize reasons from the dynamic fields.

  • This unfinalize operation on a sub-claim can be performed only when the large claim status is in the In Process.

  • To unfinalize a sub-claim when the large claim status is in the Manual Adjudication, use the Back to In Process operation to bring the large claim back to In Process status, and then the sub-claim can be unfinalized.

  • To unfinalize a sub-claim when the large claim status is in the Finalized, use the Unfinalize Large Claim operation.

Unfinalize reasons are always protected by access restrictions. HTTP API operations enforce those access restrictions:

  • HTTP status 403 is returned if the current user does not have access rights for all the unfinalize reasons in the payload. The error specified in the Unfinalize Claim for missing access grant on the unfinalize reason has also been returned.

  • If any rights are missing, no change is made at all to the claim or any of its details. The unfinalize reasons in the payload will replace possibly existing unfinalize reasons for the claim. HTTP Status 200 is returned together with a representation of the claim resource (which is now in status Change).

Authorization

A user authorization configuration protects access to this feature. The relevant access restriction is claims.unfinalize IP.

A grant must be given with the Read and Update flag set.

Response Message

Success

HTTP 200 OK is returned.

Failure
Response Description

HTTP 401

Unauthorized

HTTP 404

Claim is unknown.

HTTP 406

Cannot unfinalize a sub-claim as the linked Large Claim status is not in In Process.

HTTP 409

Claim is not in a status that allows unfinalize.

See Response Messages for more details.

Unfinalize Large Claim

Finalized claims (process category is set to large claim system) can be brought back to In Process status by the asynchronous unfinalize operation. This long-running operation unfinalize integration point supports unfinalize a large claim that has been finalized.

When a large claim is in the status Finalized and the claim is not settled, an unfinalize link is added to the claim resource:

   ... claim properties ...
 "links": [
    {
      "href": "http://[hostName]:[portNumber]/[api-context-root]/claims/{id}/unfinalizelargeclaim",
      "rel": "claim:unfinalizelargeclaim",
      "httpMethod": "POST"
    }
  ]
}

Similar to the unfinalization online operation, clients must send one or more claim unfinalize reasons with its dynamic data in the POST payload. In addition, like the synchronous IP, this IP also enforces those access restrictions around Unfinalize reasons.

A successful unfinalize operation on a Large Claim brings the following:

  • The Large Claim to status In Process

  • All the Sub-Claims to status Change.

The operation requires all the sub-claims and the large claim to be unfinalized successfully.

  • In case the activity fails then user can navigate to the response header to view the activity status and can restart the activity.

The steps to unfinalize are described in Unfinalize Large Claim.

Authorization

A user authorization configuration protects access to this feature. The relevant access restriction is claims.largeclaimUnfinalize IP.

A grant must be given with the Read and Update flag set.

Response Message

The link to the activity is given in the response header.

Success

HTTP 201 Created with operator and monitor links.

Failure
Response Description

HTTP 401

Unauthorized

CLA_IP_UNLC_001

Claim is unknown.

CLA_IP_UNLC_002

Claim is not in a status that allows unfinalize.

CLA_IP_UNLC_003

The process category of the claim is not Large Claim

See Response Messages for more details.