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.