Life Events

Life Events

As we know, Life events are events that happen to Participants, with which a Participant can get a chance to change his benefits elections. There are three types of life events:

• Scheduled: The Life events that are run on a Particular date for all Participants in the system. Examples for these Life Events would be Open, Administrative etc. These Life events are usually once in a Year kind of life events, those are run to give enrolment opportunity to all Participants.
• Explicit: These life events are caused by database column updates.
  • Person Initiated: The changes in Participant's life, which are updated by the Participant himself, fall in this category. Examples would be Birth of a Child, Marriage, Divorce, and Change in Address etc.
• System Initiated: The Changes in Participant's life that are updated by the HR department of the Enterprise fall in this category. Examples would be, New Hire, Rehire, Leave of Absence, Change in Position etc.
• Temporal: The changes in Participant's data due to time. These fall in this category. Examples would be Age, Length of Service etc. The changes in Derived Factor brackets (to be discussed) cause temporal.

Why use Life Events?

We are setting up the Benefit structure, Eligibility, Electability, rates etc to give options to the Participants, and then to track their health coverage elections and then communicate that to Carriers, right? Now, we need a process through which the eligibility, Electability, rates etc will be calculated. Then the Participant can choose their plans and options. That process is needed whenever there is a change in Participant account/ data. That process can be called as Life Event.

Let's go through some of the Life Event terminology that would help us learn the subject better.

Person Changes: The Change in data that triggers the Life Event is known as the Person Changes. There is a form where we define the Person changes, and associate that with the Life Event. So whenever the change happens on any Participant, the Life Event is triggered.

Related Person Change: This is like Person Changes. However here the changes recorded are related to Contacts of the Participants unlike Person Changes, where changes are recorded for the Participant.

Trigger Life Events: For a change on Participant data, we can trigger multiple life events, based on a set of conditions. For an example, a Lose Dependent happened. Which means, there was a record in PER_CONTACT_RELATIONSHIPS which got end dated for a Person? Now, we will trigger a Life event called "Lose Dependent" from there. However we are still unsure the Dependent lost is a Spouse / child / Domestic partner etc. So now, we will add some conditions with a Rule that can trigger multiple Life Events, like, "Lose Dependent - Spouse", "Lose Dependent - Child", "Lose Dependent - Domestic Partner" based on the Type of the Contact.

Here the "Lose dependent" is called the Trigger Life Event. The Rule that holds the conditions is known as an "Evaluation Rule"; and the "Lose Dependent - Spouse", "Lose Dependent - Child" and "Lose Dependent - Domestic Partner" are known as the Child Life Events of the Trigger Life Event.

Life Event Reason: This is the form where we define the trigger Life Events, the child ones and the related life events.

Potential Life Event: When a Participant experiences a data change that can cause a life event, the life event gets triggered on the Participant's record. The Life Event is triggered with an Occurred Date and a Notified Date. Occurred date is the date as of which the Life Event needs to be processed; and Notified date is the date when the data change occurred. For an Example, if Joe will have a change in Compensation as of 15th of January, and someone updated Joe’s salary as of 12th with an Effective date of 15^th; the life event will get triggered on his record with a Notified Date of 12th and an Occurred date of 15th. The Life event will then be processed as of 15th Of January, as that's the Occurred date. A life event before processing is known as a Potential Life Event.

When we discussed about the Trigger Life Events, all Trigger Life Events are inserted on Participant account as Potential Life Events. When the Life Event is picked for processing, the Evaluation Rule is fired and then the child Life Event is inserted and processed on the Participant.

Status of Life Events:

• A Life Event before processing has a status, Detected.
• When the Life Event is processed, if the Participant has any enrolment opportunities the Life Event status is changed to Started.
• If the Participant does not have any opportunities, the life event status is changed to Processed.
• If the Life Event needs to be rerun, OAB provides a functionality of Backing out the Life Event. Once backed out, the status is changed to Backed Out.
• If the Life Event needs to be removed / purged from the Participant account, one can ‘void’ it. The Status then becomes voided.
• When the Life Event is in started state, we can close the Life Event, so that no further processing/ enrolments can be done on the same. Then the status changes to Closed.
• We can enter conditions to make the Life Event status as Manual, where we think the Life Event is inserted with wrong data. Then the status can be manually changed to Manual Override to reprocess the life event.

