Setting Up Additional Manage Base Benefits Features

This chapter discusses how to:

• Set up Benefits Billing.

• Set up COBRA administration.

• Set up HIPAA tables.

• Setup internal administrative contact information.

• Set up multiple jobs.

• Set up retroactive benefits and deductions.

Setting Up Benefits Billing

To set up benefits billing, use the Billing Parameters (BILLING_PARAMETERS) and Billing Calendar (BILLING_CALENDAR) components.

This section provides an overview of setting up benefits billing and discusses how to:

• Setting up billing parameters.

• Setting up payment due dates.

Understanding Benefits Billing Set Up

Benefits Billing enables you to bill employees and dependents directly for benefit plan elections instead of paying through the payroll deduction process. Benefits Billing can be used for both regular and COBRA (Consolidated Omnibus Budget Reconciliation Act) benefits.

To set up Benefits Billing:

1. Set up the rules for billing on the Billing Parameter page.

   You establish only one set of billing parameters for your entire system.

2. Set up the billing cycle using the Billing Calendar page.

Pages Used to Set Up Benefits Billing

Setting Up Billing Parameters

Access the Billing Parameter page.

Billing Frequency	Indicate how often to calculate billing amounts.
Days Due	Enter the number of days after the billing period begin date that the payment is due. This value is used to determine the default payment due date on the Billing Calendar page. Note. COBRA requirements mandate at least 30 days for COBRA billing.
Days to Overdue	Enter the number of days past the payment due date that qualify a payment as overdue.

Setting Up Payment Due Dates

Access the Billing Calendar page.

Billing Period	When you first access the page, you must enter a billing period code that identifies the billing period that you’re setting up the calendar for. The code may be any unique four-character combination. PeopleSoft recommends YYMM as an identification code for monthly calendars.
Period Begin Date and Period End Date	The system uses the period begin date and the days due value set on the Billing Parameter page to calculate default payment due dates for regular and COBRA Benefits Billing processes. The system uses the period end date to evaluate effective dates. The period end date is also used as the posting date for billing charges. Note. The system does not edit the billing frequency to ensure that it matches the begin and end dates.
Payment Due, COBRA Payment Due	The system automatically sets Payment Due and COBRA Payment Due according to the days due values set in the Billing Parameters page and the period begin date that you've defined for this billing period. You can override the default dates if necessary. Note. You cannot set a COBRA due date that is less than 30 days past the begin date.
Comment	(Optional.) Enter text to appear on all of the billing statements sent out for this billing period.
Billing Calculation Run, Billing Statements Printed	Indicates current processing stage for this billing calendar.

Setting Up Internal Administrative Contact Information

To set up internal administrative contact information, use the Administrative Contacts (BENEF_ADM_CONTACTS) component.

This section discusses how to set up internal administrative contact information.

Understanding Internal Administrative Contact Information

The internal administrative contact component is similar to the Vendor component, and is used to record internal contacts for HIPAA (Health Insurance Portability and Accountability Act) and COBRA functions. This internal contact structure enables you to identify a single contact person once, and then provides flexibility for you to reference that contact multiple times throughout the Manage Base Benefits business process.

For HIPAA, the internal administrative contact component is used to record the HIPAA Administrator that must be included on all printed HIPAA certificates. The COBRA function uses this component to populate COBRA notification letters.

The contacts that are entered on the Benefits Administrative Contacts page can then be referenced on the Benefits Plan Table page and the Benefit Program Definition page. Note that while only HIPAA and COBRA currently use these contacts, they can actually be used for all benefit plan types.

Note. HIPAA reports BEN022 and BEN023 will now expect to find a HIPAA administrative contact printed on all certificates.

Page Used to Set up Internal Administrative Contact Information

Setting Up Internal Administrative Contact Information

Access the Benef Administrative Contacts page.

Benefits Contact ID	Identifies the individual contact, and assigns the next available contact ID.
Contact Description	This is an alternative contact search description.
Contact Name	Identifies the name of the internal contact. This contact can be a person, a department, or another name. The contact name is unlimited.

Setting Up COBRA Administration

