Process Rules

The process rules in Oracle Health Insurance Authorizations are configurable. The user can configure the process rules by supplying 2 levels, process steps and rule steps. Process steps form the highest level. A process step can contain of a number of underlying rule steps. A rule step can be a

• callout rule, to call out to other components with a request and receive a response that can used in processing the authorization

• event rules, to notify other components of what is happening during the processing of an authorization or trigger automatic actions

• validation rules, to validate the contents of the authorization request or to derive processing outcomes or to look up additional information

• pend rules, to stop the automatic processing of the authorization and so that control can be handed over to a user for a manual action

The system executes the Process Steps in the order as specified by the user. Executing a process step consists of evaluation and execution of the rule steps in that process step. The user can configure the order in which the rule steps are executed but within a Process step, Pend rules are always executed last.

For more information on the configuration of the process steps, rule steps and the various types of rules refer to the chapter "Process Rule Configuration" in the Configuration Guide.

The processing flow is shown in the image below:

The subsequent sections describe the processing details of each type of Rule Step. Once all the Rule Steps are executed successfully the system marks the process step as complete and moves to the next configured process step. The system moves to the finalize step after the last process step is executed.

Also, the system may move to the finalize step without executing the next configured process steps if there is a message of severity 'Fatal' on the authorization. However, presence of an authorization message of severity 'Fatal' does not stop the subsequent Rule Steps from getting executed within a process step.

Rule Steps

During processing of a process step - the callout, event and validation rules are evaluated, based on the configured execution order (sequence) and then all the pend rules are evaluated. A rule step is not evaluated when the indicator enabled on the rule is set to 'No'.

The execution of a rule must be completed successfully (that is without a technical error) before the next rule (this can be a callout rule, an event rule, a validation rule or the pend rule(s)) is executed.

Callout Rule

When an authorization reaches a step in the processing for which a callout rule has been defined, the condition dynamic logic on the callout rule is evaluated to determine if the rule is applicable; if the condition evaluates to true, the callout rule is executed. The execution of a callout rule consists of sending a request message and receiving an response message. The request and response message and the processing logic for the response message of a callout rule are configurable and is done through one dynamic logic function.

Performing the Callout

The dynamic logic function of the callout rule is responsible for creating a request message. The logic then sends the created request message to the external system’s endpoint. The end point is configurable per callout rule.

The external system is required to return its response message immediately. Upon receiving the response message from the external system the same dynamic logic processes it.

Once this process is done, an authorization callout history record is created and the timestamp of when the callout was started and the timestamp of when the callout was ended is logged.

Event Rule

The system publishes an event message to an external system through Outbound Restful Service Invocation for every applicable event rule. An event rule is considered applicable when the specified fixed criteria on the rule are satisfied and the dynamic logic condition evaluates to true. The system will not evaluate the event rule when the reraise indicator is set to 'No' and an authorization event history record exists with the same 'topic' and 'event'.

The system creates an authorization event history record for the event rule that is applied successfully when the log event indicator is set to 'Yes'.

Validation Rule

The validation rule facilitates the business to perform specific checks on the data elements of the authorization. Together with call out rules, validation rules form the central processing concept for authorizations.

Typically, a call out rule will fetch information from another component on, for example, pricing information or benefits or fraud detection. This information will then come back to Oracle Health Insurance Authorizations and be stored there so that it can be used in a validation rule. The validation rule may use solely information on the Authorization, information provided by the callout rule or it may invoke pre-configured reference sheets. In these reference sheets, the information can be linked as dimensions to actions like messages or to the adjustment of the authorized amount.

Of course, validation rules just using reference sheets without any call out being made, are also possible.

When the dynamic logic condition on the validation rule evaluates to true, the specified message is attached to the authorization and the system also executes the dynamic logic function defined on the rule. The authorization message is attached with the indicator processing set to 'Yes'. The indicator inherit on the authorization message is set as per the configuration on the validation rule.

Pend Rule

In certain circumstances it might be necessary to pend an authorization for manual intervention, for example when a very high value is requested or if the person or object does not have an enrollment product for all the procedures for which the authorization is requested.

The system evaluates all the configured pend rules for a process step. The pend rule describes the circumstance in which an authorization pends. When the specified fixed criteria on the pend rule are satisfied and the dynamic logic condition (if specified) evaluates to true, the pend is said to be applicable. The pend rule is not evaluated if the suppressed when fatal indicator is set to 'Yes' and a fatal authorization message exists.

If the pend rule applies, the pend reason is attached to the authorization. Exceptions to this behavior are

1. When the reattach indicator on the pend reason is set to 'No', then the system looks at the authorization pend history and checks if the authorization has ever been pended before for the same pend reason (irrespective of the process step) and has been resolved by the user. If such a history exists then the pend reason is not attached to the authorization.

2. When the pend reason already exists for the current process step from earlier processing iterations, then the same pend reason is not attached again.

The system always keeps pend reasons that are not resolved during earlier processing iterations even if the pend rule does not apply during the reevaluation of the process step.

When one or more pend reasons exist for the authorization for the current process step, the system checks if any of these pend reasons are required to be published to an external system (publish message indicator set to 'Yes'). If so, the system communicates the pend reasons with a publish message indicator set to 'Yes' in the pend event message. The pend event message is sent out through Outbound Restful Service Invocation. The system then sets the status of the authorization to 'Pended' and adds a status history record and pend history records for all pend reasons that were raised in the current process step.

The processing gets suspended so that a user can manually intervene in the processing of the authorization.

User Actions and Processing

In the View and edit authorizations page a user can select one of the following actions (links) when authorization is pended.

Resolve pends and submit - This action results in the removal of the authorization pend reasons related to the process step and the authorization pend history records get updated as resolved. The authorization status is set to 'In Process'. If the process step where the authorization got pended is the last step, then the processing moves to the finalize step otherwise the system evaluates the next process step.

Deny authorization- This action results in the removal of all the authorization pend reasons. The authorization pend history records get updated as resolved. The processing moves to the finalize step.

Edit authorization - The authorization is brought to the status 'Change'. If the authorization is set back to the 'Change' status in the user interface page, the pend reasons that are attached to the authorization remain on the authorization (unresolved) and new pend history records are created for all attached pend reasons. If the authorization is set back to the 'Change' status through the integration point, all authorization pend reasons are removed; they are not marked as resolved in the authorization pend history.

When the user submits or denies an authorization, the system sends out a 'Pend Done' event message to the external system through Outbound Restful Service Invocation, if any of the pend reasons were published to an external system (publish message indicator set to 'Yes') so that the external system can take appropriate actions.

Processing Technical Errors

When a technical error occurs the execution of the process step stops. Examples include a connection with the external component that cannot be made (system is down) or the dynamic logic for creating the request message having a bug. The authorization then remains halted in its current location in the flow.

Any operations performed by a process step that runs into an error are rolled back (that is undone and no history records created). However, when a process step runs into an error, this does not roll back operations performed by process steps that were executed previously.

If an authorization is halted in the process because of a processing error, the cause of this processing error must be resolved. After that, execution of the process step for the authorization can be retried. This can be done by using the UI page for (re)processing technical errors (in the operations menu of Oracle Health Insurance Authorizations).

The halted authorization can also be re-processed from the Authorization In IP. In this case the authorization is brought back to 'Change' status for re-processing.

An authorization that is halted in the process because of a technical error cannot be manually unhalted using the View and Edit Authorization UI page.