Compare Policy Versions

Compare policy versions is a process that compares a working copy of a policy with the active policy. Each detected change results in the creation of a policy enrollment event.

The process has 4 main actions:

  1. Compare Policy Versions

  2. Create Policy Enrollment Events

  3. Combine Time Valid Policy Enrollment Events

  4. Evaluate Business Event Rules

  5. Generate Policy Events

  6. Generate Enrollment Event Notifications

The process flow controls the start of the comparison process. A Process Step that has the compare versions flag checked, initiates the compare process.

Compare Versions

This step does a full compare of two policy versions. This includes the following entities, as well as dynamic fields and dynamic records.

  • Policy

    • Policy Enrollment

      • Policy Enrollment Insurable Class

      • Policy Enrollment Medicare Detail

        • Policy Enrollment Medicare Comprehensive Addiction and Recovery (CARA) Status

        • Policy Enrollment Medicare Part D Creditable Coverage

        • Policy Enrollment Medicare Part D Late Enrollment Penalty

        • Policy Medicare Enrollment Part D Low Income Subsidy

        • Policy Enrollment Medicare Race Details

        • Policy Enrollment Medicare Ethnicity Details

        • Policy Enrollment Medicare Period

      • Policy Enrollment Product

        • Parameter Value

        • Policy Add On

        • Policy Enrollment Product Medicare Detail

          • Policy Enrollment Product Medicare Election Response

          • Policy Enrollment Product Medicare Other Insurance Details

          • Policy Enrollment Product Medicare IC Model Status

          • Policy Enrollment Product Medicare Part D 4RX Data

          • Policy Enrollment Product Medicare Premium Payment Options

    • Policyholder

    • Policy Collection Setting

    • Policy Contract Period

    • Policy Broker Agent

    • Policy Group Account

    • Policy Premium Bill Allocation

      • Policy Bill Receiver

The process does not only check changed in policy data, it also checks for changes in member data.

The following member data is checked:

  • Person

    • Address

    • Assigned Provider

    • Marital Status

    • Relation Links

    • Bank Account Number

Changes in member data can only be checked for policies and related member data sent in through the Policy In Integration Point and the Member Copy functionality is enabled. Enable the member copy functionality by setting the application property ohi.preenrollment.membercopy to true.

It is possible to exclude certain attributes or dynamic fields from the comparison. All attributes listed in the Exclude Attributes table are ignored in the comparison process.

Create Policy Enrollment Events

For each change detected in a tracked entity in the policy compare action, the process creates a policy enrollment event.

When a new policy (version1) is created, and the compare policy version functionality is enabled, enrollment changes are separated per person in Enrollment Events.

The policy enrollment event is tied to the policy version, and the change details are stored as a JSON object in the policy enrollment event.

A new policy enrollment event is created for changes in every unique combination of:

  • Policy

  • Person (if applicable)

  • Entity

A single changed object or element can be identified by:

  • Reference to the policy on the policy enrollment event

  • Reference to the person on the policy enrollment event

  • The entity name in the JSON object

  • The identifier in the JSON object

  • The start date in the JSON object

These policy enrollment events are technical in nature and serve as input for the generation of Business policy enrollments events (see Evaluate Business Event Rules)

The JSON payload looks like this:

{
    "EntityName": {
        "added": [
            {
                "identifier": "identifying_value",
                "startDate": "start_date"
            }
        ],
        "removed": [
            {
                "identifier": "identifying_value"
            }
        ],
        "updated": [
            {
                "attributeName": {
                    "newValue": "new",
                    "oldValue": "old"
                },
                "identifier": "identifying_value"
            }
        ]
    }
}

Dynamic Fields and Dynamic Records

The compare includes comparison of dynamic fields and dynamic records. Dynamic records and time valid dynamic fields are recorded as separate entities in policy enrollment events. The entity name is a concatenation of the dynamic record usage name and the entity name for which the dynamic record is defined. The format is usageName#entityName.

The compare process matches dynamic records on the key value if it is defined.

Table 1. Dynamic Fields and Dynamic Records
Type Description

Single Value Not Time Valid Dynamic Fields

Represented as an attribute on the parent entity.

Multi Value Not Time Valid Dynamic Fields

Represented as a separate entity.

Since there is no key to identify whether it is an update or new, matching is done based on the dynamic field value itself. If the values match, nothing to report. So, only added/removed can be done for them.

Single Value Time Valid Dynamic Fields

Represented as a separate entity.

It is considered as an update if the dynamic field’s start date matches but if the dynamic field value and/or the end date differs.

Not Time Valid Dynamic Records

Represented as a separate entity.

Dynamic records are compared on their key field value. If no key field is defined for a dynamic record, it is not possible to compare these dynamic records.

The compare process ignores non-time valid dynamic records without a key field.

Time Valid Dynamic Records

Represented as a separate entity.

Dynamic records are compared on their key field value. If no key field is defined for a dynamic record, it is not possible to compare these dynamic records.

