Policy Callout Rules

By defining policy callout rules, the services provided by external components can be called from within the policy processing flow. The Callout is triggered during the processing of a policy when it encounters a callout rule. Essentially a callout can be set up by specifying the definition of the callout interface plus the conditions under which it is to be executed; together, they form the callout rule. The callout interface works by sending a web service request and receiving and processing the response. By using the flexibility of dynamic logic, any externally authored XML schema definition can be adhered to.

The setup of callout rules is a combination of functional setup in a UI page of Policies and technical setup:

  1. The system property ohi.<0>.endpoint.request defines the destination URL. The placeholder value is the code of the callout rule.

  2. The system property ohi.service.<0>DOC-221.client.authentication defines the authentication type. The placeholder value is the code of the callout rule.

No system properties exist to set the media type and the HTTP method for callout rules. Those are set in the dynamic logic function. Because of this, the media type and the HTTP method are not shown in the outbound integration point IP for callouts either.

Presented below are the fields of the functional setup.

Table 1. Policy Callout Rules
Field Description

Code

The identifying code of the callout rule (this code is used in the specification of technical configuration parameters. Refer to Property Management for more information on setting a property.)

Description

The description of the callout rule

Source

The source of the policy: Integration Point, User Interface or Either

Condition

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

Function

The dynamic logic function that is executed to handle the callout

Process flow

The process flow to which this callout rule is restricted

Exclude from Validation?

Is the callout rule excluded from the validation process?

Enabled?

Is the callout rule enabled?

The use of a policy callout rule can be restricted to a single policy process flow. If the rule’s process flow has no value, the callout rule can be used in any process flow.

Because response logic is always specified (within the function), the external component is required to send back a response, including a message body (for example, not just an HTTP 200 status code).

Process

Policy callouts are executed as part of the Policy Processing Flow, which can be configured with the process steps and can have one or more Rule steps like Validation or Pend rule.

This can be executed in the order as configured, as there is no fixed position of the callout in the process flow.

Asynchronous Message

Sending the Request Message

The dynamic logic condition that is executed for a policy 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 with the dynamic login function that is executed to handle the callout.

Processing the Response Message

The external component sends its response message later to the Policy Callout Integration Point.

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

  • Policy update request messages are processed and policy callout first check for:

    • Exclude from Validation? Where the Policy callout rule is restricted.

    • Enabled? Policy Callout rule is enabled.

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

Policy Callout History

The processing of policy callout rules is tracked in the policy callout history. Policy callout history is visible in the Policy UI pages. A policy callout history record is created when a callout rule is executed. A callout history record is then linked to the policy’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 policy operators also to see callouts that ran into processing errors.

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