We will learn more about these in Processing Section.

Enrolment Window: The Life Event once processed, determines the Enrolment Opportunities and a window period. Usually a window period varies from 1 day to 30 or may be 60 days at times. This is the period with in which the Participant can go and make elections.

Open: This is a Seeded Scheduled Life Event, usually run once in a year, as of the first of the Plan year. It can be run more than once a year based on its defined schedule. This is run on all Participants, to give them an enrolment Opportunity for the year. This is to make sure everyone gets a chance to alter their benefits every year. What if no life events happen to one guy, he should get a chance right? Again, this is the time frame, when most of the enterprises deal with the Carriers and arrive at the plan set ups and Premium changes. Participants get new plans, eligibility changes and rates change too. So this is a big life event for all Participants.

Let's configure a Life Event.

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Additional Setup -> Life Event Reasons

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.12 – Life Event Reasons.

(Figure 6.12 – Life Event Reasons)

Now, as the Life event is defined, let's work on the trigger part. How do we make the Life event trigger. There are two ways to do it, either use a person change or a related person changes based on the type of Life event we are going to use.

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Additional Setup -> Life Event Reasons ->Person Changes -> Define Person Change

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.13 – Person Changes.

(Figure 6.13 – Person Changes)

Related Person change is exactly the same as the Person changes, however follows a different button within.

Navigation: Total Compensation -> General Definitions-> Additional Setup -> Life Event Reasons ->Related Person Changes -> Define Related Person Change

Once the Person changes/ related person changes are defined, we can attach it to the designated Life event.

• Query the Life Event
• Click on the Person Changes / Related Person changes
• Add the Person changes in the list.
• If there are more than one Person Changes attached and
  • All the Person changes are on the same table, they all act as an AND
  • Else, they are evaluated with OR condition.

There will be cases where more than one potential life events will be triggered on a Participant with the same Occurred date. However a Participant can experience just one life event as of one day. So OAB gives us a form, where we can define a set of Collapsing logic that helps the system determine, which life event to process, and what to do with the other one.

In a case where one of the Potential Life events, is marked as Overridden, the system does not look at the Collapsing logic. It processes the Overridden one and voids the other. However if both or none of them have the Override flag checked, the system calls for the collapsing logic and then determines the winner.

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Additional Setup -> Collapse Life Events

Steps: Date track to a suitable effective date, Create a new Record.

(Figure 6.14 – Collapsing Life Event)

There are few data fields that are not stored in the system, rather derived from other data fields; and the only reason they are not stored directly is, they change with time. Like Age, Length of Service etc. These Derived factors are useful, whenever we wish to trigger something on the Participant when he attains a particular age / LOS; or may be at times when we want to define eligibility based on them.

There are six Derived Factors in place:

1. Compensation Level: Used to store the Person's compensation. It could be the compensation / a Benefit Balance /a Payroll Balance
2. Hours Worked in Period: Used to store the number of hours worked in a Particular period. It could be a Balance / a Benefit Balance.
3. Length of Service: It is used to track the Length of Service of a Participant. The Difference between the date of hire/ adjusted date of hire/ original Date of hire and SYSDATE.
4. Percent of Full Time Employment: Used to track the Percent of an employee’s work assignment with comparison to a Full Time Equivalent.
5. Age: Used to store the Age of the Person / Dependent.
6. Combination of Age and Service: We can combine two derived factors (Age and LOS) together and create a new one.

How does it work?

There is always a Min and Max value involved in all Derived Factors. Which actually define a boundary? A boundary is a block that tells us the limits of a Derived Factor. For an example, if we will set up an Age DF with the Min as 0 and Max as 64, it means the boundaries are 0 and 64. Now, let’s talk about Joe's age. Joe is an Employee who is 55 years old; so he falls under the Boundary. For 5 years, he is 60; still he is in the Boundary. After 5 more years, he becomes 65, now, he crosses the Boundary.

