Large Claims Flow

This guide clarifies the steps in the large claims process. On this page, a claim refers to a large claim.

The large claim flow is schematically depicted in the following figure:

The status of a large claim indicates where it is in the claims flow. Only one status can be applied to a large claim at once. The following large claim statuses exist:

Table 1. Flow Overview
Status	Description
Entry	If all the Sub-Claims are in the status ENTRY, then the large claim will be in status ENTRY.
In-process	For the In Process status of the large claim, a sub-claim can be in any of the following status: CHANGE INITIAL SENT OUT FOR PREPROCESSING SENT OUT FOR PRICING MANUAL PRICING PRICING DONE MANUAL PRICING ADJUDICATION PRICING ADJUDICATION DONE PRICING FINALIZED MANUAL BENEFITS BENEFITS DONE MANUAL ADJUDICATION ADJUDICATION DONE FINALIZED
Manual Adjudication	If all the Sub-Claims are in the status FINALIZED, then the large claim will be in MANUAL ADJUDICATION status. A large claim attains this status when it pends due to a configured external intervention rule(s). This results in the suspension of the large claim process. A manual intervention of acceptance or rejection of the claim is required.
Finalized	If all the Sub-Claims are in the status FINALIZED, then the large claim will be in FINALIZED status. The large claim is processed, and the claim results are now visible to other claims.

The system does not restrict the manual entry of large claims.

Large Claim Submit

A large claim may be a newly filed claim or one that is in the manual adjudication or in-process stages at the time of submission. In the event of a submission failure, the system will provide an activity link.

New Claims

Claims can be electronically submitted using the claimsimport integration point.

Existing Claims

This is also the place where claims fields can be modified, as it is the initial stage of processing a claim. For instance, a claim that has been pending for manual action can need to have a field updated before it can be resubmitted. The claim is brought back to the beginning of the flow in order to implement that change. Additionally, un-finalizing a claim indicates that it is subject to revision and that, in order to be finalized again, it must go through the whole processing sequence.

Let us look into the following example scenarios to understand how the Submit works:

Scenario 1: Submit a Large Claim with No Changelog

The large claim is in In-Process status.
The request includes selected sub-claims.

Only the selected sub-claims are submitted on Submit.

Scenario 2: Submit a Large Claim with a Changelog on the Large Claim Header

The large claim is in In-Process status.
The request includes selected sub-claims.

In this scenario, the system selects every sub-claim, regardless of which sub-claims are selected. The sub-claims are all brought back to status CHANGE by the system. Sub-claims that have reached the finalized processing status are all un-finalized and returned to status CHANGE. An un-finalized reason for submission must be included with the large claim. The user must enter an un-finalized reason via the user interface before submitting; otherwise, a warning message will be displayed. Once every sub-claim is in the CHANGE status, the change log is applied to them in ascending order of creation date and time, and then the submit process occurs.

Scenario 3: Submit a Large Claim where any of the Sub-Claim is in Error Status with No Changelog.

The large claim is in In-Process status.
The request includes selected sub-claims (any error).

In this scenario only the errored sub-claims from the list are re-processed.

Scenario 4: Submit a Large Claim where none of the Sub-Claim is in Error Status and there is No Changelog.

The large claim is in In-Process status.
The request includes selected sub-claims (any error).

In this scenario the flow moves to the sub-claims processing step.

Scenario 5: Submit a Large Claim where any of the Sub-Claim is in Error Status and there is Changelog.

The large claim is in In-Process status.
The request includes selected sub-claims (no error).

In this scenario, submit returns a _Business Error - CLA-IP-SUBLC-001 - A Large Claim cannot be submitted as one or more sub-claims have processing errors. See Submit a Large Claim For Processing for more details.

Routing Slips do not apply to large claims.

Workflow IP: Task Done (Large Claim)

This step is not relevant for newly submitted large claims. This is applicable for a large claim with the status Manual Adjudication or In-process. The workflow integration point initiates a <task> event to inform the workflow management system that the preceding task has been completed.

Remove Resolve Pend Reasons (Large Claim)

This step is not relevant for newly submitted large claims or large claims that are in the In-process status. All resolved pend reasons are removed from a claim while it is in the Manual Adjudication status. Note that these pend reasons are retained in the pend reason history.

Change-Log processing

