Claim Callout Rules

By defining claim callout rules, the Claim Callout Integration Point can be triggered at certain fixed points in the claims flow. Using callouts, services provided by external components can be called from within the Claims Flow. Examples of such services are editing of claims by an external editor and grouping of claim lines by an external DRG grouper.

This text describes the rules that are used to call out to external components. Essentially a callout can be set up by combining the definition of the callout interface, with the conditions under which it is to be executed: the claim callout rule.

Refer also to the text on the Claim Callout Integration Point for more technical details of callouts.

Concepts

A claim callout rule halts a claim at a certain point in the claims flow, for the execution of an interface with an external component. The callout interface works by sending a web service request and (optionally) receiving and processing the response. Both the creation of the request message and the handling of the response message are coded in pieces of dynamic logic. By using the flexibility of dynamic logic, any externally authored schema definition can be adhered to.

Consider the following DRG grouper example to understand callout rules:

Before progressing to the Pricing part of the claims flow, inpatient claims must be passed through a DRG grouper, in order to determine the DRG with which to price the claim (where applicable). As such a callout rule may be set up to trigger before pricing on yet ungrouped inpatient claims, using "DRG Grouper Request" dynamic logic to create the request message. When the callout rule is triggered for a claim, an actual request message with information on the claim is created and sent to the DRG Grouper component. The DRG grouper component determines the DRG and sends back a response message with the DRG. The callout rule specifies "DRG Grouper Response" dynamic logic to handle the response message, read the DRG from it and to set that DRG in a dynamic field on the claim header. After that, the claim continues in the claims flow and can now be priced using the DRG.

Claims Update Responses

Dynamic logic used by callout rules for processing response messages is limited to:

  1. setting the values of dynamic fields

  2. adding messages to the claim.

Where it is desirable to perform other actions on the claim, e.g. update native fields, instead of using dynamic logic to process the response message, the Claims Update IP request message can be leveraged. The response message must then adhere to the Claims Update IP definition. The callout rule response mechanism (implemented by the Claim Callout Integration Point) will process such responses as 'regular' Claims Update IP requests.

Fields

The setup of a callout definition is a combination of functional setup in a UI page of Claimsand technical setup. [1]. Presented below are the fields of the functional setup.

Callout Definition

Table 1. Callout Definition
Field Description Mandatory?

Code

Identifying code. This code is used in the specification of technical configuration parameters. Refer to Property Management for more information.

Y

Description

The description of the callout definition.

Y

Messaging Pattern

The messaging pattern of the callout definition:

  • Synchronous: upon executing the callout, the response of the external component is required immediately.

  • Asynchronous: upon executing the callout, the response of the external component is not required immediately. Rather Claims will wait until the response has been received. The amount of time Claims will wait before raising a time-out error is configurable.

Y

Request Logic

The dynamic logic that is executed to create the request message that is to be delivered to the external component by the callout.

Y

Response Logic

The dynamic logic that is executed to process the response message of the external component.

N

Active?

Is the Callout Definition still in use?

Y

Specifying the response logic is optional. Leaving it empty has a different meaning for synchronous and for asynchronous messaging:

  • Synchronous messaging: The response is not processed. This can be useful for implementing fire-and-forget callouts where the response of the external components is not of interest.

  • Asynchronous messaging: The response is only processed if it is a Claim Update message.

If response logic is specified, the external component is required to send back a response including a message body (e.g. not just a HTTP 200 status code).

Note that callout rule definitions which have been executed can no longer be deleted. If desired, they can be inactivated to prevent future use in claim callout rules.

A callout definition is referred to by claim callout rules. A claim callout rule specifies the conditions under which the callout is to be executed for a claim:

Claim Callout Rule

Table 2. Claim Callout Rule
Field Description Mandatory?

Step

The step in the claims flow in which the callout is to be executed. This can be any of the following fixed steps:

  • Pre Classification (message origin PRE PRICING)

  • End Classification (message origin PRE PRICING)

  • End Pricing (message origin PRICING NO RECALCULATION)

  • End Benefits (message origin BENEFITS)

