RFP BPM007148 - Solicitation Requirements.pdf

STATE OF ARIZONA

Department of Health Services

NOTICE OF REQUEST FOR PROPOSAL (RFP)

ARIZONA DEPARTMENT OF

HEALTH SERVICES

150 N. 18th Avenue, Suite 530 Phoenix, Arizona 85007

SOLICITATION NUMBER: BPM007148 – REQUIREMENTS, LOT 1, ROUND 1

SOLICITATION DUE DATE/TIME: November 5, 2026 at 3:00:00 PM Local AZ Time

SUBMITTAL LOCATION: https://app.az.gov

DESCRIPTION: HANDS Maintenance and Operation Support

PRE-OFFER CONFERENCE:

Wednesday, September 2, 2026 at 02:00 PM Local AZ Time Google Meeting Info:

Video Call Link: meet.google.com/vdo-zncm-ohw Or Dial: (US) +1 347-773-1834 PIN: 377 711 304#

In accordance with A.R.S. § 41-2534, competitive sealed proposals for the services specified will be received by the Arizona Department of Health Services (ADHS) online in the State of Arizona’s online procurement system, https://app.az.gov (Arizona Procurement Portal – APP). Proposals received by the due date and time will be opened. The name of each Offeror will be publicly available. Proposals must be submitted in the State APP system on or prior to the date and time indicated.

Late proposals will not be considered. It is the responsibility of the supplier/offeror to routinely check the APP website for Solicitation Amendments. Additional instructions for preparing an Offer are included in this solicitation.

With seventy-two (72) hours prior notice, persons with disabilities may request special accommodations such as interpreters, alternative formats, or assistance with physical accessibility. Such requests must be addressed to the Solicitation contact person named below.

OFFERORS ARE STRONGLY ENCOURAGED TO READ THE ENTIRE SOLICITATION CAREFULLY.

Solicitation Contact:

Kailee Gray Procurement Officer Arizona Department of Health Services Email: Kailee.Gray@azdhs.gov Phone: (480) 392-4154 https://app.az.gov/ https://meet.google.com/uwk-ricy-jzi?hs=122&authuser=0 https://app.az.gov/ mailto:Kailee.Gray@azdhs.gov

SCOPE OF WORK

ARIZONA DEPARTMENT

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

Phoenix, Arizona 85007

REQUEST FOR PROPOSAL No.: BPM007148

HANDS Maintenance and Operation Support

RFP rev.9.29.2025

*The following table of contents applies to all attachment documents in APP for this Solicitation*

SECTION CONTENT

Solicitation Requirements Notice Page

Table of Contents

Scope of Services

Special Terms and Conditions

Uniform Terms and Conditions

Solicitation Instructions Special Instructions to Offerors

Standard Instructions to Offerors

Attachments Located in APP • Attachment A: Offer and Acceptance

● Attachment B: Notices, Correspondence & Payments

● Attachment C: Designation of Confidential, Trade Secret and Proprietary

Information

● Attachment D: Participation of Boycott of Israel

● Attachment E: Forced Labor of Ethnic Uyghurs Ban

● Attachment F: Proposed Subcontractors

● Attachment G: Conformance Statements and Exceptions Request

● Attachment H: References

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

Phoenix, Arizona 85007

REQUEST FOR PROPOSAL No.: BPM007148

HANDS Maintenance and Operation Support

RFP rev.9.29.2025

1. BACKGROUND

1.1. HANDS Consortium Overview

The Arizona Department of Health Services (ADHS) Bureau of Nutrition and Physical Activity (BNPA) includes the Arizona Special Supplemental Nutrition Program for Women, Infants, and Children (WIC) Program.

ADHS BNPA requires a Contractor to provide the Arizona WIC Program and other members of the Health and Nutrition Delivery System (HANDS) Consortium (American Samoa, Commonwealth of the Northern Mariana Islands (CNMI), District of Columbia (DC), Guam, and Navajo Nation WIC Programs) with HANDS

2.0 maintenance and operations support. More than 650 State and clinic staff within the HANDS Consortium utilize the HANDS 2.0 application to serve more than 175,000 participants on a monthly basis. The information in Table One (1) is an estimate of each of the Partner Agencies as of June 2025.

Partner Agency Local

Agencies Clinics Monthly

Participants Monthly

Households

WIC

Vendors Arizona 21 117 145,000 92,055 526 American Samoa 0 5 4,000 2,374 28

CNMI 0 3 2,600 1,729 15

District of Columbia

4 16 12,600 8,365 51

Guam 0 4 6,500 3,813 28 Navajo Nation 0 12 4,300 2,790 49 Total 25 157 175,000 115,429 697

1.2. HANDS 2.0, Participant Portal and Vendor Web Overview

1.2.1. HANDS 2.0 is the eligibility and data management system for the WIC and the Farmers’ Market

Nutrition Program (FMNP). As of October 1, 2019, ADHS does not utilize FMNP or Commodity Supplemental Food Program (CSFP) modules. DC and Guam have FMNP but do not currently use the HANDS 2.0 functionality to provide benefits for FMNP. There is interest in updating the FMNP and CSFP modules in the future, depending on program funding. Each of the Consortium members within the HANDS Consortium will have its own HANDS 2.0 software application, and each HANDS

2.0 software application will operate on the same version.

1.2.2. ADHS issues WIC food benefits using online WIC electronic benefit transfer (EBT) technology with a magnetic stripe card and PIN. ADHS is currently contracting with Custom Data Processing (CDP) to provide the WIC Direct EBT System and provide transaction processing and support services for EBT transactions. HANDS 2.0 currently interfaces with WIC Direct using the 2020.1 Universal Interface. The HANDS 2.0 to WIC Direct interface documentation is accessible at https://azdhs.gov/prevention/azwic/agencies/index.php#hands.

