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.

Usage of Eligibility Profiles

Once we are done with all the Eligibility profiles we wanted; it’s time now to attach them. We are going to talk about the Participant Eligibility Profiles first. The Eligibility Profiles can be attached in five different places. Those would be:

Program
Plan Type in Program
Plan in Program
Plan
Option in Plan (Not applicable, if the plan does not have options.)

Even the order of evaluation is the same. So first BENMNGLE (The Benefits Engine aka BENefits MaNaGer for Life Events) goes and evaluates the Eligibility profiles attached at the Program level. If the participant passes that, it goes to the Next level, which would be the PTIP. Similarly, it goes down till the OIPL. If failed in any of the stages, it goes to the next one. For an Example, if the Active - Medical PTIP Failed, It will jump on to the PTIP with next sequence which would be the Active - Dental.

It all happens with the sequence numbers. For the Programs, it picks the Core Programs first and picks the COBRA at the last. For the Plan not in Programs, it considers their sequences and starts from the Plan, and then ends with OIPL (If OIPLs are there).

When we say, the Program eligibility is pass, what exactly does that mean? Does that mean all the eligibility profiles attached to that Program are passing? No. there is logic. We will discuss about that, however let's first see, how to attach an Eligibility Profile. We know that the eligibility can be attached in five different places. Let's play with the Program eligibility first. See Figure 6.24 – Program Eligibility.

Responsibility: HRMS Manager

Navigation: Total Compensation -> Program and Plans -> Programs

(Figure 6.24 – Program Eligibility)

Steps: Date track to a suitable effective date, Query the Program, and click on the Participation Eligibility Button.

Participation Start Date	The date as of which the Participation will start if a Person is found Eligible. The same date is used for the Calculation of Eligibility, unless is Overridden with Coverage Start date. Use "As of Event Date"
Participation End Date	The date as of which the previous enrolment will end. This can be overridden with Coverage end date. Use "One Day Before Event"
Waiting Period	We can define a Waiting Period for the Comp Object.
Maximum Enrolment	We can define a Maximum period for which a Participant can be enrolled in the Particular Comp Object.
Eligibility Button	This is where we define eligibility. Described below.
Life Event Button	We will discuss about this in Life Event Eligibility section.

Coming down to the Eligibility Button, there are two tabs here; Profiles and Rules. As part of an implementation we can use either of them; however it is always advised to use only one in all cases. Like, if we are using Eligibility Profiles, use Eligibility Profiles throughout the Implementation, else if we are using Rules, use rules everywhere. We can use Rules in Eligibility Profiles as well. Hence Profiles have an edge over the Rules.

Here, we will confine ourselves to Profiles.

In any particular level, we can have multiple Eligibility Profiles attached. We can mark them as "Required". Now, the ones marked as required are the mandatory profiles that a Participant must pass to be eligible for the level. The Design is, a Participant must pass all Mandatory and One Optional (the ones that are not marked as required) to be eligible for the level.

Let's take few examples

We have four mandatory and three optional profiles: Participant must pass all Mandatory and One of the three Optional Profiles.
We have four mandatory and one optional profiles: Participant must pass all the Profiles, as there is just one Optional, so even the optional will work as mandatory
We have no mandatory and four optional profiles: Participant must pass any of the four optional Profiles.
We have no mandatory and one optional profile: Participant must pass the profile.

With this we learnt how to set Eligibility Profiles in Programs. In all other four levels the exercise is same. We will have to repeat the same steps where ever we need the eligibility to be set up.

This is very important to design our eligibility in a manner that, we do not force the system to do a lot of rework. For an example, if the requirement says, Benefit Group A people should not get any Medical plans. How are we going to do it? Which level should we target?

We will create an Eligibility profile first, which will say, Benefit Group A- Exclude
We cannot attach that to Program Level, as we want the A people to get other Plans that are not in Medical.
We can do it at the PLIP or Plan level, however we will have to attach it to all PLIPs / Plans in the Medical plan type, so that will be a lot of re-evaluation by the system.
We can still do it at the OIPL level; however it will be even worse.
We will go to the PTIP level and attach that.

OK, one more example. Benefit group B people are eligible for the ABC Medical Plan in the Active Program; however they are not eligible for the same plan in Retiree Program.

We will create a similar Profile first.
We cannot attach the Profile at Program level, we are clear about that.
We cannot do it at PTIP level, as other Plans in the PTIP will be impacted.
We cannot attach at the Plan level, as the Plan level is evaluated both for Active and Retiree Program.
We will attach it to the Retiree - ABC Medical Plan PLIP.

This should have made the concept clear.

Life Event Driven Eligibility

There can be requirements, where our enterprise wants us to open up eligibility to all who experience a particular life event. To elaborate, we want the eligibility to open up, without checking any participant data; which should be as simple as this, if the Life event experienced is XYZ, open up eligibility; Or sometimes just the reverse case, where we want to decline Eligibility to participants experiencing a Particular life event. Both of these cases are more useful in COBRA Eligibility Determination. We will discuss more about COBRA set up later in this chapter. However let's learn how to implement Life event Eligibility.

