Bypassing automatic split claim functionality
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
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.
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.
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.
Previous topic Bypassing manual split claim functionality