1.3. Architecture

1.3.1. HANDS 2.0 is a three (3) tiered Web Application implemented using the Microsoft Model-View-

Controller (MVC) framework in conjunction with a domain driven design and an Oracle database.

HANDS 2.0 is hosted in the Amazon Web Services (AWS) West Commercial Cloud with backup hosted in the AWS East Commercial Cloud. The technology stack is primarily comprised of .NET Core 8.0, Bootstrap 4, AWS virtual servers, Redis caching, DevArt Oracle Data Provider and Oracle 19c database. ADHS plans to upgrade the Oracle 19c database as it will be end of life in April 2027.

HANDS 2.0 is designed to operate efficiently with Google Chrome and Microsoft Edge Browsers.

HANDS 2.0 uses Topaz SigPlus software to operate the signature pads, Epson Perfection (V30, V37, and V39) scanner and drivers to operate scanners, and Core Interop drivers to operate the Verifone VX 805 PIN pads.

https://azdhs.gov/prevention/azwic/agencies/index.php#hands

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

1.3.2. The Participant Portal is a web application built using Angular version 14.2.5. The Participant Portal is integrated with Google and Facebook third-party authentications via Facebook or Google using their respective Application Programming Interfaces (APIs). The Portal also connects with the HANDS 2.0 system through a set of internal APIs. This allows the two (2) applications to share data seamlessly.

1.3.3. Vendor Web is a web application built using the ASP.NET MVC architectural pattern on the server side and Knockout Javascript on the client side. Vendor Web runs on the .NET Framework 4.8 and Knockout.js 3.2.0. The MVC structure separates business logic (Models), user interface (Views), and input control (Controllers), which promote organized and maintainable code. HANDS 2.0 communicates to Vendor Web through a set of internal APIs, allowing for seamless data sharing between.

1.4. Operational Status

HANDS 2.0 and the Participant Portal are fully operational in the six (6) agencies represented by the HANDS Consortium consisting of Arizona, American Samoa, CNMI, DC, Guam, and Navajo Nation. Currently, Vendor Web is utilized by only Arizona WIC. American Samoa, CNMI, DC, Guam and Navajo Nation may implement Vendor Web in the future. Daily operations and support continue to be managed by ADHS WIC IT team and the Contractor. The Contractor provides first (1st) level help desk, hereinafter known as the WIC Service Desk, support for any application or clinic operational issues, clarifications, or questions related to HANDS 2.0. The Contractor provides second-level technical WIC Service Desk support for support items routed to the Contractor for Development. Additionally, the Contractor monitors the end-of-day process to ensure that data is processed successfully for the continued operations of HANDS 2.0 providing mandatory caseload and financial reporting.

1.5. HANDS 2.0 Features

1.5.1. HANDS 2.0, Participant Portal and Vendor Web includes functionality related to the following areas as outlined in Business Requirement Documents (BRD), associated Change Requests, Requirement Clarifications and Detail Functional Design Documents (DFDD):

1.5.1.1. General System Requirements.

1.5.1.2. Immunization.

1.5.1.3. Appointment Scheduler.

1.5.1.4. Breastfeeding.

1.5.1.5. Certification and Enrollment.

1.5.1.6. Food Package – Local Agency.

1.5.1.7. Food Package – State.

1.5.1.8. Nutrition Education.

1.5.1.9. Operation Management.

1.5.1.10. Program Integrity – Clinic.

1.5.1.11. Program Integrity – Vendor.

1.5.1.12. System Administration.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

1.5.1.13. Standard Reports.

1.5.1.14. Vendor Management.

1.5.1.15. Farmers Market.

1.5.1.16. Commodity Supplemental Food Program (CSFP).

1.5.1.17. Local Agency Profile.

1.5.1.18. Rebates.

1.5.1.19. Caseload.

1.5.1.20. Food & Nutrition Service (FNS)-798.

1.5.1.21. Grants and Cash flow.

1.5.1.22. Mongo Database.

1.5.1.23. Vendor Web.

1.5.1.24. Participant Portal.

1.5.1.25. Competitive Price Analysis

1.5.2. All HANDS 2.0, Vendor Web, and Participant Portal DFDDs are posted online at https://azdhs.gov/prevention/azwic/agencies/index.php#hands. HANDS 2.0 Documentation will be updated regularly and includes, but is not limited to, functionality listed in section 1.5.1.

2. Objective

To provide the ongoing technical support for management, operations and maintenance of the existing HANDS 2.0, Vendor Web, and Participant Portal systems. Going forward, all references to HANDS 2.0 in the Scope of Work (SOW) will include HANDS 2.0, Vendor Web and Participant Portal.

3. Scope of Work

Provide maintenance and operations support for the HANDS Consortium while coordinating with the Arizona WIC Program who leads the HANDS Consortium. Ensure the components of HANDS 2.0 are kept up to date and that the Software Design Life Cycle processes set in place by ADHS are adhered to by the contractor’s staff.

4. REQUIREMENTS

The Contractor shall:

4.1. Computer Equipment

4.1.1. Provide computers for the team supporting HANDS 2.0.

4.1.2. Access the ADHS network from within the United States. Accessing the ADHS network from outside of the United States is prohibited.

4.1.3. Allow ADHS to scan computers on the ADHS network for viruses.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

4.2. Ensure team members assigned to this project are highly qualified, dedicated and skilled with a minimum of three (3) to five (5) years’ experience in WIC, HANDS 2.0 or similar MIS Implementation or maintenance projects, Microsoft.NET, and Oracle database.

