Sanity Checks

This step holds a number of checks and rules that execute immediately once the claim enters the processing flow. Note that this step is not performed for locked claim lines and replaced claim lines. The sanity checks flow is schematically depicted by the following figure:

Remove Existing Messages

The messages attached to the claim, claim line and bills that were attached in a previous sanity checks step are removed.

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, that is, for dynamic and fixed fields and for process fields. At this point in the flow, only derivation rules are executed for which the "step" field has the value "pre reversal" which means no process field drivation rules. Pre reversal derivation rules are evaluated even if a fatal message is attached to the same (or higher) level as specified by the derivation rule. The pre reversal derivation rules are evaluated in the following order: claim (header) first, bill second, claim line last. Then, if multiple derivation rules exist, they are executed in order of the configured sequence (sequence null is evaluated last).

Reverse Edits

Reverse edits is a step that always needs to be carried out, both for a claim that comes from the Change page and for a claim that is processed again through the Claims In IP, Claims Update IP or Claims Reprocessing IP (note that this step is skipped for new claims).

Edits that are marked by a tag can be reversed automatically. Whether that actually needs to be done, can be set by an operator in the Change page or by an IP though claim tag actions. These actions refer to a particular claim and a particular skip tag, which can be set through either a callout rule or a replacement rule.

When are Edits Reversed?

Edits are reversed depending on the claim tag action:

• Redo - The edit is reversed unless:

  • One of the lines on the claim has a checked KP/KB/Locked indicator AND was added by the callout / replacement rule

  • One of the lines on the claim has a checked KP/KB/Locked indicator AND has a fatal message added by the callout rule

  • One of the lines on the claim has a checked KP/KB/Locked indicator AND has an allowed amount set by the callout rule

• Skip or Force - The edit is reversed unless:

  • One of the lines on the claim has a checked Locked indicator AND was added by the callout / replacement rule

  • One of the lines on the claim has a checked Locked indicator AND has a fatal message added by the callout rule

  • One of the lines on the claim has a checked Locked indicator AND has an allowed amount set by the callout rule

• Hold - The edit is not reversed.

What is Reversed?

Edits are reversed per skip tag. Note that edits on locked claim lines are not reversed. Reversing an edit means:

• Claim lines that were added by the callout rule(s) or a replacement rule(s) using the skip tag are removed. If the added line replaced original lines, the original lines are restored.

• Any allowed amount and allowed number of units field that was set through the callout rule(s) using the skip tag is cleared (set to 0) and the accompanying skip tag for allowed is cleared.

• Any claim line message that was added through the callout rule(s) using the skip tag are removed

Rematching

When reference data like relations, providers and procedures are loaded into Claims from an external source, it can occasionally be that the claim is stored through the Claims In Integration Point while one or more references cannot be resolved. As a result, for the unresolved reference data, unmatched values are stored on the claim, bill or claim line. There are ways to resolve this:

• by manually picking the right reference data through a list of values in the 'Receive, Change or Enter Claim' page

• by updating the reference through the Claims Update Integration Point

• by loading the more recent reference data and then reprocessing the claim so that another attempt is made to match the reference data

This last practice is automated through the rematching step. At all three levels, non-matches are being tried to resolve (a non-match is recognizable by the combination of a missing reference and at least one one of the corresponding non-matched fields being filled). The way of resolving differs, either by * trying to match the non-matched code field against the reference table. This structure applies to:

• Serviced entity type (claim, bill and claim line) - matching against insurable entity types

• Serviced person (claim, bill and claim line) - matching against persons

• Serviced object (claim, bill and claim line) - matching against objects

• Service specialty (claim, bill and claim line) - matching against specialties

• Messages (claim, bill and claim line) - matching against messages

• Modifiers (claim line) - matching against modifiers

• Claim line contract references (claim line) - matching against contract references

  • trying to match the combination of the unmatched code field and the unmatched code definition field against the reference table. This structure applies to:

• Service provider (claim, bill and claim line) - matching against providers

• Location (claim, bill and claim line) - matching against providers

• Referral provider (claim, bill and claim line) - matching against providers

• Price individual provider (claim line) - matching against individual providers

• Price organization provider (claim line) - matching against organization providers

• Benefits provider (claim line) - matching against providers

• Procedure (claim line) - matching against procedures belonging to the flex code system as specified under the claims form

• Procedure 2 (claim line) - matching against procedures belonging to the flex code system as specified under the claims form

• Procedure 3 (claim line) - matching against procedures belonging to the flex code system as specified under the claims form

• Claim sub line procedure (claim sub line) - matching against procedures

  • trying to match the combination of the unmatched code field, the unmatched code definition field and the type code against the reference table.

