Handling underwriting issues in policy revisions

This topic describes how PolicyCenter handles underwriting issues in out-of-sequence policy changes. For detailed information on how PolicyCenter handles out-of-sequence changes, see Out-of-sequence jobs.

PolicyCenter handles out-of-sequence policy changes by evaluating every future slice in the policy when it evaluates whether to raise underwriting issues. PolicyCenter first evaluates the slice. Then PolicyCenter checks to see if the slice is blocked and automatically approves auto-approvable issues. PolicyCenter evaluates whether to raise underwriting issues on the slice. The data can change such that the value of an issue changes in the future, or the issue can disappear and reappear in different slices. When this occurs, the issue is automatically split and removed as necessary. The PolicyEvalContext object pulls issues forward or backwards in time as necessary during evaluation. However, any issue with the same type and key will have the same FixedID if it is not completely removed from the policy as of the period start date.

Approvals are effective as of the slice date on which they are approved until the end of the period. When an issue is reopened or reapproved as of a particular effective date, PolicyCenter removes all approvals for that issue from that date forward. The behavior is the same for reopened and reapproved issues because a reapproved issue is automatically reopened. Thus, an approval at time T1 will extend through T2 until the end of the period, and any approval already at T2 will be removed. If the approval given at T1 is insufficient for time T2, the user will need to reopen the issue at T1 and create a more lenient approval. Alternately, the user can move T2 in effective time and reapprove the issue at time T2. PolicyCenter expires the original approval at T2 and creates a new approval from T2 until the end of the period.

If underwriting issues block future slices, PolicyCenter uses the same slice selector that it uses for out-of-sequence validation failures. PolicyCenter displays the selector if the FailedOOSEEvaluation flag is set to true on the period. This flag indicates that the policy period is out-of-sequence. The flag is set if a future slice has blocking issues but the current slice is not blocking. The flag can also be set if any issues that are generated have values that vary over time (which includes the issue itself disappearing and reappearing).

In the default configuration, PolicyCenter adds a section sign, §, to indicate that the issue varies in time. PolicyCenter displays the section sign if the ValueVariesAcrossSlices and IssueBlocksAtSomeSlice properties in UWIssueEnhancement are true. PolicyCenter displays the section sign in parentheses, (§), if the value varies in time but is not currently blocking any slice. Lastly, the user interface displays a Next Blocked Date button that automatically takes the user to the next slice in effective time where issues are blocked. The Next Blocked Date button appears if there are blocking issues in future slices. The user can step through the slices, approving issues from that point forward until the policy is no longer blocked. To see how PolicyCenter displays this in the user interface, see Underwriting issues on the Risk Analysis screen.

This topic describes how PolicyCenter handles underwriting issues in preempted jobs.

A preemption occurs if one job is in progress when another job on the same policy binds. For example, a job starts on a policy and creates policy period PP1, which is not yet bound. Then another job on the same policy binds, resulting in a bound policy period PP2 that preempts PP1. When the user handles the preemption on PP1, PolicyCenter create a new policy period PP3. PolicyCenter handles underwriting issues as follows:

• All issues and approvals which are present in PP2 are carried over to PP3. Approvals from PP2 are not expired. Therefore, if PP2 includes an approval which is invalid from the next change, that approval remains in PP3.
• If PP1 includes a new issue that does not appear in PP2, that new issue does not appear in PP3.
• If PP1 includes changes to an issue or approval that is present in PP2, the issue appears in PP3 along with the approval from PP2. However, the issue history includes links to an invalid job. (The links still refer to PP1, which was preempted and is no longer valid.)

See also

• Preempted jobs