Y

Sequence

In the event of multiple claim callout rules, the sequence specifies the order in which these rules should be executed.

Y

Classification Scheme

The callout rule is only executed for claims that have been classified using this classification scheme.

N

Condition

The dynamic logic condition that is executed to determine if the callout rule must be executed for a claim

N

Callout Definition

The callout definition that is executed if the conditions are met

Y

Skip Tag

The skip tag that will be attached to claim lines and messages as a result of the callout rule

N

Only on Change?

Should the claim callout rule only fire after a manual change?

Y

Display in UI?

Should the claim callout be shown in the UI?

Y

Enabled?

Is the callout rule enabled?

Y

Processing

When a claim reaches a step in the claims flow for which one or more callout rules have been defined (see possible steps above), each of those callout rules is evaluated to determine if it applies to the claim. In other words, the step, classification scheme and condition are evaluated to see whether a claim callout rule is applicable. Even if a callout rule is applicable, it may be that the callout rule is not actually executed. The reason is to allow a claim to (re)execute a callout to prevent unnecessary traffic or not to loose edits and overrides.

This (re)execution is steered by a combination of the skip tag and the indicator only on change of the callout rule plus the claim tag actions which are stored on the claim. The execution of the callout is prevented if one of the following situations occur:

  • the callout rule refers to a skip tag that has claim tag action 'Skip'

  • the callout rule refers to a skip tag that has claim tag action 'Hold'

  • the indicator 'Only on Change'?is checked and the claim has not reached the CHANGE status since the last finalization where an operator has made some sort of change in the Manual Change page. The proviso on reaching the CHANGE status thus excludes claims that are new as well as claims that are reprocessed through the Reprocessing IP or Claims Update IP.

  • the callout rule refers to a skip tag that still exists on the claim. This is to prevent that a line as "Keep Pricing" is marked (so that no reversal of edits took place) and later unchecked "Keep Pricing" in the Manual Pricing page, the claim is sent out.

If any callout rules apply, the claim is halted at its current location in the claims flow (the claim’s status is not changed). The callout rules that apply to the claim are then executed sequentially, in order of their specified sequence. The execution of a callout rule must have been completed successfully before the next callout rule is executed. When all callout rules have been successfully executed, the claim continues in the claims flow from its current location. Exception to this is when the response is cast as a claims update request, in which case the claim is set back to status CHANGE (see details below).

Synchronous Messaging

Sending the Request Message

The "Request Logic" dynamic logic function of the callout definition is executed. As such, a request message is created and sent to the external endpoint of the callout.

If the callout rule does not refer to "Response Logic", execution of the callout rule is complete. Any response will not be processed.

If the callout rule refers to "Response Logic", execution of the callout rule continues with processing the response message.

Processing the Response Message

The external component is required to return its response message immediately. Upon receiving the response message from the external component, the "Response Logic" dynamic logic function of the callout definition is executed. The response message is available as a bind variable to the response logic (amongst other bind variables, refer to the description of the signature in the Dynamic Logic chapter in the Developer Guide).

Asynchronous Messaging

Sending the Request Message

The "Request Logic" dynamic logic function of the callout definition is executed. As such, a request message is created and sent to the external endpoint of the callout.

Execution of the callout rule continues with processing the response message. This happens even if no "Response Logic" was specified, because the Claims Update message may be used for the response, in which case custom dynamic logic is not needed.

Processing the Response Message

The external component sends its response message at a later time to the Claims Callout Integration Point.