4.3. Comply with all of the applicable Arizona Statewide IT policies (https://aset.az.gov/resources/psp).

4.4. Comply with all Arizona Homeland Security policies (https://azdohs.gov/information-security-policies-standards-and-procedures).

4.5. Have at least two (2) years of WIC MIS or other USDA federal assistance program experience providing implementation services within the last three (3) years.

5. TASKS

5.1 Project Initiation

5.1.1. Convene a project initiation meeting within ten (10) days of Contract award. The project initiation meeting shall be in-person or virtual, as determined by ADHS following contract award. The Contractor’s Project Manager and other key Contractor staff shall attend the meeting, as deemed necessary by the ADHS. The purpose of the meeting is to establish expectations; contract deliverables, review the Contractor Project Plan, including schedule and deliverables, and discuss the management of the HANDS 2.0 maintenance and operations.

5.2 HANDS 2.0 Maintenance Management:

5.2.1. Provide maintenance management for HANDS 2.0 by providing all product or software updates which include new features, bug fixes, component updates, security fixes, and enhancements.

5.2.2. Ensure HANDS 2.0 maintains its functionality and stays applicable when compared to emerging technology, clinic operational model, or participant services.

5.2.3. Ensure the HANDS 2.0 architecture and application code are managed to ensure that the application, while it is backward compatible, does not fall behind on technology or functionality that would result in the application’s life cycle coming to a premature end.

5.2.4. HANDS 2.0 Release Management Planning:

5.2.4.1. Collaborate with ADHS for software changes, manage changes through ADHS ADO, and submit change request for major, complex, and or exceeding forty (40) hours of development effort.

5.2.4.2. Collaborate with ADHS to plan release dates based on the number of items to be completed from the product backlog and new planned features. This will enable every directly affected stakeholder to plan for the release, as the release may entail new policy or procedural changes, training, and data preparation.

5.2.4.3. Release a minimum of two (2) major versions of HANDS 2.0 on an annual basis as agreed upon with ADHS. The releases shall include the following features, feature corrections, or enhancements:

5.2.4.3.1. Fixes or changes to already implemented features based on production operations.

https://aset.az.gov/resources/psp https://azdohs.gov/information-security-policies-standards-and-procedures https://azdohs.gov/information-security-policies-standards-and-procedures

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.2.4.3.2. Fixes to software (User Interface, Business process, and Stored Procedure) for bugs or issues identified in production operations. This also includes current identified issues or bugs as documented in ADO.

5.2.4.3.3. Provide enhancement activities - system enhancements that include changes to HANDS 2.0 to accommodate or meet the requirement.

5.2.4.3.4. Security fixes.

5.2.4.3.5. System component upgrades.

5.2.4.3.6. Align data and data structures as it is relevant to HANDS 2.0 operations.

5.2.4.3.7. Complete pending functionality development on Waitlist Management.

5.2.5. Requirements Management

5.2.5.1. Ensure the development methodology follows the iterative and incremental development approach, each iteration will begin with analysis and design with its own set of approved or agreed requirements. Utilize the approach with the use of Joint Analysis and Design (JAD) sessions where requirements analysis, story boards, and ‘design mock ups’ or wireframes are presented to ADHS to document intended functionality of a new feature or enhancement feature. The output of the requirement or design sessions with ADHS will be documented with clear decisions and action items. During each JAD or requirement session, the Contractor shall work with ADHS to gain clarification of requirements, capture input on design and document design decisions through the use of meeting notes. Notes are used to prepare the use cases or BRD or update DFDD which will be used during the iteration development step.

Development and unit testing are based upon the documented requirements. The Contractor shall update documentation at the conclusion of each iteration.

5.2.5.2. Align the documentation to be solution documentation that is comprised of features, functions, and characteristics of the functionality or feature. System requirements are written at different levels of detail and are associated with different types of requirements, for example, business, transition, or reports. The solution documentation may be rendered in any number of forms. Some of the forms include:

5.2.5.2.1. BRD.

5.2.5.2.2. Uses Cases.

5.2.5.2.3. List of product backlog.

5.2.5.2.4. Coordinate with ADHS the requirement management process in place for the HANDS 2.0 development for any clarification on existing HANDS 2.0 functionality.

5.2.5.3. The purpose of BRDs or use cases is to define the new, modified, or enhanced functionality or process with consideration given to WIC regulations, Arizona WIC policy, processing related to Value Enhanced Nutrition Assessment (VENA), Participant Centered Services (PCS), and the most recent USDA requirements. The BRDs and other associated requirements are not meant to include in-depth programming language, code, or queries. In addition, the newly developed BRD, use cases, or change requests are not meant to document the complete set of requirements for HANDS 2.0. Requirements or functionality of HANDS 2.0 will be

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530 maintained in the DFDD.

5.2.5.4. The list of product backlog will be maintained and managed within ADHS ADO.

5.2.6. Development Phase

5.2.6.1. Review the product backlog, issue list, approved enhancement, ADHS prioritization, and any open change orders to determine the scope and schedule of one (1) or more sprints. Once a sprint plan is finalized, the Contractor shall publish the sprint plan to the development team. During the sprint cycle, the Contractor shall continue the agile process for development per the ADHS ADO process document. The complete SDLC process shall be managed in ADHS ADO. Technical Leads, in consultation with the Managers, shall guide the development process. Requirement documents, along with the product documentation and product code, shall be used during development.

5.2.6.2. The Quality Assurance (QA) team shall create new test scripts and/or update existing test scripts based on the work items defined in the sprint plan.

5.2.6.3. Ensure that developers have completed unit testing and that the feature implemented is complete. Based on the scope and complexity of the feature implemented, a developer may review the design with the team and demonstrate the completed functionality. The demonstration shall be completed prior to the release of the software to QA. A technical lead or developer shall review the code and approve the check-in of code.

5.2.6.4. Ensure that the individual's status on assigned tasks is monitored by the Operations

Manager through monitoring work in ADO, direct conversation, or in stand-up meetings. The Contractor’s internal process may involve more than one (1) release to the QA site prior to the final production release candidate. Such releases are coordinated by the Contractor depending on the number of items to be completed.

5.2.6.5. Manage requirements during this period through the established procedures. Any changes to the agreed upon requirements will be documented and provided for acceptance prior to a change in code, screen, functionality, feature, or database process.

5.2.7. QA Testing

5.2.7.1. Ensure that after a new version of software is released for QA, QA analysts shall begin targeted and methodical testing. Targeted testing includes testing for new features or enhancements and testing the fixes related to individual ADHS ADO items.

Methodical testing follows the testing as described in the QA section of this Contract.

The QA analysts shall conduct a formal regression testing that validates that major components of the application are still functional and no functionality has degraded.

The QA analysts shall reject a development release if there is any critical functionality degradation. The QA analysts shall also reject bug fixes that do not have the assurance that it has been unit tested and with the explicit note how the fix was implemented. For reports, The QA analysts shall require a sample report with data from development to prove that the issue has been fixed.

5.2.7.2. Ensure that the business analyst creates release documentation associated with any pending production release during QA activities.

5.2.7.3. Use ADHS ADO to manage system exceptions identified during the QA process and

ADHS User Acceptance Training (UAT) review process. Exceptions shall be checked to ensure that it conforms to the documented requirements when it relates to the

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530 scope of the functionality implemented. Any discrepancy related to requirements shall be transferred to the requirement management process.

5.2.7.4. The Arizona WIC Program will have the option to manage the two (2) QA Analysts

(referenced in SOW section 5.3.1.3) and provide direction in daily testing activities.

5.2.8. UAT Release and Support:

5.2.8.1. Following an internal agreement to release the software for UAT, the Contractor shall provide ADHS with the build details including code change, database change, windows services changes, end of day services, etc. ADHS will release the software to the web servers, install any database scripts, and any additional changes.

5.2.8.2. Support ADHS during smoke test of the UAT build. ADHS will validate the release using specific scenarios as listed below to ensure that the release is stable and is ready for UAT.

5.2.8.3. Provide release notes to ADHS a minimum of one (1) week prior to delivering the software release to the ADHS QA team for UAT. The Contractor shall provide a technical version for higher-level users and a non-technical version for end users.

5.2.9. Production Testing

5.2.9.1. Attend Pre-Release Meeting. ADHS will prepare a pre-release checklist that details the tasks and responsibilities.

5.2.9.2. The Contractor shall provide on-call support during the production release if the ADHS team encounters any issues.

5.2.9.3. The Contractor shall notify ADHS immediately if there are any operational issues found in the application. The Contractor shall work with ADHS to identify mitigation strategies and support the WIC Service Desk as needed.

5.2.10. Production Release Documentation

5.2.10.1. The Contractor shall provide ADHS with an updated DFDD to include new or updated product features a minimum of one (1) week prior to production release.

5.2.10.2. The Contractor shall provide ADHS with updated State/Clinic level User Manuals one

(1) week after each production release or at a frequency determined agreed upon by the Contractor and ADHS.

5.2.10.3. The Contractor shall update the HANDS 2.0 “Help” documentation a minimum of one

(1) week prior to production release and have it approved by ADHS. The HANDS 2.0 “Help” documentation provides instructions for each module with screenshots and is contained within the HANDS 2.0. The HANDS 2.0 “Help” screens shall be updated with the release.

5.2.10.4. The Contractor shall update the data dictionary a minimum of one (1) week prior to the production release.

5.2.11. Change Management

5.2.11.1. The Change Control document will be finalized by ADHS and the Contractor following contract award.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.2.11.2. The Contractor shall prepare all HANDS 2.0 change requests and document the system and stakeholder impacts. The change request shall include the total analysis, development, and testing hours estimate and cost.

5.2.11.3. Change requests that utilize staff currently included within this contract shall be zero

(0) cost. Change requests that utilize resources above and beyond what is required for this contract may include an additional cost, and will need to be approved by the ADHS change control board.

5.2.12. Project Management Coordination

5.2.12.1. The Contractor shall collaborate with ADHS and share information by attending the following meetings:

5.2.12.1.1. Attend weekly project manager’s meeting.

5.2.12.1.2. Attend quality assurance meetings as requested by ADHS MIS QA.

5.2.12.1.3. Attend risk management meetings.

5.2.12.1.4. Attend requirement or design meetings as requested by ADHS.

5.2.12.1.5. Attend technical status or review meetings.

5.3 HANDS 2.0 Operations Management:

5.3.1 Provide the following resources, which will work remotely:

5.3.1.1. One (1) Operations Manager

5.3.1.1.1. Oversee the success of the operations of HANDS 2.0 as it assists

ADHS to provide continuous operations to WIC clients. The Operations Manager shall have at least two (2) years of WIC MIS or WIC EBT experience, or similar experience within the last five (5) years. The Operations Manager shall have a Project Management Professional (PMP) certification or has attended project management training about the standards and practices of project management as defined by the Project Management Institute. The development and technical support activities shall be managed by the Operations Manager. The Operations Manager shall be responsible for software work products and the coordination of technical components and installation between the Contractor and ADHS.

5.3.1.1.2. Responsible for the following, but not limited to

5.3.1.1.2.1. Interact with ADHS Project Manager(s) for the

purpose of coordination, status reporting, and budgeting.

5.3.1.1.2.2. Manage the Contractor’s risks including HANDS 2.0, Participant Portal and Vendor Web applications technical risks.

5.3.1.1.2.3. Advise ADHS Project Manager(s) on risks and risk mitigation.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.3.1.1.2.4. Advise ADHS Project Manager(s) of changes in work direction.

5.3.1.1.2.5. Coordinate and plan the Contractor’s team activities utilizing ADHS Project Manager’s input.

5.3.1.1.2.6. Manage Project Reporting.

5.3.1.1.2.7. Work with ADHS Project Manager(s) towards

planning and strategies.

5.3.1.1.2.8. Communicate with ADHS Project Manager(s) and

designated ADHS personnel.

5.3.1.1.2.9. Plan and conduct project meetings, including

requirements meetings, evaluation sessions, and design and analysis sessions.

5.3.1.1.2.10. Coordinate review and signoff of deliverables.

5.3.1.1.2.11. Act as single point of contact for all Contractor issues.

5.3.1.1.2.12. Review approved business requirements and

identifying strategy for technical architecture and requirement evaluation.

5.3.1.1.2.13. Identify best business practices for best solution models.

5.3.1.1.2.14. Assist project team members.

5.3.1.1.2.15. Ensure that the project is adequately staffed to meet expectations.

5.3.1.2. One (1) Business Analyst

5.3.1.2.1. Responsible for the following, but not limited to:

5.3.1.2.1.1. Manage the requirement clarification process as

defined in the project and agreed by ADHS.

5.3.1.2.1.2. Publish meeting minutes from sessions.

5.3.1.2.1.3. Identify risk and suggest plans to mitigate risks.

5.3.1.2.1.4. Lead, conduct, and facilitates joint application design or user sessions to elicit and confirm requirements.

5.3.1.2.1.5. Gather business requirements through a variety of techniques such as work sessions and interviews.

5.3.1.2.1.6. Communicate these requirements to appropriate

stakeholders, including customers and development staff.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.3.1.2.1.7. Provide input into developing and modifying systems to meet ADHS needs.

5.3.1.2.1.8. Coordinates and facilitates meetings with ADHS to gather and document requirements and explore potential solutions.

5.3.1.2.1.9. Participate in requirement and analysis and design sessions.

5.3.1.2.1.10. Conduct & participate in design review sessions.

5.3.1.2.1.11. Develop documentation and maintain project

documentation up-to-date based on release notes.

5.3.1.2.1.12. Publish release notes.

5.3.1.2.1.13. Consolidate, document, and publish implementation details that are not documented in the project.

5.3.1.2.1.14. Document functional requirements, operational and training manuals.

5.3.1.2.1.15. Train users of application or new software releases.

5.3.1.2.1.16. Assist users or trainers during training.

5.3.1.3. Two (2) Quality Assurance Analysts

5.3.1.3.1. Responsible for the following, but not limited to:

5.3.1.3.1.1. Participate in requirement and analysis and design sessions.

5.3.1.3.1.2. Work with the project team to identify data

requirements.

5.3.1.3.1.3. Create Test Plan and test cases for validation of common and exception processing and user scenarios and enter into ADHS ADO repository.

5.3.1.3.1.4. Validate the software to verify that requirements are complete and functions as expected.

5.3.1.3.1.5. Test the application for conformance to requirements.

5.3.1.3.1.6. Run test plan and test cases and create bugs in the

ADHS ADO.

5.3.1.3.1.7. Provide Level II WIC Service Desk support as

needed.

5.3.1.3.1.8. Train users of application or new software releases.

5.3.1.3.1.9. Assist users or trainers during training.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.3.1.4. Three (3) Developers

5.3.1.4.1. Responsible for the following, but not limited to:

5.3.1.4.1.1. Conduct user requirement or design sessions as

5.3.1.4.1.2. Validate requirements, create wireframes, create development journals.

5.3.1.4.1.3. Identify and document re-engineering possibilities.

5.3.1.4.1.4. Suggest business process improvements.

5.3.1.4.1.5. Identify and document data requirements.

5.3.1.4.1.6. Develop technical documentation.

5.3.1.4.1.7. Ensure programs meet standards and technical

specifications.

5.3.1.4.1.8. Code, test, debug, and implement software work

products using Visual Studio (Microsoft.NET and Oracle).

5.3.1.4.1.9. Provide Level II WIC Service Desk support as

5.3.1.4.1.10. Monitor End-of-Day reports for any corrections.

5.3.1.4.1.11. Monitor data processing for rebates, redemptions, caseload, and financial reporting as needed.

5.3.1.5. Three (3) Customer Service Representatives (CSRs)

5.3.1.5.1. Responsible for the following, but not limited to:

5.3.1.5.1.1. Provide excellent first (1st) level customer support to the State, Local, or Clinic WIC personnel that require program or technical support with the WIC applications including: HANDS 2.0, Vendor Web, Participant Portal, Universal Product Code (UPC), EzWIC, Complaint Tracking, and Clinic Search.

5.3.1.5.1.2. Provide excellent first (1st) level customer support to WIC participants that call the WIC Shoppers Helpline to get assistance with shopping with their eWIC card.

5.3.1.5.1.3. Create and manage tickets in the Contractor provided ticketing application.

5.3.1.5.1.4. Follow ADHS defined processes for documenting and managing WIC Service Desk tickets.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.3.1.5.1.5. Maintain ninety-five percent (95%) or greater

adherence to all ADHS Service Level Agreements for customer service.

5.3.2. Provide a best value team that has the technical expertise to understand ADHS requirements with the following capabilities:

5.3.2.1. Understand ADHS and HANDS Consortium both in program and IT needs.

5.3.2.2. Understand business issues and vision as ADHS moves forward with its operational improvements and enhancements of service delivery of HANDS 2.0.

5.3.2.3. Experience implementing WIC systems of similar size and complexity.

5.3.2.4. An experienced project team with the expertise to deliver projects.

5.3.2.5. Experience with WIC, .NET, Oracle and other technologies used by WIC.

5.3.2.6. Proven methodology, tools, and techniques that provide structure and discipline, increasing team efficiency.

5.3.2.7. Development approaches that can be tailored to the specific needs of each individual project.

5.3.3. Provide resources required to provide maintenance, enhancement, operation, and WIC Service

Desk support of the HANDS 2.0 system with skilled management, development, documentation, and support resources.

5.3.4. Provide resources with skills in Microsoft .NET, jQuery, MVC, PL/SQL, Oracle database, WIC, MIS and WIC EBT.

5.3.5. Allow ADHS to review resumes, interview, and approve any resources provided prior to hire or reassignment.

5.3.6. Each resource in SOW section 5.3.1. shall provide forty (40) hours of work per week.

5.3.7. Resources in SOW section 5.3.1. that are lost due to turnover shall not be vacant for more than thirty (30) days.

5.3.8. All references to developers, business analysts, quality assurance analysts, and resource manager within this SOW are the Contractor’s resources unless referenced specifically as ADHS resources.

5.3.9. Support network, hardware, database, and technical and application software as required for preventive and adaptive maintenance to ensure business continuity. Business continuity refers to the ability to continue key operations without stoppage, regardless of adverse circumstances or events. These may include Windows configuration or components update, builds scripts definition or update, software modifications required to maintain the continuous operations of HANDS 2.0, data conversions or data corrections, one-time data loads, run time improvements, performance upgrades through software code fixes, database or SQL tuning, or server or system software configuration.

5.4 Software Development Life Cycle (SDLC) Methodology:

5.4.1. Development

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.4.1.1. Use the agile development methodology with phased releases of HANDS 2.0. These releases shall be integrated with new functionality, enhancements to existing functionality, and feature corrections. Iterative development is an approach to software development which centers on the idea of moving development cyclically, rather than trying to do entire features at once. Iterations offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. Incremental development slices the system functionality into processes or features. In each increment, a slice of functionality is delivered through cross-discipline work, from requirements to deployment. Each iteration or sprint shall last two (2) to four (4) weeks. Each iteration or sprint involves a team working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and quality assurance testing when a working set of features is completed.

5.4.1.2. Each Iteration or Sprint:

5.4.1.2.1. Iteration Planning – Perform refinement cycles consistent with an iterative process. Each refinement process shall conduct another Iteration Planning meeting to plan the remaining iterations. Iteration planning meetings will address the following:

5.4.1.2.1.1. Review achievements of past iterations.

5.4.1.2.1.2. Identify remaining requirements to be completed

based on product backlog and ADO items.

5.4.1.2.1.3. Review the planned requirements to be addressed in the present iteration.

5.4.1.2.1.4. Assign team to perform requirement analysis in

preparation for the iteration design.

5.4.1.2.1.5. Decide on whether the current plan should change based on past iteration performance.

5.4.1.2.1.6. Modify the iteration plan (if applicable).

5.4.1.2.1.7. Finalization of the modified iteration plan (if

applicable).

5.4.1.2.1.8. Enter all user stories and tasks into ADO including descriptions, links, attachments, estimated hours, and remaining hours.

5.4.1.2.2. Iteration Kick Off Meeting – Conducted as a launch point into the next iteration or start of an iteration. This meeting shall be led by the Operations Manager and the developers. The meeting will be attended by key resources such as the business analyst, developers, and quality Assurance Analysts. ADHS may choose to attend this meeting. The kick-off meeting shall:

5.4.1.2.2.1. Focus the team on the requirements of the current iteration.

5.4.1.2.2.2. Identify what screens, workflows, or functions will be modeled by reviewing HANDS 2.0, Detail Functional

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

Design Document, and any Supporting Requirement Documents.

5.4.1.2.2.3. Review the iteration plan.

5.4.1.2.2.4. Remind team of established standards to be followed.

5.4.1.2.2.5. Present the iteration’s schedule and milestones.

5.4.1.2.2.6. Review the estimated time to complete based on

progress of the project and current plan.

5.4.1.2.3. Iteration Execution

5.4.1.2.3.1. Each iteration shall cover identified aspects of multiple modules, establishing a strong foundation, as the HANDS 2.0 design and development progresses.

5.4.1.2.3.2. During the execution phase, the technical team leads shall conduct daily scrums and as needed design sessions to determine best solution and guide the developers. Additionally, the team leads shall meet with the managers to communicate any issues, risks, or challenges during the execution process so that hurdles are mitigated without an extended impact on the project. The team leads shall have the ownership to complete the features targeted for the iteration.

The development process shall be completed after the developer attests that he or she has completed the unit testing and checked the code into the ADO.

5.4.1.2.3.3. During the execution phase, the QA team shall test the previous development release and document any discrepancies with documented requirements or system exceptions in ADO. The system exceptions shall be prioritized for implementation in subsequent releases. The QA team shall also update the test scripts based on any decisions made during the scrum or design meetings.

5.4.1.2.3.4. As noted, iterate on shall be scheduled two (2) – four

(4) weeks depending on the scope and schedule of the planned iteration. Each iteration shall have its own design, development, testing, and documentation activities managing to the scope and goals of the pending release. Each iteration’s outcome would be a release. A major release shall include several iterations grouping output from more than one (1) minor release. Releases to for UAT shall be coordinated through the major release schedule cycle.

5.4.1.2.3.5. Documentation is a continuous process ending with the update of DFDD and the creation of release notes.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.4.2. Quality Assurance

5.4.2.1. Follow the agile methods used for development, by adjusting to ADHS needs with full transparency and effective communication among the SDLC teams.

5.4.2.2. Participate in HANDS 2.0 requirements and design sessions.

5.4.2.3. Create test cases from the user perspective, defining negative, alternative, and exception scenarios, and identifying potential flow exceptions or gaps.

5.4.2.4. Regression test the final build prior to authorizing a release for User Acceptance

Testing.

5.4.2.5. Quality Control Methodology

5.4.2.5.1. Ensure that Quality Control consists of setting standards and testing are being met. When a final build is released into the QA environment, the Contractor shall perform an initial smoke and sanity test. This test provides quick feedback on the stability of the system. Once a smoke test has passed successfully the Contractor practice uses a variety of methods for testing including black box testing which includes boundary testing, cause/effect testing, fuzz testing, and comparison testing. The white box testing performed includes path testing, loop testing and control structure testing.

5.4.2.5.2. Ensure that the following four (4) levels are covered in the QA process:

5.4.2.5.2.1. Unit Testing.

5.4.2.5.2.2. Integration Testing.

5.4.2.5.2.3. Component Interface Testing.

5.4.2.5.2.4. System Testing.

5.4.2.5.3. Maintain and utilize repository of test cases that include but are not limited to unit, functional, integration, scenario tests in ADHS ADO.

These scripts shall be maintained in a Master Test Plan and updated by the QA staff based on BRDs, requirements updates, enhancements, and design implementations. The updating process is initiated in several manners including a change request, clarification, or a bug.

5.4.2.5.4. Once a build has been deemed acceptable for testing based on the smoke test the QA team shall begin their methodological approach to validating and ensuring no degrade in the HANDS 2.0 product. This process includes creating a new test plan in the Microsoft Test Manager. All test cases that pertain to the release shall be copied from the master test plan and placed into the new test plan. All test cases will be run and failures shall be documented in ADO as a bug that is sent to development for resolution. After defects have been resolved the test case is run again to ensure completeness.

5.4.2.5.5. After the full testing cycle has been completed, the Contractor’s team shall review the listing of defects to evaluate the quality of the product using the priority/severity agreement between ADHS and the

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

Contractor. A final end-to-end testing shall be completed and the QA Manager certifies the build to be released to ADHS for UAT.

5.5 Software Configuration Management:

5.5.1. Ensure that the software configuration is managed to ADHS requirements.

5.5.1.1. Source and Code Structure:

5.5.1.1.1. The source code control and versioning software used for this project is Microsoft’s Azure DevOps 2019 or newer. Both Source Code and Database structure scripts are stored in ADO with each having its own respective area. ADHS reserves the right to upgrade to newer version of the software in coordination with the Contractor.

5.5.1.2. Environments:

5.5.1.2.1. Manage the migration of the HANDS 2.0 application through the various software environments. There are five (5) main software environments. These are Development, QA, User Acceptance (UAT), Training, and Production. Each of these environments has its own virtual server, database, software, etc. along with other individual environmental components.

5.5.1.2.2. The HANDS 2.0 environments include:

5.5.1.2.2.1. Development.

5.5.1.2.2.2. Quality Assurance.

5.5.1.2.2.3. User Accept Test.

5.5.1.2.2.4. Arizona Training.

5.5.1.2.2.5. American Samoa Training.

5.5.1.2.2.6. CNMI Training.

5.5.1.2.2.7. DC Training.

5.5.1.2.2.8. Guam Training.

5.5.1.2.2.9. Navajo Nation Training.

5.5.1.2.2.10. Arizona Production.

5.5.1.2.2.11. American Samoa Production.

5.5.1.2.2.12. CNMI Production.

5.5.1.2.2.13. DC Production.

5.5.1.2.2.14. Guam Production.

5.5.1.2.2.15. Navajo Nation Production.

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.5.1.2.3. The Participant Portal environments include:

5.5.1.2.3.1. Development.

5.5.1.2.3.2. Quality Assurance.

5.5.1.2.3.3. User Accept Test.

5.5.1.2.3.4. Arizona Production.

5.5.1.2.3.5. American Samoa Production.

5.5.1.2.3.6. CNMI Production.

5.5.1.2.3.7. DC Production.

5.5.1.2.3.8. Guam Production.

5.5.1.2.3.9. Navajo Nation Production.

5.5.1.2.4. The Vendor Web environments include:

5.5.1.2.4.1. Development.

5.5.1.2.4.2. Quality Assurance.

5.5.1.2.4.3. User Accept Test.

5.5.1.2.4.4. Arizona Production.

5.5.1.2.5. The HANDS 2.0 application is migrated through several different stages and environments before going from development to production as shown below. There is a predetermined set of criteria that the system will need to meet before it is migrated from one (1) environment to another. These criteria include but is not limited to:

5.5.1.2.5.1. New features.

5.5.1.2.5.2. Rework/redesign.

5.5.1.2.5.3. Test case results.

5.5.1.3. Development:

5.5.1.3.1. Have the Development team access the source code repository

(ADHS ADO) and to edit the code to accomplish new features and bug fixes in accordance with assigned work. Each developer has a development environment locally that can accomplish the full feature set of HANDS 2.0. Code files are automatically checked out of ADO and checked back in as work is complete using Microsoft’s Visual Studio 2022 or newer. ADHS reserves the right to upgrade to newer version of the software in coordination with the Contractor.

5.5.1.3.2. These checked-out files live on each developer’s workstations. Any hardware peripherals (scanners, signature pads, printers, etc.) are also used in conjunction with a developer’s setup. A development

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

Oracle database is also used. Optionally, developers may also have a local Oracle instance that they use to accomplish software development.

5.5.1.3.3. A Build Server manages nightly builds to a HANDS 2.0 development site. This ensures that code checked in each day is compatible with the whole code base and no one’s code check-in breaks the site.

5.6 Planned Maintenance

5.6.1. Ensure that the following tasks are implemented in order for the HANDS 2.0 application and its processes (EOD, SMS, etc.) continue to function optimally. These tasks shall be coordinated with ADHS and implemented:

5.6.1.1. Maintain a current or an ADHS and Contractor agreed upon version of the DevArt dotConnect utility for its primary database connections.

5.6.1.2. Review HANDS 2.0 architecture and code base for performance improvements.

Performance optimization is a continuous process based upon a cycle of observation, identification, and correction.

5.6.2. The Contractor shall maintain the HANDS 2.0 interface with the EBT System to meet the ADHS approved version of the WIC Universal MIS to EBT Interface (WUMEI). The WUMEI is available at https://www.fns.usda.gov/wic/ebt.

5.7 Documentation Management:

5.7.1. The Contractor shall use ADHS SharePoint to manage documentation in the project. The types of documentation include, but not limited to: BRDs, Change Requests, DFDDs, DTSD, Data Dictionary, User Manuals.

5.8 Application Operations Support:

5.8.1. Review the Internet Information Services (IIS) logs, database logs, MongoDB, Redis and any other logs for any performance degradation or application or infrastructure issues.

5.8.2. Implement code changes or application or infrastructure settings changes to ensure optimal performance and quality of the application.

5.8.3. Perform an initial investigation, impact assessment, and determine the urgency of the request, code issue, or application behavior concern and report to ADHS to allow for a decision determining the appropriate course of action while a remedial solution or temporary work-around is implemented while a permanent solution is implemented.

5.8.4. Provide adaptive and preventive maintenance activities that are required due to technical changes to system components such as upgrades or patches to application server, operating system, system or infrastructure software or database.

5.8.5. Provide active security management to counter the increasing speed at which new exploits on web-based applications are devised to ensure that the HANDS 2.0 application architecture is up-to-date with current industry standards on security.

5.8.6. Fix all ADHS designated security issues discovered during annual HANDS 2.0 security assessment.

https://www.fns.usda.gov/wic/ebt

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

5.8.7. Provide ADHS staff members with assistance in reporting data that is not available using the HANDS 2.0 reports and collaborate with ADHS staff member to determine the business requirements and the format required for the ad-hoc reports.

5.8.8. Review the data extracts generated from HANDS 2.0 use ad-hoc scripting to load the extract data into a database table; review the validity of the data based on the ADHS, CDC and FNS specifications; and advise ADHS of any changes to these extracts that may be necessary based on any new specifications.

5.9 Application Performance Operations Support:

5.9.1. Provide application performance support which includes but is not limited to the following factors:

network efficiency, database efficiency, hardware capacity and application code efficiency.

5.9.2. To the extent performance issues are associated with the application code and data model the

Contractor shall address the same as it is critical for the successful operations of HANDS 2.0. If the performance issues are due to other factors, the same shall be researched and addressed by ADHS. The Contractor shall evaluate performance improvements along with ADHS based on essential, conditional, and optional improvements based on their impact on overall and marginal performance gained through application, browser, bandwidth, and server capacity, functionality degradation due to regression impact, clinic operational requirements, project risk, and cost.

5.9.3. Participate in ADHS led HANDS 2.0 performance tests and assist in troubleshooting any identified issues.

5.10 End-of-Day (EOD) Operations Support:

5.10.1. Ensure the end of day HANDS 2.0 processing is successfully processed.

5.10.2. Ensure the EOD processing is successfully processed daily by reviewing EOD logs from the previous night.

5.10.3. Monitor the EOD logs for the following production installation of HANDS 2.0:

5.10.3.1. Arizona.

5.10.3.2. American Samoa.

5.10.3.3. CNMI.

5.10.3.4. DC.

5.10.3.5. Guam.

5.10.3.6. Navajo Nation.

5.10.4. If the EOD jobs are not completed its execution as scheduled due to a system issue, collaborate with the ADHS to resolve the issue. If there is a data processing or code execution error, the Contractor shall determine the nature of the error and implement a solution as required. The EOD job stream is designed so that if it does not run on a particular day, it can be set to process the missed day’s data using EOD control.

5.10.5. Assign a Developer to monitor End-of-Day in support of the daily maintenance of the HANDS 2.0 for the six (6) production environments. The Developer shall log in to each of the EOD servers for

OF HEALTH SERVICES

150 N. 18th Avenue, Suite 530

HANDS 2.0 partners, as needed, and review the log files, verify that the processes completed on all of the HANDS 2.0 databases, and verify that the EOD and EBT EOD processes were sent and retrieved. If the EOD process fails, then the Contractor shall notify ADHS by email about the failure.

In cases where there is a problem with the EOD processes the following, the Contractor shall:

5.10.5.1. Resolve EOD issues, including but not limited to:

5.10.5.1.1. Rerun Redemption or Caseload.

5.10.5.1.2. Investigate discrepancies with Missing data.

5.10.5.1.3. Rebuild the financial management tables.

5.10.5.1.4. Rebuild the rebate tables and other caseload and financial-related tables.

5.10.5.2. Provide transaction monitoring to maintain data integrity:

5.10.5.2.1. Ensure that the data is consistent across multiple sources of data.

5.10.5.2.2. Atomicity – that the data is uniquely identified across systems that are needed to complete the full business process.

5.10.5.2.3. Data Durability – The Contractor shall have process that provides accountability for the data so that the state of data is durable when updated for inconsistencies.

5.10.6. Monitor the following EOD processes for HANDS 2.0:

5.10.6.1. Process category changes, termination, and appointments.

5.10.6.2. Process to update participation based on…