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:
-
Compare Policy Versions
-
Create Policy Enrollment Events
-
Combine Time Valid Policy Enrollment Events
-
Evaluate Business Event Rules
-
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 Product
-
Parameter Value
-
Policy Add On
-
-
-
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 ingnored 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.
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:
Attribute | Matching |
---|---|
Entity |
Entity or Dynamic Record Usage name |
Event Action |
A - Policy Enrollment Event type C (added) |
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.
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:
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'
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'
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
Parameter | Attribute Value |
---|---|
Value0 |
Identifier |
Value1 |
Start Date (for time valid entities or dynamic records) |
Event Action Updated
Parameter | Attribute Value |
---|---|
Value0 |
Identifier |
Value1 |
Attribute |
Value2 |
Old Value |
Value3 |
New Value |
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:
Entity | Identifier | Time Valid |
---|---|---|
Policy |
- |
No |
Policy Enrollment |
- |
No |
Policy Enrollment Insurable Class |
Insurable Class Code |
Yes |
Policy Enrollment Product |
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 |
Collection Method Code |
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 |
- NOTE
-
When sending in Business Event Rules with the API, use the entity names as defined in the object model, so without spaces. E.g. Address or PolicyEnrollmentProduct.
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.