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

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

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?

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.

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.

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.

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

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  

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.

Timeline

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.

Q&A