Like eligibility profiles, Life event eligibility can be put in all five levels. So we will take the example of Program level first to learn about set up. See Figure 6.25 – Life Event Eligibility.

Responsibility: HRMS Manager

Navigation: Total Compensation -> Program and Plans -> Programs

(Figure 6.25 – Life Event Eligibility)

Steps:

Date track to a suitable effective date, Query the Program, and click on the Participation Eligibility Button.
Now click on the Life Event Button

Life Event	Name of the Life event for which Eligibility needs to be opened up or closed.
Participation Start Date	The date as of which the Participation will start if a Person is found Eligible. The same date is used for the Calculation of Eligibility, unless is Overridden with Coverage Start date. Use "As of Event Date" or Leave Blank.
Participation End Date	The date as of which the previous enrolment will end. This can be overridden with Coverage end date. Use "One Day Before Event" or Leave Blank.
Ignore Participation Override	This enforces the system to ignore the already overridden Participants and re-evaluate their eligibility, when this life event is run on them. Let's say, we have a set of overridden Participants, however we want them to be Ineligible for the Program after experiencing the Life Event. In cases like that we might want to check this flag.
Overridable	Checking this flag enables us to Override the result produced by this life event. This might be useful for the reverse case of the example cited above.
Waiting Period	We can define a Waiting Period for the Comp Object based on the Life event. This is very specific to the Life event in definition.
Maximum Enrolment	We can define a Maximum period for which a Participant can be enrolled in the Particular Comp Object. This is very specific to the Life event in definition. In the Applies to field, we can choose a code, in a case where we want the maximum period to be applicable to specific persons.
Family Member	In case we want the Participant to have a set of contacts in system in order to be eligible for the Comp Object, choose the set of family member code.
Eligible/Ineligible	This is a mandatory flag. This one tells the system, whether we want the Participant to be Eligible/Ineligible for the Comp Object as a resultant of this life event.

6.3.6.6 Usage of Dependent Eligibility Profiles

As we have already defined our Dependent Eligibility profiles, let’s go attach them. Before that, we know that the Dependent eligibility profiles are used to determine the eligibility of dependents, to say who is eligible to be covered and who is not; great.

Where all can we attach dependent Eligibility? We can, at three levels, namely Program, PTIP and Plan. However we can attach them at only one level out of the three levels given above. This is based on the concept of designation. Let's take an example, Joe has three children, and he wants to cover them as part of his enrolment package. If he has to do so, he has to designate his contacts to the Comp Objects, right? Here we can tell the system where to designate the dependents. The options are Program, PTIP and Plan; so based on the Enterprise's choice, Joe gets to designate the dependents in one of the three levels. That is called Designation Rule.

The most preferred Designation level is PTIP. If we choose program, Joe will lose the liberty to make the designations based on plan type. He will not be able to add Child1 and Child2 to Medical and just child3 to Vision. If the level is Program, the children chosen to be covered will be covered in all plan types. Similarly, Plan as a level is risky. What if we want one program to be at plan level and one at PTIP level? The Plan might be used across both Programs, so it will create issues later. So the best option is PTIP. It keeps it Program specific and gives the liberty to cover dependents based on Plan types.

Designation rules are Program specific. We can have One Program having designations at the Plan level, and another at the PTIP level. The level at which the designations are done, the eligibility is determined at the same level. So if our Designation level is Plan, the Dependent eligibility will be assigned at the Plan level.

Where to set the designation level now? See Figure 6.26 – Using Dependent Eligibility.

Responsibility: HRMS Manager

Navigation: Total Compensation -> Program and Plans -> Program Enrolment Requirements

(Figure 6.26 – Using Dependent Eligibility)

Steps:

o Date track to a suitable effective date, Query the Program

o Now click on the Dependent Coverage Tab

o The Designation Level box can be updated based on the Design.

Now, if we wish to make it at the Program level:

o Choose the Designation Level as Program

o Click on Program tab there

o Click on Eligibility Profiles

If it’s the Plan type level:

o Choose the Designation Level as Plan Type in Program

o Click on Plan Type tab there

o Click on Eligibility Profiles

If it’s the Plan level:

o Choose the Designation Level as Plan

o Save and close the form

o Go to Total Compensation -> Program and Plans -> Plan Enrolment Requirements

o Query the plan with the suitable date

o Click on Designations Tab

o Click on Dependent Tab

o Click on Eligibility Profiles

Now, we know where to define dependent eligibility. Now, let's see how to use the profiles.

In the Eligibility Profiles tab, we have two choices. Either we can use a set of Eligibility Profiles created earlier OR use a rule (Coverage Eligibility Rule). If it has to be Profiles, list down all the Profiles there and mark them as Mandatory based on our requirements. The logic is same here as well. The Dependent must pass all Mandatory and at least one Optional (Not marked as Mandatory) profile.

If any of our Profiles use one or more Derived Factors, then check the Derived Factors Apply Flag near the Eligibility Profiles Button.