This structure applies to:

• Diagnoses (claim, bill and claim line) - matching against diagnoses

  • trying to match the combination of the unmatched code field and the claim form code against the reference table.

This structure applies to:

• Location type (claim, bill and claim line) - matching against location types

  • trying to match either the code or the combination of the unmatched code field and the unmatched code definition field against the reference table.

This structure applies to:

• Claimant (claim) - matching against relations respectively providers

• Payment specification receiver (claim) matching against relations respectively providers

• Payment beneficiary (claim) matching against relations respectively providers

• Payment receiver (claim, bill and claim line) matching against relations respectively providers

Once a match has been made, the non-matched fields are cleared - just like an update through the UI or the Claims Update Integration Point would accomplish.

Note: Rematching for persons also includes rematching on relation or provider identifiers .

Claim Level Completeness Check

The purpose of this check is to make sure that every piece of information is matched, that is, that the information provided in the claims "in" integration point message has been successfully mapped to the reference data. This check is also executed for each bill that may be underlying to the claim. The claim completeness check is executed regardless of existing fatal messages.

The following claim fields are checked for non-matches:

• Serviced entity type

• Serviced entity (person or object)

• Service provider

• Service specialty

• Claimant

• Location

• Location type

• Referral provider

• Payment receiver

• Payment specification receiver

• Payment beneficiary

• Claim messages

• Claim diagnoses

The following bill fields are checked for non-matches:

• Serviced entity type

• Serviced entity (person or object)

• Service provider

• Service specialty

• Location

• Location type

• Referral provider

• Payment receiver

• Bill Messages

• Bill Diagnoses

A field is considered to be non-matched in the event that no foreign key has been set for that field and at least one of the pertaining non-matched fields contains a value. When a non-match is detected the following message is attached to the claim:

Code	Sev	Text
CLA-FL-PPRI-006	Fatal	The {field name} is not matched.
CLA-FL-PPRI-007	Fatal	One of the {field name} is not matched.

Examples:

CLA-FL-PPRI-006	Fatal	The serviced entity is not matched.
CLA-FL-PPRI-006	Fatal	The claimant is not matched.
CLA-FL-PPRI-007	Fatal	One of the message codes is not matched.
CLA-FL-PPRI-007	Fatal	One of the diagnoses codes is not matched.

Note that any non-match will lead to a fatal message on the claim. There is no distinction given the importance of the field. A non-matched serviced entity and non-matched tenth claim diagnosis code will both lead to a fatal message. One message is attached for each non-matched field.

Claim Line Level Completeness Check

The purpose of this check is twofold. First, this check makes sure that everything that was provided on a claim line is actually matched. Second, it is to make sure that everything vital from a processing point of view, is present. As claims are processed per line, this latter check only on the line level. The claim line completeness check is executed regardless of existing fatal messages.

The following claim line fields are checked for non-matches:

• Serviced entity type

• Serviced entity (person or object)

• Service provider

• Service specialty

• Location

• Location type

• Referral provider

• Payment receiver

• Price organization provider

• Price individual provider

• Procedure

• Procedure 2

• Procedure 3

• Benefits provider

• Claim line messages

• Claim line diagnoses

• Claim line modifiers

• Claim line contract references

• Claim sub line procedure

In the event that a non match is detected, a fatal message is attached to the line. One message is attached for each non-matched field:

Code	Sev	Text
CLA-FL-PPRI-006	Fatal	The {field name} is not matched.
CLA-FL-PPRI-007	Fatal	One of the {field name} is not matched.

Examples:

• CLA-FL-PPRI-006 - The serviced entity is not matched.

• CLA-FL-PPRI-006 - The claimant is not matched.

• CLA-FL-PPRI-007 - One of the claim line message codes is not matched.

• CLA-FL-PPRI-007 - One of the claim line diagnoses codes is not matched.

Because any non matched field may be key in determining the right price or benefit, the CLA-FL-PPRI-006 and 007 are fatal. Claim line procedures are an exception: a configuration option is available for non matched claim line procedures to result in an informative message rather than a fatal message. This configuration is available under the claims form. If the "Fatal non match" indicator is unchecked for a procedure, and that procedure is unmatched, the following message is generated instead of the the CLA-FL-PPRI-006:

Code	Sev	Text
CLA-FL-PPRI-020	Info	The {procedure display name} is not matched.

The procedure display name value is configured under the claims form.

After the non-matches have been checked, the system re-checks the serviced entity. If the serviced entity is neither matched nor unmatched, that is, not specified at all, then the following message is generated:

Code	Sev	Text
CLA-FL-PPRI-008	Fatal	The serviced entity must be specified.

