Combination checks

Combination checks compare a claim line to other claim lines. These might be claim lines within the same claim, but could also be claim lines in the claim history. A combination check always triggers on a claim line that is being processed. If triggered, the system will search across claims for another claim line that meets the requirements set by the combination check. Note that these checks are not evaluated for locked claim lines and replaced claim lines, meaning that these lines will never trigger a check. Locked claim lines are however taken into account when searching for another claim line that meets the requirements set by the combination check which is triggered by a non-locked claim line.

The type of combination check determines what happens when such a claim line is found. The outcome is always one of two possible results: either a message is attached to the line that triggered the check, or no message is attached to the line that triggered the search (effectively nothing happens). In turn, this message can lead to manual adjudication or an automatic denial. To clarify the purpose of combination checks, consider the following scenarios:

A person sends in two separate claims for the same heavy surgery, on the same day, by the same surgeon. Because it is impossible for a patient to undergo the specified surgery twice in one day, the payer wants the system to automatically deny one of the claims.

A person sends in two separate claims for a doctor consult, on the same day, by the same doctor. Because it is unlikely for a person to go to the same doctor twice on the same day, the payer wants the system to pend the claim for manual adjudication.

A person sends in two dental claims, one for a crown, one for bridge and both for the same tooth. Because it is impossible to have both a crown and a bridge for the same tooth, the payer wants the system to automatically deny the triggering claim line.

A person sends in a claim for dental anesthesia. The payer wants the system to check for another claim line with the same service date and a procedure that actually warrants dental anesthesia. This could be a number of different dental procedures, ranging from the pulling of a single tooth to extensive dental surgery. If the system does not find a claim line with the same service date and with a dental procedure that warrants anesthesia, the the system should automatically deny the triggering claim line.

Combination checks impose restrictions on how lines are sent into the application and do not take into account how those lines are adjudicated. For example, a combination check that says line A should always go together with line B will simply check if line B is present when it encounters line A. If, at a later point in the process, line B is denied, it does not automatically also deny line A as a result of that combination check.

Concepts

A combination check contains the following attributes:

Combination Check

Field	Description
Code	The unique code of the combination check
Description	The description of the combination check
Step	Specifies the step in the flow where this combination check is executed: at the start of pricing ('S') or pre benefits ('B').
Sub Type	Specifies whether this is a duplicate, exclusive or mandatory combination check. The sub type drives the way that the check is processed and whether or not a successful search should lead to a claim line message.
Procedure Group	Specifies a procedure group.
Procedure Group 2	Specifies a 2nd procedure group.
Procedure Group 3	Specifies a 3rd procedure group.
Condition Dynamic Logic	The condition when to apply the combination check
Period before	The number of units that the service date of the claim line may differ from the triggering claim line (before)
Period after	The number of units that the service date of the claim line may differ from the triggering claim line (after)
Period (unit of measure)	The unit for the period before and period after (Day, Month or Year)
Dynamic Logic Function	Specifies the search criteria that must be met when searching across claim lines.
Message	The message that is attached to the triggering claim line.
Enabled indicator	This combination check is only executed when this box is checked
Start date	The start date of the combination check
End date	The end date of the combination check

Combination Check Procedure

Field	Description
Combination check	The combination check for which specific procedures are defined.
Procedure	The procedure
Procedure 2	The second procedure
Procedure 3	The third procedure
Start date	The start date of the usage of the combination check procedure.
End date	The end date of the combination check procedure.

A combination check procedure must at least specify one procedure but may also specify a combination of 2 or 3 procedures.

Combination Check Claim Form

Field	Description
Combination check	The combination check for which specific claim forms are defined.
Claim form	The form of the incoming claim.

Three sub types of combination checks are distinguished:

Duplicate check - Choose this type when the combination check is configured to search for an identical line. What actually constitutes "identical", is configurable. If an identical claim line is found, then a message is attached to the triggering claim line. This is by far the most common combination check.

Exclusive combination check - Choose this type when the combination check is configured to catch an unlikely or contradicting combination of claim lines. If such a combination is found, then a message will be added to the triggering claim line.

Mandatory combination check - Choose this type when the combination check is configured to impose a mandatory combination of claim lines. If such a combination is not found, then a message is added to the triggering claim line.

The combination check type drives two things:

• Whether or not finding another claim line that meets the set criteria should result in attaching a message to the triggering claim line.

• The order in which combination checks are executed: duplicate checks are executed prior to exclusive and mandatory combination checks

Combination checks are triggered based on the claim line procedure codes. To this end, the combination check can specify procedure groups or procedures, or both:

• Procedure groups: a combination check can specify up to 3 procedure groups. The combination check only applies to a claim line, if for each procedure group specified on the combination check, the claim line has at least one procedure that is part of that procedure group on the claim line service (start) date.

• Procedures: a combination check can specify a list of procedure combinations. Each procedure combination must specify at least one procedure and can specify a maximum of 3 procedures. The combination check only applies to a claim line, if at least one procedure combination in the list applies to the claim line. A procedure combination applies to a claim line if each procedure specified in the combination occurs on the claim line. Only procedure combinations that are time valid on the claim line service (start) date are evaluated.

If both procedure groups and procedure combinations are specified, this has the meaning that the combination check only applies to claims lines that match with both the procedure groups AND with at least one of the procedure combinations. It is possible to specify neither a procedure group, nor a list or procedures. This is interpreted as a combination check that applies regardless of the procedures on the claim line.

Besides specifying (combinations of) procedures and/or procedure groups, a combination check can also be particularized to certain claims or claim lines, by specifying one or more claim forms and/or a dynamic logic condition.

Once a combination check is triggered, the system will start a search for another claim line for that same person or object. The search criteria are set up in the form of a dynamic logic function. The input for this function is the claim line that triggered the combination check. The output of the function is the very first claim line found that meets the search criteria. Consider the following use case in order to clarify the purpose of the dynamic logic function:

A payer wants to set up a duplicate check. A claim line is considered to be identical when:

• The claim line is for the same person or object(selected automatically)

• The claim line has a service date within the specified range (claim lines are filtered for this period)

• The first three digits of the procedure code are identical

The dynamic logic function would look like this:

// script for duplicate match based on the first three digits of the procedure code

prefix = triggeringClaimLine.procedure.code.substring(0,3)
for (claimLine in claimLineList){
  // the same first three digits in the procedure code
  if ( claimLine.procedure.code.startsWith(prefix) ) {
    return claimLine
  }
}
return null

The claimLines object that is provided to the function contains the claim lines selected on the following criteria:

• the claim line person or object is the same as on the triggering line;

• it’s not the triggering claim line itself;

• the claim line start date is within the time window specified on the CombinationCheck;

• the claim line has not been replaced;

• whether or not the claimLines object is restricted to claim lines within the claim of the triggering claim line depends on the setting of the ignore history indicator:

  • if the ignore history indicator is checked, then the claimLines object only is restricted to claim lines within the same claim as the triggering claim line

  • if the ignore history indicator is unchecked, then no additional restriction is placed on the claimLines object so it can also contain claim lines from other claims

The claimLines object is the same for both start pricing and pre benefits combination checks.

Any additional search criteria that narrow down the search space of eligible claim lines have to be written as part of the dynamic logic function, such as:

• Eligible claim lines belong to a claim with a certain status

• Eligible claim lines are not denied and have no fatal message attached.

• Eligible claim lines must have the same procedure code

• Etc…​

A search is considered successful when at least one claim line meets the criteria set by the combination check. Otherwise, it’s considered to be unsuccessful. Once the search has been completed, the combination check message is attached to the triggering claim line if one of the following statements is true:

• The combination check is a duplicate check and the search is successful;

• The combination check is a mandatory combination check and the search is unsuccessful;

• The combination check is a exclusive combination check and the search is successful;

The actual message that is attached to the triggering claim line is a user defined message. The following information is available for the message to be put into placeholders:

1. The found claim code

2. The found claim line code

For example, the set up message text would look like: "Claim {0}, claim line {1} is a suspect duplicate claim line". An actual instance of the message would then look like: "Claim 123, claim line 1 is a suspect duplicate claim line."

The user also determines the severity of the message; if the payer wishes that a combination check should filter (and deny) erroneous claim lines without manual intervention, then the message severity should be set to "Fatal".

If the payer wishes that a combination check filters claim lines so that they can be manually adjudicated, then the message severity should be "Informative". In addition, the payer should set up an external intervention rule that triggers whenever this message is detected, so that the pertaining claim line is manually adjudicated.

Note that it is possible for two separate combination checks to trigger on the same procedure(s) & claim form. Consider use case 1 for clarification.

Use Cases

Exact & suspect duplicate matches

A payer wants to set up two duplicate checks for dental procedures. Both checks trigger for the exact same procedure group, i.e., DENTAL PROCEDURES. The difference between the two checks is that:

• Duplicate check 1 has very focused search criteria. It requires an exact match on the procedure code, service data & service provider. If a claim line is found that matches these search criteria, that claim line is considered to be an exact match. A fatal message is attached to the triggering claim line so that the line is automatically denied.