To set up COBRA administration, use the COBRA Event Rules (CBR_EVENT_RULES) component.

This section lists prerequisites and discusses how to set up COBRA Administration.

• Link COBRA to your benefit packages.

• Identify COBRA eligible benefit plans.

• Establish coverage codes for COBRA.

• Define COBRA qualifying events.

• Identify COBRA events.

Prerequisites

Before you can set up COBRA Administration, complete the following steps.

1. Activate COBRA Administration on the Installation table.

   1. Access the Installation Table - Product Specific page.

   2. Select the COBRA Administration check box under the Benefits Functions group box.

2. Identify your company's COBRA administrator.

   Identify your COBRA administrative personnel using the Benefits Administrative Contacts page. Once you have entered this information, you can reference these COBRA administrators within each benefit program. This is the contact information (name and address) which will be included in printed COBRA notification letters.

Pages Used to Set Up COBRA Administration

Linking COBRA to Benefit Packages

To link COBRA to your benefit package, use the Benefit Program Table to identify the following:

• The age at which a dependent is no longer considered a dependent.

• The age at which a dependent is no longer considered a student.

• Whether a disabled person is excluded from the age limits.

• Whether dependents are ineligible for regular benefits, if married.

You will also identify any extra charges that you want added to the cost of the benefits for both disabled and non-disabled persons.

See Also

Building Base Benefit Programs

Identifying COBRA-Eligible Benefit Plans

To identify which benefit plans offered within a benefit program are eligible for COBRA administration, use the Benefit Program Table. When you design your benefit program, if you designate Health (1x) and FSA (60) plan types as COBRA-qualified plan types, you must designate an option code for those plan types. The system uses the option codes for the enrollment of employees into COBRA benefit plans. This restriction only applies if you do not use PeopleSoft Enterprise Benefits Administration.

In general, only medical and health plan types (plan types 1x and 6x) are designated as COBRA-qualified plan types. However, PeopleSoft allows you to identify non-medical plan types as COBRA-qualified plans if your organization’s policy is to offer them to your employees as part of their COBRA coverage. You will need to modify the COBRA COBOL for plan types other than Medical (1x) or FSA (6x) plan types.

For COBRA, medical coverage is a core benefit. COBRA administration defines non-core benefits such as dental and vision care benefits. If your benefits program combines core and non-core benefits, you may have to offer COBRA participants a core option that is not available to other active employees.

Nonqualified medical, dental, and vision plans are not currently supported for COBRA coverage. You should not designate these plans as COBRA-qualified plans.

See Also

Building Base Benefit Programs

Establishing Coverage Codes for COBRA

Coverage codes are created on the Coverage Code page. PeopleSoft has four coverage codes that work for COBRA Administration. You can add more codes as required by your organization, however, the coverage codes for nonqualified dependents are not for use by COBRA Administration.

The COBRA Coverage Set field on the Coverage Code page is used during COBRA processing to determine the type of coverage to offer a participant. To indicate that a coverage code is to be used during COBRA processing, enter a two-digit code in the COBRA Coverage Set field.

Example:

Let's say you have the following coverage codes:

• 1 – Employee only

• 2 – Employee + spouse

• 3 – Employee + dependents

• 4 – Family

• A – Employee only

• B – Employee + spouse

• C – Employee + dependents

• D — Family

You want COBRA processing to only consider coverage codes A, B, C, and D as eligible codes and you have decided that CO will represent COBRA eligible coverage codes. You will enter CO in the COBRA Coverage Set field for coverage codes A, B, C, and D.

Defining COBRA-Qualifying Events

PeopleSoft delivers COBRA Administration with the following qualifying events:

• Voluntary termination.

• Involuntary termination.

• Reduction of hours.

• Death of an employee.

• Divorce and legal separation.

• Loss of dependent status (due to marriage or arrival at the age limit for benefit coverage).

• Medicare eligibility.

• Retirement.

