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.




Wordage



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 15th; 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.



Configuring Life Events



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)

Name

Name of the Life Event

Type

This defines the Type of Life Event, and sometimes tells us about the module where it is to be used. We will discuss about some Important ones here.

Absence: Used in PTO
iRecruitment: Used in iRec
Compensation: Used in CWB
Checklist: Used in Core-HR Checklists
Waiting Period Satisfied: Used in OAB, seeded Life Events, to trigger when a waiting period is satisfied.
Scheduled Open: Used in OAB, seeded Life Event, for Open.

Short Name

A short name for the Life Event

Short Code

A short code for the Life Event

Evaluation Rule 

This rule gets called whenever a Potential Life event is processed. With this rule we can trigger child Life Events and also change the Occurred date, notified date etc.

Description 

The Description of the life event. This one appears on the SSHR Screen. 

Life Event Treatment 

With this code, we can control the Detection of past / future temporal events. 

Timeliness Days/ Timeliness Period/ Rule

We can choose one of these three options to tell the system about the restriction on the Life Event. The Restriction is on the difference between Notified date and the Occurred Date. 

Timeliness Evaluation 

This works in conjunction with the condition set by the trio mentioned above. We can choose to set the Life Event status to either Void or Manual. 
Example: If we want our employees to report the Marriages within 30 days. We can set the Timeliness Days to 30, and make the Evaluation to set it to Manual. So that, anyone who reports the Marriage after 30 days of actual marriage date, the Potential Life Event will be set to Manual, and will need HR intervention.

Occurred Date Determination 

There will be instances, where we want the Life event to be triggered the day after the data change. Like Termination. Sometime on the same day, like divorce. This code helps the system identify those settings. Default is the same day.

Selectable for Self Service 

This code can be used to update the system about the instances where this Life event can be chosen by the Participant in SSHR. This is applicable to the Explicit: Person initiated Life events only. One of the Following code can be chosen.

All: The Life event can be chosen with all SSHR transactions.
Add/update/delete Family Members: This LE can be chosen when the user adds / updates / end dates one of its contacts.
Add/Update Family Members: This LE can be chosen when the user Adds/ updates any of its contacts.
Delete Family Member: This LE can be chosen only when the user End dates a Family Member.
Basic Registration: This LE can be chosen with the New Hire/ New Applicant Registration process.
COBRA Registration: This LE can be chosen when a user registers itself to claim as a COBRA Beneficiary.
Basic and COBRA Registration: This LE can be used as a New Hire/ New Applicant / New COBRA Beneficiary registration. 

Check Related Person Eligibility 

This flag is checked when the Life Event causes another Life event on the related Person's of the Participant. This can be used when there is a Causes Related Person Life Event entered. Example, a Divorce might trigger COBRA Eligibility for the Divorced Spouse.

Override

If the Override flag is checked, It’s marked as an Important Life Event. This helps when two Life events are triggered with the same Occurred date; In those cases the one that's marked Override is run and the Other one is voided. If both of them or None of them are Overridden then the Collapsing logic comes in to picture.

COBRA Qualifying Event

This marks the Life event to be a COBRA Qualifying Life Event. We will learn more about these in COBRA Configuration.

 

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.



Person Changes




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)



Name

Name of the Person Change

Table Name

The Table on which we want the trigger to be placed. For an example, if we want to trigger the life event, when the assignment category of a participant changes, then we can select the PER_ALL_ASSIGNMENTS table.

Column Name

Name of the Column on which the data change should happen

Old Value and New Value

The Change should happen from what to what.

Rule

We can use a rule if we the codes are not enough to establish the business condition. Once the rule is attached, system evaluates the values in OLD and NEW value columns with the conditions mentioned. It executes the rule and then returns a yes or no. Check out the FF chapter for more on Trigger Rules.

Rule Overrides

If we want the System to determine the Life Event only with the Rule, ignoring the OLD and NEW value, then check this box. If the Box is unchecked, the Life Event gets triggered with any possibility of the Value condition or the Rule.

What-If Label

Enter the Text we want to see when what if analysis is done on Eligibility. This is a self service page that enables the user to create eligibility models.

 

 

 

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.




Collapsing Life Events



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)

Sequence

A Sequence Number

Results in

The Winner Life Event name

Tolerance Days

The number days after the earliest life event Occurred date beyond which the system ignores detected Life Events when evaluating the Conditions.

Life Event

List the potential Life events here. 

Expression

Separate two Potential Life events with a Condition, like ‘AND’ or ‘OR’ 

Collapsing Logic 

So one of the Life Events becomes the Winner. Something should happen to the other one right? Either Void it or Purge the Entry or we may put any rule to define the action. This can be updated here.
Choose Void any matching life events

Life Event Occurred Date

We can alter the Occurred date of the Winning Life event by this code.
Choose Earliest Life Event Date or Resulting Event Date.

 

 




Derived Factors and Temporal



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)


Name

Name of the Factor

Currency

The Currency of the Compensation Factor.

Source

Could be one of the following: 
Defined Balance: Use this if we are using a Balance to track the Compensation.
Benefit Balance Type: Use this if our compensation is being stored in a Benefit Balance
Stated Comp Periodicity: Use this if we want to use the Actual Compensation of the Person.
Oracle Incentive Compensation: Use this if we are using the Incentives as the comp factor here.
Rule: If none of the above satisfies our business condition, use a rule.

Defined Balance

Name the Balance here, if we are using the Defined Balance as a Source.

Benefits Balance Type

If the Source is Benefit Balance, name the Benefit Balance here.

Stated Compensation Periodicity