• Duplicate check 2 has less strict search criteria. It only requires the first three digits of the procedure code to match and that the service dates are no more than 3 days apart. If a claim line is found that matches these criteria, the claim line is considered to be a suspect match. An informative message is attached to the triggering claim line and a corresponding external intervention rule is set up, so that the line is picked up for manual adjudication.

The payer sets up two Dynamic Logic Functions. The function is called EXACT DUPLICATE FUNCTION:

// script for exact duplicate match
for (claimLine in claimLineList){
  // claim line has the same servicing provider
  if ((triggeringClaimLine.serviceProvider==claimLine.serviceProvider)
     // claim line has the same procedure code
     && (triggeringClaimLine.procedure.code==claimLine.procedure.code)
     // claim is adjudicated or finalized
     && (["FINALIZED","ADJUDICATION DONE"].contains(claimLine.claim.status))
     // claim line may not have a fatal message
     && !claimLine.hasFatalMessage()
) {
    return claimLine;
  }
}
return null;

The second function is called SUSPECT DUPLICATE FUNCTION:

// script for suspect duplicate match
for (claimLine in claimLineList){
  if ((substring(0,3, triggeringClaimLine.procedure.code)==substring(0,3, claimLine.procedure.code))
     && (claimLine.claim.status in ["FINALIZED", "ADJUDICATION DONE"])
     && !claimLine.hasFatalMessage()
)  {
    return claimLine;
  }
}
return null;

The payer sets up two messages:

• Code: EXACT DUP MESSAGE; severity:Fatal, text:"Claim {0}, line {1} is an exact duplicate claim line."

• Code: SUSPECT DUP MESSAGE; severity:Informative, text:"Claim {0}, line {1} is a suspect duplicate claim line."

Finally the payer sets ups up two combination checks. The first is a duplicate check for exact matches:

• Type: duplicate check

• Procedure Group: DENTAL PROCEDURES

• Dynamic Logic Function: EXACT DUPLICATE FUNCTION

• Message: EXACT DUP MESSAGE

• Period before and after: 0 days

and a second one for suspect matches:

• Type: duplicate check

• Procedure Group: DENTAL PROCEDURES

• Dynamic Logic Function: SUSPECT DUPLICATE FUNCTION

• Message: SUSPECT DUP MESSAGE

• Period before and after: 3 days

Mandatory combination

A payer wants to ensure that one specific dental procedure (code D123456) is never claimed without an related claim for anesthesia on the same day.

The payer sets up a Dynamic Logic Function. The function is called MANDATORY DENTAL ANESTHESIA:

// this script checks that:
// the procedure is represents some form of anesthesia (on the service date)
// the (anesthesia) claim line is not (to be) denied

for (claimLine in claimLineLiat){

  if ((claimLine.procedure.inProcedureGroup('DENTAL ANESTHESIA', claimLine.startDate))
  && !claimLine.hasFatalMessages())
 {
    return claimLine;
  }
}
return null;

The payer sets up a message:

• Code: ANESTHETICS REQUIRED; severity:Fatal, text:"Claim {0}, line {1} is cannot be claimed without a related claim line for anesthetics."

Finally the payer sets ups a combination check:

• Type: mandatory combination check

• Dynamic Logic Function: MANDATORY DENTAL ANESTHESIA

• Message: ANESTHETICS REQUIRED

• Period before and after: 0 days

Note that a period value of 0 implies that the claim line that holds the anesthetic procedure has to have the same service date as the dental procedure.

With combination check procedure:

• Procedure code: D123456

• Start date: 01-01-2009

Exclusive combination

A payer wants to pend any claim line with a procedure that specifies pain suppressing medication A (code 232-12-32453), in the event that the same person also claimed pain suppressing medication of type B (code 232-12-45332) within a period of 4 weeks.

The payer sets up two Dynamic Logic Function. The function is called EXCLUSIVE MEDICATION:

// this script checks that:
// the procedure has code 232-12-45332
// the claim line is not (to be) denied

for (claimLine in claimLineList){

  if  ((claimLine.procedure.code == '232-12-45332')
  && !claimLine.hasFatalMessages()
)  {
    return claimLine;
  }
}
return null;

The payer sets up a message:

• Code: CONFLICTING MEDS; severity:Informative; text:"This lines specifies medication that may in conflict with the medication specified by claim {0}, line {1}."

Finally the payer sets ups a combination check:

• Type: mandatory combination check

• Dynamic Logic Function: EXCLUSIVE MEDICATION

• Message: CONFLICTING MEDS

• Period before and after: 4 weeks

With combination check procedure:

• Procedure code: 232-12-32453

• Start date: 01-01-2009