According to federal government guidelines, employees and spouses of employees who undergo voluntary or involuntary termination for "gross misconduct" are not eligible for COBRA coverage. PeopleSoft does not deliver COBRA Administration with the capability to differentiate between terminations for gross misconduct and other termination types, but you can set up action reason codes and add PeopleCode to have the system perform this function.

You should review the set of events provided, change them, and add new events as necessary based on the qualifying events that your organization recognizes. Then, for each valid event:

• Define when COBRA coverage begins and how long it will last.

• Define any grace periods.

• Define when the employee has to notify the organization of the event and when the organization has to notify the employee of COBRA benefits.

• Define the qualified beneficiaries for the event.

• Define the secondary event rules for the event.

If you want to set up additional COBRA event rule records for a particular COBRA event classification, insert a new row with a different effective date. The system will always use the record with the effective date that is closest to the current date.

You can set up COBRA event rule records with future effective dates. This allows you to have the definition of a COBRA event classification change on a predetermined date.

Determining COBRA Coverage Period

COBRA coverage begins the day following the last day of regular active coverage and generally extends for 18 or 36 months following a qualifying event. If an employee is terminated on the 15th, COBRA coverage begins on the 16th.

The determination of the COBRA period begin date is dependent on several factors. The first factor is whether or not the COBRA period includes alternative coverage. Alternative coverage is the grace period of continued active coverage beyond the date when an employee’s active health coverage would normally terminate. Grace periods are provided either manually through the Manage Base Benefits business process or automatically with the Benefits Administration system.

Regardless of whether the COBRA period includes the alternative coverage, the COBRA coverage begin date is always set to the day following the last day of active coverage. It is the calculation of the COBRA coverage end date that is dependent on the inclusion or exclusion of alternative coverage.

In the case of disabled COBRA participants, however, regulations allow an extension up to 11 months past the original 18 months for termination of employment and reduction in work hours events. You can extend the coverage for disabled participants by completing the Additional Months if Disabled field on the Event Rules page.

The date on which COBRA coverage ends is defined as the COBRA period begin date plus the number of months of coverage plus any additional months if disabled.

Providing Grace Periods

There may be situations where you want to provide grace periods for your employees that begin on the day following the last day of regular coverage. During these grace periods, your organization pays all or part of the employee benefits premiums. Extending the termination dates of an individual’s health benefit plans past the COBRA-qualifying event date sets grace periods. You can do this manually or arrange for it to happen automatically through PeopleSoft Benefits Administration processes. To provide a grace period, select the Include Alternative Coverage check box and specify when you want the COBRA period to actually begin, which will be the day after the grace period ends. The system includes grace periods in the COBRA coverage period. You can select to have COBRA begin on the day of the event, on the first day of the month after the event, or on the first day of the pay period after the event day.

If you do not want a grace period to be included in the COBRA period, do not select Include Alternate Coverage. The COBRA period begin date will be the same and COBRA coverage will start on the day after the grace period ends. This means that if your organization paid for all or part of the employee premiums during a grace period, the COBRA period does not begin until after the conclusion of alternative coverage. The length of continued coverage from the qualifying event is the length of the grace period plus 18 months of COBRA continuation coverage.

The system calculates the COBRA coverage end date according to a formula derived from the parameters defined in the COBRA event rules.

Here are examples showing how COBRA can calculate COBRA coverage end dates for an employee who experiences a COBRA qualifying event on March 15, has a pay period on March 22, whose last day of active coverage is on June 30, and is allowed 18 months of COBRA coverage.

The coverage end date will always be equivalent to the COBRA period begin date plus the months of coverage for each plan type, with two exceptions:

• For employees and spouses, COBRA coverage will end before the scheduled coverage end date on the date that the employee or spouse turns 65 and becomes eligible for Medicare.

• For dependents of employees who become eligible for Medicare, the COBRA coverage end date will be the latter of the COBRA period begin date or the employee’s Medicare entitlement date plus 36 months.

Setting Rules For Secondary COBRA Events

Secondary COBRA-qualifying events are events that extend the amount of time a participant is eligible for COBRA coverage.

An event must fulfill the following basic qualifications in order for it to qualify as a COBRA secondary event:

• The initial COBRA event must be a COBRA event classification associated with a change to an employee’s job status, such as a reduction in hours, termination, or retirement.

• The employee and dependent must currently be participating in an active initial COBRA event and have COBRA coverage.

• The secondary event must be one of the COBRA event classifications that involves loss of coverage for the employee’s dependent, such as divorce, marriage of dependent, overage dependent, death of employee, or a Medicare entitlement.

For example, suppose a married employee is terminated. The employee and his spouse will receive 18 months of COBRA coverage after the termination. If the employee and spouse divorce, the divorce would be considered a secondary event for the ex-spouse. If the divorce occurred before the termination, the termination would not be a secondary event for the ex-spouse.

The classification of the event determines the amount of time for which coverage is extended and the method by which coverage is extended. In the previous example, the secondary event would cause the coverage of the ex-spouse to be extended from 18 to 36 months from the coverage begin date of the initial event. In general, even with secondary events, a dependent’s coverage cannot exceed 36 months.

The exception would be a case where the secondary event is a Medicare entitlement. When a qualified COBRA beneficiary turns 65, and is Medicare entitled, COBRA coverage ceases. In this case, the system adds the 36 months to the COBRA event date (the Medicare entitled date), thereby extending the dependent’s COBRA coverage past 36 months.

COBRA-Qualified Beneficiary

The following chart illustrates how the Benefit Lost Level and COBRA-Qualified Beneficiary relate to one another. For each COBRA Event Classification, it displays the Benefit Lost Level and COBRA-Qualified Beneficiaries typically associated with that event.

See Also

Creating Event Rules

Identifying COBRA Events

Access the Event Rules page.

COBRA Event Rules

COBRA Period Determination

Secondary Event Rules

COBRA Qualified Dependents

Setting Up HIPAA Tables

To set up HIPAA, use the EDI Trading Partners (BN_EDI_PARTNERS) and EDI 834 Transaction Map Table (BN_834_MAP_TBL) components.

This section discusses how to:

• Define EDI trading partners.

• Create transaction map tables.

Pages Used to Set Up HIPAA Tables

Defining EDI Trading Partners

Access the EDI Trading Partners page.

Name	Enter the name of the EDI trading partner. A trading partner can be one of your health care providers but doesn't have to be.
External Partner ID	Identify the receiving partner. This ID must be agreed upon by both the sender and receiver.
Internal Partner ID	Identify the sending partner. This ID must be agreed upon by both the sender and receiver.
Application Receiver's Code	Enter a value.
Application Sender's Code	Enter a value.
Use Alternate Group Number for Trans Set Identifier Code	Select this field to enter a value in Alternate Group Number.
Alternate Group Number	If you selected the Use Alternate Group Number for Trans Set Indenitfier Code field, then you must enter a value. The system uses the Alternate Group Number value in place of the External Partner ID when creating the concatenated Transaction Set Identifier Code value.
Security Password Required	Select this field to enter a value in the Password field. This indicates security information in the HIPAA file.
Password	If you selected the Security Password Required field, then you must enter a 10–character password. The systems sets the ISA03 value to '‘01’ in the ISA segment and then sends the Password value in position ISA04.
Master Policy Number	Enter a value. In the header of the HIPAAA file, the system includes a new REF segment (Transaction Set Policy Number) with a Reference ID Qualifier of ‘38’ along with this Master Policy Number value you entered in this field.
Subscriber Number	Select from the following values: Select EmplID for the value in this field the HIPAA process uses the EmplID of the Subscriber as the REF02 value in the REF*0F segment in loop 2000. Select SSN for the value in this field and the HIPAA process uses the Social Security Number (NID) of the Subscriber instead of the EmplID. The records for dependents also use the Subscriber’s SSN for the REF02 value. Note. Note: If you select SSN and the Subscriber does not have a Social Security Number (NID), the file uses the EmplID for that Subscriber and his/her members’ records.
Last Control Number	The system increments this number with each transmission to the partner. Initially the control number is set to 0. You can manually reset the control number, if necessary.
Field Separator	Enter the character used to separate fields in each segment of the EDI file. The default value is an asterisk (*), which is the value suggested by the reporting standard.
Segment Terminator	Enter the character used to mark the end of each segment of the EDI file. The default value is a tilde (~), which is the value suggested by the standard.
Subelement Separator	Enter the character used to separate component data elements within a composite data structure of the EDI file. The default value is a colon (:), which is the value suggested by the standard. Note. This delimiter is not used in PeopleSoft delivered 834 transaction segments.
File Name	Enter the name for the EDI file.
File Directory	Enter the directory where the file will be created. If this field is left blank, the file will be created in the directory PS_SERVDIR.