When the large claim is saved, the changes made to the large claim header are stored in a changelog. These are the changes to fixed fields, dynamic fields, and sub-entities such as messages, except changes to claim pend reasons.

When a large claim is submitted, if there are changes stored in the changelog, the system will apply these changes to the sub-claims:

The system will
- Unfinalize all finalized sub-claims and bring these back to the status CHANGE.
- Bring all sub-claims with a status other than finalized back to the status CHANGE.
- Apply the most recent changelog to all sub-claims.
- Proceed to the flow’s next step (sub-claims processing).

The system will start processing change logs only when a large claim is submitted and if there are no sub-claims in an error status.

Sub-Claims Processing

In this step, all the sub-claims are processed. Processing large claims pauses until every sub-claim reaches an end status.

In the event that a sub-claim finalizes, the system puts a claim transaction repository (CTR) hold on it. The system handles the application of a CTR hold. The hold type is system type (FIN_FHTP_CLA_001). It is not possible to update or delete the system-type financial hold; however, it can be used. The system automatically releases the CTR holds that were seeded upon large claim finalization.
If any sub-claim encounters a processing error, the user must resolve the error as a regular claim process. The large claim continues to be in the IN-PROCESS status.
If any sub-claim is pend, a workflow event is sent for all of the pended sub-claims as a single event at the large claim level when the pend reason has the publish indication checked.
The following section provides a detailed explanation of workflow event notification.
If all sub-claims are finalized, CTR and financial transactions for sub-claims are regular claims, and the LARGE CLAIM PRE-FINALIZATION checks begin.

When the sub-level claim gets un-finalized, the large claim status is updated to In Process.

Workflow

Suppose any of the sub-claims remain un-finalized due to pends. In that case, the workflow integration point will initiate a <task> event to alert the workflow management system to the availability of a new task at the large claim level. The Fields dynamic logic is invoked for every sub-claim, including the claim lines with publish.

If a claim has more than one pend reason, then for each unresolved pend reason (with a checked publish? indicator).

At the claim level, the Claim fields function is applied to large claim and sub-claims as a regular claim.
At the claim line level, the Claim line fields function and the Claim fields function are applied. The claim here refers to a sub-claim.

The workflow event notification is handled at the large claim level for large claim and sub-claims. See Claims Workflow Integration Point (Fixed Payload) and Claims Workflow Integration Point (Configurable Payload) for changes related to Large Claim.

Large Claim Pre-Finalized Checks

As soon as every sub-claim has been finalized, the large claim pre-finalization checks start. Pre Finalized Derivation Rules and External Intervention Rules are executed at the level of the large claim header as part of this.

Pre-Finalized Derivation Rules

A derivation rule sets the value of specific fields on a claim. There are two types of derivation rules:

Dynamic and native fields.
Process fields.

At this point in the flow, derivation rules are executed for which the step field has the value pre finalization (large claim), and the claim level has the value Large claim, which means no process field derivation rules.

Pre finalization derivation rules are evaluated even if a fatal message is attached to the claim. If multiple derivation rules exist, they are executed in the order of the configured sequence (sequence null is evaluated last).

External Intervention Rules (Large Claim)

This step involves the evaluation of all external intervention rules for the claim types Large Claim and Manual Adjudication subtypes. If the large claim successfully meets all the criteria set by the rule, then the rule is triggered.

For each triggered external intervention rule, the specified pend reason is checked: Suppose the re-attach indicator is unchecked, and the pend reason history indicates that the same pend reason has been previously attached on the same level (large claim). In that case, the pend reason is not attached, and the claim will not pend because of this external intervention rule. Otherwise, the specified pend reason is attached to the large claim and added to the claim pend reason history.

The claim moves on to the Large Claim Finalization step if the external intervention rule review results in no pending reasons. In the absence of such, MANUAL ADJUDICATION is the claim status. For additional information on configuring external intervention rules, see Claims Flow chapter in the Operations Guide.

Manual Adjudication

This step filters out large claim that require manual review. Claims that require manual review are pended by executing the external intervention. The large claim pends if it meets the conditions set by at least one of the external intervention rules.

If the large claim has at least one pend reason with a checked publish message indicator, the workflow integration point sends out a <task> event to notify a workflow management system that a new task is ready. The event contains all pending reasons that are configured to be published. For more detail, see the chapter on the workflow integration point in the implementation guide on claims flow configuration.

