Dynamic Checks
A dynamic check is a user defined validation of the data elements on the claim. The result of failing the validation is that a message is attached to the failing claim or claim line. The message can be used to pend or deny the claim or claim line. Dynamic checks are typically used for claim filing limits, late charges and missing information.
Note that claim line level dynamic checks are not evaluated for locked claim lines and replaced claim lines.
Concepts
A dynamic check has the following properties:
Dynamic Check
| Field | Description |
|---|---|
Code |
The code of the dynamic check. |
Description |
The description of the dynamic check. |
Level |
The check executes per claim or per claim line. |
Step |
The step in the process where the check executes. There are two options: pre pricing and pre benefits. |
Execute per product? |
Checked: the check is executed once per policy product. The value of the indicator is ignored for pre pricing checks. |
Claim type |
Specifies the claim type to which the dynamic check applies. Provider claim or Restitution claim. If this field is left empty then the check is executed for both types. |
Dynamic logic condition |
The validation condition. If the condition evaluates as "false" the specified message is attached to the claim or claim line. |
Message |
The message that is attached to the claim or claim line when the dynamic logic condition evaluates to False. |
Product |
The product that sets the context for the dynamic check. This also determines, assuming the check fails, the product on the message that is attached to the claim or claim line. A product can only be set for a pre benefit check. |
Enabled indicator |
Specifies whether this check is executed. |
Dynamic Check Claim Form
| Field | Description |
|---|---|
Dynamic Check |
The dynamic check for which specific claim forms are defined. |
Claim form |
The form of the incoming claim. |
Dynamic check claim forms facilitate the restriction of dynamic checks to claims of specific claim forms. The claim form of the claim must either match one of the defined dynamic check claim forms, or no dynamic check claims forms are defined. In the latter case, the dynamic check applies to all claims, irrespective of the claim form.
Pre-Benefits or Pre-Pricing?
When defining a dynamic check, the field 'Step' determines in which step the dynamic check is executed. Depending on the use case and the required data, the appropriate value of this field has to be chosen. See table below for categories of data available in each step where dynamic checks are executed:
| Step | Enrollment Data Available? | Payment Status Data Available? | Benefits Calculated? | Possible Levels |
|---|---|---|---|---|
Pre Pricing |
No |
No |
No |
Claim and Claim line |
Pre Benefits |
Yes |
Yes |
No |
Claim line |
Note that its not possible to configure a pre benefits check on the claim level. The rationale is that pre benefits checks are always within the context of a product, and a product’s benefits are always applied per claim line (and not per claim).
Also note that dynamic checks are always executed before the calculation of benefits. The rationale for not allowing line level checks is that the denial of a single claim line, after benefits have been calculated, invalidates the calculation for all lines in the claim. The rationale for not allowing claim level checks is that there is no scenario where a dynamic check causes the denial of the entire claim, based on the calculated benefits. If such a scenario is conceivable, then the cause for denial should have been reflected in the benefit rules that drive the calculation.
Pre pricing dynamic checks are checks that do not require enrollment or payment status data and do not depend on the results of the benefits calculation. Because the enrollment data is not available yet, dynamic checks executed during this step do not have access to product data. Dynamic checks executed in this step can be of claim and claim line level. See use cases below for examples:
-
High dollar claims is a claim line level dynamic check
-
Admission date versus Discharge Date is a claim level dynamic check.
Pre benefit dynamic checks are checks that require enrollment or payment status data. Dynamic checks for this step are always of claim line level, but can be product dependent:
-
The execute per product indicator is checked. The dynamic check is repeatedly executed, once for each enrolled product. This type of check can be used to check payment status per product. Another example is the checking of filing limits, when product-specific filing limits are setup.
-
A specific product can be defined for the dynamic check. In that case, the dynamic check is only executed if the user is enrolled for that product.
-
The execute product indicator is not checked and no product is defined. This type of pre benefits check is thus product independent.
For the product dependent checks (option 1 and 2 above), the processing is slightly different:
-
The product is passed as a parameter to the dynamic logic. See next section for details.
-
When the dynamic check fails, i.e., the dynamic condition evaluates as 'false', then a product specific claim line message is attached. When this is a fatal message, the product is excluded from the benefits calculation.
Use Cases
High Dollar Claims
Purpose: validate that the amount of one claim line does not exceed a fixed limit.
Dynamic Logic Conditions
| Code | Logic | Description |
|---|---|---|
HIGH |
claimLine.claimedAmount < = 1000000 |
The claimed amount on a single line should not exceed 1M. |
The messages that are used in the setup.
Admission Date Versus Discharge Date
Purpose: validate that admission date is not after discharge date.
| Both admissionDate and dischargeDate are dynamic fields. |
Dynamic Logic Conditions
| Code | Logic | Description |
|---|---|---|
ADMDIS |
claim.admissionDate =< claim.dischargeDate |
The admission date on a claim should be smaller or equal to the discharge date |
The messages that are used in the setup.
Filing Limit for Provider Claims
Purpose: check whether claim is filed within the filing limit.
Look at the filing limits for the
-
product
-
billing provider
-
state in which the person resides
-
default filing limit.
Use the highest value as the filing limit for the claim. Apply the filing limit by comparing the service date and the date received.
Dynamic Logic Conditions
-
Code: FILINGLIMIT
-
Logic:
def defaultFilingLimit = 85
def filinglimitList =[
product.filingLimit
, claimLine.claim.billingProvider.filingLimit
, claimLine.servicedMember.address.asOf().findall(it.type == "S").countryRegion.filingLimit
, defaultFilingLimit]
filinglimit = filinglimitList.max()
if (claim.dateReceived - claimLine.startDate <= filingLimit)
//Within filing limit
return true; //<< No substitution parameters returned>>
} else { // Exceeded filing limit
//<< Returning substitution parameters >>
errors[0]=startDate;
errors[1]=dateReceived;
errors[2]=filingLimit;
return false;}