Process Policy

The policy processing flow is depicted in the image below:

Receive, Enter, or Edit Policy

A new policy can be received through the Policy In integration point (described in Policy Integration Point in the Developer Guide) or it can be manually entered in the Policy user interface page. An existing policy can be edited by sending in an update request through the integration point or by editing it manually in the Policy user interface page. The policy can be submitted for processing through the integration point, in the View and Edit Policy user interface page or by the Submit Policy activity. When it is submitted for processing, the status of the policy is changed to In Process (including the creation of a policy status history record for the In Process status), and the subsequent steps of the flow are automatically executed. These steps are described in the sections below. A detailed description of the statuses of policies (including the possible status transitions) can be found in Policy Statuses.

Note that if an existing policy is updated through the integration point, any existing policy messages and policy pend reasons are removed as part of the update.

Resolve Pend Reasons

The pend reasons that were attached in process steps for which the user has Pend Resolution rights are resolved: the policy pend reasons are removed and the 'Resolved By' and 'Resolved Date Time' attributes of the related policy pend history records are set. The pend reasons that were attached in process steps for which the user does not have Pend Resolution rights are not resolved; they remain on the policy until they are resolved by a user who is allowed to resolve them or until they are removed through the integration point (see Evaluate Pend Rules section).

Remove Messages

All messages that are attached to the policy are removed. These are messages that were attached to the policy during a previous processing cycle or during a validation of the policy.

Evaluate System Validation Rules

In this step a number of system validation rules are evaluated:

All enrollment products on the policy must have the same premium currency. If the currencies do not match, message POL-FL-PRPO-001 is attached to the policy.
If a premium override amount is specified on a policy enrollment product, the currency needs to match the premium currency specified on the related enrollment product. If the currencies do not match, message POL-FL-PRPO-002 is attached to the policy for every invalid policy enrollment product.
Relation identifiers must be unique across relations if the identifier type is defines as unique.

Table 1. Evaluate System Validation Rules
Code	Sev	Text
POL-FL-PRPO-001	Fatal	All enrollment products on the policy must have the same premium currency
POL-FL-PRPO-002	Fatal	The currency specified on the policy enrollment product for {insurable entity} with start date {policy enrollment product start date} does not match the premium currency specified on the related enrollment product {enrollment product display name}
POL-FL-PRPO-004	Fatal	The {identifier type} with this {identifier} already exists.

In the above messages {insurable entity} displays the following information:

If the insurable entity is a person: insurable entity type singular display name + person formatted name.

If the insurable entity is an object: insurable entity type singular display name + object description.

If at least one fatal message is attached to the policy during the evaluation of the fixed validation rules, the status of the policy is set back to Edit, and a new policy status history record for the Edit status is created. The pend reasons that are attached to the policy (if any) remain on the policy (unresolved) and new policy pend history records are created for all attached pend reasons for the Edit status. The user can then fix the errors on the policy that caused the fatal messages (if possible) and re-submit the policy for processing.

Determine Process Flow

The application supports the configuration of multiple policy flows. Each flow defines a sequential execution of user-defined process steps. These flows are:

Generic: Applicable to all lines of businesses
Specific: Tailored to a specific line of business Within each line of business (including the generic one), a default process flow exists.

The following cases outline how an application determines the appropriate process flow for a policy:

Case 1: If the policy refers to a process flow, the policy is processed according to that flow. ( NOTE: The process flow of the policy does not necessarily have to be the same for the line of business as the policy itself.)
Case 2: If the policy does not refer to a process flow and refers to a line of business, the application selects the default policy flow for that line of business.
Case 3: If the policy does not refer to a process flow, refers to a line of business, and there is no process flow for that line of business, then the application selects the default process flow without a line of business.
Case 4: If the policy does not refer to a process flow and does not refer to a line of business, the application selects the default policy flow without a line of business.

