Enrolment

Enrolment

This is an important part of Benefits Configuration. This is where we define the specific details of a Life Event. Things like, what are the electable choices, the Defaults, when should the Coverage start, when should the existing Coverage end, the enrolment period etc. There are mainly two screens we will be discussing while talking about setting up the enrolment Opportunities; let's discus them one by one.

Before that, what are the different levels where we can set up the Enrolment Rules / Requirements? There are the same five levels where we can do that.

  • Program
  • Plan Type in Program
  • Plan in Program
  • Plan
  • Option in Plan

However, there are a few set ups that can be defined at certain levels only. It’s not that distinct like Eligibility is, but while going through it, we will learn, why the set ups are designated only to be at certain levels and not at all five levels.

Talking about the five levels, the designers have divided into two different screens, namely "Program Enrolment Requirements" and "Plan Enrolment Requirements". As the name suggests, the former is used to track the Rules for the Program, PTIP and PLIP levels, while the later tracks the Plan and OIPL levels. We can discuss the rules in two ways, either goes by screen, where we can go on discussing the things present at the screens; or we can go by the Rules, and go to the screens that do that. Let’s take the second option, as it would be easy to understand the Functionality first and then see where all can that be set up. Let's go through the Functionalities first then.

Enrolment Method

The Enrolment Method is the method by which we want the participants to choose their plans and Options. Not clear right? It was a confusing statement. The participants will log in or call up the Phone Reps to opt for a Plan and Option. Simple as is, so what are we defining here? Let’s look for an answer by discussing it a little further.

There will be plans or Options that will be given by the Firm as a free coverage. Like some firms might give an Accidental Insurance for free for all its Active employees. So the Employees get it, even if they do not opt for it. It’s just one example. There will be a lot of such benefits that an enterprise will give its Employees for free. Let's call them Automatic Benefits, as the benefits are given to an employee automatically, even if he does not opt for it.

So what is the other method in place? The other method is called the Explicit Method. The Explicit method is the one that is used to choose enrolments by the Participants. For a comp object which is not Automatic, can be termed as Explicit. Again the Explicit Elections can be either Explicit or may be Default. Once the defaults are applied, and the elections are not changed by the Participant, the election will then be known as the Default election. If the election is updated, it is known as the explicit election. We will learn more about Default elections while setting up Defaults.

In Automatic enrolment method, there are a few things that a designer must take care of.

  • There should not be more than or less than one eligible choices in the PTIP.
  • There should not be more than or less than one Electable choices in the PTIP.

So in Automatic enrolments, Eligibility = Electability = Default. Because, if more than one eligible / electable choice exists, the system will not be able to put the Participant in one comp object. If the Plan Type / PTIP allow having more than one elections / Participant, it will be a different case; however that is not very common. Again, in Automatic enrolments, if we wish to have certain business logic applied, we can certainly use an Automatic rule to return the Automatic enrolment for the Comp Object.

Now, let's see where all can we define the Enrolment Methods. The Enrolment Methods can be defined in the following levels:

  • Generic Level
    • Program
    • PTIP
    • PLIP
    • Plan
  • Life Event Level
    • Program
    • PTIP
    • PLIP
    • Plan

We know that, the first three levels are defined in the Program Enrolments Requirements screen. Here is the Navigation path

Responsibility: HRMS Manager

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

Now, we can click on the Generic tab, and then fill in the Enrolment Method for Program, PTIP and PLIPs in the Program, Plan Type and Plan sub tabs respectively.

If we click on the Life Event tab above, we can then choose the Program, PTIP and PLIPs in the Program, Plan Type and Plan sub tabs respectively to fill in the Enrolment Methods for the Life Events listed on the left of it.

The way it gets evaluated is it goes on finding the Life event specific Information first, and looks for the lowest level present. Here the Lowest level is the Plan level. If it finds a record there, that gives a valid value for the enrolment method, it uses that, else it looks a level higher. Similarly it goes on through the PLIP, PTIP and finally arrives at the Program Level. If does not find any record there, it then starts searching in the General tabs, the same way it did for the life events. It goes from Plan to Program in that order and finally wherever it finds a record, it uses the code.

Actually, all the enrolment features we are going to discuss henceforth are evaluated the same way. The search is always Life Event specific first, that to starting from the lowest level to the highest level. If no records found, the system then looks for the Generic tabs. If we have put the codes in more than one level, then the lower level overrides the values at the higher level. Clear? We used the Enrolment Method code as an example, as it is transparent. So let's move on to the next functionality.

Enrolment Code and Defaults

The enrolment code is commonly known as Electability. This is where we set the enrolment options of a particular Plan type, sometimes even in the generic level. The enrolments are usually used at Life event levels. Now, what are defaults? What if a Participant does not choose anything in one/ all plan types for one enrolment period? He might not opt to change anything or might just forget about his enrolment period. For those situations, OAB gives us an option to choose a default enrolment. If nothing is chosen, then this default enrolment will be applied to the Participant.