The completeness check only covers those fields which are not mandatory in the claims data model. These are fields that can be on multiple levels or may be non-matched. Mandatory fields (such as the claim line start date) are not checked at this point; if this field was not specified the claim would not have been accepted by the integration point.

Claim Line Level General Checks

After the completeness check, a number of basic checks regarding time validity and the use of procedures are done for each claim line. General checks are only executed on line level because information on the claim or bill level is inherited down to the claim line level. Claim line level general checks are not evaluated if a fatal message (of origin MANUAL, EXTERNAL or SANITY CHECKS) exists that is attached to the claim line, or the bill or claim to which the line belongs.

Time Validity of Codes

All the codes that can be used on a claim or claim line can have a start date and an end date. The check whether a code is valid on the right date of the claim is performed in this step. The check is performed in the following way

At the claim level no time validity checks will be performed. This is because the claim has no "as-of" date to check a code’s validity against. In addition, if the claim holds provider and diagnosis information, that information will have inherited down to the lines that did not specify their own. Since the lines are checked, checking at the claim level is redundant.

For procedures, diagnoses, providers and flex code values, the code must be valid on the start date of the claim line. More precise:

• The procedure/diagnosis/provider/flex code’s start date must be on or before the start date of the claim line

• The procedure/diagnosis/provider/flex code’s end date must be either unspecified, on or after the start date of the claim line

If this is not the case the following message will be attached to the claim line:

Code	Sev	Text
CLA-FL-PPRI-002	Fatal	The value of the code {code} in the field {"field display name"} should be valid at {"claimline.startdate"}

If this is not the case with flex codes on dynamic records the following message will be attached to the claim line:

Code	Sev	Text
CLA-FL-PPRI-018	Fatal	The value of the code {code} in the field {"record field display name"} on dynamic record {"field display name"} should be valid at {"claimline.startdate"}

Procedure Age and Gender

A claim line can specify up to three procedures. This step handles the validation of a claim line with regard to the allowed age and gender that can be specified on procedures. These attributes represent conditions that must be met by a serviced person in order to claim the specified procedure. The age is determined as the age on the claim line start date.

If the person fails to meet the age and or gender conditions, then the following message is attached to the claim line.

Code	Sev	Text
CLA-FL-PPRI-003	Fatal	The serviced person’s age {"person.age"} exceeds the age bounds {"procedure setting.age from"}, {"procedure setting.age to"}, as specified for the procedure.
CLA-FL-PPRI-021	Fatal	The serviced person’s age {"person.age"} exceeds the age bounds {"procedure setting.age from"}, {"procedure setting.age to"}, as specified for the second procedure.
CLA-FL-PPRI-022	Fatal	The serviced person’s age {"person.age"} exceeds the age bounds {"procedure setting.age from"}, {"procedure setting.age to"}, as specified for the third procedure.

Note that the bounds on the procedure are inclusive: if the "age to" is 75 and the person is exactly 75 years old on the as-of date, then no fatal message is attached.

In the event that the procedure gender attribute is specified, the gender of the serviced person has to be the same. If this is not the case, then the following message is attached to the claim line:

Code	Sev	Text
CLA-FL-PPRI-004	Fatal	The serviced person’s gender {"serviced person.gender"} does not match the gender {"procedure setting.gender"} specified for the procedure.
CLA-FL-PPRI-023	Fatal	The serviced person’s gender {"serviced person.gender"} does not match the gender {"procedure setting.gender"} specified for the second procedure.
CLA-FL-PPRI-024	Fatal	The serviced person’s gender {"serviced person.gender"} does not match the gender {"procedure setting.gender"} specified for the third procedure.

Note that this check is only relevant if the claim or claim line relates to a serviced person. It does apply to serviced objects.

Serviced Entity Type

An additional validation is executed to check whether the serviced entity type is valid for the line of business related to the claim form.

Code	Sev	Text
CLA-FL-PPRI-025	Fatal	The serviced entity type {type} is not valid for line of business {code}.

Evaluate External Intervention Rules

All external intervention rules of the sub type MANUAL CHANGE are evaluated. A rule triggers when all a claim, claim line or bill satisfies all criteria set by the rule.

For each triggered external intervention rule, the specified pend reason is checked: if the reattach indicator is unchecked and the pend reason history indicates that the same pend reason has been previously attached on the same level (claim, bill or line), then 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 claim, claim line or bill, and added to the claim pend reason history.

If no pend reasons are attached as a result of the external intervention rule evaluation, then the claim skips ahead to the "Pre Pricing" step. Otherwise, the claim indicators "Preprocessing Done?" and "Pricing Done?" are unchecked and the claim status is set to CHANGE. See the Operations Guide on claims flow configuration for more details on how to configure external intervention rules.