Table 2. Determine Process Flow
Case	Policy Refers to Process Flow?	Policy Refers to Line of Business?	Does Process Flow for LOB Exists?	Which flow is selected?
1	Yes	Not relevant	Not relevant	Referred flow
2	No	Yes	Yes	Default flow for LOB
3	No	Yes	No	Default flow without LOB
4	No	No	Not relevant	Default flow without LOB

Evaluate Process Steps

Upon submitting a policy, the system applies the user-configured rules, in the user-configured sequence, as specified by the selected policy flow.

A policy flow is collection of sequential process steps.Each process step is a subset of sequentially applied user-configured rules.The configuration of process steps is described in more detail in Policy Process Flows.

There are three types of rules: callout rules, policy validation rules and pend rules.

Callout rules and policy validation rules are applied in the user-configured sequence.Pend rules are always applied at the end of a process step.

Version Comparison, Send Notification, Revert and Enrollment File Status

A process step is of one of five possible types: Rules, Detect changes, Send Pre Approval Notification, Revert or Pend for file review.

If the policy process step type is set to Detect changes, the policy in process is compared with the active policy version. This process is described in detail in the section Compare Policy Versions.
If the policy process step type is set to Pend for file review, and the policy is linked to an enrollment file, then the following logic is applied:
- If the enrollment file status is …
  - ACCEPTED, then the policy continues with the next process step.
  - REJECTED, then the policy is reverted to the active version and any linked policy update request is rejected.
  - PENDING REVIEW, the policy transitions to the status PENDING FILE REVIEW and is suspended from further processing.

Depending on the 'Notification Definition' configuration, the next steps are configured and can result either in the policy being reverted, or process the policy.

If the policy process 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 Enrollment Event Notification Endpoint Configuration
If the policy process step type is set to Revert, then system checks if 'Revert' flag is set to 'Yes' on the 'Notification Definition' for all the generated enrollment event notifications.
- If 'Yes', then the policy is reverted to last approved version, the linked 'policy update request(s)' are set to a new status 'Processed Notification Sent'
- If 'No' or system does not find any notifications where the 'Revert' flag is set to 'Yes', then the next process step is triggered.
- For First version of policy
  - If 'Revert First Version of Policy' flag is set on the process step to 'Yes', then the first version of the policy is reverted/deleted.
    
    If set to 'No' then system does not revert or delete the first version of policy.

If a policy is reverted manually or due to any other process before the 'Revert' process step is triggered, then system sets 'Obsolete?' flag for all the notifications to 'Yes'.

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

Evaluate Callout Rules

When a policy reaches a step in the process for which one or more callout rules have been defined, each of those callout rules (the configuration of callout rules is described in more detail in Policy Process Flows) is evaluated to determine if it applies to the policy. In other words, the restrictions specified in the rule are evaluated to see whether it is applicable:

Source:
- If set to User Interface, the rule is only applicable for policies that are entered in the user interface (indManual on the attached policy data is set to Yes).

This also applies to policies entered in the user interface but submitted for processing through the integration point. Also, indManual can only be set to Yes to version 1 of the policy and cannot be set when an existing policy is updated.

If set to Integration Point, the rule is only applicable for policies that are received through the integration point (indManual on the attached policy data is set to No).

This also applies to policies received through the integration point but submitted for processing in the user interface.

If set to Either, the rule applies to both policies entered in the user interface and received through the integration point.
- Condition Dynamic Logic: if specified, the rule only applies to policies that meet the condition.

If a callout rule applies, the policy is halted at its current location in the process. The callout rule that applies to the policy is then executed. The execution of a callout rule must have been completed successfully before the following rule (this can be a callout rule, policy validation rule, or pend rule) is executed. Note that the callout rules are evaluated even if previous rules within the same process step have attached fatal messages to the policy.

The execution of a callout rule consists of sending a request message and receiving a response message. The request and response message and the processing logic for the response message of a callout rule are configurable (in one dynamic logic function). The dynamic logic function of the callout rule is responsible for creating a request message and sending the created request message to the external system’s endpoint. The endpoint is configurable per the 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.