The compare process ignores time valid dynamic records without a key field.

Combine Time Valid Policy Enrollment Events

Some basic policy enrollment events created in the previous step belong logically together. This last step in the process connects them. This is the case when an existing record is end-dated and a new record is created with a connecting start date.

These basic policy enrollment events combined are considered to be a change, like an address change or a plan change and are reported accordingly.

Example

Plan changes are a typical example of a combined event. Consider member is enrolled on plan SILVER as of 1-JAN-2021 and upgrades to plan GOLD per 1-JAN-2022. This generates a basic event for policy enrollment product, having the details of the change in a JSON object.

Because the end date of the terminated plan, and the start date of the new plan are connected, the compare process creates a combined event with the details that make up the aggregated event as JSON objects on the event. The change details are then removed from the basic event JSON.

When the end date and start date are not connected, so when in the example above, the start date of the new plan is 1-FEB-2022, no combined event is created and the change details remain as basic events.

Evaluate Business Event Rules

After the comparison is complete and changes have been detected, the business event rules are applied. The system all the policy enrollment events created in the compare policy versions process, and detects which business events match. For every matching rule, a policy enrollment event of type "Business" is created and attached to the policy.

Business event rules have attributes for matching to policy enrollment events created in the policy version compare and attributes that determine on conditions when a business policy enrollment event is created.

Matching Attributes

The following attributes are used for matching to policy enrollment events:

Table 2. Matching Attributes
Attribute Matching

Entity

Entity or Dynamic Record Usage name

Event Action

A - Policy Enrollment Event type C (added)
U - Policy Enrollment Event type C (updated)
D - Policy Enrollment Event type C (removed)
T - Policy Enrollment Event type A

Condition Attributes

Other attributes on the business event rule define the conditions on which a business policy enrollment event is created. An empty attribute means that the attribute is not applicable for the rule.

Table 3. Condition Attributes
Attribute Meaning

Attribute

Attribute name in the entity

Old Value

Attribute value in the active version of the policy

New Value

Attribute value in the new version of the policy

Old Value Empty?

Indicator if the attribute in the active version has a value

New Value Empty?

Indicator if the attribute in the new version has a value

Condition Dynamic Logic

Dynamic logic condition with signature Business Rule. When this condition returns true, a policy enrollment event is created.

Priorities

Business event rules can be assigned to a priority category. Within a priority category, only the first matching business event rule creates and attaches an event to the policy. The priority defines the sequence in which the business event rules are evaluated within a category.

  • Business Event Rules without a priority are always evaluated, regardless whether there is a priority category defined or not

  • When a business event rule with a priority evaluates to true, and attaches a business event, business event rules with a lower priority, i.e., that have a higher numerical value, in the same category, are not evaluated.

Example

In this example, the following subset of business event rules is configured:

Table 4. Example
Rule Code Action Entity Attribute Old Value Empty? New Value Empty? Priority Category Priority Condition Business Event Definition

BER001

Added

Policy

New policy

BER002

Added

PolicyEnrollment

Member Added

BER003

Updated

PolicyEnrollment

endDate

Y

N

Term

Enrollment Term

BER004

Updated

PolicyEnrollment

endDate

Y

N

Term

1

TERM_AGING

Disenrolled - Ageout

BER005

Updated

PolicyEnrollment

endDate

Y

N

Term

2

TERM_RAPID

Rapid Disenroll

BER006

Updated

PolicyEnrollment

endDate

Y

N

Term

3

TERM_NON_RENEWAL

Disenrolled - Non-renewal

BER007

Updated

PolicyEnrollmentProduct

endDate

N

Term Product

Product Termed

BER008

Updated

PolicyEnrollmentProduct

endDate

N

N

Term Product

1

TERM_PROD_EXTEND

Product Term Postponed

BER009

Updated

PolicyEnrollmentProduct

endDate

N

N

Term Product

2

TERM_PROD_REDUCE

Product Term Early

Below is explained which business event rules are evaluated and generate a business policy enrollment event when the conditions on the rule are met.

No Priority Category

All business event rules in this example without a priority category are evaluated because they don’t have a priority defined. Business policy enrollment events are generated for policy enrollment evens that meet the conditions in the rule.

Priority Category 'Term'

Table 5. Priority Category 'Term'
Rule Condition Condition Result Action

BER003

-

-

Generate Business Policy Enrollment Event

BER004

TERM_AGING

false

No Business Policy Enrollment Event Generated

BER005

TERM_RAPID

true

Generate Business Policy Enrollment Event

BER006

TERM_NON_RENEWAL

N/A

Rule not evaluated

Priority Category 'Product Term'

Table 6. Priority Category 'Product Term'
Rule Condition Condition Result Action

BER007

-

-

Generate Business Policy Enrollment Event

BER008

TERM_PROD_EXTEND

true

Generate Business Policy Enrollment Event

BER009

TERM_PROD_REDUCE

N/A

Rule not evaluated

Substitution Parameters

