Finalize Claim
This part of the flow describes what happens to a claim when it is finalized or refinalized. Before the application finalizes a claim, it first makes sure that the calculated results have not been invalidated in the time period between the calculation and finalization. This check precludes a situation where two claims, concurrently processed, fail to see each others results and therefore overtake for example a deductible. The flow for finalizing a claim is schematically depicted by the following figure:
Level 2: Finalize
Detecting concurrent use is part of the "optimistic locking" mechanism that Claims uses to prevent claims from exceeding limits and creating identical overlapping cases. In this context, optimistic means that Claims assumes that no other claims will use the counter, leaving the counter accessible to other claims, and validating the truth of this assumption at the end of the flow. The downside to this approach is, in the event of concurrent use, a claim is processed twice. The merit of this approach is that counters do not need to be locked. The implication of locking counters would be that if a claim stops being processed after locking a counter (for example the claim pends) then all other claims for the same person, family or object, that need to use the same counter, would be waiting for that counter to unlock.
Consider a scenario where two claims both count towards a deductible. Only $50 is left in the deductible. Both claims count towards the deductible for more than $50. The benefits for both claims are calculated at the same time. If there would be no check before finalization, then both claims would take $50 deductible, that is, a total of $100 deductible, while there was only $50 left to take.
Keep in mind that all process steps in the level 2: finalize flow are part of a single transaction; either all steps execute successfully or no steps execute at all. This prevents, for example, that a claim has finalized its consumption but does not get the finalized status because it gets stuck on a runtime error in an enhancement scenario.
Note that during finalization the indChangedInUi is reset (set to null). This indicator (on claim header) is set to the value Yes when a claim is changed in the Manual Change page after finalization; it needs to be reset when the claim finalizes again.
Detect Concurrent Use for Pricing
This step needs only to be executed when the claim is marked for internal pricing. During internal pricing, in the 'Select and Apply Reimbursement Methods and Pricing Rules' one of the substeps is the select and apply of provider limit rules. Consumption is calculated based on the provider limit counters at that moment in time. Another substep is the select and apply of combination adjustment rules. Marking a claim line as primary or secondary takes into account the approved claim lines of finalized claim lines at that time for the same combination adjustment rule, information which is also stored by means of a counter.
The first step in finalization of a claim is to see whether those counters have not been changed by any other claim since then. Note that this optimistic locking strategy is not necessary for:
-
Claims with a checked Ignore History indicator, because there is no risk of two claims addressing the same counter; this holds true for both the provider limit counter and the combination adjustment counter.
-
Claim lines with a checked Keep Pricing indicator
-
Claim lines with a checked Keep Benefits indicator
-
Claim lines with a skip tag for allowed
-
Claim lines that have preliminary provider limit consumptions with a checked Ignored indicator
-
Clam lines that are locked (with a checked Locked indicator)
Therefore, the version which was used during the calculation is compared to the current version on the counter. Two outcomes are possible:
-
No concurrent use for pricing
The versions are the same, that is, no other claims have touched the counter used by the claim.
-
Concurrent use for pricing
The versions are different, that is, during the time that it took this claim to calculate the pricing rules and reach the finalization step, another claim that used the same counter has either finalized for pricing or finalized. As a consequence the application of reimbursement methods and pricing rules needs to be reevaluated based on the updated counters (see section below).
Recalculate Pricing
The following [pricing/../] substeps are executed in this step:
-
Clean Up Pricing Results
-
This substep is identical to the one described in Clean Up Pricing Results, except that the messages with origin PRICING NO RECALCULATION are not removed
-
-
Select and Apply Reimbursement Methods and Pricing Rules
-
This substep is identical to the one described in Select and Apply Reimbursement Method and Pricing Rules with the following exceptions:
-
Replacement Rules are neither selected nor applied
-
During the evaluation of Pricing External Intervention Rules, if the pend reason history indicates that the same pend reason (regardless of the reattach indicator) has been previously attached on the same level (claim, bill or line) in the most recent iteration of the claims flow (that is the steps that are executed after the claim’s most recent Finalized status), then the pend reason is not attached and the claim will not pend because of this external intervention rule.
-
-
-
Evaluate External Intervention Rules
-
This step is identical to the one described in [pricing/../], with the following exception: if the pend reason history indicates that the same pend reason (regardless of the reattach indicator) has been previously attached on the same level (claim, bill or line) in the most recent iteration of the claims flow (that is the steps that are executed after the claim’s most recent Finalized status), then the pend reason is not attached and the claim will not pend because of this external intervention rule
-
-
End Pricing Derivation Rules
-
Pricing Done
Pricing Re-adjudicate Claim
This step is identical to the one described in Pricing Adjudication, with the following exception regarding the evaluation of external intervention rules: if the pend reason history indicates that the same pend reason (regardless of the reattach indicator) has been previously attached on the same level (claim, bill or line) in the most recent iteration of the claims flow (that is the steps that are executed after the claim’s most recent Finalized status), then the pend reason is not attached and the claim will not pend because of this external intervention rule.
Derive Benefits Input Amount
Because the recalculated allowed amount can differ from the one before, the benefits input amount needs to be calculated again. This is done by executing the Process Field Derivation Rule for the benefits input amount. After that, the flow is exactly the same as if a concurrent use for benefits is detected.
Detect Concurrent Use for Benefits
In the benefits step the coverage is calculated based on the counters and cases at that moment in time. The first step in finalizing a claim is to see whether those counters and cases have not been changed by any other claim since then.
For authorization, adjudication limit and regime counters, consumption is calculated based on the counters at that moment in time. Earlier in the process, during the calculation of the benefit, the counter version has been stored on the consumption. The stored version is compared to the current version on the counter (note that this is not performed for claim lines with a checked Keep Benefits indicator and locked claim lines). Two outcomes are possible:
-
The versions are the same, that is, no other claims have touched the counter used by the claim. The claim continues towards the check for an overlapping case.
-
The versions are different, that is, during the time that it took this claim to calculate its benefits and reach the finalization step, another claim that used the same counter has finalized. As a consequence the benefits of the current claim need to be recalculated based on the updated counters (see section below).
Recalculate Benefits
All substeps as specified in Benefits are executed in this step; the differences with the normal flow are described below.
The evaluation of the external intervention rules is performed differently: checking if the same pend reason has been previously attached is only performed for the pend reasons that are attached (regardless of the reattach indicator) in the most recent iteration of the claims flow (that is the steps that are executed after the claim’s most recent Finalized status).
If the claim caused the creation of a new case, then Claims attempts to find a finalized case for the same person or object, the same case definition and an overlapping time period. Two outcomes are possible:
-
No such case exists, that is, no other claims have created primary lines for the same case. The claim continues towards the selection of an enhancement scenario.
-
Such a case exists, that is, during the time that it took this claim to calculate its benefits and reach the finalization step, another claim that has created an identical case has finalized. As a consequence the benefits of the current claim need to be recalculated, taking into account the existing case. If the Keep Benefits indicator is checked for the relating claim line, or if the relating claim line was manually denied, then no recalculation will take place, but the following message is attached to the claim line instead:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-006 |
Informative |
An overlapping adjudication case was detected for claim line {code} of claim {code} that could not be resolved |
It is possible that a claim created more than one case. In this event, the check is executed per newly created case. If a claim has not created any cases, then the check is not executed at all.
Re-adjudicate Claim
The following Adjudication substeps are executed in this step:
-
Evaluate External Intervention Rules
-
This step is identical to the one described in Adjudication, with the following exception: if the pend reason history indicates that the same pend reason (regardless of the reattach indicator) has been previously attached on the same level (claim, bill or line) in the most recent iteration of the claims flow (that is the steps that are executed after the claim’s most recent Finalized status), then the pend reason is not attached, and the claim will not pend because of this external intervention rule
-
-
Set Claim and Claim Line Status
Record Consumption and Case Details
Any consumption that is marked for reversal is reversed. To understand why it is reversed as the first step of re finalizing the claim rather than directly after unfinalizing the claim, consider the following scenario:
A deductible is applied to claim 1 up to the deductible limit. Claim 1 is unfinalized. If the deductible consumption would be reversed during unfinalize the deductible would be open again, and the following undesirable situation would occur:
-
Claim 2 is processed. The deductible that was applied to claim 1 is nowapplied to claim 2. The deductible is again met, but now by claim 2.
-
Claim 1 is refinalized. No deductible is applied to claim 1, because the deductible was met on claim 2.
Any consumption that is not marked for reversal remains untouched. Subsequently, any preliminary consumption (recorded during the current flow) for a claim or a reservation claim with an unchecked Ignore indicator is finalized. The counter version is incremented by 1. This has the following effects:
-
the counter consumption becomes visible to other claims
-
adjudication limit consumption also becomes visible to the counters integration point
-
-
the increment of the version forces other claims (that have concurrently used the same counter) to recalculate
The case details (claim lines attached to new or existing cases) are written as final.
Write CTR and Financial Transaction
First, the transaction scenario that is applicable, is selected. If no transaction scenario can be found, a fatal message is issued:
| Code | Sev | Text |
|---|---|---|
GEN-PROC-003 |
Fatal |
No applicable CTR transaction scenario found for claim with code {0} and id {1} |
The transaction scenario is then applied which produces a version of the claim which is referred to as a claim transaction plus a series of details.
The dynamic logic functions to create the claim transaction and its details are applied. The dynamic logic functions to create the financial transactions and its details are always applied for a claim with process type 'Claim'. For the reservation and quote claims these dynamic logic functions are applied based on the settings of their respective (financial) system property. It is possible to configure the property for each of the process types - Quotes and Reservation - whether to create financial data or not. By default this property is set to 'Yes' for Reservations and 'No' for Quotes. For more details on system property refer Installation Guide.
The details of these dynamic functions are described in the "Claims Transaction Repository" section of the Overview page in the Data Model chapter of the Operations Guide. The outcome is a claim transaction with underlying details which is stored in the Claims Transaction Repository.
In addition, the application creates an external claims data record referencing the claim transaction. There is an option to create this external claims data record within the transaction scenario, so that values on the record can be set as part of the dynamic logic.
It is possible that the dynamic logic is set up in such a way that within one financial transaction there are one or more payable financial transaction details with different currencies. This situation can not be handled in further financial processing, so if this occurs a fatal message is attached:
| Code | Sev | Text |
|---|---|---|
CLA-FL-FINA-001 |
Fatal |
A financial transaction can not have payable details in different currencies |
In a multi-currency environment, the benefit currency (in which the coverages and withholds are stored) could differ from the payment currency. Before creation of the financial transaction details, the application detects if it has to convert the currency into another currency, by checking if a there is a function dynamic logic with the signature 'Currency Conversion (Payment)'.
If such a function dynamic logic exists, it will do the conversion as specified in the function. If the function does not find an exchange rate, technical error GEN-CURR-002 is thrown (see the "Dynamic Logic" chapter of the Developer Guide for more information).
Note that the application accepts the situation in which a financial transaction includes receivable details that are of another currency. This makes it possible to create receivable details that are directed towards for re-insurers or members (which have no relation to the payment currency) within the same financial transaction.
Reinsurance
If re-insurance applies then the application will also create financial transaction details that represent invoices directed towards one or more re-insurers.
Whether reinsurance applies is determined per claim line coverage and depends on whether the applied coverage benefit specification has a reinsurance parameter alias code assigned to it and on whether a reinsurance percentage was communicated in the enrollment response (as a policy product parameter).
Release Financial Holds
All claim transaction level financial holds on previous versions of claim transactions for the same claim and claim level financial holds that have the 'Auto release on new version' attribute set to Yes and have status Active are released when the new claim transaction is created.
The effect of releasing the holds are:
-
The Release Datetime of the active hold is set to the date and time the claim is finalized
-
Released By is set to the user that finalizes the claim