US20120246088A1

US20120246088A1 - Benefits administration system and methods of use and doing business

Info

Publication number: US20120246088A1
Application number: US13/323,750
Authority: US
Inventors: John Steinbarth; Patricia Steinbarth
Original assignee: Individual
Current assignee: Individual
Priority date: 2003-12-05
Filing date: 2011-12-12
Publication date: 2012-09-27
Also published as: US20060064313A1; US8078481B2

Abstract

An automated benefit administration system and methods of use and doing business. The full system includes a wide range of features including application of business rules to enrollment, eligibility, and maintenance data input, making of business decisions based on the specific data entered, and issuing of notices based on business rule discrepancies including notices to third parties when deemed appropriate. The full system also is secure while providing remote access, including through the Internet, limits access based on user hierarchy, allows user customization of various features including communications vehicles (e-mail, letter correspondence, or facsimile) and of the format of certain communications, provides automatic enrollment in Cobra without re-entry of beneficiary data, accomplishes various types of financial reconciliation, accommodates differing organizational structures and groupings of entities, provides business rule over-ride capability for certain users, and provides robust information about carriers and their services.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 11/006,278, filed Dec. 6, 2004, entitled “Benefits Administration System and Methods of Use and Doing Business,” the disclosure of which is hereby incorporated by reference. U.S. patent application Ser. No. 11/006,278 claims the benefit of U.S. Provisional Patent Application Ser. No. 60/526,961, filed Dec. 5, 2003, entitled “Benefit Administration System and Methods of Use and Doing Business,” the disclosure of which is hereby incorporated by reference.
The following document is a copyrighted text. All copyrights are reserved as allowed by law.

BACKGROUND

The present invention relates to benefits administration systems and methods of use and doing business. The present invention also relates to automated systems for administering benefits.
In business and industry, benefits plans are common. They often include health care, savings or retirement plan, insurance, and other funding or services for employees. Administration of benefits has long presented a substantial challenge for business and industry.
One prior art automated system designed for administration of benefits has been known as the “Phoenix” system. The Phoenix system automated certain benefits administration tasks and included features such as:

- a. enrollment of beneficiaries through a limited-access, private computer network such as an business's internal computer network;
- b. automated but limited application of certain basic business rules to inform the user, at the time of entry on-screen only, of certain limited missing information such as a beneficiary's address, birthdate dependents, or benefits plan choice;
- c. automated reconciliation of payments provided they exactly match the amount invoiced to the customer;
- d. limited automation of physical letter generation such as generation of a welcome letter to a new customer setting forth little more than the effective date of initiation of plan coverage for the customer;
- e. automated maintenance of certain limited carrier data, including certain carrier rates and rating areas;
- f. limited automation of Cobra enrollment by re-keying data for the Cobra enrollment into the system;
- g. limited automation of open enrollment and re-qualification by automated sending out of notices and issuance of failure to re-qualify reports, allowing manual entry of termination if desired by the administrator;
- h. automated termination and issuance of termination notice to the carrier upon-first termination of a customer and thus well prior to conclusion of the re-instatement option period; and
- i. limited periodic reconciling of payments actually received in-house by receipt at the system administrator's mailroom, routing to the finance department for entry into the system; if the payments matched exactly the amount of their respective invoices, the finance department would initiate a program through that would reconcile the cash received against the invoice; non-matching payments would require substantial manual involvement in the reconciliation process
- j. The Phoenix system included numerous limitations and issues, however, including:
- k. limited carrier data such as not including data (only zip codes and rates);
- l. lack of automated creation of a Cobra record from information already in the system for a given beneficiary;
- m. with regard to issuance of notices for enrollment or re-qualification, lacked ability select sub-groups (e.g., groups under 5 employees) for issuance of notices only to them, and also lacked automatic termination of groups that do not re-qualify;
- n. providing notice of termination of a group to a carrier prior to expiration of a re-qualification period for the group including Cobra members of the group;
- o. lack of automatic changing of employee status upon change of employee coverage (e.g., by changing from employee-only coverage to employee and spouse coverage), along with lack of automated corrected billing as a result of the change;
- p. lack of automated reconciliation of cash upon closing of a batch of inputted premium checks, and automatic reconciling of premium notices with payments provided by multiple payments (e.g., multiple checks providing payment for a particular premium amount);
- q. limited application of business rules to ensure correct data entry and limiting of enrollment as allowed by the rules, and relatedly, no ability to issue notices other than on-screen notices of certain limited types of information that may be missing;
- r. limited ability to generate required notices, and limited or no ability to send notices through differing media (e-mail, mail, fax);
- s. no ability to allow system access through remote or separate networks, such as via the Internet;
- t. no ability to reconcile payments that do not exactly match invoice amounts, and no ability to issue notices based on matching discrepancies; and
- u. limited data handling capacity, requiring periodic purge data to run the system.

BRIEF SUMMARY OF CERTAIN ASPECTS OF THE INVENTION

In summary, the present invention relates to an automated benefit administration system and methods of use and doing business. In certain embodiments, a full system includes a wide range of features including application of business rules to enrollment, eligibility, and maintenance data input, making of business decisions based on the specific data entered, and issuing of notices based on business rule discrepancies including notices to third parties when deemed appropriate. The full system also is secure while providing remote access, including through the Internet, limits access based on user hierarchy, allows user customization of various features including communications vehicles (e-mail, letter correspondence, or facsimile) and of the format of certain communications, provides automatic enrollment in COBRA without re-entry of beneficiary data, accomplishes various types of financial reconciliation, accommodates differing organizational structures and groupings of entities, provides business rule over-ride capability for certain users, and provides robust information about carriers and their services.
There are many other novel aspects and aspects of embodiments of the present invention. They will become apparent as the specification proceeds. In this regard, it is to be understood that the scope of the invention is not be determined by whether given subject matter addresses all or particular issues in the prior art noted above or provides all or particular features identified in this brief summary.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. A-1 to A-3 are diagrams illustrating aspects of architectures in which embodiments of the present invention may be implemented.

FIGS. H-1A and H-1B show a flowchart illustrating an example process of creating a master record for a carrier, FIGS. H-2 to H-9 illustrate example screens used in carrier record functions in embodiments of the present invention, and FIG. H-10 shows an associated screen flow.

FIGS. H-11A, H-11B and H-11C show a flowchart illustrating an example process of creating a plan, FIGS. H-12 to H-14 illustrate example screens used in plan creation functions in embodiments of the present invention, and FIG. H-15 shows an associated screen flow.

FIGS. H-16 to H-19 are flowcharts illustrating example processes for admin fee, agent fee, additional fee and rate differential, FIGS. H-20 to H-31 illustrate example screens used in fee and rate functions in embodiments of the present invention, and FIG. H-32 shows an associated screen flow.

FIG. H-33 is a flowchart illustrating example zip processes, FIGS. H-34 to H-35 illustrate example screens used in zip functions in embodiments of the present invention, and FIG. H-36 shows an associated screen flow.

FIGS. I-1 and I-2 are flowcharts illustrating example COBRA processes, FIGS. I-3 to I-11 illustrate example screens used in COBRA functions in embodiments of the present invention, and FIG. I-12 shows an associated screen flow.

FIGS. I-13 to I-23 show screen flows for screens used in change management in embodiments of the present invention.

FIG. I-24 is a flowchart illustrating example requalification and open enrollment processes,

FIGS. I-25 to I-30 illustrate example screens used in requalification and open enrollment functions in embodiments of the present invention, and FIGS. I-31 to I-33 show associated screen flows.

FIG. I-34 is a flowchart illustrating example termination processes, FIGS. I-35 to I-59 illustrate example screens used in termination and reinstatement functions in embodiments of the present invention, and FIG. I-60 show an associated screen flow.

FIGS. I-61 to I-64 illustrate example screens used in appeals and grievances functions in embodiments of the present invention, and FIG. I-65 show an associated screen flow.

FIGS. I-66 to I-71 illustrate example screens used in association masters functions in embodiments of the present invention, and FIG. I-72 show an associated screen flow.

FIGS. I-73 to I-76 illustrate example screens used in carrier issues functions in embodiments of the present invention, and FIG. I-77 show an associated screen flow.

FIGS. J-1 to J-8 illustrate example screens used in billing, cash receipt, cash reconciliation and risk adjustment functions in embodiments of the present invention.

FIGS. P-1 to P-12 are flowcharts illustrating example security mechanism processes, and

FIGS. P-13 to P-38 illustrate example screens used in security mechanism functions in embodiments of the present invention.

DETAILED DESCRIPTION

Certain embodiments of the benefits administration system may (i) apply rules to enrollment, eligibility, and/or group maintenance data input, preferably all such input, and (ii) make business rule decisions based on the specific data entered, preferably including automatic actions related to correct business rules as well as issuance of notices for business rule discrepancies. These capabilities can, in certain embodiments, include business rule over-rides based on user authority level.
For example, in the insurance industry, an enrollment application is required for enrollment into any insurance plan. Enrollment rules may pertain to the input of data from this application into the benefits administration system. An example of an enrollment rule may include inputting a Social Security number (SSN) that has been assigned to another member previously. In certain embodiments, the benefits administration system can produce a notification of a duplicate SSN and may not allow the completion of the member's enrollment utilizing the duplicate SSN.
Another example of an enrollment business rule is the entry of information for a new member who requests family health coverage but does not list any dependents on the new member's enrollment application in the system. In certain embodiments, the business rules within and automatically applied by benefits administration system can require the data entry of one spouse and at least one child in order to comply with family coverage. Without this dependent information, the system may refrain from allowing finalization of the enrollment. In certain embodiments, the system can then automatically designate the member's application as pending and generate one or more notices (such as letters) advising of the need for, or requesting, the missing information.
Eligibility rules may pertain to the specific business rules set up by the insurance companies. For example, to be eligible for a certain type of insurance, an employer group may require at least two employees; or in order for an employee to be eligible, the employee may have to work at least thirty hours per week. In certain embodiments, the benefits administration system may implement these types of specific rules.
For example, if a user seeks to enter an employer group with only one employee, in certain embodiments the system can thus refuse to finalize the enrollment unless another employee's information is entered. As another example, if user enters hours—work—per week for an employee less than the business rule of 30 hours, in certain embodiments, the system will not allow finalization of the enrollment. In certain embodiments, the system may accommodate exceptions such as when a user with a predetermined authority level, such as a manager, desires to over-ride the eligibility business rule. In certain embodiments, the system can allow the exception based on pre-arranged authority levels within the system.
Group maintenance may pertain to enrollment/eligibility activities that occur after the finalization of a group's enrollment. One example may be the addition a newly hired employee to the employer group's plan. In certain embodiments, once the new employee application is received and data is entered, the system may apply one or more business rules for the waiting period for the new hire within the group within which the new hire is hired. Based on this comparison, the system may either assign a correct effective date or deny the enrollment because the employee has not properly satisfied the waiting period. In additional embodiments, if the employee is enrolled, the system may automatically issue an enrollment letter; or if denied, the system may automatically issue a denial letter.
Yet another group maintenance example may be the receipt of monthly insurance premium payments. In certain embodiments, the system may automatically issue an invoice outlining activity affecting the premium for a given period of time, such as the past month. Such activity may include adding a newly hired employee or disenrolling a terminated employee. In certain embodiments, the system may implement business rules to provide automatic reconciliation of the premium to the amount of an invoice.
In certain embodiments, the system may also be flexible enough to take into consideration activity that occurred after the creation of the invoice in reconciling the premium. For example, the monthly invoice to a given customer may total a particular amount. By the due date of the invoice, the employer may have sent notification of an employee disenrollment. The employer may have only sent a payment that deducts the premium for the disenrolled employee. In certain embodiments, the system can automatically reconcile the received payment against the invoice amount and the termination credit for the disenrolled employee.
In certain embodiments, the benefits administration system may implement varying authority levels for data entry and system operation. For example, the system may provide that (i) a data entry position may have authority to enter data but not to finalize enrollment even if all business rules are met; (ii) yet another position may have authority to finalize enrollment if all business rules have been satisfied; (iii) a supervisor may have authority to finalize enrollment with, as possible examples, minor premium shortages or non-eligibility-related missing enrollment information; (iv) managers may have authority to finalize enrollments with significant premium shortages or non-eligibility issues; and (v) a system administrator may have authority to over-ride any business rule.
Certain embodiments may also provide remote access through disparate networks, such as, for example, through the Internet, for enrollment, eligibility, or group maintenance data input. In certain embodiments, the system may then make business rule decisions based on the specific data entered. In certain embodiments, the system also may automatically perform actions related to the business rules. In certain embodiments, the system also may automatically issue notices, including on-line notice in certain embodiments, for business rule discrepancies. In certain embodiments, the system may include business rule over-rides based on the authority level of user.
In certain embodiments, the system can allow an external business customer to process enrollment, eligibility, or group maintenance via the Internet. For example, in the insurance industry, an enrollment application typically is required for enrollment into an insurance plan. In certain embodiments, the benefits administration system may allow this application to be entered remotely through a, preferably secure, Web site.
For example, an employer may request enrollment in a health insurance plan. In certain embodiments, the employer then may access the Web site provided by the system and enter the employer's current employees' demographic and health carrier information. The employer also may pay the first month's premium on-line through the Web site.
Preferably, the system prompts the on-line user for information. While the data is being entertained, in certain embodiments the system may compare the data to the business rules associated with each field. Once the input is completed properly, in certain embodiments the system may present an enrollment summary sheet summarizing enrollment information for the on-line user. For example, in certain embodiments implementing the a wage and tax form requirement for new group enrollments, the system may present the on-line user with the completed form and instructions to return the form to, for example, the insurance company for further processing. In certain embodiments, once the insurer approves enrollment, the system may automatically e-mail or otherwise forward an enrollment acceptance form to the user.
In certain embodiments, business rules remain identical whether for in-network or remote on-line transactions such as, for example, through the Internet.
Group maintenance may involve enrollment/eligibility activity occurring after the finalization of a group's enrollment. For example, if an employer or designated contact person is attempting to enroll a newly hired employee on-line, the employee is hired to work twenty hours per week, and the business rule set up for this particular group is that all employee's must work forty hours per week, in certain embodiments the system may dis-allow the finalization of the enrollment. In certain embodiments, the system may automatically issue a notice informing the group of the non-enrollment and, preferably, the reason(s) for the non-enrollment.
Another group maintenance activity can be employee or dependent disenrollments. In certain embodiments, the employer or designated person may access the appropriate group information on-line and enter the requested termination date. If the requested termination date complies with the business rule, in certain embodiments the system may immediately process the termination, preferably including the sending of a termination notice and COBRA information to the disenrolled employee, adjusting the applicable premium invoice, and notifying the appropriate insurance carrier. If the requested termination date is not within the pertinent business rules, in certain embodiments the system may calculate the termination date and display the date to the on-line user. If the user were to accept this date, in certain embodiments the system may complete the termination and, preferably, issue a notification to the user, such as by e-mail. If the user were to decline the system's proposed termination date, in certain embodiments the system may place the requested employee termination on hold and, preferably automatically, issue a notice of the situation to an appropriate representative.
In certain embodiments, the system may limit the capability to over-ride business rules to in-house personnel (e.g., the personnel of the entity that administers the system).
In certain embodiments, the system can provide a security application or process in order to control access to the system. In certain embodiments, the security framework includes a security information database as well as an administrator login capability. In certain embodiments, the system can allow the administrator to create users, modules, groups, applications, and assign user roles and access control lists (ACLs), etc. Preferably, the system significantly restricts access to the core administrative system.
In certain embodiments, the system generates an ACL for each user at the time the user logs into the system. Access to any resource in the core administrative system may be determined by the ACL, and the determination may be stored in, e.g., a user profile object, which may be stored into the session. A user can include a person working in any of the departments in a company, Internet users, or persons accessing an in-house system from an external location. In certain embodiments, individual user permissions take precedence over group permissions. In certain embodiments, even if the group permission is less restrictive than the user permission, the user permission overrides the group permission.
For example, the agent/broker of a large association group may want to allow the members of the association to enroll through the Internet but to also provide for agent/broker review of applications prior to actual enrollment. In certain embodiments, the system, through its security system, can allow such members to enroll through the Internet (with the application being processed through the enrollment/eligibility business rules), then route the completed application to the agent/broker (versus directly into the system after passing all the business rules), in order to allow the agent/broker to review the application. In certain embodiments, upon completion of such review and approval by the agent/broker, the system can automatically finalize the enrollment.
In certain embodiments, the benefits administration system may also provide the automatic generation of documents and other communications, customizable to the desires of the users. In this regard, the system may provide a flexible mail merge system for handling external business correspondence. In certain embodiments, the merge templates are basically RTF files with placeholders for dynamic data to be merged into them. In certain embodiments, the output is either a RTF file or a PostScript or a PDF document.
In certain embodiments, the system can also maintain a log of mail merge letters generated. The log information may include the template identification, a timestamp, the triggering application, and identification of the user generating the letter and to whom the letter is addressed (i.e., which group or member or agent). In certain embodiments, the templates are readily available, and the system may accommodate a virtually unlimited number of templates.
For example, when the agent/broker provides final approval for association member enrollment, in certain embodiments the system may issue enrollment approval and related correspondence. In certain embodiments, such correspondence or other documentation may be customized through the system to issue on the agent/broker's letterhead.
In certain embodiments, the system may provide for customizable work groups. Workgroups may define the broad categorization of a group of agents, internal working personnel, external working personnel, and mailing groups. In certain embodiments, the workgroup customization process includes creating a hierarchy of one or more parent entities and defining other workgroups under the parent(s).
In this event, a parent may be the highest in the hierarchy of a workgroup. Examples of parent work groups may include agent work groups or internal work groups. Examples of workgroups under the parent group may include groups of agents of differing authority levels within a given agent work group. In certain embodiments, further sub-groups or child groups may be established within the system. An example may include may include agents in a given geographical area or a customer group that has been enrolled in the system. In certain embodiments, the system includes the ability to exchange workgroup members or duplicate workgroup members in whole or in part.
In certain embodiments, the benefits administration system provides automatic but flexible account reconciliation. Cash reconciliation can provide a process of reconciling the cash receipts to individual invoices and reconciling the amount paid by the group. In certain embodiments, the system may provide a rule for reconciliation such as, for example:

- a. determine if negative cash is available and reconcile it with the positive cash (e.g., for NSF checks); and
- b. identify the oldest unreconciled invoice and reconcile it with the oldest cash.
- c. The reconciliation process may include automatic review of all invoices that have not been reconciled for a specific group and reconciling the invoice that has the earliest date with the cash received. It also may match the cash receipt with the invoice amount.
- d. In certain embodiments, the reconciliation process can be started automatically when a cash receipt batch is closed to reconcile cash received with invoices.
- e. Other functions that may be automatically performed
  cash reconciliation may include one or more of the following:
- f. Billed amounts and cash receipt: this reconciliation process may reconcile an invoice that has not yet been reconciled for a specific group, determine if the invoice is the earliest unreconciled invoice for the specific group, and reconcile the invoice with the cash received from the group/member;
- g. Cash to negative cash: this process may reconcile negative cash with the positive cash received from the group. This may arise from receipt of a NSF (Non-Sufficient Funds) check after the applicable group's invoice has been reconciled. Upon receipt of notification of the NSF check, the NSF cash receipt entry may be created in the system. Upon receipt of a replacement check for the NSF check, the NSF check may be automatically reconciled with the replacement check provided the amount of the replacement check is the same as the amount of the NSF check.

Adjustments to cash: this process may include reconciling a cash receipt with the adjustment that may be available in the next invoice. For example, if the group has received the invoice for the next month and an employee has been terminated during the month but after the generation of invoice, the generated invoice may not identify this adjustment for the termed employees. The applicable group may deduct the adjustments for the terminated employee and forward the cash that does not match the original invoice. In certain embodiments, the system can automatically identify the discrepancy and adjust the cash receipt for the invoice with the termination adjustment taken in to account. In certain embodiments, the next invoice may identify the cash receipt and the adjustment for employee termination.
Adjustment to billed amounts: this process can identify previously billed invoices for the group provide adjustment as needed to the next invoice.
Billed amount to itself if no payment is due: this process can identify if the group has been terminated after the invoice for the group has been created. In certain embodiments, the system automatically creates an invoice for the terminated group and adjusts the amount due based on the previous invoice. In certain embodiments, the system issues a final invoice for the terminated group showing net amount due, if any, or refunded.
Adjustment to adjustment: this process may reconcile invoice adjustments against each other. For example, if a payment late fee accrues but is later waived, in certain embodiments the system may automatically adjust (eliminate) the late fee. Another may involve reinstatement of an employer group termination and associated charging of a reinstatement fee. If such a fee were to then be waived, in certain embodiments the system may automatically reconcile the waived fee.
Certain embodiments of the benefits administration system provide a substantially improved ability to handle much larger data sets and to handle data more efficiently. In addition, certain embodiments utilize an independent platform and portable programming language such as Java. Preferably, the system components are built using object oriented programming concepts. Preferably, these object-oriented components can be reused in other applications with similar requirements or extended further with additional features when and wherever required. Preferably, the system is developed using scalable J2EE standards.
In certain embodiments, the system may allow a given user to work with the system in differing roles or capacities. For example, a manager may seek to perform the role of data entry as well as that of a manager or authorizing entity. In certain embodiments, the system allows modification or addition of user roles as desired. In certain embodiments, the CAS (Core Administration System) system is, however, preconfigured for a basic set of predefined roles.
In certain embodiments, the benefits administration may further provide one or more of the following aspects:

- a. selective issuance of notices to sub-groups meeting certain criteria;
- b. automated creation of a Cobra record from information in the system for a given beneficiary;
- c. automatic issuance of notice to a member prior to termination of the re-qualification period;
- d. automatic revision of employee status upon change of employee coverage;
- e. automatic issuance of notices when data is not entered correctly or completely, including issuance of other than on-screen notices to one or more system administrators or other entity;
- f. ability of a user to customize how the user may be provide notices or correspondence, such as by e-mail, mail, or facsimile; and
- g. enhanced carrier data maintenance within the system.

The system may be utilized by a benefits provider as part of it business and operation. Alternatively, the system may be utilized by a service provider, such as for or in connection with remuneration provided to the service provider by customers. For example, user fees may be provided by the users of the system, such as benefits providers or employers.
The system may also be utilized by an employer or group of employers, and their employees, to provide automated benefits administration for the employer or group of employers.
In certain embodiments, all features identified above may be provided by the system. The system may thereby provide an automated benefits administration and method of use of the system and doing business in conjunction with it.
There are many other novel aspects and aspects of embodiments of the present invention. They will become apparent as the specification proceeds. In this regard, it is to be understood that the scope of the invention is not be determined by whether given subject matter addresses all or particular issues in the prior art noted above or provides all or particular features identified in this brief summary.

Benefit Partners Inc

BPI—Software Architecture Document

Architectural Design Specification Document

Document Id: BPI CAS ADS

Version: <1.0>

1. Introduction

The Software Architecture Document will provide an overview of the entire “Software Architecture” that will be used to develop Web Interface Module for BPI.

1.1. Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions that have been made on the system.

1.2. Definitions, Acronyms and Abbreviations

Some of the common acronyms used in this document are as follows:


	Abbreviations	Description

	EJB	Enterprise Java Beans
	HTML	Hypertext Markup Language
	J2EE	Java
2 Enterprise Edition
	JMS	Java Messaging Services
	JNDI	Java Naming and Directory Interface
	JSP	Java Server Pages
	MVC	Model View Controller
	W3C	World Wide Web Consortium
	XML	Extensible Markup Language
	BPI	Benefit Partners Inc

1.3. Overview

This Software Architecture Document, at high level, will contain:

- a. Architectural representation of proposed system
- b. Architectural goals
- c. Software requirement
- d. Software selection for the proposed system
- e. Standards and methodologies that will be adopted for the proposed system

2. Architectural Goals

These guidelines will lay a foundation for the design and implementation strategy, selection of development tools, application software, and testing tools. The basic goals of the architectural design are discussed below.
2.1. Portability
Java is a platform independent and portable language. Applications developed in Java are proven to be portable across popular platforms.
2.2. Distribution
The J2EE Standards will be adopted to develop the new application. J2EE standards demonstrate consistency of distributed applications that access various data sources:
2.3. Reusability
The components will be built using Object Oriented concepts. These object-oriented components can be reused in other applications with similar requirements or extended further with additional features when and wherever required.
2.4. Scalability
Applications developed using the J2EE Standards are proven to be scalable. Therefore, the system will be built in conformance with the J2EE Standards.
2.5. Performance
Identifying the latencies within the system and outside the system boundaries enables us to increase the performance of the application. Since most of the threading issues that lower the performance of an application are well handled within the Websphere application server, Websphere server's features and resources will be effectively utilized to achieve performance.

3. Architectural Representation of the Proposed System

The System will be developed based on the J2EE specification and follow the N-tier MVC architecture.
A tier is a logical partition of the separation of concerns in the system. Each tier is assigned its unique responsibility in the system.
J2EE specifications are multi tiered consisting of the Client Tier, Middle Tier (Presentation Layer, Business Layer, and Integration Layer), and the Data source. The J2EE architecture diagram is described below. (See FIG. A-1)
3.1. Client Tier
This tier represents all devices or system clients accessing the system or the application. In this case, the client would be a web browser or other application.
3.2. Middle Tier
The middle tier can be classified into multiple logical layers depending upon the business requirements and programming model. Three basic classifications are discussed below.
3.2.1. Presentation Layer
This tier encapsulates all presentation logic required to service the clients that access the system. The presentation tier intercepts the client requests, provides single sign-on, session management and accesses business services, constructs the response, and delivers the response to the client. Servlets, JSP, HTML reside in this tier.
3.2.2. Business Layer
This tier provides the business services required by the application clients. The tier contains the business data and business logic. All business processing for the application is centralized into this tier. The enterprise bean components are the choice for implementing the business objects in the business tier.
3.2.3. Integration Layer
This tier is responsible for communicating with external resources and systems, such as data stores and legacy applications. The business tier is coupled with the integration tier whenever the business objects require data or services that reside in the resource tier. The components in this tier can use JDBC, J2EE connector technology, or some proprietary middleware to work with the resource tier.
3.3. Data Source
This is the tier that contains the database and external resources such as legacy systems, business-to-business (B2B) systems, and services, such as, credit card authorization and EFT.
3.4. Framework
The following figure depicts the interaction model of a typical Model View Controller or the JSP Model 2 Architecture that is adopted in the Framework. (See FIG. A-2)
Here, the servlet acts as the controller and is in charge of processing the request and creating any objects of the beans used by the JSP. It also redirects, to the respective JSP, based on the Browser's request. There will be very minimal logic present in the JSP regarding the presentation. All the database access and program business logic will be processed within the bean.
There will be different beans for data source access (database, enterprise systems, queue, XML, etc.), error handling, access logging, and module wise application business logic processing. This clearly separates the presentation from the content and enables easy maintenance and scalability.
This model is the widely used and accepted model for application development in Java. This model is also adopted by Apache Stnits framework for Java application development.

4. Software Selection for the Proposed System

This section provides an insight on the software selection for the various tiers depicted in this document.
4.1. Software Selection


Component	Software Name and Version

Ooerating System	Server/Client - Win NT/Win2000
Browser	IE 5.5 and above
Client Side Scriotmc	HTML 4.0, Java Script 1.2
Server Side	JSP 1.1, Java Servlets 2.2, JDK 1.3
Programming
Database Server	DB2 UBD Version V 7.3
Web Server	IBM HTTP Server V 1.3.19
Application Server	Websphere Application Server Advanced
	Edition Version 4.0
Report Server	Seagate Crystal Reports 8.5
Office Tools	Microsoft Office 2000 (select Word 2000,
	Excel 2000 and Outlook 2000 and Access
	2000), Post Script Printer, Adobe Acrobat 5.0
Servlet, Bean	Visual Age 4.0
Development
HTML, JSP, XML, etc.	Dream Weaver 4.0
Testing	JTest 4.5
Data Flow and Class	UML Studio
Design

4.2. API Versions


API Name	Version	Remarks

J2EE	Specification 1.2	Supported by Websphere 4.0
EJB	Specification 1.2	Supported by Websphere 4.0
JDK	JDK 1.2.2	Supported by Websphere 4.0
Servlet	Servlet 2.2	Supported by Websphere 4.0
JSP	JSP 1.1	Supported by Websphere 4.0
HTTP	HTTP/1.1	Stable W3C Specification

5. Standards and Methodologies

The standards and methodologies that will be followed for the application development are discussed below.
5.1. Design Document
Detailed design document will be prepared based on the scope of the application prior to the development. This document will contain the details on graphic user interface, navigation, class diagrams, data dictionary, field validation criteria, and program logic.
5.2. Bean Classification
The types of Java beans that will be used to perform different business logics will be decided during the design stage. The bean types will be classified based on the complexity of the business logic and the scalability.
5.3. Coding
A separate document will be prepared outlining the coding standards that will be adopted in the application development. The document will contain details on program naming conventions to be used while coding. All programs developed will follow this standard.
5.4. Testing
Test plan and test case documents will be prepared for unit and integration testing of the application. The test cases will be used to test the application modules and integration. JTest will be used for testing code construction (white-box testing), code functionality (black-box testing), and code integrity (regression testing).
5.5. Error Handling
All error messages and error codes for the application will be stored in the database. Run time errors will be logged to text files that will be generated periodically by the system. Input validations will occur in both the client tier and the middle tier. The input validation error messages captured in the client tier will be displayed using JavaScript alerts. The input validation error messages captured in the middle tier will be displayed in HTML format, on the same page on which the error has occurred, in a different color.
5.6. Page Design
A Page Design Guidelines document will be created by Mascon, and approved by BPI, prior to the development. All pages in the application will conform to the standards depicted in this document. This document will contain the specifications for fonts, layouts, images, and other relevant details.
5.7. Parameterization
Custom JSP tag libraries will be created for all initial values and parameters used in the application. JSP tag libraries define declarative, modular functionality that can be reused by any JSP page. Tag libraries reduce the necessity to embed large amounts of Java code in JSP pages by moving the functionality provided by the tags into tag implementation classes. In doing so, tag libraries make authoring JSP pages easier and modular.

6. System Architecture and Hardware Selection

This section provides the details of the system architecture with nodes, terminals and their placement within the respective zones.
6.1. Physical Architecture (See FIG. A-3)
6.2. Hardware Selection


			Current
#	Server	Base	Configuration	Software/Hardware

	Database Server	Intel Pentium	Intel XEO		1. Windows 2000
		Processor, 2	Processor	Advanced Server
		CPU,	1 CPU	2. IE 5.5 and above
		HD 104 GB, 2 GB	HDD 34 GB	3. IBM DB2 UDB
		RAM, Raid 5	2 GB RAM	version 7.2.x
			CPU 2.4 Ghz.
2	Application	Intel Pentium	Intel XEO		1. Windows 2000
	Server -	Processor, CPU	Processor	Advanced Server
	Intranet
	1, HD 18 GB, 2 GB	1 CPU	2. IE 5.5 and above
		RAM	HDD 200 GB	3. Websphere
			2 GB RAM	Application Server
			CPU 2.4 Ghz.	Advanced Edition
				Version 4.0
				4. IBM DB2 UDB
				version 7.2.x (For
				WAS Repository)
				5. IBM HTTP Server
				1.3.19
				6. Microsoft Office
				2000 (select Word
				2000, Excel 2000
				and Outlook 2000
				and Access 2000),
				Post Script Printer,
				Adobe Acrobat 5.0
3	Application	Intel Pentium	Not Available	1. Windows 2000
	Server -	Processor, CPU		Advanced Server
	Internet
	1, HD 18 GB, 2 GB		2. IE 5.5 and
		RAM		Netscape 4.7 and
				above
				3. Websphere
				Application Server
				Advanced Edition
				Version 4.0
				4. IBM DB2 UDB
				version 7.2.x (For
				WAS Repository)
				5. Microsoft Office
				2000 (select Word
				2000, Excel 2000
				and Outlook 2000
				and Access 2000),
				Post Script Printer,
				Adobe Acrobat 5.0
4	Report Server -	Intel Pentium	Intel Processor		1. Windows 2000
	Crystal Reports	Processor, CPU	1 CPU	Advanced Server
		1, HD 18 GB, 2 GB	HDD 17 GB	2. IE 5.5 and above
		RAM	2.3 GB RAM	3. Seagate Crystal
			CPU 1266 Mhz.	Reports 8.5
				4. Microsoft Office
				2000 (select Word
				2000, Excel 2000
				and Outlook 2000
				and Access 2000),
				Post Script Printer,
				Adobe Acrobat 5.0
				5. lIS for Crystal
				reports
5	Web Server -	Intel Pentium	Not Available	1. Windows 2000
	Internet	Processor, CPU		Advanced Server
		1, HD 18 GB, 2 GB		2. IE 5.5 and above
		RAM		3. IBM HTTP Server
				1.3.19
				4. Microsoft Office
				2000 (select Word
				2000, Excel 2000
				and Outlook 2000
				and Access 2000),
				Post Script Printer,
				Adobe Acrobat 5.0

7. Browser Client Application Limitations and Work Around Solutions

The limitations of the Web Browser (thin client) based application, when compared to thick clients, are as follows:

- a. Input field masking, such as automatic date formatting and phone number formatting, are not easily handled in this environment. The thin client user interface is not as easy and robust as the thick client user interface. A work around must be designed to force the user to enter values in the required format.
- b. Due to the limitations of different browsers, a common methodology will be adopted that will work for all indicated browsers. This narrows down the user interface implementation features in a browser.
- c. Because of the lower level on interactivity, some actions that are presented entirely on one screen in the thick client may span multiple screens. Since each screen presentation involves a round trip to the server, this will result in slightly slower screen response when compared to the single screen approach. This can be minimized with some re-design of the user interface workflow, but overall, thin clients require more “clicks” than thick clients.
- d. Hot-keys validation scripts are cumbersome and take longer to download. Thus, hot-key functionality will be limited.

Benefit Partners Inc

Process Specification

BPI_CAS_FSD_CM

_—01

1. Introduction

1.1. Purpose
This purpose of this document is to identify the process associated with the business use case Create Carrier Master.
1.2. Business Use Case Specification Reference

- Business Use Specification


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_CM_001	Create Carrier Master

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background
Create Carrier Master is user for creation of master record for the carrier which includes the general information about the carrier, Department Contact Information, Mode of Communications Line of Coverage, plan type and the benefit level offered by the carrier and the benefit description.
2.2. Process Description & Flow
This process describes the Use Case “Create Carrier Master”. This document is the amendment of BPI_CAS_FSD_CM_—01 (Version 1.1).
2.2.1. Create Carrier Master

- The flow of the process is as described below.
- a. Input the general information about the carrier.
- b. Input the Department Contact Information
- c. Validate if the department contact information has the right data type.
- d. If yes add the information to a temporary storage.
- e. If not re enter the information correctly and add again.
- f. Continue adding further department contact information.
- g. If yes follow steps from b) to e)
- h. Edit or delete the Department Contact Information.
- i. On edit remove the data from temporary storage and populate the department contact information data to the fields and change the data. Continue from c) to e).
- j. On delete remove the data from the temporary storage.
- k. Can continue from step b) onwards or go to step l)
- l. If not then check if the data entered for the general carrier information is correct or erroneous.
- m. If erroneous re enter the correct data.
- n. If Correct then save the data to the repository.
- o. System auto generates a unique identification number for the carrier.
- p. Choose the Line of coverage
- q. For the line of coverage choose the system show the Plan type.
- r. Choose the Plan Type
- s. For the plan type choose the system show the benefit level
- t. Choose the benefit level and enter the benefit level name for the specific carrier and add.
- u. The Line of coverage, plan type, Benefit Level and the name is populated in and shown.
- v. Check if the data entered is correct or erroneous.
- w. If erroneous then edit or delete the benefit level name.
- x. Else continue adding the next line of coverage
- y. If the process is completed save the data.
- z. The data is saved into the repository and unique identification number is generated for the all the benefit level offered by the specific carrier a CarrierName_PlanType_BenefitLevel_UniqueID

2.2.2. Process Flow Diagrams

- (See FIG. H-1)

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


		Corresponding HTML File
Screen ID (SID)	Screen Name	Name

carrier.general	Carrier General Info	/bpi/cas/carrier/master/
		CarrierInfo.jsp
carrier.search	Carrier Search	/bpi/cas/carrier/master/
		CarrierSearch.jsp
carrier.view	Carrier General Info	/bpi/cas/carrier/master/
	View	CarrierGeneralInfo.jsp
carrier.product	Carrier Product Info	/bpi/cas/carrier/master/
		CarrierProduct.jsp
carrier.prodsearch	Search Product	/bpi/cas/carrier/master/
		ProductSearch.jsp
carrier.prodinfo	Carrier Product Info	/bpi/cas/carrier/master/
		ProductView.jsp

3.1.2. User Interface ID: Create Carrier Master
3.1.2.1. Screen Name: Create Carrier Master

- (BPI_CAS_SCR_CM_—001_—001)
- (See FIG. H-2)

3.1.2.2. Element Name, Element Type, Label & Purpose


	Element
Element Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the screen being
Create		Create Carrier	navigated
Carrier		Master
Master
Sub Header	Text	Sub Header	Proved Content Area Text
Carrier		Carrier
General		General
Information		Information
Sub Header	Text	Sub Header	Text for the Company Address
Address		Address
Company	Text	Company	Text for the entry field
Name		Name
Company	Entry Field	Company	Entry Field for Company name
Name (Entry		Name (Entry
Field)		Field)
Address	Text	Address	Text for the Address
Address (Entry	Entry Field	Address (Entry	Entry Field for Address
Field)		Field)
Suite/Apt #	Text	Suite/Apt #	Text for Suite/Apt #
Suite/Apt #	Entry Field	Suite/Apt #	Entry Field for Suite/Apt #
(Entry Field)		(Entry Field)
City	Text	City	Text for City
City (Entry	Entry Field	City (Entry	Entry Field for City
Field)		Field)
State	Text	State	Text for state
State (Entry	Entry Field	State (Entry	Entry Field for State
Field)		Field)
ZIP	Text	ZIP	Text for ZIP
ZIP (Entry	Entry Field	ZIP (Entry	Entry Field for ZIP
Field)		Field)
Sub Header	Text	Sub Header	Text for the sub heading
Contact		Contact
Department		Department
Department	Drop Down	Department	List all the departments for the carrier for
	List		contact information
Contact Name	Text	Contact Name	Text for Contact name
Salutation	Text	Salutation	Text for Salutation
First Name	Text	First Name	Text for First name
Middle name	Text	Middle name	Text for middle name
Last name	Text	Last name	Text for last name
Suffix	Text	Suffix	Text for Suffix
Title	Text	Title	Text for title
Salutation	Entry Field	Salutation	Entry Field for Salutation
First Name	Entry Field	First Name	Entry field for first name
Middle name	Entry Field	Middle name	Entry field for middle name
Last name	Entry Field	Last name	Entry field for last name
Suffix	Entry Field	Suffix	Entry Field for Suffix
Title	Entry Field	Title	Entry Field for title
Address	Text	Address	Text for the Address
Address (Entry	Entry Field	Address (Entry	Entry Field for Address
Field)		Field)
Suite/Apt #	Text	Suite/Apt #	Entry Field for Suite/Apt #
Suite/Apt #	Entry Field	Suite/Apt #	Entry Field for Suite/Apt #
(Entry Field)		(Entry Field)
City	Text	City	Text for City
City (Entry	Entry Field	City (Entry	Entry Field for City
Field)		Field)
State	Text	State	Text for state
State (Entry	Entry Field	State (Entry	Entry Field for State
Field)		Field)
ZIP	Text	ZIP	Text for ZIP
ZIP (Entry	Entry Field	ZIP (Entry	Entry Field for ZIP
Field)		Field)
Mode of	Drop Down	Mode of	List various of contact preferred
Communication	List	Communication
Phone	Text	Phone	Text for phone
FAX	Text	FAX	Text for FAX
Email	Text	Email	Text for email
Phone	Entry Field	Phone	Entry Field for Phone number
FAX	Entry Field	FAX	Entry field for FAX
Email	Entry Field	Email	Entry field for email
ADD	Button	ADD	To add the above details on to the html table
	(HTML		after validation check
	Submit
	button)
Table	HTML	Table	Table for adding up the contact information
	Table
Delete	Button	Delete	To delete the contact information checked for
	(HTML		deletion
	Button)
Check All	Text Link	Check All	To check all the check boxes in the table
Clear All	Text Link	Clear All	To un check all the check boxes checked in
			the table
Delete	Check box	Delete	To check the items for deletion
Edit	Button	Edit	To edit the contact information against the
	(HTML		row selected for edition
	Button)
Department	Text	Department	Shows the name of the department added.
Name		Name	For example finance, marketing etc.
Last Name	Text	Last Name	Name of the contact person
Phone	Text	Phone	Phone of the contact person
FAX	Text	FAX	FAX of the contact person
Email	Text	Email	Email address of the contact person
SAVE	Button	SAVE	Save all the above information to the
	HTML		repository)
	Submit
	button)
CANCEL	Button	CANCEL	To reset the entries made in all the fields
	(HTML
	reset
	button)

3.1.2.3. Front End Validations

- Validation Details
  - This section provides the front-end screen validations along with the associated message—Success/Error Message text


#	Element Name	Action/Validation Details	Message

1.	Company Name	Refer Document No.	Refer Document No.
	(Entry Field	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
2.	Address (Entry	Refer Document No.	Refer Document No.
	Field)	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
3.	Suite/Apt #	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
4.	Suite/Apt # (Entry	Refer Document No.	Refer Document No.
	Field)	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
5.	City	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
6.	City (Entry Field)	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
7.	State	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
8.	State (Entry Field)	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
9.	ZIP (Entry Field)	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
10.	Department	Should list various departments like	If none of the option is
		Finance, Sales, Administration,	selected. Then should
		Technical, Miscellaneous etc from the	show an Error Dialog Box
		repository.	With message.
		The First option should be	“Department Name - Is
		Choose One. Subsequent options	required”
		should be listed alphabetically.
11.	Salutation	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
12.	First Name	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
13.	Middle name	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
14.	Last name	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
15.	Suffix	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
16.	Title	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
17.	Address (Entry	Refer Document No.	Refer Document No.
	Field)	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
18.	Suite/Apt # (Entry	Refer Document No.	Refer Document No.
	Field)	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
19.	City (Entry Field)	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
20.	State (Entry Field)	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
21.	ZIP (Entry Field)	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
22.	Mode of	Should list various types of Mode of	If none of the option is
	Communication	Communications like Phone, FAX,	selected. Then should
		email, USPS etc. from the repository.	show an Error Dialog Box
		The First option should be	With message.
		Choose One. Subsequent options
		should be listed alphabetically.
23.	Phone	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
24.	Email	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
25.	FAX	Refer Document No.	Refer Document No.
		BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
26.	ADD	Should function with Enter Key	Error Dialog Box Text:
		Cursor Positioned on the “ADD”	“Department Name - Is
		button or Mouse Click.	required”
		Check if the Contact Department is
		selected. If choose one default
		option is only selected throw a Java
		script error message.
		Check if the Mode of Communication
		is selected. If choose one default
		option is only selected throw a Java
		script error message.
		Check if the value entered for the
		fields for the Department contact
		information are correct. If not throw
		error message.
		Success: Populates the HTML Table
		with the data on each column as
		relevant with the data entered in the
		entry field.
27.	Table	Should have column header and each
		subsequent row should be identified
		by alternate color combinations, i.e.
		First row should have color ‘x’ and the
		next row should have color ‘y’. The
		next row should have color ‘x’ again
		and so on. The size of any text inside
		any cell should be wrapped if the text
		becomes too long.
28.	Delete	Should function with Enter Key	Error Message: “Please
		Cursor Positioned on the “Delete”	choose the row or rows to be
		button or on Mouse Click.	deleted.”
		Delete Button should work on
		multiple deletes based on the check
		box or boxes selected. If the user
		clicks on the delete button without
		checking any of the delete check box
		should throw error message.
		Success: Deletes the row or rows
		from the HTML Table (temporary
		storage)
29.	Check All	On clicking the “Check All” link	On clicking the “Check All”
		should check all the check boxes in	link should check all the
		the HTML table.	check boxes in the HTML
			table.
30.	Clear All	On clicking the “Clear All” link	On clicking the “Clear All”
		should uncheck all the checked check	link should uncheck all the
		boxes in the HTML table.	checked check boxes in the
			HTML table.
31.	Delete	Check box option with default	Check box option with
		“unchecked”	default “unchecked”
32.	Edit	Should function with Enter Key	Should function with Enter
		Cursor Positioned on the “edit” button	Key Cursor Positioned on
		or on Mouse Click.	the “Edit” button or on
		On clicking the edit button the row	Mouse Click.
		edited should be removed from the	On clicking the edit button
		HTML table and the data should be	the row edited should be
		populated back on the editable entry	removed from the HTML
		fields.	table and the data should be
			populated back on the
			editable entry fields.
33.	Department Name	Display the data in a text
34.	Name	Display the data in a text
35.	Phone	Display the data in a text
36.	Email	Display the data in a text
37.	FAX	Display the data in a text
38.	SAVE	Should function with Enter Key	Error Dialog Box Text:
		Cursor Positioned on the “SAVE”	“The value entered for ‘FIELD
		button or on Mouse Click.	NAME’ is incorrect. Please
		On saving the data the data gets saved	enter the correct value.”
		to the database.	Note: The field name should
		Validation Check: For the entire	be picked up dynamically
		field on the carrier general	for the each field that is
		information.	erroneous.
		Check if the data entered for the	For general script
		Carrier General Information is	validations for common
		correct.	functionality refer
		If not throw error message.	BPI_CAS_FSD_COMMON
		Check if there is data populated on the	System Error: Common
		Department Contact information	Text shall be followed for
		field. If yes show a dialog box with	the System Error.
		message “Would you like to Add the	Dialog Box Text:
		department contact information
		before saving” Yes/No.
		If yes allow the user to add the data.
		If no save the data without adding the
		Department contact information to
		the HTML Table.
		On Successful saving the flow should
		automatically be navigated to the next
		screen.
		(BPI_CAS_SCR_CM_001_002)
39.	Cancel	Cancel Button should clear all the
		content filled on the entry fields.

3.1.3. User Interface ID: Create Product
3.1.3.1. Screen Name: Create Product

- (BPI_CAS_SCR_CM_—001_—002)
- (See FIG. H-3)

3.1.3.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the screen being
Carrier		Carrier	navigated
Offered Plan		Offered Plan
Trans Id	Text	Trans Id	Text for Trans Id
Trans Id	Entry Field	Trans Id	To Enter the Trans Id
Plan Name	Text	Plan Name	Text for Plan Name
Plan Name	Entry Field	Plan Name	To Enter Plan Name
Carrier Name	Text	Carrier Name	Text for Carrier Name
Carrier Name	Drop Down	Carrier Name	Lists various Carrier Names
	List
Line of	Text	Line of	Text for Line of Coverage
Coverage		Coverage
Line of	Drop Down	Line of	Lists various line of coverage offered.
Coverage	List	Coverage	Example Medical, Dental, Vision, CAM etc.
Plan Type	Text	Plan Type	Text for plan type
Plan Type	Drop Down	Plan Type	List the Plan Type available for the line of
	List		coverage selected. Example HMO, PPO, PSO
			etc.
Add	Button	Add	To add the Benefit Level Name to the HTML
	(HTML		table.
	Button)
Table	HTML	Table	For adding and displaying all the names of the
	table		benefit level offered by the carrier
Delete	Button	Delete	To delete single or multiple rows of the
	(HTML		benefit level checked
	Button)
Check All	Text Link	Check All	To check all the check boxes in the table
Clear All	Text Link	Clear All	To un check all the check boxes checked in
			the table
Enrolment	Button	Enrolment	To Navigate to Enrolment Transmission
			Screen
Premium	Button	Premium	To Navigate to Premium Transmission
			Screen
Delete	Check box	Delete	To check the items for deletion
Edit	Button	Edit	To edit the benefit level against the row
	(HTML		selected for edition
	Button)
SAVE	Button	SAVE	Save all the above information to the
	(HTML		repository
	Submit
	button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	reset
	button)

3.1.3.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1.	Trans Id	This name should be brought from the	Plan Id is required
		previous screen	PlanId accepts
		BPI_CAS_SCR_CM_001_001.	alphanumeric values only
2.	Line of Coverage	Should list various types of Line of	Note: The Screen
		Coverage from the database.	should not be refreshed
		Default Line of Coverage should be	when choosing different
		Choose One	Line of Coverage.
		Subsequent line of coverage should	Line of Coverage is
		be listed alphabetically.	required
		On choosing the line of coverage
		corresponding Plan Type should be
		listed.
		On choosing different Line of
		Coverage the Plan Type List should
		be refreshed and new set of plan type
		should be listed for the new line of
		coverage selected.
3.	Plan Type	Should list various types of Plan Type	Note: The Screen
		from the database.	should not be refreshed
		Plan Type should be Listed	when choosing different
		alphabetically	Plan Type.
		On choosing the Plan Type	Plan Type is required
		Corresponding Benefit Level Should
		be listed.
		On choosing different Plan Type the
		Benefit Level List should be refreshed
		and new set of Benefit Level should
		be listed of the new Plan Type
		selected.
4.	Carrier Name	Should be entered	Carrier Name is required
5.	Plan Name	Should be entered	Plan Name is required
6.	Add	Should function with Enter Key	Error Dialog Box Text:
		Cursor Positioned on the “ADD”	“The name entered for
		button or Mouse Click.	alternate Benefit Level
		Check if alternate Benefit Level name	Name is incorrect. Please
		is valid.	enter the correct name.”
		If not throw error message.	“The is no name entered
		Check if there is no duplicate entry	for Benefit Level Name.
		for the Combination of Line of	Please enter the name.”
		Coverage, Plan Type and Benefit	Error Dialog Box Text:
		level selected.	“The Benefit Level Name
		If Duplicate Show Error Message	for the combination of
		Check if there is blank field if so	Line of Coverage, Plan
		throw error message	type and Benefit Level is
		Success: The items selected with the	already entered. Please
		benefit level name are added to the	select other
		HTML table below (temporary)	combination.”
7.	Table	Should have column header and each
		subsequent row should be identified
		by alternate color combinations. i.e.
		First row should have color ‘x’ and the
		next row should have color ‘y’. The
		next row should have color ‘x’ again
		and so on. The size of any text inside
		any cell should be wrapped if the text
		becomes too long.
8.	Delete	Should function with Enter Key	Error Message: “Please
		Cursor Positioned on the “Delete”	choose the row or rows to
		button or on Mouse Click.	be deleted.”
		Delete Button should work on
		multiple deletes based on the check
		box or boxes selected. If the user
		clicks on the delete button without
		checking any of the delete check box
		should throw error message.
		Success: Deletes the row or rows
		from the HTML table (temporary
		storage)
9.	Check All	On clicking the “Check All” Link all	On clicking the “Check
		the rows with the check box option	All” Link all the rows
		are checked.	with the check box option
			are checked.
10.	Clear All	On clicking the “Clear All” Link all	On clicking the “Clear
		the rows with the check box option	All” Link all the rows
		checked are unchecked.	with the check box option
			checked are unchecked.
11.	Delete	Check box option with default
		“unchecked”
12.	Edit	Should function with Enter Key	Note: All edits that are
		Cursor Positioned on the “Edit”	done on the data from the
		button or on Mouse Click.	repository or database,
		On clicking the edit button the row	history of the changes
		edited should be removed from the	made must be available.
		table and the data should be populated
		back on the editable entry field.
13.	SAVE	Should function with Enter Key	Common Text shall be
		Cursor Positioned on the “SAVE”	followed for the System
		button or on Mouse Click.	Error.
		Validation Check:	Dialog box:
		Check if there is any data entered in	“Would you like to Add
		the alternate Benefit Level Name	the Alternate Benefit
		field.	Level name before
		If yes show a dialog box with	saving” Yes/No.
		message “Would you like to Add the
		Alternate Benefit Level name before
		saving” Yes/No
		If yes allow the user to add the data.
		If no save the data without adding the
		Alternate Benefit Level Name to the
		HTML Table.
		On saving the data the data gets saved
		to the database.
		Success:
		On Successful saving the flow should
		be automatically be navigated back to
		the previous screen.
		(BPI_CAS_SCR_CM_001_001)
14.	Cancel	Cancel Button should clear all the
		content filled on the entry fields

3.1.4. User Interface ID: Search Carrier Master
3.1.4.1. Screen Name: Search Carrier Master

- (BPI_CAS_SCR_CM_—001_—003)
- (See FIG. H-4)

3.1.4.2. Element Name, Element Type, Label & Purpose
3.1.4.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1.	Carrier name	Default option on the list is
		Choose One
		Lists all the active carrier in
		alphabetical order
2.	View	Should function with Enter Key	Error Dialog Box Text:
		Cursor Positioned on the “View”	“Please choose a carrier
		button or on Mouse Click.	to view information”
		On clicking the View Button if no
		Carrier name is selected then throw an
		error message.
		Else Success should navigate to the
		view page
		BPI_CAS_SCR_CM_001_006 with
		the data pertaining to the carrier
		selected.
3.	Edit	Should function with Enter Key	Error Dialog Box Text:
		Cursor Positioned on the “Edit”	“Please choose a carrier
		button or on Mouse Click.	to Edit information”
		On clicking the Edit Button if no
		Carrier name is choose then throw an
		error message.
		Else Success should navigate to the
		Edit pages
		BPI_CAS_SCR_CM_001_004 with
		the data pertaining to the carrier
		selected.

3.1.5. User Interface ID: Modify Carrier Master
3.1.5.1. Screen Name: Modify Carrier Master

- (BPI_CAS_SCR_CM_—001_—004)
- (See FIG. H-5)

3.1.5.2. Element Name, Element Type, Label & Purpose


	Element
Element Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the screen being
Edit Carrier		Edit Carrier	navigated
Master		Master
Sub Header	Text	Sub Header	Provide Content Area Text
Carrier General		Carrier General
Information		Information
Sub Header	Text	Sub Header	Text for the Company Address
Address		Address
Company	Text	Company	Text for the entry field
Name		Name
Company	Entry Field	Company	Entry Field for Company name with data
Name (Entry		Name (Entry	filled and editable
Field)		Field)
Address	Text	Address	Text for the Address
Address (Entry	Entry Field	Address (Entry	Entry Field for Address with data filled and
Field)		Field)	editable
Suite/Apt #	Text	Suite/Apt #	Text for Suite #
Suite/Apt #	Entry Field	Suite/Apt #	Entry Field for Suite/Apt # with data filled
(Entry Field)		(Entry Field)	and editable
City	Text	City	Text for City
City (Entry	Entry Field	City (Entry	Entry Field for City with data filled and
Field)		Field)	editable
State	Text	State	Text for state
State (Entry	Entry Field	State (Entry	Entry Field for State with data filled and
Field)		Field)	editable
ZIP	Text	ZIP	Text for ZIP
ZIP (Entry	Entry Field	ZIP (Entry	Entry Field for ZIP with data filled and
Field)		Field)	editable
Sub Header	Text	Sub Header	Text for the sub heading
Contact		Contact
Department		Department
Department	Drop Down	Department	List all the departments for the carrier for
	List		contact information
Contact Name	Text	Contact Name	Text for Contact name
Salutation	Text	Salutation	Text for salutation
First Name	Text	First Name	Text for First name
Middle name	Text	Middle name	Text for middle name
Last name	Text	Last name	Text for last name
Suffix	Text	Suffix	Text for suffix
Title	Text	Title	Text for title
Salutation	Entry Field	Salutation	Entry Field for salutation
First Name	Entry Field	First Name	Entry field for first name
Middle name	Entry Field	Middle name	Entry field for middle name
Last name	Entry field	Last name	Entry field for last name
Suffix	Entry Field	Suffix	Entry Field for suffix
Title	Entry Field	Title	Entry Field for title
Address	Text	Address	Text for the Address
Address (Entry	Entry Field	Address (Entry	Entry Field for Address
Field)		Field)
Suite/Apt #	Text	Suite/Apt #	Text for Suite #
Suite/Apt #	Entry Field	Suite/Apt #	Entry Field for Suite/Apt #
(Entry Field)		(Entry Field)
City	Text	City	Text for City
City (Entry	Entry Field	City (Entry	Entry Field for City
Field)		Field)
State	Text	State	Text for state
State (Entry	Entry Field	State (Entry	Entry Field for State
Field)		Field)
ZIP	Text	ZIP	Text for ZIP
ZIP (Entry	Entry Field	ZIP	Entry Field for ZIP
Field)
Mode of	Drop Down	Mode of	List various modes of contact preferred
Communication	List	Communication
Phone	Text	Phone	Text for phone
FAX	Text	FAX	Text for FAX
Email	Text	Email	Text for email
Phone	Entry Field	Phone	Entry Field for Phone number
Email	Entry Field	Email	Entry field for email address
FAX	Entry Field	FAX	Entry field for FAX
ADD	Button	ADD	To add the above details on the HTML table
	(HTML		below
	Submit
	button)
Table	HTML	Table	Table for adding up the contact information.
	Table		The table also contains all the contact
			information already available in a multiple
			rows.
Delete	Button	Delete	To delete the contact information
	(HTML
	Button)
Check All	Text Link	Check All	To check all the check boxes in the table
Clear All	Text Link	Clear All	To un check all the check boxes checked in
			the table
Delete	Check box	Delete	To check the items for deletion
Edit	Button	Edit	To edit the contact information against the
	(HTML		row selected for edition
	Button)
Department	Text	Department	Shows the name of the department added. For
Name		Name	example finance, marketing etc.
Last Name	Text	Last Name	Last Name of the contact person
Phone	Text	Phone	Phone of the contact person
Email	Text	Email	Email address of the contact person
FAX	Text	FAX	Fax of the contact person
SAVE	Button	SAVE	Save all the above information to the
	(HTML		repository
	Submit
	button)
CANCEL	Button	CANCEL	Cancels the current operations and sets to the
	(HTML		value as before saving
	Reset
	button)
EDIT	Button	EDIT	Navigates to the next screen without saving
CARRIER	(HTML	CARRIER	the data. The purpose is if the editing needs to
OFFERED	Submit	OFFERED	be done for the next screen
PLAN	button)	PLAN	(BPI_SCREEN_005)
New	Button	New	To create a new page as first time.
	(HTML
	button)

3.1.6. User Interface ID: Modify Carrier Product
3.1.6.1. Screen Name: Modify Carrier Product

- (BPI_CAS_SCR_CM_—001_—005)
- (See FIG. H-6)

3.1.6.2. Element Name, Element Type, Label & Purpose
3.1.6.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1.	Carrier name	This name should be brought from the
		previous screen
		BPI_CAS_SCR_CM_001_004.
2.	Line of Coverage	Should list various types of Line of	Note: The Screen should
		Coverage from the database.	not be refreshed when
		Default Line of Coverage should be	choosing different line of
		Choose One	coverage.
		Subsequent line of coverage should be
		listed alphabetically.
		On choosing the line of coverage
		corresponding Plan Type should be
		listed.
		On choosing different Line of Coverage
		Plan Type List should be refreshed and
		new set of plan type should be listed for
		the new line of coverage selected.
3.	Plan Type	Should list various types of Plan Type	Note: The Screen should
		from the database.	not be refreshed when
		Plan Type should be Listed	choosing different Plan
		alphabetically	Type.
		On choosing the Plan Type
		Corresponding Benefit Level Should be
		listed.
		On choosing different Plan Type the
		Benefit Level List should be refreshed
		and new set of Benefit Level should be
		listed of the new Plan Type selected.
4.	Benefit Level	Should list various types of Benefit Level
		from the database.
		Benefit Level should be listed
		alphabetically.
5.	Benefit Level Name	The field is used for filling Benefit Level
		Name

6.	Alternate name	The field is used for entering Alternate	Error Dialog Box Text:
		Benefit Level Name	“The value entered for
			Alternate Benefit Level
			Name is incorrect. Please
			enter the correct value.”
7.	Add	Should function with Enter Key Cursor	Error Dialog Box Text:
		Positioned on the “ADD” button or	“The value entered for
		Mouse Click.	Benefit Level Name is
		Check if Alternate Benefit Level name is	incorrect. Please enter the
		valid.	correct value.”
		If not throw error message.	Embedded Error
		Check if there is no duplicate entry for	Message:
		the Combination of Line of Coverage,	Show this message on space
		Plan Type and Benefit Level selected. If	above the HTML table with
		Duplicate Show Error Message	RED color.
		Success: The items selected with the	“The Benefit Level Name
		benefit level name are added to the	for the combination of Line
		HTML table below (temporary)	of Coverage, Plan type and
			Benefit Level is already
			available. Please select
			other benefit level.”
8.	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. i.e. First
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of any text inside any cell should be
		wrapped if the text becomes too long.
9.	Delete	Check box option with default
		“unchecked”
10.	Delete	Should function with Enter Key Cursor	Error Message: “Please
		Positioned on the “Delete” button or on	choose the row or rows to
		Mouse Click.	be deleted.”
		Delete Button should work on multiple
		deletes based on the check box or boxes
		selected. If the user clicks on the delete
		button without checking any of the delete
		check box should throw error message.
		Note: the delete action should only delete
		the single or multiple rows selected from
		the view inside the table.
		However the data must not be deleted
		from the database on saving. It should
		only inactivate the benefit level
		name/names selected for deletion.
11.	Edit	Should function with Enter Key Cursor	Repository Data should be
		Positioned on the “Edit” button or on	green in color and the
		Mouse Click.	Temporary data should be
		On clicking the edit button the row edited	red in color.
		should be removed from the table and the
		data should be populated back on the
		editable entry field.
12.	SAVE	Should function with Enter Key Cursor	System Error: Common
		Positioned on the “SAVE” button or on	Text shall be followed for
		Mouse Click.	the System Error.
		Validation Check:	Dialog box:
		Check if there is any data entered in the	“Would you like to Add the
		Alternate Name field.	Alternate Benefit Level
		If yes show a dialog box with message	name before saving”
		“Would you like to Add Alternate	Yes/No.
		Benefit Level name before saving”	Note: For all the changes
		Yes/No.	made history of changes
		If yes allow the user to add the data.	should be available for
		If no save the data without adding the	viewing via reports for the
		Benefit Level Name to the HTML Table.	specific modules.
		On saving the data the data gets saved to
		the database.
		Success:
		On Successful saving the flow should be
		automatically be navigated back to the
		Search Screen.
		(BPI_CAS_SCR_CM_001_003)
		Note: Data must not be deleted from the
		database on saving. It should only
		inactivate the benefit level name/names
		selected for deletion.
13.	Cancel	To cancel the previous operation.

3.1.7. User Interface ID: View Carrier Master
3.1.7.1. Screen Name: View Carrier Master

- (BPI_CAS_SCR_CM_—001_—006)
- (See FIG. H-7)

3.1.7.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the screen being
View Carrier		View Carrier	navigated
Master		Master
Sub Header	Text	Sub Header	Name for the sub header
carrier general		carrier general
Information		Information
Carrier name	Dynamic	Carrier name	Name of the carrier being viewed
	Text
Sub Header	Text	Sub Header	Name of the sub header
Address		Address
Company	Text	Company	Text for the entry field
Name		Name
Company	Text	Company	Text for Company name with data filled
Name		Name
Address	Text	Address	Text for the Address
Address	Entry Field	Address	Text for Address with data filled
Suite/Apt #	Text	Suite/Apt #	Text for Suite #
Suite/Apt #	Text	Suite/Apt #	Test for Suite/Apt # with data filled
City	Text	City	Text for City
City	Text	City	Text for City with data filled
State	Text	State	Text for state
State	Text	State	Text for State with data filled
ZIP	Text	ZIP	Text for ZIP
ZIP	Text	ZIP	Text for ZIP with data filled
Table	HTML	Table	Table for populating the contact details
	Table
Department	Text	Department	Shows the name of the department added. For
Name		Name	example finance, marketing etc.
Name	Text	Name	Name of the contact person
Phone	Text	Phone	Phone of the contact person
Email	Text	Email	Email address of the contact person
FAX	Text	FAX	Fax of the contact person
Back	HTML	Back	Submit Button to navigate to the start screen
	Button
Delete	HTML	Delete	Button to delete the particular record currently
	Button		viewed.

3.1.7.3. Front End Validations

- [xxx] None.

3.1.8. User Interface ID: Search Product
3.1.8.1. Screen Name: Search Product

- (BPI_CAS_SCR_CM_—001_—007)
- (See FIG. H-8)

3.1.8.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Search Product	Text	Search	To give the heading for the
		Product	screen being navigated
Plan name	Text	Plan name	Title for carrier name
Plan name	Drop Down	Plan name	List all the active carrier
	List		names available in the system
View	HTML	View	Button to view the carrier
	Button		name selected
Edit	HTML	Edit	Button to edit the carrier
	Button		name selected

3.1.8.3. Front End Validations

3.1.9. User Interface 10: View Product Info
3.1.9.1. Screen Name: View Product Info

- (BPI_CAS_SCR_CM_—001_—008)
- (See FIG. H-9)

3.1.9.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the screen being
Carrier		Carrier	navigated
Product Info		Product Info
Sub Header	Text	Sub Header	Name for the sub header
Plan Info		Plan Info
Plan Id	Text	Plan Id	Provide Text
Plan Id	Dynamic	Plan Id	Name of the Plan Id being viewed
	Text
Plan Name	Text	Plan Name	Provide Text
Plan Name	Dynamic	Plan Name	Name of the Plan Name being viewed
	Text
Carrier Name	Text	Carrier Name	Provide Text
Carrier Name	Dynamic	Carrier Name	Name of the Carrier Name being viewed
	Text
Line of	Text	Line of	Provide Text
Coverage		Coverage
Line of	Text	Line of	Name of the Line Of Coverage Name being
Coverage		Coverage	viewed
Plan Type	Text	Plan Type	Provide Text
Plan Type	Dynamic	Plan Type	Name of the Plan Type being viewed
	Text
Carrier name	Dynamic	Carrier name	Name of the carrier being viewed
	Text
Sub Header	Text	Sub Header	Name of the sub header
Address		Address
Table	HTML	Table	Table for populating the plan offered
	Table
Benefit level	Text	Benefit level	For showing the benefit level name
name		name
Product Name	Text	Product Name	For showing the Product name
Delete	HTML	Delete	Button to delete the particular record currently
	Button		viewed.
Back	HTML	Back	To Navigate to Search Screen
	Button

3.1.9.3. Front End Validations

- None.

3.1.10. Screen Flow

- (See FIG. H-10)

Benefit Partners Inc

Process Specification

BPI_CAS_FSD_CM_—02

1. Introduction

1.1. Purpose
This purpose of this document is to identify the process associated with the business use case Create Plan. This document is the amendment of
BPI_CAS_FSD_CM_—02 (Version 1.0).
1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_CM_002	Create M Plan

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background
This process identifies the functionality for creation of Line of Coverage, Plan Type and Benefit Level.
This process is used to create various Line of Coverage, Plan type and benefit level offered by PacAdvantage. Line of coverage includes the coverage offered by PacAdvantage e.g. Medical, Dental, Vision, Chiropractic, Voluntary Medical etc. These classify broad range of all the line of coverage offered.
Plan type includes plan type for specific line of coverage e.g. PPO, HMO, PSO etc. Benefit Level specifies the specific benefit level offered for the line of coverage and plan type e.g. Standard, Preferred, preferred plus etc.
2.2. Process Description & Flow
2.2.1. Create Line of Coverage

- 1. Input Line of Coverage name
- 2. Validate Line of Coverage name
- 3. If yes add the information to a temporary storage.
- 4. If not re enter the information correctly and add again.
- 5. Edit or delete Line of Coverage name
- 6. If erroneous re enter the correct data.
- 7. If Correct then save the data to the repository
- 8. System auto generates a unique identification number for Line of Coverage
- Refer Process Flow Diagram

2.2.2. Create Plan Type

- 1. Input Plan Type name
- 2. Validate Plan Type name
- 3. If yes add the information to a temporary storage.
- 4. If not re enter the information correctly and add again.
- 5. Edit or delete Plan Type name
- 6. If erroneous re enter the correct data.
- 7. If Correct then save the data to the repository
- 8. System auto generates a unique identification number for Plan Type
- Refer Process Flow Diagram

2.2.3. Create Benefit Level

- 1. Input Benefit Level name
- 2. Validate Benefit Level name
- 3. If yes add the information to a temporary storage.
- 4. If not re enter the information correctly and add again.
- 5. Edit or delete Benefit Level name
- 6. If erroneous re enter the correct data.
- 7. If Correct then save the data to the repository
- 8. System auto generates a unique identification number for Benefit Level
- Refer Process Flow Diagram

2.2.4. Process Flow Diagrams

(See FIG. H-11)

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


Screen ID
(SID)	Screen Name	Corresponding HTML File Name

plan.loc	Line of Coverage	/bpi/cas/carrier/mplan/LineOfCoverage.jsp
plan.plan	Plan Type	/bpi/cas/carrier/mplan/PlanType.jsp
plan.ben	Benefit Level	/bpi/cas/carrier/mplan/BenefitLevel.jsp

3.1.2. User Interface ID: Create Line of Coverage
3.1.2.1. Screen Name: Create Line of Coverage

(BPI_CAS_SCR_CM_—002_—001)

(See FIG. H-12)

3.1.2.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the
Line of		Line of	screen being navigated
coverage		coverage
Line of	Text	Line of	Provide text
Coverage		Coverage
Loc Name	Entry Field	Loc Name	Entering line of coverage
Add	HTML	Add	Button for adding the Line of
	Button		coverage to the table below
Table	HTML table	Table	For adding and displaying all
			the names of the Line of
			Coverage
Delete	Button	Delete	To delete the line of Coverage
	(HTML		checked
	Button)
Check All	Text Link	Check All	To check all the check boxes
			in the table
Clear All	Text Link	Clear All	To un check all the check
			boxes checked in the table
Delete	Check box	Delete	To check the items for
			deletion
Edit	Button	Edit	To edit the Line of coverage
	(HTML		against the row selected
	Button)		for edition
Save	Button	Save	Save all the above information
	(HTML		to the repository
	Submit
	button)
Cancel	Button	Cancel	To resent the entries made
	(HTML		in all the fields
	reset button)

3.1.2.3. Front End Validations

- Validation Details
  - This section provides the front-end screen validations along with the associated message—


#	Element Name	Action/Validation Details	Message

1.	Line of coverage	This field is used for entering the line of	“Line of Coverage - Is
	Entry	coverage. The Line of coverage should	required.”
		be alphanumeric only. The special	“Line of Coverage -
		character permitted is only space bar	Accepts alphanumeric
		between the two words. And can have	values only”
		max length 20. Blank line of coverage not
		allowed
2.	Add	On Clicking add button or pressing enter	On click of Add button
		key field with the cursor position on the	checks for the above
		Add button, The data gets added to the	mentioned validations +
		table. Validation checks are done to not	“Line of Coverage -
		allow null value on the entry field and the	Already exists.”
		entry field should have only	(Occurs on duplicate record
		alphanumeric values. Duplicate name for	entry)
		the line of coverage should not be
		allowed.
3.	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. i.e. First
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of any text inside any cell should be
		wrapped if the text becomes too long.
4.	Delete	Should function with Enter Key Cursor	“! Select record(s) for
		Positioned on the “Delete” button or on	deletion”
		Mouse Click.	(If the operation is in Edit
		Delete Button should work on multiple	Mode & delete operation is
		deletes based on the check box or boxes	invoked)
		selected. If the user clicks on the delete
		button without checking any of the delete
		check box should throw error message.
		Success: Deletes the row or rows from
		the table (temporary storage)
5.	Check All	On clicking the “Check All” link should
		check all the check boxes in the HTML
		table.
6.	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check boxes in
		the HTML table.
7.	Delete	Check box option with default	Delete Check box is
		“unchecked”	disabled and grayed out if
			the data in the corresponding
			row/rows has child parent
			relationship (I.e. it has
			reference somewhere else in
			the database.)
8.	Edit	Should function with Enter Key Cursor	“! Complete the update
		Positioned on the “Edit” button or on	process”
		Mouse Click.	(If the operation is already in
		On clicking the edit button the row edited	Edit Mode & another Edit
		should be disabled and the data should be	operation is invoked)
		populated back on the editable entry
		field.
		Note: All data that are from the
		repository should be in green color. The
		data that is added and not saved should be
		in red. The data selected for editing
		should be displayed in gray. The “Add”
		button will be changed to “Update”
		button.
9.	Save	Should function with Enter Key Cursor	For general script
		Positioned on the “SAVE” button or on	validations for common
		Mouse Click.	functionality refer
		On saving the data the data gets saved to	BPI_CAS_FSD_COMMON
		the database.	System Error: Common
		Check if there is data populated for	Text shall be followed for
		editing. If yes show a dialog box with	the System Error.
		message “Complete update Process.”	“! Do any operation to save.”
			(Displayed when invoked
			immediately after the screen
			is loaded).
			“! Complete the update
			process”
			(Displayed when Save is
			invoked in edit Mode).
10.	Cancel	Should reset all the entries to previous
		status before saving. i.e. the fields should
		be blank. If any of the data has been
		selected for editing, the same data should
		appear when cancel button is clicked.

3.1.3. User Interface ID: Create Plan Type
3.1.3.1. Screen Name: Create Plan Type

(BPI_CAS_SCR_CM_—002_—002) (See FIG. H-13)

3.1.3.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the
Plan Type		Plan Type	screen being navigated
Plan Type	Text	Plan Type	Provide text
Plan type	Entry Field	Plan type	Entering Plan type
Entry		Entry
Add	HTML	Add	Button for adding the Plan
	Button		Type to the table below
Table	HTML table	Table	For adding and displaying all
			the names of the Plan Type
Delete	Button	Delete	To delete the Plan Type
	(HTML		checked
	Button)
Check All	Text Link	Check All	To check all the check boxes
			in the table
Clear All	Text Link	Clear All	To un check all the check
			boxes checked in the table
Delete	Check box	Delete	To check the items for
			deletion
Edit	Button	Edit	To edit the Plan Type against
	(HTML		the row selected for edition
	Button)
SAVE	Button	SAVE	Save all the above information
	(HTML		to the repository
	Submit
	button)
CANCEL	Button	CANCEL	To reset the entries made
	(HTML		in all the fields
	reset button)

3.1.3.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1.	Plan type Entry	This field is used for entering the Plan	Error Dialog Box:
		Type. The Plan Type should be	“Plan Name - Is required.”
		alphanumeric only. The special character	“Plan Name - Accepts
		permitted is only space bar between the	alphanumeric values only”
		two words. And can have max length
		255. Blank line of coverage not allowed
2.	Add	On Clicking add button or pressing enter	Error Dialog Box:
		key field with the cursor position on the	On click of Add button
		button, The data gets added to the table.	checks for the above
		Validation checks are done to not allow	mentioned validations +
		null value on the entry field and the entry	“Plan Name - already
		field should have only alphanumeric	exists.”
		values.	(Occurs on duplicate record
			entry)
3.	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. i.e. First
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of any text inside any cell should be
		wrapped if the text becomes too long.
4.	Delete	Should function with Enter Key Cursor	Error Dialog Box:
		Positioned on the “Delete” button or on	“! Select record(s) for
		Mouse Click.	deletion”
		Delete Button should work on multiple	“! Complete the update
		deletes based on the check box or boxes	process”
		selected. If the user clicks on the delete	(If the operation is in Edit
		button without checking any of the delete	Mode & delete operation is
		check box should throw error message.	invoked)
		Success: Deletes the row or rows from
		the table temporarily
5.	Check All	On clicking the “Check All” link should
		check all the check boxes in the HTML
		table.
6.	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check boxes in
		the HTML table.
7.	Delete	Check box option with default	Delete Check box is
		“unchecked”	disabled and grayed out if
			the data in the corresponding
			row/rows has child parent
			relationship (I.e. it has
			reference somewhere else in
			the database.)
8.	Edit	Should function with Enter Key Cursor	“! Complete the update
		Positioned on the “Edit” button or on	process”
		Mouse Click.	(If the operation is already in
		On clicking the edit button the row edited	Edit Mode & another Edit
		should be disabled and the data should be	operation is invoked)
		populated back on the editable entry
		field.
		Note: All the data inside the table that are
		from the repository should be green in
		color. The temporary data should be red
		in color text. The data selected for editing
		should be displayed in gray. The “Add”
		button will be changed to “Update”
		button.
9.	Save	Should function with Enter Key Cursor	For general script
		Positioned on the “SAVE” button or on	validations for common
		Mouse Click.	functionality refer
		On saving the data the data gets saved to	BPI_CAS_FSD_COMMON
		the database.	BPI_CAS_FSD_COMMON
		Check if there is data populated for	System Error: Common
		editing. If yes show a dialog box with	Text shall be followed for
		message “Complete update Process.”	the System Error.
			“! Do any operation to save.”
			(Displayed when invoked
			immediately after the screen
			is loaded).
			“! Complete the update
			process”
			(Displayed when Save is
			invoked in Edit Mode).
10.	Cancel	Should reset to the previous status on
		clicking the cancel button. i.e. make all
		the entry field blank. If any of the data
		has been selected for editing, the same
		data should appear when cancel button is
		clicked.

3.1.4. User Interface ID: Create Benefit Level
3.1.4.1. Screen Name: Create Benefit Level

(BPI_CAS_SCR_CM_—002_—003) (See FIG. H-14)

3.1.4.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give the heading for the screen being
Benefit Level		Benefit Level	navigated
Benefit Level	Text	Benefit Level	Provide text
Name		Name
Benefit Level	Entry Field	Benefit Level	Entering the benefit level name
Name Entry		Name Entry
Add	HTML	Add	Button for adding the Benefit Level to the table
	Button		below
Table	HTML table	Table	For adding and displaying all the names of the
			Benefit Level
Delete	Button	Delete	To delete the Benefit Level checked
	(HTML
	Button)
Check All	Text Link	Check All	To check all the check boxes in the table
Clear All	Text Link	Clear All	To un check all the check boxes checked in the
			table
Delete	Check box	Delete	To check the items for deletion
Edit	Button	Edit	To edit the Benefit Level against the row
	(HTML		selected for edition
	Button)
Save	Button	Save	Save all the above information to the repository
	(HTML
	Submit
	button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	reset button)

3.1.4.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1.	Benefit Level	This field is used for entering the Benefit	Error Dialog Box:
		Level. The Benefit Level should be	“Benefit Level - Is
		alphanumeric only. The special character	required.”
		permitted is only space bar between the	“Benefit Level - Accepts
		two words. And can have max length	alphanumeric values only”
		255. Blank line of coverage not allowed
2.	Add	On Clicking add button or pressing enter	Error Dialog Box:
		key field with the cursor position on the	On click of Add button
		button, The data gets added to the table.	checks for the above
		Validation checks are done to not allow	mentioned validations +
		null value on the entry field and the entry	“Benefit Level - already
		field should have only alpha values.	exists.”
		Should check for duplicate entries	(Occurs on duplicate record
			entry)
3.	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. i.e. First
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of any text inside any cell should be
		wrapped if the text becomes too long.
4.	Delete	Should function with Enter Key Cursor	Error Dialog Box:
		Positioned on the “Delete” button or on	“! Select the record(s) for
		Mouse Click.	deletion”
		Delete Button should work on multiple	“! Complete the update
		deletes based on the check box or boxes	process”
		selected. If the user clicks on the delete	(If the operation is in Edit
		button without checking any of the delete	Mode & delete operation is
		check box should throw error message.	invoked)
5.	Check All	On clicking the “Check All” link should
		check all the check boxes in the HTML
		table.
6.	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check boxes in
		the HTML table.
7.	Delete	Check box option with default	Delete Check box is
		“unchecked”	disabled and grayed out if
			the data in the corresponding
			row/rows has child parent
			relationship (I.e. it has
			reference somewhere else in
			the database.)
8.	Edit	Should function with Enter Key Cursor	“! Complete the update
		Positioned on the “Edit” button or on	process”
		Mouse Click.	(If the operation is already in
		On clicking the edit button the row edited	Edit Mode & another Edit
		should be removed from the table and the	operation is invoked)
		data should be populated back on the
		editable entry field.
		If the data is from the repository show it
		in green color text. If it is temporary data
		just added show it in red color text. The
		data selected for editing should be
		displayed in gray. The “Add” button will
		be changed to “Update” button.
9.	Save	Should function with Enter Key Cursor	For general script
		Positioned on the “SAVE” button or on	validations for common
		Mouse Click. On saving the data the data	functionality refer
		gets saved to the database.	BPI_CAS_FSD_COMMON
		Check if there is data populated for	System Error: Common
		editing. If yes show a dialog box with	Text shall be followed for
		message “Complete update Process.”	the System Error.
			“! Do any operation to save.”
			(Displayed when invoked
			immediately after the screen
			is loaded).
			“! Complete the update
			process”
			(Displayed when Save is
			invoked in Edit Mode).
10.	Cancel	Should reset to the previous status on
		clicking the cancel button. If any of the
		data has been selected for editing, the
		same data should appear when cancel
		button is clicked.

3.1.5. Screen Flow

- The flow of the process is as described below. (See FIG. H-15)

Benefit Partners Inc

Process Specification

BPI_CAS_FSD_CM_—03

1. Introduction

1.1. Purpose
This purpose of this document is to identify the process associated with the business use case Create Rate Master. This document is the amendment of BPI_CAS_FSD_CM_—03 (Version 1.1).
1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_CM_003	Create Rate Master

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background

- This process describes the Use Case “Rate Master”.
- Rate Master is used to upload all the rates for the products (Benefits) provided by individual health insurance provider (Carrier). The individual rate files are provided by PacAdvantage with the rate for all the products offered by all the carriers in a specific file format. This Process for loading the rates would be covered in the Document Reference No: BPI_CAS_FSD_EC
- The rates are normally classified as blended rates and raw rates.
- Raw rates would include only the premium rates for the products offered.
- Blended rate would include the sum total of the entire raw rate, admin fees, agent commission additional fees and Differential Fees. The rate classification would define the formula for calculating the blended rate for the product under offering. Using the administrative screens the classification of rates for arriving to these calculations is provided.
- Admin Fees: Further Admin fees can be of two types % of the premium or a fixed flat $ amount.
- Agent Commission: Agent commission can be a % of premium or a flat $ amount per member or a flat $ amount per group size.
- Additional Fees: Additional Fees can be a % premium or flat $ amount for the carrier.
- Differential Fees The amount type for Differential Rate should include Flat $ amount as Flat $ amount per member and also Flat $ amount per Group. When the Flat $ amount is per group it should be able to specify group size.
- The state is divided into several service areas based on the number of counties and their population. In the state of California there are presently 6 service areas. The Rate is based on the service area where the employees are residing. Also there are cases when the ZIP code has two or more Service Areas. Under these conditions the ZIP code should be attached to those services areas from where the rates are to be picked.

2.2. Process Description & Flow
2.2.1. Admin Fee

- The flow of the process is as described below.
- 1. Input the rate type information.
- 2. Validate if the rate type information has the right data type.
- 3. If Correct then save the data to the repository.
- 4. Search admin fee records.
- 5. Select a record in modify mode
- 6. Edit the rate type information.
- 7. Validate if the rate type information has the right data type.
- 8. If Correct then save the data to the repository.
- 9. Search admin fee records.
- 10. Select a record in view/delete mode
- 11. View the selected admin fee
- 12. Delete the selected admin fee from the repository.
- Refer Process Flow Diagram FIG. 1.

2.2.2. Agent Fee

- The flow of the process is as described below.
- 1. Input the rate type information.
- 2. Validate if the rate type information has the right data type.
- 3. If Correct then save the data to the repository.
- 4. Search agent fee records.
- 5. Select a record in modify mode
- 6. Edit the rate type information.
- 7. Validate if the rate type information has the right data type.
- 8. If Correct then save the data to the repository.
- 9. Search agent fee records.
- 10. Select a record in view/delete mode
- 11. View the selected agent fee.
- 12. Delete the selected agent fee from the repository.

Refer Process Flow Diagram FIG. 2.

2.2.3. Additional Fee

- The flow of the process is as described below.
- 1. Input the rate type information.
- 2. Validate if the rate type information has the right data type.
- 3. If Correct then save the data to the repository.
- 4. Search additional fee records.
- 5. Select a record in modify mode
- 6. Edit the rate type information.
- 7. Validate if the rate type information has the right data type.
- 8. If Correct then save the data to the repository.
- 9. Search additional fee records.
- 10. Select a record in view/delete mode
- 11. View the selected additional fee.
- 12. Delete the selected additional fee from the repository.
- Refer Process Flow Diagram FIG. 3.

2.2.4. Rate Differential

- The flow of the process is as described below.
- 1. Input the rate type information.
- 2. Validate if the rate type information has the right data type.
- 3. If Correct then save the data to the repository.
- 4. Search rate differential records.
- 5. Select a record in modify mode
- 6. Edit the rate type information.
- 7. Validate if the rate type information has the right data type.
- 8. If Correct then save the data to the repository.
- 9. Search rate differential records.
- 10. Select a record in view/delete mode
- 11. View the selected rate differential.
- 12. Delete the selected rate differential from the repository.
- Refer Process Flow Diagram FIG. 4.

2.2.5. Process Flow Diagrams

- (See FIG. H-16)
- (See FIG. H-17)
- (See FIG. H-18)
- (See FIG. H-19)

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


		Corresponding HTML File
Screen ID (SID)	Screen Name	Name

rate.admin	Admin Fees	/bpi/cas/carrier/rates/AdminFee.jsp
rate.admin.search	Search Admin Fees	/bpi/cas/carrier/rates/AdminFeeSearch.jsp
rate.admin.view	View Admin Fees	/bpi/cas/carrier/rates/AdminFeeView.jsp
rate.admin.confirm	Confirm Admin Fees	/bpi/cas/carrier/rates/AdminFeeConfirm.jsp
rate.agent	Agent Commission	/bpi/cas/carrier/rates/AgentFee.jsp
rate.agent.search	Search Agent	/bpi/cas/carrier/rates/AgentFeeSearch.jsp
	Commission
rate.agent.view	View Agent	/bpi/cas/carrier/rates/AgentFeeView.jsp
	Commission
rate.agent.confirm	Confirm Agent	/bpi/cas/carrier/rates/AgentFeeConfirm.jsp
	Commission
rate.add	Additional Fees	/bpi/cas/carrier/rates/AdditionalFee.jsp
rate.add.search	Search Additional Fees	/bpi/cas/carrier/rates/AdditionalFeeSearch.jsp
rate.add.view	View Additional Fees	/bpi/cas/carrier/rates/AdditionalFeeView.jsp
rate.add.confirm	Confirm Additional Fees	/bpi/cas/carrier/rates/AdditionalFeeConfirm.jsp
rate.ratediff	Differential Fees	/bpi/cas/carrier/rates/DifferentialRate.jsp
rate.ratediff.search	Search Differential Fees	/bpi/cas/carrier/rates/DifferentialRateSearch.jsp
rate.ratediff.view	View Differential Fees	/bpi/cas/carrier/rates/DifferentialRateView.jsp
rate.ratediff.confirm	Confirm Differential	/bpi/cas/carrier/rates/DifferentialRateConfirm.jsp
	Fees

3.1.2. User Interface ID: Rate Classification—Admin Fees
3.1.2.1. Screen Name: Rate Classification—Admin Fees

(BPI-CAS_SCR_CM_—003_—001) (See FIG. H-20)

3.1.2.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Admin		for Admin
Fees		Fees
Rate Type	Radio	Rate Type	To Select a rate type (Whether Blended or Non
			Blended)
Rate Type	Radio	Rate Type	To Select a rate type (Whether Enroll or
			Renew)
Group Type	Drop Down	Group Type	List all the Group Type Available in the system
	List
Association ID	Drop Down	Association	List all the Association Type Available in the
	List	ID	system
Member Type	Radio	Member Type	To Select a Member type (Whether Individual
			or Association)
Percentage	Entry Field	Percentage	Entry field for entering % premium
Premium		Premium
Effective Date	Entry Field	Effective Date	To choose the date required, by calendar or
			entering it
Amount	Entry Field	Amount	Entry field for entering Amount in $
Medical	Entry Field	Medical	Entry field for entering the Medical Fee in $
Dental	Entry Field	Dental	Entry field for entering the Dental Fee in $
Vision	Entry Field	Vision	Entry field for entering the Vision Fee in %
CAM	Entry Field	CAM	Entry field for entering the CAM Fee in %
Save	Button	Save	Save all the above information to the repository
	(HTML
	Submit
	button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	reset
	Button)

3.1.2.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1.	Rate Type	Rate Type should be selected for Adding	“Rate Type - Is required”
		Admin Fees (Either one of Blended Rate
		or Non Blended Rate) and (Either one of
		Enroll or Renew).
2.	Group Type	Should list all the Group Type within the	“Group Type - Is required”
		system
		The first option should be -
		-- Choose One --. Subsequent Group
		Types should be listed in alphabetical
		order

3.	Association Id	Should list all the Association Id within	“Association Id - Is
		the system. The first option should be -	required”
		-- Choose One --. Subsequent Group
		Types should be listed in alphabetical
4.	Member Type	Member Type should be selected for	“Member Type - Is
		Adding Admin Fees if Group Type is	required. Select either
		Guaranteed Association.	Individual Member or
			Association Group”
5.	Percentage	Percentage Premium should be entered if	“Percentage Premium - Is
	Premium	the rate type is Blended	Required”
			“Percentage Premium -
			Accepts numeric value only
			(0 to 100)”
6.	Effective Date	Effective Date should be selected from	“Effective Date - Is
		Calendar or entered For valid Date	required”
		Format Refer BPI_CAS_FSD_Common	“Effective Date - Accepts
			the format in
			MM/DD/YYYY”
7.	Amount	Amount should be entered if the rate type	“Amount - Is required”
		is Non Blended	“Amount - Accepts
			currency format only
			(###.##)”
8.	Medical	Medical should be entered if the rate type	“Medical - Is required”
		is Non Blended	“Medical - Accepts
			currency format only
			(###.##)”
9.	Dental	Medical should be entered if the rate type	“Dental - Is required”
		is Non Blended	“Dental - Accepts currency
			format only (###.##)”
10.	Vision	Medical should be entered if the rate type	“Vision - Is required”
		is Non Blended	“Vision - Accepts numeric
			value only (0 to 100)”
11.	CAM	Medical should be entered if the rate type	“CAM - Is required”
		is Non Blended	“CAM - Accepts numeric
			value only (0 to 100)”
12.	Save	Should function with Entry Key Cursor	For general script
		Positioned on the “SAVE” button or on	validations for common
		Mouse Click.	functionality refer
		On saving the data the data gets saved to	BPI_CAS_FSD_COMMON
		the database.	System Error: Common
		Should there be any validation error on	Text shall be followed for
		any of the fields. Should show the script	the System Error.
		error and place the cursor on the specific	“! Do any operation to
		entry field.	save.”
		Check if the entries are not duplicate.	(Displayed when invoked
		On Successful saving the flow should	immediately after the
		reside in the same screen.	screen is loaded).
		Exception: If the data selected for edition	“! Complete the update
		is from the repository retain its previous	process.”
		state. I.e. the data should be visible in the	(Displayed when Save is
		table after saving.	invoked in Edit Mode).
		Also show different text color for the
		data added (temporary) and the data
		picked from the repository.
13.	Cancel	Should reset to the previous state on
		clicking the cancel button

3.1.3. User Interface ID: Rate Classification—Search Admin Fees
3.1.3.1. Screen Name: Rate Classification—Search Admin Fees

(BPI_CAS_SCR_CM_—003_—002) (See FIG. H-21)

3.1.3.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Admin		for Admin
Fees		Fees
Rate Type	Radio	Rate Type	To Select a rate type (Whether Blended or Non
			Blended)
Rate Type	Radio	Rate Type	To Select a rate type (Whether Enroll or
			Renew)
Group Type	Drop Down	Group Type	List all the Group Type Available in the system
	List
Association ID	Drop Down	Association	List all the Association Type Available in the
	List	ID	system
Percentage	Entry Field	Percentage	Entry field for entering % premium
Premium		Premium
Effective Date	Entry Field	Effective Date	To choose the date required, by calendar or
			entering it
Search	HTML	Search	Button to search the data based on inputs and
	Button		displays the results in HTML table below
Table	HTML table	Table	Shows the all the data in the column format
View/Delete	Button	View/Delete	Button to view the selected record data
	(HTML
	Button)
Check Index	Radio	Check Index	To check the items for modify, view and
	Button		deletion
Edit	Button	Edit	To edit the data against the row selected for
	(HTML		edition
	Button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	Button)

3.1.3.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1	Effective Date	Effective Date should be selected from	“Effective Date - Accepts
		Calendar or entered	the format in
		For valid Date Format Refer	MM/DD/YYYY”
		BPI_CAS_FSD_Common
2	Search	Should function with Entry Key Cursor	On click of Search button
		Positioned on the “Search” button or	checks for the above
		Mouse Click.	mentioned validations
		All the entries are valid. It fetches the
		records from repository based on inputs
		and displays the records in the table
		below. Else throws error dialog box.
3	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. I.e. first
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of the text inside any cell should be
		wrapped if the text becomes too long.
4	View/Delete	Should function with Entry Key Cursor	“! Select any one of the
		Positioned on the “View/Delete” button	record”
		or on Mouse Click.
		If the user clicks on the view button
		without checking any of the view radio
		button should throw error message.
		Success: View the current row from the
		table.
5	Modify	Should function with Enter Key Cursor
		Positioned on the “Modify” button or on
		Mouse Click.
		On clicking the modify button the row is
		edited and the data should be populated.
6	Cancel	Should reset to the previous state on
		clicking the cancel button

3.1.4. User Interface ID: Rate Classification—View Admin Fees
3.1.4.1. Screen Name: Rate Classification—View Admin Fees

(BPI_CAS_SCR_CM_—003_—003) (See FIG. H-22)

3.1.4.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the
rate		rate	screen being navigated
Classification		Classification
for Admin		for Admin
Fees		Fees
Rate Type	Text Field	Rate Type	Displays Blended or
			Non Blended rates
Enroll	Text Field	Enroll	Displays Enroll or Renew
Renew		Renew
Group Type	Text Field	Group Type	Displays Group Type
Association ID	Text Field	Association	Displays Association Type
		ID
Percentage	Text Field	Percentage	Displays % premium
Premium		Premium
Effective Date	Text Field	Effective Date	Displays Effective date
Amount	Text Field	Amount	Displays Amount in $
Medical	Text Field	Medical	Displays Medical Fee in $
Dental	Text Field	Dental	Displays Dental Fee in $
Vision	Text Field	Vision	Displays Vision Fee in %
CAM	Text Field	CAM	Displays CAM Fee in %
Delete	Button	Delete	To delete the data
	(HTML
	Button)
New Admin	Button	New Admin	Go to New Admin fee
fees	(HTML	fees	screen
	Button)

3.1.4.3. Front End Validations


#	Element Name	Action/Validation Details	Message

1	Delete	Should function with Enter Key	“Do you want
		Cursor Positioned on the	to delete the
		“Delete” button or on	selected record?”
		Mouse Click.
		If the user clicks on the delete
		button throw message box.
		Success: Deletes the row from
		the data base
2	New Admin	Should go to the admin fees
	Fees	screen clicking the New
		Admin Fees button

3.1.5. User Interface ID: Rate Classification—Agent Commission
3.1.5.1. Screen Name: Rate Classification—Agent Commission

(BPI_CAS_SCR_CM_—003_—004) (See FIG. H-23)

3.1.5.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Agent Fees		for Agent Fees
Rate Type	Radio	Rate Type	To Select a rate type (Whether Blended or Non
			Blended)
Rate Type	Radio	Rate Type	To Select a rate type (Whether Enroll or
			Renew)
Enrolled	Check Box	Enrolled	To be checked if enrolled before 1997.
before 1997		before 1997
Group Type	Drop Down	Group Type	List all the Group Type Available in the system
	List
Association ID	Drop Down	Association	List all the Association Type Available in the
	List	ID	system
Member Type	Radio	Member Type	To Select a Member type (Whether Individual
			or Association)
Percentage	Entry Field	Percentage	Entry field for entering % premium
Premium		Premium
Effective Date	Entry Field	Effective Date	To choose the date required by calendar or
			entering
Group Size	Entry Field	Group Size	Entry field for entering group size Upper limit.
Lower Limit		Lower Limit
Amount	Entry Field	Amount	Entry field for entering Amount in $
Medical	Entry Field	Medical	Entry field for entering the Medical Fee in $
Dental	Entry Field	Dental	Entry field for entering the Dental Fee in $
Vision	Entry Field	Vision	Entry field for entering the Vision Fee in %
CAM	Entry Field	CAM	Entry field for entering the CAM Fee in %
Save	Button	Save	Save all the above information to the repository
	(HTML
	Button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	Button)

3.1.5.3. Front End Validations


·	Element Name	Action/Validation Details	Message

1.	Rate Type	Rate Type should be selected for Adding	“Rate Type - Is Required”
		Agent Fees (Either one of Blended or
		Non Blended Rate and Either one of
		Enroll or Renew)
2.	Enrolled before	Should be selected if enrolled before
	1997	1997.
3.	Group Type	Should list all the Group Type within the	“Group Type - Is required”
		system
		The first option should be
		-- Choose One --. Subsequent Group
		Types should be listed in alphabetical
		order

4.	Association Id	Should list all the Association Id within	“Association Id - Is
		the system. The first option should be	required”
		-- Choose One --. Subsequent Group
		Types should be listed in alphabetical
5.	Member Type	Member Type should be selected for	“Member Type - Is
		Adding Agent Fees if Group Type is	required. Select Individual
		Guaranteed Association.	Member or Association
			Group.”
6.	Percentage	Percentage Premium should be entered if	“Percentage Premium”-
	Premium	the rate type is Blended	Is required
			“Percentage Premium in -
			Accepts numeric values
			only (0 to 100)”
7.	Effective Date	Effective Date should be selected from	“Effective Date - Is
		Calendar or entered	required”
		For valid Date Format Refer	“Effective Date - Accepts
		BPI_CAS_FSD_Common	the format in
			MM/DD/YYYY”
8.	Group Size Lower	Group Size Lower Limit should be	“Group Size Lower Limit -
	Limit	entered if the rate type is Non Blended	Is required”
			“Group Size Lower limit -
			Accepts numeric values
			only (1-999)”
9.	Group Size Upper	Group Size Upper Limit should be	“Group Size Upper Limit -
	Limit	entered if the rate type is Non Blended	Is required”
			“Group Size Upper Limit -
			Accepts numeric values
			only (1-999)”
			“Kindly enter Group Size
			Upper limit greater than
			Lower Limit”
10.	Amount	Amount should be entered if the rate type	“Amount - Is required”
		is Non Blended	“Amount - Accepts
			currency format only
			(###.##)_”
11.	Medical	Medical should be entered if the rate type	“Medical - Is required”
		is Non Blended	“Medical - Accepts
			currency format only
			(###.##)”
12.	Dental	Medical should be entered if the rate type	“Dental - Is required”
		is Non Blended	“Dental - Accepts currency
			format only (###.##)”
13.	Vision	Medical should be entered if the rate type	“Vision - Is required”
		is Non Blended	“Vision - Accepts numeric
			value only (0 to 100)”
14.	CAM	Medical should be entered if the rate type	“CAM - Is required”
		is Non Blended	“CAM - Accepts numeric
			value only (0 to 100)”
15.	Save	Should function with Enter Key Cursor	For general script
		Positioned on the “SAVE” button or on	validations for common
		Mouse Click.	functionality refer
		On saving the data the data gets saved to	BPI_CAS_FSD_COMMON
		the database.	System Error: Common
		Should there be any validation error on	Text shall be followed for
		any of the fields. Should show the script	the System Error.
		error and place the cursor on the specific	“! Do any operation to
		entry field.	save.”
		Check if the entries are not duplicate.	(Displayed when invoked
		On Successful saving the flow should	immediately after the
		reside in the same screen.	screen is loaded).
		Exception: If the data selected for edition
		is from the repository retain its previous
		state. I.e. the data should be visible in the
		table after saving.
16.	Cancel	Should reset to the previous state on
		clicking the cancel button

3.1.6. User Interface ID: Rate Classification—Search Agent Commission
3.1.6.1. Screen Name: Rate Classification—Search Agent Commission

(BPI-CAS_SCR_CM_—003_—005) (See FIG. H-24)


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Agent Fees		for Agent Fees
Rate Type	Radio	Rate Type	To Select a rate type (Whether Blended or Non
			Blended)
Enroll/	Radio	Enroll/	To Select a rate type (Whether Enroll or
Renew		Renew	Renew)
Group Type	Drop Down	Group Type	List all the Group Type Available in the system
	List
Association ID	Drop Down	Association	List all the Association Type Available in the
	List	ID	system
Effective Date	Entry Field	Effective Date	To choose the date required by calendar or
			entering
Group Size	Entry Field	Group Size	Entry field for entering Group size Lower limit.
Lower Limit		Lower Limit
Group Size	Entry Field	Group Size	Entry field for entering Group size Upper limit.
Upper Limit		Upper Limit
Search	HTML	Search	Button to search the data based on inputs and
	Button		displays the results in HTML table below
Table	HTML table	Table	Shows the all the data in the column format
View/Delete	Button	View/Delete	Button to view the selected record data
	(HTML
	Button)
Check Index	Radio	Check Index	To check the items for modify, view and
	Button		deletion
Modify	Button	Modify	To edit the data against the row selected for
	(HTML		edition
	Button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	Button)

3.1.6.3. Front End Validations


·	Element Name	Action/Validation Details	Message

1	Effective Date	Effective Date should be selected from	“Effective Date - Accepts
		Calendar or entered	the format in
		For valid Date Format Refer	MM/DD/YYYY”
		BPI_CAS_FSD_Common
2	Group Size Lower	Group Size Lower Limit should be	“Group Size Lower limit -
	Limit	entered if the rate type is Non Blended	Accepts numeric values
			only (1-999)”
3	Group Size Upper	Group Size Upper Limit should be	“Group Size Upper Limit -
	Limit	entered if the rate type is Non Blended	Accepts numeric values
			only (1-999)”
			“Kindly enter Group Size
			Upper limit greater than
			Lower Limit”
4	Search	Should function with Enter Key Cursor	On click of Search button
		Positioned on the “Search” button or	checks for the above
		Mouse Click.	mentioned validations
		All the entries are valid. It fetches the
		records from repository based on inputs
		and displays the records in the table
		below. Else throws error dialog box.
5	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. I.e. first
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of the text inside any cell should be
		wrapped if the text becomes too long.
6	View/Delete	Should function with Enter Key Cursor	“! Select any one of the
		Positioned on the “View/Delete” button	record”
		or on Mouse Click.
		If the user clicks on the view button
		without checking any of the view radio
		button should throw error message.
		Success: View the current row from the
		table.
7	Modify	Should function with Enter Key Cursor	“! Select any one of the
		Positioned on the “Modify” button or on	record”
		Mouse Click.
		On clicking the modify button the row is
		edited and the data should be populated.
8	Cancel	Should reset to the previous state on
		clicking the cancel button

3.1.7. User Interface ID: Rate Classification—View Agent Commission
3.1.7.1. Screen Name: Rate Classification—View Agent Commission

(BPI_CAS_SCR_CM_—003_—006) (See FIG. H-25)

3.1.7.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Agent Fees		for Agent Fees
Rate Type	Text Field	Rate Type	To Display rate type (Whether Blended or Non
			Blended)
Enroll Type	Text Field	Enroll Type	To Display enroll type (Whether Enroll or
			Renew)
Enrolled	Text Field	Enrolled	To Display enrolled before 1997 or not.
before 1997		before 1997
Group Type	Text Field	Group Type	To Display Group Type
Association ID	Text Field	Association	To Display Association Type
		ID
Member Type	Text Field	Member Type	To Display member type (Individual or
			Association)
Percentage	Text Field	Percentage	To Display % premium
Premium		Premium
Effective Date	Text Field	Effective Date	To Display Effective date
Group Size	Text Field	Group Size	To Display Group size Lower limit
Lower Limit		Lower Limit
Group Size	Text Field	Group Size	To Display Group size Upper limit
Upper Limit		Upper Limit
Amount	Text Field	Amount	To Display Amount in $
Medical	Text Field	Medical	To Display Medical Fee in $
Dental	Text Field	Dental	To Display Dental Fee in $
Vision	Text Field	Vision	To Display Vision Fee in %
CAM	Text Field	CAM	To Display CAM Fee in %
Delete	Button	Delete	To delete the data
	(HTML
	Button)
New Agent	Button	New Agent	To go to New Agent fees screen
Fees	(HTML	Fees
	Button)

3.1.7.3. Front End Validations


·	Element Name	Action/Validation Details	Message

1	Delete	Should function with Enter Key	“Do you want
		Cursor Positioned on the	to delete the
		“Delete” button or on	selected record?”
		Mouse Click.
		If the user clicks on the delete
		button throw message box.
		Success: Deletes the row from
		the data base
2	New Agent	Should go to the agent fees
	Fees	screen clicking the New Agent
		Fees button

3.1.8. User Interface ID: Rate Classification—Additional Fees
3.1.8.1. Screen Name: Rate Classification—Additional Fees

(BPI_CAS_SCR_CM_—003_—007) (See FIG. H-26)

3.1.8.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Additional		for Additional
Fees		Fees
Cobra Type	Radio	Cobra Type	To Select a Cobra Type (Whether Cal Cobra or
			Federal Cobra)
Additional Fee	Entry Field	Additional	Entry field for entering % Additional Fees
Percentage		Fee
		Percentage
Effective Date	Entry Field	Effective Date	To choose the date required by calendar or
			entering
Save	Button	Save	Save all the above information to the repository
	(HTML
	Button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	Button)

3.1.8.3. Front End Validations


·	Element Name	Action/Validation Details	Message

1.	Cobra Type	Cobra Type should be selected for	“Kindly choose Cobra”
		Adding Additional Fees
2.	Additional Fee	Additional Fee Percentage should be	“% Of Additional Fees - Is
	Percentage	entered.	required”
			“% of Additional Fees -
			Accepts numeric value only
			(0 to 100)
3.	Effective Date	Effective Date should be selected from	“Effective Date - Is
		Calendar or entered	required”
		For valid Date Format Refer	“Effective Date - Accepts
		BPI_CAS_FSD_Common	the format in
			MM/DD/YYYY”
4.	Save	Should function with Enter Key Cursor	For general script
		Positioned on the “SAVE” button or on	validations for common
		Mouse Click.	functionality refer
		On saving the data the data gets saved to	BPI_CAS_FSD_COMMON
		the database.	System Error: Common
		Should there be any validation error on	Text shall be followed for
		any of the fields. Should show the script	the System Error.
		error and place the cursor on the specific	“! Do any operation to
		entry field.	save.”
		Check if the entries are not duplicate.	(Displayed when invoked
		On Successful saving the flow should	immediately after the
		reside in the same screen.	screen is loaded).
		Exception: If the data selected for edition
		is from the repository retain its previous
		state. I.e. the data should be visible in the
		table after saving.
5.	Cancel	Should reset to the previous state on
		clicking the cancel button

3.1.9. User Interface ID: Rate Classification—Search Additional Fees
3.1.9.1. Screen Name: Rate Classification—Search Additional Fees

(BPI_CAS_SCR_CM_—003_—008) (See FIG. H-27)

3.1.9.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Additional		for Additional
Fees		Fees
Cobra Type	Radio	Cobra Type	To Select a Cobra Type (Whether Cal Cobra or
			Federal Cobra)
Additional Fee	Entry Field	Additional	Entry field for entering % Additional Fees
Percentage		Fee
		Percentage
Effective Date	Entry Field	Effective Date	To choose the date required by calendar or
			entering
Search	HTML	Search	Button to search the data based on inputs and
	Button		displays the results in HTML table below
Table	HTML	Table	Shows the all the data in the column format
	Table
View/Delete	Button	View/Delete	Button to view the selected record data
	(HTML
	Button)
Check Index	Radio	Check Index	To check the items for modify, view and
	Button		deletion
Modify	Button	Modify	To edit the data against the row selected for
	(HTML		edition
	Button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	Button)

3.1.9.3. Front End Validations


·	Element Name	Action/Validation Details	Message

1	Additional Fee	Additional Fee Percentage should be	“% of Additional Fees -
	Percentage	entered.	Accepts numeric value only
			(0 to 100)”
2	Effective Date	Effective Date should be selected from	“Effective Date - Accepts
		Calendar or entered	the format in
		For valid Date Format Refer	MM/DD/YYYY”
		BPI_CAS_FSD_Common
3	Search	Should function with Enter Key Cursor	On click of Search button
		Positioned on the “Search” button or	checks for the above
		Mouse Click.	mentioned validations
		All the entries are valid. It fetches the
		records from repository based on inputs
		and displays the records in the table
		below. Else throws error dialog box.
4	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. I.e. first
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of the text inside any cell should be
		wrapped if the text becomes too long.
5	View/Delete	Should function with Enter Key Cursor	“! Select any one of the
		Positioned on the “View/Delete” button	record”
		or on Mouse Click.
		If the user clicks on the view button
		without checking any of the view radio
		button should throw error message.
		Success: View the current row from the
		table.
6	Modify	Should function with Enter Key Cursor	“! Selected any one of the
		Positioned on the “Modify” button or on	record”
		Mouse Click.
		On clicking the modify button the row is
		edited and the data should be populated.
7	Cancel	Should reset to the previous state on
		clicking the cancel button

3.1.10. User Interface ID: Rate Classification—View Additional Fees
3.1.10.1. Screen Name: Rate Classification—View Additional Fees

(BPI_CAS_SCR_CM_—003_—009) (See FIG. H-28)

3.1.10.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for Additional		for Additional
Fees		Fees
Cobra Type	Text Field	Cobra Type	To Display Cobra Type (Whether Cal Cobra or
			Federal Cobra)
Additional Fee	Text Field	Additional	To Display % Additional Fes
Percentage		Fee
		Percentage
Effective Date	Text Field	Effective Date	To Display Effective date
New	HTML	New	Button to go to new Additional fees
Additional	Button	Additional
Fees		Fees
Delete	Button	Delete	To delete the current additional fees data
	(HTML
	Button)

3.1.10.3. Front End Validations


·	Element Name	Action/Validation Details	Message

1	Delete	Should function with Enter Key	“Do you want
		Cursor Positioned on the	to delete the
		“Delete” button or on	selected record?”
		Mouse Click.
		If the user clicks on the delete
		button throw message box.
		Success: Deletes the row from
		the data base
2	New	Should go to the additional fees
	Additional	screen clicking the New
	Fees	additional Fees button

3.1.11. User Interface ID: Rate Classification—Differential Fees
3.1.11.1. Screen Name: Rate Classification—Differential Fees

(BPI_CAS_SCR_CM_—003_—010) (See FIG. H-29)

3.1.11.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for		for
Differential		Differential
Factor		Factor
Group Size	Entry Field	Group Size	Entry field for entering Group size Lower limit.
Lower Limit		Lower Limit
Group Size	Entry Field	Group Size	Entry field for entering Group size Upper limit.
Upper Limit		Upper Limit
Differential	Entry Field	Differential	Entry field for entering Differential Factor
Factor		Factor
Effective Date	Entry Field	Effective Date	To choose the date required by calendar or
			entering
Applicable For	Radio	Applicable	To Select a Applicable For (Whether New
		For	Business Only or New Business or Renewal)
Group Size	Radio	Group Size	To Select a Group Size Criteria (Whether
Criteria		Criteria	Eligible Employee or Enrolled Employee)
Save	Button	Save	Save all the above information to the repository
	(HTML
	Submit
	button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	reset
	Button)

3.1.11.3. Front End Validations


•	Element Name	Action/Validation Details	Message

1.	Group Size Lower	Group Size Lower Limit should be	“Group Size Lower Limit -
	Limit	entered.	Is required”
			“Group Size Lower limit -
			Accepts numeric values
			only (1-999)”
2.	Group Size Upper	Group Size Upper Limit should be	“Group Size Upper Limit -
	Limit	entered.	Is required”
			“Group Size Upper Limit -
			Accepts numeric values
			only (1-999)”
			“Kindly enter Group Size
			Upper limit greater than
			Lower Limit”
3.	Differential Factor	Differential Factor should be entered.	“Differential Factor - Is
			required”
			“Differential Factor -
			Accepts numeric values
			only.”
			“Differential Factor -
			Cannot be Zero”
4.	Effective Date	Effective Date should be selected from	“Effective Date - Is
		Calendar or entered	required”
		For valid Date Format Refer	“Effective Date - Accepts
		BPI_CAS_FSD_Common	the format in
			MM/DD/YYYY”
5.	Save	Should function with Enter Key Cursor	For general script
		Positioned on the “SAVE” button or on	validations for common
		Mouse Click.	functionality refer
		On saving the data the data gets saved to	BPI_CAS_FSD_COMMON
		the database.	System Error: Common
		Should there be any validation error on	Text shall be followed for
		any of the fields. Should show the script	the System Error.
		error and place the cursor on the specif	“! Do any operation to
		entry field.	save.”
		Check if the entries are not duplicate.	(Displayed when invoked
		On Successful saving the flow should	immediately after the
		reside in the same screen.	screen is loaded).

3.1.12. User Interface ID: Rate Classification—Search Differential Fees
3.1.12.1. Screen Name: Rate Classification—Search Differential Fees

(BPI_CASE_SCR_CM_—003_—011) (See FIG. H-30)

3.1.12.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for		for
Differential		Differential
Factor		Factor
Group Size	Entry Field	Group Size	Entry field for entering Group size Lower limit.
Lower Limit		Lower Limit
Group Size	Entry Field	Group Size	Entry field for entering Group size Upper limit.
Upper Limit		Upper Limit
Differential	Entry Field	Differential	Entry field for entering Differential Factor
Factor		Factor
Effective Date	Entry Field	Effective Date	To choose the date required by calendar or
			entering
Applicable For	Radio	Applicable	To Select a Applicable For (Whether New
		For	Business Only or New Business or Renewal)
Group Size	Radio	Group Size	To Select a Group Size Criteria (Whether
Criteria		Criteria	Eligible Employee or Enrolled Employee)
Search	HTML	Search	Button to search the data based on inputs and
	Button		displays the results in HTML table below
Table	HTML table	Table	Shows the all the data in the column format
View/Delete	Button	View/Delete	Button to view the selected record data
	(HTML
	Button)
Check Index	Radio	Check Index	To check the items for modify, view and
	Button		deletion
Modify	Button	Modify	To edit the data against the row selected for
	(HTML		edition
	Button)
Cancel	Button	Cancel	To reset the entries made in all the fields
	(HTML
	Button)

3.1.12.3. Front End Validations


•	Element Name	Action/Validation Details	Message

1	Group Size Lower	Group Size Lower Limit should accept	“Group Size Lower limit -
	Limit	numeric.	Accepts numeric values
			only (1-999)
2	Group Size Upper	Group Size Upper Limit should accept	“Group Size Upper Limit -
	Limit	numeric	Accepts numeric values
			only (1-999)”
			“Kindly enter Group Size
			Upper limit greater than
			Lower Limit”
3	Differential Factor	Differential Factor should accept	“Differential Factor -
		numeric.[[.]]	Accepts numeric values
			only.”
4	Effective Date	Effective Date should be selected from	“Effective Date -Accepts
		Calendar or entered	the format in
		For valid Date Format Refer	MM/DD/YYYY”
		BPI_CAS_FSD_Common
5	Search	Should function with Enter Key Cursor	On click of Search button
		Positioned on the “Search” button or	checks for the above
		Mouse Click.	mentioned validations
		All the entries are valid. It fetches the
		records from repository based on inputs
		and displays the records in the table
		below. Else throws error dialog box.
6	Table	Should have column header and each
		subsequent row should be identified by
		alternate color combinations. I.e. first
		row should have color ‘x’ and the next
		row should have color ‘y’. The next row
		should have color ‘x’ again and so on. The
		size of the text inside any cell should be
		wrapped if the text becomes too long.
7	View/Delete	Should function with Enter Key Cursor	“! Select any one of the
		Positioned on the “View/Delete” button	record”
		or on Mouse Click.
		If the user clicks on the view button
		without checking any of the view radio
		button should throw error message.
		Success: View the current row from the
		table.
8	Modify	Should function with Enter Key Cursor	“! Select any one of the
		Positioned on the “Modify” button or on	record”
		Mouse Click.
		On clicking the modify button the row is
		edited and the data should be populated.
9	Cancel	Should reset to the previous state on
		clicking the cancel button

3.1.13. User Interface ID: Rate Classification—View Differential Fees
3.1.13.1. Screen Name: Rate Classification—View Differential Fees

(BPI_CAS_SCR_CM_—003_—0012)(See FIG. H-31)

3.1.13.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
rate		rate
Classification		Classification
for		for
Differential		Differential
Factor		Factor
Group Size	Text Field	Group Size	To Display Group size Lower limit.
Lower Limit		Lower Limit
Group Size	Text Field	Group Size	To Display Group size Upper limit.
Upper Limit		Upper Limit
Differential	Text Field	Differential	To Display Differential Factor
Factor		Factor
Effective Date	Text Field	Effective Date	To Display Effective date
Applicable For	Text Field	Applicable	To Display Applicable For (Whether New
		For	Business Only or New Business or Renewal)
Group Size	Text Field	Group Size	To Display Group Size Criteria (Whether
Criteria		Criteria	Eligible Employee or Enrolled Employee)
New	Button	New	To go to Differential rate screen.
Differential	(HTML	Differential
Rate	Button)	Rate
Delete	Button	Delete	To delete the current Differential fee
	(HTML
	Button)

3.1.13.3. Front End Validations


	Element
•	Name	Action/Validation Details	Message

1	Delete	Should function with Enter Key Cursor	“Do you
		Positioned on the “Delete” button or on	want to
		Mouse Click.	delete the
		If the user clicks on the delete button	selected
		throw message box.	record?”
		Success: Deletes the row from the data
		base

2	New	Should go to the agent fees screen
	Differential	clicking the New Differential Fees button
	Fees

3.1.14. Screen Flow

- (See FIG. H-32)

Benefit Partners Inc

Process Specification

1. Introduction

1.1. Purpose
This purpose of this document is to identify the process associated with the business use case Create ZIP. This document is the amendment of BPI_CAS_FSD_CM_—04(Version 1.0).
1.2. Business Use Case Specification Reference

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background
This process describes the Use Case “Create ZIP”. Standard ZIP is loaded into the system. Refer the document reference no. BPI_CAS_FSC_EC for process of loading ZIP Code. Also for the specific ZIP Codes the corresponding service areas are loaded. The state is divided into several service areas based on the number of counties and their population. In the state of California there are presently 6 service areas. The Rate is based on the service area where the employees are residing.
2.2. Process Description & Flow
2.2.1. Zip Code Search

- The Screen described below has two features provided:
- Zip code search feature is by which the user can search for zip based on any of the selection criteria. Search for zip is based on City name, County name or a Valid Zip code. When user enters the search value, search results are displayed on a table format.
- There is also provision for canceling the search value. Numbers of records fetched are also displayed on the screen.
- There is also a feature to print the records fetched. A separate page is invoked on clicking the printer icon. The print page has the fetched records with print button. Clicking on which will invoke the printer dialog.
- User can view records in Normal as well as Expanded mode. Expanded mode can be invoked by clicking the gif in the table header.

2.2.2. Zip Distance

- Zip Distance feature is by which user can get the distance of the zip codes entered. Zip distance is calculated based on the geographical distribution of the area by its latitudinal & longitudinal position. The result is displayed in miles.
- The user interface for Zip is provided below. The two screenshots is the same screen shown to describe these two features.

2.2.3. Process Flow Diagrams

(See FIG. H-33)

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


Screen ID (SID)	Screen Name	Corresponding HTML File Name

zip.zipsearch	Zip Search	/bpi/cas/carrier/zip/ZipSearch.jsp

3.1.2. User Interface ID: Zip Search
3.1.2.1. Screen Name: Zip Search (BPI_CAS_SCR_CM_—004_—001) (See FIG. H-34)

- Zip Distance: BPI_CAS_SCR_CM_—004_—002 (See FIG. H-35)

3.1.2.2. Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Main Header	Text	Main Header	To give heading for the screen being navigated
Searching		Searching
ZIPS		ZIPS
City	Text	City	Provide Text
City	Radio	City	To choose a city for search
County	Text	County	Provide Text
County	Radio	County	To choose a county for search
ZIP	Text	ZIP	Provide Text
ZIP	Radio	ZIP	To choose a zip for search
Search Value	Entry Field	Search Value	Entering the Zip search value
Search	HTML	Search	Button to be invoked for displaying the search
	Button		results based on the Entered text in Search
			Value.
Cancel	HTML	Cancel	To clear the entered field.
	Button
ZIP
1	Text	ZIP	1	Provide Text
ZIP
1	Entry Field	ZIP	1	Entering the Zip1 value
ZIP
2	Text	ZIP	2	Provide Text
ZIP
2	Entry Field	ZIP	2	Entering the Zip2 value
Go	HTML	Go	Button to be invoked for displaying the distance
	Button		between the two zip codes entered in miles.
Cancel	HTML	Cancel	To clear the entered field.
	Button

3.1.2.3. Front End Validations

- Validation Details
  - This section provides the front-end screen validations along with the


#	Element Name	Action/Validation Details	Message

1.	City	Max length of the search field is set.
2.	County	Max length of the search field is set.
3.	Zip	Max length of the search field is set.
4.	Search	On click of the button, records are	“Search Value - Is
		fetched from repository based on	required.”
		selection criteria.	“City - Accepts alphabetic
			characters only.”
			“County - Accepts
			alphabetic characters only.”
			“ZIP - Accepts exactly 5
			digit numbers only.”
5.	Cancel	On click of this button, entry field is
		cleared.
6.	Go	On click of the button, distance between	“Zip1 - Is required.”
		the two zip codes is displayed.	“Zip2 - Is required.”
			“ZIP - Accepts exactly 5
			digit numbers only.”
7.	Cancel	On click of this button, entry field is
		cleared.

3.2. Screen Flow
This section describes the screen flow for the group enrollment process. (See FIG. H-36)

Benefit Partners Inc

Process Specification

Cobra Enrollment

1. Introduction

1.1 Purpose
The purpose of this document is to describe the process of COBRA Enrollment. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.
1.2 Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_EN	Enrollment
	BPI_SCOPE_EN_OO2	COBRA Enrollment
	BPI_SCOPE_EN_OO1	Group Enrollment

1.3 Document Reference


Document ID	Document Name

BPI_CAS_FSD_EN	Functional Specification Document-
	Enrollment
BPI_CAS_FSD_EN_001	Process Flow—New Business Enrollment
BPI_CAS_FSD_EN_002	Process Flow—Enrollment Changes/Add-On
BPI_CAS_FSD_EN_003	Process Flow—COBRA Enrollment/Changes
BPI_CAS_FSD_EN_005	Process Flow—Termination/Reinstatement

1.4 Definitions, Acronyms & Abbreviations


	Term	Explanation

2 Process Identification

2.1 Background
California State laws and federal laws govern COBRA Rules based on whether it is Cal COBRA or Federal COBRA.
The decision whether the Group is a CAL COBRA or FEDERAL COBRA would be based on the Group size or the number of employee in the group. If the number of the employee were greater than or equal to 20 then it would be FEDERAL COBRA. If the group size were less than 20 employees then it would be Cal COBRA. This needs to be entered at the time of group enrollment. Based on applications received for group.
2.2 Process Description
The objective of the COBRA Enrollment is to:

- New Business COBRA Enrollment
- Existing member converting to COBRA because of the qualifying rules.
- Add on for COBRA members
- Changes to COBRA members
- Requalification and Open enrollment and Open enrollment for the COBRA members.

2.3 Process Flow
Process for COBRA is based on the type of COBRA enrollment

- New Business COBRA Enrollment
- Existing members converting into COBRA after termination

Process Flow for New Buiness COBRA Enrollment
1) Search for the group and select the SEG Group or Alternate Group with whom the COBRA members are to be added.
2) Specify if the Member is enrolling as COBRA member as an individual or with dependent
3) If the member is enrolling with dependent then specify the number of dependent
4) Enter member general information, which includes the personal information and address information.
5) Add the dependent/dependents if the option selected is with dependent and enter the dependent/dependents information.
6) Enter COBRA information for the member and dependents as applicable.
7) Select the Line of coverage options for the member and dependent as applicable.
8) List COBRA member summary and select the Benefit Level (Carrier Selection) based on the ZIP code and Service area provided.
9) Show missing information for the COBRA enrollment.
10) Enroll/Decline the COBRA enrollment (based on ACL).
Process Flow for new Business COBRA (See FIG. I-1)
Process Flow for existing Member COBRA Enrollment
1) Search for the group and employee who need to be converted into the COBRA members.
2) Check the term status and reasons for the Employee/dependent.
3) Process COBRA Eligibility checks. This checks the eligibility of the Employee if termed and the reasons for the term, which form the basic for the qualifying event. Of if the employee is not termed and the dependent/dependents are termed their reasons for terms and qualifying event. If none qualify then COBRA enrollment is declined based on ACL. If either qualifies then the COBRA enrollment information is shown with option to select line of coverage for the termed members.
4) Identify the primary member based on the criteria.

- Employee is also termed and opts for COBRA then the employee becomes the primary member.
- If spouse is termed with children and spouse opts for COBRA coverage then spouse becomes the primary member
- If Children/child is termed and opts for COBRA coverage the oldest child becomes the primary member.

5) Check if the Plan is available in the Primary members ZIP/Service area. If so then the member should select the same plan as was before. If not, pend and send quote for plans available and then allow the member to select the plan that is available in the new ZIP service area.
6) Dependents should have the same plan as well. However they can waive any plan. (Refer the business rules for COBRA)
7) Show Summary and missing information.
8) Enroll/Decline member/members as COBRA group.
Process Flow for Existing COBRA conversion (See FIG. I-2)

3 User Interface

3.1 User Interface Screens
3.1.1 Screen ID's


Screen ID (SID)	Screen Name	Corresponding HTML File Name

bpi.enrollment.cobra.new.	Group Search	/bpi/cas/enrollment/cobra/new/groupsearch/GroupSearch.jsp
search
bpi.enrollment.cobra.new.	Group Information	/bpi/cas/enrollment/cobra/new/generalinfo/GeneralInfo.jsp
general
bpi.enrollment.cobra.new.	Billing Info	/bpi/cas/enrollment/cobra/new/billinginfo/BillingInfo.jsp
billing
bpi.enrollment.cobra.new.	Coverage Info	/bpi/cas/enrollment/cobra/new/coverageinfo/CoverageInfo.jsp
coverage
bpi.enrollment.cobra.new.	Dependent Information	/bpi/cas/enrollment/cobra/new/dependentinfo/DependentInfo.jsp
dependent
bpi.enrollment.cobra.new.	CobraSearch	/bpi/cas/enrollment/cobra/new/cobrasearch/CobraSearch.jsp
searchcobra
bpi.enrollment.cobra.new.	Missing Information	/bpi/cas/enrollment/cobra/new/missinginfo/MissingInfo.jsp
missing
bpi.enrollment.cobra.new.	Group Inactivate	/bpi/cas/enrollment/cobra/new/groupinactivate/GroupInactivate.jsp
inactivate
bpi.enrollment.cobra.new.	Confirmation	/bpi/cas/enrollment/cobra/new/confirmation/Confirmation.jsp
confirmation
bpi.enrollment.cobra.existing.	Employee Search	/bpi/cas/enrollment/cobra/existing/employeesearch/EmployeeSearch.jsp
employeesearch
bpi.enrollment.cobra.existing.	Member Process	/bpi/cas/enrollment/cobra/existing/memberprocess/MemberProcess.jsp
memberprocess
bpi.enrollment.cobra.existing.	Existing General	/bpi/cas/enrollment/cobra/existing/generalinfo/GeneralInfo.jsp
general	Information
bpi.enrollment.cobra.existing.	Existing Billing Info	/bpi/cas/enrollment/cobra/existing/billinginfo/BillingInfo.jsp
billing
bpi.enrollment.cobra.existing.	Existing Coverage Info	/bpi/cas/enrollment/cobra/existing/coverageinfo/CoverageInfo.jsp
coverage
bpi.enrollment.cobra.existing.	Existing Dependent Info	/bpi/cas/enrollment/cobra/existing/dependentinfo/DependentInfo.jsp
dependent
bpi.enrollment.cobra.existing.	Existing Cobra Search	/bpi/cas/enrollment/cobra/existing/cobrasearch/CobraSearch.jsp
searchcobra
bpi.enrollment.cobra.existing.	Existing Missing Info	/bpi/cas/enrollment/cobra/existing/missinginfo/MissingInfo.jsp
missing
bpi.enrollment.cobra.existing.	Existing confirmation	/bpi/cas/enrollment/cobra/existing/confirmation/Confirmation.jsp
confirmation
bpi.enrollment.cobra.existing.	Existing Inactivate	/bpi/cas/enrollment/cobra/existing/groupinactivate/GroupInactivate.jsp
inactivate

3.1.2 User Interface Id: BPI_SCR_EN_—002_—001—Group Search
3.1.2.1 Screen Name: Group Search (See FIG. I-3)
3.1.2.2 Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Group Id	Text	Group Id	To provide text
Group Id	Entry Field	Group Id	Enter the group Id for Search
Group Name	Text	Group Name	To provide text
Group Name	Entry Field	Group Name	To enter group name for search
Group Phone	Text	Group Phone	To provide text
Group phone	Entry field	Group phone	Enter group phone number for search
Search	HTML	Search	Button for searching the Group
	button
Table	HTML	Table	Table to display group information
	Table
Select Group	Radio	Select Group	Button to select the group for Attaching the
	Button		COBRA members
Single	Radio	Single	To choose if the COBRA Member is enrolling
Member	Button	Member	as a single member
Member With	Radio	Member With	To choose if COBRA Member is enrolling as a
dependent	Button	dependent	member with dependent
Dependent	Entry Field	Dependent	Field to enter the number of dependent
Member		Member	members being added to the member as
Count		Count	COBRA

3.1.2.3 Screen Validations


Element Name	Action/Validation Details	Message

Group ID	Enter valid group ID only	Error Dialog Box:
		“Please enter valid group ID”
Group Name	Enter the group name	None
Group Phone	Enter valid phone number for the group	Error Dialog Box:
		“Please enter valid phone number”
Search	On click of the search button should list	None
	the groups or a single group based on the
	search criteria.
Select Group	If the groups are multiple then the radio	Error Dialog Box:
	button option to select the specific group	“Please select a group with whom
	should be provided.	you would like to add COBRA
	If the Group available is only one then it	member”
	should be selected by default.
Select member Only	There should be option either to select	None
or Member with	single member or member with
dependent	dependent.
Dependent Member	If the option selected is member with	Error Dialog Box:
Count	dependent specify the number of	“Please enter the number of
	dependents.	dependent as the option selected is
		member with dependent.”

3.1.2.4 Help Menu

- New Business enrollment can bring in the members as COBRA. This screen is used for adding the COBRA members to the new business groups based on the selection of the group.


Element Name	Purpose	Valid Values

Search	To search for the	Should list single or multiple
	Group	groups based on the search
		criteria
Single Member or	This is to specify if	None
member with	the member is
dependent	availing COBRA
	benefits
	individually or with
	dependents
Dependent Member	Specify the count	None
Count	of the dependent
	members to be
	enrolled with the
	primary member as
	COBRA.

3.1.3 User Interface Id: BPI_SCR_EN_—002_—002—Group Information
3.1.3.1 Screen Name: Group Information (See FIG. I-4)
3.1.3.2


Element	Element
Name	Type	Label	Purpose

Employer	Text	Employer	To provide text
Information		Information
Date PM	Text	Date PM	To provide text
Date PM	Entry field	Date PM	Provide entry for Date Postmarked
Date Recd	Text	Date Recd	To provide text
Date Recd	Entry field	Date Recd	Provide entry for Date Received
Salutation	Text	Salutation	To provide text
Salutation	Drop Down	Salutation	List the Salutation MR., MRS., MS.
	List
First name	Text	First name	To provide text
First name	Entry field	First name	Provide entry field for the First name
Last name	Text	Last name	To provide text
Last Name	Entry Field	Last Name	Provide entry field for the Last name
MI	Text	MI	To provide text
MI	Entry Field	MI	Enter the middle initial
Suffix	Text	Suffix	To provide text
Suffix	List	Suffix	List the suffix for selection
Social	Text	Social Security	To provide text
Security		Number
Number
SSN	Entry field	SSN	Enter the SSN number
Unique ID	Text	Unique ID	To provide text
Unique ID	Entry field	Unique ID	Show the unique ID generated
	(Uneditable).
Auto Generate	HTML	Auto Generate	Button to generate Unique Id if SSN is not
	button		provided
Date of Birth	Text	Date of Birth	To provide text
Date of Birth	Calendar	Date of Birth	Calendar to select the birth date. Should also
			allow to enter date of birth as
			MM/DD/YYYY
Gender	Text	Gender	To provide text
Gender	List	Gender	List whether Male or Female
Physical Main	Text	Physical Main	To provide text
Address		Address
Street Address	Entry field	Street Address	Enter the street address
Suite/Apts.	Text	Suite/Apts.	To provide text
Suite/Apts.	Entry Field	Suite/Apts.	Enter the suite/apts. number
City	Text	City	To provide text
City	Entry Field	City	Enter the city name
State	Text	State	To provide text
State	Drop Down	State	List all the state in US
	List
ZIP	Text	ZIP	To provide text
ZIP	Entry Field	ZIP	Enter zip code
Service Area	Text	Service Area	To provide text
Service Area	Entry Field	Service Area	Shows the Service Area based on the ZIP
	(uneditable)		code typed
	or list		Show list if the ZIP has multiple service area
County	Text	County	To provide text
County	Entry Field	County	Display the county name based on the zip and
	(uneditable)		service area selected
Preferred	Text	Preferred mode	To provide text
mode of		of
correspondence		correspondence
Mode of	Drop Down	Mode of	List the mod of communication, USPS, FAX,
correspondence	List	correspondence	or email/web. Phone is not allowed.
Phone number	Text	Phone number	To provide text
Phone	Entry Field	Phone	To enter phone number
Home FAX	Text	Home FAX No.	To provide text
No.
FAX	Entry Field	FAX	To enter FAX number
Extension	Entry Field	Extension	To enter extension number
E-Mail	Text	E-Mail Address	To provide text
Address
E-mail	Entry field	E-mail Address	Enter email address
Address
Mailing	Text	Mailing	To provide text
Address		Address
Street Address	Text	Street Address	To provide text
Street Address	Text	Street Address	Enter the street address
Suite/Apts./	Text	Suite/Apts./	To provide text
PO Box #		PO Box #
Suite/Apts./	Entry Field	Suite/Apts./	Enter the suite/apts. number
PO Box #		PO Box #
City	Text	City	To provide text
City	Entry Field	City	Enter the city name
State	Text	State	To provide text
State	Drop Down	State	List all the state in US
	List
ZIP	Text	ZIP	To provide text
ZIP	Entry Field	ZIP	Enter zip code
Cancel	HTML Reset	Cancel	To cancel the operation and reset for new
	Button		selection
Continue	HTML	Continue	To save the data gathered in this screen and
	Submit		continue to the next screen
	Button		BPI_CAS_SCR_EN_002_003

3.1.3.3 Screen Validations


Element Name	Action/Validation Details	Message

Salutation	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
First Name	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Last name	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
MI	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Suffix	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Birth date	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
SSN	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Unique Id	Unique	9 digit ID should be generated	None
	if the SSN number is not provided.
	This unique ID should not be repeated
	for any employee. Also unique Id
	should be generated on change mode.
	Number should start with 999 999
	000 and start descending e.g.
	999 998 999
	999 998 998 and so on
Street Address	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Suite/Apts.	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
City	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
State	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
ZIP	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Service Area	Should pick up the service area based	None
	on the Zip code number typed in the
	above ZIP entry field from the
	database
	If there are multiple service area then
	it should list the service area for
	picking up the service area.
County	Show the county name based on the	none
	ZIP code and Service area
	combination
Mode of	List mode of communications like	Error Dialog Box:
Communication	USPS, FAX, Email/Web and others.	“Please choose the mode of
	If the option selected is Email then the	communication”
	Email address field cannot be blank.
	Default Option should be
	-- choose one --.
	If none is selected should throw error
	message.
Phone	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Extension	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
FAX	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Extension	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
E-mail Address	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Gender	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Street Address	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Suite/Apts.	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
City	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
State	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
ZIP	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Cancel	Reset Button	To reset the value in the
		Entry Field to its previous
		state as was on loading page
Continue	Should function with Enter Key	Error Dialog Box:
	Cursor Positioned on the “Continue”	“The value entered for the
	button or on Mouse Click.	FIELD NAME is erroneous.
	Check for all the validation on the	Please enter valid values.”
	fields	“Please choose the mode of
	If any data type error throw error	communication”
	message.
	Allows blank entry
	On Success Leads to the next page
	for filling further information on the
	employee.
	Screen
	BPI_CAS_SCR_EN_002_003

3.1.3.4 Help Menu

- This screen is used for filling up the primary COBRA member information. The information contained here is the personal information and the address information. The ZIP and the service are provided here governs the rate calculation for the COBRA member.


Element Name	Purpose	Valid Values

Continue	On clicking the	None
	button leads to
	the next page for
	filling up the
	dependent
	information if
	applicable of
	member
	coverage
	information

3.1.4 User Interface Id: BPI_SCR_EN_—002_—003—Dependent Information
3.1.4.1 Screen Name: Dependent Information (See FIG. I-5)
3.1.4.2 Element Name, Element Type, Label & Purpose


Element	Element
Name	Type	Label	Purpose

Salutation	Text	Salutation	To provide text
Salutation	List	Salutation	List type of salutation
Dependent	Text	Dependent	To provide text
First name		First name
First Name	Entry Field	First Name	Enter the first name
Dependent	Text	Dependent	To provide text
Last name		Last name
Last name	Entry field	Last name	Enter the last name
MI	Text	MI	To provide text
MI	Entry Field	MI	Enter the middle initial
Suffix	Text	Suffix	To provide text
Suffix	Entry Field	Suffix	Enter the suffix
Dependent	Text	Dependent	To provide text
Social		Social
Security		Security
Number		Number
SSN	Text	SSN	To provide text
SSN	Entry field	SSN	Enter the SSN number
Unique ID	Text	Unique ID	To provide text
Unique ID	Entry field	Unique ID	Show the unique ID generated
	(uneditable).
Gender	Text	Gender	To provide text
Gender	List	Gender	List the gender
Relationship	Text	Relationship	To provide text
Relationship	List	Relationship	List all types of relationship like spouse,
			domestic partner, child, step child others
Birth Date	Text	Birth Date	To provide text
Birth Date	Calendar	Birth Date	Calendar to choose the birth date
Add	HTML	Add	To add the above dependent Information to the
Dependent	Submit	Dependent	html table below
	Button
Table	HTML	Table	Table for adding up the dependent information
	Table
Delete	Button	Delete	To delete the items checked for deletion
	(HTML
	Button)
Check All	Text Link	Check All	To check all the check boxes in the table
Clear All	Text Link	Clear All	To un check all the check boxes checked in the
			table
Delete	Check box	Delete	To check the items for deletion
Edit	Button	Edit	To edit the items against the row selected for
	(HTML		edition
	Button)
Disabled	Text	Disabled	To provide text
Disabled	Radio	Disabled	Temporary or permanent disability (Can be
Radio Button	Button	Radio Button	only one or the other) Default NONE.
Domestic	Text	Domestic	To provide text
Partner		Partner
Domestic	Check box	Domestic	Is Form available if so check.
Partner		Partner
Legal	Text	Legal	To provide text
Guardian		Guardian
Legal	Check box	Legal	Is Form available if so check.
Guardian		Guardian
Signature	Text	Signature	To provide text
Signature	Check box	Signature	Is signature available if check
Continue	HTML	Continue	On clicking the continue button save the
	Button		information
Cancel	HTML reset	Cancel	To reset to the state as was before loading the
	Button		page

3.1.4.3 Screen Validations


Element Name	Action/Validation Details	Message

First Name	Refer BPI_CAS_FSD_Common	Refer BPI_CAS_FSD_Common
Last name	Refer BPI_CAS_FSD_Common	Refer BPI_CAS_FSD_Common
MI	Refer BPI_CAS_FSD_Common	Refer BPI_CAS_FSD_Common
Suffix	Refer BPI_CAS_FSD_Common	Refer BPI_CAS_FSD_Common
SSN Number	Refer BPI_CAS_FSD_Common	Refer BPI_CAS_FSD_Common
Unique Id	Unique	9 digit ID should be generated if	None
	the SSN number is not provided. This
	unique ID should not be repeated for any
	employee. Also unique Id should be
	generated on change mode. Number
	should start with 999 999 000 and start
	descending e.g.
	999 998 999
	999 998 998 and so on
Birth Date	Refer BPI_CAS_FSD_Common	Refer BPI_CAS_FSD_Common
Gender	Refer BPI_CAS_FSD_Common	Refer BPI_CAS_FSD_Common
Relationship	Default option should be	Error Dialog Box:
	-- Choose one --. If none is selected	“Please select the relationship of the
	throw error message	dependent with the employee”
Add Dependent	On clicking the Add Dependent the	Error Dialog Box:
	dependent information gets filled in the	“The value entered in the FIELD NAME is
	HTML Table. All validation checks are	incorrect. Please enter valid entries”
	performed on the entry field before
	adding the dependent.
Table	Should have column header and each	None
	subsequent row should be identified by
	alternate color combinations. i.e. First
	row should have color ‘x’ and the next
	row should have color ‘y’. The next row
	should have color ‘x’ again and so on. The
	size of any text inside any cell should be
	wrapped if the text becomes too long.
	Note: The values inside the table on
	create mode would be blank. If this
	screen is reached on edit/change mode
	then the values inside the table would be
	green in color if retrieved from the
	database. If temporarily added then it
	would be red in color.
Delete	Should function with Enter Key Cursor	Error Dialog Box:
	Positioned on the “Delete” button or on	“Please choose the row or rows to be
	Mouse Click.	deleted.”
	Delete Button should work on multiple
	deletes based on the check box or boxes
	selected. If the user clicks on the delete
	button without checking any of the delete
	check box should throw error message.
	Success: Deletes the row or rows from
	the HTML Table (temporary storage)
Check All	On clicking the “Check All” link should	On clicking the “Check All” link
	check all the check boxes in the HTML	should check all the check boxes in the
	table.	HTML table.
Clear All	On clicking the “Clear All” link should	On clicking the “Clear All” link should
	uncheck all the checked check boxes in	uncheck all the checked check boxes in
	the HTML table.	the HTML table.
Delete	Check box option with default	Check box option with default
	“unchecked”	“unchecked”
Edit	Should function with Enter Key Cursor	On clicking the edit button the row
	Positioned on the “Edit” button or on	edited should be removed from the
	Mouse Click.	HTML table and the data should be
	On clicking the edit button the row edited	populated back on the editable entry
	should be removed from the HTML table	fields.
	and the data should be populated back on
	the editable entry fields.
	On clicking the edit for the data that is
	Green in color (permanent data) the edit
	becomes disabled and the Add button
	becomes Update.
	On clicking edit for the red color data
	(temporary data) the row with the data
	disappears from the table
Domestic Partner	Default is un checked. Allow to check if	None
	applicable
Legal Guardian	Default is un checked. Allow to check if	None
	applicable
Signature	Default is un checked. Allow to check if	None
	applicable
Continue	Should function with Enter Key Cursor	Dialog Box:
	Positioned on the “Continue” button or	“Do you want to add the coverage
	on Mouse Click.	information before continuing” Yes/
	On success should save the data lead to	No
	the next page.
Cancel	Should reset to the state as was before	None
	loading the page.

3.1.4.4 Help Menu

- This screen is used for filling up the dependent COBRA member information. The information contained here is the personal information. If there are multiple ° dependent then you can add the dependent COBRA members here.


Element Name	Purpose	Valid Values

Continue	On clicking the	none
	button leads to
	the next page for
	filling up the
	member
	coverage
	information

3.1.5 User Interface Id: BPI_SCR_EN_—002_—004—Coverage Information
3.1.5.1 Screen Name: Coverage Information (See FIG. I-6)
3.1.5.2 Element Name, Element Type, Label & Purpose


Element
Name	Element Type	Label	Purpose

COBRA	Page sub Header	COBRA qualifying	To provide text
qualifying		Event
Event
Initial	Text	Initial COBRA effective	To provide text
COBRA		date
effective date
Date	Entry field	Date	Enter the initial effective date
COBRA End	Text	COBRA End Date	To provide text
Date
Period	Entry field	Period	Enter the COBRA effective
			period
Reasons for	Text	Reasons for electing	To provide text
electing		COBRA
COBRA
Reasons for	Drop Down List	Reasons for electing	List the reasons for COBRA
electing		COBRA	election
COBRA
Where would	Text	Where would you like	To provide text
you like the		the bills to be sent
bills to be sent
Where would	Check Box	Where would you like	Check if the bill is to be sent to
you like the		the bills to be sent	the group or the member
bills to be sent
Is member	Text	Is member signature	To provide text
signature		verified
verified
Is member	Check box	Is member signature	Check if signature is verified
signature		verified
verified
Line of	HTML Table	Line of Coverage	Table to display the Member
Coverage		Selection Table	names and the Line of coverage
Selection			check boxes for picking the line
Table			of coverage for each COBRA
			members
Coverage	Check Box	Coverage Selection	Check box to select the line of
Selection			coverage
Show	HTML button	Show Coverage Choice	Button to show the coverage
Coverage			choice for each line of coverage
Choice			based on the check box/boxes
			checked.
Continue	HTML Button	Continue	Button to save the data and lead
			to the next screen for showing
			the summary and selection of
			Benefit level offered by carriers
			(Screen
			BPI_CAS_SCR_EN_002_004)

3.1.5.3 Screen Validations


Element Name	Action/Validation Details	Message

Date	Defaults to system date. User can either	Error Dialog Box:
	enter the date or pick the date from the	“Date cannot be future date
	calendar	Please enter past date”
COBRA effective	Defaults to 18 months. Can be changed	None
period	by the user.
Reasons for electing	List the qualifying reasons for COBRA.	None
COBRA
Where would you	Option to bill either the group of the	None
like the bills to be	COBRA member based on the flag
sent	checked
Is member signature	Check if the member signature is verified	None
verified
Line of Coverage	Table to show the Line of coverage	None
Selection Table	against each member for picking the
	option. The Line of coverage displayed is
	based on the line of coverage selected by
	the primary group.
	Note: The table would display the
	Member name in the following priority.
	Employee as primary member
	Spouse as the next member
	Other members would be listed based on
	the age.
Coverage Selection	Check Box to pick any combination of	None
	coverage's for all the member for this
	specific COBRA group
Show Coverage	On click of the Coverage choice system	None
Choice	should identify the coverage choice
	based on the options checked. Whether
	member only, member and spouse tec.
Continue	On clicking the continue button saves the	Dialog Box:
	data and leads to the page	“Are you sure to continue”
	BPI_CAS_SCR_EN_002_005

3.1.5.4 Help Menu

- This screen is used for filling up the COBRA qualifying events and the COBRA tenure for the members. Also there is an option to select the line of coverage opted for the various members.


Element Name	Purpose	Valid Values

Continue	On clicking the	None
	button leads to
	the next page for
	selecting the
	benefit level
	(Carrier)

3.1.6 User Interface Id: BPI_SCR_EN_—002_—006—Summary/Missing Information
3.1.6.1 Screen Name: Missing Info (See FIG. I-7)
3.1.6.2 Element Name, Element Type & Purpose


Element
Name	Element Type	Label	Purpose

Member	Text	Member Missing	To provide text
Missing		Information
Information
Employee Tab	Expandable Tree	Employee Tab	Should be able to expand the
			Employee Tab to list the
			Details for the Employee
			Missing and information and
			Also show an expandable tab
			for the Dependent Missing
			Information
Enrollment	Drop Down List	Enrollment Status	List the status of enrollment.
Status			Can be Enroll or Decline
Remarks	Entry Field	Remarks	Remark for the status of
			enrollment
Reasons for	Drop Down List	Reasons for Decline	List the reasons for decline
Decline
Other Reasons	Entry Field	Other Reasons	Any other reasons for decline
			or others
Cancel	HTML Button	Cancel	To reset the operation
Process	HTML Button	Process Enrollment	Process the enrollment and
Enrollment			leads to the enrollment
			confirmation page.
			BPI_CAS_SCR_EN_001_011

3.1.6.3 Screen Validations


Element Name	Action/Validation Details	Message

Enrollment Status	List the status of enrollment. The default	Error Dialog Box:
	option should be --choose one--	“Please choose enrollment
	If the option selected is Decline.	status before continuing.”
	Should list the list box containing
	reasons for the decline.
	If none is selected throw error message.
Remarks	Can accept any character.
Reasons for Decline	List the reasons for the decline. The	Error Dialog Box:
	default option should be --choose one--	“Please choose reasons for
	If none is selected throw error message.	declining before
		continuing.”
Other Reasons	Can accept any character	None
Cancel	Resets to the status as was on loading this	None
	page
Process Enrollment	Should function with Enter Key Cursor	Error Dialog Box:
	Positioned on the “Process Enrollment”	“Please choose enrollment
	button or on Mouse Click.	status before continuing.”
	On success leads to the confirmation	“Please choose reasons for
	page.	declining before
	BPI_CAS_SCR_EN_001_011	continuing.”
	It checks the eligibility rule for the
	COBRA member once again. Process the
	post enrollment activity like sending
	emails, welcome letter. First month
	invoices and email alert to GMS, Sales
	and finance.

3.1.7 User Interface Id: BPCSCR_EN_—002_—007—Existing COBRA Employee Search
3.1.7.1 Screen Name: Employee Search (See FIG. I-8)
3.1.7.2 Element Name, Element Type & Purpose


Element
Name	Element Type	Label	Purpose

Group ID	Text	Group ID	To provide text
Group Id	Entry field	Group Id	Enter the group id for searching
			the employee
Employee ID	Text	Employee ID	To provide text
Employee ID	Entry field	Employee ID	Enter the Employee ID for
			searching the employee
Employee	Text	Employee SSN	To provide text
SSN
Employee	Entry field	Employee SSN	Enter the Employee SSN for
SSN			searching the employee
Phone number	Text	Phone number	To provide text
Phone number	Entry field	Phone number	Enter the Employee Phone
			number for searching the
			employee
List Employee	HTML Tree	List Employee	Tree to List the Employee and
			their dependent
Employee	HTML Table	Employee Table	Table to list employee
Table			information and status
Dependent	HTML table	Dependent Table	Table to list dependent
Table			information and status
Process	HTML button	Process COBRA	Button to check the COBRA
COBRA			eligibility and take to the next
			page
			BPI_CAS_SCR_EN_002_008 if
			eligible. If not the show the same
			page.

3.1.7.3 Screen Validations


Element Name	Action/Validation Details	Message

Group Id	Enter the Group ID or pick the group ID	Group ID can be tnered
	based on the Group search	along with any other valid
		fields for the employee
		provided below.
Employee ID	Enter the employee Id or pick the	Note: At least one of the
	employee based on the employee search	field with the search criteria
	window.	for the employee must be
		entered
Employee SSN	Enter the employee SSN or pick the	Note: At least one of the
	employee based on the employee search	field with the search criteria
	window.	for the employee must be
		entered
Phone number	Enter the employee Phone or pick the	Note: At least one of the
	employee based on the employee search	field with the search criteria
	window.	for the employee must be
		entered
List Employee	Tree to open up if dependent exist for the	None
	employee
Employee Table	List the employee with status and	None
	effective date
Process COBRA	Check the status and term reasons and	Embedded error if non-of
	process the eligibility check for the	the member is termed or not
	existing member to COBRA	qualifies for COBRA.
	Note: It should check the following
	status. Term Status, Term reasons
	Only the member termed all eligible for
	the COBRA. The reasons for term can
	either decline COBRA enrollment or
	define the COBRA period.

3.1.8 User Interface Id: BPI_SCR_EN_—002_—008—Existing COBRA Enrollment
3.1.8.1 Screen Name: COBRA Enrollment (See FIG. I-9)
3.1.8.2 Element Name, Element Type & Purpose


Element
Name	Element Type	Label	Purpose

COBRA	Page sub Header	COBRA qualifying	To provide text
qualifying		Event
Event
Initial	Text	Initial COBRA effective	To provide text
COBRA		date
effective date
Date	Entry field	Date	Enter the initial effective date
COBRA End	Text	COBRA End Date	To provide text
Date
Period	Entry field	Period	Enter the COBRA effective
			period Default to the period
			based on the qualifying event
Reasons for	Text	Reasons for Term	To provide text
Term
Reasons for	Dynamic Text	Reasons for Term	Reasons for Term based on the
Term			term reasons provided
Term Date	Text	Term Date	To provide text
Term Date	Dynamic text	Term Date	Display the term date of the
			member
Where would	Text	Where would you like	To provide text
you like the		the bills to be sent
bills to be sent
Where would	Check Box	Where would you like	Check if the bill is to be sent to
you like the		the bills to be sent	the group or the member
bills to be sent
Is member	Text	Is member signature	To provide text
signature		verified
verified
Is member	Check box	Is member signature	Check if signature is verified
signature		verified
verified
Line of	HTML Table	Line of Coverage	Table to display the Member
Coverage		Selection Table	names and the Line of coverage
Selection			check boxes for picking the line
Table			of coverage for each COBRA
			members
Coverage	Check Box	Coverage Selection	Check box to select the line of
Selection			coverage
Show	HTML button	Show Coverage Choice	Button to show the coverage
Coverage			choice for each line of coverage
Choice			based on the check box/boxes
			checked.
Continue	HTML Button	Continue	Button to save the data and lead
			to the next screen for showing
			the summary and selection of
			Benefit level offered by carriers
			(Screen
			BPI_CAS_SCR_EN_002_009)

3.1.8.3 Screen Validations


Element Name	Action/Validation Details	Message

Date	Default to the date next to the term date.	Error Dialog Box:
	Allow for making changes based on	“Date cannot be prior to the
	authorization	term date. Please enter the
		valid date”
Period	Default to the period based on the	none
	Qualifying events. Allow to change
	based on authorization
Where would you	Check the option for billing, Whether to	none
like the bills to be	the group or the member
sent
Is member signature	Check if signature is verified	none
verified
Line of Coverage	Table to show the Line of coverage	None
Selection Table	against each member for picking the
	option. The Line of coverage displayed is
	based on the line of coverage selected by
	the primary group.
	Note: The table would display the
	Member name in the following priority.
	Employee as primary member
	Spouse as the next member
	Other members would be listed based on
	the age.
Check if member is	This is check if the member is not opting	None
not enrolling for	for the COBRA
COBRA
Coverage Selection	Check Box to pick any combination of	None
	coverage's for all the member for this
	specific COBRA group
Show Coverage	On click of the Coverage choice system	None
Choice	should identify the coverage choice
	based on the options checked. Whether
	member only, member and spouse etc.
Continue	On clicking the continue button saves the	Dialog Box:
	data and leads to the page	“Are you sure to continue”
	BPI_CAS_SCR_EN_002_009

3.1.9 User Interface Id: BPI_SCR_EN_—002_—009—Primary Member Information
3.1.9.1 Screen Name: Primary Member Information (See FIG. I-10)

- Note: This screen is pre filled with the employee information available in the employee master for all the members and the dependents belonging to this employee. Changes can be made to the information as applicable.

3.1.9.2


Element Name	Element Type	Label	Purpose

Main Address	Text	Main Address	To provide text
Street Address	Entry field	Street Address	Enter the street address
Suite/Apts.	Text	Suite/Apts.	To provide text
Suite/Apts.	Entry Field	Suite/Apts.	Enter the suite/apts. number
City	Text	City	To provide text
City	Entry Field	City	Enter the city name
State	Text	State	To provide text
State	Drop Down List	State	List all the state in US
ZIP	Text	ZIP	To provide text
ZIP	Entry Field	ZIP	Enter zip code
Service Area	Text	Service Area	To provide text
Service Area	Entry Field	Service Area	Shows the Service Area based
	(uneditable) or list		on the ZIP code typed
			Show list if the ZIP has
			multiple service area
County	Text	County	To provide text
County	Entry Field	County	Display the county name based
	(uneditable)		on the zip and service area
			selected
Preferred mode	Text	Preferred mode of	To provide text
of		correspondence
correspondence
Mode of	Drop Down List	Mode of	List the mode of
correspondence		correspondence	communication, USPS, FAX,
			email
Home Phone	Text	Home Phone number	To provide text
number
Phone	Entry Field	Phone	To enter phone number
Extension	Entry Field	Extension	To enter extension number
Home FAX No.	Text	Home FAX No.	To provide text
FAX	Entry Field	FAX	To enter FAX number
Extension	Entry Field	Extension	To enter extension number
E-Mail Address	Text	E-Mail Address	To provide text
E-mail Address	Entry field	Email Address	Enter email address
Alternate	Text	Alternate Address	To provide text
Address
Street Address	Text	Street Address	To provide text
Street Address	Entry field	Street Address	Enter the street address
Suite/Apts./	Text	Suite/Apts./PO Box #	To provide text
PO Box #
Suite/Apts./	Entry Field	Suite/Apts./PO Box #	Enter the suite/apts. number
PO Box #
City	Text	City	To provide text
City	Entry Field	City	Enter the city name
State	Text	State	To provide text
State	Drop Down List	State	List all the state in US
ZIP	Text	ZIP	To provide text
ZIP	Entry Field	ZIP	Enter zip code
Cancel	HTML Reset	Cancel	To cancel the operation and
	Button		reset for new selection
Continue	HTML Submit	Continue	To save the data gathered in
	Button		this screen and continue to the
			next screen
			BPI_CAS_SCR_EN_002_010

3.1.9.3 Screen Validations


Element Name	Action/Validation Details	Message

Street Address	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Suite/Apts.	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
City	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
State	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
ZIP	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Service Area	Should pick up the service area based	None
	on the Zip code number typed in the
	above ZIP entry field from the
	database
	If there are multiple service area then
	it should list the service area for
	picking up the service area.
County	Show the county name based on the	none
	ZIP code and Service area
	combination
Mode of	List mode of communications like	Error Dialog Box:
Communication	USPS, FAX, Email and others. If the	“Please choose the mode of
	option selected is Email then the	communication”
	Email address field cannot be blank.
	Default Option should be--
	choose one --.
	If none is selected should throw error
	message.
Phone	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Extension	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
FAX	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Extension	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
E-mail Address	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Street Address	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Suite/Apts.	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
City	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
State	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
ZIP	Refer Document No.	Refer Document No.
	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
Cancel	Reset Button	To reset the value in the
		Entry Field to its previous
		state as was on loading the
		page
Continue	Should function with Enter Key	Error Dialog Box:
	Cursor Positioned on the “Continue”	“The value entered for the
	button or on Mouse Click.	FIELD NAME is erroneous.
	Check for all the validation on the	Please enter valid values._”
	fields	“Please choose the mode of
	If any data type error throw error	communication”
	message.
	Allows blank entry
	On Success Leads to the next page
	for filling further information on the
	employee.
	Screen
	BPI_CAS_SCR_EN_002_010

3.1.10 User Interface Id: BPI_SCR_EN_—002_—010—Existing Coverage Information
3.1.10.1 Screen Name: Coverage Information (See FIG. I-11)
3.1.10.2 Element Name, Element Type, Label & Purpose


Element
Name	Element Type	Label	Purpose

Benefit Level	HTML Table	Benefit Level (carrier	Table to display all the
(carrier		Selection)	Members in the row and The
Selection)			Benefit level selection option in
			the Columns.
Member name	Link	Member name	Provide feature to edit the
			member information by clicking
			this link
Coverage	HTML ROW	Coverage Choice	The row get pre populated based
Choice			on the choice made in the screen
			BPI_CAS_SCR_EN_002_009
Benefit Level	Link	Benefit Level Name	Link to the carrier selection for
Name			the specific line of coverage if
			not available in the ZIP and
			service area of the Primary
			member.
PCP info	Link	PCP info (Available)	Link to edit the PCP info of the
(Available)			individual members as
			applicable.
COBRA	HTML Button	COBRA Summary	Button to click for saving the
Summary			date and navigating to the next
			page for displaying COBRA
			summary/missing information
Cancel	HTML reset	Cancel	Button to reset to the state as
	button		was on loading the page.

3.1.10.3 Screen Validations


Element Name	Action/Validation Details	Message

Benefit Level	Should have column header and each	None
(carrier	subsequent row should be identified by
Selection)	alternate color combinations. I.e. First
	row should have color ‘x’ and the next
	row should have color ‘y’. The next row
	should have color ‘x’ again and so on. The
	size of any text inside any cell should be
	wrapped if the text becomes too long.
	The Header and the Left Column should
	be distinguishable.
Member name	This is a link to edit the member	None
	information when on change or edit
	mode.
PCP Info	This is a link to edit the PCP information	None
	for the specific member. If PCP
	information is not available then on
	clicking the link it allows to fill in the
	PCP information for the specific line of
	coverage.
Coverage	Displays the dynamic text based on the	None
Choice	choices checked in the previous screen
	BPI_CAS_SCR_EN_002_004
Benefit Level	Default benefit level would that the	None
Selection	employee selected when the status was
	enrolled.
	On clicking the Link show a minimized
	window with option to select the benefit
	level for the specific line of coverage.
	Note the line of coverage is displayed
	based on the Group options (i.e. only if
	the group has selected the line of
	coverage)
	Also the benefit level (carrier) displayed
	is based on the ZIP code/Service area of
	the primary COBRA member.
	Only if the prior Benefit level is not
	available in the current ZIP/service are
	of the primary member this is allowed to
	be changed.
COBRA	On clicking the COBRA Summary	Dialog Box:
Summary	button save the content of this page into	“Are you
	the repository and leads to the COBRA	sure you
	summary page to display the COBRA	would like
	missing information. Screen	to continue”
	BPI_CAS_SCR_EN_002_006
	This also does all the COBRA eligibility
	checks prior to the display of summary
	Page
Cancel	Resets to the state as was on loading the	none
	page.

Note: the rest of the flow is common for both new Business COBRA and the Existing member conversion to COBRA.
Screen BPI_CAS_SCR_EN_—006 followed by COBRA enrollment.
3.2 Screen Flow:
Screen Flow Diagram for COBRA Enrollment (See FIG. I-12)

4 Business Rule Mapping


	Activity	Rules

	New Business COBRA (NB brings	Need to know initial COBRA effective date
	in COBRA)	Need to have system calculate COBRA end date (18 mo, 36 mo, or
		other) based on Term Reason (Qualifying events)
		For system to do this we need to have the following data captured
		during the New Business COBRA Enrollment
		a) Initial Effective date
		b) Qualifying events
	COBRA coverage	COBRA coverage has no lapse of time from the date of term &
		COBRA enrollment
		Exception: Death
		Main subscribers coverage is terminated date of death and not the
		end of the month: qualified beneficiaries (i.e. spouse/child)
		effective date of COBRA is the day after the members death
		Note: Since the COBRA coverage has no lapse of time it should be
		basically effective from the day following the term date what ever
		be the reasons.
		Normal terms are always done on the end of the Month.
		Death is done on the day of the death.
	COBRA Election	60 days to elect COBRA coverage from the time of COBRA
		notification letter.
		60 days is based off the;
		Date that we are notified of the termination (Postmark date for
		termination)
		OR
		The termination date
		WHICHEVER IS LATER. The decision is to be made based on
		manual review by GMS personnel.
	COBRA Election for Federal	If a FED COBRA group, we need to include an additional 14 days
	COBRA	from termination notification date because FED Employers have 14
		days to notify their employees of their rights after which they notify
		the plan administrator/Pac Advantage). The decision is to be made
		based on manual review by GMS personnel.
	COBRA Premium Dues	COBRA members initial premium (all premiums from effective
		date to current) must be made/mailed/postmarked within 45 days
		from the COBRA election date (the date the application is
		postmarked)
		If payment is not MADE within this time frame, the COBRA
		coverage is termed flat (effective date). Any partial premium
		payments made will be reimbursed.
		Provide over ride for 45^thday rule (ACL)
		(This override needs to be available upon creating the COBRA)
	COBRA Employee governed by	If main Employer group goes into possible term status or is termed,
	Employer (Groups)	the COBRA will need to be notified and put in same status.
		Employee will have the same coverage type, carrier & co-pay as
		when termed (continue with exact coverage as before)
		Cannot add dependents that were not previously covered (until o/e
		or qualifying event)
	Benefit Levels	Benefit level cannot change. Optional benefits and medical offered
		by the group is not mandatory [Line of Coverage]
	Possible extension of COBRA	Social Security disability - coverage extended to a total of 29 month
	coverage	(11 mo. Extension) (all other term reasons apply)
		The main subscriber does not have to elect to extend the coverage
		for himself, just his dependents can elect to take the extension
		Age 60 prior to loss of employment & worked for Employer for 5
		consecutive years - coverage extended until the Employee turns age
		65 (all other term reasons apply)
		The main subscriber does not have to elect to extend the coverage
		for himself, just his dependents can elect to take the extension
		Also there should be a facility to grant COBRA extension if
		applicable based on authority

Qualifying Events	Qualifying Beneficiaries	Continuation period

TERMINATION_OF_EMPLOYMENT	Employee, Spouse and Children	18
REDUCTION_OF_WORK_HOURS	Employee, Spouse and Children	18
CAN_NO_LONGER_AFFORD_COVERAGE	Employee, Spouse and Children	18
OBTAINED_COVERAGE_ELSE_WHERE	Employee, Spouse and Children	18
DEATH	Spouse and Children	36
ENTITLED_TO_MEDICARE	Employee, Spouse and Children	36
FRAUD_OR_MISREPRESENTATION	Employee, Spouse and Children	36
DPND_OBTAINED_COVERAGE_ELSEWHERE	Employee, Spouse and Children	18
DIVORCE_OR_LEGAL_SEPARATION	Employee, Spouse and Children	36
EMPLOYEE_CANNOT_AFFORD_SPOUSE_COVERAGE	Spouse		36
DPND_DEATH	None		18
DPND_ENTITLED_TO_MEDICARE	Dependent Spouse and Children	36
DPND_FRAUD_OR_MISREPRESENTATION	None		36
OVER_AGE_23	Dependent Child	18
NO_LONGER_AN_ELIGIBLE_DEPENDENT	Dependent Spouse and Children	18
NO_LONGER_A_DISABLED_CHILD	Dependent Child	18
EMPLOYEE_CAN_NO_LONGER_AFFORD_CHILD_COVERAGE	Child		18
OTHERS	Employee, Spouse and Children	36

There are other qualifying events, which are also considered while COBRA enrollment based on their Reason For Term.

5 User Role

The respective level of user role can over rule the following missing information.


	User Role	Level II, Level III, Level IV
S. No.,	Missing Information	Condition

1	SSN already exists	Employee SSN already exists
2	SSN already exists.	Dependent SSN already exists

Benefit Partners INC

Process Specification

Functional Design Process Specification

Add On and Change

1. Introduction

1.1. Purpose
This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.
1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_EN	Enrollment
	BPI_SCOPE_EN_002	Enrollment Add On

Other Document Reference


Document ID	Document Name

BPI_CAS_FSD_EN	Functional Specification Document -
	Enrollment
BPI_CAS_FSD_EN_001	Process Flow - New Business Enrollment
BPI_CAS_FSD_EN_003	Process Flow - COBRA Enrollment/Changes
BPI_CAS_FSD_EN_005	Process Flow - Termination/Reinstatement
BPI_CAS_RULEBOX	RULE BOX for Add on and change

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

Process Flow and Description
This process is used to make changes to the Existing groups/members or dependents or add a new member/dependent to the Group or employee based on the business rules associated with changes and “Add ON's”.
2.1. Background
2.2. Process Description

- The objective of the process

2.3. Process Flow

- This process is used to make changes to the Existing groups/members or dependents or add a new member/dependent to the Group or employee based on the business rules associated with changes and “Add ON's”.

2.4. User Interface Screens
2.4.1. Screen ID's


Screen ID (SID)	Screen Name	Corresponding HTML File Name

Enrollment.addon.newemp.groupsearch	GroupSearch	/bpi/cas/enrollment/addon/newemp/groupsearch
Enrollment.addon.newemp.changerequest	ChangeRequest	/bpi/cas/enrollment/addon/newemp/changerequest
Enrollment.addon.newemp.groupgeneral	EmployeeGeneral	/bpi/cas/enrollment/addon/newemp/addemployee
	Info
Enrollment.addon.newemp.employeecoverage	EmployeeCoverage	bpi/cas/enrollment/addon/newemp/employeecoverage
	Info
Enrollment.addon.newemp.dependent	DependentGeneral	bpi/cas/enrollment/addon/newemp/adddependent
	Info
Enrollment.addon.newemp.missing	PreEnrollment	bpi/cas/enrollment/addon/newemp/preenrollment
Enrollment.addon.newemp.summary	EnrollmentSummary	bpi/cas/enrollment/addon/newemp/enrollmentsummary
Enrollment.addon.newemp.confirmation	Confirmation	bpi/cas/enrollment/addon/newemp/confirmation
Enrollment.addon.newemp.employeesearch	Employee	bpi/cas/enrollment/addon/newemp/employeesearch
	Search
Enrollment.addon.newemp.dependentsearch	Dependent	bpi/cas/enrollment/addon/newemp/dependentsearch
	Search
Enrollment.addon.employeesearch	Employee	bpi/cas/enrollment/addon/adddependent/employeesearch
	Search
Enrollment.addon.changerequest	Change Request	bpi/cas/enrollment/addon/adddependent/changerequest
Enrollment.addon.dependent	Dependent	bpi/cas/enrollment/addon/adddependent/dependent
	General Info
Enrollment.addon.adddependentsearch	Modify	bpi/cas/enrollment/addon/adddependent/dependentsearch
	dependent
Enrollment.addon.missingforadddependent	Pre-Enrollment	bpi/cas/enrollment/addon/adddepedent/preenrollment
Enrollment.addon.addconfirmation	Confirmation	bpi/cas/enrollment/addon/adddependent/confirmation
bpi.enrollment.change.group.groupsearch	Group Search	/bpi/cas/enrollment/change/group/groupsearch
bpi.enrollment.change.group.changerequest	Change Request	/bpi/cas/enrollment/change/group/changerequest
bpi.enrollment.change.group.identifychanges	Identify	/bpi/cas/enrollment/change/group/identifychanges
	Changes
bpi.enrollment.change.group.general	Group	/bpi/cas/enrollment/change/group/generalinfo
	GeneralInfo
bpi.enrollment.change.group.billing	Group Billing	/bpi/cas/enrollment/change/group/billinginfo
	Info
bpi.enrollment.change.group.agent	Agent Info	/bpi/cas/enrollment/change/group/agentinfo
bpi.enrollment.change.group.coverage	Coverage Info	/bpi/cas/enrollment/change/group/coverageinfo
bpi.enrollment.change.group.missinginfo	Missing Info	/bpi/cas/enrollment/change/group/missinginfo
bpi.enrollment.change.group.confirmation	Confirmation	/bpi/cas/enrollment/change/group/confirmation
bpi.enrollment.change.group.groupmodifysearch	Modify Search	/bpi/cas/enrollment/change/group/groupmodifysearch
bpi.enrollment.change.employee.employeesearch	Employee	/bpi/cas/enrollment/change/employee/employeesearch
	Search
bpi.enrollment.change.employee.changerequest	Change Request	/bpi/cas/enrollment/change/employee/changerequest
bpi.enrollment.change.employee.identifychanges	Identify	/bpi/cas/enrollment/change/employee/identifychanges
	Changes
bpi.enrollment.change.employee.individualemployee	Individual	/bpi/cas/enrollment/change/employee/indivemployee
	Employee
bpi.enrollment.change.employee.individualbilling	Individual	/bpi/cas/enrollment/change/employee/indivbilling
	Billing
bpi.enrollment.change.employee.individualcoverage	Individual	/bpi/cas/enrollment/change/employee/indivcoverage
	Coverage
bpi.enrollment.change.employee.individualmissing	Individual	/bpi/cas/enrollment/change/employee/indivmissing
	Employee
	Missing
bpi.enrollment.change.employee.employeemodifysearch	Modify Search	/bpi/cas/enrollment/change/employee/employeemodifysearch
bpi.enrollment.change.employee.employeeconfirm	Employee	/bpi/cas/enrollment/change/employee/employeeconfirm
	Confirm
bpi.enrollment.change.employee.employeegeneral	Employee	/bpi/cas/enrollment/change/employee/employeegeneral
	General Info
bpi.enrollment.change.employee.employeecoverage	Employee	/bpi/cas/enrollment/change/employee/employeecoverage
	Coverage
bpi.enrollment.change.employee.employeemissing	Missing Info	/bpi/cas/enrollment/change/employee/employeemissing
bpi.enrollment.change.dependent.dependentsearch	Dependent	/bpi/cas/enrollment/change/dependent/dependentsearch
	Search
bpi.enrollment.change.dependent.changerequest	Change Request	/bpi/cas/enrollment/change/dependent/changerequest
bpi.enrollment.change.dependent.identifychanges	Identify	/bpi/cas/enrollment/change/dependent/identifychanges
	Changes
bpi.enrollment.change.dependent.dependentgeneral	Dependent	/bpi/cas/enrollment/change/dependent/dependentgeneral
	General
bpi.enrollment.change.dependent.missinginfo	Missing Info	/bpi/cas/enrollment/change/dependent/missing info
bpi.enrollment.change.dependent.dependentconfirm	Confirmation	/bpi/cas/enrollment/change/dependent/dependentconfirm
bpi.enrollment.change.dependent.dependentmodify	Modify Search	/bpi/cas/enrollment/change/dependent/dependentmodify

2.4.1.1. SID, Element Name, Element Type & Purpose
2.4.1.1.1 SID: enrollment.addon.newemp.groupsearch
2.4.1.1.1.1 Screen Snap Shot

- Refer BPI_CAS_FSD _—01—User Interface ID

:BPI_CAS_SCR_EN_—001_—012

2.4.1.1.1.2 Element Name, Element Type & Purpose

- Refer 3.1.13.2 of BPI_CAS_FSD_EN_—01 for the details.

2.4.1.1.2 SID: enrollmentaddon.newemp.changerequest
2.4.1.1.2.1 Screen Snap Shot
2.4.1.1.2.2 Element Name, Element Type & Purpose
2.4.1.1.3 SID: enrollmentaddon.newemp.groupgeneral
2.4.1.1.3.1 Screen Snap Shot

- Refer User Interface ID: BPI_CAS_SCR_EN_—001_—002—Group General of BPI_CAS_FSD_EN _—01

2.4.1.1.3.2 Element Name, Element Type & Purpose

- Refer 3.1.3.2 of BPI_CAS_FSD_EN_—01 for the details.

2.4.1.1.4 SID: enrollment.addon.newemp.employeecoverage
2.4.1.1.4.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—007—Employee Coverage of BPI_CAS_FSD_EN _—01

2.4.1.1.4.2 Element Name, Element Type & Purpose

- Refer 3.1.8.2 of BPI_CAS_FSD_EN_—01 for the details.

2.4.1.1.5 SID: enrollment.addon.newemp.dependent
2.4.1.1.5.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—008—Dependent of BPI_CAS_FSD_EN _—01

2.4.1.1.5.2 Element Name, Element Type & Purpose

- Refer 3.1.9.2 of BPI_CAS_FSD_EN_—01 for the details

2.4.1.1.6 SID: enrollment.addon.newemp.missing
2.4.1.1.6.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—010—Missing Information of BPI_CAS_FSD_EN _—01

2.4.1.1.6.2 Element Name, Element Type & Purpose

- Refer to 3.1.11.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.7 SID: enrollmentaddon.newemp.summary
2.4.1.1.7.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN 001_—009—Enrollment Summary of BPI_CAS_FSD_EN _—01

2.4.1.1.7.2 Element Name, Element Type & Purpose
Refer to 3.1.10.1 of BPI_CAS_FSD_EN _—01
2.4.1.1.8 SID: enrollmentaddon.newemp.confirmation
2.4.1.1.8.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—011—Enrollment Confirmation of BPI_CAS_FSD_EN _—01

2.4.1.1.8.2 Element Name, Element Type & Purpose

- Refer to 3.1.12.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.9 SID: enrollmentaddon.newemp.employeesearch
2.4.1.1.9.1 Screen Snap ShotElement Name, Element Type & Purpose

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—013—Employee Search of BPI_CAS_FSD_EN _—01

2.4.1.1.9.2 Element Name, Element Type & Purpose

- Refer to 3.1.14.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.10 SID: enrollmentaddon.newemp.dependentsearch
2.4.1.1.10.1 Screen Snap Shot

- Refer to User interface ID: BPI_CAS_SCR_EN_—001_—014—Dependent Search of BPI_CAS_FSD_EN _—01

2.4.1.1.10.2 Element Name, Element Type & Purpose

- Refer to 3.1.15.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.11 SID: enrollment.addon.employeesearch
2.4.1.1.11.1 Screen Snap Shot
Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—013—Employee Search of BPI_CAS_FSD_EN _—01
2.4.1.1.11.2 Element Name, Element Type & Purpose

- Refer to 3.1.14.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.12 SID: enrollment.addon.changerequest
2.4.1.1.12.1 Screen Snap Shot
2.4.1.1.12.2 Element Name, Element Type & Purpose
2.4.1.1.13 SID: enrollment.addon.dependent
2.4.1.1.13.1 Screen Snap Shot

2.4.1.1.13.2 Element Name, Element Type & Purpose
2.4.1.1.14 SID: enrollment.addon.adddependentsearch
2.4.1.1.14.1 Screen Snap Shot

2.4.1.1.14.2 Element Name, Element Type & Purpose

- Refer to 3.1.15.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.15 SID: enrollment.addon.missingforadddependent
2.4.1.1.15.1 Screen Snap Shot

2.4.1.1.15.2 Element Name, Element Type & Purpose

- Refer to 3.1.11.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.16 SID: enrollment.addon.addconfirmation
2.4.1.1.16.1 Screen Snap Shot

2.4.1.1.16.2 Element Name, Element Type & Purpose

- Refer to 3.1.12.2 of BPI_CAS_FSD_EN _—01

2.4.1.1.17 Change Screen SID
2.4.1.1.17.1 Screen Snap Shot

- Refer to User Interface ID BPI_CAS_FSD_EN _—01
  - BPI_CAS_RULKEBOX

2.4.1.1.17.2 Element Name, Element Type & Purpose

- Refer to User Interface ID BPI_CAS_FSD_EN _—01
  - BPI_CAS_RULKEBOX

2.4.2. Screen Flow
(See FIG. I-13)
(See FIG. I-14)
(See FIG. I-15)
(See FIG. I-16)
(See FIG. I-17)
Change:—Group Change New Request
(See FIG. I-18)
Change:—Group Modify Pending Changes
(See FIG. I-19)
Change:—Employee Change New Request
(See FIG. I-20)
Change:—Employee Modify Pending Changes
(See FIG. I-21)
Change:—Dependent Change New Request
(See FIG. I-22)
Change:—Dependent Modify Pending Changes
(See FIG. I-23)

3. Business Rule Mapping


Activity	Rules

Employer Add	The rate for the employer is guaranteed for one year
On	(One year from the date of enrollment) Hence the
	entire rates that is effective for the employer/group
	needs to be effective for the new employees as well.
	However the eligibility rules that is applicable for the
	Employee at the time of enrollment. Counts for the
	add-on employee can go more than 70 and up to 100 if
	Small Employer Group (override based on ACL). If
	Guaranteed association then there is no limit on the
	employee count at any time.
Process Add on	Shows the missing information of the Add On
	employee and emails the missing information to the
	GMS rep.
Process Add on	On successful Add On the welcome mail is sent to the
	Employer/Employee and cc to Agent. Billing
	adjustment is made which would be handled in the
	Finance Module.
Process Add On	Adding employee needs to check on the Waiting
(waiting Period)	Period. If the employee does not satisfy the waiting
	period then it should send email to the GMS rep. Also
	the employee effective date should default to the date
	when the employee is actually eligible. If the
	Employee satisfied the waiting period and is 60 days
	past the waiting period then it should flag this as
	missing information as this becomes a late
	application, which needs clarification from the
	employer before enrolling the employee. This
	employee can be enrolled only with authorization.
	The employee application form is not deemed as
	“Late” if it is postmarked within 60 days from the
	eligibility date. If it is postmarked within 60 days
	from the eligibility date, the application is declined as
	it is “Late”.
	Late application can be enrolled only on the next
	ROE.

Employee Add On (Adding Dependent)


Activity	Rules

Employee Add On	The rate for the employer is guaranteed for one
	year (One year form the date of enrollment) Hence
	the entire rate that is effective for the employer/
	group needs to be effective for the new dependent
	as well. However the eligibility of the Dependent is
	base on the normal eligibility rules that is applicable
	for the Dependent at the time of enrollment.
	Coverage Choice to be manipulated by System
	automatically.
Process Add on	Shows the missing information of the Add On
	Dependent and emails the missing information to
	the GMS rep.
Process Add on	On successful Add On the welcome mail is sent to
	the Employer/Employee/Dependent and cc to
	Agent. Billing adjustment is made which would be
	handled in the Finance Module.
General Rules	If the employee has selected the Employee only
	option as coverage choice then it needs to be
	changed for adding a dependent. System would not
	allow adding dependent with Employee only status.

Employer Change


Activity	Rules

Demographic	Demographic change can include change in Company
changes	Name, Contact name, Address, Phone, Fax, Email,
	Tax ID. All these change can be made and does not
	affect the business rules except for transmission of
	letter, email contacts
Billing Changes	All Billing changes are flag and email is sent to GMS
	rep and Finance for Information. Billing changes
	would effect the billing frequency or the mode of
	payment (EFT, Credit Card or Check)
Waiting Period	Change in the waiting period would affect the
Change	Employee Eligibility criteria for all add on
	employees, going forward, as the change may be.
	Change in the Employee type for the waiting period
	consideration would also affect the Employee
	Eligibility for the New Employees ‘Add-On’, going
	forward.
	Waiting period would be based on the Employer
	Effective date.
	Effective date for changing the Waiting period should
	default to the 1^stof the following month.
	Waiting period can be changed only once from the
	date of enrollment (effective date) to one-year cycle
	for the employer.
	If the waiting period changes are more than once in
	the calendar year for the employer. This is to be
	notified to the GMS rep and only the authorized
	person can override this and allow for waiting period
	change beyond 1 in employer anniversary date (one
	year cycle).
Employer	Contribution would be based on the Employer
Contribution	Effective date.
	Effective date for changing the Contribution should
	default to the 1^stof the following month.
	Contribution can be changed only twice from the date
	of enrollment (effective date) to one-year cycle for the
	employer.
	If the Contribution changes are more than once in the
	calendar year for the employer. This is to be notified
	to the GMS rep and only the authorized person can
	override this and allow for contribution change
	beyond 1 in employer calendar year.
	Note: Effective dates for Contribution changes
	should be 1^stfollowing month if the billing cycle
	has not completed.
	If the billing cycle is complete then it should be
	effective the next billing cycle. I.e. 1^stof the month
	following the next month.
Option benefits	a) Medical: No change allowed.
Changes	b) Dental Can be added only during ROE cycle.
	Can be dropped any time. Note if dental is
	dropped then it can be added in the ROE
	following 12 month from the date of dropping the
	dental plan.
	c) Vision and CAM: Can be added and dropped any
	time. Note if an optional benefit is dropped then
	it can be added in the ROE following 12 month
	from the date of dropping the optional benefit.
	d) This is to be notified to the GMS rep and only the
	authorized person can override this.
Employee Counts	Can be changed only at next ROE cycle.
(Number of
employee)
COBRA	Can Change any time but will effective from 1^stof the
	monthly only
	If this changes then any existing COBRA with this
	group will change accordingly and automatically, 1^st
	of the month.
	Should trigger automatic transmission
TEFRA	Can be change any time but will be effective from 1^st
	of the month only.
	Transmit record to the carrier only if the employee is
	65+
Part time	Can be change only during open enrollment or Re
coverage/	qualification and open enrollment. But should allow
Domestic partner	for overriding this feature based on authority.
	Note: Any over riding function should trigger auto
	email to the concerned GMS rep for making the
	changes based on their authority
Agent Change	This triggers a new process flow. (Refer process flow
	diagram FIG. 4.)

Note: For all changes effective date will be defaulted based on POST MARK DATE, If POST MARK date is lesser than 15th Day of month then Effective date will be 1st day of next month else it will be 1st day of next of the next month

4. User Role


	User Role	Level II, Level III, Level IV
	S. No., Missing Information	Condition

	1 SSN already exists.	Employee
	2 SSN already exists.	Dependent

Employee, Group and Dependent Changes (w.r.t. Current Date)

	User Role	Condition

	Level I	Reinstatement date is with in 30 days prior or later
	Level II	Reinstatement date is with in 30 days prior or later
	Level III	Reinstatement date is with in 60 days prior or later.

Benefit Partners Inc

Process Specification

ROE/OE Process

1. Introduction

1.1. Purpose
The purpose of this document is to describe the process of ROE/OE Process. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.
1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_EN	Enrollment
	BPI_SCOPE_EN_004	Enrollment - ROE

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

1.4. Document Reference


Document ID	Document Name

BPI_CAS_FSD_EN	Functional Specification Document -
	Enrollment
BPI_CAS_FSD_EN_001	Process Flow - New Business Enrollment
BPI_CAS_FSD_EN_002	Process Flow - Enrollment Changes/Add-On
BPI_CAS_FSD_EN_003	Process Flow - COBRA Enrollment/Changes
BPI_CAS_FSD_EN_005	Process Flow - Termination/Reinstatement

2. Process Identification

2.1. Background

- Once a year, on the anniversary date of a group's enrollment in PacAdvantage (or for some, its July 1st, not their anniversary date), the group's participation, contribution and qualification is reviewed. This review is to ensure that the group meets the qualification requirement. The main objective of this process is to review these criteria and re qualify as needed, notify them of rate changes and provide an opportunity for employees of the group to make changes to their enrollment.
- This process is identified as Re-qualification and open enrollment. Also there is another process associated with this called as open enrollment where in the group has the privilege to make the changes to the plan, waiting period etc.
- The difference between the two processes is that for re-qualification the Group has to under go the eligibility check to qualify for their next term.
- For open enrollment the group need not re qualify and under go the eligibility checks.
- The group should already have been enrolled with the PacAdvantage and have no termination date for the ROE to be done.

2.2. Process Description

- The objective of the ROE/OE Process is to:
  - Annual Re qualification or open enrollment form filled by the Employer
  - Open Enrollment Change form completed by employee, if applicable
  - Employee Enrollment form(s) completed by employee, if applicable
  - Dependent Enrollment fonn(s) completed by employee, if applicable
- The following are the other requirements that will be supported and constraints on the proposed system:
  - 1) The system has to initiate ROE/OE process 3 months prior to the actual anniversary date for the specific group. This process needs to be initiated by GMS personnel.
  - 2) System has to pick up the Groups for ROE based on the rules defined below:
  - Group Size: less than or equal to 4—All the groups needs to be re-qualified.
  - Group Size: 5 to 9-10% of the Group needs to be re-qualified
  - Group Size: greater than or equal to 10-1% of the group needs to be re-qualified.
  - 3) System has to randomly pick up the groups based on the above rules for ROE based on random generator algorithm.
  - 4) All other Group that is a part of ROE and OE needs to have their open enrollment processed.
  - 5) Also their needs to be a facility to have manual OE process wherein the Employee or Employees are manually picked for ROE or OE process. Manual OE is usually performed based on searching the Employee based on line of coverage and plan.
  - 6) There needs to be a feature to Finalize the ROE or OE for all the groups that have the same ROE/OE cycle.

2.3. Process Flow
Process for ROE/OE
The process starts after manual initiation

- 1) Identify the group that has their anniversary date 3 months hence.
- 2) Based on the group size identify if the group needs to be re-qualified.
- 3) Randomly pick up the group for re-qualification
- 4) If the group is not picked for re-qualification then the group only needs to have open enrollment.
- 5) Send ROE/OE packets to mail house. The packet includes the Agent Packet and the group packet.
- 6) Also sent the packets to the COBRA members of the existing group.
- 7) Send reminder for the ROE/OE every month.
- 8) Receive the ROE/OE packets completed by the Group and enter into the system.
- 9) Follow up for missing information
- 10) Convey the Group/Agent about the ROE status on completion of the process.

Note the screens for entry of data for the ROE/OE processes are similar to the Group/Employee/Dependent Changes screen. However for the ROW/OE process the status would be identified as ROE process.
Process Flow Diagram—ROE process (See FIG. i-24)

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


Screen ID (SID)	Screen Name	Corresponding HTML File Name

enrollment.roe.groupsearch	Group Search	/bpi/cas/enrollment/roe/groupsearch
enrollment.roe.request	Group Request	/bpi/cas/enrollment/roe/request
enrollment.roe.identifygroupchange	Identify Group Change	/bpi/cas/enrollment/roe/identifygroupchange
	Request
enrollment.roe.groupgeneral	Group General Info	/bpi/cas/enrollment/roe/groupgeneral
enrollment.roe.groupbilling	Group Billing Info	/bpi/cas/enrollment/roe/groupbilling
enrollment.roe.groupagent	Group Agent Info	/bpi/cas/enrollment/roe/groupagent
enrollment.roe.agentsearch	Agent Search	/bpi/cas/enrollment/roe/agentsearch
enrollment.roe.groupcoverage	Group Coverage Info	/bpi/cas/enrollment/roe/groupcoverage
enrollment.roe.employeesearch	Employee Search	/bpi/cas/enrollment/roe/employeesearch
enrollment.roe.identifyemployeechange	Identify Employee	/bpi/cas/enrollment/roe/identifyemployeechange
	Change Request
enrollment.roe.employeegeneral	Employee General Info	/bpi/cas/enrollment/roe/addemployee
enrollment.roe.employeecoverage	Employee Coverage Info	/bpi/cas/enrollment/roe/employeecoverage
enrollment.roe.dependentsearch	Dependent Search	/bpi/cas/enrollment/roe/dependentsearch
enrollment.roe.identifydependentchange	Identify Dependent	/bpi/cas/enrollment/roe/identifydependentchange
	Change Request
enrollment.roe.dependentgeneral	Dependent General	/bpi/cas/enrollment/roe/adddependent
enrollment.roe.groupsummary	Group Summary	/bpi/cas/enrollment/roe/enrollmentsummary
enrollment.roe.groupmissing	Group Missing Info	/bpi/cas/enrollment/roe/preenrollment/
enrollment.roe.groupconfirm	Group Confirm	/bpi/cas/enrollment/roe/groupconfirm
enrollment.roe.individualemployeesearch	Indiv Employee Search/	/bpi/cas/enrollment/roe/indivemployeesearch
	Indiv Group Search
enrollment.roe.indivemployeerequest	Indiv Employee Request	/bpi/cas/enrollment/roe/indivemployeerequest
enrollment.roe.identifyindivemployee	Identify Indiv Employee	/bpi/cas/enrollment/roe/identifyindivemployeechange
change	Change Request
enrollment.roe.individualemployeegeneral	Indiv Employee General	/bpi/cas/enrollment/roe/indivemployee
	Info
enrollment.roe.individualbilling	Indiv Billing Info	/bpi/cas/enrollment/roe/indivbilling
enrollment.roe.individualagent	Indiv Agent Info	/bpi/cas/enrollment/roe/indivagent
enrollment.roe.individualagentsearch	Indiv Agent Search	/bpi/cas/enrollment/roe/indivagent
enrollment.roe.individualemployeecoverage	Indiv Coverage Info	/bpi/cas/enrollment/roe/indivcoverage
enrollment.roe.individualdpendentsearch	Indiv Dependent Search	/bpi/cas/enrollment/roe/indivdependentsearch
enrollment.roe.identifyindivdependent	Identify indiv Dependent	/bpi/cas/enrollment/roe/identifyindivdependentchange
change	Change Request
enrollment.roe.individualdependentgeneral	Indiv Dependent General	/bpi/cas/enrollment/roe/indivdependent/
	Info
enrollment.roe.individualsummary	Indiv Enrollment	/bpi/cas/enrollment/roe/indivenrollmentsummary
	Summary
enrollment.roe.individualmissing	Indiv Pre Enrollment	/bpi/cas/enrollment/roe/indivpreenrollment
bpi.enrollment.cobraroe.new.searchcobra	COBRA Search	/bpi/cas/enrollment/cobraroe/new/cobraroesearch
bpi.enrollment.cobraroe.new.request	COBRA ROE/OE	/bpi/cas/enrollment/cobraroe/new/request
	Process Request
bpi.enrollment.cobraroe.new.identify	Identify COBRA ROE/	/bpi/cas/enrollment/cobraroe/new/request
changes	OE Change Request Info
bpi.enrollment.cobraroe.new.general	COBRA General info	/bpi/cas/enrollment/cobraroe/new/generalinfo
bpi.enrollment.cobraroe.new.billing	COBRA Billing Info	/bpi/cas/enrollment/cobraroe/new/billinginfo
bpi.enrollment.cobraroe.new.coverage	COBRA Coverage Info	/bpi/cas/enrollment/cobraroe/new/coverageinfo
bpi.enrollment.cobraroe.new.dependent	COBRA Dependent Info	/bpi/cas/enrollment/cobraroe/new/dependentinfo
bpi.enrollment.cobraroe.new.missing	COBRA Missing Info	/bpi/cas/enrollment/cobraroe/new/missinginfo
bpi.enrollment.cobraroe.new.confirmation	COBRA Confirmation	/bpi/cas/enrollment/cobraroe/new/confirmation
Enrollment.roe.manualroe	ROE/OE Process	/bpi/cas/enrollment/roe/manualroe
Enrollment.roe.roetransfer	ROE/OE Transfer	/bpi/cas/enrollment/roe/roetransfer

3.1.2. SID, Element Name, Element Type & Purpose
3.1.2.1. SID: enrollment.roe.groupsearch
3.1.2.1.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—012—Group Search of BPI_CAS_FSD_EN _—01

3.1.2.1.2 Element Name, Element Type & Purpose

- Refer to 3.1.13.2 of BPI_CAS_FSD_EN _—01

3.1.2.2. SID: enrollment.roe.request
3.1.2.2.1 Screen Snap Shot (See FIG. I-25)
3.1.2.3. SID: enrollment.roe.identifygroupchange
3.1.2.3.1 Screen Snap Shot (See FIG. I-26)
3.1.2.4. SID: enrollment.roe.groupgeneral
3.1.2.4.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—002—Group General of BPI_CAS_FSD_EN _—01

3.1.2.4.2 Element Name, Element Type & Purpose

- Refer to 3.1.3.2 of BPI_CAS_FSD_EN _—01

3.1.2.5. SID: enrollment.roe.groupbilling
3.1.2.5.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—003—Billing of BPI_CAS_FSD_EN _—01

3.1.2.5.2 Element Name, Element Type & Purpose

- Refer to 3.1.4.2 of BPI_CAS_FSD_EN _—01

3.1.2.6. SID: enrollment.roe.groupagent
3.1.2.6.1 Screen Snap Shot
Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—005—Agent of BPI_CAS_FSD_EN _—01
3.1.2.6.2 Element Name, Element Type & Purpose

- Refer to 3.1.6.2 of BPI_CAS_FSD_EN _—01

3.1.2.7. SID: enrollment.roe.agentsearch
3.1.2.7.1 Screen Snap Shot
3.1.2.7.2 Element Name, Element Type & Purpose
3.1.2.8. SID: enrollment.roe.groupcoverage
3.1.2.8.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—004—Group Coverage of BPI_CAS_FSD_EN _—01

3.1.2.8.2 Element Name, Element Type & Purpose

- Refer to 3.1.5.2 of BPI_CAS_FSD_EN _—01

3.1.2.9. SID: enrollment.roe.employeesearch
3.1.2.9.1 Screen Snap Shot

3.1.2.9.2 Element Name, Element Type & Purpose

- Refer to 3.1.14.2 of BPI_CAS_FSD_EN _—01

3.1.2.10. SID: enrollment.roe.identifyemployeechange
3.1.2.10.1 Screen Snap Shot (See FIG. I-27)
3.1.2.11. SID: enrollment.roe.employeegeneral
3.1.2.11.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—006—Employee Information of BPI_CAS_FSD_EN _—01

3.1.2.11.2 Element Name, Element Type & Purpose

- Refer to 3.1.7.2 of BPI_CAS_FSD_EN _—01

3.1.2.12. SID: enrollment.roe.employeecoverage
3.1.2.12.1 Screen Snap Shot

3.1.2.12.2 Element Name, Element Type & Purpose

- Refer to 3.1.8.2 of BPI_CAS_FSD_EN _—01

3.1.2.13. SID: enrollment.roe.dependentsearch
3.1.2.13.1 Screen Snap Shot

3.1.2.13.2 Element Name, Element Type & Purpose

- Refer to 3.1.15.2 of BPI_CAS_FSD_EN _—01

3.1.2.14. SID: enrollment.roe.identifydependentchange
3.1.2.14.1 Screen Snap Shot (See FIG. I-28)
3.1.2.15. SID: enrollment.roe.dependentgeneral
3.1.2.15.1 Screen Snap Shot

3.1.2.15.2 Element Name, Element Type & Purpose

- Refer to 3.1.9.2 of BPI_CAS_FSD_EN _—01

3.1.2.16. SID: enrollment.roe.groupsummary
3.1.2.16.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—009—Enrollment Summary of BPI_CAS_FSD_EN _—01

3.1.2.16.2 Element Name, Element Type & Purpose

- Refer to 3.1.10.2 of BPI_CAS_FSD_EN _—01

3.1.2.17. SID: enrollment.roe.groupmissing
3.1.2.17.1 Screen Snap Shot

3.1.2.17.2 Element Name, Element Type & Purpose
Refer to 3.1.11.2 of BPI_CAS_FSD_EN _—01
3.1.2.18. SID: enrollment.roe.groupconfinn
3.1.2.18.1 Screen Snap Shot

3.1.2.18.2 Element Name, Element Type & Purpose

- Refer to 3.1.12.2 of BPI_CAS_FSD_EN _—01

3.1.2.19. SID: enrollment.roe.individualemployeesearch
3.1.2.19.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_—001_—013—Employee Search of BPI_CAS_FSD_EN _—01

3.1.2.19.2 Element Name, Element Type & Purpose

- Refer to 3.1.14.2 of BPI_CAS_FSD_EN _—01

3.1.2.20. SID: enrollment.roe.indivemployeerequest
3.1.2.20.1 Screen Snap Shot
3.1.2.20.2 Element Name, Element Type & Purpose
3.1.2.21. SID: enrollment.roe.identifyindivemployeechange
3.1.2.21.1 Screen Snap Shot
3.1.2.21.2 Element Name, Element Type & Purpose
3.1.2.22. SID: enrollment.roe.individualemployeegeneral
3.1.2.22.1 Screen Snap Shot

3.1.2.22.2 Element Name, Element Type & Purpose

- Refer to 3.1.7.2 of BPI_CAS_FSD_EN _—01

3.1.2.23. SID: enrollment.roe.individualbilling
3.1.2.23.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_—001_—003—Billing of BPI_CAS_FSD_EN _—01

3.1.2.23.2 Element Name, Element Type & Purpose

- Refer to 3.1.4.2 of BPI_CAS_FSD_EN _—01

3.1.2.24. SID: enrollment.roe.individualagent
3.1.2.24.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN_—001_—005—Agent of BPI_CAS_FSD_EN _—01

3.1.2.24.2 Element Name, Element Type & Purpose

- Refer to 3.1.6.2 of BPI_CAS_FSD_EN _—01

3.1.2.25. SID: enrollment.roe.individualagentsearch
3.1.2.25.1 Screen Snap Shot
3.1.2.25.2 Element Name, Element Type & Purpose
3.1.2.26. SID: enrollment.roe.individualemployeecoverage
3.1.2.26.1 Screen Snap Shot

3.1.2.26.2 Element Name, Element Type & Purpose

- Refer to 3.1.8.2 of BPI_CAS_FSD_EN _—01

3.1.2.27. SID: enrollment.roe.individualdependentsearch
3.1.2.27.1 Screen Snap Shot

3.1.2.27.2 Element Name, Element Type & Purpose

- Refer to 3.1.15.2 of BPI_CAS_FSD_EN _—01

3.1.2.28. SID: enrollment.roe.identifyindivdependentchange
3.1.2.28.1 Screen Snap Shot
3.1.2.28.2 Element Name, Element Type & Purpose
3.1.2.29. SID: enrollment.roe.individualdependentgeneral
3.1.2.29.1 Screen Snap Shot

- Refer to User Interface ID: BPI_CAS_SCR_EN 001-008—Dependent of BPI_CAS_FSD_EN _—01

3.1.2.29.2 Element Name, Element Type & Purpose.

- Refer to 3.1.9.2 of BPI_CAS_FSD_EN _—01

3.1.2.30. SID: enrollment.roe.individualsummary
3.1.2.30.1 Screen Snap Shot

3.1.2.30.2 Element Name, Element Type & Purpose

- Refer to 3.1.10.2 of BPI_CAS_FSD_EN _—01

3.1.2.31. SID: enrollmentroe.individualmissing
3.1.2.31.1 Screen Snap Shot

3.1.2.31.2 Element Name, Element Type & Purpose

- Refer to 3.1.11.2 of BPI_CAS_FSD_EN _—01

3.1.2.32. SID: bpi.enrollment.cobraroe.new.searchcobra
3.1.2.32.1 Screen Snap Shot

- Refer to 3.1.1 Screen Shot: BPI_SCR_EN 002_—001 of BPI_CAS_FSD_EN_—02

3.1.2.32.2 Element Name, Element Type & Purpose

- Refer to 3.1.2 of BPI_CAS_FSD_EN_—02

3.1.2.33. SID: bpi.enrollment.cobraroe.new.request
3.1.2.33.1 Screen Snap Shot (See FIG. I-29)
3.1.2.34. SID: bpi.enrollment.cobraroe.new.identifychanges
3.1.2.34.1 Screen Snap Shot (See FIG. I-30)
3.1.2.35. SID: bpi.enrollment.cobraroe.new.general
3.1.2.35.1 Screen Snap Shot

- Refer to 3.8.1 Screen Shot: BPI_SCR_EN_—002_—009 of BPI_CAS_FSD_EN_—02

3.1.2.35.2 Element Name, Element Type & Purpose

- Refer to 3.8.2 of BPI_CAS_FSD_EN_—02

3.1.2.36. SID: bpi.enrollment.cobraroe.new.billing
3.1.2.36.1 Screen Snap Shot

3.1.2.36.2 Element Name, Element Type & Purpose

- Refer to 3.1.4.2 of BPI_CAS_FSD_EN _—01

3.1.2.37. SID: bpi.enrollment.cobraroe.new.coverage
3.1.2.37.1 Screen Snap Shot

- Refer to 3.9.1 Screen Shot: BPI_SCR_EN 002_—010 of BPI_CAS_FSD_EN_—02

3.1.2.37.2 Element Name, Element Type & Purpose

- Refer to 3.9.2 of BPI_CAS_FSD_EN_—02

3.1.2.38. SID: bpi.enrollment.cobraroe.new.dependent
3.1.2.38.1 Screen Snap Shot

- Refer to 3.3.1 Screen Shot: BPI_SCR_EN_—002_—003 of BPI_CAS_FSD_EN_—02

3.1.2.38.2 Element Name, Element Type & Purpose

- Refer to 3.3.2 of BPI_CAS_FSD_EN_—02

3.1.2.39. SID: bpi.enrollment.cobraroe.new.missing
3.1.2.39.1 Screen Snap Shot

- Refer to 3.5.1 Screen Shot: BPI_SCR_EN 002_—006 of BPI_CAS_FSD_EN_—02

3.1.2.39.2 Element Name, Element Type & Purpose

- Refer to 3.5.2 of BPI_CAS_FSD_EN_—02

3.1.2.40. SID: bpi.enrollment.cobraroe.new.confirmation
3.1.2.40.1 Screen Snap Shot

3.1.2.40.2 Element Name, Element Type & Purpose

- Refer to 3.1.12.2 of BPI_CAS_FSD_EN _—01

3.1.3. Screen Flow
(See FIG. I-31)
(See FIG. I-32)
(See FIG. I-33)

4. Business Rule Mapping


Activity	Rules

ROE Process	Identify the group randomly based on the Group
	size for ROE.
ROE validation	All the eligibility rules that are applicable as
	new business enrollment are applicable for the
	ROE as well.
Open Enrollment	Open enrollment allows for making the changes
	that are normally not possible during the normal
	changes.
Billing	Bill in a normal way if the ROE/OE has a
	completed status. Make the bill for the new
	effective date.
	If the ROE/OE has a status as pend then pend
	the bill for the new effective date.

5. User Role

The respective level of user role can over rule the following missing information,

ROE OE SEG/Alternate/Indiv Group

User Role	Level II, Level III, Level IV
S. No., Missing Information	Condition

1 SSN already exists.	Employee SSN already exists
2 SSN already exists.	Dependent SSN already exists
3 Employer Tax Id already exists.	Employer Tax Id already exists

ROE OE COBRA Group

	User Role	Level II, Level III, Level IV
	S. No., Missing Information	Condition

	1 SSN already exists.	Employee SSN already exists
	2 SSN already exists.	Dependent SSN already exists

Benefit Partners Inc

Process Specification

Termination Reinstatement

1. Introduction

1.1. Purpose
The purpose of this document is to identify the process associated with the business use case Termination and Reinstatement
1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_EN	Enrollment
	BPI_SCOPE_EN_005	Termination and Reinstatement

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background
<Brief Description of the Process>
2.2. Process Description

- Process Flow for Group Term
- This process is used to terminate or reinstate the Group, Employee and or Dependent.
- The FIG. 1 shows the process flow for the group termination. The group can be termed broadly based on two reasons; Non-payment of Premium or by group request for termination. Non-payment of premium is an automated process and starts and completes the term process automatically. The employer request is a manual term process and the Group is termed manually.
- Automated Term process initiates the Term Process. Letter is sent to the Group with 15 days notice for reinstatement. The system holds the status as “Term Pending” although the group believes they are completely termed. The reason for this is to prevent the sending of termination then reinstatement transmissions to the carriers; which causes confusion. The finance department then processes the term to completion if the payment is not received. Finance also has ability to override the term pend status based on authority.
- Manual Term process is based on the request received from the group. All manual term process is notified to finance for necessary action. If the Group has a shortfall then the system notifies the finance department and finance processes the term. Term letter is send to the Group for paying through the balance premium. If the balance premium is paid then the finance department completes the term. If the balance is not paid then finance terms the group retrospectively.
- If the Group has a refund due them then the system notifies the finance department and finance processes the refund and completes the term process.

Process Flow for Employee Term

- Employee term is based on the Employer request to terminate the employee based on certain reasons. Based on these reasons the employee is termed and all employees who are termed needs to be sent the COBRA packets for COBRA enrollment. Billing adjustments are made for the employee term in the next invoice generated.

Process Flow for Dependent Term

- Dependent term is based on the Employer/Employee request to terminate the Dependent based on certain reasons. Based on these reasons the Dependent is termed and the termed Dependent are sent the COBRA packets for COBRA enrollment. Billing adjustments are made for the Dependent term in the next invoice generated for the Group.

2.3. Process Flow

- Process flow description (See FIG. I-34)

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


		Corresponding HTML File
Screen ID (SID)	Screen Name	Name

enrollment.termination.groupsearch	Search Group for Termination	/bpi/cas/enrollment/termination/group/GroupSearch.jsp
enrollment.termination.grouptermination	Group Termination Request	/bpi/cas/enrollment/termination/group/GroupTerminationRequest.jsp
request
enrollment.termination.groupprocess	Group Termination Process	/bpi/cas/enrollment/termination/group/GroupProcessTermination.jsp
termination
enrollment.termination.grouptemination	Group Termination	/bpi/cas/enrollment/termination/group/GroupTerminationConfirm.jsp
confirmation	Confirmation
enrollment.termination.multiple	Multiple Group Termination	/bpi/cas/enrollment/termination/group/
groupsearch	Request	MultipleGroupTerminationRequest.jsp
enrollment.termination.multiple	Multiple Group Termination	/bpi/cas/enrollment/termination/group/
groupterminationconfirm	Confirmation	MultipleGroupTerminationConfirm.jsp
enrollment.termination.employee	Search Employee for Termination	/bpi/cas/enrollment/termination/employee/EmployeeSearch.jsp
search
enrollment.termination.employee	Employee Termination Request	/bpi/cas/enrollment/termination/employee/
terminationrequest		EmployeeTerminationRequest.jsp
enrollment.termination.employee	Employee Process Termination	/bpi/cas/enrollment/termination/employee/
processtermination		EmployeeProcessTermination.jsp
enrollment.termination.employee	Employee Termination	/bpi/cas/enrollment/termination/employee/
terminationconfirm	Confirmation	EmployeeTerminationConfirm.jsp
enrollment.termination.dependent	Search Dependent for	/bpi/cas/enrollment/termination/dependent/
search	Termination	DependentSearch.jsp
enrollment.termination.dependent	Dependent Termination	/bpi/cas/enrollment/termination/dependent/
terminationrequest	Request	DependentTerminationRequest.jsp
enrollment.termination.dependent	Dependent Process Termination	/bpi/cas/enrollment/termination/dependent/
processtermination		DependentProcessTermination.jsp
enrollment.termination.dependent	Dependent Termination	/bpi/cas/enrollment/termination/dependent/
terminationconfirm	Confirm	DependentTerminationConfirm.jsp
enrollment.reinstatement.group	Search Group for Reinstatement	/bpi/cas/enrollment/reinstatement/group/GroupSearch.jsp
search
enrollment.reinstatement.group	Group Reinstatement Request	/bpi/cas/enrollment/reinstatement/group/GroupReinstatementRequest.jsp
reinstatementrequest
enrollment.reinstatement.group	Group Process Reinstatement	/bpi/cas/enrollment/reinstatement/group/GroupProcessReinstatement.jsp
processreinstatement
enrollment.reinstatement.group	Group Reinstatement	/bpi/cas/enrollment/reinstatement/group/GroupReinstatementConfirm.jsp
reinstatementconfirm	Confirmation
enrollment.reinstatement.employee	Search for Employee	/bpi/cas/enrollment/reinstatement/employee/EmployeeSearch.jsp
search	Reinstatement
enrollment.reinstatement.employee	Employee Reinstatement	/bpi/cas/enrollment/reinstatement/employee/
reinstatementrequest	Request	EmployeeReinstatementRequest.jsp
enrollment.reinstatement.employee	Employee Process	/bpi/cas/enrollment/reinstatement/employee/
processreinstatement	Reinstatement	EmployeeProcessReinstatement.jsp
enrollment.reinstatement.employee	Employee Reinstatement	/bpi/cas/enrollment/reinstatement/employee/
reinstatementconfirm	Confirmation	EmployeeReinstatementConfirm.jsp
enrollment.reinstatement.dependent	Search Dependent for	/bpi/cas/enrollment/reinstatement/dependent/DependentSearch.jsp
search	Reinstatement
enrollment.reinstatement.dependent	Dependent Reinstatement	/bpi/cas/enrollment/reinstatement/dependent/
reinstatementrequest	Request	DependentReinstatementRequest.jsp
enrollment.reinstatement.dependent	Dependent Process	/bpi/cas/enrollment/reinstatement/dependent/
processreinstatement	Reinstatement	DependentProcessReinstatement.jsp
enrollment.reinstatement.dependent	Dependent Reinstatement	/bpi/cas/enrollment/reinstatement/dependent/
reinstatementconfirm	Confirmation	DependentReinstatementConfirm.jsp

3.1.1.1. SID, Element Name, Element Type & Purpose

- SID: enrollment.termination.groupsearch
- Screen Snap Shot (See FIG. I-35)


Element Name	Element Type	Purpose

Group Id	Entry Field	Enter Group Id
Group Name	Entry Field	Enter Group Name
Phone Number	Entry Field	Enter Phone Number

- SID: enrollment.termination.groupterminationrequest
- Screen Snap Shot (See FIG. I-36)


Element Name	Element Type	Purpose

Mode of	Selection Box	Entry Field for the Group Id.
Request
Postmark Date	Entry Field	Entry Field for the Group Name
Date Received	Entry Field	Entry Field for the Date Received
Authorized	Selection Box	Entry Field for the Authorized Contact
Contact
Requested	Entry Field	Entry Field for the Request Term Date
Term Date
Reason for	Selection Box	Select the Reason for Term
Term
Other Reason	Entry Field	Entry Field for the Other Reason

- SID: enrollment.termination.groupprocesstermination
- Screen Snap Shot (See FIG. I-37)


Element Name	Element Type	Purpose

Effective Term Date	Entry Field	Entry Field for the Group Id.
Change Term Status	Select Box	Select Change Term Status

- SID: enrollment.termination.groupterminationcontirm
- Screen Snap Shot (See FIG. I-38)
- SID: enrollment.termination.multiplegroupsearch
- Screen Snap Shot (See FIG. I-39)


Element Name	Element Type	Purpose

Postmark Date	Entry Field	Entry Field for the Group Name
Date Received	Entry Field	Entry Field for the Date Received
Requested	Entry Field	Entry Field for the Request Term Date
Term Date
Reason for	Selection Box	Select the Reason for Term
Term
Other Reason	Entry Field	Entry Field for the Other Reason

- SID: enrollment.termination.multiplegroupterminationconfirm
- Screen Snap Shot (See FIG. I-40)
- SID: enrollment.termination.employeesearch
- Screen Snap Shot (See FIG. I-41)


Element Name	Element Type	Purpose

Group Name	Entry Field	Entry Field for the Group Name
Group Id	Entry Field	Entry Field for the Group ID
Employee	Entry Field	Entry Field for the Employee First
First Name		Name
Employee	Entry Field	Entry Field for the Employee Last
Last Name		Name
Employee Phone	Entry Field	Entry Field for the Employee Phone
Number		Number
Employee SSN	Entry Field	Entry Field for the Employee SSN
Employee ID	Entry Field	Entry Field for the Employee ID

- SID: enrollment.termination.employeeterminationrequest
- Screen Snap Shot (See FIG. I-42)


Element Name	Element Type	Purpose

Mode of Request	Selection Box	Entry Field for the Group Id.
Postmark Date	Entry Field	Entry Field for the Group Name
Date Received	Entry Field	Entry Field for the Date Received
Authorized Contact	Selection Box	Entry Field for the Authorized
		Contact
Requested Term	Entry Field	Entry Field for the Request Term
Date		Date
Reason for Term	Selection Box	Select the Reason for Term
Other Reason	Entry Field	Entry Field for the Other Reason

- SID: enrollment.termination.employeeprocesstermination
- Screen Snap Shot (See FIG. I-43)


Element Name	Element Type	Purpose

Effective Term Date	Entry Field	Entry Field for the Group Id.
Chance Term Status	Select Box	Select Change Term Status

- SID: enrollment.termination.employeeterminationconfirm
- Screen Snap Shot (See FIG. I-44)
- SID: enrollment.termination.dependentsearch
- Screen Snap Shot (See FIG. I-45)


Element Name	Element Type	Purpose

Employee First Name	Entry Field	Entry Field for the Employee
		First Name
Employee Last Name	Entry Field	Entry Field for the Employee
		Last Name
Employee SSN	Entry Field	Entry Field for the Employee
		SSN
Employee Id	Entry Field	Entry Field for the Employee Id
Dependent First Name	Entry Field	Entry Field for the Dependent
		First Name
Dependent Last Name	Entry Field	Entry Field for the Dependent
		Last Name
Dependent SSN	Entry Field	Entry Field for the Dependent
		SSN
Dependent Id	Entry Field	Entry Field for the Dependent Id

- SID: enrollment.termination.dependentterminationrequest
- Screen Snap Shot (See FIG. I-46)

- SID: enrollment.termination.dependentprocesstermination
- Screen Snap Shot (See FIG. I-47)


Element Name	Element Type	Purpose

Effective Term Date	Entry Field	Entry Field for the Term Date.
Change Term Status	Select Box	Select Change Term Status

- SID: enrollment.termination.dependentterminationconfirm
- Screen Snap Shot (See FIG. I-48)
- SID: enrollment.reinstatement.groupsearch
- Screen Snap Shot (See FIG. I-49)

- SID: enrollment.reinstatement.groupreinstatementrequest
- Screen Snap Shot (See FIG. I-50)


Element Name	Element Type	Purpose

Mode of Request	Selection Box	Entry Field for the Group Id.
Postmark Date	Entry Field	Entry Field for the Group Name
Date Received	Entry Field	Entry Field for the Date Received
Authorized Contact	Selection Box	Entry Field for the Authorized
		Contact
Reinstatement Date	Entry Field	Entry Field for the Request Rein
Requested		Date
Reason for	Selection Box	Select the Reason for
Reinstatement		Reinstatement
Other Reason	Entry Field	Entry Field for the Other Reason

- SID: enrollment.reinstatement.groupprocessreinstatement
- Screen Snap Shot (See FIG. I-51)


Element Name	Element Type	Purpose

Effective Date	Entry Field	Entry Field for the Date.
Change Status	Select Box	Select Change Status

- SID: enrollmentreinstatementgroupreinstatementconfirm
- Screen Snap Shot (See FIG. I-52)
- SID: enrollmentreinstatementemployeesearch
- Screen Snap Shot (See FIG. I-53)


Element Name	Element Type	Purpose

Group Name	Entry Field	Entry Field for the Group Name
Group Id	Entry Field	Entry Field for the Group ID
Employee First Name	Entry Field	Entry Field for the Employee
		First Name
Employee Last Name	Entry Field	Entry Field for the Employee
		Last Name
Employee Phone	Entry Field	Entry Field for the Employee
Number		Phone Number
Employee SSN	Entry Field	Entry Field for the Employee
		SSN
Employee ID	Entry Field	Entry Field for the Employee ID

- SID: enrollment.reinstatement.employeereinstatementrequest
- Screen Snap Shot (See FIG. I-54)

- SID: enrollment.reinstatement.employeeprocessreinstatement
- Screen Snap Shot (See FIG. I-55)

- SID: enrollmentreinstatementemployeereinstatementconfirm
- Screen Snap Shot
- SID: enrollment.reinstatement.dependentsearch
- Screen Snap Shot (See FIG. I-56)

- SID: enrollmentreinstatement.dependentreinstatementrequest
- Screen Snap Shot (See FIG. I-57)

- SID: enrollment.reinstatement.dependentprocessreinstatement
- Screen Snap Shot (See FIG. I-58)

- SID: enrollmentreinstatement.dependentreinstatementconfinn
- Screen Snap Shot (See FIG. I-59)

3.1.2. Screen Flow (See FIG. I-60)

4. Business Rule Mapping


Activity	Rules

Term Process (request	The person who requested the term should be the
received from)	designated contact person or agent assigned to
	that group. Other persons are not authorized to
	initiate the term request.
Term Process	On employer request the term process is initiated.
(Manual)	The term process should check the billing
	status and the balance due or refund. If the
	group has paid through and there is no
	shortage or surplus then this process
	should auto initiate the term process. Send
	letters the Group, Employee and
	dependent. Notify via mail to the GMS
	rep if the group size is less than 15 and if
	above 15 notify the Sales rep.
	If there is a shortage then send a mail to
	the finance and put the term status as term
	pending. Finance should initiate follow up
	for collecting the balance due and sent the
	term letter and payment letter. On receipt
	of payment term the Group. If the
	Payment is not received then retro terms
	the group.
	If there is refund due to the group the
	finance should process the refund and
	initiate the term there after.
	Note: GMS can process Term up to 30 days
	(LEVEL I)
	Term beyond 30 days-60 days can be
	processed only by lead (LEVEL II)
	Term extended beyond 60 days is based on
	ultimate authority to a specified user (LEVEL
	III AND IV)
Term Process	Automated term process is initiated if the group
(Automated)	does not pay the premium or there is shortage of
	premium. Term letter is sent to the group on 32
	day of non-receipt of payment and the Group is
	given 15-day notice to repay. If the Group does
	not pay within 32 + 15 days the finance should
	finalize term based on authority.
General Term rules	If the group is termed then all the employees and
	dependents for the group are termed. The
	COBRA Members associated with the group
	should also be termed. The term letter should
	be sent to the entire member for the Group
	including the COBRA group. EFT and auto
	credit card deductions should stop on term.
Term Process	Dependent can be terminated based on various
	reason provide for the employee termination.
	All term should be effective end of the current
	month or if the term is requested for the month
	after the current month.
	Dependent cannot be termed with past date
	beyond 30 days.
	Exception:
	Death of the dependent. The dependent is termed
	the on the day of the death.
Term Rules	Auto initiate Dependent terms if the age of the
	dependent is 23 and the dependent other than
	spouse or domestic partner are no longer eligible.
	Also send the COBRA packet to the dependent if
	termed.
Billing Adjustment	Make adjustment to the billing for the termed
	dependent in the next billing cycle
Term Process	The person who requested the term should be
(request received	designated contact person. Other person are not
from)	authorized to initiate the term request.
Term Process	On employer request the term process is initiated.
(Manual)	The term process should check the billing
	status and the balance due or refund. If the
	group has paid through and there is no
	shortage or surplus then this process
	should auto initiate the term process. Send
	letters the Group, Employee and
	dependent. Notify via mail to the GMS
	rep if the group size is less than 15 and if
	above 15 notify the Sales rep.
	If there is a shortage then send a mail to
	the finance and put the term status as term
	pending. Finance should initiate follow up
	for collecting the balance due and sent the
	term letter and payment letter. On receipt
	of payment term the Group. If the
	Payment is not received then retro terms
	the group.
	If there is refund due to the group the
	finance should process the refund and
	initiate the term there after.
	Note: GMS can process Term up to 30 days.
	(LEVEL I)
	Term beyond 30 days-60 days can be
	processed only by lead (LEVEL II)
	Term extended beyond 60 days is based on
	ultimate authority to a specified user (LEVEL
	III AND IV)
Term Process	Automated term process is initiated if the group
(Automated)	does not pay the premium or there is shortage of
	premium. Term letter is sent to the group on 32
	day of non-receipt of payment and the Group is
	given 15-day notice to repay. If the Group does
	not pay within 32 + 15 days the finance should
	finalize term based on authority.
General Term rules	If the group is termed then all the employees and
	dependents for the group are termed. The
	COBRA Members associated with the group
	should also be termed. The term letter should
	be sent to the entire member for the Group
	including the COBRA group. EFT and auto
	credit card deductions should stop on term.
Term Process	This is to complete the term process where the
	term status was term pend. All auto initiated term
	process has the term status as term pend. It
	requires user intervention to complete the term
	process based on authority.
Term Process	Employee can be terminated based on various
	reason provide from the employee termination
	All term should be effective end of the current
	month or if the term is requested for the month
	after the current month
	Employee cannot be termed with past date beyond
	30 days.
	Exception:
	Death of the employee. The employee is termed
	the on the day of the death.
Process Associated	All employee terms should send term letter to the
with term	employee and group. The employee can opt for
	COBRA and hence the COBRE enrollment
	packet should be sent to the employee
Billing Adjustment	There should be billing adjustment in the
	subsequent bill for termed employee
Term Process	Dependent can be terminated based on various
	reason provide for the employee termination
	All term should be effective end of the current
	month or if the term is requested for the month
	after the current month.
	Dependent cannot be termed with past date
	beyond 30 days
	Exception:
	Death of the dependent. The dependent is termed
	the on the day of the death.
Term Rules	Auto initiate Dependent terms if the age of the
	dependent is 23 and the dependent other than
	spouse or domestic partner are no longer eligible.
	Also send the COBRA packet to the dependent if
	termed.
Billing Adjustment	Make adjustment to the billing for the termed
	dependent in the next billing cycle.
Reinstatement Process	The person who requested the reinstatement
	should be the designated contact person. Other
	persons are not authorized to initiate the
	reinstatement request.
	If reinstatement cannot happen then send the
	denial letter.
	If reinstated notify finance
	System should calculate the reinstatement fees.
	Finance will reinstate on receipt of payment.
	Note When the group is reinstated all the
	members associated with the group are also
	reinstated.
	Including COBRA GROUP.
	GMS can reinstate within 30 days. Any period
	above this needs authorization.
Reinstatement Process	The person who requested the reinstatement
	should be the designated contact person. Other
	persons are not authorized to initiate the
	reinstatement request.
	If reinstatement cannot happen then send the
	denial letter.
	Note When the Employee is reinstated all the
	dependents of the Employee are also reinstated.
Reinstatement Process	The person who requested the reinstatement
	should be designated contact person. Other
	persons are not authorized to initiate the
	reinstatement request.
	If reinstatement cannot happen then send the
	denial letter.
	If reinstated notify finance for reinstatement fees
	calculation if applicable.

5. User Role

The respective level user can terminate or reinstate the dependent, employee or group based on the criteria mention in the following table. The following validations are done with respect to the current date.

Dependent Termination

S. No.,	User Role	Condition

1	Level I	Termination date is with in 30 days prior or later
2	Level II	Termination date is within 60 days prior or later
3	Level III,	Termination date is within 90 days prior or later
	Level IV

Employee Termination

S. No.,	User Role	Condition

1	Level I	Termination date is with in 30 days prior or later
2	Level II	Termination date is within 60 days prior or later
3	Level III	Termination date is within 90 days prior or later
	Level IV

Group Termination

Dependent Reinstatement

Employee Reinstatement

Group Reinstatement

Benefit Partners Inc

Proceess Specification

Appeals and Grievances

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the process of Appeals and Grievances. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.

1.2. Business Use Case Specification Reference


	Business Use
	Specification ID	Business Use Case Name

	BPI_SCOPE_EN	Enrollment
	SCOPE_ADD	Addendum to the Scope Document

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

	BPI_CAS_FSD_EN	Functional Specification
		Document—Enrollment
	BPI_CAS_FSD_EN_001	Process Specification—New
		Business Enrollment
	BPI_CAS_FSD_EN_002	Process Specification—Enrollment
		Changes/Add-On
	BPI_CAS_FSD_EN_003	Process Specification—COBRA
		Enrollment/Changes
	BPI_CAS_FSD_EN_004	Process Specification—ROE/OE
	BPI_CAS_FSD_EN_005	Process Specification—Termination/
		Reinstatement

2. Process Identification

2.1. Background
Any process or transaction that is performed by PacAdvantage is subject to a review process. The rule for such is defined in the PacAdvantage handbook. There are cases when the Customer is not satisfied with some of the decisions made during the administration of the program. When a customer is not satisfied with the decision made they can submit a request for Program Review. Once a decision has been made to grant or deny the request, an Appeal can then be submitted to overturn the decision of the Program Review. Not all decisions are appealable. In any case, all grievances need to be sent to PacAdvantage-Roseville, along with other certain requirements, for making a decision whether to consider the Grievances or to reject them as the case may be.
PacAdvantage-Roseville makes the decision on the initial requests or “Program Reviews” and forwards the response to the customer. Upon receipt of a second request or “Appeal”, if the decision is appealable, Pac Advantage-Roseville forwards the information to PacAdvantage-SF to make a ruling. (If the decision is not appealable, PacAdvantage-Roseville sends a letter regarding such to the customer.) PacAdvantage-SF then returns a ruling and PacAdvantage-Roseville forwards the response to the customer.
This entire process needs to be captured and tracked by the system.
Any transaction within the system has a history. The personnel handling the grievance need to review the history and generate a report regarding the grievance for review.
2.2. Process Description
The objective of the Grievance process is to:

- 1) Maintain a status for all Grievances received from the customer and follow up with the decision made either by PacAdvantage-Roseville or PacAdvantage-SF.

The following are the other requirements that will be supported and constraints on the proposed system:

- 1) The system would track the initial request from open to close.
- 2) The system would track subsequent requests, if a proper appeal, from re-open to close.
- 3) Track subsequent requests, if not a proper appeal, for receive dates, remarks and any correspondence.
- 4) The system would also have a history of all the transactions to get the report for the Nature of Grievance.

2.3. Process Flow
Process for Grievances—First Request (or “Program Review”)

- 1) Receive the Grievance from Group and/or Member and/or Agent representing the Group and/or Member.
- 2) Categorize the nature of the Grievance.
- 3) Review the history and collect all the relevant documents for the Grievance.
- 4) Make decision to approve/deny the Grievance.
- 5) Close the Grievance.
- 6) Send relevant letters.
- 7) If the Grievance is in favor of the group or the employee, send notification to Finance and or GMS to take necessary action (Reinstate the Group/Member).

Process for Grievances—Second Request (or “Appeal”)

- 1) Receive the Grievance from the Group and/or Member and/or Agent representing the Group and/or Member.
- 2) Categorize the nature of the Grievance.
- 3) Review the history and collect all the relevant documents for the Grievance.
- 4) Forward the document with relevant information to PacAdvantage-SF.
- 5) Follow up with PacAdvantage-SF regarding the decision on the Grievance.
- 6) On receiving the decision convey the decision to the Group and or employee.
- 7) Close the Grievance.
- 8) Send relevant letters.
- 9) If the Grievance is in favor of the group or the employee send notification to Finance and or GMS to take necessary action (Reinstate the Group/Member).

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


	Screen	Corresponding
Screen ID (SID)	Name	HTML File Name

bpi.enrollment.grievance.appellantsearch	Grievance	grievancesearch
	Search
bpi.enrollment.grievance.grievancecreate	Grievance	grievancecreate
	Create
bpi.enrollment.grievance.grievancemodify	Grievance	grievancemodify
	Modify
bpi.enrollment.grievance.grievanceclose	Grievance	grievanceclose
	Close

3.1.1.1. SID, Element Name, Element Type & Purpose
SID: bpi.enrollment.grievance.appellantsearch (See FIG. I-61)

Element Name


	Element
Element Name	Type	Label	Purpose

Complainant	Text	Complainant	To display text
Type		Type
appellantType	Radio	Complainant	To select the type “Group”
	button	Type	or “Member”
Complainant	Text	Complainant	To display text
ID		ID
appellantId	Text Field	Complainant	To enter complainant id
		ID
Company	Text	Company	To display text
Name		Name
companyName	Text Field	Company	To enter company name
		Name
First Name	Text	First Name	To display text
firstName	Text Field	First Name	To enter first name
Last Name	Text	Last Name	To display text
lastName	Text Field	Last Name	To enter last name
SSN	Text Field	SSN/Tax ID	To enter SSN or Tax ID
Phone Number	Text	Phone Number	To display text
phoneNumber	Text Field	Phone Number	To enter phone number
search	HTML	Search	To perform Search
	button		operation
cancel	HTML	Cancel	To reset the all search fields
	button
Search Table	HTML		To list the Complainant ID,
	Table		Company Name, First
			Name, Last Name and
			Phone number is
			displayed on the screen

3.1.1.2. SID, Element Name, Element Type & Purpose
SID: bpi.enrollment.grievance.grievancecreate (See FIG. I-62)


Element Name	Element Type	Label	Purpose

Complainant Type	Text	Complainant Type	To display text
Complainant Type	Text	Complainant Type	To display complainant type
			dynamically
Complainant ID	Text	Complainant ID	To display text
Complainant ID	Text	Complainant ID	To display complainant type
			dynamically
Group Information	HTML Table	Group Information	To display company name,
			contact name, address, phone,
			effective date, ROE date, status
Postmark Date	Text	Postmark Date	To display text
postMarkDate	Calendar	Postmark Date	To enter the postmark date
Received date	Text	Received date	To display text
receivedDate	Calendar	Received date	To enter the received date
Nature of	Text	Nature of Grievance	To display text
Grievance
natureOfGrievance	List	Nature of Grievance	To list the Nature of Grievance.
			Upon selection of the Nature of
			Grievance, the corresponding
			Grievance Type is displayed on
			the screen
Subject of	Text	Subject of Grievance	To display text
Grievance
subjectOfGrievance	List	Subject of Grievance	To list the subject of Grievance
			for selection
Urgent	Text	Urgent	To display text
urgent	Checkbox	Urgent	To select the option of having
			urgent.
Remarks	Text	Remarks	To display text
remarks	Text Area	Remarks	to enter remarks larger area is
			provided
save	HTML button	Save	Submit the data and save in the
			database
cancel	HTML button	Cancel	To reset to previous status as
			was on loading the page

Screen Validations


Element Name	Action/Validation Details	Message

Postmark Date	Should default to system date.	Error Dialog Box:
	Postmark date can never be a future	“Please choose the correct date. Postmark
	date and can be one day older than	date can be a future date.
	current date only
Received date	Should default to system date.	Error Dialog Box:
	Received date can never be a future	“Please choose the correct date. Received
	date and should be equal to OR	date can be a future date.”
	greater than current date.
Nature of Grievance	Default Option should be --Choose	Error Dialog Box:
	One-- Should list all the types of	“Please choose the nature of grievance_”
	Natures of Grievances
Subject of	Default Option should be --Choose	Error Dialog Box:
Grievance	One-- Should list all the types of	“Please choose the subject of grievance_”
	subject of Grievances
Remarks	Entry Text Area to enter the	None
	remarks for the Grievance. The text
	area should have scrollbar if the
	content within the text area grows.
Save	Should function On clicking the	Error Dialog Box:
	Save Button or pressing the Enter	“The value entered for ‘FIELD NAME’ is
	key with cursor on the “Save	incorrect. Please enter the correct value.”
	Button”	Note: The “FIELD NAME” name should be
	Save the data to the repository with	dynamically picked based on the name of
	the status of the Grievance as open	the field for which the error has occurred.
	Auto generate the grievance ID
Cancel	Should reset to the status as was on	None
	loading the page on clicking the
	cancel button

3.1.1.3. SID, Element Name, Element Type & Purpose
bpi.enrollment.grievance.grievancemodify (See FIG. I-63)


Element Name	Element Type	Label	Purpose

Search by	Text	Search by Complainant	To display text
Complainant
searchType	Radio button	Search by Complainant	To select the option of search
Search by	Text	Search by Grievance	To display text
Grievance
searchType	Radio button	Search by Grievance	To select the option of search
Grievance ID	Text	Grievance ID	To display text
grievanceID	Read only field	Grievance ID	To display Grievance ID. Ability to
			search for open Grievances
Complainant ID	Text	Complainant ID	To display text
appellantId	Entry Field	Complainant ID	To enter complainant ID. Ability to
			search for open Grievances for the
			specific complainant.
search	Button	Search	To search for the Grievance ID or
			the Complainant ID (group or
			member id) with open grievances
Grievance	HTML Table	Grievance Process Table	List the grievances based on the
Process Table			search criteria.
Process	HTML Button	Process	To show the grievance selected for
			further processing
Grievance	HTML Table	Grievance	Table to display Postmark Date,
			Received Date, Nature of
			Grievance, Subject of Grievance,
			Appellant type, Appellant ID,
			Grievance Status, Remarks.
Additional	Text	Additional Remarks	To display text
Remarks
additionalRemarks	Entry Field	Additional Remarks	To enter text
Forward for	Text	Forward for Approval	To display text
Approval
forwardForApproval	Check box	Forward for Approval	To check if forwarding for approval
Forward to	Text	Forward to	To display text
forwardedTo	Entry Field	Forward to	if “Forwarded for Approval” is
			checked then this field must be
			completed. To enter the name of
			the person to whom the Grievance
			is to be forwarded
Forward Date	Text	Forward Date	To display text
forwardDate	Calendar	Forward Date	If “Forward for Approval” is
			checked then this field must be
			completed. Enter the forward date
Batch Date	Text	Batch Date	To display text
batchDate	Calendar	Batch Date	To enter batch date
save	HTML button	Save	Save the data and save in the
			database
cancel	HTML button	Cancel	To reset to previous status as was on
			loading the page

Screen Validations


Element Name	Action/Validation Details	Message

Grievance	Entry field to enter grievance ID and on	Error Message:
	tab should populate the Grievance based	“The grievance ID not available”
	on the Grievance id
Complainant	Entry fields to enter Complainant ID	Error Message:
	and on tab should populate all the	“Complainant ID not available”
	Grievances for the specific appellant.
Search	Search for the Grievance ID or	None
	Appellant ID
Grievance Process	The table gets populated based on the	None
Table	search criteria. For Grievance ID the
	table shows only one grievance. For
	Appellant search the table shows all the
	grievances for the specific Appellant.
Process	Process the specific Row in the table	NONE
	selected
Grievance	Table to display Postmark Date,	None
	Received Date, Nature of Grievance,
	Subject of Grievance, Appellant Type,
	Appellant ID, Grievance Status,
	Remarks.
Additional Remarks	Entry field for additional remarks	None
Forward for	Check box to check if forward or not.	None
Approval
Forward To	If “Forward for Approval” is checked	Error Dialog Box:
	then this field must be completed. To	“Please Enter the Forwarded to persons
	enter the name of the person to whom	name”
	the Grievance is to be forwarded
Forward Date	Allow entering the date or picking up	Error Dialog Box:
	from the calendar	“Please Enter the Forwarded Date”
	if “Forward for Approval” is checked
	then this field must be completed. Enter
	the forward date
Batch Date	Allow entering the batch date or picking	None
	up from the calendar
Save	Should function On clicking the Save	Error Dialog Box:
	Button or pressing the Enter key with	“The value entered for ‘FIELD NAME’ is
	cursor on the “Save Button”	incorrect. Please enter the correct
	Save the data on clicking the save	value.” Note: The “FIELD NAME” name
	button.	should be dynamically picked based on
		the name of the field for which the error
		has occurred.
Cancel	Reset to the state as was on loading the	None
	page

3.1.1.4. SID, Element Name, Element Type & Purpose
SID: bpi.enrollment.grievance.grievanceclose (See FIG. I-64)


Element Name	Element Type	Label	Purpose

Search by	Text	Search by Complainant	To display text
Complainant
searchType	Radio button	Search by Complainant	To select the option of search
Search by	Text	Search by Grievance	To display text
Grievance
searchType	Radio button	Search by Grievance	To select the option of search
Grievance ID	Text	Grievance ID	To display text
grievanceID	Entry Field	Grievance ID	To enter Grievance ID. Ability to
			search for open Grievances
Complainant ID	Text		To display text
complainant ID	Text	Complainant ID	To display Complainant ID. Ability
			to search for open Grievances for
			the specific complainant.
search	Button	Search	To search for the Grievance ID or
			the Complainant ID (group or
			member id) with open grievances
Grievance	HTML Table	Grievance Close Table	List the grievances based on the
Close Table			search criteria.
Grievance	HTML Table	Grievance Table	Table to display Postmark Date,
Table			Received Date, Nature of
			Grievance, Subject of Grievance,
			Appellant Type, Appellant ID,
			Grievance Status, Remarks.
Conclusion	Text	Conclusion	To display text
conclusion	List	Conclusion	List the conclusion of appeal as
			Approved, Denied, or Cancelled
Reason	Text	Reason	To display text
reason	List	Reason	List the Reason for the conclusion
otherReason	Entry Field	Other Reason	To enter reason not included in
			Reason List
Batch Date	Text	Batch Date	To display text
batchDate	Calendar	Batch Date	To enter batch date
save	HTML button	Save	Save the data and save in the
			database

Screen Validations


Element Name	Action/Validation Details	Message

Grievance	Entry field to enter grievance ID	Error Message:
		“Grievance ID is required”
Complainant	Entry fields to enter Complainant ID.	Error Message:
		“Complainant ID is required”
Search	Search for the Grievance ID or Appellant	None
	ID
Grievance Close	The table gets populated based on the	None
Table	search criteria. For Grievance ID the
	table shows only one grievance. For
	Appellant search the table shows all the
	grievances for the specific Appellant.
Close	Process the specific Row in the table	NONE
	selected
Conclusion	Default option should be --choose one--.	None
	List the conclusion for closing the
	grievance as Approved, Denied or
	cancelled
Reason	Default option should be --choose one--.	None
	List the reasons applicable
Other Reason	If the reason selected is others the enter	None
	the other reason
Batch Date	Allow entering the batch date or picking	None
	up from the calendar
Submit	Should function On clicking the Submit	Error Dialog Box:
	Button or pressing the Enter key with	“The value entered for ‘FIELD NAME’ is
	cursor on the “Submit “Button”	incorrect. Please enter the correct
	Save the data on clicking the submit	value.”
	button.	Note: The “FIELD NAME” name should
		be dynamically picked based on the
		name of the field for which the error
		has occurred.

3.1.2. Screen Flow

(See FIG. I-65)

4. Business Rule Mapping


Activity	Rules

Appeals and	Appeals and grievance is the screen that needs to be
grievance	handled by personnel skilled with the operations of the
	PacAdvantage and the governing rules.
	All appeals are entered and followed up for the outcome of
	the appeals. The tum around time for the appeals should be
	3 days at the BPI office for entering the record and
	gathering the reports and summarizing the history.

Benefit Partners Inc

Process Specification

Association Master

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the process of Association Master. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.

1.2. Business Use Case Specification Reference


Business Use Specification ID	Business Use Case Name

BPI_SCOPE_EN	Enrollment
SCOPE_ADD	Addendum to the Scope Document
BPI_SCOPE_EN_01	Business Use case specification - Group
	Enrollment
BPI_SCOPE_EN_03	Business Use case specification - Create
	Individual Association

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background

- Associations are basically a body of groups/members representing certain types of associations within the State of California. Association Groups and Association Members can participate in the Pac Advantage program similar to small employer groups or members. Associations are classified as Guaranteed, Endorsed, PEO's or Chambers. Each of the associations classified have specific business rules when participating in PacAdvantage program. This document identifies the rules and business governing the association groups and members.

2.2. Process Description

- The objective of the Association Master is to:
- 1) Create a master record for the association based on the classification of the association and specify the business rules associated with these classifications.
- 2) The master record for association includes
  - General information about the association
  - Contact information
  - Coverage Information
  - Agent information
  - Other information like internal work group, membership status etc.

2.3. Process Flow
Process for Association Master

- Create, modify or inactivate an association master is the basic operations that can be performed on the association master.
- 1) Enter general information about the association. The general information includes
  - Association Type
  - Association Name
  - Affiliation ID
  - Address
  - Suite
  - City
  - State
  - ZIP
- 2) Enter contact information. The contact information includes
  - Salutation
  - First Name
  - Middle Initial
  - Last Name
  - Suffix
  - Contact Phone
  - Contact Fax
  - Email Address
- 3) Enter coverage information. Coverage information includes
  - Line of coverage offered
  - Domestic Partner Coverage
  - Rate Type
  - Admin Fees Type (Note: This are captured in Carrier Maintenance Module (Rate Classification)
  - Agent Fees Type (Note: This are captured in Carrier Maintenance Module (Rate Classification)
  - Additional Fees type (Note: This are captured in Carrier Maintenance Module (Rate Classification)
- 4) Enter other information. Other information includes
  - Internal Work group
  - Membership status
  - Contract Date
  - Association re qualification period
  - Special Handling

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's


Screen ID (SID)	Screen Name	Corresponding HTML File Name

enrollment.association.associationgeneral	Association	/bpi/cas/enrollment/association/associationgeneral/AssociationGeneralInfo.jsp
	General Info
enrollment.association.associationcoveraeg	Association	/bpi/cas/enrollment/association/associationcoverage/AssociationCoverageInfo.jsp
	Coverage Info
enrollment.association.associationother	Association	/bpi/cas/enrollment/association/associationother/AssociationOtherInfo.jsp
	Other Info
enrollment.association.associationconfirm	Association	/bpi/cas/enrollment/association/associationconfirm/AssociationConfirm.jsp
	Confirmation
enrollment.association.internalworkgroupsearch	Internal Work	/bpi/cas/enrollment/association/internalworkgroupsearch/InternalWorkGroupSearch.jsp
	Group Search
enrollment.association.associationgeneralsearch	Association	/bpi/cas/enrollment/association/associationgeneral/AssociationGeneralSearch.jsp
	Search

3.1.1.1. SID, Element Name, Element Type & Purpose

- SID: enrollment.association.associationgeneral
- Screen Snap Shot (See FIG. I-66)


Element
Name	Element Type	Purpose

General	Header Text	To provide content for header
Information
Association	Text	To provide text
name
Association	Entry Field	Enter association name
name
Search	HTMLButton	To show pop up window to search for
		the association name for editing the data
Association	Text	To provide text
Type
Association	Drop Down List	List the types of association to select
Type		from
Address	Sub Header	To provide content for sub header
Information
Address	Text	To provide text
Address	Entry field	Enter the address
Suite	Text	To provide text
Suite	Entry field	Enter the suite number
City	Text	To provide text
City	Entry field	Enter the city name
State	Text	To provide text
State	Drop Down List	List the states in USA for selection
ZIP	Text	To provide text
ZIP	Entry field	Enter the ZIP code
Contact	Sub Header for	Text for sub header content
Information	contact
	information
Salutation	Text	To provide text
Salutation	Drop Down List	Select the salutation
First Name	Text	To provide text
First name	Entry field	Enter first name
MI	Text	To provide text
MI	Entry field	Enter Middle initial
Last name	Text	To provide text
Last name	Entry field	Enter last name
Suffix	Text	To provide text
Suffix	Drop down List	To select the suffix
Phone	Text	To provide text
Phone	Entry field	Enter phone number
Extension	Text	To provide text
Extension	Entry field	Enter extension number
FAX	Text	To provide text
Fax	Entry Field	Enter the Fax number
Email	Text	To provide text
Email	Entry field	Enter the email address
Continue	HTML Button	Save and continue to the next screen
		BPI_CAS_SCR_EN_007_002
Cancel	Reset Button	Reset to the status as was on loading
		the page

- SID: enrollmentassociation.associationcoverage


Element	Element
Name	Type	Purpose

Coverage	Header Text	To provide header for Coverage
Information
Line of	Text	To provide text
coverage
Line of	Check boxes	Check boxes to select multiple line of
Coverage		coverage offered
Domestic	Text	To provide text
Partner
Coverage
Domestic	Radio Boxes	To choose yes or no for domestic partner
Partner		coverage
Coverage
Coverage	Text	To provide text
Rate Type
Coverage	Radio Boxes	To choose if the rate type is blended or non
Rate type		blended
Continue	HTML	Submit button to save the data entered in to
	Button	the. repository and navigate to the next
		screen BPI_CAS_SCR_EN_007_003
Cancel	HTML reset	To reset to the status as was on loading
	Button	the page

- SID: enrollment.association.associationother
- Screen Snap Shot (See FIG. I-68)


Element
Name	Element Type	Purpose

Other	Header text	To provide text for the header
Information
Internal work	Text	To provide text
group
Internal work	Entry field	Enter the work group ID
group
Search	HTML Button	Button to search for the work group to be
		attached to the association
Membership	Text	To provide text
status
Membership	Drop down list	List the membership status as active, closed or
status		frozen
Contract Date	Entry field (Calendar)	To enter or pick up the association's effective
		date
Association re	Entry field (Calendar)	To enter or pick up the association's re
qualification		qualification date
period
Batch billing	Text	To provide text
Batch billing	Radio box	To specify if the association groups and
		members are to billed as one batch
Desired	Text	To provide text
Association
name on the
bill
Desired	Radio Box	To specify if the Association name should be on
Association		the bill or not
name on the
bill
Continue	HTML Button	Button to save the information on this page
Clear	HTML reset Button	To reset to the status as was on loading the page

- SID: enrollment.association.associationconfirm
- Screen Snap Shot (See FIG. I-69)
- SID: enrollmentassociation.internalworkgroupsearch
- Screen Snap Shot (See FIG. 70)
- SID: enrollment.association.associationgeneralsearch
- Screen Snap Shot (See FIG. I-71)

3.1.2. Screen Flow

(See FIG. I-72)

4. Business Rule Mapping


Activity	Rules

Allow	Are eligible to enroll at any time and follow business rules
Employer	for Non-Association Small Employer Groups 2-50.
Groups 2-50	This rule applies for Guaranteed, Endorsed, PEO's and
	Chambers
Allow	Must have a membership number and apply after 60 days
Individual	(read as waiting period), but within 120 days, of becoming
Members	a member of the Association or of a group sponsored for
	coverage. Effective date of coverage will be within
	45 days of receipt of a completed application. Declines
	must wait until Open Enrollment. Waives may enroll
	within 30 days of losing other employer-sponsored
	coverage. The Individual Association member is required
	to enroll in all lines of coverage offered by the Association
	master. The Individual Association member is not eligible
	for COBRA.
	This is applicable only to Guaranteed association
Allow	Are eligible to enroll at any time and follow business rules
Employer	for Small Employer Groups 2-50 EXCEPT for the size of
Groups >100	the group for Guaranteed association (Group size can be
	un limited for guaranteed association)
Rates	Rate for each association for various rate classification are
	defined in the carrier maintenance module (Admin Fees,
	Agent Commission, Additional Fees and Rate differential)
Agent	All associations have an Agency and/or Agent(s).
	Commissions are applicable to both Group's an
	Association Member's. For both, the agent is attached at
	the Group/Association member, but can only be chosen
	from the particular agents attached to the association.
	Agent is selected based on the internal work group
	assigned to the agent/agency.
Screen	Small employer group after identifying the association
Rules	would follow the same navigation as applicable for the
for Group	Small employer group. The Group Affiliated to an
	association should also have the Membership Number and
	the date of membership.
Screen	Individual association would follow the same navigation
Rules for	as applicable to the employee after selecting the
Individual	association and validating that the association is
Association	guaranteed. The only additional things needed are a
members	“Membership Number” and a “Date of Membership”.
	Essentially the “Date of Membership” replaces the
	employee “Date of Hire” for an employee

Benefit Partners Inc

Process Specification

Carrier Issues

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the process of Carrier Issues. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.

1.2. Business Use Case Specification Reference

1.3. Definitions, Acronyms & Abbreviations


Term	Explanation

BPI_CAS_FSD_EN	Functional Specification Document -
	Enrollment
BPI_CAS_FSD_EN_001	Process Specification - New Business
	Enrollment
BPI_CAS_FSD_EN_002	Process Specification - Enrollment Changes/
	Add-On
BPI_CAS_FSD_EN_003	Process Specification - COBRA Enrollment/
	Changes
BPI_CAS_FSD_EN_004	Process Specification - ROE/OE
BPI_CAS_FSD_EN_005	Process Specification - Termination/
	Reinstatement

2. Process Identification

2.1. Background

- Various issues can arise for a member or group once enrolled with a carrier through PacAdvantage. These issues can vary from not receiving identification cards to incomplete transmission upload by the carrier. As PacAdvantage becomes aware of these issues it is their responsibility to resolve the issue in a timely manner acting as a liaison between the member and the carrier. All issues need to be tracked from start to finish by reason for issue and related carrier for reporting on performance standards as well providing information to PacAdvantage-SF regarding recurring issues within a carrier.
- Issues can arise at the Group level, for all members on a group and/or all members on a line of coverage. Issues can also arise at the Employee level and/or Dependent level, by member and/or by plan.
- Within PacAdvantage there are personnel who specifically handle all carrier related issues. Other representatives within PacAdvantage can receive the initial request, document it as needed and forward it to the Carrier Issue personnel. The Carrier Issue personnel contact the carrier to resolve the issue. They mark the documentation as needed and then close the issue and forward the resolutions back to the initial requestor (Originator). The Originator informs the member/group of resolution.

2.2. Process Description

- The objective of the Carrier Issues process is to:
  - 1) Maintain a status for all Carrier Issues received from the customer and follow up with the carrier for resolution and inform the customer of resolution.
- The following are the other requirements that will be supported and constraints on the proposed system:
  - 1) The system would track the initial request from open to close.
  - 2) The system would track both the reported issue and the actual issue.
  - 3) The system would track the final resolution.
  - 4) The system would also have a history of all the transactions to get the report for the Reported Issue.

2.3. Process Flow
Process for Carrier Issues

- 1) Representative is notified of the issue by the customer and cannot resolve the issue alone.
- 2) Representative initiates a request either from the Group level, Employee level, or Dependent level.
- 3) The representative categorizes the reported issue and provides any supporting documentation.
- 4) The issue is marked as “Open” for the Carrier Issue personnel to handle.
- 5) The Carrier Issue personnel contact the carrier.
- 6) The Carrier Issue personnel provide the carrier with necessary information to resolve the issue. (i.e. re-transmission, e-mail of information)
- 7) The Carrier Issue personnel mark the issue as “Closed” and inform the Originator.
- 8) The originator follows-up with the member.

3. User Interface

3.1. User Interface Screens
3.1.1. Screen ID's

- <List SID and the screen name and Corresponding HTML file for the screen.


		Corresponding
Screen ID (SID)	Screen Name	HTML File Name

bpi.enrollment.carrierissue.carrierissuesearch	Carrier Issue Search	carrierissuesearch
bpi.enrollment.carrierissue.carrierissuecreate	Carrier Issue	carrierissuecreate
	Create
bpi.enrollment.carrierissue.carrierissuemodify	Carrier Issue	carrierissuemodify
	Modify
bpi.enrollment.carrierissue.carrierissueclose	Carrier Issue	carrierissueclose
	Close

3.1.1.1. SID, Element Name, Element Type & Purpose

- SID: bpi.enrollment.carrierissue.carrierissuesearch (See FIG. I-73)


	Element
Element Name	Type	Label	Purpose

Customer Type	Text	Customer	To display text
		Type
clientType	Radio	Customer	To select the type
	button	Type	“Group” or “Member”
Customer ID	Text	Customer ID	To display text
clientId	Text Field	Customer ID	To enter complainant id
Company	Text	Company	To display text
Name		Name
companyName	Text Field	Company	To enter company name
		Name
First Name	Text	First Name	To display text
firstName	Text Field	First Name	To enter first name
Last Name	Text	Last Name	To display text
lastName	Text Field	Last Name	To enter last name
SSN	Text Field	SSN/Tax ID	To enter SSN or Tax ID
SSN	Text Field	SSN/Tax ID	To enter SSN or Tax ID
Phone Number	Text	Phone	To display text
		Number
phoneNumber	Text Field	Phone	To enter phone number
		Number
search	HTML	Search	To perform Search operation
	button
cancel	HTML	Cancel	To reset the all search fields
	button
Search Table	HTML		To list the Complainant ID,
	Table		Company Name, First Name,
			Last Name and Phone number
			is displayed on the screen

3.1.1.2. SID, Element Name, Element Type & Purpose

- SID: bpi.enrollment.carrierissue.carrierissuecreate (See FIG. I-74)


Element Name	Element Type	Purpose

Received date	Text	To display text
Received date	Calendar	To enter the received date
Reported Issue	Text	To display text
Reported Issue	List	To list the Reported Issue
Group	Entry Field	To enter Group ID if Client Type is Group. Ability to
		search for Group, upon selection or entry of the Group,
		the group's general information is displayed (Company
		Name, Contact Name, Address, Phone, Effective Date,
		ROE Date, Status)
Member	Entry Field	To enter Member ID if Client Type is Member. Ability
		to search for Member, upon selection or entry of the
		member ID, the member's general information is
		displayed (Name, Address, Phone, Effective Date, ROE
		Date, Status, Benefit Level, Coverage Choice)
Remarks	Text	To display text
Remarks	Entry Field	To enter remarks
Submit	HTML button	Submit the data and save in the database
Cancel	HTML button	To reset to previous status as was on loading the page
Cancel	HTML button	To reset to previous status as was on loading the page

Screen Validations


Element Name	Action/Validation Details	Message

Received date	Should default to system date.	Error Dialog Box:
	Received date can never be a future	“Please choose the correct date.
	date.	Received date can be a future date.”
Reported Issue	Default Option should be --Choose	Error Dialog Box:
	One-- Should list all the types of	“Please choose the reported issue.”
	Reported Issues
Client Type	Option to choose Group or member	None
	with radio button group.
Client	Entry field to enter the group ID or	None
	member ID based on the Client type
	selected. Based on the Client selected
	Display the Group or member
	information in the HTML table.
Search	Pop up window to search for the	None
	Group or Member based on the Client
	type selected.
Group	HTML Table to display the Group	None
	Information
Member	HTML Table to display member	None
	information
Remarks	Entry Text Area to enter the remarks	None
	for the Carrier Issue. The text area
	should have scrollbar if the content
	within the text area grows.
Submit	Should function On clicking the	Error Dialog Box:
	Submit Button or pressing the Enter	“The value entered for ‘FIELD NAME’
	key with cursor on the “Submit	is incorrect. Please enter the correct
	Button”	value.”
	Save the data to the repository with	Note: The “FIELD NAME” name
	the status of the Carrier Issue as open.	should be dynamically picked
	Auto generate the Carrier Issue ID	based on the name of the field for
		which the error has occurred.
Cancel	Should reset to the status as was on	None
	loading the page on clicking the
	cancel button

3.1.1.3. SID, Element Name, Element Type & Purpose

- SID: bpi.emollment.carrierissue.carrierissuemodify (See FIG. I-75)


Element Name	Element Type	Purpose

Carrier Issue ID	Text	To display text
Carrier Issue ID	Entry Field	To enter Carrier Issue ID. Ability to search for open
		Carrier Issues
Client	Text	To display text
Client	Entry Field	To enter client ID. Ability to search for open Issues for
		the specific client
Search	Pop Up window	To search for the Carrier Issue ID or the Client ID
		(group or member id) with open issues
Carrier Issue Process	HTML Table	List the issues based on the search criteria
Table
Process	HTML Button	To show the issue selected for further processing
Carrier Issue	HTML Table	Table to display Received Date, Reported Issue, Client
		Type, Client ID, Issue Status, Remarks.
Additional Remarks	Text	To display text
Additional Remarks	Entry Field	To enter text
Notify Carrier	Text	To display text
Notify Carrier	Radio Button	To check if notifying to carrier
Mode of Notification	Text	To display text
Mode of Notification	List Box	If “Notify Carrier” is checked then this field must be
		completed. To enter the mode of notification
Date Notified	Text	To display text
Date Notified	Calendar	If “Notify Carrier” is checked then this field must be
		completed. Enter the notified date
Batch Date	Text	To display text
Batch Date	Calendar	To enter batch date
Submit	HTML button	Submit the data and save in the database
Cancel	HTML button	To reset to previous status as was on loading the page

Screen Validations


Element Name	Action/Validation Details	Message

Carrier Issue	Entry field to enter Carrier Issue ID	Error Message:
	and on tab should populate the Carrier	“Carrier Issue ID is required”
	Issue based on the Carrier Issue id
Client	Entry fields to enter Client ID and on	Error Message:
	tab should populate all the Carrier	“Client ID is required”
	issues for the specific Client.
Search	search for the Carrier Issue ID or	None
	Client ID
Carrier Issue	The table gets populated based on the	None
Process Table	search criteria. For Carrier Issue ID
	the table shows only one Carrier
	Issue. For Client search the table
	shows all the Carrier Issues for the
	specific Client
Process	Process the specific Row in the table	NONE
	selected
Carrier Issue	Table to display Received Date,	None
	Reported Issue, Client Type, Client
	ID, Issue Status, Remarks.
Additional Remarks	Entry field for additional remarks	None
Notify Carrier	Radio button to select if notify or not	None
Mode of	If “Notify Carrier” is yes then this	Error Dialog Box:
Notification	field must be completed. To enter the	“Please Enter the Mode of
	Mode of Notification for whom the	Notification”
	Issue is to be forwarded
Date Notified	Allow entering the date or picking up	Error Dialog Box:
	from the calendar	“Please Enter the Notified Date”
	If “Notify Carrier” is yes then this
	field must be completed. Enter the
	notified date
Batch Date	Allow entering the batch date or	None
	picking up from the calendar
Submit	Should function On clicking the	Error Dialog Box:
	Submit Button or pressing the Enter	“The value entered for ‘FIELD NAME’
	key with cursor on the “Submit	is incorrect. Please enter the correct
	Button”	value.”
	Save the data on clicking the submit	Note: The “FIELD NAME” name
	button. If the Mode of Notification is	should be dynamically picked
	Email, then open new message with	based on the name of the field for
	appropriate information. If Mode of	which the error has occurred.
	Notification is Fax, then enter
	appropriate information for fax.
Cancel	Reset to the state as was on loading	None
	the page

3.1.1.4. SID, Element Name, Element Type & Purpose

- SID: bpi.enrollment.carrierissue.carrierissueclose (See FIG. I-76)


Element Name	Element Type	Label	Purpose

Search by	Text	Search by Customer	To display text
Customer
searchType	Radio button	Search by Customer	To select the option of search
Search by	Text	Search by Carrier	To display text
Carrier Issue		Issue
searchType	Radio button	Search by Carrier	To select the option of search
		Issue
Carrier Issue ID	Text	Carrier Issue ID	To display text
carrierIssueId	Entry Field	Carrier Issue ID	To enter Carrier Issue ID. Ability to search
			for open Carrier Issue
Customer ID	Text		To display text
customerId	Text Field	Customer ID	To display Customer ID. Ability to search
			for open Carrier Issue for the specific
			Customer
search	Button	Search	To search for the Carrier Issue ID or the
			Customer ID (group or member id) with
			open carrier issues
Carrier Issue	HTML Table	Carrier Issue Close	List the carrier issue based on the search
Close Table		Table	criteria.
Carrier Issue	HTML Table	Carrier Issue Table	Table to display Received Date, Reported
Table			Issue, Client Type, Client ID, Issue Status,
			Remarks.
Actual Issue	Text	To display text	Actual Issue
Actual Issue	List	List the Actual Issue	Actual Issue
Retransmission	Text	Retransmission	To display text
Retransmission	Radio button	Retransmission	Select if retransmission needed or not
Resolution	Text	Resolution	To display text
Resolution	List	Resolution	List the Resolution of Issue as Verbally
			Updated; Retransmitted, etc.
Resolution	Text	Resolution	To display text
Comments		Comments
Resolution	Entry Field	Resolution	To enter text
Comments		Comments
Date Carrier	Text	Date Carrier	To display text
Resolved		Resolved
Date Carrier	Calendar	Date Carrier	To enter date Carrier resolved
Resolved		Resolved
Batch Date	Text	Batch Date	To display text
Batch Date	Calendar	Batch Date	To enter batch date
Notify	Text	Notify Originator	To display text
Originator
Notify	Radio Button	Notify Originator	To select if notifying to Originator
Originator
save	HTML button	Save	Submit the data and save in the database

Screen Validations


Element Name	Action/Validation Details	Message

Carrier Issue	Entry field to enter Carrier Issue ID	Error Message:
	and on tab should populate the Carrier	“Carrier Issue ID is required”
	Issue based on the Carrier Issue id
Customer	Entry fields to enter Client ID and on	Error Message:
	tab should populate all the Carrier	“Customer ID is required”
	Issues for the specific Client.
Search	search for the Carrier Issue ID or	None
	Client ID
Carrier Issue	The table gets populated based on the	None
Process Table	search criteria. For Carrier Issue ID
	the table shows only one Carrier
	Issue. For Client search the table
	shows all the Carrier Issues for the
	specific Client.
Close	Close the specific Row in the table	None
	selected
Carrier Issue	Table to display Received Date,	None
	Reported Issue, Client Type, Client
	ID, Issue Status, Remarks.
Actual Issue	Default option should be the same as
	reported issue. List all issues.
Retransmission	Radio button to select if retransmit or	None
	not
Resolution	Default option should be --choose
	one--. List the resolutions for closing
	the issue as Updated, Denied or
	cancelled
Resolution	Entry field for additional comments	None
Comments
Date Carrier	Allow entering the date or picking up	None
Resolved	from the calendar
	If “Notify Carrier” is yes then this
	field must be completed. Enter the
	notified date
Batch Date	Allow entering the batch date or	None
	picking up from the calendar
Notify Originator	Radio button to select if notify or not.
	If yes send pre-formatted email to
	Originator.
Submit	Should function On clicking the	Error Dialog Box:
	Submit Button or pressing the Enter	“The value entered for ‘FIELD NAME’
	key with cursor on the “Submit	is incorrect. Please enter the correct
	Button”	value.”
	Save the data on clicking the submit	Note: The “FIELD NAME” name
	button. If the Mode of Notification is	should be dynamically picked
	Email, then open new message with	based on the name of the field for
	appropriate information. If Mode of	which the error has occurred.
	Notification is Fax, then enter
	appropriate information for fax.
Cancel	Reset to the state as was on loading	None
	the page

3.1.2. Screen Flow

(See FIG. I-77)

4. Business Rule Mapping


Activity	Rules

Carrier Issues	Carrier Issue is the screen that needs to be handled by
	personnel skilled with the operations of the
	PacAdvantage and the coordination of data with the
	Carriers.
	All issues are entered and followed up for the resolution
	of the issue.

Benefit Partners

Process Specification

Billing

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the process of Billing. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.

1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_FI_001	Finance - Business use case
		Specification - Billing

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background

- Billing is the process of creating the invoice for the Customers enrolled in the PacAdvantage program. The Invoice is on broad base classified into two—First Time Invoice (invoice to the group/member that has enrolled as new business) and Running invoice or periodic invoice (To the existing Group/Members).

2.2. Process Description

- The objective of the Billing process is to:
  - 1) Generate first time invoice to the groups/members who have enrolled as new business. The invoice should get all the information about the group/member prior to invoicing. Generation of first time invoice is an automated process and should be triggered on completion of group/member enrollment.
  - 2) Generate running invoice or periodic invoice to the existing groups/members. All the information about the existing group/members and their real time transaction details are required to invoice correctly.
- This billing sub module also needs to have a feature to incorporate the following.
  - Suppress periodic Bill for a specific Group/Member or collective group and members
  - Preview invoice prior to creation of actual invoice.
  - Suppress late fee for a specific Group/Member or collective group and members
  - Calculate Reinstatement Fee for a specific Group/Member or collective group and members
  - Include feature to add dynamic content on the bills sent to the for a specific Group/Member or collective groups and members
  - Calculate additional fee for Credit card transaction if applicable.
  - Calculate adjustment when there is retrospective change in Benefit Level (for the Carrier Selected) for group/member and make adjustments in the subsequent bill.
  - Calculate adjustment if the group/members have termed.
  - Generate manual invoice and preview invoices before generating them.
  - All billing transactions would be period specific (i.e. the bills would be associated with the month of coverage). Invoices would be run only on a monthly basis, whatever is the billing frequency. For example if the billing frequency opted is quarterly. The excess amount would be adjusted as credits in the subsequent month's invoices.
  - Invoice view/preview prior to generation of invoice needs to be provided in the Enrollment module.

2.3. Process Flow
Process for Billing—First Time Invoice

- 1) Enrollment is completed for the new business prior to generation of First Time Invoice.
- 2) All information relevant for billing (Generation of Invoice is gathered) These information are
  - Group ID
  - Group Billing Address
  - Billing information for the group like billing frequency, mode of payment and relevant information for mode of payment like EFT or Credit Card.
  - Employees and Dependents information
  - Member count
  - Employer Contribution
  - Employee Contribution
  - Raw Rate for Each of the Benefit Level for the specific Carrier selected by the employee (for specific Age bracket, Service Area, Coverage Choice with effective date)
  - Rate differential based on member count (Group size) with effective date
  - Admin fees for the specific group type with effective date.
  - Agent commission that is defined in the Agent Info tab for the group if defined. Otherwise the default agent commission specified in the Carrier Maintenance Module (Agent Commission Fees) with effective date.
  - Additional fees if any for the specific group type with effective date.

Process for Billing—Running Invoice (Periodic Invoice)

- 1) Monthly or periodic invoice is sent to the existing group/members based on the Frequency selected by the group/member and the mode of communication preferred.
- 2) Existing billing also gathers all information relevant for billing.
- 3) In addition to this it also needs the previous invoice history to calculate the additional fees, late fees, reinstatement fees or as applicable.
- 4) The running invoice generated is for the coverage period following the previous invoice period. I.e if the previous invoice was generated in the month of Jan. 5 2002 and for the coverage period February 2002, The invoice generate on Feb. 5 2001 would be for the coverage period March 2002,
- 5) Billing should also calculate the Fees required for Credit Card transaction if applicable.
- 6) Adjustment for Add On employee/dependent or member.
- 7) Adjustment for Termed employee/dependent or member.
- 8) Reinstatement fees Termed Group, employee/dependent or member are reinstated.
- 9) Invoice once created by the system cannot be cancelled.
- An invoice is considered closed only if the invoice has been reconciled. Hence all open invoices should be considered for late fee calculation.

3. User Interface

3.1. User Interface Screens
3.1.1. Suppress Batch Billing
3.1.1.1. Screen Snapshot (See FIG. J-1)
3.1.1.2. Element Name, Element Type & Purpose


Element	Element
Name	Type	Label	Purpose

Bill Period	Option Box	Bill Period	Bill period for which batch billing is suppressed
Selected	Display Text	Selected Groups	Displays count of groups selected out of total
Groups			groups

Filter

Group Id	Text Box	Group Id	To filter groups based on group id
Group Name	Text Box	Group Name	To filter groups based on group name
Group Type	Option Box	Group Type	To filter groups based on group type
Group Size	Text Box	Group Size	To filter groups based on group size
ROE Date	Text Box	ROE Date - To	To filter groups based on ROE date of groups
Range
Effective Date	Text Box	Effective Date -	To filter groups based on effective date of groups
Range		To
Rate Type	Option Box	Rate Type	To filter groups based on rate type
View	Option Box	View	To filter groups based on whether batch billing is
			suppressed or not
Filter	Command	Filter	Refreshes group selection table based on the filter
			entered
Clear Filter	Command	Clear Filter	Clears the filter and displays all groups in the
			group selection table
Groups	Selection		For selecting groups for export. Options for
Selection	Table		selection all groups, all groups in a page,
			deselecting all and selection inversion are
			available to the user.
New	Command	New	Clears the screen
Save	Command	Save	Saves the suppressed groups information to the
			database

3.1.1.3. Screen Validations.


Element	Action/Validation
Name	Details	Message

Bill Period	Check to see that	“Please enter a valid billing period”
	billing period is not
	null

3.1.2. Group Auto Bill Suppressing
3.1.2.1. Screen Snapshot (See FIG. J-2)
3.1.2.2. Element Name, Element Type & Purpose


Element	Element
Name	Type	Label	Purpose

Run Id	Display Text	Import Id	Displays unique system
			generated id for the bill
			process run
Bill Period	Option Box	Bill Period	Period for which batch billing
			is run
Run By	Display Text	Run By	Displays id of user who
			initiated the process
New	Command	New	Clears the screen
Process	Command	Process	Starts the batch billing process
View Status	Command	View Status	View status of batch
			billing process

3.1.2.3. Screen Validations


Element
Name	Action/Validation Details	Message

Bill	Check to see that billing	“Please enter a valid billing period”
Period	period is not null

3.1.3. Manual Bill
3.1.3.1. Screen Snapshot (See FIG. J-3)
3.1.3.2 Element Name, Element Tyne & Purpose


Element
Name	Element Type	Label	Purpose

Bill Details

Bill #	Display Text	Bill #	Displays unique system generated bill #
Bill Date	Display Text	Bill Date	Displays bill date
Bill Period	Option Box	Bill Period	Period for which group is billed
Due Date	Display Text	Due Date	Displays date on which bill is due
Status	Display Text	Status	Displays the status of bill: Open or Reconciled
Reconciled	Display Text	Reconciled	Displays date on which bill was reconciled
Date		Date

Group Information

Group Id	Text Box	Group Id	Id of the group being billed
Group Type	Display Text	Group Type	Displays group type
Group name	Display Text	Group Name	Displays group name
Association	Display Text	Association	Displays name of association if group is enrolled
Name		Name	through one
Status	Display Text	Status	Displays status of group
Rate Type	Display Text	Rate Type	Displays the rate type for the group: blended or
			non-blended

Billing Summary

Prior Bill	Display Text	Prior period	Displays prior period bill amount for the group
Amount		billed amount
Adjustments	Display Text	Adjustments	Displays adjustments total for the group
		since prior
		period
Payments	Display Text	Payments	Displays payments made by the group from
		received	previous bill
Current Bill	Display Text	Current bill	Displays current bill amount
		amount
Total Due	Display Text	Total due	Displays total due from the group

Employer Level Adjustments

Adjustment	Option Box	Adjustment	Type of adjustment
Type		Type
Amount	Text Box	Amount	Adjustment Amount
Period	Option Box	Period	Period for which adjustment entry is posted
Adjustments	Entry Table
Entry Table

Employee Level Adjustments

Employee	Display	Employee	Displays name of employee
Name	Column	Name
Period	Display	Period	Displays adjustment period
	Column
Plan Name	Display	Plan Name	Displays the name of the plan
	Column
Plan Type	Display	Plan Type	Displays plan type
	Column
Coverage	Display	Coverage Type	Displays coverage option selected by the employee
Type	Column
# Members	Display	# Members	Displays member count under the employee's
	Column		coverage
Premium	Display	Premium	Displays premium
	Column
Admin Fee	Display	Admin Fee	Displays admin fee
	Column
Agent Fee	Display	Agent Fee	Displays agent fee
	Column
Total	Display	Agent Fee	Displays total premium
Premium	Column

Employee Level Detail

Employee	Display	Employee	Displays name of employee
Name	Column	Name
Plan Name	Display	Plan Name	Displays the name of the plan
	Column
Plan Type	Display	Plan Type	Displays plan type
	Column
Coverage	Display	Coverage Type	Displays coverage option selected by the employee
Type	Column
# Members	Display	# Members	Displays member count under the employee's
	Column		coverage
Premium	Display	Premium	Displays premium
	Column
Admin Fee	Display	Admin Fee	Displays admin fee
	Column
Agent Fee	Display	Agent Fee	Displays agent fee
	Column
Total	Display	Total Premium	Displays total premium
Premium	Column

Bill Summary

Medical	Display Text	Subtotal -	Displays medical premium subtotal
Premium		Medical
		Premium
Dental	Display Text	Subtotal -	Displays dental premium subtotal
Premium		Dental
		Premium
Vision	Display Text	Subtotal -	Displays vision premium subtotal
Premium		Vision
		Premium
CAM	Display Text	Subtotal -	Displays CAM premium subtotal
Premium		CAM Premium
Admin	Display Text	Administration	Displays total of member level admin fee
Member Fee		Member Fee
Agent	Display Text	Agent Member	Displays total of member level agent fee
Member Fee		Fee
Admin Flat	Display Text	Administration	Displays group level admin flat fee
Fee		Flat fee
Agent Flat	Display Text	Agent Flat Fee	Displays group level agent flat fee
Fee
Current Due	Display Text	Total Due	Displays current bill amount
		Current Period
Past Due	Display Text	Add Past	Displays amount due from previous bill
		Amount Due
Total due	Display Text	Total Due	Displays total due from the group
New	Command	New	Clears the screen
Create	Command	Create	Creates the bill

3.1.3.3. Screen Validations


Element
Name	Action/Validation Details	Message

Bill Period	Check to see if bill period is not null	“Please enter
	and is valid	a valid bill period”
Group Id	Check to see if group id is not null	“Please enter a
	and is valid	valid group id”
Adjustment	Check to see that the value for the	“Please enter a valid
Type	filed is not null and is valid	adjustment type”
Amount	Check to see that the value for the	“Please enter a valid
	filed is not null and is valid	adjustment amount”
Period	Check to see that the value for the	“Please enter a valid
	filed is not null and is valid	adjustment period”

3.1.4. Billing Adjustments
3.1.4.1. Screen Snapshot (See FIG. J-4)
3.1.4.2. Element Name, Element Type & Purpose


Element	Element
Name	Type	Label	Purpose

Adjustment Id	Display Text	Adjustment Id	Displays unique system generated id for the
			adjustment
Adjustment	Text Box	Adjustment Date	Adjustment Date
Date
Status	Display Text	Status	Status of the adjustment: Open or Reconciled
Group Id	Text Box	Group Id	Id of group for which adjustment entry is made
Group Type	Display Text	Group Type	Displays group type
Group Name	Display Text	Group Name	Displays group name
Association	Display Text	Association	Displays name of association if group is enrolled
Name		Name	through one
Group Status	Display Text	Group Status	Displays status of group
Adjustment	Option Box	Adjustment Type	Type of adjustment
Type
Amount	Text Box	Amount	Adjustment Amount
Period	Option Box	Period	Period for which adjustment entry is posted
New	Command	New	Clears screen for a new adjustment entry
Save	Command	Save	Saves the adjustment entry to the database
Search	Command	Search	Provides search functionality for adjustments

3.1.4.3. Screen Validations


Element Name	Action/Validation Details	Message

Group Id	Check to see that the value for the	“Please enter a
	filed is not null and is valid	valid group id”
Adjustment	Check to see that the value for the	“Please enter a valid
Type	filed is not null and is valid	adjustment type”
Amount	Check to see that the value for the	“Please enter a valid
	filed is not null and is valid	adjustment amount”
Period	Check to see that the value for the	“Please enter a valid
	filed is not null and is valid	adjustment period”

3.2. Interface Flow

- N/A

4. Business Rule Mapping


Activity	Rules

I - First Time Invoice	Blended

	For Small Employer Group	(New Business) Note: All new business falls under blended rate
		only

	1.	Check All the member for Small Employer Group
	2.	Check the Employee Raw Rate for the Specific Line of Coverage for the (Carrier
		Selected) Benefit Level.
	3.	Apply formula on the entire employee for all the line of coverage provided by the group
		for the (Carrier Selected) Benefit Level (Age Bracket, Coverage Choice and Service Area
		for the specific Employee). Refer Formula
	4.	The Admin Fees, Agent Commission and Rare Differential Factor are governed by the
		effective date. Apply the effective date for these fees with the Effective date for the Group
		in deriving the Blended rate for the employees and the total amount payable by the Group.
		However the Agent commission is based on the one provided at the group level in the
		Agent Information Tab. It overrides the fee provided in the carrier maintenance agent
		commission fees.
	5.	Check if the initial payment made by the group equals the Total amount as derived above.
		If not then check the difference. Allow for Reconciliation up to $2 without and authorized
		intervention. For amount between $50-$3 Allow reconciliation based on security. For
		amount above $50 allow reconciliation based on ultimate authority. (This rule governs if
		the group can be enrolled or not. Hence there should be an invoice preview that identifies
		the Cash received and the total amount due for the new business) This should be viewable
		by all.
	6.	The rate should be picked up based on the rules specified below:
		Check the Effective date for the Group (initial enrollment date)
		Check the rate from the rate table whose effective date is latest but less than the effective
		date of the Group. (E.g.) Group Effective date 3/1/01. Rate effective dates 1/1/01 and
		7/1/01. In this example since the group effective date is 3/1/01 the Rate picked should be
		1/1/01 effective date rate.
	7.	Show the Employer Contribution and the Employee Deduction in the invoice summary.
		Billing Address should be picked up based on the billing address provided by the group. If
		billing address is not provided, then business address should be considered for billing.
		Also check the mode of communication. If the group prefers to be mailed emailed or
		faxed and accordingly transmit the invoice. Refer Sample Invoice 1 for the Small
		Employer Group (New Business)

	Note: Small employer may bring in the COBRA members. Bill the COBRA members
	separately or along with the Group based on the decision made for billing the COBRA Group.

		If the COBRA members are billed separately. Generate a separate invoice for the each
		subscriber COBRA members. Refer Rule for COBRA Member Invoice
		However the bill for the COBRA members can be sent to the primary group if that option
		is selected.
		All COBRA Invoices whether billed to the primary group or the COBRA Group should
		have a separate invoice for all the COBRA groups.

	For COBRA Members	(New Business) Note: All new business falls under blended rate
		only even for COBRA members brought by new business.

	1.	Check the entire subscriber COBRA member for Small Employer Group (primary Group).
	2.	Check Coverage Choice for the Subscriber member for each lines of coverage and also
		note that these line of coverage are selected by the Primary group.
	3.	Check what are the line of coverage picked up be each of the members including the
		subscriber member and their dependent.

Note: The rate for the COBRA member should be based on the following rule.

		Identify the subscriber member line of coverage selected. The age, service area and the
		coverage choice provided by the subscriber member is the governing rate.
		If the subscriber does not select the line of coverage that the dependent member have
		selected. Check if the dependent member have relation ship as spouse or child/children. If
		the Relationship is spouse then the Spouse Age should be the deciding factor for the rate
		and the coverage choice opted.
		If the relationship is child/children then the eldest dependent member should be the
		deciding factor for the rate based on the Age.

	Note however in all the above cases the Service Area is governed by the Service area of the
	Subscriber COBRA member.
	Note: If the Primary COBRA member is a child they have their own Group ID and their own
	line of coverage and benefit level.

	For Individual Association	(New Business) Note: All new business falls under blended rate
	Member	even for the individual association member.

	1.	Individual association member can have dependent attached to the member.
	2.	The rate for the individual association member is governed by the rate applicable for the
		Guaranteed association based on the effective date for the Association.
	3.	The individual members can have the same line of coverage as defined by the association.
	4.	The Admin Fee, Agent Commission, Additional fees and rate differential factor is as
		applicable for the Association with the effective date.
	5.	The calculation formula is the same as applicable for the employee of Small employer
		group.
	6.	The dependents for the individual association members are governed by what has been
		selected by the subscriber individual association member.

	Small employer Group	New Business) Note: All new business falls under blended rate
	affiliated to association	even for the Small employer group affiliated to an association.

	1.	Small employer groups affiliated with an association have the same rules as applicable
		to the Small employer group with exception for the rate.
	2.	The Admin fees, Agent commission, additional fees and Differential factor for the small
		employer groups affiliated with an association are as defined for the Association with
		effective date for the Association.
	3.	However the Agent commission is based on the one provided at the group level in the
		Agent Information Tab. It overrides the fee provided in the carrier maintenance agent
		commission fees

II - First Time Invoice Formula

Blended for Small Employer Group

	Blended Rate = (Raw Rate * Differential Factor)/(1 − Agent Commission % − Admin Fee %)
Example	The formula for the premium calculation for invoice Blended is as follows (Blended)

	a)	Raw Rate
	b)	Agent Commission
	c)	Admin fee
	d)	Additional Fees
	e)	Differential factor


	The total amount billed to group should include all the Rates after applying this formula for
	all the employees/members and their line of coverage.

III - First Time Invoice Formula

Blended for COBRA Members

Example	The formula for the premium calculation for the invoice Blended for Cal COBRA is as
	follows:
	Cal Cobra Total Premium = Blended Rate * (1 + Additional Fees %)

	The total amount billed to COBRA Subscriber member should include all the Rates after
	applying this formula for all the members and their line of coverage.

IV - Running Invoice

Blended

	1.	For Running invoice all that is applicable for first time invoice is applicable. In addition to
		that the running invoice has the following as well:
	2.	Late fee if applicable: Late fee charges are 5% on the Amount due in the prior invoices.
		The late fee calculation rule is as follows:
		Due Date:
		Postmark date:
		Received date:
		If the post mark date for cash receipt is available it should fall on or before due date.
		If postmark date is not available then if should check 5 calendar days backward from the
		date received and see if it falls within the due date.
		If the amount is received within the due date as per the above rules and is short late fee is
		still applied for the shortage of premium.
		If the above two conditions are not satisfied then late fee is charged for the Group or
		member.

	Note: Late fee is charged on the prior month's current premium
	(e.g.) Due date is l^stof every month or the first business day of the month. Whichever is
	applicable. For example 2/1/01
	Date payment received: 2/1/01 No late fee
	Date payment received is 2/2/01 and post marked 1/31/01 No late fee
	Date payment received is 2/3/01 and post marked 2/2/01 late fee applicable
	Date payment received is 2/6/01 and postmarked date not available. Look 5 days behind for
	the date for receipt, I.e 2/1/01 hence no late fees
	Date payment received is 2/8/01 and postmarked date not available. Look 5 days behind for
	the date for receipt. I.e 2/3/01 hence late fees applicable.

	3.	Balance forward if applicable: Balance forward is the amount balance from the previous
		invoice or shortage of premium.
	4.	Billing Adjustment: Billing adjustments can have various categories: Note The adjustment
		can be positive or negative based on the coverage period.
		Employee Coverage Choice Change
		Employee/Dependent Benefit Level (Selected carrier) change
		Employee/Dependent Termination
		Employee/Dependent Add On
		Rate for the Benefit Level Offered by the carrier changes retrospectively. I.e over writing
		the previous effective date that was applicable for the group.
	5.	Credit Card Payment transaction fee if applicable: Credit card transaction fee is
		2.5% of the total amount due for the group/member
	6.	NSF Check if applicable: $25 handling fees is charged for the NSF check.
	7.	Reinstatement fees: (Reinstatement fees are on the following assumption that on the date
		of term all the previous balances on the group are settled.) The group needs to be
		reinstated on the date next to the term date. The Amount due for the reinstatement from
		the date following the term dates to the current month when the group is reinstated.

(e.g.) Group Term Dare: 2/31/01

Date when the group was reinstated 5/10/01

	Effective reinstatement date is 3/1/01. Reinstatement fees is calculated for the Period 3/1/01
	I.e. the month when the reinstatement occurred. The invoice contains the premium due for the
	next month as well i.e. 6/1/01. However the current amount due is based on the current period
	i.e. from 3/1/01 to 5/31/01. Next months period 6/31/01 and reinstatement fees
	Percentage on the premium due when reinstatement occurred (The amount on which the
	reinstatement fees is calculated.)
	Note: Subsequent billing cycle would contain the Reinstatement Adjustments and
	Reinstatement fees on reinstatement for the group/member.
	A reinstatement fee is 10% of the premium due when reinstatement occurred.

V - Running Invoice

Non-Blended

	Note: The difference in the rules for non-blended and blended is in the rate calculation rules.
	The rest of the processes are same as for the blended.
Formula	Formula for Non-Blended Rates
	The formula for the premium calculation for the invoice Non-Blended is as follows
	(Non-Blended)

	a)	Raw Rate
	b)	Agent Commission per Member
	c)	Agent Commission per Group based on group size
	d)	Admin fee per Member
	e)	Admin fee per Group based on group size
	f)	Additional Fees
	g)	Differential factor

	Member Level Fees = Raw Rate + Member Count * (Agent Commission Per Member +
	Admin Fee Per Member)
	Note (If differential factor is applicable then Raw rate should be factored i.e Raw Rate *
	Differential Factor)
	Group Level Fees = Agent Commission per Group Size + Admin Fees per Group size
	Total Non Blended Premium Billed to Group = Member Level Fees + Group Level Fees

Example	Raw Rate	=	$100
	Agent Commission per Member	=	$10
	Agent Commission per Group based on group size	=	$50 for Group size => 15
	Admin fee per Member	=	$10
	Admin fee per Group based on group size	=	$50 for Group size => 15
	Additional Fees	=	10% on Raw Rate
	Differential factor
	Employee1 Member count including employee	=	3
	Employee2 Member count including employee	=	2
	Employee3 Member count including employee	=	4
	Employee4 Member count including employee	=	5
	Employee5 Member count including employee	=	1
	Total Member count	=	15
	Group size (=> 15)	=	15
	Member Level Fee
	Employee1 = 100 + 3 (10 + 10)	=	$160
	Employee2 = 100 + 2 (10 + 10)	=	$140
	Employee3 = 100 + 4 (10 + 10)	=	$180
	Employee4 = 100 + 5 (10 + 10)	=	$200
	Employee5 = 100 + 1 (10 + 10)	=	$120
	Member Level Fees	=	$800
	Group Level Fees	=	$50 + $50 + $100

	Total Non Blended Premium Billed to Group =
	Member Level Fees + Group Level Fees = $800 + $100 = $900
	This formula is for the specific Benefit Level (offered by carrier) for a specific line of
	coverage and a specific employed member.
	The total amount billed to group should include all the Rates after applying this formula for
	all the employees/members and their line of coverage.
Formula	Formula for Non-Blended Rates
Example	The formula for the premium calculation for the invoice Non Blended for Cal COBRA is as
	follows:
	Member Premium for Cal COBRA − Raw Rate * (1 + Additionul fee %)
	Example:
	Member Premium for Cal COBRA = 100 * (1 + 0.10) = $110
	Amount Billed to COBRA Group = $110
	This formula is for the specific Benefit Level (offered by carrier) for a specific line of
	coverage and a specific employee/member.
	The total amount billed to COBRA Subscriber member should include all the Rates after
	applying this formula for all the members and their line of coverage.

Benefit Partners Inc

Process Specification

Cash Receipt

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the process of Cash Receipt. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.

1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_FI_002	Finance - Business use case
		Specification - Cash Receipt

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

	EFT	Electronic Fund Transfer

2. Process Identification

2.1. Background

- Cash Receipt is the process of entering the cash received by BPI into the system. The cash receipt can be received in various modes as defined by the business process. Cash Receipt includes Lock Box receipts, Check, Credit Card, EFT and Transfer.

2.2. Process Description

- This Cash Receipt sub module also needs to incorporate the following.
  - 1) Enter the lock box payment received as a batch process into the system
  - 2) Enter EFT payment received as a batch process into the system
  - 3) EFT payment made directly to Wells Fargo Bank
  - 4) On line payment using the Credit Card and Check
  - 5) User interface to make payment over phone by Credit card or Check
  - 6) Credit Card payment with automatic pulling of the cash or manually on request
  - 7) Handle negative check i.e. NSF's, Refund and Transfer.
  - 8) Transfer of cash from one group to the other.
- This Cash Receipt sub module also needs to have a feature to incorporate the following.
  - Batch the cash receipt based on the batch number defined.
  - There should be ability to batch each of the modes of the payment received into a separate batch.
  - For EFT, Credit Card, On Line Check and Lockbox payments there should be ability to upload the files into the system as one batch. Reconciliation will follow once the batch is imported and closed.
  - In addition, prior entry of Lock box total entry made needs to tally with the lock box total.
- This document details only one mode of cash entry namely, Manual Batch. Lockbox, EFT and payments through credit cards are detailed in their respective process specification documents.

2.3. Process Flow

- Cash receipts into the system can be from the following sources:
  - EFT
  - Check received at BPI
  - Lock Box file
  - On line Credit Card
  - Check or Credit card over phone
- The cash received by any of the above mode is batched and entered into the system. The batch number is identified based on the mode of payment receipts. All batches should be identified uniquely with batch number and timestamp.
- The Payment received are either entered manually into the system or uploaded into the system from the files available. The batch total and sum of the entries made in each batch should tally before saving the batch.
- Batch date should represent the deposit date.
- Batch Types are:
  - 1. Manual Batch
  - 2. NSF Batch
  - 3. Returns Batch
  - 4. Positive Transfer
  - 5. Negative Transfer
  - 6. Lockbox Check
  - 7. Auto-Batch EFT
  - 8. Direct Deposit
  - 9. Wire Transfer
  - 10. CC over phone
  - 11. Auto-Batch Credit Card
  - 12. Online Credit Card

3. User Interface

3.1. User Interface Screens
3.1.1. Manual Cash Batch
3.1.1.1. Screen Snapshot (See FIG. J-5)
3.1.1.2. Element Name, Element Type & Purpose


Element	Element
Name	Type	Label	Purpose

Batch Information

Batch Id	Display Text	Batch Id	Displays unique system generated id for the batch
Batch Date	Text Box	Batch Date	Batch Date
Batch Total	Display Text	Batch Total	Displays total of all cash entries
Batch Type	Option Box	Batch Type	Type of manual batch. Possible options are
			Manual Batch, NSF Batch, Returns Batch,
			Positive Transfer, Negative Transfer
Tape Total	Text Box	Tape Total	Tape total of all cash entries
Tape Balance	Display Text	Tape Balance	Displays difference between the tape total and
			total of cash entries entered
Batch Status	Display Text	Batch Status	Displays status of batch: Open or Closed

Check Information

Postmark Date	Text Box	Postmark Date	Date on which the payment was postmarked
Received Date	Text Box	Received Date	Date on which payment was received
Check #	Text Box	Check #	Check number
Check Amount	Text Box	Check Amount	Check amount

Check Distribution

Group Id	Text Box	Group Id	Group against which payment is allocated
Group Name	Display Text	Group Name	Displays name of selected group
Amount	Text Box	Amount	Amount allocated to the group out of the total
			payment amount
Comments	Option Box	Comments	Standard comments for the payment, if any
Others	Text Box	Others	To enter any comments other than the standard
			ones
Payment	Editable Table		Displays all payment entries for the batch for
Entries			editing
New	Command	New	Clears screen for a new batch entry
Save	Command	Save	Saves the batch information to the database
Close	Command	Close	Closes the batch. A batch can not be edited after
			closing
Search	Command	Search	To search for saved batches

3.1.1.3. Screen Validations


Element Name	Action/Validation Details	Message

Batch Information

Batch Date	Check to see if batch date is not	“Please enter a valid
	null and is valid	batch date”
Batch Type	Check to see if valid batch type is	“Please select a
	selected	valid batch type”
Tape Total	Check to see if tape total is not null	“Please enter a
	and is valid	valid tape total”

Check Information

Postmark Date	Check to see if postmark date is	“Please enter a valid
	not null and is valid	postmark date”
Received Date	Check to see if the received date is	“Please enter a valid
	not null and is valid	received date”
Check #	Check to see if check number is	“Please enter a valid
	not null and is valid	check number”
Check Amount	Check to see if check amount is	“Please enter a valid
	not null and is valid	check amount”

Check Distribution

Group Id	Check to see if group id is not null	“Please enter a
	and is valid	valid group id”
Amount	Check to see if amount is not null	“Please enter a
	and is valid	valid amount”

3.2. Interface Flow

- N/A

4. Business Rule Mapping


Activities	Rules

Batch Entry	Unique id should be created for each batched. The batch total should be tallied to the
	individual sum before saving the batch. The batch id should be uniquely generated prior
	to creation of batch. Each cash receipt should have the postmark date, date received and
	the system date (I.e the date when the batch is created) and batch total. The line items
	within each batch should have a feature to Split the payment for multiple group ids if
	required. Batch date should be the deposit data.
	Any entries made to the batch can be saved prior to completion of the batch entries.
	However there would be a status for the batch which would indicate if the batch is closed
	or not. Modification can be done only to the batches that are open. Any batch that is
	closed cannot be modified. If there is an erroneous entry for the batch and the batch is
	saved. Only Transfer can be done and it is not allowed to delete the batch that are closed.
	Only the batches that are closed can be reconciled.
Batch by File	The batch that are created by uploading the files like for Lockbox, EFT or Credit Card
Uploads	will have an identification that payment for this batch was made by Lockbox, EFT or
	Credit Card. These batches are always closed.
Negative	NSF would be entered into the system and there would be an indicator indicating that
Check (NSF)	this batch is a NSF batch.
Transfer	Cash transfer may be due to the reason that the Cash has been wrongly enter for the
	group to which the cash does not belong. In such cased entering negative cash receipt for
	the Group for whom the cash has been wrongly entered and making positive cash to the
	group to whom the cash belongs makes the cash adjustment. There should be a positive
	and negative cash adjustment.
Returns	Refund would be a batch and would be handled similar to the NSF Check.

Benefit Partners Inc

Process Specification

Cash Reconciliation

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the process of Cash Reconciliation. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.

1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_FI_003	Finance - Business use case
		Specification - Cash
		Reconciliation

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

	EFT	Electronic Fund Transfer

2. Process Identification

2.1. Background

- Cash Reconciliation is the process of reconciling the cash receipts to individual invoices and reconciling the amount paid by the group.
- The objective of the Cash Reconciliation process is to reconcile:
  - 1) Billed amounts and cash receipt
  - 2) Cash to negative cash
  - 3) Adjustment to cash
  - 4) Adjustment to billed amounts
  - 5) Billed amount to itself if the total due results in zero
  - 6) Adjustment to Adjustment

2.2. Process Flow and Description

- Process for Cash Reconciliation:
- Reconciliation is the process of matching one to one the cash received on hand and the invoices that are open. The cash are received by numerous ways as described in BPI_CAS_FSD_FI_—02 (Cash Receipt). The invoice is generated for the various groups/members based on the premium due. These invoices are matched with the cash receipts and reconciled.
- The rule for reconciliation should be as follows:
  - 1. Look for the Negative Cash available and reconcile it with the positive cash (for NSF checks).
  - 2. Look for the oldest unreconciled invoice and reconcile with the oldest cash.
- The reconciliation process should look through all the invoices that have not been reconciled for a specific group and reconcile the invoice that has the earliest date with the cash received. It should also match the Cash receipt with the invoice amount.
- Note: reconciliation process is started automatically when the cash receipt batch is closed and it reconciles the cash received with the invoices.
  - Billed amounts and cash receipt: This reconciliation process is to reconcile the invoice that has not yet been reconciled for the specific group and check if the invoice is earliest un reconciled invoice for the specific group and reconcile the invoice with the cash received form the group/member.
  - Cash to negative cash: This is the process of reconciling the negative cash with the positive cash received from the group. This case arises when there is a NSF check and the group's invoice has been reconciled. The bank usually notifies NSF check and then NSF Cash receipt entry is created in the system. Now on receipt of a replacement check against the NSF check the NSF check is reconciled with the replacement check provided the amount tallies.
  - Adjustments to Cash: This is the process of reconciling the cash receipt with the adjustment that may be available in the next invoice. Example: If the group has received the invoice for the next month and they have an employee termed this month after the generation of invoice. The generated invoice would not identify this adjustment for the termed employees as the employee was termed after creation of invoice. But the Group may deduct the adjustments for the termed employee and send the cash that would be short as they would sent the check with the adjustments. Hence this process should identify such conditions and adjust the cash receipt for the invoice with adjustment taken in to account. The next invoice would show the cash receipt and the adjustment for the employees termed. This process can also be coined as “Reconciled but not billed”.
  - Adjustment to billed amounts: This process identifies the invoices that are already billed to the group and any adjustments that are not made in the current invoice needs to be adjusted in the next invoice with the adjustments made.
  - Billed amount to itself if the total due results in zero: This is process identifies if the group is termed and the invoice is already created for the group for the next month. Invoice would be created for the termed group on group termination and would adjust that with previous invoice. There would always be a final invoice for the termed groups showing adjustments that would include refund, or short fall or zero balance.
  - Adjustment to Adjustment: This process is for adjusting the late fee with late fee is waived, Reinstatement fees with reinstatement fee waive as the case may be. If the Late fee is shown in the previous invoice that can be adjusted by waiving late fee or reinstatement fees as applicable. Example: Late fees may be $25.00 and waive late fees would be $−25.00. Here adjustment to adjustment would be $25 to $25. Also adjustment needs to be made on invoice with invoice.

3. User Interface

3.1. User Interface Screens
3.1.1. Manual Reconciliation
3.1.1.1. Screen Snapshot (See FIG. J-6)
3.1.1.2. Element Name, Element Type & Purpose


Element	Element
Name	Type	Label	Purpose

Group Information

Group Id	Display Text	Group Id	Displays id of the group
Group Type	Display Text	Group Type	Displays group type
Group Name	Display Text	Group Name	Displays group name
Association	Display Text	Association	Displays name of association if group is enrolled
Name		Name	through one
Status	Display Text	Status	Displays status of group
Rate Type	Display Text	Rate Type	Displays the rate type for the group: blended or
			non-blended
Left to balance	Display Text	Left to balance	Displays amount left to be reconciled

Bill Information

Bill #	Display	Bill #
	Column
Coverage	Display	Coverage Period
Period	Column
Due Date	Display	Due Date
	Column
Bill Date	Display	Bill Date
	Column
Bill Total	Display	Bill Total
	Column
Total Due	Display	Total Due
	Column

Adjustments Information

Adjustment Id	Display	Adj. Id
	Column
Adjustment	Display	Adj. Type
Type	Column
Adjustment	Display	Adj. Date
Date	Column
User Id	Display	User Id
	Column
Coverage	Display	Cvrg Month
Month	Column
Amount	Display	Amount
	Column

Cash Receipts

Batch Id	Display	Batch Id
	Column
Postmarked	Display	Date PM
Date	Column
Date Received	Display	Date Recd
	Column
Check #	Display	Check #
	Column
Batch Type	Display	Batch Type
	Column
Payment	Display	Pmt Amt
Amount	Column
Unused	Display	Unused Amt
Amount	Column
Comments	Display	Comments
	Column
Post	Command	Post	Post reconciliation entries
Reconciliation		Reconciliation
Clear	Command	Clear	Clears screen for a new import.
Search	Command	Search	Provides functionality to search groups

3.1.1.3. Screen Validations

- Note: Reconciliation can have any of the possible combination provided below:
  - 1) Invoice to Invoice
  - 2) Invoice to Cash receipt
  - 3) Invoice to Adjustment
  - 4) Cash receipt to cash receipt
  - 5) Cash receipt to adjustment
  - 6) Adjustment to adjustment
- Hence, the validation for the amount left to balance is done based on any of the combination selected from the check boxes.
- Note: Adjustments would be shown only under special conditions where term has been initiated after generation of invoices and the group pays short taking this adjustments into account.

3.1.2. Billing & Payments History
3.1.2.1. Screen Snapshot (See FIG. J-7)
3.1.2.2. Element Name, Element Type & Purpose


Element	Element
Name	Type	Label	Purpose

Group Information

Group Id	Display Text	Group Id	Displays id of the group
Group Type	Display Text	Group Type	Displays group type
Group Name	Display Text	Group Name	Displays group name
Association	Display Text	Association	Displays name of association if group is enrolled
Name		Name	through one
Status	Display Text	Status	Displays status of group
Rate Type	Display Text	Rate Type	Displays the rate type for the group: blended or
			non-blended

Bill Information

Adjustments Information

Cash Receipts

Batch Id	Display	Batch Id
	Column
Postmarked	Display	Date PM
Date	Column
Date Received	Display	Date Recd
	Column
Check #	Display	Check #
	Column
Batch Type	Display	Batch Type
	Column
Payment	Display	Pmt Amt
Amount	Column
Unused	Display	Unused Amt
Amount	Column
Comments	Display	Comments
	Column
Search	Command	Search	Provides functionality to search groups

3.1.2.3. Screen Validations

- NA

3.2. Interface Flow

- N/A

4. Business Rule Mapping


Activities	Rules

Automated	Automatic Reconciliation would be done on closing the batch for the cash receipt. If the
Reconciliation	cash receipt batch were closed then it would start the reconciliation process.
	The following process would be auto reconciled:
	Billed amounts and cash receipt
	Adjustment to cash
	Billed amount to itself if the total due results in zero
	Adjustment to billed amounts
Reconciliation	Reconciliation process would look for the earliest un reconciled invoice and reconciles it
for the Existing	provided it is less than $ +_2.00.
Groups	Reconciliation would be as per the following sequence.
	Look for the Negative Cash available and reconcile it with the positive cash (for NSF
	checks).
	Look for the oldest unreconciled invoice and reconcile with the oldest un-reconciled
	cash and so on.
	On Reconciliation the entire invoice, cash receipts would have a status as reconciled.
Manual	This process would trigger reconciliation manually based on authority or if the user is trying
Reconciliation	to reconcile and specific cash receipts with the invoice as the case may be. Manual
	reconciliation can be does only for those invoices that has not reconciled automatically
Manual	Cash to negative cash
Reconciliation	Adjustment to Adjustment
	Any reconciliation that is not completed by automatic reconciliation process would be
	reconciled manually.
Formula for	General formula for reconciliation would be as follows:
reconciliation	Billed amounts and cash receipt = (Invoice Amount − Cash Receipt)
	Adjustment to cash = (Adjustment − Cash Receipts)
	Billed amount to itself if the total due results in zero = (Invoice Amount + Invoice Amount)
	Adjustment to billed amounts = (Adjustment Amount + Invoice Amount)
	Cash to negative cash = (Cash receipt + cash receipt)
	Adjustment to Adjustment = (Adjustment + adjustment)
	General formula = (Invoice Amount + Adjustment Amount − Cash Receipt Amount)
	Example
	Invoice = $000.00, Cash receipt = $−100.00, Cash receipt = $918.00,
	Adjustment = $−100.00, Adjustment = $−80.00
	Amount that can be Reconciled = 1000 − (−100) − (800) + (−100) + (−80) = 1000 + 100 − 918 −
	100 − 80 = $2.00 This $2.00 is balance forward for the subsequent invoice.
New Business	Excluding COBRA and Individual Association Members who follow the reconciliation rules
Reconciliation	as per the Existing Group, the new business groups is auto reconcile if within $ +− 2.00. If
	the amount is short by $100.00 the invoice and the cash receipt would be reconciled and the
	short fall would be balance forward in the next invoice. PacAdvantage Fund (A Cash
	Receipt Batch auto generated by the system) would adjust this short fall. This would be
	based on authority (Finance/GMS).
	Also for the new business the auto reconciliation process would apply to reconcile the
	Invoice Generated on successful enrollment with the cash receipt as initial enrollment
	payment.

Benefit Partners Inc

Process Specification

Risk Adjustment

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the process of Risk Adjustment. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process.

1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE_FI_007	Finance - Business use case
		Specification - Risk Adjustment

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

	EFT	Electronic Fund Transfer

2. Process Identification

2.1. Background

- Risk Adjustment is the process of accessing the risk borne by each of the Carrier in paying for the claims submitted to them by members.
- Risk adjustment factor is assigned to the Carrier. Based on these factors the carrier may be classified as Payers, Receivers or None (if no factor is assigned).
  Payers are the one who pays in the risk adjustment amount to the Pool. Receivers are the one who receives the Risk Adjustment amount from the pool.
- These risk adjustment factors are pre-defined by PacAdvantage.

2.2. Process Description

- The objective of the Risk Adjustment process is to:
  - 1) Provide for upload of Risk Adjustment (RA) factors in the form of text files into PX2 system
- The uploaded data would subsequently be used in cash disbursement reports for suggesting the amount to be paid out to carriers after application of RA factors.
- The following are the other requirements that will be supported and constraints on the proposed system:
  - 1) The system will maintain a log of all zip codes and service area imports. The log information will include the user, the day & time of import, the file path & format and the status of the import.

2.3. Process Flow
Process for Upload of Risk Adjustment Factors

- 1) The import file and an effective date for import are all input from the user.
- 2) The system checks to see if the file data is per the format expected. If not, an error is reported.
- 3) If data already exists for an effective date, the system prompts to the user as to whether it should overwrite the data or cancel the import.
- 4) The system imports Risk Adjustment factors to its database.
- 3. User Interface

3.1. User Interface Screens
3.1.1. Risk Adjustment Factors Import
3.1.1.1. Screen Snapshot (See FIG. J-8)
3.1.1.2. Element Name, Element Type & Purpose


Element	Element
Name	Type	Label	Purpose

Import Id	Display Text	Import Id	Displays unique id for
			the import
Status	Display Text	Status	Displays status of import
Imported By	Display Text	Imported By	Displays id of user who
			did the import
Import Date	Display Text	Import Date	Displays date on which
			import was done
Import File	Text Box	Import File	Full path of the file to
			be imported
Effective Date	Text Box	Effective Date	Date on which the RA
			factors becomes effective
New	Command	New	Clears screen for a
			new import.
Import	Command	Import	Starts the import process
Search	Command	Search	Provides functionality
			for search of imports

3.1.1.3. Screen Validations


Element Name	Action/Validation Details	Message

Import File Name	Check to see that the value for	“Please enter a valid
	the field is not null	import file name”
Effective Date	Check to see that the value for	“Please enter a valid
	the filed is not null and is valid	effective date”

3.2. Interface Flow

- N/A

4. Business Rule Mapping


Activities	Rules

Risk	The formula for risk Adjustment factor is as given below:
Assessment	Raw Rate = Premium Amount (Raw Rate for Medical
Formula	Line of coverage and the benefit level for the specific
	carrier opted by the member)
	Adjustment Factor = Fixed dollar amount per member
	count (can be negative or positive based on whether the
	Carrier is receiver or payer) Positive is the receiver and
	negative is the payer.
	Risk Adjustment amount = Raw rate + (Risk Adjustment
	factor * member count for that plan)
	Example
	Adjustment Factor = $ + 5.00 for Aerna (receiver)
	Adjustment Factor = $ − 2.00 for Health Net (payer)
	Employee 1 = $ 400 with (4 member inclusive of
	employee) Aerna
	Employee
2 = $ 300 with (2 member inclusive of
	employee) Health net
	Employee
3 = $ 200 with (1 member inclusive of
	employee) Health net
	For Health net
	300 + (−2 * 2) + 200 + (−2 * 1) = 304 + 202 = 494.00
	For Aerna
	400 + (5 * 4) = $ 420.00

Note:
the adjustment factor has an effective date attach to it. Normally it is loaded once in 6 months.

Benefit Partners Inc

Process Specification

BPI_CAS_PSD_SECURITY

_—01

1.1 Introduction

- This purpose of this document is to identify the processes associated with the security mechanism for core administrative system

1.2 Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	NONE	NONE

1.3 Process Identification

1.3.1 Process Description & Flow

- This process describes the security framework requirements. The security framework consists of creating database for security system as well as administrator login into the system. The system also allows the administrator to create users, module, groups, and application, assign user roles and ACL etc. The system also takes care of user login into the core administrative system. The system should generate the ACL for each user when user logs in into the system. The access to any resource in the core administrative system will be decided by this ACL which will be stored in the User Profile object, stored into the session.
- The security system for Intranet application built for shall broadly contain following categories.
  - 1. Definition of Realms
  - 2. Definition of Modules
  - 3. Definition of Applications
  - 4. Definition of Resources
  - 5. Definition of groups (groups can ideally be a department which has a number of users)
  - 6. Definition of User
  - 7. Definition of User Roles
  - 8. Definition ACL/Permissions
  - 9. Resources, which can be assigned to the groups.
  - 10. User, User Role and Groups mapping
  - 11. Overriding the group access rights.

Realms

- A realm is a database of users, groups, modules, application resources and access control lists. A user must be defined in a realm in order to access any resources belonging to that realm.

Modules

- The modules provide the high level classification for the applications. The module is a group of applications. The following modules have been identified in the initial stage as a part of core administrative system viz. Carrier Maintenance, Enrollment, Sales and Marketing and Finance.

Applications

- A module consists of many applications. An application represents the business use case or set of related use cases. A module consists of many applications. For e.g. Carrier Maintenance module consists of following applications viz. Zip Master, Carrier Master, and M Plan etc. Each application can be further classified into the pages.

Resources

- An application can be further classified into the Resources. An application can have one or more resources.
- Resources are the valuable items accessible from the Web server/Web Application server:
  - Web applications: Java.Servlet or JSP
- The resources can be protected by using a single access control (ACL). The ACL specifies which users or groups are allowed to access or modify the resource. For each resource to protect, you'll specify:
  - An access control list (ACL)—a list defining who can use the resource

Groups

- A group is a collection of users. A user can belong to multiple groups. The groups can be created based on the department where all the uses are going to perform the similar kind of operation.
- Groups are sets of users. Groups provide an efficient way to manage large numbers of users because an administrator can specify permissions for an entire group at one time. The resources pages can be allocated to group instead of assigning to individual user. The user gets the default access rights as a part of group. The user can override the group access rights. A person can be defined as both an individual user and as a member of a group. When an individual user also belongs to a group, the individual access permissions override any group access permissions.
- For e.g. a set of data entry operators can have be classified into one group. The rights can be assigned to this group as all basically going to do the data entry operation.

User Roles

- In any system, there are many roles, which a particular entity plays. For e.g. in any industry role played by the manager differs from the subordinate.
- The roles need to be classified into the security system. A user can play multiple roles in the system. A manager can play the role as data entry as well as authorizing body.
- A data entry operation may not have provision to enter some critical data, which manager does enter if manager is logging into the system as manager role. The managers can login into the system as data entry operator as well.
- If manager is logging in as data entry operation he may not have the privileges as he was having in manager role. In such a case he will be treated as data entry operator. The security system needs to take above situations. The user roles can be
  - SUPER USER
  - SENIOR MANAGEMENT
  - MANAGER
  - DATA ENTRY PERSONNEL
  - PART TIME EMPLOYEE
- The user roles need to be configured into the system. The user roles can be added for the future modifications. The CAS (Core Administration System) system need to be pre configured for the basic pre defined roles which will not be editable.

Users

- A user is an identity that can be authenticated by the system. A user can represent a person who is working in any of the departments in Benefit Partners Inc. A user can belong to multiple groups.
- A user can play multiple roles

Access Rights/Permissions

- Permissions represent the privileges required for accessing resources. An administrator protects resources by establishing access control lists to grant permissions to users and groups.
- Individual user permissions take precedence over group permissions. Individual user permission overrides the more restrictive group permission. (Even if the group permission is less restrictive than the user permission, the user permission overrides the group permission and vice versa).

List of Programs

- 1. Security Login
  - Allows the administrator to login into the security system.
- 2. Module Master
  - Allows administrator to do following operations
  - Create Module
  - Modify Module
  - Delete Modules
- 3. Application Master
  - Allows administrator to do following operations
  - Create Application
  - Modify Application
  - Delete Application
- 4. Resources
  - Allows administrator to do following operations
  - Create Resources
  - Modify Resources
  - Delete Resources
- 5. Group Master
  - Allows administrator to do following operations
  - Create Group
  - Modify Group
  - Delete Group
- 6. User Master
  - Allows administrator to do following operations
  - Create User
  - Modify User
  - Delete User
- 7. User Role
  - Allows administrator to do following operations
  - Create Role
  - Modify Role
  - Delete Role
- 8. User Access Rights
- 9. User, User Role and Groups Mapping
- 10. Group Access Rights
  - Allows administrator to do following operations.
  - Assign Rights for a User. This program allows the administrator to override the access rights for a user.
- 11. User Login
  - When the system user logs in into the core administration system the separate ACL will be generated for each user. The ACL will be stored in the User Profile object, which will be stored in the user session. When user request for a particular page controller will check with the security system whether user is having access to the particular page.
  - The user password needs to be validated as follows
    - The password need to be minimum 6 characters long and max 10 characters
    - The password needs to be combination of alphabets and special characters and numbers (for e.g. Amit1$3, sriRam9#445 etc).
    - The password is valid for 15 days, which is configurable. The system should prompt user to change the password three days (which is configurable) prior to expiry date of the password.
    - If user changes the password then his password is valid for 15 days (which is configurable) from the date of change.
    - In the same way administrator can configure the minimum limit for password age, which signifies that user cannot change the password for this period from the date of prior change.
    - The minimum limit for the password age, which is configured value, cannot be greater than or equal to configured maximum limit of the password age.
    - First time user must change his password before entering into the system.
    - Scenario
      - If the user password is “123456” the for first time login user goes and change the password to “Mali5%9”. The user is created on date Jan. 4, 2002. User logs in on Jan. 5, 2002 and password expiry date for the user changes to Jan. 19, 2002 (15 calendar days) if the configured time limit is 15 days. The user needs to prompt to change password on Jan. 17, 2002 (3 calendar days prior to the expiry date). If user changes the password within stipulated time then extend the password expiry date by 15 calendar days. (New Date=Sys Date+15). All changes in the date is effective from 0000 AM
    - The above validation is not applicable at the time of user creation as administrator can keep the password 123456 for all.
    - The new password in the change password is to be validated for above conditions. The old password need not be validated for above conditions. As user can have 123456 as first time as his password.
    - The old password needs to be maintained in the history. The new password must not be equal to last five passwords. This number of history of passwords (here its 5) should be configurable. (A configurable password history where the administrator can enter value that would represent how many passwords it would remember until the user can use the same password again)
    - The ability to enable or disable Account lockout with a configuration value for the number of user log in attempts at which point a lockout would occur. A way timer for when to reset the count of attempts before lock would be helpful. Also if it possible to make a lockout duration value that would be configurable would also be helpful.
    - User Name cannot be a part of password.

Configurable Items


Sr No	Item Name	Value

1	Length Of Password	Integer (Ranging From 1-n)
	(Minimum Value)	Need to be set by the
		administrator
2	Length Of Password	Integer (Ranging From 1-n)
	(Maximum Value)	Need to be set by the
		administrator
		Maximum need to be greater
		than minimum value
3	Expiry of the password from the	Integer (Number of days)
	date of validity	Ranging from 1-n
	(Maximum Range)	Need to be set by the
		administrator
4	Expiry of the password from the	Integer (Number of days)
	date of validity	Ranging from 1-n
	(Minimum Range)	Need to be set by the
		administrator
5	Password Repeat allowed value	Integer (Number of days)
	This indicates that new passwords	Ranging from 1-n
	can not be same as last	Need to be set by the
	n passwords	administrator
6	Invalid Passwords allowed before	Integer (Number of days)
	locking the account	Ranging from 1-n
	If user enters the password	Need to be set by the
	incorrect for n times then his	administrator
	account will be locked
	automatically.
7	Lock Time	Time for which account to be
		locked if it is locked because
		of successive invalid
		passwords entry.
8	Password change prompt date	This value signifies that user
		need to be intimated by 3
		days prior about password
		change (Value here set as 3)

1.3. Security Framework
Process Flow Diagram (See FIG. P-1)
1.3.1.1. Script for Setup

- Run the basic admin script, which will create the basic administrative user for security login and minimal data into the database.

1.3.1.2. Security Login

- Security Login
  - Refer Process Flow Diagram FIG. 2. The flow of the process is as described below.
  - System allows user to login into the system. The basic user id and password validation will be done for the administrator for the security system.
  - On successful login administrator can create modules, groups, applications, user etc.
- FIG. 2 Process Flow Diagram (See FIG. P-2)

1.3.1.3. Module Master

- Refer Process Flow Diagram FIG. 3, The flow of the process is as described below.

Create Modules

- a) On selecting create modules option. The user needs to enter the module name and description.
- b) The user enters the details and clicks save.
- c) Upon save the data will be stored in the database. Modify Modules
- a) When user selects modify modules option. He will be shown all the modules in the combo box.
- b) The user selects the module name and clicks select.
- c) The user will be shown the details about the selected module. The user can modify the module details and click save. The data will be updated into database.

Delete Modules

- a) When user selects the Delete option, the user will be shown all the modules where in user can select one or more access control list and click delete.
- b) The selected modules will be deleted from the database.
- FIG. 3: Process Flow Diagram (See FIG. P-3)

1.3.1.4. Application Master

- Refer Process Flow Diagram FIG. 4. The flow of the process is as described below.

Create Application

- a) On selecting create application option. The user needs to enter the application details like application name, module name and description.
- b) The user enters the data and clicks save.
- c) Upon save the data will be stored in the database.

Modify Application

- a) When user selects modify applications option. He will be shown all the applications in the selection box. The user selects one application and clicks select.
- b) The user will be shown the details about the selected application. The user can modify the application details and click save.
- c) The data will be updated into database.

Delete Application

- a) When user selects the Delete option, the user will be shown all the applications where in user can select one or more applications and click delete.
- b) The selected applications will be deleted from the database.
- FIG. 4: Process Flow Diagram (See FIG. P-4)

1.3.1.5. Resource Master

- Refer Process Flow Diagram. The flow of the process is as described below.

Create Resource

- a) On selecting create resource option. The user needs to enter the resource details like resource name, application name and description.
- b) The user enters the data and clicks save.
- c) Upon save the data will be stored in the database.

Modify Resource

- a) When user selects modify resource option. He will be shown all the resources in the selection box. The user selects one resource and clicks select.
- b) The user will be shown the details about the selected resource. The user can modify the resource details and click save.
- c) The data will be updated into database.

Delete Resource

- a) When user selects the Delete option, the user will be shown all the resource where in user can select one or more resources and click delete.
- b) The selected resources will be deleted from the database.
- FIG. 5: Process Flow Diagram (See FIG. P-5)

1.3.1.6. Group Master

- Refer Process Flow Diagram FIG. 6. The flow of the process is as described below.

Create Group

- a) On selecting create group option. The user needs to enter the group details like group name and description.
- b) The user enters the data and clicks save.
- c) Upon save the data will be stored in the database.

Modify Group

- a) When user selects modify group's option. He will be shown all the groups in the selection box. The user selects one group and clicks select.
- b) The user will be shown the details about the selected group. The user can modify the group details and click save
- c) The data will be updated into database.

Delete Group

- a) When user selects the Delete option, the user will be shown all the groups where in user can select one or more groups and click delete
- b) The selected groups will be deleted from the database.
- FIG. 6: Process Flow Diagram (Sec FIG. P-6)

1.3.1.7. User Creation

- Refer Process Flow Diagram FIG. 7. The flow of the process is as described below.

Create User

- a) On selecting create user option. The user needs to enter the details like user name, description, address details etc.
- b) The user enters the data and clicks save.
- c) Upon save the data will be stored in the database.

Modify User

- a) When user selects modify user option. He will be shown all the user details in the selection box. The user selects one-user and clicks select.
- b) The user will be shown the details about the selected user. The user can modify the user details and click save
- c) The data will be updated into database.

Delete User

- a) When user selects the Delete option, the user will be shown all the users where in user can select one or more users and click delete
- b) The selected users will be deleted from the database.
- FIG. 7: Process Flow Diagram (See FIG. P-7)

1.3.1.8. User Role Creation

- Refer Process Flow Diagram FIG. 7 a. The flow of the process is as described below.

Create User Role

- a) On selecting create user role option. The user needs to enter the details like user role name, description
- b) The user enters the data and clicks save.
- c) Upon save the data will be stored in the database.

Modify User Role

- a) When user selects modify user role option. He will be shown all the user role details in the selection box. The user selects one-user role and clicks select.
- b) The user will be shown the details about the selected user role. The user can modify the user details and click save.
- c) The data will be updated into database.

Delete User Role

- a) When user selects the Delete option, the user role will be shown all the users roles where in user can select one or more users role and Click delete
- b) The selected user roles will be deleted from the database.
- FIG. 7 a: Process Flow Diagram (See FIG. P-8)

1.3.1.9. User, User Role and Group Mapping

- Refer Process Flow Diagram FIG. 8. The flow of the process is as described

Assign Rights

- a) On selecting the User, User Role and Group Mapping option. The user will be shown the all the users and user roles in the selection box. The user can select the combination of user and user role.
- b) On selection user will be shown the all the groups with already assigned groups as checked.
- c) The user adds or removes the group assignment and clicks save.
- d) Upon save the data will be stored in the database
- FIG. 8: Process Flow Diagram (See FIG. P-9)

1.3.1.10. Group Access Rights

- Refer Process Flow Diagram. The flow of the process is as described below.

Assign Rights

- a) On selecting the group access rights. The user will be shown the all the groups in the selection box. The user can select any group and click select.
- b) When user selects the particular group, the user will be shown the all the resources and with the access rights selection box corresponding to each module.
- c) User can assign one or more resources to the group and click save.
- d) Upon save the data will be stored in the database.
- FIG. 9: Process Flow Diagram (See FIG. P-10)

1.3.1.11. User Access Rights

- Refer Process Flow Diagram. The flow of the process is as described below.
- As stated earlier, user can override the access specified to the group.

Assign User Rights.

- a) On selecting the user access rights. The user will be shown the all the users in the selection box. The user can select anyone user and click select.
- b) When user selects the particular user, the user will be shown the all the access rights for his group for corresponding resource.
- c) The user can add or remove the resources.
- d) Upon save the data will be stored in the database.

1.3.1.12. Configure Items

- Refer Process Flow Diagram. The flow of the process is as described below. This allows administrator to configure various items like password length, expiry etc.
- FIG. 10: Process Flow Diagram (See FIG. P-11)
- FIG. 10A: Process Flow Diagram (See FIG. P-12)

1.4 User Interface
1.4.1 User Interface ID: SECURITY_SCREEN_—001 (See FIG. P-13)

- User Interface ID: SECURITY_SCREEN_—002 (See FIG. P-14)

1.4.1.1 User Interface Screen Snap Shot—Screen Name: Security Login
1.4.1.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_LOGIN_SCREEN_001

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Security Login		being navigated
Sub Header	Text	Text for the Login Name
Login Name
Login Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the password
password
Password	Entry Field	Text for the password
Save	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)
Select the Role	Text	Text for the Role
Role	Selection Box	Selection box applicable for user
		login only.

Table for Screen SECURITY LOGIN SCREEN 002

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Security Login		being navigated
Sub Header Login	Text	Text for the Login Name
Name
Login Name	Entry Field	Text for the entry field
Sub Header old	Text	Text for the old password
password
old Password	Entry Field	Text for the old password
Sub Header new	Text	Text for the new password
password
new Password	Entry Field	Text for the new re enter password
Sub Header re	Text	Text for the re enter password
enter password
re enter Password	Entry Field	Text for the re enter password
Select	Button (HTML	To select the current selected module
	Button)	to modify.
Cancel	Button (HTML	To cancel current operation.
	Button)

1.4.1.3 Front End Validation

- Validation Details
  - This section provides the front end screen validations along with the associated message—Success/Error Message text


	Element
#	Name	Action/Validation Details	Message

1.	Login Name	Accepts all the alphabets	Mandatory Max Length: 15
	(Entry Field)	and numeric characters.	“Please Enter Login Name”
2.	Password	Accepts all the alphabets	Mandatory Max Length: 15
		and numeric characters.	Min Length: 6
			“Please Enter the
			password”
3.	User Role	Selection Box validation	Default: Choose One
			“Mandatory”
			“Please choose one of the
			options specified”

1.4.2 User Interface ID: SECURITY_SCREEN_—003 (See FIG. P-15)

- User Interface ID: SECURITY_SCREEN_—004 (See FIG. P-16)
- User Interface ID: SECURITY_SCREEN_—005 (See FIG. P-17)

1.4.2.1 User Interface Screen Snap Shot—Screen Name: Module Master
1.4.2.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_003

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Create Module		being navigated
Sub Header	Text	Text for the Module Id
Module Id
Module Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Module Name
Module Name
Module Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Module Name
Module
Description
Module	Entry Field	Text for the entry field
Description
Save	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_004

Element Name	Element Type	Purpose

Search	Gif File	Used to search the module

Table for Screen SECURITY_SCREEN_004

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Modify Module		being navigated
Sub Header	Text	Text for the Module Id
Module Id
Module Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Module Name
Module Name
Module Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Module Name
Module
Description
Module	Entry Field	Text for the entry field
Description
Update	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_005

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen being
Delete Modules		navigated
Sub Heading	Text	To give the sub heading for the screen
Select the		being navigated
modules
Module Names	Check Box	Check boxes for module names to be
Sales, finance		deleted.
Check Box	Check All	On clicking the “Check All” link should
		check all the check boxes in the HTML
		table.
Check Box	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check boxes in
		the HTML table.
Delete	Delete	To Delete the data this button need to
		be clicked

1.4.2.3 Front End Validation


		Action/
#	Element Name	Validation Details	Message

1	Module Name	Accepts all	Max length: 50
	(Entry Field)	the alphabets	Mandatory
		and numeric	BPI_CAS_FSD_COMMON
		characters.
2	Module Id (Entry	Accepts all	Max length: 10
	Field)	the alphabets	Mandatory
		and numeric	BPI_CAS_FSD_COMMON
		characters.
3	Comments (Entry	Accepts all	Max length: 250
	Field)	the alphabets	BPI_CAS_FSD_COMMON
		and numeric
		characters.

1.4.3 User Interface ID: SECURITY_SCREEN_—006 (See FIG. P-18)

- User Interface ID: SECURITY_SCREEN_—007 (See FIG. P-19)
- User Interface ID: SECURITY_SCREEN_—008 (See FIG. P-20)

1.4.3.1

- User Interface Screen Snap Shot—Screen Name: Group Master

1.4.3.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_006

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Create Group		being navigated
Sub Header	Text	Text for the Group Id
Group Id
Group Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Group Name
Group Name
Group Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Group Name
Group
Description
Group	Entry Field	Text for the entry field
Description
Save	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_007

Element Name	Element Type	Purpose

Search	Image	To provide search

Table for Screen SECURITY_SCREEN_007

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Modify Group		being navigated
Sub Header	Text	Text for the Group Id
Group Id
Group Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Group Name
Group Name
Group Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Group Name
Group
Description
Group	Entry Field	Text for the entry field
Description
Update	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_008

	Element
Element Name	Type	Purpose

Main Heading	Text	To give the heading for the screen being
Delete Group		navigated
Sub Heading	Text	To give the sub heading for the screen being
Select the		navigated
Groups
Group Names	Check	Check boxes for group names to be deleted.
Sales, finance	Box
Check Box	Check All	On clicking the “Check All” link should
		check all the check boxes in the HTML
		table.
Check Box	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check boxes in the
		HTML table.
Delete	Delete	To Delete the data this button need to
		be clicked

1.4.3.3 Front End Validation


	Element	Action/
#	Name	Validation Details	Message

1	Group Name	Accepts all the	Max length: 50
	(Entry Field)	alphabets and numeric	Mandatory
		characters.	BPI_CAS_FSD_COMMON
2	Group Id	Accepts all the	Max length: 10
	(Entry Field)	alphabets and numeric	Mandatory
		characters.	BPI_CAS_FSD_COMMON
3	Comments/	Accepts all the	Max length: 255
	Description	alphabets and numeric	BPI_CAS_FSD_COMMON
		characters.

1.4.4 User Interface ID: SECURITY_SCREEN_—009 (See FIG. P-21)

- User Interface ID: SECURITY_SCREEN_—010 (See FIG. P-22)
- User Interface ID: SECURITY_SCREEN_—011 (See FIG. P-23)

1.4.4.1 User Interface Screen Snap Shot—Screen Name: Application Master
1.4.4.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_009

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Create		being navigated
Application
Sub Header	Text	Text for the Application Id
Application Id
Application Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Application Name
Application Name
Application Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Application Name
Application
Description
Application	Entry Field	Text for the entry field
Description
Sub Header	Text	Text for the Module Name
Module Name
Selection Box	Selection Box	Module Name
Save	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_010

Element Name	Element Type	Purpose

Search	Gif	To search the application

Table for Screen SECURITY_SCREEN_010

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Modify		being navigated
Application
Sub Header	Text	Text for the Application Id
Application Id
Application Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Application Name
Application Name
Application Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Application Name
Application
Description
Application	Entry Field	Text for the entry field
Description
Update	Button (HTML	To Save the data this button need to
	Button)	be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_011

	Element
Element Name	Type	Purpose

Main Heading	Text	To give the heading for the screen
Delete		being navigated
Application
Sub Heading	Text	To give the sub heading for the screen
Select the		being navigated
Application
Application	Check Box	Check boxes for applications names
Names		to be deleted.
Sales, Select box
for Application
Check Box	Check All	On clicking the “Check All” link
		should check all the check boxes in the
		HTML table.
Check Box	Clear All	On clicking the “Clear All” link
		should uncheck all the checked check
		boxes in the HTML table.
Delete	Delete	To Delete the data this button need
		to be clicked

1.4.4.3 Front End Validation


	Element	Action/
#	Name	Validation Details	Message

1	Application	Accepts all the	Max length: 50
	Name	alphabets and numeric	Mandatory
	(Entry Field)	characters.	BPI_CAS_FSD_COMMON
2	Application	Accepts all the	Max length: 10
	Id	alphabets and numeric	Mandatory
	(Entry Field)	characters.	BPI_CAS_FSD_COMMON
3	Comments/	Accepts all the	Max length: 255
	Description	alphabets and numeric
		characters.
4	Module	Selection Box	Default: Choose One
	Name	validation	BPI_CAS_FSD_COMMON

1.4.5 User Interface ID: SECURITY_SCREEN_—012 (See FIG. P-24)

- User Interface ID: SECURITY_SCREEN_—013 (Sec FIG. P-25)
- User Interface ID: SECURITY_SCREEN_—0014 (See FIG. P-26)

1.4.5.1 User Interface Screen Snap Shot—Screen Name: Resource Master
1.4.5.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_012

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Create Resource		being navigated
Sub Header	Text	Text for Resource Id
Resource ID
Resource ID	Entry Field	Text for the entry field
Sub Header	Text	Text for Resource Name
Resource Name
Resource Name	Entry Field	Text for the entry field
Sub Header	Text	Text for screen url
Screen URL
Screen URL	Entry Field	Text for the entry field
Resource	Text	Text for the Resource Description
Description
Resource	Entry Field	Text for the entry field
Description
Save	Button (HTML	To Save the data this button need to
	Button)	be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_012 & Screen

SECURITY_SCREEN_013

Element Name	Element Type	Purpose

Search	Gif	To search the resource and application

Table for Screen SECURITY_SCREEN_013

Table for Screen SECURITY_SCREEN_14

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Delete		being navigated
Resources
Sub Heading	Text	To give the sub heading for the screen
Select the		being navigated
Resources
Resources	Check Box	Check boxes for Resources to be
		deleted.
Check Box	Check All	On clicking the “Check All” link should
		check all the check boxes in the
		HTML table.
Check Box	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check boxes in
		the HTML table.
Delete	Delete	To Delete the data this button need to
		be clicked

1.4.5.3 Front End Validation


	Element	Action/
#	Name	Validation Details	Message

1	Resource	Accepts all the	Max length: 50
	Name	alphabets and numeric	Mandatory
	(Entry Field)	characters.	BPI_CAS_FSD_COMMON
2	Resource Id	Accepts all the	Max length: 10
	(Entry Field)	alphabets and numeric	Mandatory
		characters.	BPI_CAS_FSD_COMMON
3	Screen URL	Accepts all the	Max length: 255
	(Entry Field)	alphabets and numeric	Mandatory
		characters.	BPI_CAS_FSD_COMMON
4	Comments/	Accepts all the	Max length: 255
	Description	alphabets and numeric
		characters.
5	Application	Selection Box	Default: Choose One
	Name	validation	“Mandatory”
			BPI_CAS_FSD_COMMON

1.4.6 User Interface ID: SECURITY_SCREEN_—015 (See FIG. P-27)

- Interface ID: SECURITY_SCREEN_—016 (See FIG. P-28)
- User Interface ID: SECURITY_SCREEN_—017 (See FIG. P-29)

1.4.6.1 User Interface Screen Snap Shot—Screen Name: User Master
1.4.6.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_015

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Create User		being navigated
Sub Header User	Text	Text for the User Id
Id
User Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Display Name
Display Name
Display Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Name
Name
Sub Header First	Text	Text for the First Name
Name
First Name	Entry Field	Text for the entry field
Sub Header MI	Text	Text for Middle Initial
Middle Initial	Entry Field	Text for the entry field
Sub Header Last	Text	Text for last name
Name
Last Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the password
password
Password	Entry Field	Text for the entry field
Sub Header	Text	Text for the Phone
Phone
Phone	Entry Field	Text for the entry field
Sub Header Fax	Text	Text for the fax
Fax	Entry Field	Text for the entry field
Sub Header Extn	Text	Text for the ext
Extn	Entry Field	Text for the entry field
Sub Header email	Text	Text for the email
Email	Entry Field	Text for the entry field
Sub Header Lock	Text	Text for the lock
Lock	Check Box	Check box for lock field
Save	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_016

Element Name	Element Type	Purpose

Search	Gif	To search the user

Table for Screen SECURITY_SCREEN_016

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Modify User		being navigated
Sub Header User	Text	Text for the User Name
Name
Sub Header User	Text	Text for the User Id
Id
User Id	Entry Field	Text for the entry field
Sub Header	Text	Text for the Display Name
Display Name
Display Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the Name
Name
Sub Header First	Text	Text for the First Name
Name
First Name	Entry Field	Text for the entry field
Sub Header MI	Text	Text for MI
MI	Entry Field	Text for the entry field
Sub Header Last	Text	Text for last name
Name
Last Name	Entry Field	Text for the entry field
Sub Header	Text	Text for the password
password
Password	Entry Field	Text for the entry field
Sub Header	Text	Text for the Phone
Phone
Phone	Entry Field	Text for the entry field
Sub Header Fax	Text	Text for the fax
Fax	Entry Field	Text for the entry field
Sub Header Ext	Text	Text for the Ext
Ext	Entry Field	Text for the entry field
Sub Header email	Text	Text for the email
Email	Entry Field	Text for the entry field
Lock	Check Box	Check box for the lock field
Update	Button (HTML	To Save the data this button need to
	Button)	be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_017

	Element
Element Name	Type	Purpose

Main Heading	Text	To give the heading for the screen
Delete User		being navigated
Sub Heading	Text	To give the sub heading for the
Select the User		screen being navigated
User Names	Check	Check boxes for User names to be deleted.
Sales. Select	Box
box for
Application
Check Box	Check All	On clicking the “Check All” link should
		check all the check boxes in the
		HTML table.
Check Box	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check boxes in the
		HTML table.
Delete	Delete	To Delete the data this button need to
		be clicked

1.4.6.3 Front End Validation


#	Element Name	Action/Validation Details	Message

1	Display Name	BPI_CAS_FSD_COMMON	Mandatory Max Length: 30
	(Entry Field)		BPI_CAS_FSD_COMMON
2	First Name (Entry Field)	BPI_CAS_FSD_COMMON	Mandatory Max Length: 25
			BPI_CAS_FSD_COMMON
3	MI (Entry Field)	BPI_CAS_FSD_COMMON	Mandatory Max Length: 1
			BPI_CAS_FSD_COMMON
4	Last Name (Entry Field)	BPI_CAS_FSD_COMMON	Mandatory Max Length: 35
			BPI_CAS_FSD_COMMON
5	Password (Entry Field)	BPI_CAS_FSD_COMMON	Mandatory Max Length: 15
			Min Length: 6
			BPI_CAS_FSD_COMMON
6	Phone	BPI_CAS_FSD_COMMON	Max Length: 10
			BPI_CAS_FSD_COMMON
7	Fax	BPI_CAS_FSD_COMMON	Max Length: 10
			BPI_CAS_FSD_COMMON
8	Extn	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
9	Email	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
10	Lock Status	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON

1.4.7 User Interface ID: SECURITY_SCREEN_—0018 (See FIG. P-30)

- User Interface ID: SECURITY_SCREEN_—019 (See FIG. P-31)
- User Interface ID: SECURITY_SCREEN_—020 (See FIG. P-32)

1.4.7.1 User Interface Screen Snap Shot—Screen Name: User Role Master
1.4.7.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_018

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Create User Role		being navigated
Sub Header User	Text	Text for the User Role Id
Role Id
User Role Id	Entry Field	Text for the entry field
Sub Header User	Text	Text for the User Role Name
Role Name
User Role Name	Entry Field	Text for the entry field
Sub Header User	Text	Text for the User Role Name
Role Description
User Role	Entry Field	Text for the entry field
Description
Save	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_019

Element Name	Element Type	Purpose

Search	Gif	To search the user role

Table for Screen SECURITY_SCREEN_019

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Modify User Role		being navigated
Sub Header User	Text	Text for the User Role Id
Role Id
User Role Id	Entry Field	Text for the entry field
Sub Header User	Text	Text for the User Role Name
Role Name
User Role Name	Entry Field	Text for the entry field
Sub Header User	Text	Text for the User Role Name
Role Description
User Role	Entry Field	Text for the entry field
Description
Update	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_020

	Element
Element Name	Type	Purpose

Main Heading	Text	To give the heading for the screen
Delete User Role		being navigated
Sub Heading	Text	To give the sub heading for the screen
Select the User		being navigated
Role
User Role Names	Check Box	Check boxes for User Role names to
Sales. finance		be deleted.
Check Box	Check All	On clicking the “Check All” link
		should check all the check boxes
		in the HTML table.
Check Box	Clear All	On clicking the “Clear All” link should
		uncheck all the checked check
		boxes in the HTML table.
Delete	Delete	To Delete the data this button need to
		be clicked

1.4.7.3 Front End Validation


#	Element Name	Action/Validation Details	Message

1	User Role Name	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
	(Entry Field)
2	User Role Id	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
	(Entry Field)
3	Comments/Description	BPI_CAS_FSD_COMMON	Max length: 255

1.4.8 User Interface ID: SECURITY_SCREEN_—021 (See FIG. P-33)
1.4.8.1 User Interface Screen Snap Shot—Screen Name: Group Access Rights
1.4.8.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_021

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Group Access		being navigated
Rights
Sub Header	Text	Text for the Group Name
Select Group
Group Name	Selection Box	Selection box for the Group Name
Sub Header	Text	Text for the Application Name
Select
Application
Application	Selection Box	Selection box for the Application Name
Name
Select	Button (HTML	To select the current selected Group
	Button)	to assign rights and modules.
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_021

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Group Access		being navigated
Rights
Sub Header	Text	Text for the Resource Name
Resource Name
Resource Name	Check Boxes	Check boxes
Sub Header	Text	Text for Access Rights
Access Rights
Combo Box	Combo Box	Combo box for selection of access
		rights.
Save	Button (HTML	To Save the data this button need to
	Button)	be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

1.4.8.3 Front End Validation


#	Element Name	Action/Validation Details	Message

1	Group Name	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
2	Application Name	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON
3	Resource Id	BPI_CAS_FSD_COMMON	BPI_CAS_FSD_COMMON

1.4.9 User Interface ID: SECURITY_SCREEN_—022(See FIG. P-34)

- User Interface ID: SECURITY_SCREEN_—023 (See FIG. P-35)

1.4.9.1 User Interface Screen Snap Shot—Screen Name: User, Role and Group Mapping
1.4.9.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_022

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen being
User Search		navigated
Sub Header	Text	Text for the User Id
Select User Id
User Id	Text Box	Text Field for the User Id
Sub Header	Text	Text for the User Name
Select User
Name
User Name	Text Box	Text Field for the User Name
Search	Button (HTML	To search the current selected User id
	Button)
Cancel	Button (HTML	To cancel current operation.
	Button)

Table Screen SECURITY_SCREEN_022

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
User Search		being navigated
Sub Header	Text	Text for the User Id
Select User Id
User Id	Text Field	Text Field for the User Id
Sub Header	Text	Text for the User Name
Select User
Name
User Name	Text Field	Text Field for the User Name
Search	Button (HTML	To search the current selected User id
	Button)
Cancel	Button (HTML	To cancel current operation.
	Button)
Sub Heading	Text	To give the heading for the search
User Search		screen
Results
Sub Header User	Label	Text for the User Id
Id
Sub Header User	Label	Text for the User Name
Name
Data Row from	User Id	User id from database. To be
database		displayed in table
Data Row from	User Name	User name from database. To be
database		displayed in table
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_023

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
User Role		being navigated
Mapping
Sub Header	Text	Text for the User Id
Select User Id
User Id	Text Label	Text Label for the User Id
Sub Header	Text	Text for the User Name
Select User
Name
User Name	Text Label	Text Label for the User Name
Sub Header	Text	Text for the User Role
Select User Role
Selection box	Selection Box	Selection Box for User Role
Select	Button (HTML	To select the current selected User id
	Button)
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen FIG. 33: Screen SECURITY_SCREEN_023

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
User Role		being navigated
Mapping
Sub Header	Text	Text for the User Id
Select User Id
User Id	Text Label	Text Label for the User Id
Sub Header	Text	Text for the User Name
Select User
Name
User Name	Text Label	Text Label for the User Name
Sub Header User	Text	Text for the User Role
Role
Text Label	Text Label	Selection Box for User Role
Sub Header	Text	Text for the Groups
Select the groups
Check Box	Check Box	Check Box for groups. User can
		select one or more groups.
Select	Button (HTML	To select the current selected User id
	Button)
Cancel	Button (HTML	To cancel current operation.
	Button)

1.4.10 User Interface ID: SECURITY_SCREEN_—024 (See FIG. P-36)

- User Interface ID: SECURITY_SCREEN_—025 (See FIG. P-37)

1.4.10.1 User Interface Screen Snap Shot—Screen Name: Group Access Rights
1.4.10.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_024

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
User Search		being navigated
Sub Header	Text	Text for the User Id
Select User Id
User Id	Text Box	Text Field for the User Id
Sub Header	Text	Text for the User Name
Select User
Name
User Name	Text Box	Text Field for the User Name
Search	Button (HTML	To search the current selected User id
	Button)
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_024

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
User Search		being navigated
Sub Header	Text	Text for the User Id
Select User Id
User Id	Text Field	Text Field for the User Id
Sub Header	Text	Text for the User Name
Select User
Name
User Name	Text Field	Text Field for the User Name
Search	Button (HTML	To search the current selected User
	Button)	id
Cancel	Button (HTML	To cancel current operation.
	Button)
Sub Heading	Text	To give the heading for the search
User Search		screen
Results
Sub Header User	Label	Text for the User Id
Id
Sub Header User	Label	Text for the User Name
Name
Data Row from	User Id	User id from database. To be
database		displayed in table
Data Row from	User Name	User name from database. To be
database		displayed in table
Cancel	Button (HTML	To cancel current operation.
	Button)

Table for Screen SECURITY_SCREEN_025

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
User Access		being navigated
Rights
Sub Header User	Text	Text for the User Name
Name
User Name	Text	Text for the User Name
Sub Header User	Text	Text for the User Id
ID
User Id	Text	Text for the User Id
Sub Header	Text	Text for the Module Name
Module Name
Selection Box	Selection Box	Selection Box for Module name
Sub Header Role	Text	Text for the Role Name
Name
Selection Box	Selection Box	Selection Box for Role name
Select	Button (HTML	To select the current selected User
	Button)	assign rights for all the
		application.
Cancel	Button (HTML	To cancel current operation.
	Button)

indicates data missing or illegible when filed

Table for Screen SECURITY_SCREEN_025

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen being
User Access		navigated
Rights
Sub Header	Text	Text for the Resource Name
Resource Name
Resource name	Text	Text for the Resource Name
Sub Header	Text	Text for Access Rights
Access Rights
Combo Box	Combo Box	Combo box for selection of access
		rights.
Save	Button (HTML	To Save the data this button need
	Button)	to be clicked
Cancel	Button (HTML	To cancel current operation.
	Button)

1.4.10.3 Front End Validation


#	Element Name	Action/Validation Details	Message

1	User Role	BPI_CAS_FSD_COMMON	“Please choose
			the User Role”
2	Module Name	BPI_CAS_FSD_COMMON	“Please choose the
			Module name”
3	Access Rights	BPI_CAS_FSD_COMMON	“Please choose the
			Resource name”

1.4.11 User Interface ID: SECURITY_SCREEN_—026 (See FIG. P-38)
1.4.11.1 User Interface Screen Snap Shot—Screen Name: Configurable Items
1.4.11.2 Field Name, Element Type & Purpose

Table for Screen SECURITY_SCREEN_026

Element Name	Element Type	Purpose

Main Heading	Text	To give the heading for the screen
Configure Items		being navigated
Sub Header	Text	Text for the Password Length
Password Length
Password Length	Text Box	Text Field for the Password Length
Sub Header	Text	Text for the Password Length
Password Length		(Minimum)
(Minimum)
Password Length	Text Box	Text Field for the Password Length
(Minimum)		(Minimum)
Sub Header	Text	Text for the Expiry of password
Expiry of
password (Max)
Expiry of	Text Box	Text Field for the Expiry of password
password
Sub Header	Text	Text for the Expiry of password
Expiry of
password (Min)
Expiry of	Text Box	Text Field for the Prompt Date Period
password
Sub Header	Text	Text for the Prompt Date Period
Prompt Date
Period
Prompt Date	Text Box	Text Field for the Expiry of password
Period		Prompt Date Period
Sub Header	Text	Text for the Password Repeat Count
Password Repeat
Count
Password Repeat	Text Box	Text Field for the Password Repeat
Count		Count
Sub Header	Text	Text for the Invalid Passwords Count
Invalid
Passwords Count
Invalid	Text Box	Text Field for the Invalid Passwords
Passwords Count		Count
Sub Header Lock	Text	Text for the Lock Time
Time
Lock Time	Text Box	Text Field for the Lock Time
Search	Button (HTML	To search the current selected User id
	Button)
Cancel	Button (HTML	To cancel current operation.
	Button)

1.4.11.3 Front End Validation


		Action/Validation
#	Element Name	Details	Message

1	Password Length	Numeric (Integer)	Integer Length max 2
	(Maximum &		For eg Min Value 6
	Minimum)		Max Value 10
2	Expiry of password	Numeric (Integer)	Integer Length max 2
	(Min)		For eg Min Value 1
			Max Value 99
3	Expiry of password	Numeric (Integer)	Integer Length max 2
	(Max)		For eg Min Value 0
			Max Value 99
			Should be greater than
			Expiry of password (Min)
4	Password Repeat	Numeric (Integer)	Integer Length max 2
	Count		For eg Min Value 1
			Max Value 10
5	Invalid Passwords	Numeric (Integer)	Integer Length max 2
	Count		For eg Min Value 1
			Max Value 10
6	Lock Time	Numeric (Integer)	Integer Length max 2
	(Minutes)		For eg Min Value 10
			Max Value 36000
7	Password Length	Numeric (Integer)	Integer Length max 2
	(Minimum)		For eg Min Value 6
			Max Value 10
			Less than maximum length
			of password
8	Prompt Date	Numeric (Integer)	Less than maximum limit
	Period for		for expiration date
	expiration		For eg Min Value 1
			Max Value 10

1.4.12 User Login

- When the system user logs in into the core administration system the separate ACL will be generated for each user. The ACL will be stored in the User Profile object, which will be stored in the user session. When user request for a particular page controller will check with the security system whether user is having access to the particular page.
- When any user requests a particular page in the core administrative system, the controller will ask the security system about the security rights for the application. If user is having rights he will be allowed to perform the current operation.
- For e.g. If user request for create carrier master. The carrier master is registered into the system with system with id as 0001. The controller will check the access rights for the carrier master. If the rights for carrier master is write then user will have access to create carrier master as the user rights are higher than requested one. If user is having access rights as read for carrier master then he would not be able to access because it is having lower rights than requested one.

Password Validation

- Password validation to be done as per the requirements specified before. The following items need to be configured as per requirements.

1.5 Business Rules


	Activity	Rules

	Delete Rule	For Deleting referential integrity need to be
		considered.
		A group can be deleted if no user is referring to the
		group
		Same applies to other hierarchy
		Module
		Application
		Resource

1.6 Help Menu

- Help to be provided for all the screens. Help should contain following details.
  - Basic Functionality Description
  - Description about the screen fields.

1.7 Process-Data Structure

- This section describes the likely data structure that would contain the data for/by executing the process

BPI_MODULES

Data Element Name	Data Element Type	Constraints

MODULE_ID	Varchar (10)	PK Not Null
MODULE_NAME	Varchar (50)	Not Null
DESCRIPTION	Varchar (255)
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
STATUS	NUMBER	1- Active
		0- Inactive

BPI GROUPS

Data Element Name	Data Element Type	Constraints

GROUP_ID	Varchar (10)	PK Not Null
DESCRIPTION	Varchar (255)	Not Null
GROUP_NAME	Varchar (50)
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
STATUS	NUMBER	1- Active
		0- Inactive

BPI APPLICATIONS

Data Element Name	Data Element Type	Constraints

APPLICATION_ID	Varchar (10)	PK Not Null
APPLICATION_NAME	Varchar (50)	Not Null
DESCRIPTION	Varchar (255)
MODULE_ID	Varchar (10)	FK Refers
		BPI_MODULES
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
STATUS	NUMBER	1- Active
		0- Inactive

BPI RESOURCES

	Data Element
Data Element Name	Type	Constraints

RESOURCE_ID	Varchar (10)	PK Not Null
RESOURCE_NAME	Varchar (50)	Not Null
DESCRIPTION	Varchar (255)
APPLICATION_ID	Varchar (10)	FK Refers
		BPI_APPLICATIONS
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar(25)
LAST_MODIFIED_DATE	Timestamp
STATUS	NUMBER
	1 Active
		0- Inactive

BPI ACL

Data Element Name	Data Element Type	Constraints

ACL_ID	Varchar (10)	PK Not null
ACL_NAME	Varchar (50)	Not null
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar(25)
LAST_MODIFIED_DATE	Timestamp
STATUS	NUMBER
	1 Active
		0- Inactive

BPI ROLES

Data Element Name	Data Element Type	Constraints

ROLE_ID	Varchar (10)	PK Not null
ROLE_NAME	Varchar (50)	Not null
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar(25)
LAST_MODIFIED_DATE	Timestamp
STATUS	NUMBER
	1 Active
		0- Inactive

BPI USERS

Data Element Name	Data Element Type	Constraints

USER_ID	Varchar (10)	PK Not null
PASSWORD	Varchar (30)	Not null
ADDRESS
1	Varchar (30)
ADDRESS 2	Varchar (30)
CITY	Varchar (25)
STATE	Varchar (25)
ZIP	Varchar (25)
COUNTRY	Varchar (25)
PHONE 1	Varchar (25)
PHONE 2	Varchar (25)
PHONE 3	Varchar (25)
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
STATUS	Number
	1 Active
		0 Inactive
PASSWORD_EXPIRY_DATE	Timestamp
LOCK_STATUS	Number

BPI GROUP ACCESS

	Data Element
Data Element Name	Type	Constraints

GROUP_ID	Varchar (10)	Not null Refers
		BPI_GROUPS
RESOURCE_ID	Varchar (105)	Not null Refers
		BPI_RESOURCES
APPLICATION_ID	Varchar (10)	Not null Refers
		BPI_APPLICATIONS
ACL_ID	Varchar (10)	Not null Refers
		BPI_ACL
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
STATUS	Number
	1 Active
		0 Inactive

BPI USER ROLES

Data Element Name	Data Element Type	Constraints

USER_ID	Varchar (10)	Not Null Refers
		BPI_USERS
ROLE_ID	Varchar (10)	Not Null Refers
		BPI_ROLES
GROUP_ID	Varchar (10)	Not Null Refers
		BPI_USGROUPS
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
Status	Number
	1 Active
		0 Inactive

BPI USER ACCESS

	Data
	Element
Data Element Name	Type	Constraints

RESOURCE_ID	Varchar (10)	Not Null
		Refers BPI_RESOURCE
USER_ID	Varchar (25)	Not Null Refers
		BPI_USERS
ACL_ID	Varchar (10)	Not Null Refers BPI_ACL
ROLE_ID	Varchar (10)
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
Status	Number
	1 Active
		0 Inactive

BPI USER PASSWORD HISTORY

Data Element Name	Data Element Type	Constraints

USER_ID	Varchar (10)	Not Null Refers
		BPI_USERS
PASSWORD	Varchar (10)	Not Null
CREATED_BY	Varchar (25)
CREATED_DATE	Timestamp
MODIFIED_BY	Varchar (25)
LAST_MODIFIED_DATE	Timestamp
Status	Number
	1 Active
		0 Inactive

1.8 Back End Validations

- This subsection provides the field element name and corresponding back end validation if applicable.
- Back end validations are those validations where the validations have got to be necessarily done using the database.
- As a general rule backend validations should be done for all the validation checks that are being carrier on the front end.

1.9 Non-Functional Requirements

- This subsection corresponds to the requirements that do not relate to the user function. It provides information on the system requirements—Ideally identifies the present problems in the existing system from a non-functional perspective and avoiding the same in the new system


Non Functional
Requirement	Details

Performance	Performance criteria should be established based
	on the data size and the page size.
System Exception	All system exceptions should be handled grace
	fully throwing a error page with relevant exception
	information and action to be taken for resolving the
	exception

1.10 Access Control List

- This section describes the classification of users who can access the process under definition


User ID	Job Description	Functionality	Access Level

Benefit Partners Inc

Process Specification

Common Functional Features

1. Introduction

1.1. Purpose

- The purpose of this document is to describe the common functional features available across all the modules. This document is identified as Common Functional Features. This document identifies how the user interacts with the system, the data to be captured, the business logic to be implemented, and the output of the process for the common functional features.

1.2. Business Use Case Specification Reference


	Business Use Specification ID	Business Use Case Name

	BPI_SCOPE	Scope Document
	BPI_SCOPE_ADD	Addendum to scope

1.3. Definitions, Acronyms & Abbreviations


	Term	Explanation

2. Process Identification

2.1. Background

- Common functional feature is to identify the common functionality across all the modules that have the same usage. This would help in standardization and reuse of the components.

2.2. Process Description

- The objective of the Common Functional Features process is to:
  - 1) Identify the Common functional features across all the modules:

2.3. Process Flow

- Not applicable

3. User Interface

3.1. User Interface Screens
3.1.1. Not Applicable
3.1.2. Not Applicable
3.1.3. Element Name, Element Type & Purpose


Element Name	Element Type	Purpose

First name	Entry Field	Enter the First name
Last name	Entry Field	Enter the last name
Middle name (MI)	Entry Field	Enter the middle Name
Suffix	Drop Down List	List the Suffix
Salutation	Drop Down List	List the Salutation
Title	Entry Field	Enter the Job Title
Address	Entry Field	Enter the first detail about the address
Suite/Apt. #	Entry Field	Enter the suite/Apartment or PO BOX number
City	Entry Field	Enter the name of the city
State	Drop Down List	List all the States in UAS
ZIP	Entry Field	Enter the ZIP Code
Phone #	Entry Field	Enter the Phone number
Fax #	Entry Field	Enter the FAX number
Phone Extension	Entry Field	Enter extension number
FAX Extension	Entry Field	Enter extension number
Email Address	Entry Field	Enter the email address
Credit Card Number	Enter the Credit Card	Entry Credit Card number
	Number
Credit Card Type	Drop Down List	List the type of Credit Card
(Date) Current Date	Calendar/Entry Field	Entry field to type the date or Calendar to pick the
(System Date)		date
(Date) Past Date (1900	Calendar/Entry Field	Entry field to type the date or Calendar to pick the
to system date)		date
(Date) Future Date	Calendar/Entry Field	Entry field to type the date or Calendar to pick the
(System date to 100 Yr.		date
hence)
(Date) Default 1^stof	Calendar/Entry Field	Entry field to type the date or Calendar to pick the
Following Month (eg.		date
System date is Dec. 2, 2001
should default to
Jan. 1, 2002)
(Date) Default 1^stof	Calendar/Entry Field	Entry field to type the date or Calendar to pick the
the current Month (e.g.		date
System date is Dec. 2, 2001
should default to
Dec. 1, 2001)
(Date) Default End of	Calendar/Entry Field	Entry field to type the date or Calendar to pick the
current Month (eg.		date
System date is Dec. 2, 2001
should default to
Dec. 31, 2001)
(Date) Credit Card	Drop Down List	List all the Months in a year
Date (should only
accept future date.)
Month
Date) Credit Card	Drop Down List	List the year 25 years ahead
Date (should only
accept future date.)
Year
Social Security	Entry Field	Enter the Social Security number
Number
TAX Identification	Entry Field	Enter the Tax Identification Number
Number
Mode of	Drop Down List	List Various modes of communication
Communication
Browser Back Button	Button	Validate the back button
Browser Forward	Button	Validate the forward button
Button
Refresh Button	Button	Validate Refresh button
Address Bars	Tool Bars	Hide Address bar
Link Bar	Tool Bars	Hide Link bar
Standard Button	Tool bars	Hide standard bars
Window Close	Browser Window	Validate Close
Window Minimize	Browser Window	Validate minimize

3.1.4. Screen Validations

- Note: Validation provided here are the default validations. However if the module functionality has specified different validations for these element described then that would override the default validations provided here.


Element Name	Action/Validation Details	Message

First name	Entry Field with 40 Character long.
	Can accept only Alpha characters.
	Arnold
Last name	Entry Field with 40 Character long
	Can accept only Alpha characters.
	Schwarzenegger
Middle name (MI)	Entry Field with 1 Character long
	Can accept only Alpha characters.
	M. A etc.
Suffix	List should include Jr., Sr., I., II.,
	III., IV., and V.
Salutation	List should include Mr., Mrs., Ms.
Title	Entry Field with 20 Character long
	Can accept Alpha and numeric
	character and blank space between
	character (Example Administrator 1)
Address	Entry Field with 40 Character long
	3013 Douglas Boulevard,
	Can accept free form entry with any
	character.
Suite/Apt. #	Entry Field with 20 Character long
	Example 200 or 1 D etc.
	Can accept free form entry with any
	character.
City	Entry Field with 20 Character long
	Alpha only and Blank between
	words allowed
	Roseville, San Jose, San Diego
State	List all the States in USA in
	abbreviated form as CA, IL, OH, NY
	etc.
ZIP	Entry Field with 5 Character long
	Should allow maximum and
	minimum of 5 Numbers only. Whole
	Number Field.
Phone #	Entry Field with 10 Character long
	Should allow maximum and
	minimum of 10 Numbers only.
	Whole Number Field.
	3 for Area code, 7 for the number.
Fax #	Entry Field with 10 Character long
	Should allow maximum and
	minimum of 10 Numbers only.
	Whole Number Field.
	3 for Area code, 7 for the number.
Phone Extension	Entry Field with 5 Character long
	Should allow maximum of 5 and
	minimum of 1. Blanks fields are
	acceptable.
	Whole Number Field.
FAX Extension	Entry Field with 5 Character long
	Should allow maximum of 5 and
	minimum of 1. Blanks fields are
	acceptable.
	Whole Number Field.
Email Address	Entry Field with 40 Character long
	Allow entering more than 40
	character.
	Validate for a Valid Email Address.
Credit Card	Entry Field with 20 Character long
Number	Minimum and maximum value
	should be 16. Allow only Whole
	Number. Numeric Field
	For Amex allow 20 as min and max
	value.
Credit Card Type	List Credit Card type as
	Visa, Master, Discovery, Amex etc
(Date) Current	Entry Field or Calendar with default
Date (System Date)	system date in the Entry Field and
	calendar.
(Date) Past Date	Entry Field or Calendar with default
(1900 to system	system date − 1 in the Entry Field
date)	and calendar. Do not allow for
	Current date and future date
(Date) Future Date	Entry Field or Calendar with default
(System date to	system date in the Entry Field and
100 Yr. hence)	calendar. Do not allow for past date
(Date) Default 1^st	Entry Field or Calendar with default
of Following	first of the following month date in
Month (eg. System	the Entry Field and calendar.
date is Dec. 2, 2001
should default to
Jan. 1, 2002)
(Date) Default 1^st	Entry Field or Calendar with default
of the current	first of the current month date in the
Month (e.g. System	Entry Field and calendar.
date is Dec. 2, 2001
should default to
Dec. 1, 2001)
(Date) Default End	Entry Field or Calendar with default
of current Month	end of the current month date in the
(eg. System date is	Entry Field and calendar.
Dec. 2, 2001 should
default to
Dec. 31, 2001)
(Date) Credit Card	List to show all the months in a year
Date (should only
accept future date.)
Month
Date) Credit Card	List the years from current year to
Date (should only	100 years forward hence.
accept future date.)	Validate The Credit Card month and
Year	year together. Should not have past
	month as credit card entry.
Social Security	Entry Field with 9 Character long
Number	Should allow maximum of 9 and
	minimum of 9.
	Whole Number Field.
TAX Identification	Entry Field with 9 Character long
Number	Should allow maximum of 9 and
	minimum of 9.
	Whole Number Field.
Mode of	List various modes of
Communication	Communication like Fax, Phone,
	Email, USPS
Browser Back	Disable the browser back button and
Button	hide the back button
Browser Forward	Disable the browser forward button
Button	and hide the forward button
Refresh Button	Disable the browser refresh button
	and hide the refresh button
Address Bars	Disable the address bar so that user
	cannot type the URL to navigate to
	the respective screen
Link Bar	Disable the link bar
Standard Button	Disable the browser standard button
Window Close	Catch windows close event with
	Java script and show the message.
Window Minimize	Allow to minimize the window

3.1.5. Interface Flow

- N/A

3.1.6. Help Menu


Element Name	Purpose	Valid Values

4. Business Rule Mapping

- Not Applicable


	Activity	Rules

	1.

5. Data Structures

- Not Applicable


	Data Element Name	Data Element Type

5.1. Back End Validations

- Not Applicable


	Field Element Name	Back End Validation

6. Non-Functional Requirements

- Not Applicable


	Non Functional Requirement	Details

7. Access Control List

- Not Applicable


User ID	Job Description	Functionality	Access Level

Claims

1.-13. (canceled)

14. An automated benefits administration system of the type used to administer benefits subject to business rules for such benefits, the benefits being organized as multiple benefit plans offered from multiple carriers, the benefits administration system comprising:

(A) an automated business rules application including software instructions for automatically applying multiple business rules to data input for enrollment data, eligibility data, and group maintenance data, and further including software instructions for making business rule decisions based on said data input, wherein the multiple business rules include:

one or more enrollment rules, each of the one or more enrollment rules pertaining to enrollment in one of the multiple benefit plans from one of the multiple carriers;

one or more eligibility rules, each of the one or more eligibility rules pertaining to eligibility for at least one benefit available as part of one of the multiple benefit plans from one of the multiple carriers; and

one or more group maintenance rules, each of the one or more group maintenance rules pertaining to enrollment or eligibility activities for a group of one or more members; and

(B) an automatic action application including software instructions for issuing notices for business rule discrepancies based on said data input.

15. The automated benefits administration system of claim 14 also comprising: (C) a business rules database having the multiple business rules and making the multiple business rules accessible to the automated business rules application, whereby the automated business rules application may apply the multiple business rules from said business rules database.

16. The automated benefits administration system of claim 15 also comprising: (D) a business rule override tool through which a user may override one or more of the multiple business rules applied by the automated business rules application based on user authority level, wherein the business rule override tool includes software instructions for:

identifying an exception to one of the multiple business rules;

determining type of the exception;

identifying an authority level of the user; and

determining whether or not to override the exception based upon the authority level of the user and the type of the exception.

17. The automated benefits administration system of claim 14 also comprising: (C) a business rule override tool through which a user may override one or more of the multiple business rules applied by the automated business rules application based on user authority level, wherein the business rule override tool includes software instructions for:

identifying an exception to one of the multiple business rules;

determining type of the exception;

identifying an authority level of the user; and

18. The automated benefits administration system of claim 17 wherein the determining the type of the exception comprises classifying the exception as one of:

a first exception type that indicates missing enrollment data;

a second exception type that indicates inconsistent enrollment data;

a third exception type that indicates failure of one of the one or more eligibility rules; and

a fourth exception type that indicates failure of one of the one or more group maintenance rules.

19. The automated benefits administration system of claim 17 wherein the determining the authority level comprises setting the authority level as one of:

a first authority level that indicates absence of authority to override exceptions to the multiple business rules;

a second authority level that indicates authority to override exceptions that relate to missing enrollment data but not to eligibility; and

a third authority level that indicates authority to override any exceptions to the multiple business rules.

20. The automated benefits administration system of claim 14 further comprising an accounting module that includes software instructions for:

receiving a change notification that indicates a change in enrollment for a group for which an invoice has been generated, the invoice indicating an invoice amount;

receiving a payment notification that indicates a payment amount from the group;

determining that the payment amount differs from the invoice amount; and

automatically accounting for the change in enrollment for the group by adjusting an amount due to reconcile the payment amount and the invoice amount.

21. The automated benefits administration system of claim 20 wherein the change in enrollment for the group is a termination of a member of the group, and wherein the adjustment comprises decreasing the amount due based upon the termination.

22. The automated benefits administration system of claim 14 wherein the automated business rules application further includes software instructions for:

initiating termination of a group;

delaying the termination for a delay period based on a reinstatement period duration; and

if the delay period expires before reinstatement of the group occurs, completing the termination of the group.

23. The automated benefits administration system of claim 14 wherein the automated business rules application further includes software instructions for:

for each of the plural members of the group:

accepting the enrollment data and the eligibility data for a given application by the member;

checking the enrollment data for the application against the one or more enrollment rules;

checking the eligibility data for the application against the one or more eligibility rules;

upon satisfaction of the one or more enrollment rules and the one or more eligibility rules, routing a completed version of the application to a reviewer for the group for approval;

for each of the plural completed versions of the applications:

presenting to the reviewer the completed version of application by the member; and

upon receipt of approval from the reviewer, finalizing enrollment of the member.

24. The automated benefits administration system of claim 14 wherein the automated business rules application further includes software instructions for:

from a first user having a first authority level, accepting the enrollment data and the eligibility data for a given application;

checking the enrollment data and the eligibility data for the application against the one or more enrollment rules and the one or more eligibility rules, respectively, to identify one or more exceptions;

presenting at least one of the one or more exceptions to a second user for review, the second user having a second authority level higher than the first authority level;

accepting user input from the second user indicating whether to override the at least one of the one or more exceptions;

if any of the one or more exceptions remains, for at least one remaining exception:

presenting the remaining exception to a third user having a third authority level higher than the second authority level; and

accepting user input from the third user indicating whether to override the remaining exception; and

if none of the one or more exceptions remains, finalizing the application.

25. The automated benefits administration system of claim 24 wherein the first authority level is data entry authority level, the second authority level is supervisor authority level, and the third authority level is manager authority level.

26. A benefits administration method of operating an automated benefits administration computing system of the type for administering benefits subject to business rules for said benefits, the benefits being organized as multiple benefit plans offered from multiple carriers, the benefits administration method comprising:

(A) in the automated benefits administration computing system, automatically applying multiple business rules to data input for enrollment data, eligibility data, and group maintenance data, and making business rule decisions based on said data input, wherein the multiple business rules include:

(B) in the automated benefits administration computing system, automatically issuing notices for business rule discrepancies based on said data input.

27. The benefits administration method of claim 26 further comprising, during said automatic application step (A), automatically accessing a business rules database having the multiple business rules.

28. The benefits administration method of claim 27 further comprising, in step (A), providing a business rule override as selected by a user have a predetermined authority level, including:

identifying an exception to one of the multiple business rules;

determining type of the exception;

identifying the predetermined authority level of the user; and

deciding to override the exception based upon the predetermined authority level of the user and the type of the exception.

29. The benefits administration method of claim 26 further comprising, in step (A), providing a business rule override as selected by a user have a predetermined authority level, including:

identifying an exception to one of the multiple business rules;

determining type of the exception;

identifying the predetermined authority level of the user; and

30. The benefits administration method of claim 26 wherein the automatic issuance of notices for business rule discrepancies includes automatic issuance of one or more attention notices to a remote managing party upon entry of certain unsatisfactory data during local data input, the method further comprising:

(C) in the automated benefits administration computing system, providing at least remote enrollment access over the Internet to said automated benefits administration computing system.

31. An automated benefits administration system of the type used to administer benefits subject to business rules for such benefits, the benefits being organized as multiple benefit plans offered from multiple carriers, the benefits administration system comprising:

(A) an automated business rules application including software instructions for automatically applying multiple business rules, including at least all legally-required rules and desired additional rules, to data input for enrollment data, eligibility data, and group maintenance data, and further including software instructions for making business rule decisions based on said data input, wherein the multiple business rules include:

(B) an automatic action application including software instructions for issuing notices for business rule discrepancies based on said data input, the automatic action application including the ability to issue notices to third parties by disparate communications vehicles.

32. The automated benefits administration system of claim 31 also comprising: (D) a business rule override tool through which a user may override one or more of the multiple business rules applied by the automated business rules application based on user authority level, wherein the business rule override tool includes software instructions for:

identifying an exception to one of the multiple business rules;

determining type of the exception;

identifying an authority level of the user; and

33. The automated benefits administration system of claim 31 also comprising: (C) a business rule override tool through which a user may override one or more of the multiple business rules applied by the automated business rules application based on user authority level, wherein the business rule override tool includes software instructions for:

identifying an exception to one of the multiple business rules;

determining type of the exception;

identifying an authority level of the user; and