Split claims
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 criteriaThe split claim criteria decision 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:
Criteria | Action code | Description |
Claim spans calendar year | SPC1 | The 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 Lines | SPC2 | The 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/termination | SPC3 | The SCE will split the claim so that each claim will be associated with a specific provider contract. |
Provider termination | SPC4 | The SCE will split the claim if the provider contract is terminated during the dates of service. |
Member plan termination | SPC5 | The 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:
![](https://docs.pega.com/sites/default/files/drupal/dita/out/3401/strategic-apps-user-guide/Content/SCE/Images/split_claims.jpg)
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 split claim criteria 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.
- 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 claimsEvent code | Name | Description |
SGB-0002 | COB units cannot be split | The service units reported by the other payer (COB) on the split claim line cannot be evenly split. |
SGB-0003 | Service units cannot be split | The service units on the split claim line cannot be evenly split. |
SGB-0004 | Billed amounts not balanced | After 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-0005 | Claim line split | The claim line was split by the system during processing. |
SGB-0006 | COB adjustment units cannot be split | The adjustment units reported by the other payer (COB) on the split claim line cannot be evenly split. |
SGB-0017 | Re-split claim line | The claim line has previously been split and will be split again; review required. |
SGB-0019 | COB paid amounts not balanced | After 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-0020 | COB adjustment amounts not balanced | After 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-0024 | Multiple split criteria | A claim eligible for automatic split meets more than one criterion for the split. |
SGB-0026 | COB paid amounts not balanced | After 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-0027 | Remaining patient liability amounts not balanced | After 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-0028 | Non-covered amounts not balanced | After 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-0030 | COB adjustment units cannot be split | The adjustment units reported by the other payer (COB) on the split claim cannot be evenly split. |
SGB-0031 | Remaining patient liability not balanced | After 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-0032 | Medicaid paid amount not balanced | After 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-0033 | Calendar year split | The claim was split into two or more claims based on billed service dates spanning multiple calendar years. |
SGB-0034 | Max line split | The claim was split into two or more claims based on reaching the configured maximum number of claim lines. |
SGB-0035 | Provider termination split | The claim was split into two or more claims based on billed service dates spanning the termination of the provider in the system. |
SGB-0036 | Provider contract termination split | The claim was split into two or more claims based on billed service dates spanning the termination of the provider contract in the system. |
SGB-0037 | Member plan termination split | The claim was split into two or more claims based on billed service dates spanning the termination of the member plan. |
SGB-0045 | Medicaid paid amounts not balanced | After 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:
- Identify if the claim is eligible for split based on the specific criteria.
- Once eligible, the split will be performed in the module where the appropriate criteria are reviewed.
- Two or more new split claims will be created as needed based on the criteria. The new claims are assigned a status of New.
- 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.
- The original claim will be cancelled and assigned with a Resolved-Split status.
- 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.
- 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.
- The new split claim units are balanced against the new lines. If these fail balancing, then event codes associated with the error are assigned.
- The header level totals are updated based on the new information assigned to the lines.
- 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.
- The original and split claims are associated together in the related claims section of the UX.
- 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.
- Event codes associated with the type of split are assigned to the new split claims.
- Audit messages are added to the audit trail detailing the split reason are added to the original and new claims.
- The new split claims are submitted for adjudication utilizing the appropriate split units and amounts.
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:
- Identify if the claim line meets the criteria for a split based on the logic being applied in the module.
- 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.
- 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).
- 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.
- The original claim line will be cancelled and assigned a Cancelled status.
- 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.
- 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.
- 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.
- Action code SP-102 is assigned to each of the new claim lines.
- Audit messages detailing the split reason are added to the audit trail
- 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.
![Displaying split claim lines in the claim view](https://docs-previous.pega.com/sites/default/files/drupal/dita/out/3401/strategic-apps-user-guide/Content/SCE/Images/claim_lines.jpg)
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.
![Split claims ratio](https://docs-previous.pega.com/sites/default/files/drupal/dita/out/3401/strategic-apps-user-guide/Content/SCE/Images/formula_split_claim.jpg)
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 dates | Line number | Units | Billed amount |
12/24/2020 – 1/1/2021 | 1 | 9 | $1800 |
After Split
Claim | Service dates | Line number | Units | Billed amount | Status |
Original | 12/24/2020 – 1/1/2021 | 1 | 9 | $1800 | Cancelled |
New claim 1 | 12/24/2020 – 12/31/2020 | 1 | 8 | $1600 | New |
New claim 2 | 1/1/2021 – 1/1/2021 | 1 | 1 | $200 | New |
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 dates | Line number | Units | Billed amount | COB paid amount | COB patient remaining liability | COB adjustment amount |
12/30/2020 – 1/19/2021 | 1 | 42 | $3528 | $2000 | $105 | $1528 |
After Split
Claim | Service dates | Status | Line number | Units | Billed amount | COB paid amount | COB patient remaining liability | COB adjustment amount |
Original claim | 12/30/2020 – 1/19/2021 | Cancelled | 1 | 42 | $3528 | $2100 | $105 | $1428 |
New claim 1 | 12/30/2020 – 12/31/2020 | New | 1 | 4 | $336 | $200 | $10 | $136 |
New claim 2 | 1/1/2021 – 1/19/2021 | New | 1 | 38 | $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 dates | Line number | Units | Billed amount |
12/24/2020 – 1/1/2021 | 1 | 8 | $1800 |
After Split
Claim | Service dates | Line number | Units | Billed amount | Status |
Original | 12/24/2020 – 1/1/2021 | 1 | 8 | $1800 | Cancelled |
New claim 1 | 12/24/2020 – 12/31/2020 | 1 | 7.11* | $1600 | New |
New claim 2 | 1/1/2021 – 1/1/2021 | 1 | 0.88* | $200 | New |
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/modifiedThe 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.
Level | Modified / Split | Field |
Claim | Modified | From date of service |
Claim | Modified | To date of service |
Claim | Modified | Statement from date (institutional claims only) |
Claim | Modified | Statement to date (institutional claims only) |
Claim | Split | Total billed amount |
Claim | Split | COB – Other payer paid amount (per payer) |
Claim | Split | COB – Remaining patient liability (per payer) |
Claim | Split | COB – Non covered amount (per payer) |
Claim | Split | COB – Adjustment amount (per payer) |
Claim | Split | COB – Adjustment units (per payer) |
Line | Modified | From date of service |
Line | Modified | To date of service |
Line | Split | Billed amount |
Line | Split | COB – Other payer paid amount (per payer) |
Line | Split | COB – Other payer paid units (per payer) |
Line | Split | COB – Adjustment amount (per payer) |
Line | Split | COB – Adjustment units (per payer) |
Line | Split | COB – 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 yearsIn 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
Line | Dates of Service |
Claim level | 12/29/2020 – 1/1/2021 |
1 | 12/29/2020 |
2 | 12/30/2020 |
3 | 12/31/2020 |
4 | 1/1/2021 |
- Split claim 1
Line | Dates of Service |
Claim level | 12/29/2020 – 12/31/2020 |
1 | 12/29/2020 |
2 | 12/30/2020 |
3 | 12/31/2020 |
- Split claim 2
Line | Dates of Service |
Claim level | 1/1/2021 |
1 | 1/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 yearsIn 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
Line | Dates of Service |
Claim level | 12/29/2020 – 1/1/2021 |
1 | 12/29/2020 – 1/1/2021 |
2 | 12/29/2020 |
3 | 12/30/2020 |
4 | 1/1/2021 |
- Split claim 1
Line | Dates of Service |
Claim level | 12/29/2020 – 12/31/2020 |
1 | 12/29/2020 – 12/31/2021 |
2 | 12/29/2020 |
3 | 12/30/2020 |
- Split claim 2
Line | Dates of Service |
Claim level | 1/1/2021 |
1 | 1/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.
Previous topic Third party liability edits Next topic Episode processing