Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Split claims

Updated on August 31, 2021

This section details how the SCE can automatically split a claim and identifies the event codes when the SCE is unable to execute the split successfully.

The SCE has the module Split Claim (SSC) which is used to configure these rules and perform the splits. Some of the logic to perform the splitting of the claim is in the associated module retrieving the functionality. For example, splitting claims based on the overlap of provider contracts is in Provider eligibility (SPE) and the member plan termination is in Policy selection and eligibility (SMP).

Split claim configuration

There are two configurations that are used to control when splits are performed on the claim. The first is the decision table which will identify whether split rules are enabled and when appropriate, some specific configurations for those rules. The second is another configurable decision table, but this provides the ability to bypass the split based on specific criteria.

Split claim criteria

The split claim criteria table is responsible for identifying if a specific split rule is enabled. The SCE provides the following types of rules. Each rule returns an action code that is applied to the claim:

CriteriaAction codeDescription
Claim spans calendar yearSPC1The SCE will split the claim and appropriate lines if the DOS spans across multiple years. The resultant claims should have all lines with the DOS within the same calendar year.
Exceeding LinesSPC2The SCE will split the claim if the number of lines exceeds the configured max. Each resultant claim will have at most the max number of lines defined.
Provider contract change/terminationSPC3The SCE will split the claim so that each claim will be associated with a specific provider contract.
Provider terminationSPC4The SCE will split the claim if the provider contract is terminated during the dates of service.
Member plan terminationSPC5The SCE will split the claim if the member plan is terminated during the dates of service.

The table controlling the split claims is the SplitClaimCriteria table:

This table can be extended as necessary to add new columns. The table is currently configured to support the claim type and claim identifier, so that each permutation could potentially have a different configuration. If the split rules are to be enabled, the split claim column for the specific criteria will be populated with “Yes”. The maximum number of lines configuration is also in this table. The threshold will identify the maximum number of lines a claim can have before it needs to be split. The action code and description are also returned from this decision table to provide appropriate auditing in the log and the assignment of the action code to the claim.

The decision table will be a part of configuration menu in the BA portal within configuration under the option " Delegated rules". Upon clicking the gear icon from the split claim’s configuration, the decision table will be opened where from the user can make changes to the decision table and save his changes. The decision table is accessible from the Delegated rules in the Configuration menu on the portal.

Split claim bypass

The SCE also provides a configuration to bypass the split claims rules for specific scenarios. This will enable a client to exclude claims meeting certain criteria from having the split logic applied. The table controlling this is the BypassSplit table.

Two examples of ideal business scenarios in which split logic would be skipped are discussed below.

  1. There are times when a patient is admitted to an inpatient acute care hospital, inpatient rehab facility or a long-term care hospital. If during this stay, the patient changes status (is terminated, changes plan or changes policy), the system should not split the claim automatically. The Plan that was effective on the admission date would be liable for the entire inpatient stay up to the Plan limit.

IF:

THEN:

If The provider is in an inpatient acute care hospital, inpatient rehab facility or a long-term care hospital

and the patient changes status (payer/plan) during an inpatient stay: therefore, effective on the patient admission date.

The claim is NOT to split and plan that was effective on the admission date is liable for the entire inpatient stay up to plan limits. (i.e. 180 skilled nursing days)
  • There are times when a patient would be enrolled before the start date of care and is admitted to a home health provider. If during this stay, the patient changes status (is terminated, changes plan or changes policy), the system should not split the claim automatically. The Payer would be liable until disenrollment or else a new episode must be opened by the home health provider for the new payer.

IF:

THEN:

If the patient was enrolled before the start date of care and the provider is a home health provider.

and the patient changes status (payer/plan) during the home health episode: therefore, effective on the patient admission date.

The payer is liable until disenrollment, but the claim is NOT to split because a new episode must be opened by the home health provider for the new payer.