Evaluate Policy Validation Rules

The policy validation rule facilitates the business to perform specific checks on the data elements of the policy (the configuration of policy validation rules is described in more detail in Group Validation Rules), for example:

Product A cannot go together with Product B on the same policy enrollment
The collection frequency on the policy must match the collection frequency (dynamic field) on the group account
The deductible must be a multiple of 250 and between 1000 and 3000 for group account A
Dynamic field A must be set in combination with dynamic field B
It is not allowed to set cost share parameters on policy enrollment product level if group account has value X for dynamic field A.

The policy validation rule is evaluated to determine if the policy, policy enrollments or policy enrollment products (depending on the level of the policy validation rule) are valid. In other words, the restrictions specified on the rule are evaluated to see whether it is applicable:

Source: same as for the callout rules
Condition Dynamic Logic: if specified, the rule is only applicable for policies, policy enrollments or policy enrollment products that meet the condition

If the policy, policy enrollment or policy enrollment product meets the above specified restrictions, the message of the policy validation rule (if specified) is attached to the policy (with the applicable placeholder values) and/or the function dynamic logic of the policy validation rule (if specified) is executed.

The dynamic logic function can set or update native field and dynamic field values of a policy, policy enrollment or policy enrollment product. This is described in more detail in the Functions chapter of the "Dynamic Logic" chapter in the Developer Guide.

Note that if the level of the rule is Policy Enrollment, the rule is evaluated per policy enrollment, which can result in multiple messages being attached to the policy and the dynamic logic function being executed multiple times. The same applies to rules with level Policy Enrollment Product. Also note that policy validation rules are evaluated even if previous rules within the same process step have attached fatal messages to the policy.

Fatal Messages

After evaluating all callout rules and policy validation rules within a process step, if at least one fatal message is attached to the policy, the status of the policy is set back to Edit and a new policy status history record for the Edit status is created. The pend reasons that are attached to the policy (if any) remain on the policy (unresolved) and new policy pend history records are created for all attached pend reasons for the Edit status. The user can then fix the errors on the policy that caused the fatal messages (if possible) and re-submit the policy for processing.

Evaluate Pend Rules

It might be of interest to the business to pend the policy for manual intervention in certain circumstances, for example, persons on the policy have different addresses. This is done by setting up pend rules. The pend rule describes the circumstance in which a policy pends (the configuration of pend rules is described in more detail in Pend Rules). When the specified criteria (see below) on the pend rule are met, the pend is said to be applicable:

Source: same as for the policy validation rules
Message: if specified, the rule is only applicable for policies that have this message attached to them
Message Group: if specified, the rule is only applicable for policies that have at least one of the messages in the message group attached to them
Brand: if specified, the rule is only applicable for policies that belong to this brand
Condition Dynamic Logic: if specified, the rule is only applicable for policies that meet the condition

If the pend rule is applicable, the pend reason specified on the rule is attached to the policy. The pend reason is not attached to the policy if it is already attached to the policy for the same process step (in the current or a previous processing cycle). The pend reason is also not attached to the policy If the 'Reattach?' indicator on the pend reason is unchecked and the same pend reason has already been resolved in the past on the policy (regardless of the policy version and process step).

Note that the evaluation of pend rules is skipped if one or more fatal messages were attached to the policy during the evaluation of the callout rules and policy validation rules, because in case of fatal messages the policy will be set back to the Edit status.

The evaluation of the pend rules can result in the policy being pended. A pended policy can be submitted for further processing or it can be set back to the Edit status. This is described in more detail (including an example) in the sections below.

Pend Policy

The policy is pended for manual intervention if any of the pend reasons that are attached to the policy have a reference to the process step that is being evaluated. These can be pend reasons that are attached in the current processing cycle or pend reasons that were attached in the same process step in a previous processing cycle.

