Routing Slips

The purpose of this appendix is to clarify how the routing slips interact with the ability to keep processing results (keep benefits?, keep pricing? indicators).

Introduction

This appendix holds a number of scenarios. Each scenario shows an image of a flow diagram. Each flow diagram shows two junctions. At each of these junctions Claims checks the claim to see whether the claim stays in for further processing or the claim should be sent out to another SOA component. Each of the junctions relates to a specific part of the process , that is, claim pricing and applying claim benefits.

Claims cannot not derive that a claim has passed a pricer, or benefits component by looking at the fields on the claim, since it is perfectly possible that a claim passes through a component without undergoing changes. For example, when a claim is repriced, the new price might be equal to the previously calculated price. So, instead, Claims expects that each process component in the architecture flags the claim to let other components know that the task it is responsible for, is done, regardless of the result.

These flags are indicators on the claim header:

indPricingDone
indBenefitsDone

These indicators are referred to as a claim’s routing slips. Claims interprets a checked routing slip as: "This claim has passed the component responsible for pricing/benefits and so it is not necessary to (re)do that specific task." An unchecked routing slip is interpreted as that the claim still needs pricing/benefits.

In this case a claim ends up in Claims and it has an unchecked slip, the value of two other indicators are considered:

indExternalPricing
indExternalBenefits

These indicators specify whether the task at hand has to be executed by Claims or another by component in the SOA. In this context, external means outside of Claims. For example, if a claim pricing routing slip is unchecked, and the claim species that pricing is external, then Claims sends the claim out for pricing using the pre-finalized claim integration point.

The external indicators can be set (1) upon entry of the claim and (2) by process field derivation rules (refer to text on derivation rules in the implementation guide on process rules). Note that they cannot be updated in the UI. When not set explicitly upon entry, the external indicators default to: indExternalPricing "checked" and indExternalBenefits "unchecked".

Claims versus lines

In a claims processing architecture, the different components that make up the processing chain commonly communicate with each other in terms of claims. After all, this is also the granularity of communication beyond the borders of the architecture, that is, a provider sends in a claim, and expects a payment, explanation and/or specification per claim.

When Claims determines that a claim needs pricing, it sends out the whole claim. Once that claim has passed the components responsible for pricing, Claims expects the whole claim to be returned. When a claim returns the 'old' copy of the claim, that is, the copy that was sent out, is replaced by the new copy of the claim. Subsequently, the claims flow within Claims is restarted. The only information that remains intact on the old, existing claim is the status and pend history of the claim. Also, in some specific cases, an existing claim line’s pricing result or even the entire existing claim line is retained.

The SOA components responsible for processing claims communicate with each other in terms of claims. In contrast, the bulk of the processing takes place at the more granular claim line level. Processing results are stored per claim line, not per claim. Claims offers the ability to keep pricing and/or benefit results on a line by line basis. The reason for keeping the results is that an operator manually edited the price and or benefit results, and does not want Claims to overwrite these manual edits when Claims receives a new copy of a claim. For example, within the same claim, one line may have been automatically priced by a (non-Claims) pricer component, while the next line has been manually priced within Claims, and has been marked so that the result of that manual operation should remain intact. More than often the desired result would be that the automatically re-priced line replaces its old counterpart in the claim, but that the manually edited existing line is retained and that its repriced counterpart in the new copy is ignored.

Send out or keep in?

When a claim is initially processed, everything happens in a set order. This is the happy flow. Claims that are partially automatically priced, and partially manually priced do not present any unusual issues. It is when such a claim needs to be reprocessed that things become more complex. The key question that requires an answer is: does the reason for reprocessing the claim also warrant a send out for re-pricing?

By default, Claims behaves in the following way: claims that are returned to an earlier part of the flow will ALWAYS have their routing slips reset. For example. consider a claim which has been externally priced (indExternalPricing=Y) and for which benefits have been calculated by Claims (indExternalBenefits=N). The routing slips then read: indPricingDone=Y, indBenefitsDone=Y. If this claim is changed in Claims, it will get its routing slips reset: indPricingDone=N, indBenefitsDone=N. Thus the claim will be sent out for repricing.

Routing slips are reset up to the part of the flow to which the claim is returned. For example, when a claim is set back from adjudication to pricing or change, both indPricingDone and indBenefitsDone will be reset to N. However if a claim is set back from adjudication to benefits, only indBenefitsDone will be reset to N.

Note that the Claims In integration point has the ability to recognize claim lines which have had manual edits to the pricing and/or benefit calculation results and can retain those results if desired. In other words, manual edits can be retained even when Claims receives a new copy of that claim.

Keep in mind that a claims operator can also decide to re-check the routing slips in the Enter Change Claim page, effectively preventing the claim from being sent out for repricing. Note that routing slips values are not interdependent in such a way that checking or unchecking one routing slip, automatically checks or unchecks another routing slip. For example, when an operator checks the benefits routing slip, Claims does not automatically also check the pricing routing slip. This is the responsibility of the claims operator.

Manual Unfinalize

The image shows possible flows in the situation that a claim is manually unfinalized:

1. The operator opens the Unfinalize Claim page for the finalized claim, picks an unfinalize reason and unfinalizes the claim.
2. Claims changes the status of the claim to CHANGE. The routing slips for pricing and benefits are unchecked
3. The Enter Change Claim page opens, displaying all routing slips unchecked.

