Pre Benefit Checks
In this step, the results from the enrollment interface and the payment status interface are available (in contrast to the step Pre Pricing Checks) as well as the results from the pricing. All pre-benefit checks are user defined. That means that if no pre benefit rules or checks have been configured, then no rules or checks are evaluated in this part of the flow. Note that this step is not performed for locked claim lines and replaced claim lines.
The pre benefits checks flow is schematically depicted by the following figure:
Remove Messages
The claim messages, bill messages and the claim line messages that were applied automatically in an earlier executed pre benefits step are removed. This includes messages that are attached to replaced lines.
Derivation Rules
A derivation rule sets the value of certain fields on a claim, bill or claim line. There are two types of derivation rules:
-
process field derivation rules can be used during the pre benefits checks to set the value of the following fields:
-
claimLine.benefitsInputAmount
-
claim.dueDate
-
-
derivation rules can set the value of a dynamic or native field on either the claim, the bill or the claim line.
At this point in the flow, only derivation rules are executed for which the "step" field has the value "pre benefits".
Derivation rules are not evaluated if a product independent fatal message (of origin MANUAL, EXTERNAL, SANITY CHECKS, PRE PRICING, ENROLLMENT, RESERVATION, PRICING, PRICING LIMIT, PRICING NO RECALCULATION or PAYMENT STATUS) exists that is attached to the same (or higher) level as specified by the derivation rule.
The pre benefits derivation rules are evaluated in the following order:
-
Derivation Rules on the claim; if multiple derivation rules exist, they are executed in order of the configured sequence (sequence null is evaluated last)
-
Derivation Rules on the bill; if multiple derivation rules exist, they are executed in order of the configured sequence (sequence null is evaluated last)
-
Derivation Rules on the claim line; if multiple derivation rules exist, they are executed in order of the configured sequence (sequence null is evaluated last)
-
Process Field Derivation Rules on the claim line (benefits input amount). If and only if the benefits input amount is set through the successful execution of a process field derivation rule, then the benefits input amount is possibly converted into another currency. The logic for this is described in the paragraph 'Currency Conversion (Benefit)'
-
Process Field Derivation Rules on the claim
The result of the evaluation of the process field derivation rules on the claim line is a list of eligible process field derivation rules on the claim line start date; the result of the evaluation of the process field derivation rules on the claim is a list of eligible process field derivation rules on the claim start date.
If more than one process field derivation rule is found for a certain process field, the list is ordered by the process derivation priority of the process field derivation rule. The lower the priority field value, the higher the priority. If a process field derivation rule has no priority value, then this is interpreted as the lowest possible priority. This way, only a single process field derivation rule should have the highest priority for a certain process field. If not, the following product independent fatal message is attached to the claim or claim line:
| Code | Sev | Text |
|---|---|---|
CLA-FL-PBEN-002 |
Fatal |
Multiple process field derivation rules with the same priority have been found for process field {process field name} |
Currency Conversion (Benefit)
A multi-currency environment can be necessary, for example, an international company based in a centralized country with labor contracts for all employees. The employees, however, can be working in various countries and that is where they will need medical attention.
During claims flow processing, the following currencies are distinguished to facilitate such an environment:
-
pricing currency
Billing will be in the currency of the provider and according to the provider’s contracts. Both the claimed amount and the allowed amount will be in this currency. -
benefit currency
Details of the medical arrangements in the labor contracts, like heights of deductible and coinsurance, will be in the currency of the employer which means that all benefits evaluation needs to be done in that currency. Both the benefits input amount and the covered amount will be in the benefit currency, as will consumptions be on authorization and coverage regimes. -
authorization currency
Evaluation of an authorization regime may lead to the need for an authorization. Such an authorization will often be specified in the provider’s currency. Therefore, before the evaluation of an authorization, a conversion may be needed from the benefit currency into the authorization currency. Likewise, after the evaluation, a conversion back into the benefit currency may be needed. -
payment currency
For a provider claim, the payment will typically be in the claimed currency which is the pricing currency. For a restitution claim, it might be in the benefit currency. So, before creation of the financial transaction details, a conversion from the benefit currency into the payment currency may be needed.
In a single currency environment, all these conversions are obviously unnecessary.
The process field derivation rule for benefits input amount will - if successfully executed - have as output the benefits input amount without taking any conversion into account. The function dynamic logic with signature 'Currency Conversion (Benefit)' will automatically be applied to this outcome so that the benefits input amount is stored in the benefit currency. If there is no function dynamic logic with signature 'Currency Conversion (Benefit)', no conversion will take place. If the function dynamic logic exists, but it 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).
Dynamic Checks
A dynamic check represents a (user configured) condition. If the claim or claim line fails to meet that condition, a message is attached. A dynamic check is executed on one of two points in the flow. The first moment is during the pre pricing checks. The second moment is during the pre benefits checks, as described here. At which of the two points a check executes depends on the way the check is configured.
It is not possible to configure claim (header) level pre benefits dynamic checks, so during this step only claim line level pre benefits checks are executed.
Dynamic checks executed during the pre benefits checks are typically dependent on information returned via the enrollment or payment status integration point. Dynamic checks are not evaluated if a product independent fatal message (of origin SANITY CHECKS, PRICING, PRICING LIMIT, PRICING NO RECALCULATION or ENROLLMENT) exists at the configured or higher level.
Combination Checks
Only combination checks with step 'Pre Benefits' are evaluated here. There are three types of combination checks: duplicate checks, mandatory checks & exclusive checks. Each type is described in the following paragraphs. All the combination checks in this step are executed at claim line level. For more information on "Combination Checks" page of the Process Flow chapter in the Configuration Guide.
All three types of combination checks search in the same way for relevant claim lines; this will be described here. After that, the evaluation differs, which will be described in different sections (Duplicate Checks and Mandatory Checks and Exclusive Combination Checks respectively).
Combination checks are not evaluated if a product independent fatal message (of origin SANITY CHECKS or ENROLLMENT) exists at the claim line, or at the claim or bill to which the line belongs. In addition, if the duplicate check attaches a fatal message to a claim line, then the evaluation of mandatory/exclusive checks on that line is skipped.
Duplicate Check
For each claim line in the processed claim, Claims evaluates the configured duplicate combination checks. If a combination check applies to a claim line, that claim line triggers a search across other claim lines. That line is referred to as the 'triggering line'. How to find a possible duplicate line is defined by a dynamic logic function.
The dynamic logic function has access to relevant claim line history. That means that the following lines are filtered:
-
Not the triggering claim line;
-
Lines with the same serviced person or object;
-
No replaced lines;
-
Lines with a start date within the period before and after as specified on the combination check, relative to the start date of the triggering line.
The following criteria should be included in the dynamic logic:
-
The status(es) that the resulting claim line can have.
-
That the resulting claim line has no fatal messages attached.
-
Any other search criteria.
If the dynamic logic function returns a claim line, then the message specified on the combination check is attached to the triggering claim line. If no line is returned, then no action is taken. It is possible that more than one duplicate check will trigger for the same claim line. In that event, the combination checks will be processed in an arbitrary order.
Mandatory Checks and Exclusive Combination Checks
Both mandatory and exclusive combination checks are processed as follows: for each claim line in the processed claim, \claimComponent} evaluates the configured mandatory and exclusive combination checks. If a combination check applies to a claim line, that claim line triggers a search across other claim lines. That line is referred to as the 'triggering line'. How to find a line that would prompt an exclusion or is part of a mandatory combination is defined by a dynamic logic function.
The dynamic logic function has access to relevant claim line history. That means that the following lines are filtered:
-
Not the triggering claim line;
-
Lines with the same serviced person or object;
-
No replaced lines;
-
Lines with a start date within the period before and after as specified on the combination check, relative to the start date of the triggering line.
The following criteria should be included in the dynamic logic:
-
The status(es) that the resulting claim line can have.
-
That the resulting claim line has no fatal messages attached.
-
Any other search criteria.