There are two main functions of DFs.

1. Eligibility Determination: As Long as Joe is inside the boundary, he will pass the DF. The moment he goes out of the Boundary, he fails.
2. Temporal Detection: Temporal are nothing but a set of Life events. We will talk about these more later. However imagine we will attach DFs in such a manner that, we need a Life Event triggered, the moment a participant crosses the Boundary. We can do that through Temporal.

Now we know how DFs work with Boundaries. Let’s learn how to define Derived factors; and then we will learn how to use them.

Compensation

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility/Rate Factors -> Derived Factors -> Compensation Tab

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.15 – DF Compensation.

(Figure 6.15 – DF Compensation)

Hours Worked

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility/Rate Factors -> Derived Factors -> Hours Worked Tab

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.16 – DF Hours Worked.

(Figure 6.16 – DF Hours Worked)

Length of Service

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility/Rate Factors -> Derived Factors -> Hours Worked Tab

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.17 – DF Length of Service.

(Figure 6.17 – DF Length of Service)

Percent of FTE

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility/Rate Factors -> Derived Factors -> Full Time Equivalent Tab

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.18 – Full Time Equivalent.

Age

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility/Rate Factors -> Derived Factors -> Age Tab

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.19 – DF Age.

(Figure 6.19 – DF Age)

Combination of Age and LOS

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility/Rate Factors -> Derived Factors -> Age and Service Tab

Steps: Date track to a suitable effective date, Create a new Record. See Figure 6.19 – DF Age and Service.

(Figure 6.20 – DF Age and Service)

Temporal, as discussed here, are a specific type of Life Events. They are triggered whenever a Participant crosses the Boundary of a Derived Factor. There are 6 DFs, so there are 6 Temporal Life Events too.

1. Age Changed
2. Length of Service Changed
3. Combined Age and Length of Service Changed
4. Compensation Changed
5. Hours Worked in Period Changed
6. Period of Enrolment Changed
7. Total Percent Full Time Changed

Each one is attached to the related Derived Factor. Now, whenever a Participant crosses his boundaries in Age DF, he gets the "Age Changed" Life Event. Similarly all others depend on their respective DFs.

Why Use Temporal?

Temporal are used for Life Event triggering. What if our enterprise wants us to drop off Eligibility of a Person on his 65th Birthday? We can just use an Eligibility Profile to do so. However we will need a Life Event on his 65th Birthday in order to re-evaluate his Eligibility Right? Are we going to run scripts to identify the set of population every day? No way. But we can use an Age DF, with Boundaries as 0 and 64. Attach it to the Eligibility Profile. The moment anyone turns 65, he will cross the Boundary and he will get an "Age Changed" event detected on him. Pretty powerful tool, isn't it?

The System actually stores the data in the BEN_ELIG_PER_F, where it has one column dedicated to one DF, with each level, where we can attach an Eligibility Profile. For an example, it will have a dedicated Age column. As the table conceives a row for each Comp Object level, for each Life Event transaction, the DF columns will be filled in with the values. Every time the system finds the older value in the Boundary and the new value out of the Boundary or vice versa, it triggers the Temporal Life Event.

There are a lot of things that can be done through Temporal. There will be cases, where the Eligibility condition will be in the reverse. Like, we want the Person to be eligible only when he reaches 65. In those cases the Person will not be eligible before he turns 65, so we must tick the "Track Ineligible Person" flag in that case. If the flag is checked, the system tracks the persons, even though they are ineligible, and keeps on filling in the values. The moment it finds the guy crossing the boundary, it triggers the Temporal LE.

In this section, we re going to learn about the Eligibility, Electability, Enrolments, Certifications and Post Election Edit Rules (PEER)

Eligibility is one of the most important functionalities in OAB. We already know, Eligibility determines, whether a person is eligible for any particular Compensation object or not. It is also used to determine Rates in some cases. Hence it is always referred to as "Participation and Rate Eligibility"

