Policy Process Flows

When a user or a process creates a new policy, or modifies an existing one, that policy moves through a series of steps to approve the policy. Each step applies multiple rules and checks that a changed policy needs to pass. These rules and checks ensure that the data is correct, ensure that the data is complete, and detects changes in an active enrollment record.

The Oracle Health Insurance application provides a framework for these rules and checks. The user configures the business logic for each rule and the ordering that each rule follows in a step. Such a sequence of rules is called a Process Flow. The application supports multiple process flows. For example, a different flow for each line of business.

Each process flow has two layers: process steps and rule steps. A sequence of a process steps builds a process flow and each process step comprises rule steps. This page describes configuration methods for process flow, process step, and rule step.

Policy Process Flow

Following are fields that create a policy process flow:

Table 1. Policy Process Flow

Field	Description
Code	The code of the policy process flow
Description	The description of the policy process flow
Default?	Is this the default policy process flow?
Active?	Is this policy process flow currently available?
Line of Business	A code and description of the line of business

Policy Process Step

Table 2. Policy Process Step

Field	Description
Process Flow	The reference to the policy process flow
Sequence	The sequence of the process step
Display Name	The display name of the process step
Type	Apply Rules, Detect Changes, Pend for File Review, Send Pre Approval Notifications (Or) Revert
Revert First version of Policy?	If the process step of type 'Revert' is set, then should the policy with 1st version to be reverted? Yes No
Access Restriction	The access restriction restricting pend resolution in the process step

The sequence of the process step determines the order in which the steps are executed. It is not possible to have multiple process steps with the same sequence.

• If the step type is set to Detect changes, then the system performs the policy version compare function. Only one process step in a process flow can be set to Detect changes.

• If the step type is set to Send Pre Approval Notifications, then the system collects all the 'Enrollment Event Notifications' in the context of the policy which are in status 'Ready' and sends the linked 'Notification Payload' to the configured end-point. Refer End-point configuration.

  • This step should only be configured post 'Detect Changes' step.

  • Only one process step of type 'Send Pre Approval Notification' can be set.

• If the step type is set to Pend for file review, then the system checks if the enrollment file is still under review or not. This possible results in the policy pending file rile review. Only one process step in a process flow can be set to Pend for file review.

• Execution of a policy process step may result in a policy to be 'Pended': the processing of the policy gets suspended for manual intervention.

• It is possible to attach an access restriction that defines who can resolve the pend reasons that are attached in that step.

• If the step type is set to Revert, then system checks the generated enrollment event notifications if 'Revert' flag is set to 'Yes' on the 'Notification Definition'.

  • This step should only be configured post 'Send Pre Approval Notifications' step.

  • Only one process step of type 'Revert' can be set.

Refer Enrollment Event Notifications for more information on processing of notifications.

Rule Steps

Rule steps identify which process rules (Policy Callout Rules, Pend Rules and Policy Validation Rules) the system executes within a process step, and the order of execution within the step. A process step can have one or more rule steps.

Process rules can be added to a process step that has the same process flow as the process step, or that has no process flow. Process rules without a process flow value can be included in multiple process flows (as they are not restricted to having the same process flow as the process step).

Table 3. Rule Steps

Field	Description
Process Step	The process step that the rule step belongs to
Sequence	The sequence within the process step in which the rule is executed (not applicable for Pend Rules)
Callout Rule	The callout rule that is executed within the process step
Policy Validation Rule	The policy validation rule that is executed within the process step
Pend Rule	The pend rule that is executed within the process step

Policy Process Steps can have callout rules, pend rules and policy validation rules. Callout rules and validation rules have a sequence within the process step. The sequence determines the order in which the rules are executed within the process step. It is not possible to have multiple process rules (callout rules, and policy validation rules) for the same process step with the same sequence. Pend rules do not have a sequence within a process step; they are executed after the execution of the call out rules and validation rules. It is not possible to have the same pend rule multiple times for the same process step.

Exclude Attribute

A policy process rule can initiate a compare action between a policy version, and the last approved version of the policy. It is possible to define a list of attributes which are not part of the compare process. The compare process ignores the attributes listed in this entity.

Excluded attributes are stored as a comma separated list, without any spaces in between.

Table 4. Exclude Attribute

Field	Description
Subject	The subject for which fields are exluded (for example, Policy)
Field List	A list of fields in the subject which are excluded from the compare