So let's check out what all levels and codes do we have from Oracle. We will look for levels first. As we have discussed initially, there are many levels where we can attach enrolment requirements. For Enrolment codes, here are the levels.

  • Generic Level
    • Program level
    • PTIP Level
    • PLIP Level
    • Plan level
    • OIPL level
  • Life event Level
    • Program level
    • PTIP level
    • PLIP level
    • Plan level
    • OIPL level

Here the laws are the same. The first three levels are defined in Program Enrolment Requirements screen. The others can be done in the "Plan Enrolment Requirement Screen". Again the Life Event levels are checked first from bottom to top, and then the Generic Level. The level in which the system gets the first code, it uses the same, and stops searching.

For Defaults, the levels are:

  • Generic Level
    • Program level
    • PTIP Level
    • PLIP Level
    • OIPL level
  • Life event Level
    • Program level
    • PTIP level
    • PLIP level
    • Plan level
    • OIPL level

The Default enrolment codes are not available at Generic- Plan level. This can be used only in a case where the Plan is not in Program.

(Figure 6.27 – Enrolment Requirements)

Now let's look at the available Enrolment codes. See Figure 6.27 – Enrolment Requirements.

Let's have a look at Default Codes. However before that, there is something called as "Assign on Default Flag". This flag is present on the following levels:

  • Generic Level
    • PLIP Level
    • OIPL level
  • Life event Level
    • PLIP level
    • Plan level
    • OIPL level

This flag should be checked at only one Comp Object (OIPL Or Plan, if there are no options) in a Plan type. The system identifies that as the Default Comp Object. When we specify a code, that asks the system to use a Default enrolment, the system then takes the same Comp Object and uses that as the default. It will have more clarity when we talk about the codes. Let's do that now.

Timings

Timing is nothing but the dates on which the Life Event related things happen. For an example, we must tell the system about when do we want the Coverage and rate to start, when to start the enrolment period and for how many days, when to close the window etc. All these are known as the Timing of the Enrolment. Let's discuss them one by one.

Coverage and Rate Dates

The Coverage Start date tells the system as of which the Coverage should start, for the Comp Object, if chosen. Similarly, the End date tells the system about when to end the Coverage of the Comp Object that the Participant was enjoying. Similarly, for Rates, the similar logic applies.

Let's take an example. Joe had "Medical Plan 1" with Employee + spouse tier since 2009. Now, on 23rd Feb 2010 he Experiences a Life event, for which the Coverage start date is "First of Next Month", and End date is "End of Month". So is the configuration for Rate start and end dates. Now, as Joe had the Life Event in the middle of the Month, if he opts for another Medical plan, let's say "Medical Plan 2" then, Joe will remain Enrolled in "Medical Plan 1" until end of February, and will get enrolled in "Medical Plan 2", as of first of March. Similarly, Joe will pay Plan 1 rates for the Month of February, and from March onwards, he will pay the Plan 2 Rate amount.

So what are the available Levels, where we can define the Coverage and Rate dates?

  • Generic Level
    • Program Level
    • PTIP Level
    • PLIP Level
  • Life Event Level
    • Program Level
    • PLIP Level

The Basic rules of Enrolments apply here too. First Life Event then Generic; and both with a Bottom to Top approach. In the Life Event level, the level that is seen is the Program level; which is the most widely used level. However if there is any Particular PLIP that needs to have different set of dates, than all other PLIPs in the Program, we can click on the "Enrolment Period of Plan" button. We will have to mention the PLIPs there, and then define the Coverage and Rate dates.

Enrolment Period

The Enrolment period of the life event is the window in which the elections can be done. Every Life event with an enrolment opportunity must have an enrolment period in order to give the Participant a time frame, in which they can make / alter elections. All life events have their own set of rules and window requirements; like we might want to give a 60 days window for a New Hire, and just a 7 days window for a Gain Dependent Life event.

The enrolment period can be defined only at Life Event - Program and Life Event - PLIP level, in the Timing - Life events tab. See Figure 6.28 – Enrolment Timing.

(Figure 6.28 – Enrolment Timing)

Reinstate and Override Code

If a Life Event is backed out and rerun, the system has a capability of reinstating the elections/ defaults made as part of the backed out Life event. So the Reinstatement code is the code that can tell the system more about the reinstatement.

The Available codes are:

  • Reinstate all if no electability change for life event
  • Reinstate if no change for backed out enrolment
  • Reinstate if electability exists for backed out result
  • Never Reinstate

Now, if the Reinstate happens, and the activity rates of the previous elections were overridden, then the Override code is the one that tells the system, what to do with rates. There are two codes:

  • Always use overridden rates
  • Override the rates if no change

The levels at which the Reinstate and Override can be attached are Life Event - Program and Life Event - PLIP level, in the Timing - Life events tab.

Default Apply Date

This is the date as of which the Defaults are applied. As we know the defaults are the enrolments that are applied, if a Person fails to make an explicit election on any given plan type; there can be logic on application of default dates as well.

