STATE OF MONTANA
                                 REQUEST FOR PROPOSAL (RFP)
                        RFP Title:
RFP Number...
TABLE OF CONTENTS

SCHEDULE OF EVENTS........................................................................................
5.9    OPERATIONS AND MAINTENANCE PHASE......................................................................................
SCHEDULE OF EVENTS


                                   EVENT                                                       DATE
R...
SECTION 1.PROJECT OVERVIEW AND INSTRUCTIONS/ADMINISTRATIVE
                            REQUIREMENTS
1.0.OVERVIEW
The Depar...
including a SFSL for DPHHS. CHIMES-TANF and CHIMES-SNAP will leverage work completed in CHIMES-Medicaid.
These three syste...
TANF systems.

The following table provides a detailed breakdown of the anticipated components for the stated contract ter...
1.3.2. Form of Questions
Offerors with questions or requiring clarification or interpretation of any section within this R...
in any formal written addendum issued for this RFP and will apply to all offerors submitting a response to this RFP. The S...
1.7.SUBMITTING A PROPOSAL
   1.7.1. Organization of a Proposal
Offerors must organize their proposal into sections that fo...
1.8.COST OF PREPARING A PROPOSAL
   1.8.1. State Not Responsible for Preparation Costs
The costs for developing and delive...
SECTION 2.RFP STANDARD INFORMATION
2.0.AUTHORITY
This RFP is issued under the authority of section 18-4-304, MCA (Montana ...
required information is not provided or the proposal is not within the plans and specifications described and
required in ...
2.3.7. Evaluator/Evaluation Committee Recommendation for Contract Award
The evaluator/evaluation committee will provide a ...
2.5.DEPARTMENT OF ADMINISTRATION POWERS AND DUTIES
The Department of Administration is responsible for carrying out the pl...
SECTION 3.RFP INTRODUCTION AND BACKGROUND
3.0.GENERAL INFORMATION
DPHHS seeks to replace its current mainframe TANF and SN...
c. The systems must incorporate system training modules and/or a system help function.
        d. The systems must incorpo...
a. Data within the systems must be secure and accessible only to those with proper access.
       b. The systems must have...
areas of quality control, program security, and EBT system benefit issuance. The new eligibility systems must
use a variet...
•   Reengineering processes critical to the Department mission.
•   Developing and operating internal and external compute...
3.1.3.4.Organization Chart
3.1.4. Information Technology Services Division
The State’s Information Technology Services Division (ITSD) is also an imp...
3.1.5. SNAP Program Overview
The Supplemental Nutrition Assistance Program (SNAP), formerly known as the Food Stamp Progra...
each year. If they do not, the Federal government can penalize the state by sanctioning a percentage of their
block grant ...
SECTION 4.GENERAL REQUIREMENTS
4.0.INTRODUCTION
This section of the RFP provides general requirements for the contractor s...
the project management function must be completed according to the contractor’s proposed work plan, as
approved by Departm...
fix per defect to date.
7. During user acceptance test, weekly reporting of the number of test cases, scripts or scenarios...
development activities in relation to this project. The contractor will be a partner with the Department project
staff and...
programs that are administered by DPHHS. The contractor must follow operational compliance efforts with
existing and ongoi...
the Department that the requesting party has signed the State’s HIPAA Business Associate Addendum.
2. Before disclosing an...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
SNAP and TANF Eligibility Systems, Enterprise Architecture ...
Upcoming SlideShare
Loading in …5
×

SNAP and TANF Eligibility Systems, Enterprise Architecture ...

3,081 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,081
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SNAP and TANF Eligibility Systems, Enterprise Architecture ...

  1. 1. STATE OF MONTANA REQUEST FOR PROPOSAL (RFP) RFP Title: RFP Number: SNAP AND TANF ELIGIBILITY SYSTEMS, ENTERPRISE ARCHITECTURE, AND RFP09-1694P FISCAL SERVICES RFP Response Due Date and Time: July 30, 2009 Number of Pages: Part 1 of 3, 83 pages 2:00 p.m., Local Time ISSUING AGENCY INFORMATION Procurement Officer: Issue Date: Penny Moon May 29, 2009 State Procurement Bureau Phone: (406) 444-2575 General Services Division Fax: (406) 444-2529 Department of Administration TTY Users, Dial 711 Room 165, Mitchell Building 125 North Roberts Street P.O. Box 200135 Website: http://vendor.mt.gov/ Helena, MT 59620-0135 INSTRUCTIONS TO OFFERORS Mark Face of Envelope/Package: Return Sealed Proposal to: RFP Number: RFP09-1694P State Procurement Bureau RFP Response Due Date: July 30, 2009, 2:00 General Services Division p.m. Department of Administration Room 165, Mitchell Building Special Instructions: 125 North Roberts Street Mandatory Pre-Proposal Conference June 23, P.O. Box 200135 2009 1:00 p.m., Local Time Helena, MT 59620-0135 IMPORTANT: SEE STANDARD TERMS AND CONDITIONS OFFERORS MUST COMPLETE THE FOLLOWING Offeror Name/Address: Authorized Offeror Signatory: (Please print name and sign in ink) Offeror Phone Number: Offeror FAX Number: Offeror E-mail Address: OFFERORS MUST RETURN THIS COVER SHEET WITH RFP RESPONSE Revised 2/09
  2. 2. TABLE OF CONTENTS SCHEDULE OF EVENTS........................................................................................................................4 SECTION 1. PROJECT OVERVIEW AND INSTRUCTIONS / ADMINISTRATIVE REQUIREMENTS............................................................................................................5 1.0 OVERVIEW...........................................................................................................................................5 1.1 CONTRACT TERM...............................................................................................................................6 1.2 SINGLE POINT OF CONTACT.............................................................................................................7 1.3 REQUIRED REVIEW............................................................................................................................7 1.4 PROCUREMENT LIBRARY..................................................................................................................8 1.5 PRE-PROPOSAL CONFERENCE........................................................................................................8 1.6 GENERAL REQUIREMENTS................................................................................................................8 1.7 SUBMITTING A PROPOSAL..............................................................................................................10 1.8 COST OF PREPARING A PROPOSAL...............................................................................................11 SECTION 2. RFP STANDARD INFORMATION...........................................................................12 2.0 AUTHORITY........................................................................................................................................12 2.1 OFFEROR COMPETITION.................................................................................................................12 2.2 RECEIPT OF PROPOSALS AND PUBLIC INSPECTION...................................................................12 2.3 CLASSIFICATION AND EVALUATION OF PROPOSALS..................................................................12 2.4 STATE’S RIGHTS RESERVED...........................................................................................................14 2.5 DEPARTMENT OF ADMINISTRATION POWERS AND DUTIES.......................................................15 2.6 COMPLIANCE WITH STATE OF MONTANA IT STANDARDS...........................................................15 SECTION 3. RFP INTRODUCTION AND BACKGROUND.....................................................16 3.0 GENERAL INFORMATION.................................................................................................................16 3.1 BACKGROUND INFORMATION.........................................................................................................18 3.2 RFP ORGANIZATION.........................................................................................................................24 SECTION 4. GENERAL REQUIREMENTS....................................................................................25 4.0 INTRODUCTION.................................................................................................................................25 4.1 CONTRACTOR RELATIONSHIP WITH DEPARTMENT AND OTHER CONTRACTORS..................25 4.2 PROJECT MANAGEMENT AND REPORTING...................................................................................25 4.3 CONTRACTOR COMMITMENT TO QUALITY MANAGEMENT.........................................................27 4.4 CONTRACTOR TRANSPARENCY, ACCOUNTABILITY, AND RESPONSIBILITY.............................28 4.5 COMMUNICATION REQUIREMENTS................................................................................................28 4.6 COMPLIANCE WITH FEDERAL REQUIREMENTS............................................................................29 4.7 SECURITY, CONFIDENTIALITY, AND AUDITING.............................................................................29 4.8 TECHNICAL REQUIREMENTS...........................................................................................................31 SECTION 5. PHASE-SPECIFIC REQUIREMENTS....................................................................41 5.0 OVERVIEW.........................................................................................................................................41 5.1 START UP PHASE..............................................................................................................................42 5.2 DETAILED REQUIREMENTS DEFINITION PHASE...........................................................................44 5.3 DESIGN PHASE..................................................................................................................................46 5.4 CONSTRUCTION PHASE...................................................................................................................48 5.5 CONVERSION....................................................................................................................................50 5.6 TESTING PHASE................................................................................................................................52 5.7 PILOT PHASE.....................................................................................................................................57 5.8 IMPLEMENTATION PHASE................................................................................................................60 RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 2
  3. 3. 5.9 OPERATIONS AND MAINTENANCE PHASE.....................................................................................62 5.10 TURNOVER PHASE...........................................................................................................................67 5.11 MAJOR MILESTONES SUMMARY.....................................................................................................68 5.12 REQUIRED DELIVERABLES SUMMARY...........................................................................................69 SECTION 6. ENTERPRISE ARCHITECTURE..............................................................................72 6.0 OVERVIEW.........................................................................................................................................72 6.1 SERVICE-ORIENTED ARCHITECTURE............................................................................................73 6.2 ENTERPRISE SERVICE BUS.............................................................................................................73 6.3 WEB PORTAL.....................................................................................................................................74 6.4 SINGLE SIGN-ON...............................................................................................................................76 6.5 SHARED INFORMATION AND WEB SERVICES...............................................................................77 6.6 INTERSYSTEM NAVIGATION............................................................................................................79 6.7 ENHANCING CHIMES-MEDICAID......................................................................................................81 RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 3
  4. 4. SCHEDULE OF EVENTS EVENT DATE RFP Issue Date May 29, 2009 Deadline for Receipt of First Round of Written Questions June 19, 2009 Pre-Proposal Conference June 23, 2009 Deadline for Receipt of Second Round of Written Questions June 26, 2009 Deadline for Posting Written Responses to the State's Website July 9, 2009 RFP Responses Due Date July 30, 2009 Notification of Offeror Interviews/Product Demonstrations/Oral September 4, 2009 Presentations Offeror Interviews September 8-11, 2009 Offeror Product Demonstrations/Oral Presentations September 8-11, 2009 Site Visits September 14-17, 2009 Intended Date for Contract Award October 2, 2009 Contract Finalized January 4, 2010 RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 4
  5. 5. SECTION 1.PROJECT OVERVIEW AND INSTRUCTIONS/ADMINISTRATIVE REQUIREMENTS 1.0.OVERVIEW The Department of Public Health and Human Services, hereinafter referred to as the Department or DPHHS, is soliciting competitive, responsive proposals from experienced and financially sound organizations to design, develop, support, and maintain for the State of Montana: • A new Supplemental Nutrition Assistance Program (SNAP) eligibility system. (Note – SNAP was called the Food Stamp Program until October 2008.) • A new Temporary Assistance for Needy Families (TANF) eligibility system. • Enterprise architecture for these two new systems and the existing Medicaid eligibility system. • A library of shared fiscal services to support the shared fiscal (accounts receivable and accounts payable) responsibilities associated with the issuance of eligibility and benefits for SNAP and TANF. This is a unique development project because the TANF and SNAP eligibility systems will be developed as stand-alone systems in a highly coordinated environment. DPHHS is migrating from a legacy system supporting integrated eligibility determination for SNAP, TANF, and Medicaid to separate web-based systems that share common services and communicate through enterprise architecture. The Department first replaced the Medicaid eligibility system with the Combined Healthcare Information and Montana Eligibility System (CHIMES). The new SNAP and TANF eligibility systems will leverage work completed in CHIMES-Medicaid because the three programs’ eligibility systems share a large number of functional commonalities. Leveraging development work completed in CHIMES will reduce the amount of time needed to develop the SNAP and TANF eligibility systems because much of the underlying structure is already in place. Using CHIMES as a base for the TANF and SNAP eligibility systems will also help assure a common look and feel for system users, particularly Office of Public Assistance (OPA) eligibility workers, who will determine eligibility for SNAP, Medicaid, and TANF. The enterprise architecture and its service-oriented architecture will coordinate the three systems seamlessly, meaning end users will use the separate eligibility systems as if they were one integrated system determining eligibility for three programs. The system name is an important component of its look and feel. In order to create consistency with the new Medicaid eligibility system, the SNAP eligibility system will be called the Combined Healthcare Information and Montana Eligibility System-SNAP (CHIMES-SNAP) and the TANF eligibility system will be called the Combined Healthcare Information and Montana Eligibility System-TANF (CHIMES-TANF). The original CHIMES system will now be called the Combined Healthcare Information and Montana Eligibility System-Medicaid (CHIMES-Medicaid). All three systems will jointly be called CHIMES. DPHHS envisions the contractor’s enterprise architecture solution for these three systems becoming the architecture standard used by the Department going into the future. New systems being developed and implemented in the future will use the enterprise architecture solution developed by the successful offeror to this RFP. Detailed functional requirements and contractor responsibilities for the systems, enterprise architecture, and the shared fiscal services layer (SFSL) are provided in Sections 6, 7, 8, 9, and 10 of this RFP. Offerors should carefully read and understand all RFP responsibilities, performance requirements, and terms and conditions before responding. 1.0.1. Procurement Objectives The objective of this procurement is to select a contractor or a contractor and its subcontractors to design, develop, and implement new SNAP and TANF eligibility systems, an enterprise architecture solution, and associated shared services, RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 5
  6. 6. including a SFSL for DPHHS. CHIMES-TANF and CHIMES-SNAP will leverage work completed in CHIMES-Medicaid. These three systems and all their components must coordinate with the development of other systems in the Department and the State. The Department anticipates that these systems will have an expected useful life of 20 years or more. In planning this procurement, DPHHS developed the following guiding principles to meet their objectives for the CHIMES- SNAP, CHIMES-TANF, enterprise architecture, and SFSL contract: • Maximize competition so the Department receives the best and most creative technical solutions for the enterprise architecture and the eligibility systems. • Develop a quality RFP that increases accountability and meets the needs of the State by: o Thoroughly documenting requirements to elicit the optimum pricing and minimize future misunderstandings. o Clearly defining and documenting contractor and Department roles, responsibilities, and scope of work to provide a clear, firm base for the development contracts to reduce risk to the Department. o Maintaining eligibility focus to determine scope and priorities. o Documenting reasonable performance measures and standards. o Clearly identifying Department expectations. o Allowing a thorough State review prior to release. • Develop an RFP to meet SNAP-specific and TANF-specific goals, including: o Creating flexible, reliable, easily updateable, accurate, and easily maintainable systems. o Ensuring single data entry capability for the three eligibility systems. o Developing user-friendly eligibility systems from the Department and client perspectives. o Incorporating efficient interfaces and interoperability to allow for future collaboration with other states and other Montana programs. o Allowing for comprehensive, flexible, usable, ad-hoc and scheduled reports for case management and program management. o Ensuring robust and controllable system access and security. o Coordinating common functions across TANF, SNAP, and Medicaid eligibility systems. o Incorporating sound fiscal processes. o Developing well-defined data fields and rules so the eligibility systems serve the right people with the right services at the right time. The purpose of guiding principles is to set priorities, establish boundaries, and allocate resources for the success of the CHIMES-TANF, CHIMES-SNAP, and enterprise architecture project. They will be used by the project to govern the decision- making phases and will be expanded as needed. 1.1.CONTRACT TERM The contract term is for a period of five years beginning December 2009 and ending September 2014. The Department anticipates the design, development, and implementation portion of the contract will last two years. A one-year warranty period and a three-year maintenance period, with the first year running concurrently with the warranty period, will begin at the completion of the design, development and implementation (DDI) work after the successful offeror meets the Department’s system acceptance criteria. Renewals of the maintenance contract, by mutual agreement of both parties, may be made at one-year intervals, or any interval that is advantageous to the State. This contract, including any renewals, may not exceed a total of ten years, at the option of the State. The Department expects the DDI of the shared fiscal services layer to be completed on a more aggressive schedule, to last one year, with a one-year warranty for that component, followed by State takeover of that shared fiscal services function. The Department believes that this shared fiscal services functionality will be developed and designed as a standalone process, whereby the shared services may be utilized by the Department prior to the completion of the CHIMES-SNAP and CHIMES- RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 6
  7. 7. TANF systems. The following table provides a detailed breakdown of the anticipated components for the stated contract term: CONTRACT DATES MAJOR CONTRACT ACTIVITY Design and development of CHIMES-SNAP and January 2010 – September 2011 CHIMES-TANF and enterprise architecture January 2010 – September 2010 Design and development of SFSL October 2010 – September 2011 One-year warranty for SFSL One-year warranty for CHIMES-SNAP and October 2011 – September 2012 CHIMES-TANF systems Three-year maintenance period for CHIMES- October 2011 – September 2014 SNAP and CHIMES-TANF systems (with enterprise architecture) Potential one-year contract extensions for October 2014 – September 2019 CHIMES-SNAP and CHIMES-TANF maintenance and operations 1.2.SINGLE POINT OF CONTACT From the date this Request for Proposal (RFP) is issued until an offeror is selected and the selection is announced by the procurement officer, offerors are not allowed to communicate with any State staff or officials regarding this procurement, except at the direction of Penny Moon, the procurement officer in charge of the solicitation. Any unauthorized contact may disqualify the offeror from further consideration. Contact information for the single point of contact is as follows: Procurement Officer: Penny Moon Address: State Procurement Bureau Room 165, Mitchell Building 125 North Roberts PO Box 200135 Helena, MT 59620-0135 Telephone Number: (406) 444-3313 Fax Number: (406) 444-2529 Email Address: pmoon@mt.gov 1.3.REQUIRED REVIEW 1.3.1. Review RFP Offerors should carefully review the instructions, mandatory requirements, specifications, standard terms and conditions, and contract set out in this RFP and promptly notify the procurement officer identified above in writing or via email of any ambiguity, inconsistency, unduly restrictive specifications, or error which they discover upon examination of this RFP. This should include any terms or requirements within the RFP that either preclude the offeror from responding to the RFP or add unnecessary cost. This notification must be accompanied by an explanation and suggested modification and be received by the deadline for receipt of written or emailed inquiries set forth below. The State will make any final determination of changes to the RFP. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 7
  8. 8. 1.3.2. Form of Questions Offerors with questions or requiring clarification or interpretation of any section within this RFP must address these questions in writing or via email to the procurement officer referenced above on or before June 26, 2009. Each question must provide clear reference to the section, page, and item in question. Questions received after the deadline may not be considered. 1.3.3. State’s Response The State will provide an official written response by July 9, 2009 to all questions received by June 26, 2009. The State's response will be by formal written addendum. Any other form of interpretation, correction, or change to this RFP will not be binding upon the State. Any formal written addendum will be posted on the State's website alongside the posting of the RFP at http://gsd.mt.gov/osbs by the close of business on the date listed. Offerors must sign and return with their RFP response an Acknowledgment of Addendum for any addendum issued. 1.4.PROCUREMENT LIBRARY A procurement library has been established for this procurement. The procurement library contains a number of documents and reference materials that may be useful in preparing a proposal in response to this RFP. A detailed list of its contents is included in Appendix 13.0. All possible effort has been made to ensure that library material is complete and current. However, the Department does not warrant that the information is, indeed, complete or current at the time of viewing. The procurement library, containing all CHIMES-Medicaid-related material, is available on the State of Montana, Department of Health and Human Services website at: http://www.dphhs.mt.gov/legalresources/rfp/procurementlibrary/. 1.5.PRE-PROPOSAL CONFERENCE The Department invites interested parties to submit general questions prior to the mandatory pre-proposal conference. These questions will help the Department in preparing for the conference to focus on the items/questions that most need to be addressed. Written questions should be emailed to Penny Moon at pmoon@mt.gov by close of business on June 19, 2009. These questions will be added to those received after the pre-proposal conference and written answers will be provided by the date stated in subsection 1.3.3. A mandatory pre-proposal conference will be conducted at the Department of Environmental Quality Building, 1100 N Last Chance Gulch, Helena, Room 112 on June 23, 2009 at 1:00 p.m. Offerors are encouraged to use this opportunity to ask clarifying questions, obtain a better understanding of the project, or to notify the State of any ambiguities, inconsistencies, or errors discovered upon examination of this RFP. All responses to questions at the pre-proposal conference will be oral and in no way binding on the State. 1.6.GENERAL REQUIREMENTS 1.6.1. Acceptance of Terms and Conditions/Contract By submitting a response to this RFP, offeror agrees to acceptance of the contract with all terms and conditions as set out in Attachment A of this RFP. The selected offeror will be expected to enter into an Agreement that is substantially the same as the contract in Attachment A. In no event is an offeror to submit its own standard contract terms and conditions as a response to this RFP. The offeror must submit any requests for additions or exceptions to the contract terms, including any necessary licenses or other added provisions, exceptions and exact contract deviations that its firm wishes to negotiate to the procurement officer referenced above by the date for receipt of written/emailed questions, which is June 26, 2009; however, many clauses are required by Montana state law and cannot be negotiated. Any request must be accompanied by an explanation of why the exception is being sought and what specific effect it will have on the offeror's ability to respond to the RFP or perform the contract. Requests must be made in the format of the table included in Appendix 13.10 of this RFP. Any material exceptions requested and granted to the standard terms and conditions and contract language will be addressed RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 8
  9. 9. in any formal written addendum issued for this RFP and will apply to all offerors submitting a response to this RFP. The State reserves the right to address nonmaterial requests for exceptions with the highest scoring offeror during contract negotiation. The State will make any final determination of changes to the contract and its terms and conditions. 1.6.2. Resulting Contract This RFP and any addenda, the offeror's RFP response, including any amendments, a best and final offer, and any clarification question responses shall be included in any resulting contract. The State's contract, attached as Attachment A, contains the contract terms and conditions which will form the basis of any contract between the State and the highest scoring offeror. In the event of a dispute as to the duties and responsibilities of the parties under this contract, the contract, along with any attachments prepared by the State, will govern in the same order of precedence as listed in the contract. 1.6.3. Mandatory Requirements To be eligible for consideration, an offeror must meet the intent of all mandatory requirements as summarized in Appendix 13.2. The State will determine whether an offeror's RFP response complies with the intent of the requirements. RFP responses that do not meet the full intent of all requirements listed in this RFP may be deemed nonresponsive. 1.6.4. Understanding Specifications and Requirements By submitting a response to this RFP, offeror agrees to an understanding of and compliance with the specifications and requirements described in this RFP. 1.6.5. Prime Contractor/Subcontractors The highest scoring offeror will be the prime contractor if a contract is awarded and shall be responsible, in total, for all work of any subcontractors. Use of subcontractors, if any, must be clearly explained in the proposal and any subcontractor must be identified by name in the proposal. The State reserves the right to approve all subcontractors. The contractor shall be responsible to the State for the acts and omissions of all subcontractors or agents and of persons directly or indirectly employed by such subcontractors, and for the acts and omissions of persons employed directly by the Contractor. Further, nothing contained within this document or any contract documents created as a result of any contract awards derived from this RFP shall create any contractual relationships between any subcontractor and the State. At a minimum, the subcontractor information shall include name, address, the general scope of work to be performed by each subcontractor, its willingness to perform such work, and certification that it does not discriminate in its employment practices. The prime contractor shall report to the State annually information on its use of subcontractors, certifying that the subcontractor meets the employment practices mandated by Federal and State statutes and regulations. The subcontractor shall be held to the same standards as the prime contractor, as stated in this RFP. The State reserves the right to approve or disapprove the subcontractor and staff assigned to this contract. 1.6.6. Offeror’s Signature The proposals must be signed in ink by an individual authorized to legally bind the business submitting the proposal. The offeror's signature on a proposal in response to this RFP guarantees that the offer has been established without collusion and without effort to preclude the State of Montana from obtaining the best possible supply or service. Proof of authority of the person signing the RFP response must be furnished upon request. 1.6.7. Offer in Effect for 180 Days A proposal may not be modified, withdrawn, or canceled by the offeror for a 180-day period following the deadline for proposal submission as defined in the schedule of events, or receipt of best and final offer, if required, and offeror so agrees in submitting the proposal. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 9
  10. 10. 1.7.SUBMITTING A PROPOSAL 1.7.1. Organization of a Proposal Offerors must organize their proposal into sections that follow the format of the Proposal Submission Requirements detailed in Section 11 of this RFP, with tabs separating each section, as indicated in the proposal submission instructions. Response pages must be consecutively numbered. Using the Mandatory Requirements Checklist in Appendix 13.2, offerors must acknowledge all RFP sections. An offeror making the statement “Refer to our literature…” or “Please see www…….com” may be deemed nonresponsive or receive point deductions. If making reference to materials located in another section of the RFP response, specific page numbers and sections must be noted. The Evaluator/Evaluation Committee is not required to search through literature or another section of the proposal to find a response. 1.7.2. Failure to Comply with Instructions Offerors failing to comply with these instructions may be subject to point deductions. The State may also choose to not evaluate, may deem nonresponsive, and/or may disqualify from further consideration any proposals that do not follow this RFP format, are difficult to understand, are difficult to read, or are missing any requested information. 1.7.3. Multiple Proposals Offerors may, at their option, submit multiple proposals, in which case each proposal shall be evaluated as a separate document. 1.7.4. Separate Technical and Cost Proposals Offerors must submit proposals in two parts – 1) a technical proposal and 2) a cost proposal. The format and content of each are specified in Section 11 of the RFP. Cost information must not be included in the technical proposal. 1.7.5. Copies Required and Deadline for Receipt of Proposals Offerors must submit one original technical proposal, four copies, and seven electronic copies to the State Procurement Bureau. Electronic copies should be submitted as Microsoft Word 2003, Microsoft XP, or Adobe Portable Document Format (PDF) documents. Electronic copies should be on separate CDs, so each evaluation team member can have his or her own. CDs must be complete; any product samples or other information not able to be included on the CD must be provided in one original and 11 paper copies. All CDs should be tested to ensure they are readable. If any confidential materials are included, per the requirements of subsection 2.2.2, they must be submitted on a separate CD or memory stick. Offerors must submit one original cost proposal and two paper copies to the State Procurement Bureau under separate, sealed cover. The State Procurement Bureau will hold all cost proposals for opening until after the evaluation committee has completed its evaluation of the technical proposals. The time of opening will be at the State Procurement Bureau's option. At such time as the cost proposals are opened and reviewed by the procurement officer, they will be provided to the evaluation committee and become available for public inspection. PROPOSALS MUST BE SEALED AND LABELED ON THE OUTSIDE OF THE PACKAGE to clearly indicate that they are in response to RFP09-1694P. Proposals must be clearly marked as either technical or cost proposals. Proposals must be received at the receptionist's desk of the State Procurement Bureau prior to 2:00 p.m., local time, July 30, 2009. 1.7.6. Late Proposals Regardless of cause, late proposals will not be accepted and will automatically be disqualified from further consideration. It shall be the offeror's sole risk to assure delivery at the receptionist's desk at the designated office by the designated time. Late proposals will not be opened and may be returned to the offeror at the expense of the offeror or destroyed if requested. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 10
  11. 11. 1.8.COST OF PREPARING A PROPOSAL 1.8.1. State Not Responsible for Preparation Costs The costs for developing and delivering responses to this RFP and any subsequent presentations of the proposal as requested by the State are entirely the responsibility of the offeror. The State is not liable for any expense incurred by the offeror in the preparation and presentation of their proposal or any other costs incurred by the offeror prior to execution of a contract. 1.8.2. All Timely Submitted Materials Become State Property All materials submitted in response to this RFP become the property of the State and are to be appended to any formal documentation, which would further define or expand any contractual relationship between the State and offeror resulting from this RFP process. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 11
  12. 12. SECTION 2.RFP STANDARD INFORMATION 2.0.AUTHORITY This RFP is issued under the authority of section 18-4-304, MCA (Montana Code Annotated) and ARM 2.5.602 (Administrative Rules of Montana). The RFP process is a procurement option allowing the award to be based on stated evaluation criteria. The RFP states the relative importance of all evaluation criteria. Only the evaluation criteria outlined in this RFP will be used. 2.1.OFFEROR COMPETITION The State encourages free and open competition among offerors. Whenever possible, the State will design specifications, proposal requests, and conditions to accomplish this objective, consistent with the necessity to satisfy the State's need to procure technically sound, cost-effective services and supplies. 2.2.RECEIPT OF PROPOSALS AND PUBLIC INSPECTION 2.2.1. Public Information All information received in response to this RFP, including copyrighted material, is deemed public information and will be made available for public viewing and copying shortly after the time for receipt of proposals has passed with the following three exceptions: (1) bona fide trade secrets meeting the requirements of the Uniform Trade Secrets Act, Title 30, chapter 14, part 4, MCA, that have been properly marked, separated, and documented; (2) matters involving individual safety as determined by the State; and (3) other constitutional protections. See section 18-4-304, MCA. The State will make a copier available for interested parties to use at $0.10 per page. The interested party is responsible for the cost of copies and to provide personnel to do the copying. 2.2.2. Procurement Officer Review of Proposals Upon opening the proposals received in response to this RFP, the procurement officer in charge of the solicitation will review the proposals and separate out any information that meets the referenced exceptions in subsection 2.2.1 above, providing the following conditions have been met: • Confidential information is clearly marked and separated from the rest of the proposal. • The proposal does not contain confidential material in the cost or price section. • An affidavit from an offeror's legal counsel attesting to and explaining the validity of the trade secret claim as set out in Title 30, chapter 14, part 4, MCA, is attached to each proposal containing trade secrets. Counsel must use the State of Montana “Affidavit for Trade Secret Confidentiality” form in requesting the trade secret claim. This affidavit form is available on the General Services Division's website at: http://gsd.mt.gov/procurement/forms.asp or by calling (406) 444-2575. Information separated out under this process will be available for review only by the procurement officer, the evaluator/evaluation committee members, and limited other designees. Offerors must be prepared to pay all legal costs and fees associated with defending a claim for confidentiality in the event of a “right to know” (open records) request from another party. 2.3.CLASSIFICATION AND EVALUATION OF PROPOSALS 2.3.1. Initial Classification of Proposals as Responsive or Nonresponsive All proposals will initially be classified as either “responsive” or “nonresponsive,” in accordance with ARM 2.5.602. Proposals may be found nonresponsive at any time during the procurement process if any of the RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 12
  13. 13. required information is not provided or the proposal is not within the plans and specifications described and required in the RFP. If a proposal is found to be nonresponsive, it will not be considered further, and the price proposal will not be opened. 2.3.2. Determination of Responsibility The procurement officer will determine whether an offeror has met the standards of responsibility in accordance with ARM 2.5.407. Such a determination may be made at any time during the procurement process if information surfaces that would result in a determination of nonresponsibility. If an offeror is found nonresponsible, the determination must be in writing, made a part of the procurement file, and mailed to the affected offeror. 2.3.3. Evaluation of Proposals An evaluation committee will evaluate the remaining proposals. The State Procurement Bureau will hold all cost proposals for opening until after the evaluation committee has completed its evaluation of the technical proposals. The time of opening will be at the State Procurement Bureau's option. At such time as the cost proposals are opened and reviewed by the procurement officer, they will be provided to the evaluation committee and become available for public inspection. The committee will recommend whether to award the contract to the highest scoring offeror or, if necessary, to seek discussion/negotiation or a best and final offer in order to determine the highest scoring offeror. All responsive proposals will be evaluated based on stated evaluation criteria. In scoring against stated criteria, the State may consider such factors as accepted industry standards and a comparative evaluation of all other qualified RFP responses in terms of quality and contractual factors. Differing costs will be considered in cost proposal scoring. The combined technical and cost proposal scores will be used to determine the most advantageous offering to the State. If an evaluation committee meets to deliberate and evaluate the proposals, the public may attend and observe the evaluation committee deliberations. Section 12 of this RFP explains the evaluation approach and criteria for the technical and cost proposals in more detail. 2.3.4. Completeness of Proposals Selection and award will be based on the offeror's proposal and other items outlined in this RFP. Submitted responses may not include references to information located elsewhere, such as Internet websites or libraries, unless specifically requested. Information or materials presented by offerors outside the formal response or subsequent discussion/negotiation or best and final offer, if requested, will not be considered, will have no bearing on any award, and may result in the offeror being disqualified from further consideration. 2.3.5. Opportunity for Discussion/Negotiation and/or Oral Presentation/Product Demonstration After receipt of all proposals and prior to the determination of the award, the State may initiate discussions with one or more offerors should clarification or negotiation be necessary. Offerors may also be required to make an oral presentation and/or product demonstration to clarify their RFP response or to further define their offer. In either case, offerors should be prepared to send qualified personnel to Helena, Montana, to discuss technical and contractual aspects of the proposal. Oral presentations and product demonstrations, if requested, shall be at the offeror's expense. 2.3.6. Best and Final Offer The Best and Final Offer (BAFO) is an option available to the State under the RFP process, which permits the State to request a best and final offer from one or more offerors if additional information is required to make a final decision. Offerors may be contacted asking that they submit their best and final offer, which must include any and all discussed and/or negotiated changes. The State reserves the right to request a best and final offer for this RFP, if any, based on price/cost alone. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 13
  14. 14. 2.3.7. Evaluator/Evaluation Committee Recommendation for Contract Award The evaluator/evaluation committee will provide a written recommendation for contract award to the procurement officer that contains the scores, justification, and rationale for the decision. The procurement officer will review the recommendation to ensure its compliance with the RFP process and criteria before concurring in the evaluator's/evaluation committee’s recommendation of the responsive and responsible offeror that achieves the highest score and is, therefore, the most advantageous to the State. The State reserves the right to reject any or all proposals or to award this contract in a manner deemed to be in the best interest of the State. 2.3.8. Request for Documents Notice Upon concurrence with the evaluator's/evaluation committee's recommendation, the procurement officer will issue a “Request for Documents Notice” to the highest scoring offeror to obtain the required documents/information, such as insurance documents, contract performance security, an electronic copy of any requested material, i.e., RFP response, response to clarification questions, and/or best and final offer, and any other necessary documents. Receipt of the “Request for Documents Notice” does not constitute a contract and no work may begin until a contract signed by all parties is in place. The procurement officer will notify all other offerors of the State's selection. 2.3.9. Contract Execution Upon receipt of all required materials requested in the “Request for Documents Notice," a formal contract utilizing the contract with terms and conditions attached as Attachment A, as well as the highest scoring offeror's response to the RFP, will be provided to the highest scoring offeror for signature. The highest scoring offeror will be expected to accept and agree to all material requirements contained in the contract and set out in Attachment A of this RFP. If the highest scoring offeror does not accept all material requirements, the State may move to the next highest scoring offeror, or cancel the RFP. Work under the contract may begin when the contract is fully executed, i.e., when the contract is signed by all parties. 2.3.10 Protest Procedure Bidders and offerors may protest a solicitation or award of a contract per section 18-4-242, MCA, and ARM 2.5.406. The protest must be in writing and state in detail all of the protestor's objections. The complete protest must be submitted to the Department no later than the close of business 14 calendar days after the execution of the contract in question. If the 14th day falls on a Saturday, Sunday, or legal holiday, the protest is due at the end of the next business day. The State is under no obligation to delay, halt, or modify the procurement process pending the result of a protest, contested case proceeding, or judicial review. 2.4.STATE’S RIGHTS RESERVED While the State has every intention to award a contract as a result of this RFP, issuance of the RFP in no way constitutes a commitment by the State of Montana to award and execute a contract. Upon a determination such actions would be in its best interest, the State, in its sole discretion, reserves the right to do any of the following: • Cancel or terminate this RFP (section 18-4-307, MCA). • Reject any or all proposals received in response to this RFP (ARM 2.5.602). • Waive any undesirable, inconsequential, or inconsistent provisions of this RFP, which would not have significant impact on any proposal (ARM 2.5.505). • Not award if it is in the best interest of the State not to proceed with contract execution (ARM 2.5.602). • If awarded, terminate any contract if the State determines adequate State funds are not available (section 18-4-313, MCA). RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 14
  15. 15. 2.5.DEPARTMENT OF ADMINISTRATION POWERS AND DUTIES The Department of Administration is responsible for carrying out the planning and program responsibilities for information technology (IT) for State government. (Section 2-17-512, MCA) The Chief Information Officer is the person appointed to carry out the duties and responsibilities of the Department of Administration relating to information technology. The Department of Administration shall: • Review the use of information technology resources for all State agencies. • Review and approve State agency specifications and procurement methods for the acquisition of information technology resources. • Review, approve, and sign all State agency IT contracts and shall review and approve other formal agreements for information technology resources provided by the private sector and other government entities. 2.6.COMPLIANCE WITH STATE OF MONTANA IT STANDARDS The offeror is expected to be familiar with the State of Montana IT environment. All services and products provided as a result of this RFP must comply with all applicable State of Montana IT policies and standards in effect at the time the RFP is issued. The offeror must request exceptions to State IT policies and standards in accordance with subsection 1.5 of this RFP. It will be the responsibility of the State to deny the exception request or to seek a policy or standards exception through the Department of Administration, Information Technology Services Division (ITSD). Offerors are expected to provide proposals that conform to State IT policies and standards. It is the intent of ITSD to utilize the existing policies and standards and not to routinely grant exceptions. The State reserves the right to address nonmaterial requests for exceptions with the highest scoring offeror during contract negotiation. The links below will provide information on State of Montana IT strategic plans, current environment, policies, and standards. State of Montana Information Technology Strategic Plan http://itsd.mt.gov/stratplan/statewideplan.asp State of Montana Information Technology Environment http://itsd.mt.gov/techmt/compenviron.asp State of Montana IT Policies http://itsd.mt.gov/policy/itpolicy.asp State of Montana Software Standards http://itsd.mt.gov/policy/software.asp RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 15
  16. 16. SECTION 3.RFP INTRODUCTION AND BACKGROUND 3.0.GENERAL INFORMATION DPHHS seeks to replace its current mainframe TANF and SNAP (previously called the Food Stamp Program) eligibility system with web-based systems, and to procure an enterprise architecture solution to serve as the common infrastructure connecting the separate systems. Included in this scope is the development of a shared fiscal services layer (SFSL) to provide functionality that supports the common fiscal functions shared by the CHIMES-SNAP and CHIMES-TANF systems, by providing a library of shared fiscal services where the fiscal interfaces and processing required by both the CHIMES-SNAP and CHIMES-TANF systems can be performed. The current legacy system, TEAMS, is built in a monolithic architecture that is difficult and costly to maintain, and that will not easily facilitate the implementation of enterprise architecture. In addition, it will become increasingly difficult to find programmers experienced in the legacy technology and languages needed to support TEAMS. The current system typifies state legacy systems in its inflexibility and use of codes, commands, and functions that could take years for an eligibility worker to master. Montana’s economy and employment patterns, like the rest of the country’s, are changing. In today’s world, very few people will retain jobs as OPA eligibility workers for the majority of their careers. The flexible and transient nature of the new state employee requires a new type of system. New systems or applications will have to replace institutional, people-based knowledge with better, more flexible technology that is easy to learn and use. 3.0.1. Strategic Goals and Objectives SNAP and TANF strategic goals and objectives were developed in conjunction with procurement project guiding principles. The goals and objectives, like the guiding principles, will be the benchmark from which procurement and system success will be measured. Specific requirements based on these goals and objectives are articulated in RFP Sections 6 through 10. The main purpose of the new system is to determine eligibility. In addition to this, the SNAP eligibility system must meet specific program needs, including requirements of the Federal quality assurance standards and the SNAP Employment and Training program, and the TANF eligibility system must meet TANF-specific program needs including Federal reporting and case management requirements. The following goals and objectives address how the new eligibility system should operate to best support Montana’s TANF and SNAP programs. All goals and objectives are applicable to both programs unless otherwise noted. 1. The new eligibility systems must be flexible, modular, reliable, easy to update, and easy to maintain. a. The State must be able to easily make changes within the systems, including changes to reports, tables, and rules. The State must be able to maintain eligibility rules, if they choose to do so. This flexibility and updateability is required for the systems to be responsive to changing program business needs. b. The systems must be easily maintained over the long-term. End users must be able to perform this long-term maintenance. c. The systems must be scaleable and modular. 2. The systems must be user-friendly from the State and client perspectives. More specifically, they must be quick, responsive, easy to learn, easy to search, and incorporate features including training modules, single entry, online help, online applications, links to policy manuals, and client-friendly correspondence. a. The new systems must be easy to learn for new and existing State employees. The onscreen text must be written in plain English, so a user can look at a screen and know why he or she is on that screen, and know what to do to successfully use the screen. State employees must not have to remember illogical codes or workarounds to use the eligibility systems. The systems must be intuitive. b. The systems must incorporate a search functionality to make it more useable. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 16
  17. 17. c. The systems must incorporate system training modules and/or a system help function. d. The systems must incorporate policy training modules and/or links to the SNAP and TANF policy manuals. This will allow eligibility workers to answer questions quicker and more accurately, improving the workers’ and the applicants’ or clients’ experiences. e. The systems must incorporate sound fiscal processes. f. The systems must one day have the ability to produce documents in other languages. g. The systems must have a common intake function so demographic, income, resource, and other shared information only needs to be entered once. h. The systems must be as paperless as possible. i. The systems must be accessible to all, including people with disabilities. j. The systems should be able to accept online applications and contain an online screening tool. k. The systems must include spell check for case notes and notices. l. The systems must have flexible and easy to use correspondence, to which changes can easily be made. System-generated correspondence must have basic word processing functionality including word wrap, the ability to have different line spacing, a variety of fonts, and bold and italics. m. At a minimum, online availability is required between 6:00 a.m. and 7:00 p.m. seven days a week. The system must be available for longer hours in special circumstances, including the migrant season. The systems must have a consistent look and feel. 3. The systems must be able to easily exchange data with other systems. The new systems must have efficient interfaces and a high level of interoperability, allowing for future collaboration with other states or Montana programs. a. The systems must coordinate with and be compatible with other information systems. Data must be easily exchanged between systems. b. Interfaces must be intelligent and real-time. The systems need to be able to interface with other Montana State systems, Federal systems, non-profit partners, and other non-State program partners. The TANF and SNAP systems must also be able to share allowable information with appropriate tribal entities. c. The systems must effectively and efficiently interface with all federally required systems. d. System users must be able to smoothly transition to other programs from the systems, including Word and Excel. 4. The systems must have the ability to create reliable, comprehensive, flexible, usable, ad-hoc and scheduled reports for case management and program management. a. The reporting capabilities must demonstrate accountability to and compliance with State and Federal standards. b. The systems must automatically produce managerial reports, including case load reports, and the system must give staff the ability to query data to generate any other reports needed (ad-hoc reports). c. The systems must have the ability to create accurate Federal reports. d. The TANF system must calculate participation rates using the Federal formula. This formula must be easy to update. e. The TANF system must have the ability to implement and accurately measure legislative performance measures. f. The systems must be able to produce consistent reporting statistics (longitudinally valid). g. The systems must retain accurate records. h. The systems must be built to seamlessly coordinate with the shared fiscal services layer. i. Reports must be clear, flexible, accurate, and timely. 5. The systems must have robust security and controllable system access. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 17
  18. 18. a. Data within the systems must be secure and accessible only to those with proper access. b. The systems must have varying levels of access. Protected health information needs to be accessible only to people with a certain security level. c. The systems must have theft and fraud prevention built in to them. d. The systems must contain a history of each user ID and the dated actions taken by specific users. 6. System development processes must be efficiently and effectively coordinated with other systems. TANF, SNAP, and Medicaid eligibility system users must use only one process and one set of screens to perform their work. a. The systems must be successfully completed under budget and on time. b. There must be a positive working partnership between the system users and the developers. c. The systems must capitalize on the investment and development work completed on CHIMES- Medicaid. d. The development of the systems must be coordinated with the development of other new systems including Child and Adult Protective Services System (CAPS), System for the Enforcement and Recovery of Child Support (SEARCHS), and CHIMES-Medicaid. e. The systems must have consolidated financial processes, including overpayment management. f. The SNAP and TANF systems must be developed to work with the Electronic Benefits Transaction (EBT) system and the shared fiscal services layer. g. The systems intake process must be coordinated with other eligibility systems (Medicaid, TANF, and SNAP). 7. The systems must have well-defined data fields and rules. The systems must serve the right people with the right services at the right time. a. The systems must accurately determine eligibility. b. Data must be accurate and reliable in the new systems. c. The systems must contain strong controls to limit and correct errors. Certain errors must be able to be corrected without programmer involvement. d. The systems must minimize agency-caused errors. e. The systems must have flexible eligibility categories for emergencies, such as Hurricane Katrina. 8. The systems must support efficient case management and assessment. a. The systems must contain an effective case management and assessment module. b. The systems must retain a history of case action, which must be easily searchable. c. The systems must help OPA eligibility workers manage their time efficiently. d. The SNAP system must include the Employment and Training (E&T) Program. 3.1.BACKGROUND INFORMATION 3.1.1. Procurement Overview Montana needs both a new SNAP eligibility system and a new TANF eligibility system to meet the changing program and administrative needs of today and the future. Montana’s current integrated eligibility system is a typical legacy system; it is inflexible, less accurate than it should be, expensive and difficult to update or change, and does not allow for adequate reporting or case management. The Department intends to procure the two new systems that will support the overall Department goal of providing accurate and timely assistance to eligible Montanans. In order to do that, the systems will need to be more accurate and complete. The new eligibility systems must be easier to change, and changes should be made quickly and at a lower cost. They must have flexible and accurate reporting functionality, to allow for efficient and accurate Federal and State reporting. The systems should improve program management in the RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 18
  19. 19. areas of quality control, program security, and EBT system benefit issuance. The new eligibility systems must use a variety of mechanisms to interface with Federal, State, and other stakeholder systems. The Department also intends to procure an enterprise architecture solution to allow these two systems, the Medicaid eligibility system, and other systems to efficiently communicate and share data, including a Shared Fiscal Services Layer. The Department anticipates that the design, development, and implementation of CHIMES-TANF, CHIMES- SNAP, the Enterprise Architecture (EA), and the SFSL will be completed within an approximate budgeted cost of $20,000,000. The contract period coincides with the State’s biennium, and appropriate funding has been requested in the Montana Department budget request for the five-year base contract period. It is the Department’s intent to extend the contract term annually dependent upon the biennium budget authorizations, with the option of five additional one-year extensions up through July 2019. Appropriate funding will be requested through the State’s budgetary process for securing the funding for years 2015 through 2019 of this contract. This contract and any contract extensions are contingent upon approval by the Department, the State Procurement Bureau, and the Governor or his designee, and upon available and approved funding. No Federal funds may be used for lobbying, and the selected vendor must comply with the Clean Air Act and Clean Water Act. Offerors must certify their compliance in the transmittal letter. 3.1.2. Procurement History The Economic Assistance Management System (TEAMS) currently determines eligibility and benefit issuance for Medicaid, TANF, and SNAP. TEAMS was originally developed in 1990 and has become consistently less responsive to the needs of these programs. TEAMS was federally certified early in 1992 after reviews of the system by both the US Department of Health and Human Services (HHS), Health Care Financial Administration (HCFA), and the US Department of Agriculture (USDA), Food and Nutrition Services (FNS) Administration. TEAMS is implemented on an IBM z9 mainframe running under zOS. The system is built on Computer Associates' Integrated Database Management System (IDMS). It contains online dialogues written in ADS/O and batch modules written in MVS COBOL. The system contains approximately 1,275 online programs and batch programs. It consists of 355 screens, 900 reports and stores 15.5 gigabytes of data. Approximately 150,000 active clients are processed by the system each month. The system supports approximately 500 eligibility specialists and support staff located across the State of Montana in Offices of Public Assistance (OPAs), as well as Work Readiness Component (WoRC) Operators. 3.1.3. Department of Public Health and Human Services The State of Montana, DPHHS is responsible for the delivery of a wide range of public assistance services funded through a combination of State and Federal dollars. DPHHS is comprised of 12 divisions: 1) Director’s Office; 2) Children and Family Services; 3) Child Support Enforcement; 4) Technology Services; 5) Public Health and Safety; 6) Quality Assurance; 7) Human and Community Services; 8) Addictive and Mental Disorders; 9) Health Resources; 10) Disability Services; 11) Business and Financial Services; and 12) Senior and Long Term Care. The Technology Services Division, the Public Assistance Bureau within the Human and Community Services Division, and the Business and Financial Services Division are the three DPHHS divisions managing this procurement process, and the system design, development and implementation. The contractor must obtain deliverable acceptance from applicable divisions. Some will require acceptance from all three divisions, others will only need acceptance from two. 3.1.3.1.Technology Services Division The Technology Services Division (TSD) provides operational and technological support to DPHHS to ensure efficient and effective implementation of Department programs. Support services include: RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 19
  20. 20. • Reengineering processes critical to the Department mission. • Developing and operating internal and external computer systems. • Designing and managing networks. • Programming. • Supporting databases and application servers. • Providing help desk support. • Conducting technical planning of electronic government applications. • Supporting telecommunications. TSD supports a Project Management Bureau (TSD-PMB), which is the project management office for all DPHHS technology-related projects. Other divisions within DPHHS are their customers and partners on technology projects. TSD-PMB adheres to the standards described by the Project Management Institute (PMI) in the Project Management Body of Knowledge (PMBOK). The Department requires the contractor to adhere to the same standards, as outlined in Section 4.2. 3.1.3.2.Human Community Services Division, Public Assistance Bureau The Human and Community Services Division (HCSD) helps families and individuals meet basic needs and work their way toward self-sufficiency. HCSD does this by administering a variety of Federal and State programs that offer cash assistance, employment training, SNAP benefits, Medicaid, child care, meal reimbursement, nutrition training, energy assistance, weatherization, and other services to help families move out of poverty. The Human and Community Services Division is comprised of four bureaus: 1) Public Assistance; 2) Early Childhood Services; 3) Intergovernmental Human Services; and 4) Fiscal Services. The CHIMES systems fall within the purview of the Public Assistance Bureau (PAB). PAB administers Montana’s SNAP and TANF programs, and determines Medicaid eligibility. Services are provided by approximately 400 full-time equivalent employees (FTEs) assigned to the Offices of Public Assistance throughout the state. 3.1.3.3.Business and Financial Services Division The Business and Financial Services Division (BFSD) provides a variety of professional fiscal services to DPHHS, including: • Financial and accounting operation and oversight. • Cash management. • Preparation and filing of Federal financial reports. • Supply and equipment purchasing. • Payroll processing. • Audit coordination. • Lease management. • Vital records and statistics management. • Property management. • Records management. • Accounts payable. • Institutional reimbursement. BFSD also provides leadership and guidance in the development and implementation of accounting policies and procedures and best business practices. RFP09-1694P, SNAP and TANF Eligibility Systems, Enterprise Architecture, and Fiscal Services, Page 20
  21. 21. 3.1.3.4.Organization Chart
  22. 22. 3.1.4. Information Technology Services Division The State’s Information Technology Services Division (ITSD) is also an important player in the CHIMES and enterprise architecture project. The ITSD, under the authority of the State CIO, provides State agencies and customers information technology services in a fair, timely and responsive manner. The services provided ensure that the State’s information technology infrastructure is reliable, secure, and cost effective, and that it meets the business requirements of State agencies and citizens. For this project, ITSD will provide hosting services for the three CHIMES systems and the enterprise architecture. ITSD will also oversee the project from initial planning through contract completion to ensure the systems and architecture comply with the information technology (IT) standards it has developed for all State systems. ITSD will ensure that this IT investment aligns with DPHHS’ strategic plans and that the Department realizes maximum benefit from this IT investment. Additionally, ITSD will assist with developing continuity of government, continuity of operations, and disaster recovery plans. 3.1.4.1.Organization Chart
  23. 23. 3.1.5. SNAP Program Overview The Supplemental Nutrition Assistance Program (SNAP), formerly known as the Food Stamp Program, provides nutrition benefits to low-income participating clients, supports work, and delivers economic benefits to communities. In Montana, the SNAP eligibility system will determine eligibility, determine benefits levels, and capture participant information for the 35,800 Montana SNAP households. Households eligible to receive SNAP benefits include people that are: • Working for low wages or working part-time. • Unemployed. • Receiving TANF or other public assistance payments. • Elderly or disabled and are low-income. • Homeless. The program is Federally funded, and most program rules are mandated in Federal regulation. However, states administer the program and have some flexibility in eligibility rules and service delivery models. All state agencies are required to sufficiently automate their SNAP operations and computerize their systems for obtaining, maintaining, utilizing and transmitting information concerning SNAP. Also, all state agencies are required to issue the monthly benefit allotment electronically through EBT systems – eliminating paper “stamps” or coupons. The FNS is the Federal agency responsible for administering SNAP. Since the late 1990s, FNS has led two major Federal initiatives that have increased the performance expectations for State agencies: • Increase SNAP participation by eligible households. • Improve quality assurance and payment accuracy. Both of these initiatives have increased pressure on states to process larger volumes of applications while maintaining or increasing the accuracy of the eligibility determination and benefit levels. The efficiency and effectiveness of Montana’s new SNAP system will have a direct impact on Montana’s performance in these two areas. 3.1.6. TANF Program Overview The Temporary Assistance for Needy Families (TANF) program assists low-income adults with dependent children by providing employment and training services, work supports, and monthly cash grants. The TANF program is primarily funded by the Federal government through block grants to states or tribal entities. At the Federal level, the program is administered by HHS’ Administration for Children and Families (ACF). State governments and participating tribes, not the Federal government, decide on the design of their program, the type and amount of assistance payments, the range of services to be provided, and the rules for determining who is eligible for benefits. However, there are Federal rules and regulations that all state programs must comply with, including a 60-month lifetime limit on assistance for participating adults. Also, states are limited in the kinds of activities that can be funded by the TANF block grant. Funding must be used for one of the four purposes defined in Federal law, which include: 1. Providing assistance to needy families so that children may be cared for in their own homes or in the homes of relatives. 2. Ending the dependency of needy parents on government benefits by promoting job preparation, work, and marriage. 3. Preventing and reducing the incidence of out-of-wedlock pregnancies and establishing annual numerical goals for preventing and reducing the incidence of these pregnancies. 4. Encouraging the formation and maintenance of two-parent families. In addition, all states must meet annual program performance expectations – the most significant of which is the annual work participation rate. State programs must meet the minimum participation rate requirements
  24. 24. each year. If they do not, the Federal government can penalize the state by sanctioning a percentage of their block grant funding. In February 2006, President Bush signed the Deficit Reduction Act of 2005. The law reauthorized Federal funding and made changes in four areas that impact how Montana manages its program. 1. Recalibration of the base year for the caseload reduction credit, effectively increasing the work participation rate requirements for states. 2. More precise definitions of work activity categories, eliminating some state flexibility in defining their work programs. 3. Addition of some new categories of individuals into the work participation rate. 4. Establishing new work verification plan requirements. The combined impact of the four major changes has been to increase the performance expectations of the TANF program and to increase the importance of the TANF system to efficiently gather work participation data using a method that meets the new Federal work verification requirements. 3.2.RFP ORGANIZATION The remainder of this RFP is organized as follows: • SECTION 4: General Requirements – Defines overarching requirements including contractor, project management, and general technical requirements. • SECTION 5: Phase-Specific Requirements – Delineates specific contractor responsibilities, performance expectations, milestones, deliverables, and Department responsibilities for each of the 10 contract phases or components. • SECTION 6: Enterprise Architecture Requirements – Defines detailed functional system requirements for the enterprise architecture. • SECTION 7: Detailed Common Requirements – Describes system functional requirements common to both TANF and SNAP systems. • SECTION 8: Detailed SNAP Requirements – Describes detailed, functional system requirements for CHIMES-SNAP. • SECTION 9: Detailed TANF Requirements – Describes detailed, functional system requirements for CHIMES-TANF. • SECTION 10: Shared Fiscal Services Requirements – Describes detailed, functional system requirements for the shared fiscal services layer. • SECTION 11: Proposal Requirements – Defines the format and contents for the Technical and Cost Proposals to be submitted by offerors. • SECTION 12: Evaluation Methodology – Includes an overview of the proposal evaluation methodology and a summary of evaluation criteria. • SECTION 13: Appendices – Provided to support information presented in these sections, including detailed information on CHIMES-Medicaid.
  25. 25. SECTION 4.GENERAL REQUIREMENTS 4.0.INTRODUCTION This section of the RFP provides general requirements for the contractor scope of work in this RFP, and includes overall technical requirements that must be met within the development processes, as well as within the systems and enterprise architecture themselves. 4.1.CONTRACTOR RELATIONSHIP WITH DEPARTMENT AND OTHER CONTRACTORS As the CHIMES-TANF, CHIMES-SNAP, and enterprise architecture contractor, contractor staff will have an ongoing relationship with Department staff and other contractor staff that is based on trust, confidentiality, objectivity, and integrity throughout all phases of the contract. The contractor will be privy to internal policy discussions, contractual issues, price negotiations, State financial information, and advanced knowledge of legislation. The contractor must maintain complete confidentiality related to the CHIMES-SNAP, CHIMES- TANF, and enterprise architecture project. As part of the tasks described in this subsection, the contractor is responsible for the following general contract requirements: 1. Work cooperatively with key State staff, other system stakeholders, and the staff of other contractors as required in the course of the contract period. 2. Identify efficiencies that could be garnered by altering requirements, changing functionality, adapting business processes, or making other changes to the enterprise architecture or CHIMES systems. 3. Work on the eligibility systems and enterprise architecture at all times according to Federal and State regulations. 4. Inform Department management staff of current trends and issues in the eligibility and related systems’ marketplace, and provide information on new technologies in use in other states. 5. Work cooperatively with State staff assigned to the enterprise architecture, CHIMES-TANF, and CHIMES- SNAP project to ensure the success of the project. 6. Maintain complete and detailed records of all project meetings, system development life cycle documents, presentations, transition and system change planning issues, infrastructure management documents, performance reporting, risk assessment, project planning schedules, and any other interactions related to the system development project described in this RFP, and make such records electronically available to the Department on a regular basis throughout the life of the contract. 7. Work through the Department to share intellectual property information needed for external contractor quality assurance or independent verification and validation work. 8. Work collaboratively with other vendors performing quality assurance or independent verification and validation work, fixing identified defects and sharing performance metrics outlined in Section 4.2. In addition, contract requirements specific to each functional system area and phase are presented in later sections of this RFP. 4.2.PROJECT MANAGEMENT AND REPORTING The Department requests that the contractor propose an approach to project management for system development as well as project control tools to be used during the contract. The contractor must provide project management on an ongoing basis throughout the contract. The multiple deliverables associated with
  26. 26. the project management function must be completed according to the contractor’s proposed work plan, as approved by Department staff. The contractor is required to adhere to the standards described by the Project Management Institute (PMI) in the Project Management Body of Knowledge (PMBOK). All projects and plans must conform to the industry best practices. The Department will use the following criteria to determine acceptance of the services and/or deliverables included in this RFP: 1. Project plans to be executed according to a standard dictated by the Department. 2. Deliverables document the validity of the requested development process relative to current industry standards and rates. 3. Documentation and deliverables conform to the acceptance and adequacy standards dictated by the Department. 4. All required documentation, as specified by the Department, will be delivered within mutually agreed-upon time frames. 5. Each deliverable will be accompanied by a Deliverable Acceptance Request (DAR) that must be completed and returned to contractor within a mutually agreed upon time period. The TSD/PMB project manager/lead and the applicable customer project manager(s) must sign DARs. The contractor will be required to submit status reports to the Department’s Project Manager for the duration of the contract. The contractor's status reporting must provide information on progress toward meeting milestone dates and a formal report on progress and compliance with entrance and exit criteria. The Department will monitor each project milestone completion date to ensure that the implementation date will be met. Failure to meet any project milestone or deliverable completion date will be considered a signal to the State of Montana that a key date has not or will not be met. Damages may be assessed for failure to meet a project milestone or the implementation start date, as specified in this RFP and the resulting contract. The status report must also identify any problem or circumstance encountered by the contractor, or of which the contractor gained knowledge during the period since the last such status report, which may prevent the contractor from completing any of its obligations or may generate charges in excess of those previously agreed to by the parties. The contractor must identify the amount of excess charges, if any, and the cause of any identified problem or circumstance and the steps taken to remedy the same. The contractor will be required to create and store documents on the State’s SharePoint site established for the project. This includes but is not limited to status reports, deliverables, project plans, project management documents, and other supporting project documentation. Managing to schedule on large Design, Development, and Implementation projects is always a challenge. The Department believes strongly in the use of project performance metrics as a valuable management tool. At its discretion the Department may employ the services of a Quality Assurance and/or Independent Verification and Validation (IV&V) vendor to provide independent assessments of project performance. The Department requires the contractor to provide the following performance metrics data, preferably in a readily accessible electronic format: 1. Throughout the project, weekly updated estimates in person-hours of all work remaining. 2. Throughout the project, weekly reporting of actual work completed in person-hours. 3. During construction and unit test, weekly reporting of modules successfully coded and unit tested. 4. During integration/system test, weekly reporting of the number of test cases, scripts or scenarios executed, passed, and failed. 5. During integration/system test, weekly updated estimates of the number of test cases, scripts or scenarios remaining to be executed. 6. During integration/system test, weekly reporting of defects found, open and closed, and average hours to
  27. 27. fix per defect to date. 7. During user acceptance test, weekly reporting of the number of test cases, scripts or scenarios executed, passed, and failed. 8. During user acceptance test, weekly updated estimates of the number of test cases, scripts or scenarios remaining to be executed. 9. During user acceptance test, weekly reporting of defects found, open and closed, and average hours to fix per defect to date. 10. During pilot and implementation, weekly reporting of defects found, open and closed, and average hours to fix per defect to date. 11. During operations (warranty) and maintenance, monthly reporting of staff hours by type of staff (e.g., management, administrative, database application programming, web application programming). Additional operational reporting performance metrics will be agreed to with the contractor upon entering that phase of the contract. 4.3.CONTRACTOR COMMITMENT TO QUALITY MANAGEMENT The Department is making a significant investment in procuring the system development services described in this RFP. The contractor selected will perform an essential role in the State’s eligibility determination processes. To maintain continuous focus on the importance of delivering quality systems and services, the contractor must plan, implement, rigorously endorse, and constantly improve a quality assurance program. The Department seeks contractor endorsement of the fundamental importance of quality embedded in a living plan to introduce, promote, reinforce, and acknowledge quality in all contractor activities including communications. The contractor must develop a quality assurance/quality management (QA/QM) proposed structure as part of the proposal and refined early in the project to address the needs and specific opportunities for quality improvement throughout the contract period. The final plan will be developed and submitted to the State for review once the contract has been approved. The QA/QM plan should reflect the contractor's experience and resolve toward quality in systems design, testing, and implementation; process design and staff training; performance standards development and measurement; and customer satisfaction measurement and analysis. As part of its approach to quality management, the contractor must develop, support, and report progress against system metrics or software measurement criteria to allow both the contractor and the State to assess the progress of the systems development. The contactor must perform a review of information technology or information systems, to verify that the systems under development meet the objectives of the Department, and to ensure that the systems are developed in accordance with generally accepted standards for systems development. The evaluation of obtained evidence determines if the information systems are safeguarding assets, maintaining data integrity, and operating effectively and efficiently to achieve the organization's goals and objectives. The QA/QM process must also address contractor operations, and the plan should contain associated means to measure this. The QA/QM plan must provide adequate information on internal structures to determine if it is appropriate for the contractor to perform its own information system quality reviews and security audits, or whether the contractor must contract with an outside entity to perform these reviews and audits. The plan must also include a proposed process for deliverable submittal and State review. The QA/QM plan must be updated and submitted annually to the State for review. 4.4.CONTRACTOR TRANSPARENCY, ACCOUNTABILITY, AND RESPONSIBILITY The Department desires a significant level of transparency and visibility into the awarded contractor’s
  28. 28. development activities in relation to this project. The contractor will be a partner with the Department project staff and is expected to be proactive in identifying problems or areas for improvement and communicating any issues or recommendations to the Department in a timely manner. The Department also desires maximum contractor accountability. The contractor will be responsible for acknowledging and assuming responsibility for their actions, products, decisions, and policies. Specific responsibilities include: 1. Providing the Department ongoing electronic access to documentation used to support the activities conducted by the contractor. 2. Working collaboratively with the Department to gain Department approval of deliverables related to system development requested by the Department. These deliverables include, but are not limited to, requirements documents, design documents, testing plans and results, implementation readiness documents, and post-implementation review documents. Collaboration includes conducting walk-throughs of draft and final deliverables, communication on how Department comments were incorporated in final draft, and other Department defined collaboration requirements. 3. Clearly communicating the contractor’s understanding of changes or modifications requested by the Department. 4. Providing justification for any estimates for changes or modifications. The Department may request independent review or validation of such estimates using function point counts or similar industry methodologies to verify budget and schedule information provided by the contractor. 5. Revising hour and cost estimates and communicating any changes to original estimates in the change or modification’s detailed requirements document. 4.5.COMMUNICATION REQUIREMENTS The contractor will be responsible for developing a communications management plan for all project-related activities. This plan will be submitted to the Department for review and approval within the first 45 days after the contract start date. This plan should describe, at a minimum, how the contractor will communicate with the Department and other entities, frequency and quality of communication, and communication types. The contractor must provide all necessary software to support all electronic communications involved in day- to-day activities associated with the contract: 1. The Department must provide the ability for the contractor to connect with the State’s email system. 2. The system must enable all assigned contractor personnel to easily exchange documents and electronic files with the Department in compatible formats. The contractor is to maintain software versions that are compatible with the Department including, but not limited to, the following: a. Microsoft Word (State currently uses Office 2003. They plan to move to 2007 in the next year.) b. Microsoft Excel c. Microsoft Project d. Microsoft Access e. Microsoft PowerPoint f. Microsoft Visio g. Adobe PDF files (version 8) 3. The contractor must maintain such office automation compatibility between the Department and contractor personnel throughout the life of this contract. 4.6.COMPLIANCE WITH FEDERAL REQUIREMENTS The contractor must assist the Department in meeting Federal requirements for the joint State and Federal
  29. 29. programs that are administered by DPHHS. The contractor must follow operational compliance efforts with existing and ongoing legislation passed at the Federal or State level, including all requirements around Protected Health Information and the Health Insurance Portability and Accountability Act (HIPAA). 4.6.1. Federal and State Ownership of Copyright Licenses The State and FNS reserve royalty-free, nonexclusive and irrevocable license to reproduce, publish, or otherwise use and authorize others to use for Federal Government purposes, the copyright in any software and associated documentation developed under the resulting contract. All documentation and other work products developed by the contractor for this project will be considered works made for hire and owned by the State. For more detailed information, please refer to the U.S. Copyright Law at http://www.copyright.gov/title17/circ92.pdf. The U.S. Copyright Law states the following regarding documentation created for hire: “Works Made for Hire: In the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author for purposes of this title, and, unless the parties have expressly agreed otherwise in a written instrument signed by them, owns all of the rights comprised in the copyright.” 4.7.SECURITY, CONFIDENTIALITY, AND AUDITING The contractor must comply with State and Federal regulations, guidelines, and standards related to security, confidentiality, and auditing. 4.7.1. Security All information systems owned and operated by the State of Montana have some level of sensitivity and require the appropriate level of protection. The contractor must comply with Federal and State guidelines related to securing eligibility-related information. The contractor must provide assurance that it has effective internal controls over the processing of transactions performed under the resulting contract. The contractor must also demonstrate that it has adequate controls and safeguards over data and transactions maintained and processed on behalf of the State. Refer to subsection 7.151 for detailed security requirements. 4.7.2. Confidentiality The contractor must abide by all of the HIPAA Privacy Regulations found at 45 CFR Part 160 and Part 164, including future revisions and additions to these regulations. This includes agreement to control the use or disclosure of Protected Health Information as permitted or required by this agreement or as required by law. The contractor must establish, maintain, and use appropriate safeguards to prevent use or disclosure of client and provider personal information used by the contractor. This information must be held confidential and must not be divulged without the written consent of the Department. Need for access must be demonstrable and an auditable record of approvals must be maintained. All documents, data compilations, reports, computer programs, photographs, and any other work provided to or produced by the contractor in the performance of the contract must be kept confidential by the contractor until publicly released by the Department or until written permission is granted by the Department for its release. Publicly available information that is owned by the Department and information that is developed or maintained as part of this contract should not be released by contractor unless specifically authorized by the Department. The contractor will be responsible for adhering to the following guidelines: 1. Prior to release of protected health information (PHI) to any non-State entity, the contractor must verify with
  30. 30. the Department that the requesting party has signed the State’s HIPAA Business Associate Addendum. 2. Before disclosing any privileged information, the contractor must verify with the Department that such information may be disclosed. 3. Contractor personnel must sign Department confidentiality agreements before commencing work under this contract. 4.7.3. Auditing There are five distinct areas of auditing that need to be supported by the contractor. No additional funding will be allocated to the contractor for the audits required under this RFP. Therefore, the contractor is responsible for the cost of all audits and should ensure that those costs are included in the price of the contract. Detailed requirements are described below. The contractor must respond to requests for information or access in the Department-specified timeframe. 4.7.3.1.General Audits may be performed by a number of State and Federal Agencies or authorized agents. The contractor must fully cooperate with the audit process. An audit may include, but is not limited to, the following capabilities and applies to the applications and architecture: 1. Storing, retrieving, and executing programs, whether such programs are part of the contractor’s production system, or generated by contractor staff. 2. Sampling and reconciling subsystem files to ensure accurate and timely maintenance. 3. Demonstrating services and/or benefits were provided for eligible clients. 4. Reviewing the contractor’s organization, policies, procedures, practices, effectiveness of control, operating efficiency, facility and software security, and back-up procedures. 5. Reviewing the contractor’s compliance with contract terms, system specifications, State or Federal regulations, administrative directives, and program documentation. 6. Reviewing any phase or aspect of the project for any purpose related to the system. 7. Responding to requests for data or information. 8. Having access to files, documentation, and contractor personnel. 9. Assisting Department staff in responding to Federal inquiries. This level of support must also be provided to all other State audit agencies or their designees. 4.7.3.2.Performance Auditing The State may conduct an audit of the contractor’s and/or the system’s performance. Contractors will have an opportunity to respond to the audit. The performance audit may cover all phases of the contract and may include, but not be limited to, an examination of the program, function, operation, and/or the management of the system, security, and the procedures of the contractor. The purpose of this audit is to provide assurance to the State that the contractor is achieving economy, efficiency and effectiveness in the employment of available resources. Completed assessments may be kept on record at the State, maintained by the Quality Assurance Division of DPHHS, and may serve as past performance data. Past performance data will be available to assist agencies in the selection of IT service providers for future projects and procurement efforts.

×