The status of the policy is set to Pended and a policy status history record for the Pended status is created. Per pend reason that is attached (current and previous processing cycles) in the process step that is being evaluated, a policy pend history record is created that is related to the newly created policy status history record. Note that no policy pend history records are created for attached pend reasons that do not belong to the process step that is being evaluated.

If the policy is not pended, it proceeds to the next process step or to the Finalize Policy step if the current process step is the last user defined step.

Submit Policy

A pended policy can be submitted for further processing. Note that only users that have Pend Resolution rights for the process step in which the policy is pended can submit the policy for further processing.

When it is submitted for processing, the status of the policy is changed to In Process (including the creation of a policy status history record for the In Process status) and the pend reasons that were attached in the process step (current or previous processing cycle) in which the policy is pended, are resolved: the policy pend reasons are removed and the 'Resolved By' and 'Resolved Date Time' attributes of the related policy pend history records are set. Pend reasons that were attached in other process steps are not resolved. The policy then proceeds to the next process step or to the Finalize Policy step if the current process step is the last user defined step.

Edit Policy

A pended policy can be set back to the Edit status so it can be edited. In this case a new policy status history record for the Edit status is created.

If the policy is set back to the Edit status in the user interface page, the pend reasons that are attached to the policy remain on the policy (unresolved) and new policy pend history records are created for all attached pend reasons for the Edit status. If the policy is set back to the Edit status through the integration point, all policy pend reasons are removed; they are not resolved in the policy pend history. Note that if the policy is set back to the Edit status through the integration point any existing policy messages are also removed.

Pend Resolution Example

There are two user defined process steps configured both having a pend rule. Process step 1 has pend rule 1 (with pend reason 1). Process step 2 has pend rule 2 (with pend reason 2). There are four users that have Update rights on the View and Edit Policy user interface page, but that have different Pend Resolution rights:

User 1 (first pend operator) has Pend Resolution rights for process step 1
User 2 (second pend operator) has Pend Resolution rights for process step 2
User 3 (super user) has Pend Resolution rights for both process steps
User 4 (new user) has no Pend Resolution rights

A policy is entered and submitted for processing. The policy pends in process step 2. Pend reason 2 is attached to the policy and a policy pend history record is created for the attached pend reason for the Pended status. The different users can perform the following actions in this Pended status:

The first pend operator cannot submit the policy for further processing nor set the policy back to the Edit status
The second pend operator can submit the policy for further processing; he/she can also set the policy back to the Edit status
The super user can submit the policy for further processing; he/she can also set the policy back to the Edit status
The new user cannot submit the policy for further processing nor set the policy back to the Edit status

If the policy is submitted for further processing, the pend reason will be resolved (removed and resolved in the policy pend history) and the policy will be approved. If the policy is set back to the Edit status, the pend reason will remain on the policy and a policy pend history record for the pend reason will be created for the Edit status. In the Edit status all users will be able to submit the policy for further processing. What happens with the attached pend reason depends on which user submits the policy.

If the second pend operator or the super user fixes the error that resulted in the policy being pended and submits the policy, the pend reason will be resolved (removed and resolved in the policy pend history) and the policy will continue in the processing flow. It will no longer pend in process step 2, because the error has been fixed, so it will eventually be approved. Note that if the user submits the policy without fixing the error, the pend reason will still be resolved. If the 'Reattach?' indicator on the pend reason is checked the policy will again be pended in process step 2; else it will not pend again and it will be approved.

If the first pend operator or the new user fixes the error that resulted in the policy being pended and submits the policy, the pend reason will not be resolved, but the policy will continue in the processing flow. Because the pend reason is not resolved, the policy will again pend in process step 2 (regardless of the 'Reattach?' indicator), where the second pend operator or the super user needs to approve the fixes and resolve the pend. Note that the same happens even if the first pend operator or the new user submits the policy without fixing the error.

