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 Integration Guide) or it can be manually entered in the New Policy user interface page (described in New Policy). An existing policy can be edited by sending in an update request through the integration point or by editing it manually in the View and Edit Policy user interface page (described in View and Edit Policy). The policy can be submitted for processing through the integration point or in the View and Edit Policy user interface page. 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 triggered in the View and Edit Policy user interface page (described in View and Edit Policy) or through the validate policy operation (described in the integration guide).

Evaluate Fixed Validation Rules

In this step a number of fixed 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.
If a parameter value of type amount is specified for a policy enrollment product, the currency needs to match the parameter currency specified on the related enrollment product. If the currencies do not match, message POL-FL-PRPO-003 is attached to the policy for every invalid parameter value.

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-003	Fatal	The currency specified for parameter {parameter alias display name} on the policy enrollment product for {insurable entity} with start date {policy enrollment product start date} does not match the parameter currency specified on the related enrollment product {enrollment product display name}

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-003

Fatal

The currency specified for parameter {parameter alias display name} on the policy enrollment product for {insurable entity} with start date {policy enrollment product start date} does not match the parameter currency specified on the related enrollment product {enrollment product display name}

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.

Evaluate Process Steps

The processing of a policy involves sequential execution of user defined process steps. A process step groups various related and interdependent process rules (callout rules, policy validation rules and pend rules) to be executed in a user defined order. The configuration of process steps is described in more detail in Process Steps.

The system first determines the sequence of the process steps and then starts evaluating the process steps one by one. Process steps have rule steps that identify which process rules are executed within a process step and the order of execution within the step. Callout rules and policy validation rules have a sequence within a process step; pend rules do not have a sequence (they are executed after the execution of the callout rules and policy validation rules). The system determines the sequence (where applicable) of the process rules within a process step and starts evaluating them one by one. The evaluation of the different process rules is described in the sections below.

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 Callout Rules) is evaluated to determine if it applies to the policy. In other words, the restrictions specified on 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 are entered in the user interface (indManual on the attached policy data is set to Yes)
  - Note that this also applies for policies that are are entered in the user interface, but are submitted for processing through the integration point.
- 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)
  - Note that this also applies for policies that are received through the integration point, but are submitted for processing in the user interface
- If set to Either, the rule is applicable for both policies that are entered in the user interface and received through the integration point
Condition Dynamic Logic: if specified, the rule is only applicable for 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 next rule (this can be a callout rule, policy validation rule or pend rule) is executed. Note that 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 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.

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 Policy 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 fixed 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 implementation 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 e.g. 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 in the View and Edit Policy user interface page (described in View and Edit Policy). 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. This can be done through the View and Edit Policy user interface page or through the Policy In Integration Point (described in more detail in View and Edit Policy and Policy In Integration Point). The status of the policy is set back to Edit, and 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 OHI Enterprise Policy Administration) 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 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. This is described in more detail in View and Edit Policy and Policy In Integration Point.