The display text in a business event definition can have up to 10 substitution parameters. The policy enrollment events created in this process have the following substitution parameters pre-populated:

Event Action Added

Table 7. Event Action Added
Parameter Attribute Value

Value0

Identifier

Value1

Start Date (for time valid entities or dynamic records)

Event Action Updated

Table 8. Event Action Updated
Parameter Attribute Value

Value0

Identifier

Value1

Attribute

Value2

Old Value

Value3

New Value

Event Action Deleted

Table 9. Event Action deleted
Parameter Attribute Value

Value0

Identifier

Event Action time valid change

Table 10. Event Action Time Valid Change
Parameter Attribute Value

Value0

Identifier (from current active policy version)

Value1

Start Date (for time valid entities or dynamic records)

Value2

Identifier (from new policy version)

Availability of substitution parameters

Not every entity has an identifier as substitution parameter. When the identifier is used in a display text for a business event rule when there is no identifier available, "undefined" will be displayed.

The following table shows for which entities an identifier substitution parameter is available:

Table 11. Availability of Substitution Parameters
Entity Identifier Time Valid

Policy

-

No

Policy Enrollment

-

No

Policy Enrollment Insurable Class

Insurable Class Code

Yes

Policy Enrollment Medicare Detail

-

No

Policy Enrollment Medicare Comprehensive Addiction and Recovery (CARA) Status

Drug Class

Yes

Policy Enrollment Medicare Part D Creditable Coverage

First Enrollment Start Date

No

Policy Enrollment Medicare Part D Late Enrollment Penalty

-

Yes

Policy Medicare Enrollment Part D Low Income Subsidy

-

Yes

Policy Enrollment Medicare Race Details

Race

No

Policy Enrollment Medicare Ethnicity Details

Ethnicity

No

Policy Enrollment Medicare Period

Period type

Yes

Policy Enrollment Product

Enrollment Product Code

Yes

Policy Enrollment Product Medicare Detail

Enrollment Product Code

No

Policy Enrollment Product Medicare Election Response

Enrollment Product Code, Medicare OEC SEP Code, Type

No

Policy Enrollment Product Medicare Other Insurance Detail

Enrollment Product Code, Member ID, Group ID

Yes

Policy Enrollment Product Medicare IC Model Status

Enrollment Product Code, Type Indicator

Yes

Policy Enrollment Product Medicare Part D 4RX Data

Enrollment Product Code

Yes

Policy Enrollment Product Medicare Premium Payment Options

Enrollment Product Code

Yes

Parameter Value

Enrollment Product Code, Parameter Alias

Yes

Policy Add On

Enrollment Product Code, Add On Code

Yes

Policyholder

-

Yes

Policy Collection Setting

-

Yes

Policy Contract Period

-

Yes

Policy Broker Agent

Agent Code, Broker Code

Yes

Policy Group Account

Group Account Code

Yes

Policy Premium Bill Allocation

-

Yes

Policy Bill Receiver

-

Yes

Address

Address Type Display Name

Yes

Person

-

No

Assigned Provider

Provider Code

Yes

Marital Status

Marital Status Code

Yes

Relation Link

Relation Link Type Code

No

Bank Account Number

Bank Account Number

Yes
When sending in business event rules with the API, use the entity names (without spaces) as defined in the object model. For example, Address or PolicyEnrollmentProduct.

Generate Policy Events

A policy enrollment event of type Business can lead to the creation of a policy event of type Recalculation.

The following attributes of the business event rule determine the creation of the policy event.

Table 12. Generate Policy Events
Attribute Description

Recalculate?

If set to true, generate a policy event of type Recalculation.

Function Dynamic Logic

Dynamic logic function with signature Business Rule. This function returns the effective date for the policy event.

For every policy enrollment event of type Business with the indicator re-calculate set to true, a policy event is also created with the following details:

Table 13. Policy Event
Policy Event Attribute Value

Event Level

Policy

Type

Recalculation

Policy

Reference to the policy for which the business event rule is being evaluated

Cause

C POLI R for a new policy and U POLI R for an update to an existing policy

Change Log

-

Effective Date

Effective date as returned by the Business Rule function dynamic logic

This policy event can lead to a policy premium recalculation if the policy event leads to creation of a policy mutation. See policy events and mutations for additional details on how policy events are processed.

Generate Enrollment Event Notifications

  • By configuring a notification definition, the user defines:

    • For which business event should generate a notification,

    • When the notification should be sent, example:

      • 'Pre Approval' of Policy (or)

      • 'Post Approval' of Policy

  • Notification definition refers to business event definitions which intern is referred by a Business Event Rule.

  • Hence, on the comparing policy versions where these business event rules linked to notification definition successfully evaluates, system generates an enrollment event notification along with the policy enrollment event of type business.

  • Every notification that is generated will have reference to the policy GID, notification definition and the linked policy update request(s).

  • Each of these notifications will contain the payload of the detected changes on the policy in reference to the linked policy enrollment event.

For more details refer Enrollment Event Notifications.