Creating Transaction Map Tables

Access the EDI 834 Transaction Map Table page.

Some of the codes required by the ASC X12.834 Implementation Guide need to be mapped from PeopleSoft or customer defined codes. PeopleSoft delivers the mapping for existing codes. If you add your own codes, you will need to map those codes to EDI 834 codes.

Default EDI Code	Each Plan Type has one default EDI code used in the HIPAA file, for example HLT for Plan Type 10. Note. If you do not enter a value in the EDI Insurance Line Code field on the Benefit Plan Table page, the system uses the mapped value for the plan type as the Default EDI Code value in the HIPAA file.
Original Description	The description of the code that is being mapped.
EDI 834 Value	The ASC X12.834 value corresponding to the PeopleSoft or customer defined code.
EDI 834 Description	The ASC X12.834 code description.

Setting Up Multiple Jobs

To set up multiple job features, use the Multiple Job Options (BAS_MJ_OPTIONS_PGP) component.

This section discusses how to set up multiple jobs.

Understanding Multiple Jobs

Many organizations have employees that work in more than one job at the same time. The system needs to know how to process these employees with more than one job. Rules need to be created to answer questions such as:

• Which jobs should contribute salary information for calculating deductions that are based on the employee's earnings?

• Which jobs should provide pay group information, hire date, and termination date?

Page Used to Set Up Multiple Jobs

Setting Up Rules for Multiple Jobs

Access the Multiple-Job Optns page.

When a Job is Hired, Re-Hired or Added

When a Job Terminates

Explode activity triggers to all Benefit Records

Workflow for Job Actions

While the multiple jobs rules are automatically applied for hires, rehires and terminations, you can automatically notify a benefits administrator to review the situation for any job action.

For example, a change to the full-time/part-time status of a concurrent job might affect the determination of the primary job.

To configure this function:

1. Locate the action/action reason combinations that should generate a workflow notification.

2. Select the Notify Benefits Administrator check box.

   Whenever a job action is entered into the system for one of these combinations, a worklist entry is generated for the benefits administrator.

   Selecting the worklist entry accesses the Administrator to the Primary Jobs Maintenance page for that employee.

Setting Up Retroactive Benefits and Deductions

To set up retroactive benefits and deductions, use the Retroactive Ben/Ded Program (RETRO_DED_TABLE) and Retro Ben/Ded Mass Request (RETRODED_MASS_RQST) components.

This section lists prerequisites and discusses how to:

• Activate retroactive benefits and deductions.

• Define retroactive benefit and deduction programs.

• Defining the parameters for mass retroactive benefit and deduction requests.

To set up retroactive benefits and deductions, you:

1. Activate retroactive benefits and deductions on the Installation page.

2. Define retroactive benefits and deductions programs.

3. If you are creating mass requests, define the retroactive benefit deduction selection criteria.

   The Retroactive Benefit and Deduction Mass Request feature gives you the ability to create a large number of requests via a batch process. This is necessary when you retroactively update system-level pages that affect multiple employees. Changes to the following system-level pages could generate mass retroactive benefit and deduction requests:

   • Deduction Table.

   • General Deduction Table.

   • Most benefit plan design tables (such as the Life and AD/D Plan Table).

   • Calculation Rules Table.

   • All rate tables.

Note. Because the Retroactive Benefit and Deduction feature involves PeopleSoft Enterprise Payroll for North America processes in the calculation of retroactive benefits and deductions and the loading of retroactive benefit and deduction totals to payroll, it is unavailable to those users who do not currently implement Payroll for North America.