The bypass split table is accessible from the Delegated rules section of the Configuration menu in the portal. The table is provided with columns for plan type, plan ID, claim type, provider taxonomy and the split criteria. If a match is made against the conditions, and the ByPassSplit returns “Yes”, then the split logic will be bypassed. The split criteria, matching the description from the Split claim criteria table, can be entered so that only specific criteria can be bypassed through this logic. This table can be extended as necessary to add other conditions. The number in the return value from the table will be detailed on the audit trail if the bypass split is “Yes”.

Splitting the claims

The actual splitting of the claims is performed when the criteria or rationale is met, but the process for splitting is the same and the system sets global event codes when the claim cannot be split automatically. This enables the same event codes to be fired regardless of where the split claims logic is performed. For example, through the member module, provider module or the split claims module.

An event code is also assigned for each of the split claim models. This enables clients to configure the disposition to route them for review if required. The event codes for split claims are typically assigned when the claim cannot be split automatically due to an uneven distribution of amounts or units across the dates of service.

Global event codes for split claims
Event codeNameDescription
SGB-0002COB units cannot be splitThe service units reported by the other payer (COB) on the split claim line cannot be evenly split.
SGB-0003Service units cannot be splitThe service units on the split claim line cannot be evenly split.
SGB-0004Billed amounts not balancedAfter the claim line split, the billed amounts on the split lines do not sum up to the billed amount submitted on the original claim line.
SGB-0005Claim line splitThe claim line was split by the system during processing.
SGB-0006COB adjustment units cannot be splitThe adjustment units reported by the other payer (COB) on the split claim line cannot be evenly split.
SGB-0017Re-split claim lineThe claim line has previously been split and will be split again; review required.
SGB-0019COB paid amounts not balancedAfter the claim line split, the COB paid amounts on the split lines do not sum up to the COB paid amount submitted on the original claim line.
SGB-0020COB adjustment amounts not balancedAfter the claim line split, the COB adjustment amounts on the split lines do not sum up to the COB adjustment amount submitted on the original claim line.
SGB-0024Multiple split criteriaA claim eligible for automatic split meets more than one criterion for the split.
SGB-0026COB paid amounts not balancedAfter the claim split, the COB paid amount on the split claims does not sum up to the COB paid amount submitted on the original claim.
SGB-0027Remaining patient liability amounts not balancedAfter the claim split, the remaining patient liability amount on the split claims does not sum up to the remaining patient liability amount submitted on the original claim.
SGB-0028Non-covered amounts not balancedAfter the claim split, the non-covered amount on the split claims does not sum up to the non-covered amount submitted on the original claim.
SGB-0029

COB adjustment amounts not balanced

After the claim split, the COB adjustment amount on the split claims does not sum up to the COB adjustment amount submitted on the original claim.
SGB-0030COB adjustment units cannot be splitThe adjustment units reported by the other payer (COB) on the split claim cannot be evenly split.
SGB-0031Remaining patient liability not balancedAfter the claim line split, the remaining patient liability amounts on the split lines do not sum up to the remaining patient liability amount submitted on the original claim line.
SGB-0032Medicaid paid amount not balancedAfter the claim split, the Medicaid paid amount on the split claims does not sum up to the Medicaid paid amount submitted on the original claim.
SGB-0033Calendar year splitThe claim was split into two or more claims based on billed service dates spanning multiple calendar years.
SGB-0034Max line splitThe claim was split into two or more claims based on reaching the configured maximum number of claim lines.
SGB-0035Provider termination splitThe claim was split into two or more claims based on billed service dates spanning the termination of the provider in the system.
SGB-0036Provider contract termination splitThe claim was split into two or more claims based on billed service dates spanning the termination of the provider contract in the system.
SGB-0037Member plan termination splitThe claim was split into two or more claims based on billed service dates spanning the termination of the member plan.
SGB-0045Medicaid paid amounts not balancedAfter the claim line split, the Medicaid paid amounts on the split lines do not sum up to the Medicaid paid amount submitted on the original claim line.
General split claim identification and processing flow

