Skip to main content

Bypassing automatic split claim functionality

Suggest edit Updated on April 26, 2021

In addition to the configuration of event codes that drive manual split claim bypass functionality, SCE supports other user-configurable scenarios in which automatic split claim logic may be bypassed. Two scenarios are described below.

Scenario 1: Patient is admitted to an inpatient acute care hospital, inpatient rehab facility or long-term care hospital. If during this admission the patient’s status changes (e.g., patient is termed, changes plan, or changes policy) the claim is not eligible for automatic split because the plan that was effective on the admission date is liable for the entire admission up to the plan limit.

Scenario 2: Patient is enrolled prior to the start date of a new episode of care by a home health provider. If during that episode of care the patient’s status changes (e.g., patient is termed, changes plan or changes policy), the claim is not eligible for automatic split because the payer is liable for the entire episode, until a new episode begins with the home health provider under a new payer.

In these scenarios, the split logic is bypassed, facilitating the consumption of accumulator transactions during a single plan year (e.g., the plan that was effective on the admission date in both cases is liable for the entire hospital admission, or home health episode of care, respectively, and all associated accumulator transactions are then consumed during the same plan year).

Configuring non-split logic

SCE uses a decision table entitled BypassSplit to drive the configuration of multiple conditions under which automatic split claim logic is bypassed. This is an extendable decision table that is easily configured to meet the customer’s business requirements.

OOTB fields included in the BypassSplit decision table are PlanType, PlanID, ClaimType, Provider Taxonomy, and Split criteria.

Split criteria

SCE supports the following split criteria:

  • Provider termination
  • Provider contract change/termination
  • Calendar year split
  • Exceeding lines split
Note: While included in the SplitClaimCriteria decision table, Member Plan Change/Termination is not currently available.

To be enabled for use in the BypassSplit decision table, each of the above referenced split criterion must first be configured in the Split claim criteria decision table, using the following properties:

  • ClaimType
  • ClaimIdentifier
  • ActionCode
  • SplitCodeDesc
  • Maxlinethreshold

Then, if a claim meets the associated criteria, and the split logic field in the BypassSplit decision table is configured with a return value of Yes, the split logic will be bypassed.

Within the BypassSplit decision table are 2 return values configured in 2 different columns:

  • In the column labelled ByPassSplit the user configures either Yes or No to indicate whether the split should occur. If Yes, the split logic is bypassed; if No, the split may be executed.
  • The column labelled Return identifies the corresponding row number on which the split logic bypass is based. The return value in this column should be configured as a whole number (neither negative nor decimal) > 0.

If a claim meets any of the criteria within the BypassSplit decision table, then based on that table’s return value (Yes or No) the split logic will either be applied or bypassed.

To bypass the split logic, a claim’s data must exactly match all the data configured in at least 1 row of the BypassSplit decision table, that is configured with a return value of Yes.

To facilitate the bypassing of the split logic, all columns within a row of the decision table must be populated, with the exception of Plan ID. If the Plan ID field is blank the logic is applicable for all plans associated to a configured plan type. If, however, a specific Plan ID is present in a given row, the bypass is only applicable to that Plan ID. Note: Best practice suggests that when a Plan ID is configured within the BypassSplit decision table, the return value in the BypassSplit column should be configured as No in order to enable a claim split (as the application of bypass to specific plans is not recommended). Also, when Plans IDs are specified within discrete rows, those rows should be configured at the top of the decision table, and rows in which plan IDs are blank should be configured below.

The BypassSplit decision table will be evaluated on a row-by-row basis, and if any row meets all the criteria, and the return value is No, the claim will be split at that point, and subsequent rows will not be evaluated.

If during the evaluation of the rows within the BypassSplit decision table SCE finds a row that meets all the criteria, and the return value is Yes, the split logic will be bypassed. At this point subsequent rows will continue to be evaluated until a row meeting all the criteria, and with a return value of No is found. Consequently, multiple matching rows may continue to be evaluated until a matching row with a No return value is found.

One possible scenario is that there may be 2 rows configured with same criteria, except for Plan ID (i.e. one row having Plan ID and the other one not having the plan ID). In this case, the user should ensure that the row with plan ID is configured in the top position to ensure the expected results.

Note: Best practice suggests that the user not configure the same criteria in 2 different rows, one with a return value as Yes and another with the return value of No.

When a match is found between the claim data and the data configured in the BypassSplit decision table, SCE displays an audit message in the claim UI indicating the claim is eligible for split bypass based on the identified criteria. This message includes the identification of the exact row # from the decision table that was the basis of the decision to bypass the split logic.

If the BypassSplit column return value is configured as Yes, all the subsequent rows in the decision table will be evaluated until SCE reaches a row with a return value of No. And if the claim matches multiple criteria resulting in multiple instances of bypassed split logic, then multiple audit messages will be displayed across multiple modules.

If any of the matching bypass criteria returns a value of No, SCE will continue to split further.

Note: The execution of SplitClaimCriteria occurs according to the sequence of clam adjudication. This means the criteria against which the claim is split depends on the sequential order of SCE’s adjudication modules. Consequently, even though the first row of the SplitClaimCriteria decision table is configured OOTB with the Claim spans calendar year criterion, when other criteria are configured (e.g., Exceeding lines) below that row, SCE will automatically execute the split based on the order of the claim’s adjudication and not the order of configuration in the decision table.
Did you find this content helpful? YesNo

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us