1. Cloud Benefits: Changing Track
Moving from Unrestricted to Life Event model
Lynda Cowan-Tollefson
Director of Cloud Benefits
Product Management
June 2017
Confidential – Oracle Internal/Restricted/Highly Restricted

3. Cloud Benefits : Discussion Topics
Change
Unrestricted enrollment Model
Life Event enrollment Model
Business Reasons for using each model
Pros and Cons
Case Study: Life Event Analysis, Timeline for Transition, Steps for Transition
Recommendations
Q&A

4. Change
Both the world and our view of it are constantly changing; circumstances never remain static, so why should our responses to them be forever locked in their initial form?
We may like to pretend we live in a straightforward but we also know it's not.
The best answer often changes over time.
So its OK to change, its even expected
Why does the simple act of re-opening a settled question to re-examine it from another angle and of then wanting to answer it differently seem to require such courage?

5. Unrestricted Enrollment Model- anytime, any day, every day
Unrestricted model allows participants to update their benefits anytime, any day, every day
Every attempt to alter the benefits enrollment will close any previous unrestricted event and starts a new unrestricted life event . Re-sets Coverage Start Date.
Unrestricted processing does not affect other types of life events.
You can have an Unrestricted event, and an Explicit event, on the same day.
Unrestricted Life Event
Unrestricted Open
Unrestricted Rate & Eligibility Recalculate
Can be run in Batch mode or individual mode
In Fusion, unlike in EBS, Unrestricted life events can be backed out. An Unrestricted event is created for each processing attempt by the employee (via SSBEN), and by the admin (in BSC). For example, an employee’s Person Life Events can display an Unrestricted on March 1st, and another one on March 15. It’s possible to back out the March 15th event, to restore the March 1st enrollments. This tracks history of changes, to some extent.
To enable unrestricted processing, specify the default benefits relationship in the Configure Default Benefits Relationships task in the Setup and Maintenance work area.

6. Life Event Enrollment Model aka a Restricted event
A life event is simply that a change a person experiences
The change can be to person data or a scheduled event that can potentially result in an enrollment opportunity.
Life event model offers a restricted benefits enrollment method where updates to benefits require specific conditions are met.
Life event conditions restrict dates, time to make changes, and type of changes you can make.
An event can be configured dependant on HR data change. For example, termination, new hire, relocation.
An employee can self-report an event in Self-Service Benefits Enrollment.
Events are flexible in that if you have 5 events, you can configure different enrollment & eligibility behavior for each. This provides flexibility for meeting detailed business requirements. (Ex: New hire allows you to select any Medical plan; but Gain Dependent only allows you to change options within a plan.)
Offers Collapsing capability.

7. Business Reasons: Unrestricted vs. Explicit Life Event
Reasons to use Unrestricted Model
If employees can change benefits any day, any time (ex: US 401k savings plan)
There’s no need to track detail of what work or personal change resulted in the enrollment update
If you’re fine with coverage start date updating at each enrollment
You don’t have requirements for different coverage / rate start dates or plan eligibility, based on different circumstances.
You have limited reporting requirements
Reasons to use Explicit Life Event Model
If only specific events allow employee to make benefits updates. (ex: US IRS Section 125 plans)
You need to report & track what resulted in the enrollment update.
Don’t want the administrative burden of daily running the recalculate process in batch mode for entire population.
You want to report on the details of benefits changes
model to allow for tracking, monitoring of insurances changes or events that affect the employee’s benefits. This will allow the functional users that support the system to feel confident that they know what is happening in a person’s record instead of trying to piece together what happening with varying levels of success.

8. Pros & Cons: Unrestricted vs. Explicit Life Event
Pros of using Unrestricted Model
Empower employee to make their own enrollments, without calls to administrator
Lessened maintenance of Intervening events ‘backing out’ of historical enrollments
Less configuration setup and maintenance
Pros of using Explicit Life Event Model
Can be a fully automated solution
Collapsing capability
Employee can self-report certain life events if configured (ex: Marriage, Relocation) in Self-Service Enrollment
Fancy configuration: Each event can have its own enrollment restrictions

9. Case Study: Unrestricted to Life event Model
Analyze pattern of life events and review past and project into future.
Create a timeline for conversion to new model
Determine how to manage Life events that occur in the cut off period
Decide on cut over date to move to life event model
Make all Unrestricted plans inactive a day prior to cut-over date.
Remove the legal entity defaults for unrestricted and add life event entries prior to this date
Create new benefit relations for life event model for all active employees prior to this cut-over date.
End the Unrestricted enrollments after new life event based equivalent enrollments are in the system via the conversion event
Enter future events: future hires, contract terminations, worker category updates, change in work hours, change in salary, etc
In Test Configure life events
In Test create a new program to house current enrollments
In Test Code the new life event program with events and enrollment rules
In Test run process to end date all of the unrestricted benefits relationships in current program
In Test Close current program but allow it to remain accessible to access history
In Test Enroll everyone with a batch process into new program with formula
In Test : Test, test, and test some more. Test events, processing schedule, batch processes, back outs, intervening events, re-instatement rules. Review the event counts, frequency of events etc to identify a proper schedule for processing events in bulk.
In Test Create processing schedule to run processes as needed
 When all testing is a successful create plan to add new configuration to Production
Configure life events
Create a program to house all plans
Code the program with events and enrollment rules
Run process to end date all of the unrestricted benefits relationships
Enroll everyone with a batch process into new program with formula configured to default the enrollments from prior plans so an explicit re-enrolment is not required.
Validate
Create processing schedule to run processes as needed

10. Life Event Analysis example
Run a monthly query on how many of what type of events you are experiencing in your employee population. This will help determine which life events you’ll want to configure. You will also look back at this analysis when you load future life events after conversion.

11. Timeline

12. Recommendations
Create new plans and convert to them. Do not update existing Unrestricted program to Life Event driven. It will error:
Don’t create / convert past life events. Only create Future life events after Conversion date.
Don’t convert enrollment history. Just convert enrollments effective Conversion date.

13. Q&A