Deductions based on earnings (such as garnishments or savings plan deductions) are not included in the retroactive benefits and deductions process. They are handled as part of the Payroll for North America adjustment process.

Prerequisites

Before you can define retroactive benefits and deduction programs, you must:

1. Activate Retroactive Benefits and Deductions on the Installation table.

2. Set up core tables and benefit plans.

See Setting Up and Installing PeopleSoft HRMS.

See Setting Up Base Benefits Core Tables.

See Setting Up Benefit Plans.

Pages Used to Define Retroactive Benefit and Deduction Programs and Mass Requests

Defining Retroactive Benefit and Deduction Programs

Access the Retroactive Ben/Ded Program (retroactive benefit/deduction program) page.

Program Definition

Warning! If you change the Retro Program ID after retroactive benefit and deduction processing begins, improper retroactive benefit and deduction calculations will result.

Refunds Paysheet Processing

Deductions Tab

Mass Retro Override Tab

If you are setting up a mass retroactive benefit and deduction program, fill in the Start Date Ovrd for Mass Retro (start date override for mass retroactive benefit/deduction) and End Date Ovrd for Mass Retro (end date override for mass retroactive benefit/deduction) fields to override the process start date and process end date for the requests that are created.

Refunds Versus Deductions

The system only loads refunds to employee paysheets. In situations where the retroactive benefit and deduction process finds that employees owe additional payments, the system collects these funds through the Payroll for North America arrears adjustment process. The system drops all employee retroactive benefits and deductions into the arrears balance via arrears adjustments. If there is enough money, the system will collect the amounts during the current payroll run, according to the arrears rules that you defined for that deduction.

See Also

Processing Retroactive Benefits and Deductions

Setting Up Deduction Codes

Defining the Parameters for Mass Retroactive Benefit and Deduction Requests

Access the Retro Ded Mass Rqst Criteria (retroactive deduction mass request criteria) page.

Description	Enter a description that explains the purpose of this mass retroactive benefit and deduction ID.
Comments	Describe the need for the particular mass retroactive benefit and deduction program that you are creating.
Process Start Dt (process start date) and Process End Dt (process end date)	Define the period during which the mass request calculates retroactive benefits or deductions. The Process End Dt is automatically set to today’s date when a new Mass Request ID is created. The process start date becomes the effective date of the generated requests, except for cases where the selected employee begins to meet the criteria at some point after the start date, in which case that latter date is used as the effective date of the request.
Retro Program ID (retroactive benefit/deduction program ID)	Select an appropriate ID from the list. Only those retroactive benefit and deduction programs defined for Mass processing will appear.
Selection Start Dt (selection start date) Selection End Dt (selection end date)	During the processing period set up by the Process Start and End Dates, the system searches employee records active between the Selection Start and Selection End Dates for the information specified in the Selection Criteria group box.
Delete Request	Use this check box to stop the mass retro benefit and deduction process if you have not yet run the calculation process for your Mass Retro ID. When you run the Mass Retro batch process, it deletes every Mass Request ID and related request that has this check box selected and has not yet been through the calculation process.
Hire Date	(Optional.) Use to select employees that have a hire date on the Employment Table that is less than or equal to this date. If this field is blank, the system creates requests for employees that have a hire date less than or equal to the Selection End Dt.
Service Date	Functions the same way as the Hire Date field except that it refers back to the Employment Table’s Service Date field.

Selection Criteria

The fields in this group box define the types of employees that the Mass Retro batch process looks for. You can set up multiple rows of selection criteria for your mass retroactive benefit and deduction program to open up a new one.

Enter the other selection criteria as necessary. Values for all selection criteria fields that are blank will be selected by the system. If you want to use more than one of the available values of a particular field in your selection request, enter an additional row.

The three Elig Cal Days (eligible calculation days) fields are linked to the Job Code, Location Code, and Union Code fields. They each enable you to create selection requests for employees who have been assigned a specific job code, location or union code for a specific number of days. For each Elig Cal Days field, the system takes a look at the effective date of the selected job record.