BENEFITS ADMINISTRATION SYSTEM AND METHODS OF USE AND DOING BUSINESS

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.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
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

    • 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. 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

    • 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. 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

    • 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. 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

    • 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. 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.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

    • 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. 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

    • 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. 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

    • 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. 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

    • 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 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

    • 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 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

    • 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. 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

    • 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 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

    • 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 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

    • 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. 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

    • 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 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

    • 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. 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

    • 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 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

    • 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 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

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 “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 45th day 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

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

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—014—Dependent Search of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—010—Missing Information of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—011—Enrollment Confirmation of BPI_CAS_FSD_EN—01

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 1st of 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 1st of 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 1st following 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. 1st of 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 1st of the monthly only If this changes then any existing COBRA with this group will change accordingly and automatically, 1st of the month. Should trigger automatic transmission TEFRA Can be change any time but will be effective from 1st 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

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 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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—013—Employee Search of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—007—Employee Coverage of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—014—Dependent Search of BPI_CAS_FSD_EN—01

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

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

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—010—Missing Information of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—011—Enrollment Confirmation of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—006—Employee Information of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—007—Employee Coverage of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—014—Dependent Search of BPI_CAS_FSD_EN—01

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

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

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—010—Missing Information of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—003—Billing of BPI_CAS_FSD_EN—01

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

    • Refer to User Interface ID: BPI_CAS_SCR_EN—001—011—Enrollment Confirmation of BPI_CAS_FSD_EN—01

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)

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.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)

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.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)

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.employeeprocessreinstatement
    • Screen Snap Shot (See FIG. I-55)

Element Name Element Type Purpose Effective Date Entry Field Entry Field for the Date. Change Status Select Box Select Change Status
    • SID: enrollmentreinstatementemployeereinstatementconfirm
    • Screen Snap Shot
    • SID: enrollment.reinstatement.dependentsearch
    • Screen Snap Shot (See FIG. I-56)

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: enrollmentreinstatement.dependentreinstatementrequest
    • Screen Snap Shot (See FIG. I-57)

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.dependentprocessreinstatement
    • Screen Snap Shot (See FIG. I-58)

Element Name Element Type Purpose Effective Date Entry Field Entry Field for the Date. Change Status Select Box Select Change Status
    • 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 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

Dependent Reinstatement 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 Reinstatement 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 Reinstatement 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

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

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

    • 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 lst of 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 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 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. 7a. 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. 7a: 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

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

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

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

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

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

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 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_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

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

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

    • 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 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

    • 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 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

    • 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 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

    • 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 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

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

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 1st of 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 1st of 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 1st 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 1st 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
determining whether or not to override the exception based upon the authority level of the user and the type of the exception.

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: 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) 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
deciding to override the exception based upon the predetermined authority level of the user and the type of the exception.

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: 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, 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
determining whether or not to override the exception based upon the authority level of the user and the type of the exception.

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
determining whether or not to override the exception based upon the authority level of the user and the type of the exception.
Patent History
Publication number: 20120246088
Type: Application
Filed: Dec 12, 2011
Publication Date: Sep 27, 2012
Inventors: John Steinbarth (Lake Dallas, TX), Patricia Steinbarth (Lake Dallas, TX)
Application Number: 13/323,750
Classifications
Current U.S. Class: Benefits Package (705/322)
International Classification: G06Q 10/06 (20120101);