The SCE reviews the criteria for the split and performs the same process for splitting the claims based on the information in the claim. The SCE is designed to perform the splits if possible, but to set an event code should the claim fail to be split based on the information on the claim.

The split claims flow goes through the following steps:

  1. Identify if the claim is eligible for split based on the specific criteria.
  2. Once eligible, the split will be performed in the module where the appropriate criteria are reviewed.
  3. Two or more new split claims will be created as needed based on the criteria. The new claims are assigned a status of New.
  4. All the basic claim information is copied to the other claims from the original claim. This is the original claim data and not the calculated fields.
  5. The original claim will be cancelled and assigned with a Resolved-Split status.
  6. If claim lines are split, the values will be moved into the new claim lines and the original line will be assigned a Cancelled status.
  7. All the amounts and units are assigned to the new claims and lines based on the appropriate split ratio. If the units or amounts cannot be split evenly, then event codes associated with the error are assigned.
  8. The new split claim units are balanced against the new lines. If these fail balancing, then event codes associated with the error are assigned.
  9. The header level totals are updated based on the new information assigned to the lines.
  10. The amount and unit totals in the split claims are summed and validated against the original claim. If not, event codes associated with the specific error are assigned.
  11. The original and split claims are associated together in the related claims section of the UX.
  12. Action codes associated with the type of split performed are assigned to the original and new splits claims. The original claim has action code ASOC – Automatic Split Original Claim assigned to it.
  13. Event codes associated with the type of split are assigned to the new split claims.
  14. Audit messages are added to the audit trail detailing the split reason are added to the original and new claims.
  15. The new split claims are submitted for adjudication utilizing the appropriate split units and amounts.
General split claim line identification and processing

Split claims line is used to split a claim line into multiple new lines when specific business scenarios exist (for example, the dates on the claim line overlap multiple network or ratesheet configurations). When the SCE splits a claim line, the system cancels the original claim line and create additional claims lines as required.

When a claim split occurs, the system splits the following information at the line:

  • Units
  • Dates
  • COB / line adjudication information
  • Billing information

Once the split is complete, the SCE validates that the sum of the amounts (COB, billed, units) on the new split lines equal the original claim line. When the amounts differ, event codes are applied to the claim.

The split claim line flow goes through the following steps:

  1. Identify if the claim line meets the criteria for a split based on the logic being applied in the module.
  2. Two or more new split claim lines will be created as needed based on the criteria. The new claims are assigned a status of New.
  3. The new lines are given a X.1y, X.2y, X.3y, etc. naming convention where X is the original line number that was split, and y is either s (automatic system split) or m (manual split).
  4. All the basic claim line information is copied to the other claim lines from the original claim line. This is the original claim line data and not the calculated fields.
  5. The original claim line will be cancelled and assigned a Cancelled status.
  6. All the amounts, units and dates are assigned to the new claim lines based on the appropriate split ratio. If the units or amounts cannot be split evenly, then event codes associated with the error are assigned.
  7. The new split claim line units are balanced against the new lines. If these fail balancing, then event codes associated with the error are assigned.
  8. The amount and unit totals in the split claim lines are summed and validated against the original claim line. If not, event codes associated with the specific error are assigned.
  9. Action code SP-102 is assigned to each of the new claim lines.
  10. Audit messages detailing the split reason are added to the audit trail
  11. The new split claim lines continue the adjudication path.

The display of new split lines can be seen in the example below, where claim line 1 has been split into 1.1S and 1.2S, and the original line is displayed as cancelled.

Split claim ratio

The movement of units, dollar amounts, etc, when splitting the claim and/or lines to the new claims and/or lines is based on the split claim ratio. This ratio is used to calculate the appropriate units or amounts for the new claim and/or line. The calculation of the split ratio is the new total days of service over the total days of service for the original claim.

