Background

As delivered, PeopleSoft provides Base Benefits for a manual enrollment process and Benefits Administration for automation and self-service. The intention of allowing Base Benefits and Benefits Administration in the same database is to have the different functionality used on different groups of employees - not having both processes used on the same individual employee record.

Issue

The ramifications of making changes directly in the base benefit pages are:

1. Updating the tables will not trigger a Ben Admin event.  If Benefits Administration ever does process this enrollment the eligibility rules will apply and it may terminate the coverage. There is no guarantee that there will never be an occasion where Ben Admin will act on the plan, because the Ben Admin COBOL is robust and checks every aspect of enrollments for employees whose records are being processed, every time it is run. 
2. Ben Admin will not recognize rows inserted in employee enrollments using Base Benefits and may not recognize entries via Correct History in rows previously written by Ben Admin.  The continuing use of Base Benefits, on employees whose Benefits Participation record shows Ben Admin, could cause errors that are progressively more difficult to resolve.  
3. The interface process used for Delta Dental (Ben100A and HIPAA 834) will pick up changes to benefits enrollments or dependents if a new effective dated row is inserted by Ben Admin.  If Change History is used to amend enrollments or dependents, the changes likely will not be 'visible' to the interface process.

Analysis

If the changes are made to rows dated BEFORE the start date of Benefits Administration on the Installation Table, there is no impact and no events are created.

Date example -- Changes for a Base Benefits row from the year 2000 would be fine if the Ben Admin start date is 01/01/2010. 

Navigation: Set Up HRMS > Install > Installation Table > Product Specific tab

If manual changes are made on the base benefit pages, Ben Admin will look at the previous benefit event to determine what options were prepared, not the base benefit table. Any manual changes made in Base Benefits will be ignored. This can have consequences that are severe and difficult to overcome.

Source: Oracle Documentation ID 889633.1 - What is the Impact of Updating Base Benefits Enrollments When Utilizing Benefits Administration?

Recommendations

Appropriate training and communication should be provided to all staff members that have access to base benefit pages.

In conjunction with HR Managers, Campus Security Administrators can determine the appropriate access to Base Benefit tables.  It is recommended that View Only access be granted to most staff accessing base benefit pages.  Elevated access can be considered for staff with advanced system experience in administering benefits within PeopleSoft.

Considerations

Specific to CSU, any references to manual data entry in the base benefit tables does not apply to the CSU modification for Permitting Events. The Permitting Event resides within the Base Benefit Health pages but data entry for permitting events does not update the health table.

Cross-Functional Impacts (Positive / Negative)

None.

To be filled out by BSA (from Change Impact Tracking log):

The following items will be answered / addressed by Change Management:

1. Areas of potential change resistance to proposed HR process / policy changes?

   Resistance would be to change bad habits. Since it’s a long established process with many campuses, this habit will need to be broken. They do this as a workaround if they think the system is not working properly. But the root cause is not understanding why the system is setup the way it is to maintain data integrity.

2. Potential resource needs in order to plan, engage, prepare, and/or deploy the change?

   Communication and training needs to be provided for Benefits staff on the appropriate/ correct way to do this in the system. Recorded training sessions are currently available on SharePoint.

3. Associated costs relative to the scope of the change to requirements requested?

   Free recorded training sessions with PowerPoint slides are available on SharePoint. Training is free so the cost impact would be the time commitment. People won’t be allowed to do what they’re doing currently in this process in 9.2 and they should not be doing it now either.

4. Training needs or if a straightforward change?

   See #2 & 3.  Our recommendation is for Security to remove access to “Correction Mode” in the Benefits pages only, or restrict the access to a single Management-level staff member at each campus. Only one person in Benefits departments (management level staff) should have correction mode access. This should happen once data cleanup has been completed and will eliminate the issue and the behavior altogether.

5. Implication on any other related process / functions?

   This behavior adversely affects benefit interfaces that go to CalPERS, State Controller's Office (SCO), and other benefit vendors. If the data is incorrect on internal networks, it reflects across multiple other system networks. This causes additional errors in the system for next open enrollment and what happens with employees’ data in the future, and potential time spent on cleanup when discrepancies are found. 
   While campuses are doing it as a quick and easy workaround to fix something needed on their end, the appropriate action is to contact CMS if they can’t figure out how the system should be updated efficiently.

   Recommendation is to take away access now, before it’s forced in 9.2. Awareness of the need for changing this behavior now would have more favorable impact on campuses vs. when institutionalized as the “new rule”.

REVISION CONTROL

Revision History

Review/Approval History

End of Article