Choose the Periodicity at which the Compensation is going to be calculated. For example, if it’s Monthly, then the Compensation in consideration will be Monthly salary.

Calculation Rule

The Rule to be mentioned here, if the Source is a Rule.

Alternate Value

This is not used in this form. This is a Pseudo-field.

Determination 

We can use the determination code / rule to tell the system the date as of which the Compensation is to be fetched.

Min and Max Values 

This is the bracket here. The Min and Max tells us about the boundaries through which the Factor operates.

Rounding Code 

The rounding code to be applied on the Resultant Compensation.

Incentive Compensation Information

This is used when the source is defined as "Oracle Incentive Compensation". Here we can put the dates with in which the Incentives are to be calculated.


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)


Name

Name of the Factor

Source

Could be one of the following: 
Defined Balance: Use this if we are using a Balance to track the Hours Worked by the Participant.
Benefit Balance: Use this if ‘Hours worked’ is being stored in a Benefit Balance.
Rule: If none of the above satisfies our business condition, use a rule.

Defined Balance

Name the Balance here, if we are using the Defined Balance as a Source.

Benefits Balance

If the Source is Benefit Balance, name the Benefit Balance here.

Calculation Rule

The Rule to be mentioned here, if the Source is a Rule.

Frequency

Here we mention the period for which we want the Hours to be calculated.

Once or Continuing

This is where we can tell the System, if we want the Hours to be calculated just ONCE with any given Life event; or if we want the Hours to be calculated every time we run a Participation Batch Process.

Alternate Value

This is not used in this form. This is a Pseudo-field.

Determination 

We can use the determination code / rule to tell the system the date as of which the Hours are to be fetched.

Min and Max Values 

This is the bracket here. The Min and Max tells us about the boundaries through which the Factor operates.

Rounding Code 

The rounding code to be applied on the Resultant Hours.


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)

Name

Name of the Factor

UOM

The unit of measure in the dimension of Time.

Calculation Rule

The Rule to calculate the LOS should be mentioned here. If the LOS logic is simple, we can just use the Date to use code and the Date of determination to get the LOS calculated.

Alternate Value

This is not used in this form. This is a Pseudo-field.

Date to Use

This is where we tell the system to calculate the LOS from what date. Could be DOH, Adjusted DOH or Original DOH. We might also opt for a rule, if the date to use is complex.

Use Override Service Date

If this flag is checked, the system uses the Overridden Service date if present in the Participation Override window.

Determination 

We can use the determination code / rule to tell the system the date as of which the LOS are to be Calculated.

Min and Max Values 

This is the bracket here. The Min and Max tells us about the boundaries through which the Factor operates.

Rounding Code 

The rounding code to be applied on the Resultant LOS.


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.




(Figure 6.18 – DF Full Time Equivalent)

Name

Name of the Factor

Min and Max Values 

This is the bracket here. The Min and Max tells us about the boundaries through which the Factor operates.

Rounding Code 

The rounding code to be applied on the Resultant Percentage of FTE.

Use Primary Assignment Only

Check this flag, if we want to use the Primary assignment only, for the calculation of the Percentage of FTE.

Use Sum of all Assignments

Checking this flag tells the system to sum up all the active assignments for the participant and then calculate the Percentage of FTE.



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)

Name

Name of the Factor

UOM

The unit of measure in the dimension of Time.

Age to use

This is not used in this form. This is a Pseudo-field.

Calculation Rule

The Rule to calculate the Age should be mentioned here. If the Age Calculation logic is simple, we can just use the Date to use code and the Date of determination to get the Age calculated.

Determination 

We can use the determination code / rule to tell the system the date as of which the Age is to be Calculated.

Min and Max Values 

This is the bracket here. The Min and Max tells us about the boundaries through which the Factor operates.

Rounding Code 

The rounding code to be applied on the Resultant 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)

Name

Name of the Factor

Age Factor

Add the Age Derived Factor here.

LOS Factor

Add the LOS Derived Factor here.

Min and Max Values 

This is the bracket here. The Min and Max tells us about the boundaries through which the Factor operates.





Temporal



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



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



(Figure 6.21 – Eligibility Profiles)

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

Name

Name of the Eligibility Profile

Description

Description of the Profile

Assignment Type

This is where we specify the Assignments to be used and their precedence for Eligibility Profile evaluation. This could be one of the following: 

Any Assignment: Could pick any assignment that is fed by the BENMNGLE
Applicant Assignment Only: Picks only the Applicant Assignment
Benefits Assignment Only: Picks only Benefits Assignment.
Benefits then Employee Assignment: Picks Benefits assignment first, if not found, picks Employee assignment.
Employee Assignment Only: Picks Employee Assignments.
Employee then Benefits Assignment: Picks Employee assignment first, if not found, picks Benefits assignment.
Employee then Benefits then Applicant Assignment: Picks Employee assignment first, if not found, picks Benefits assignment, if neither is found, picks Application Assignment.

Status 

Could be one of these: Active, Pending, Inactive, and Pending. Same as Explained in Plans and Programs.

Applies To

Choose Benefits Profile. As it is being used in Benefits and Rates Eligibility.

 

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.

Name

Name of the Eligibility Profile

Status 

Could be one of these: Active, Pending, Inactive, and Pending. Same as Explained in Plans and Programs.

Regulation 

Choose a Regulation that defines the eligibility criteria maintained in this profile. It’s Optional.

Description

A description of the Profile.

Rule

We can use a Rule here, if the Criteria do not satisfy our objective of the Profile. 

Criteria 

Use one or more conditions in the Criteria tabs to set up the eligibility.

Display All 

It displays all the conditions except the Rule, in a list format.