Now let’s say the first pend operator or the new user edits the policy to fix the error, but while editing, introduces another error. The user submits the policy: the pend reason will not be resolved, but the policy will continue in the processing flow. Because of the newly introduced error, the policy pends in process step 1. Pend reason 1 is attached to the policy and a policy pend history record is created for the attached pend reason for this Pended status. Note that pend reason 2 is still attached to the policy; there is no policy pend history record created for that pend reason for the new Pended status. The different users can perform the following actions in this Pended status:

The first pend operator can submit the policy for further processing; he/she can also set the policy back to the Edit status
The second pend operator cannot submit the policy for further processing nor set the policy back to the Edit status
The super user can submit the policy for further processing; he/she can also set the policy back to the Edit status
The new user cannot submit the policy for further processing nor set the policy back to the Edit status

If the policy is submitted for further processing, only pend reason 1 will be resolved; pend reason 2 will remain on the policy. Note that this also applies if the super user, that has Pend Resolution rights for process step 2, submits the policy. If the policy is set back to the Edit status, both pend reasons will remain on the policy and a policy pend history record for both pend reasons will be created for the Edit status. What happens with the pend reasons when the policy is again submitted depends on which user submits the policy:

First pend operator: only pend reason 1 is resolved
Second pend operator: only pend reason 2 is resolved
Super user: both pend reasons are resolved
New user: no pend reasons are resolved

Generating Person Covered Services

In this step the system checks for an active dynamic logic function of the signature 'Person Covered Services'. If the system finds such a function, it will run it. If it does not find it, the system moves to the next step.

Processing Errors

Errors in processing may be both of a technical nature and a functional nature, for example:

A connection with the external component cannot be made (system is down) for a callout
The dynamic logic specified on an evaluated process rule has a bug

When a processing error occurs, the execution of the process step for a policy stops. The policy remains halted in its current location in the flow. Any operations performed by a process step that runs into an error (for example attaching messages, attaching pend reasons, changing the policy status, creating policy status history records, setting fields, etc) are rolled back (that is undone). Note that when a process step runs into an error, this does not roll back operations performed by process steps that were (successfully) executed earlier in the process.

If a policy is halted in the process because of processing errors, the causes of these processing errors must be resolved. After that, execution of the process step for the policy can be 'retried'. This can be done by using the View Activities user interface page (in the operations menu of Policies) where technical errors can be (re)processed. Note that a policy that is halted in the process because of pending process steps execution, cannot be manually unhalted using the View and Edit Policy user interface page.

Reprocessing of process step includes reselection and evaluation of the process steps and the rule steps. This means that if the setup of a process step or a process rule is changed, it may now not trigger and not be executed where it did in the initial processing (or the other way around).

Approve Policy

After the last process step is evaluated the status of the policy is set to Approved, and a policy status history record for the Approved status is created. Note that policies that have fatal messages cannot be approved; they will be set back to the Edit status in an earlier stage of the processing flow (see Fatal Messages section).

An approved policy can be 'unfinalized' so it can be edited if needed. This can be done through the View and Edit Policy user interface page or through the Policy In Integration Point. When a policy is 'unfinalized', a new version of the policy (copy of the current version) with the Edit status and a new policy status history record for the Edit status are created.

When the policy is approved, the updated person details in context of the policy are approved as well. The updated person information becomes the active person information.

When a policy is approved and there are no policy enrollment events for the policy version, the policy is identical to the active version of the policy. In that case, no new policy version is created. See Revert Policy to Previous Version for details.

Updating Policy Update Requests

When a policy is approved, the applied policy update requests i.e. the policy update requests with status 'Loaded' are also marked as processed.

The final status for the applied policy update requests depends on the outcome of the Compare Policy Versions i.e.

'Processed' if the current version is Approved
'Processed No Update' if the current version is reverted because of no new changes to the policy
'Processed Notification Sent' if the external system is notified and the policy is reverted because of an enrollment event notification

No impact on Disable Update From Queue? flag or any other update requests with status 'Failed', 'Rejected', 'Initial' and 'Queued'