Membership Audit Process
If you add or edit a membership, the system checks whether an active audit event type exists for the C1-Membership business object. If an active audit event type exists for the business object, the creates the audit event using the audit event type. The system creates the audit event whenever a membership is added to a policy plan and dependent member person is added to a membership. It also creates the audit event whenever the membership and member person details are updated. However, note that the audit events are created in the update scenario when the element listed for auditing in the age based or tier based pricing rule types is updated. The system considers only those pricing rule types whose pricing rules are effective during the respective entity (i.e. membership or member person whichever is updated) date range.
The audit event is created in the Pending status. An effective date is stamped corresponding to the audit event which later helps in deriving the timeline during premium calculation. Note that the system creates distinct audit events in the following scenarios:
| Scenario | System Behavior | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A membership is added to a policy plan | One audit event is created for the membership. Here, the
effective date in the audit event is set to the membership's start
date. For example, two memberships named M1 (with the start date as 01-01-2020) and M2 (with the start date as 01-15-2020) are added to a policy plan named PP1. In such case, the system will create two audit events - one for M1 with the effective date as 01-01-2020 and another for M2 with the effective date as 01-15-2020. |
||||||||||||||||||||
| A dependent member person is added to a membership | One audit event is created for the membership. Here, the
effective date in the audit event is set to the dependent member person's
start date. For example, one dependent member person named MP1 (with the start date as 06-05-2020) is added to the M1 membership and another dependent member person named MP2 (with the start date as 06-10-2020) is added to the M2 membership. In such case, the system will create two audit events - one for M1 with the effective date as 06-05-2020 and another for M2 with the effective date as 06-10-2020. |
||||||||||||||||||||
| A dependent member person is removed from a membership | One audit event is created for the membership. Here, the
effective date in the audit event is set to the dependent member person's
start date. For example, one dependent member person named MP4 (with the start date as 9-15-2020) is removed from the M1 membership. In such case, the system will create one audit event for M1 with the effective date as 9-15-2020. |
||||||||||||||||||||
| A membership is added to a policy plan along with a dependent member person | Multiple audit events are created for the membership - one
where the effective date is set to membership's start date, another
where the effective date is set to dependent member person's start
date, and third where the effective date is set to dependent member
person's end date +1 Day. Note that the second audit event is created
when the dependent member person's start date is later than membership's
start date. And, the third audit event is created when the dependent
member person's end date is earlier than membership's end date. For example, one membership named M1 (with the start date as 01-01-2020 and end date as 12-31-2020) is added with two member persons - MP1 who is a main subscriber and MP2 (with the start date as 03-01-2020 and end date as 10-31-2020) who is a dependent member person. In such case, the system will create three audit events for M1 - one with the effective date as 01-01-2020, another with the effective date as 03-01-2020, and third with the effective date as 11-01-2020 (i.e. 10-31-2020 + 1 Day). |
||||||||||||||||||||
| Membership characteristics are added or updated in the system | Multiple audit events are created for the membership - one
for each set of membership characteristics with the same effective
date. Here, the effective date in the audit event is set to the date
from when the membership's characteristic is effective. For example, the following characteristics are added or updated for the M1 membership:
In such case, the system will create two audit events for M1 - one with the effective date as 9-15-2020 and another with the effective date as 9-20-2020. |
||||||||||||||||||||
| Member person characteristics are added or updated in the system | Multiple audit events are created for the membership - one
for each set of member person's characteristics with the same effective
date. Here, the effective date in the audit event is set to the date
from when the member person's characteristic is effective. For example, the following characteristics are added or updated for the member persons in the M1 membership:
In such case, the system will create two audit events for M1 - one with the effective date as 9-15-2020 and another with the effective date as 9-20-2020. |
||||||||||||||||||||
| A set of membership fields except membership start and end dates is updated in the system | One audit event is created for the membership. Here, the
effective date in the audit event is set to the membership's start
date. For example, the external membership ID of the M1 membership (with the start date as 9-15-2020) is changed. In such case, the system will create one audit event for M1 with the effective date as 9-15-2020. |
||||||||||||||||||||
| The membership start date is updated in the system | One audit event is created for the membership. Here, the
effective date in the audit event is set to the membership's new start
date. For example, the start date of the M1 membership is changed from 9-15-2020 to 9-20-2020. In such case, the system will create one audit event for M1 with the effective date as 9-20-2020. |
||||||||||||||||||||
| The membership end date is updated in the system | One audit event is created for the membership. Here, the
effective date in the audit event is set to membership's new end date. For example, the end date of the M1 membership is changed from 12-31-2020 to 11-30-2020. In such case, the system will create one audit event for M1 with the effective date as 11-30-2020. |
||||||||||||||||||||
| A set of member person's fields except member person start and end dates is updated in the system | One audit event is created for the membership. Here, the
effective date in the audit event is set to the member person's start
date. For example, the relationship type and status of the MP1 member person (with the start date as 01-01-2020) in the M1 membership is changed. In such case, the system will create one audit event for M1 with the effective date as 01-01-2020. |
||||||||||||||||||||
| The dependent member person's start date is updated in the system | Three audit events are created for the membership - one where
the effective date is set to the dependent member person's previous
start date, another where the effective date is set to the dependent
member person's new start date, and third where the effective date
is set to dependent member person's end date + 1 Day. However, if
the derived effective date is later than the membership end date,
the system does not create the third audit event for the membership.
In such scenario, it simply creates first two audit events. For example, the Mike's effective date range is changed from 04-01-2019 - 09-30-2019 to 01-15-2019 - 09-30-2019 in the M1 membership which is effective from 01-01-2019 to 12-31-2019. In such case, the system will create three audit events for M1 - one with effective date as 04-01-2019, another with effective date as 01-15-2019, and third with effective date as 10-01-2019 (i.e. 09-30-2019 + 1 Day). In addition, if there is a characteristic for the person whose effective date falls with the new enrollment date range, the system creates an audit event for the person where the effective date is set to characteristic's effective date. Note that the system considers those effective characteristics where the characteristic entity is set to Person. Let us assume that in the above example a characteristic for Mike was effective from 02-01-2019. In such case, the system creates three audit events for the M1 membership (with the effective dates as mentioned above) and one audit event for the person (i.e. Mike) where the effective date is set to 02-01-2019. |
||||||||||||||||||||
| The dependent member person's end date is updated in the system | Two audit events are created for the membership - one where
the effective date is set to dependent member person's previous end
date + 1 Day and another where the effective date is set to dependent
member person's new end date + 1 Day. However, if the derived effective
date is later than the membership end date, the system does not create
the second audit event for the membership. In such scenario, it simply
creates the first audit event. For example, the Garry's effective date range is changed from 04-01-2019 - 09-30-2019 to 04-01-2019 - 12-31-2019 in the M1 membership which is effective from 01-01-2019 to 12-31-2019. In such case, the system will create one audit event for M1 with the effective date as 10-01-2019 (i.e. 09-30-2019 + 1 Day). It will not create another audit event for M1 because the derived effective date (i.e. 12-31-2019 + 1 Day = 01-01-2020) is later than membership end date (i.e. 12-31-2019). In addition, if there is a characteristic for the person whose effective date falls with the new enrollment date range, the system creates an audit event for the person where the effective date is set to characteristic's effective date. Note that the system considers those effective characteristics where the characteristic entity is set to Person. Let us assume that in the above example a characteristic for Garry was effective from 11-01-2019. In such case, the system creates one audit event for M1 membership (with the effective date as mentioned above) and another audit event for the person (i.e. Garry) where the effective date is set to 11-01-2019. |
||||||||||||||||||||
| The dependent member person's start and end dates are updated in the system | Four audit events are created for the membership - one where
the effective date is set to the dependent member person's previous
start date, another where the effective date is set to the dependent
member person's new start date, third where the effective date is
set to dependent member person's previous end date + 1 Day, and fourth
where the effective date is set to dependent member person's new end
date + 1 Day. However, if the derived effective date is later than
the membership end date, the system does not create the fourth audit
event for the membership. In such scenario, it simply creates the
first three audit events. For example, the Juliet's effective date range is changed from 04-01-2019 - 09-30-2019 to 01-01-2019 - 11-30-2019 in the M1 membership which is effective from 01-01-2019 to 12-31-2019. In such case, the system will create four audit events for M1 - one with effective date as 04-01-2019, another with effective date as 01-01-2019, third with effective date as 10-01-2019 (i.e. 09-30-2019 + 1 Day), and fourth with effective date as 12-01-2019 (i.e. 11-30-2019 + 1 Day). In addition, if there is a characteristic for the person whose effective date falls with the new enrollment date range, the system creates an audit event for the person where the effective date is set to characteristic's effective date. Note that the system considers those effective characteristics where the characteristic entity is set to Person. Let us assume that in the above example two characteristics of Juliet were effective from 03-01-2019 and 10-01-2019, respectively. In such case, the system creates four audit events for M1 membership (with the effective dates as mentioned above), fifth audit event for the person (i.e. Juliet) where the effective date is set to 03-01-2019, and sixth audit event for the person (i.e. Juliet) where the effective date is set to 10-01-2019. |
For each audit event, the system identifies the policy plan to which the membership belongs and the active pricing rules defined on the policy plan. It then identifies the pricing rule types using which these active pricing rules are created in the system. A repricing entity detail record is created for each membership, pricing rule type, and effective date combination in the CI_REPRC_ENTITY_DTL table. The status of the repricing entity detail record is set to P.
Let us understand this with the help of an example.
| Entity | Entity Detail | |
|---|---|---|
| Audit Event | AE11 | AE12 |
| Membership | M1 | M2 |
| Membership Start Date | 01-03-2019 | 01-02-2019 |
| Policy Plan to which Membership Belongs | PP11 | PP12 |
| Pricing Rules Defined on the Policy Plan | PR1 (Using PRT1), PR2 (Using PRT2), PR3 (Using PRT3) | PR11 (Using PRT1), PR13 (Using PRT2) |
| Pricing Rule Types Associated with the Policy Plan | PRT1, PRT2, PRT3 | PRT1, PRT2 |
For the AE11 audit event, the system creates three repricing entity detail records with the following combinations in the CI_REPRC_ENTITY_DTL table:
-
M1, PRT1, 01-03-2019
-
M1, PRT2, 01-03-2019
-
M1, PRT3, 01-03-2019
And, for the AE12 audit event, the system creates two repricing entity detail records with the following combinations in the CI_REPRC_ENTITY_DTL table:
-
M2, PRT1, 01-02-2019
-
M2, PRT2, 01-02-2019
Once the repricing entity detail records are created successfully, the status of the audit event is set to Complete. However, if an error occurs while creating the repricing entity detail records for an audit event, the status of the audit event is set to Error.