The green flow reflects the default behavior of Claims:

4. The operator does not touch the routing slips and resubmits the claim.
5. Because the claim pricing routing slip is unchecked, and pricing is external (to Oracle Health Insurance) the claim is sent out.
6. The claim is priced outside of Claims.
7. The claim reenters Claims through the claims in integration point, with the pricing routing slip checked.
8. The claim’s benefits are calculated and the claim re-finalizes.

The red flow reflects what happens if the operator decides to override the default behavior

4. The operator rechecks the routing slip for pricing and resubmits the claim.
5. The claim is kept in, using the existing pricing results.
6. The claim’s benefits are calculated and the claim re-finalizes.

Unfinalize through Reprocessing IP

The following scenarios focus on the flow of claims unfinalized by the reprocessing IP.

Request with checked routing slips

Claims receives a request to reprocess a finalized claim. The request specifies that the claim’s pricing routing slip remains checked.
The claim is unfinalized, the claim status is set to INITIAL and the pricing routing slip remains checked.
The claim is kept in, using the existing pricing results.
The claim’s benefits are calculated and the claim re-finalizes.

Request with unchecked or unspecified routing slips

Claims receives a request to reprocess a finalized claim. The request either specifies that the claim’s pricing routing slip is to be unchecked, or the routing slip isn’t specified at all.
The claim is unfinalized, the claim status is set to INITIAL. Alternatively, if the reprocessing request contained pend reasons, the claim is set to CHANGE. Either way, the pricing and benefits routing slips are unchecked.
Assuming the request contained no pend reasons, and because pricing is external (to Oracle Health Insurance), the claim is sent out.
The claim is priced outside of Claims.
The claim re-enters Claims through the claims in integration point, with the pricing routing slip checked.
The claim’s benefits are calculated and the claim re-finalizes.

Sending Back A Pended Claim

The image shows the possible flows in the situation that a claim is pended for manual adjudication:

1. The operator opens the Manual Adjudication page for the pended claim, selects the action "Change claim" and clicks on Ok.
2. Claims changes the status of the claim to CHANGE. The routing slips for pricing and benefits are unchecked
3. The Enter Change Claim page opens, displaying all routing slips unchecked.

The green flow reflects the default behavior of Claims:

4. The operator does not touch the routing slips and resubmits the claim.
5. Because the claim’s pricing routing slip is unchecked, and pricing is external (to Oracle Health Insurance) the claim is sent out.
6. The claim is priced outside of Claims.
7. The claim re-enters Claims through the claims in integration point, with the pricing routing slip checked.
8. The claim’s benefits are calculated and the claim re-finalizes.

The red flow reflects what happens if the operator decides to override the default behavior

4. The operator rechecks the routing slip for pricing and resubmits the claim.
5. The claim is kept in, using the existing pricing results.
6. The claim’s benefits are calculated and the claim re-finalizes.

Overwriting a Claim

When Claims receives a new copy of an existing claim, the claim status of the existing copy is also irrelevant. The existing copy is replaced by the new copy. The values of the routing slips are as specified by the new copy.

The claim line codes in the claim request and the claim line codes in the old copy of the claim are compared. If a match is found, the keep pricing and keep benefits indicators are compared. If both lines have a checked keep pricing indicator, then the allowed amount and allowed number of units of the existing claim line will be retained, and the allowed amount and allowed number of units in the claim request will be ignored. If both lines have both a checked keep pricing indicator and keep benefits indicator, then the entire existing claim line is retained, and the matching claim line in the claim in request message is ignored.

In the scenario portrayed by the image, it is assumed that the new copy has a checked pricing routing slip. The claim is not sent out.

Keep Benefits Checked

This flow shows the effect of checking the keep benefits indicator on the claim line.

The effect of checking the keep benefits indicator is that the benefits aren’t recalculated nor are the external intervention rules triggered, for that particular line. Note that because other lines (or even the claim itself) may still cause a pend, it remains possible that a line with the Keep Benefits indicator checked ends up in manual benefits.

The operator opens the Unfinalize Claim page for the finalized claim, picks an unfinalize reason and unfinalizes the claim.
The application changes the status of the claim to CHANGE.
The Enter Change Claim page opens, displaying the routing slips.
The operator checks the pricing routing slip.
The claim is kept in, using the existing pricing results.
Lines that have a checked Keep Benefits indicator are not touched and do not cause pends. All other lines are recalculated and may still cause the claim to pend.
The claim re-finalizes.

Benefits Done Checked

This flow shows the effect of checking the benefits routing slip.

The effect of checking the benefits routing slip that the claim isn’t recalculated. The purpose of unfinalizing in order to reprocess it, but without actually recalculating its benefits could be that the claim only requires a manual edit on the "old" benefits. When an operator checks the benefits routing slip, it stands to reason that the operator also checks the pricing routing slip.

The operator opens the Unfinalize Claim page for the finalized claim, picks an unfinalize reason and unfinalizes the claim.
The application changes the status of the claim to CHANGE.
The Enter Change Claim page opens, displaying the routing slips.
The operator checks all routing slips and resubmits the claim.
The claim is kept in, using the existing pricing and benefits results. Even though the application does not recalculate the claim, it may still pend for manual benefits.
The claim re-finalizes.