The assumption is that the external workflow management system assigns a manual adjudication task to a user. The user can choose to perform one of the following actions:

Accept – the way Claims processed the claim.
Deny - entire claim
Change – large claim is brought back to In Process status

If the large claim has at least one pend reason with a checked publish message indicator, then the workflow integration point sends out a <task> event to notify a workflow management system that a new task is ready. The event contains all pending reasons that are configured to be published. For more detail, see the chapter on the workflow integration point in the implementation guide on claims flow configuration.

The assumption is that the external workflow management system assigns a manual adjudication task to a user. The user can choose to perform one of the following actions:

Accept the large claim as processed by the Claims application.
Deny the large claim.
Revert to a status that makes it possible to change the claim.

Change Claim

The large claim returns to the "In Process" status when the claim is changed. Triggering the change log happens when the header is updated and submitted.

Accept Claim

On Accept user action, with no pend reasons remaining, the following happens.

1) Workflow IP: Task Done

2) Remove resolved the pend reasons

3) Large claim is finalized

Deny Claim

Denial is the presence of a fatal message on the large claim. A fatal message added by a user to a large claim and then submitting the claim propagates to all the sub-claims, which are then submitted but eventually get denied due to the fatal message on the large claim header.

On Deny user action, with no pend reasons remaining, the following happens.

1) Workflow IP: Task Done

2) Remove all the pend reasons

3) Apply the Change Log

4) Both large claim and sub-claims are finalized

NOTE: For more details on Adding a Fatal Message see Adding a Fatal Claim Message.

Submitting Claim

When the claim is submitted, it is brought back to the beginning of the flow in order to implement that change.

Claim Event Rules (Large Claim Status: Manual Adjudication)

The system evaluates the Claim Event Rules for a large claim. Depending on how the Claim Event Rules are configured for large claims, this may lead to the generation of one or more Claim Events. The Claim Event Rule applies to a large claim in the Manual Adjudication and Finalized statuses.

Large Claim Finalization

A claim attains this status when all the sub-claims have been finalized and passed Adjudication logic. A snapshot of a claim or a claim transaction is kept in the CTR. Note that no financial transaction will be created for a large claim. The application releases the financial hold on the sub-claims CTR transaction that was put in place as part of the sub-claims processing upon the finalization of the large claim.

Finalized claims can be un-finalized through the user interface or an integration point. Un-finalizing a claim means that the claim is open for changes, but the claim will need to go through the entire processing flow in order to be finalized again. When a large claim is un-finalized, then it gets a status In-process, and all the sub-claims are un-finalized and brought back to a status CHANGE.

A user can un-finalize a group of sub-claims without having to un-finalize each sub-claim using a large claim un-finalization.

Mapping Tables

Let us look into the following scenarios to understand how a CTR mapping table works for a large claim:

Consider a large claim that gets finalized the first time, assuming sub-claims 1 and 2 are on version 1 and sub-claim 3 is on version 2. In this scenario, the CTR mapping table holds the following information.

Table 2. CTR Mappings Table
Large claim CTR version 1	Sub-claim 1 Version 1
Large claim CTR version 1	Sub-claim 2 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1R
Large claim CTR version 1	Sub-claim 3 Version 2

Consider the large claim is now un-finalized and re-finalized. In this scenario, when the large claim is un-finalized, all sub-claims also get un-finalized to maintain reversal consistency. In this case, the CTR mapping table holds the following information.

Table 3. CTR Mappings Table
Large claim CTR version 1	Sub-claim 1 Version 1
Large claim CTR version 1	Sub-claim 2 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1
Large claim CTR version 1	Sub-claim 3 Version 1R
Large claim CTR version 1	Sub-claim 3 Version 2
Large claim CTR version 1R	Sub-claim 1 Version 1R
Large claim CTR version 1R	Sub-claim 2 Version 1R
Large claim CTR version 1R	Sub-claim 3 Version 2R
Large claim CTR version 2	Sub-claim 1 Version 2
Large claim CTR version 2	Sub-claim 2 Version 2
Large claim CTR version 2	Sub-claim 3 Version 3

For claims-out response on a large claim, see Claims Out Integration Point for changes related to Large Claim.

Claim Event Rules (Large Claim Status: Finalized)

NOTE: Deleting a large claim or a sub-claim is not supported. Error message CLA-CLAI-056 is returned on delete operation.