The AccumBLProcessing collection has the steps shown above and described below:

1. Ignore this step. It is included to create the benefit limit accumulators for testing purposes through the TestLimit data transform rule.
2. This step checks whether there are any limits found for each of the claim lines reported on the claim. The CheckLimitsFound When rule is called to perform this check. If it returns false, then the entire collection is stopped and no further limits processing is done. There are no limits found for this claim.
3. This step checks if there are any specific pends set earlier in the claim processing. At the same time, it checks if there are any audit history entries made before the claim processing. Then it clears two page list values.
4. This step retrieves the list of matching benefit limits already existing in the accumulator manager. The RetrieveBLimitAccum data transform rule is used to perform the search activity. This data transform iterates over Claim.ClaimLine list to retrieve the corresponding benefit limit accumulators.

If the search result count is 1, then it checks the status of the accumulator, whether it is active or not. If the status is active, it calculates the delta value and then copies the details into the in-process accumulator placeholder. If the status is exhausted, then it checks for the re-ordering scenario.

If the current claim line’s (claim line which is requesting for units from the currently matched benefit limit accumulator) date of service is earlier than (less than) that of the claim line of the claim which has exhausted the accumulator that was returned in the search result, then it sets the re-ordering pend.

If the search result count is greater than 1, it checks the number of active matching benefit limits accumulators. If there are multiple active accumulators found, then it sets the pend as Multiple active accumulators found. If there is only one active accumulator, then it calculates the delta value and other parameters as required and copies those details into the in-process accumulator placeholder. If there are no active accumulators, then it checks for exhausted accumulators matching the criteria. If it finds any results (zero or greater), then it sets the pend that Benefit limit accumulator is exhausted and also checks for the re-ordering scenario as explained above.

If the search result count equals 0, then it creates a new accumulator rule. The CreateBenefitAccum data transform rule is called to create new accumulator along with header and transaction details. It copies those header and transaction details into the in-process accumulator placeholder.

If there are any limits of other than Units limit type entries found in the claim.claimline.limitfixed place, then it adds an audit that Claim engine would not support these accumulators.

1. After performing the above mentioned process, copy the in-process accumulator records to BenefitAccumsToCommit page list, which refers to the list of accumulators being committed to the database.
2. In Step 6, Smart Claims Engine adds respective Event codes for benefit limit accumulators processing.
3. In Step 7, Smart Claims Engine adds respective audit history entries for benefit limit accumulator processing.