We use the Participant data in evaluating eligibility. System takes the ASSIGNMENT_ID for the Person being evaluated, and fetches the required data. Based on the data the Eligibility is evaluated. It can consider all kind of data, like Indicative Data, Enrolment Data, Derived Data and the Beneficiary Data.

Basically, as part of eligibility we define a set of conditions and call it an Eligibility Profile. One Eligibility Profile can have more than one Condition and coupled with ‘AND’ or ‘OR’ clauses. If the Conditions pass, the Eligibility Profile is considered to be a pass. The Eligibility Profiles are encapsulated and can be used in more than one place. We will see this more clearly later, however let's first learn how to create an Eligibility Profile.

There are two types of Eligibility Profiles.

• Participation Eligibility Profile
• Dependent Eligibility Profile

Participation Eligibility Profiles

As we know, its set of conditions clubbed together with either ‘AND’ or ‘OR’ clause. See Figure 6.21 – Eligibility Profiles.

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility Profiles -> Participant

Now, let's look at the Different criteria on which we can define Eligibility:

Personal:

• Competencies: We can use the Competencies KFF and use a rating to determine Eligibility
• Disabled: We can use the Disability Indicators to determine Eligibility
• Gender: We can also use the Gender as an Eligibility Indicator
• Leave of Absence: The Leaves can also be used as an Eligibility
• Leaving Reason: The Leaving Reason of a Participant can also be used to determine eligibility
• Opted For Medicare: We can use the Participant's participation in Medicare as an Indicator for Eligibility.
• Person Type: The Person type of the Person can also be used as an Eligibility Indicator
• Postal Zip: We can create Zip ranges and determine Eligibility based on that.
• Qualification Title: The Qualification of a Participant can be used for Eligibility.
• Service Area: It’s similar to Postal Zips; however this is related to service area, which is in turn a combination of Zips.
• Tobacco Use: The Tobacco usage can also be used for Eligibility Determination.

Employment:

• Assignment Set: We can use an Assignment set to determine Eligibility.
• Assignment Status: The Assignment status of a Participant can be used as an Indicator.
• Bargaining Unit: It’s an Indicative data in Assignments Table and form
• Full / Part Time: The Employment status can be used for Eligibility. It’s found in the Assignment screen
• Grade: The Grade can be found in Assignments table, and can be used for Eligibility
• Hourly/ Salaried: The H/S code in Assignments can be used for Eligibility too.
• Job: Even Job specifications can be used as filters.
• Labour Union Member: This uses the membership of the Participant in any specific Labour union.
• Legal Entity: The GRE of an employee can be used for Eligibility Determination.
• Organization Unit: The Organization is stored in Assignments, and can be used as an Indicator.
• Payroll: The Payroll can also be used for Eligibility.
• Pay Basis: Pay Basis is stored in Assignments as well, and can be used for Eligibility.
• People Group: We can use the People Group KFF to determine Eligibility.
• Performance Rating: Employee's rating can be used for Eligibility as well.
• Position: Similar to Job, Position is stored in assignments, and used for Eligibility.
• Quartile in Grade: It uses a range. The Salary of an employee is divided by 4 and then is used in the range for comparison and eligibility determination.
• Range of Scheduled Hours: This data is stored as Working hours in Assignments. Based on the Min and Max ranges the eligibility is determined.
• Work Location: The Location is stored in Assignments, and can be used for Eligibility.

Derived Factors:

There are six Derived Factors.

• Age
• Length of Service
• Comp Level
• Full Time Equivalent
• Hours Worked
• Age and LOS

In these criteria, we can mention the Defined Derived factors to either return a Yes or No, based on the ranges mentioned in them. If it’s a Yes, it's a Pass.

Others:

• Benefits Group: The Benefit Group of a Participant is stored in Peoples form. It can be used for Eligibility.
• COBRA Qualified Beneficiary: Here we list the row as a Pass, if the Participant has a COBRA QB record for the particular Program or PTIP.
• Continuing Participation: It tracks the date as of which the payments for a Benefit must be made to continue in the Benefits. It’s usually applicable for the Ex-Employees and Beneficiaries turned COBRA participants.
• Health Coverage Selected: This can be used to evaluate Eligibility based on the Enrolments the participant has.
• Participation in Another Program: Its more over similar to Health Coverage Selected Option, however with just a choice of Plan.
• Rule: We can use a FF here to return Y and N. Unlike all other Tabs, this tab is counted as an AND. If all the FFs Pass, its pass, else fail.
• Total Coverage Volume: This is used to track the entire Coverage amount / Premium across all plans and OIPLs. This can be used, when a firm allows only a particular amount as a Cap for benefits, and puts it in a First come, first serve Basis. However it’s always advisable to use a rule.
• Total Participants: This is similar to the Total Coverage Volume. However, this counts the number of Participants not the Coverage.
• User Defined Criteria: Often referred to as UDC. OAB allows us to create an UDC and use that for Eligibility Determination. The UDC Button helps us create a new Criterion, and use that in the ranges of Lookups / Value sets.

Related Coverage:

This criterion looks at the Enrolment data, either as of Eligibility determination day or the day before. The different checks are:

• Covered by
• Eligible For
• Enrolled in

The various Enrolment levels, where these checks can be applied are: Plan, PLIP, PTIP and Program. Other than these checks, there are two more additional checks that can be added.

• Dependent Eligible for another PTIP: Can be used to determine Participant eligibility based on Dependent's eligibility as of Day of Eligibility determination.
• Other Coverage: An indicator, that checks if the Participant avails coverage from outside, and then use that as an Eligibility Indicator.

Display All:

Once all our criteria are set and saved. We can use this tab to view them all in one screen. While troubleshooting, this will be the first tab we would like to visit, as this gives a clear picture of all the criteria and the values in use for the eligibility profile.

Laws of Participant Eligibility Profiles

• The Exclude Flag makes the Condition act in inversion of the statement. Which means it satisfies, if the condition mentioned is not true.
• We should pay extra attention while using the Exclude flag. For an example, if we have 10 Benefit Groups, namely 1 to 10; and we want to make an Eligibility profile which should pass for all except 8 and 9. We should not mention all benefit groups in the list and mark 8 and 9 as exclude. This will create issues, when we add another Benefit group in future. It’s always advised to just exclude the two groups and not mention any other group as an ‘include’.
• All Criteria tabs have effective dates in place. We should date track to insert / end date any record.
• More than one Criteria is considered AND.
• Conditions in a criterion are considered AND.
• Rows in a Condition are considered OR; except the Rules Condition. Rules are considered AND.
• For an example, See Figure 6.22 – Eligibility Profiles Display:

(Figure 6.22 – Eligibility Profile Display)

• Assignment status and Full/Part Time are two conditions from the Employment tab. So they will be AND-ed. Tobacco Use is from Personal, so it will be AND-ed with the Employment Criteria. However rows inside a Condition will be OR. Like the Participant should either be in Active Assignment OR Terminate Assignment. In Rules the rows will be AND-ed.
• The Best way to understand this is, forget the Criteria, and consider all conditions as Independent Conditions. All conditions will be AND-ed. The Rows inside the Condition will be OR; except for the case of Rules.

Dependent Eligibility Profiles

Now, let's have a look at the Dependent Eligibility Profiles. The Dependent eligibility profiles are used to enforce eligibility criteria upon Dependents. Our enterprise might want to add some conditions with which a Dependent can be covered. Things like age, Disability factor, other eligibility etc are some basic criteria upon which enterprise make decision whether to allow or decline the dependent to be enrolled. See Figure 6.23 – Dependent Eligibility Profile.

Responsibility: HRMS Manager

Navigation: Total Compensation -> General Definitions-> Eligibility Profiles -> Dependent Coverage

(Figure 6.23 – Dependent Eligibility Profile)

Steps: Date track to a suitable effective date, Create a new Record.