In Timing tab in Program Enrolment Requirements, there is a text box with caption "Days after enrolment Period to apply defaults". The Text box is designed to take a number and a sign; numbers like -8, 15 etc. The system then takes the Enrolment period end date, adds the given number to it and the resultant date is used as the Default apply date. So if it’s -8, the system is going to add -8 to the enrolment period end date and return that as the default apply date.

Days after Enrolment Period for Ineligibility Date

OAB enables us with an option, where we can tell the system a date after which the person will no longer be found eligible for the benefits for which the life event in context, made him eligible. So, let's talk about Joe again. Joe was found eligible for the COBRA Program, however if this particular field is set to 1, Joe will no longer be found eligible for the COBRA Program, once the Enrolment period is over. This field can be found in the same Timing-> Life events tab in Program Enrolment Requirements.

This code is usually used with COBRA set up. Because First time COBRA eligibility is mostly driven by Life Events, and firms would like to put a condition there, a Person must elect COBRA with that Life Event that made him eligible, if he does not, the Eligibility will be gone.

Additional Processing Days

This sets the Processing End Date. In this case the Processing End Date will be set as the Enrolment Period End date + the number mentioned in this text box. The Processing End Date will be the date after which no enrolment changes can be done, not even by the Benefits administrator via forms. Usually for some Life Events, Benefit Administrators keep few additional days in hand, so that they can alter the benefits of Participant on request, that extra set of dates are known as the Additional Processing days, and the deadline is known as the Processing End date.

Close Enrolment Date to Use

Once the enrolment Period is over, we usually close the events on the Participants. Because unless an active Life Event is closed on a Participant, no other life event can be processed. OAB provides a particular concurrent process that can close the enrolments for the users. Now, we need to tell the system, when to close the events. There are these three options.

  • Processing End Date: Once the Processing end date is over, close the Life Event.
  • When Elections are made: Close the Life Event once the enrolments are made.
  • When enrolment Period Ends: Close the Life Event once the enrolments are made, without looking at the Processing End date.

Once the Process is run, the Life Events will be set to close once the conditions are met.

Limitations

We can also set Limitations on the Compensation Objects. Limitations can include the following:

  • Minimum and Maximum number of enrolments in a Plan type / PTIP / Plan
    • This can be found in the Plan Type level (Plan Type Screen), PTIP level (Program enrolment Requirement Screen) and Plan level (Plan enrolment Requirement Screen). We have a set of Min and Max flags and text box, like we had in Derived Factors. These can be filled in to say, how many enrolments are possible in that level. The best case scenario is to put it at the PTIP level with 1 min and 1 max. In COBRA Program, it’s preferred to have No Min and 1 Max.
  • A mandatory period of enrolment once enrolled
    • This can be found in the same three screens as explained above. However with this, we can add in a mandate for the Participant to stay enrolled for a given period of time, once enrolled.
  • Option is a Mandatory enrolment
    • This flag can be found only at the OIPL level. This flag is used to define an Option as a Mandatory election in the Plan.

PEER

PEER stands for Post Election Edit Rules. This rule fires once the elections are made and the save Button is clicked, either on the Forms or on the Web (SSHR). Now, what is the purpose of this? Imagine a situation where we have some business rules defined on the basis of Election; something like, one will have to choose the same tier in all health coverage plan types, MED, DEN and VIS, or something like one cannot opt for Spousal Life Insurance, unless s/he takes Employee Term Life Insurance.

(Figure 6.29 – PEER)

So in these cases, the decision is based on the elections one makes. We cannot manage these business rules in Eligibility / Electability, as we never know what the Participant is going to choose. In cases like this, PEER Helps. We can key in the Business retirements in a FF, and attach that FF to the PEER section of the Comp Object in concern. The Rule will fire when the elections are saved, and with that we can either allow the save or ask the Participant to alter the elections with a Message with the details. See Figure 6.29 – PEER.

PEERs are not Life event specific. The Rules are set only at the Generic level, and they act same for all Life Events. PEERs can be attached at the following levels:

  • Generic Level
    • PTIP Level
    • PLIP Level
    • Plan Level
    • OIPL Level

Enrolment Actions

There would be cases where our firm might like to put in some extra restrictions on the enrolments too. For example, a dependent must have an address, to enrol a spouse one must produce a marriage certificate, sometimes we would need our HR team to review the Newly Eligible Participants manually etc; so all these can be managed through something called as Action Items. We can set up the action item, and set up deadline by which the Participant must produce the required documents. Once the documents are verified, our HR representative can go in to the Participant record and approve the enrolment.

The Enrolment Actions are different than the PEER; as PEER does not allow us to save elections unless the business conditions are met. However the Action types allow the elections, and just ask for Documents. The levels at which the Action Types can be set are the Program Level and the Plan Level. The Action types are not specific to Life Events, they are generic and act the same way for all Life Events.