This ratio is used to calculate the appropriate amounts and units for the new claims or lines by multiplying the ratio by the number of units or amounts of the original claim.

Example 1: A claim has 1 line with 9 units and a service state span of 9 days that crosses a calendar year.

Original claim

Service datesLine numberUnitsBilled amount
12/24/2020 – 1/1/202119$1800

After Split

ClaimService datesLine numberUnitsBilled amountStatus
Original12/24/2020 – 1/1/202119$1800Cancelled
New claim 112/24/2020 – 12/31/202018$1600New
New claim 21/1/2021 – 1/1/202111$200New

The split ratio for new claim 1 is 8/9 and the split ratio for new claim 2 is 1/9

Example 2: A claim has 1 line with 42 units and a service state span of 21 days that crosses a calendar year and we need to calculate the COB amounts applied to the lines.

Original claim

Service datesLine numberUnitsBilled amountCOB paid amountCOB patient remaining liabilityCOB adjustment amount
12/30/2020 – 1/19/2021142$3528$2000$105$1528

After Split

ClaimService datesStatusLine numberUnitsBilled amountCOB paid amountCOB patient remaining liabilityCOB adjustment amount
Original claim12/30/2020 – 1/19/2021Cancelled142$3528$2100$105$1428
New claim 112/30/2020 – 12/31/2020New14$336$200$10$136
New claim 21/1/2021 – 1/19/2021New138$3192$1900$95$1292

The split ratio for new claim 1 is 2/21 and the split ratio for new claim 2 is 19/21

Example 3: Using the same claim as example 1, but with a unit count of 8 will cause an uneven split and as such an event code to be reported as this would need manual review.

Original claim

Service datesLine numberUnitsBilled amount
12/24/2020 – 1/1/202118$1800

After Split

ClaimService datesLine numberUnitsBilled amountStatus
Original12/24/2020 – 1/1/202118$1800Cancelled
New claim 112/24/2020 – 12/31/202017.11*$1600New
New claim 21/1/2021 – 1/1/202110.88*$200New

The split ratio for new claim 1 is 8/9 and the split ratio for new claim 2 is 1/9. These do not create an even unit situation for the new claims and SGB-0003 will be assigned to the original claim for manual review and split.

After the split, the amounts and units are summed to ensure that they match the amounts submitted on the original claim. This supports the rounding of amounts as part of the split to support automatic splitting. In the instance the sum of the new lines and claims do not match the original, balancing event codes are created for manual review.

In the instance that there are uneven splits at the line and the header, the line issues will be reported first and need to be resolved before any header level balancing or uneven split logic event codes are reported. Audit messages are applied when uneven units or balancing issues are identified.

Fields that are split/modified

The following table lists the fields on the claim that may be split or modified at the claim or line level depending upon where the split is being applied. Modified fields are the dates which are realigned based on the dates of the rationale for the split.

LevelModified / SplitField
ClaimModifiedFrom date of service
ClaimModifiedTo date of service
ClaimModifiedStatement from date (institutional claims only)
ClaimModifiedStatement to date (institutional claims only)
ClaimSplitTotal billed amount
ClaimSplitCOB – Other payer paid amount (per payer)
ClaimSplitCOB – Remaining patient liability (per payer)
ClaimSplitCOB – Non covered amount (per payer)
ClaimSplitCOB – Adjustment amount (per payer)
ClaimSplitCOB – Adjustment units (per payer)
LineModifiedFrom date of service
LineModifiedTo date of service
LineSplitBilled amount
LineSplitCOB – Other payer paid amount (per payer)
LineSplitCOB – Other payer paid units (per payer)
LineSplitCOB – Adjustment amount (per payer)
LineSplitCOB – Adjustment units (per payer)
LineSplitCOB – Remaining patient liability (per payer)

Split claim with overlapping calendar years