The response may either be a Claims Update IP message or a custom message:

  • Custom response messages are processed like synchronous responses: the "Response Logic" dynamic logic function specified in the callout definition is executed with the response message available as a bind variable. If the callout definition does not specify "Response Logic", the response is not processed. The response message can update dynamic fields and add a message through a pre-defined method; if a message is added, then the new messages are given a skip tag if the claim callout rule has a reference to a skip tag.

  • Claims Update request messages are processed like this:

    • The claim is first set to status CHANGE.

    • The 'regular' Claims Update IP processing then takes place (refer to the description of the Claims Update IP in the Claims Flow chapter of the Operations Guide). Dependent on the submit indicator in the response message, the claim is either submitted to the claims flow or remains in status CHANGE

    • The execution of the callout rule is marked complete if the Claims Update IP processing completed without errors.

    • Note that because the claim is set back to status CHANGE any other applicable callout rules in the same step, that were not yet executed because of a higher sequence number, are effectively bypassed.

    • New claim lines and new messages are given a skip tag if the claim callout rule has a reference to a skip tag. For claim lines, this holds true for any added new claim line, be that a replacement or not. For messages, this holds true for any added messages. Using the indOverwriteMessage of the Claim Update IP, this could mean all messages (indicator set to Yes) or just the added one (indicator set to No).

    • A claim line (existing or new) is given a skip tag for allowed (the second reference to a skip tag) if the claim callout rule has a reference to a skip tag and the update request sets/changes the allowed amount and/or the allowed number of units. This supports the scenario that edits lead to an update of the allowed amount and/or allowed number of units of an existing claim line; without the second reference to a skip tag for allowed these lines could not be distinguished from new claim lines that were added by iCes. Note that if in this situation, there is an update of an attribute of an existing claim line not being the allowed amount or allowed number of units, then no skip tag is added to the claim line at all.

Processing Errors

Errors in processing callout rules may be both of a technical nature and a functional nature. Examples include:

  • A connection with the external component cannot be made (system is down)

  • The dynamic logic for creating the request message has a bug

  • The response to an asynchronous callout has not yet been received while the time-out limit has been reached.

  • A functional error message is raised while processing a callout response cast as a claims update request

When a processing error occurs, the execution of callout rules for a claim stops. The claim remains halted in its current location in the flow. If the processing error concerns a callout response cast as a claims update request, the claim status is reverted back from CHANGE to the status it had upon executing the callout rule (and halted in that status).

Any operations performed by a callout rule that runs into an error are rolled back (i.e. undone). Note that when a callout rule runs into an error, this does not roll back operations performed by callout rules that were (successfully) executed earlier in the same step.

If a claim is halted in the claims flow because of callout rules processing errors, the causes of these processing errors must be resolved. After that, execution of the callout rule for the claim can be 'retried'. This can be done by using the UI page for (re)processing technical errors (in the operations menu of Claims). Note that a claim that is halted in the claims flow because of pending callouts (whether still in progress or in error), cannot be manually unhalted using the Claims UI pages.

A failed callout rule is not reprocessed on its own. Rather, upon reprocessing a callout rule error for a particular claim, the processing of all callout rules in the same step is redone. The rationale for processing all callout rules again, versus only the failed one and yet unprocessed ones, is that the cause of the processing error may lie in the setup of any of the callout rules in that step. It is then safer to redo the entire processing of all callout rules in that step (for the concerned claim).

Where it is desirable to prevent a callout rule from triggering again, an appropriate condition can be coded on the callout rule. E.g. for the DRG callout rule a condition might be coded that checks that the dynamic field in which the DRG is stored, does not yet have a value.

Note that reprocessing of callout rules includes reselection and evaluation of whether a callout rule is applicable to the claim. This means that if the setup of a callout rule was changed, it may now not trigger and not be executed where it did in the initial processing (or the other way around).

Claim Callout History

The processing of claim callout rules is tracked in the claim callout history. Claim callout history is visible in the claims UI pages depending on the "Display in UI?" indicator of the callout rule. A claim callout history record is created when a callout rule is executed. A callout history record is then linked to the claim’s most recent status history record at that point in time.

Note that callout history records are created regardless of any errors that may be raised while processing the callout. This allows claim operators to also see callouts that ran into processing errors.

Also note that the presence of claim callout history does not preclude a callout from executing again (e.g. upon reprocessing the claim).

1. Refer to Property Management page of the System Administration guide for description of the technical setup. Note that the technical setup must be present in order to successfully execute a claim callout rule (otherwise a processing error is raised on applicable claims).