The SCE can split claims based on calendar years based on two models. This split is performed in the split claim module (SSC). The two types of split are:

  • Split the claim where each claim line is associated with a different calendar year
  • Split the claim where individual lines span across different calendar years.

Note that a claim may contain a combination of both scenarios.

Split the claims where different claim lines are spanning across different calendar years

In this scenario, the claim will have multiple claim lines and each of these claim lines will have dates of services in different calendar years. In this situation, the SCE will split the claim into a claim for each calendar year.

Example:

  • Original Claim
LineDates of Service
Claim level12/29/2020 – 1/1/2021
112/29/2020
212/30/2020
312/31/2020
41/1/2021

  • Split claim 1
LineDates of Service
Claim level12/29/2020 – 12/31/2020
112/29/2020
212/30/2020
312/31/2020

  • Split claim 2
LineDates of Service
Claim level1/1/2021
11/1/2021

On split claims meeting the calendar span split rule will have event code SGB-0033 and action code SPC-1 assigned.

Split the claims where claim lines have a date span covering different calendar years

In this scenario, the claim can have multiple claim lines, but at least one spans multiple calendar years. In this situation, the SCE will split the claim into a claim for each calendar year and split any lines that span the calendar years into the appropriate split claim.

Example:

  • Original Claim
LineDates of Service
Claim level12/29/2020 – 1/1/2021
112/29/2020 – 1/1/2021
212/29/2020
312/30/2020
41/1/2021

  • Split claim 1
LineDates of Service
Claim level12/29/2020 – 12/31/2020
112/29/2020 – 12/31/2021
212/29/2020
312/30/2020

  • Split claim 2
LineDates of Service
Claim level1/1/2021
11/1/2021

On split claims meeting the calendar span split rule will have event code SGB-0033 and action code SPC-1 assigned.

Split claim with line count threshold

The SCE can split a claim based on the number of lines in the claim that has been received. This enables the SCE to integrate with other claims processing platforms that cannot support the maximum number of lines that can be received. Using the configuration in the SplitClaimCriteria table for the maximum number of lines, the SCE will split any claim that is received with the number of lines greater than the configuration into new claims, each with a maximum line count.

An example is that a claim is received with 150 lines and the threshold is 100 lines. The claim will be split into two new claims, the first with a line count of 100 and the second with a line count of 50.

Another example is that a claim is received with 260 lines and the threshold is 100 lines, the claim will be split into 3 claims, two with 100 lines and one with 60.

In these situations, the event code SGB-0034 and action code SPC-2 will be raised on the claim, along with the appropriate audit trail.

Special scenarios for split claims

Interim claims

Institutional claims which are submitted with a bill type of 112, 113 and 114 are considered as interim claims.

  • Claim having 112 bill type is the initial claim of interim sequence
  • Claim having 113 bill type is the middle or continuing claim of interim sequence
  • Claim having 114 bill type is the final claim of interim sequence

The logic for interim claims processing is there should be only one 112 (initial) or 114 (final) claim in the interim sequence and if there are multiple 112 or 114 claims, then the system raises an event code. To support this model, when a claim is billed with an initial status is eligible for splitting, then one of the new claims split needs to be the initial claim and the subsequent claims should be part of the continuing sequence. The SCE updates the claim with the appropriate frequency code and bill type to match the processing sequence. The same is true when a claim is billed as the final status needs to be split. In this instance, one of the new split claims becomes the final and the other is part of the continuing sequence. The dates of service on these splits determine whether the new split claim is the first, continuing or last claim in the sequence.

For example:

  • The new split claim with the earliest dates of service would be the first claim (112) if the bill type or frequency code from the original indicates it is the initial claim in an interim. The other split claim(s) would have a bill type of 113.
The new split claim with the latest dates of service would be the final claim (114) if the bill type or frequency code from the original indicates it is the final claim in an interim sequence. The other split claim(s) would have a bill type of 113.

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

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