CTR050724 A3.pdf

CONTRACT AMENDMENT

ARIZONA DEPARTMENT OF

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

CONTRACT NO.: CTR050724 AMENDMENT NO.: 3 Procurement Officer Diana Landeros

HANDS Management, Operations and Maintenance

Effective upon signature by both parties, it is mutually agreed that the Contract referenced in this amendment is amended as follows:

1. Pursuant to the Uniform Terms and Conditions, Provision Five (5), contract Changes, Section 5.1, the Contract is hereby revised with the following:

1.1. The Scope of Work is revised and replaced with this Amendment Three (3); and

1.2. The Price Sheet is revised and replaced with this Amendment Three (3).

ALL OTHER PROVISIONS SHALL REMAIN IN THEIR ENTIRETY

Contractor hereby acknowledges receipt and acceptance of above amendment and that a signed copy must be filed with the Procurement Office before the effective date

The above referenced Contract Amendment is hereby executed this _____ day of __________ 20______ at Phoenix, Arizona

(To be filled out by Procurement Office)

Contractor Signature

Contractor Signature Date

Authorized Signatory’s Name and Title

CURRIER, MCCABE & ASSOCIATES, INC

Contractor’s Name Procurement Officer Signature

3/6/23

Rachel Harpootlian, CFO Gina Corwin

Digitally signed by Gina Corwin Date:

2023.03.06 16:49:59 -07'00'

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

CONTRACT NO.: CTR050724 AMENDMENT NO.: 3 Procurement Officer Diana Landeros

SCOPE OF WORK

1. Background

1.1. HANDS Consortium Overview

1.1.1. 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. WIC is a public health nutrition program administered by the United States Department of Agriculture (USDA) Food and Nutrition Service (FNS). The Arizona WIC Program’s mission is to safeguard the health of low-income women, infants, and children up to age five who are at nutrition risk, by providing nutritious foods to supplement diets, information on healthy eating, and referrals to health care and social services,

1.1.2. The Arizona WIC Program contracts with 22 Local Agencies to provide services approximately 130,000 (monthly) WIC participants in over 100 clinic locations throughout the State of Arizona. These local agencies are comprised of County Health Departments and non-profit Health Centers,

1.1.3. In addition to Local Agency partnerships, the Arizona WIC Program contracts with approximately 550 grocery stores (vendors) for food benefit distribution. These vendors provide participants with nutritious foods, which improve health outcomes for Arizona’s children and mothers, and

1.1.4. The Arizona WIC Program is the lead State Agency in the Health and Nutrition

Delivery System (HANDS) Consortium that includes Arizona, American Samoa, Commonwealth of the Northern Mariana Islands (CNMI), District of Columbia (DC) Guam, and Navajo Nation WIC Programs. All HANDS Consortium members use HANDS as the Management Information System (MIS) to provide WIC participants with certification services, nutrition education, risk assessment, breastfeeding services, outreach services, and food benefits via online Electronic Benefits Transfer (EBT), known as eWIC.

1.2. HANDS Overview

1.2.1. HANDS is a highly scalable, multi-tiered web application implemented using the

Microsoft Model-View-Controller (MVC) framework in conjunction with a Service Oriented Architecture (SOA) and an Oracle database. The technology stack is primarily comprised of Microsoft ASP.NET MVC framework, Razor View Engine, jQuery, C#, LINQ, DevArt Oracle Data Provider, and Oracle 19c. HANDS interfaces with the eWIC system, called WIC Direct, using the 2014 version of the WIC Universal MIS to EBT Interface (WUMEI). HANDS interfaces with the eWIC system, called WIC Direct, using the 2014 version of the WIC Universal MIS to EBT Interface (WUMEI). The WUMEI is a standard interface developed and agreed upon by the USDA FNS. Each HANDS Consortium member’s HANDS environment uses the same code base, interface with WIC Direct, and infrastructure. The HANDS Technology is eleven (11) years old and will be end of life in the next few years.

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

2. Objective

2.1. Implement HANDS 2.0 by upgrading HANDS architecture and technology stack, modernize the User Interface (UI), update the interface to the eWIC System and implementing changes to HANDS functional and business requirements.

3. Scope of Work

3.1. Fixed Price, Deliverable Based Scope

3.1.1. The following sub-sections describe the deliverables that will be provided by the contractor in the execution of this amendment, and

3.1.2. Existing provisions of the contract regarding the time and material nature of maintenance and operations are modified as follows:

3.1.2.1. Staffing. For staff assigned to the fixed priced services identified in this Amendment and associated with the development of HANDS 2.0, CMA shall assign an adequate number of CMA personnel to perform the Services defined in this Scope of Work in the agreed upon timeline in the published project plan. CMA personnel shall be properly educated, trained and fully qualified for the Services they are to perform in this Scope of Work.

3.2. Project Management Deliverables

3.2.1. Project Manager,

3.2.1.1. The Contractor shall provide a full time project manager with the following:

3.2.1.1.1. Project Management Professional (PMP) certification or have attended a Project Management Institute (PMI) training within the last three (3) years,

3.2.1.1.2. Minimum of three (3)) years of experience with WIC Management Information Systems (MIS), and

3.2.1.1.3. Provide Day-to-day management of the project staff.

3.2.2. Project Work Plan,

3.2.2.1. The Contractor shall develop and maintain a project work plan using

Microsoft Project for the duration of the HANDS 2.0 Project,

3.2.2.2. All work items shall be between eight (8) to eighty (80) hour increments;

3.2.2.3. The work plan shall identify tasks, start date, end date, predecessors, durations, and resource;

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.2.2.4. Track actual progress of work compared to the project work plan; and

3.2.2.5. Workflow diagrams.

3.2.3. Project Management Plan,

3.2.3.1. The Contractor shall develop the Project Management Plan and provide to ADHS; and

3.2.3.2. The Contractor shall update the Project Management Plan based on feedback from ADHS.

3.2.4. Communications Plan,

3.2.4.1. The Contractor shall provide inputs on the HANDS 2.0 Communication Plan; and

3.2.4.2. The HAND Communication will detail who, what, when, and how communications are allowed for each stakeholder.

3.2.5. Risk and Issue Management Plan,

3.2.5.1. The Contractor shall provide inputs, review and provide feedback on the

HANDS 2.0 Risk and Issue Management Plan; and

3.2.5.2. The Contractor shall attend scheduled risk and issue management meetings.

3.2.6. Change Management Plan,

3.2.6.1. HANDS 2.0 Change Management process will be defined in the HANDS

2.0 Change Management Plan;

3.2.6.2. The Change Management Plan defines the activities, roles, and responsibilities necessary to effectively and efficiently manage and coordinate changes to project items such as scope, schedule, and cost baselines;

3.2.6.3. As change requests arise during the HANDS 2.0 project, the Contractor shall provide analysis of the proposed change in terms of schedule, cost, and quality;

3.2.6.4. All change requests will be documented within the change request log as defined in the Change Management Plan;

3.2.6.5. Change requests will be approved by ADHS and The Contractor prior to inclusion.; and

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.2.6.6. In the event of a large feature change, The Contractor shall conduct requirements elicitation and document requirements in a BRD. The BRD must be approved prior to development.

3.2.7. Training Plan,

3.2.7.1. The Contractor shall provide a HANDS 2.0 Training Plan that include training methods, materials, resources, training environments, facilities, agenda and schedules.

3.2.8. Data Conversion Plan,

3.2.8.1. The contractor shall provide a data conversion plan that will delineate the details outlined in the FNS Handbook 901 prior to system integration testing.

3.2.9. Knowledge Transfer Plan,

3.2.9.1. The contractor shall provide a knowledge transfer plan that outlines how the maintenance and operations team will be trained on HANDS 2.0.

That plan shall include but is not limited to the following items;

3.2.9.1.1. Schedules for each area\module within HANDS (plus

overall architecture training) and a timeline for the training,

3.2.9.1.2. Overview of the training tasks that will be given to trainees to show their recently-learned knowledge of the system, and

3.2.9.1.3. Integration of the M & O team in completing bugs\tasks within the main HANDS 2.0 codebase once they have satisfactorily completed the training tasks.

3.2.10. Test Plan,

3.2.10.1. The Contractor shall develop a test plan that includes test environment, test cases, types of testing, test data;

3.2.10.2. Test Plan shall describe the following; and

3.2.10.2.1. Entrance and exit criteria for System Integration Testing,

3.2.10.2.2. Schedule for testing activities,

3.2.10.2.3. Software tools required to track tests status and defects through the resolution process,

3.2.10.2.4. The process for managing the test cycles such as test scheduling, defect tracking and running test scripts, HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.2.10.2.5. The approach to developing test scripts, and

3.2.10.2.6. The process for managing testing environment and test data.

3.2.10.3. The Contractor shall provide input on the ADHS UAT plan.

3.2.11. Reporting,

3.2.11.1. Weekly Status Meeting,

3.2.11.1.1. The Contractor Project Manager shall attend a weekly meeting with ADHS Project Managers, EBT Contractor, IV&V Contractor and any other stakeholders.

3.2.11.2. Monthly Report

3.2.11.2.1. The Contractor shall provide a monthly report no more than five (5) days following the end of the month, and

3.2.11.2.2. The monthly report shall contain the following.

3.2.11.2.2.1. Previous month accomplishments,

3.2.11.2.2.2. Following month accomplishments,

3.2.11.2.2.3. Sprint Schedule and Status, and

3.2.11.2.2.4. Risks and issues.

3.3. Documentation Management Deliverables;

3.3.1. Document Repository,

3.3.1.1. All project deliverables including project management documentation, business requirements, DFDDs shall be uploaded and maintained in an ADHS SharePoint site.

3.4. Project Kickoff Meeting;

3.4.1. The Contractor shall lead a project initiation meeting with ADHS and its stakeholders as agreed to define expectations, identify deliverables, and conduct high level release planning for the HANDS 2.0 Enhancement work, and

3.4.2. The Contractor shall demonstrate a prototype of the planned upgraded HANDS 2.0 solution during the project kickoff meeting.

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.5. Architecture Upgrade Deliverables;

3.5.1. HANDS 2.0 shall be a highly scalable, multi-tiered web application implemented using the Microsoft Model-View-Controller (MVC) framework in conjunction with a Service Oriented Architecture (SOA) and an Oracle database. The technology stack is primarily comprised of latest stable version of Microsoft ASP.NET, Bootstrap 4, Docker Containerization, jQuery, C#, DevArt Oracle Data Provider, and Oracle 19c.

HANDS interfaces eWIC system, called WIC Direct, using the 2020 version of the WIC Universal MIS to EBT Interface (WUMEI). The WUMEI is a standard interface developed and agreed upon by the USDA FNS and grocery retailer community. Each HANDS Consortium member HANDS environment uses the same code base, interface with the WIC Direct, and infrastructure,

3.5.2. HANDS 2.0 architecture shall be loosely coupled tiers and layers. The architecture divides the system into loosely coupled interchangeable components, such as application core, user interface, data repositories, and other system interfaces etc.

The application core that contains the business domain information and it is surrounded by a layer that contains adapters handling bi-directional communication with other components in a generic way,

3.5.3. Adapter Layers,

3.5.3.1. There is an adapter layer that surrounds the application core. Adapters in this layer are not part of the core but interact with it. Primary adapter uses input ports to trigger the execution of use cases. The primary adapter is exposed to the REST API. Changes from Web to Mobile UI can be made without interacting with the domain model. Driving adapters are Controllers or Console Commands who are injected in their constructor with some object whose class implements the interface (port) that the controller or console command requires. The secondary adapters are called by the use cases. SQL is the secondary adapter.

Unlike the Driver Adapters, who wrap around a port, the Driven Adapters implement a Port, an interface, and are then injected into the Application Core, wherever the port is required.

3.5.4. Web User Interface (UI),

3.5.4.1. HANDS 2.0 Web UI shall introduce best built-in controls and open source frameworks. UI framework shall be built using latest Bootstrap 4 themes, SASS, and latest jQuery UI library;

3.5.4.2. Usability;

3.5.4.2.1. A key component of the UI design is usability which helps improve the end user experience. Usability of an application/product depends on the following elements, HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.5.4.2.2. Ease of Use —It supports users in completing actions accurately and easily. Users can perform tasks quickly through the easiest process,

3.5.4.2.3. Error—It supports a range of user actions and only shows an error in genuine erroneous situations. You achieve this by finding out the number, type and severity of common errors users make, as well as how easily users can recover from those errors,

3.5.4.2.4. Hands 2.0 UI design shall be developed based on Usability best practices,

3.5.4.2.5. Each Label or Error message shall be easily

understandable, real-world texts to avoid confusion to the user. These are inline error messages and an Error Summary are provided for users to easily recognize them,

3.5.4.2.6. Screens shall be designed in such a way that error prone situations are avoided such as asking for confirmation before saving the screen,

3.5.4.2.7. Consistency across the application by providing industry standard actions,

3.5.4.2.8. Side menu navigations are provided for users to navigate easily to various screens,

3.5.4.2.9. Help and documentation are easily accessible in the application at the top navigation bar,

3.5.4.2.10. Status of what is happening in application is easily viewable by providing the loading bar at top of screen, and

3.5.4.2.11. Values are auto filled into the elements wherever possible to help reduce the time, as long it does not contradict any policy.

3.5.4.3. Consistency;

3.5.4.3.1. In UX design principles, usability heuristics, which are core principles for interaction design defined since the early stages of large-scale application design, and Consistency is the one of the key fundamental principles. Consistency improves the application by providing standard look, feel, and functions a in similar way with similar elements across multiple devices and platforms to keep things simple for the user and minimize the level of effort to learn or get trained

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 to do their work. User interfaces that aren’t consistent often yield confused and frustrated users and can drive even the most promising products to failure, and

3.5.4.3.2. HANDS 2.0 UI shall be designed based on UI Consistency best practices which reduces the learning curve and allows user to make fewer mistakes.

3.5.5. Docker Containerization,

3.5.5.1. Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take up less space than VMs (container images are typically tens of MBs in size), can handle more applications and require fewer VMs and Operating systems; and

3.5.5.2. Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.

Application containerization is an OS-level virtualization method used to deploy and run distributed applications without launching an entire virtual machine (VM) for each app. Multiple isolated applications or services run on a single host and access the same OS kernel.

Containers work on bare-metal systems, cloud instances and virtual machines, across Linux and select Windows and Mac OSes.

3.5.6. Data Access Upgrade,

3.5.6.1. HANDS 2.0 shall use a Windows Communication Foundation (WCF)

Web service or Web API) to separate the service layer from the UI layer and can be deployed on different servers and scaled differently. With WCF, HANDS 2.0 can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by Microsoft Internet Information Services (IIS), or it can be a service hosted in the application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as Extensible Markup Language (XML), or as complex as a stream of binary data; and

3.5.6.2. WCF supports many different transport protocols. Messages can be sent on any of several built-in transport protocols and encodings. The most common protocol and encoding is to send text encoded SOAP messages using the Hypertext Transfer Protocol (HTTP) for use on the World Wide Web. Messages can be encrypted to protect privacy and require users to authenticate themselves before being allowed to

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 receive messages. Security can be implemented using well-known standards such as SSL or WS-Secure Conversation.

3.5.7. ASP .NET Web API,

3.5.7.1. HANDS 2.0 shall use ASP .NET Web API, which is an extensible framework for building HTTP based services that can be accessed in different applications on different platforms such as web, windows, mobile etc. It works the same way as ASP.NET MVC web application except that it sends data as a response instead of html view. Web API only supports HTTP protocol. Each of the HANDS 2.0 functional modules will be created as separate APIs along with a shared API which will be used for common functionality;

3.5.7.2. GET requests over collection resources can potentially return many items. GET requests are used to retrieve and request data from a specified resource in a server. Hence the web API will be designed to limit the amount of data returned by any single request;

3.5.7.3. An upper limit will be imposed on the number of items returned, to help prevent Denial of Service attacks. Additionally, GET requests that return paginated data will include metadata that indicate the total number of records available in the collection;

3.5.7.4. A similar strategy of using a query string value for sort parameter with a field name to sort data as it is fetched will be implemented. However, this approach can have a negative effect on caching because query string parameters form part of the resource identifier used by many cache implementations as the key to cached data;

3.5.7.5. Give all optional parameters in query strings meaningful defaults. For example, set the limit parameter to 10 and the offset parameter to 0 if you implement pagination, set the sort parameter to the key of the resource if you implement ordering, and set the fields parameter to all fields in the resource if you support projections;

3.5.7.6. A resource may contain large binary fields, such as files or images. To overcome problems caused by unreliable and intermittent connections and to improve response times, consider enabling such resources to be retrieved in chunks. To do this, the web API should support the Accept- Ranges header for GET requests for large resources. This header indicates that the GET operation supports partial requests. The client application can submit GET requests that return a subset of a resource, specified as a range of bytes;

3.5.7.7. A web API must return messages that contain the correct HTTP status code to enable the client to determine how to handle the result, the appropriate HTTP headers so that the client understands the nature of

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 the result, and a suitably formatted body to enable the client to parse the result;

3.5.7.8. The code that implements an HTTP operation should provide comprehensive exception handling rather than letting uncaught exceptions propagate to the framework. If an exception makes it impossible to complete the operation successfully, the exception can be passed back in the response message, but it should include a meaningful description of the error that caused the exception. The exception should also include the appropriate HTTP status code rather than simply returning status code 500 for every situation;

3.5.7.9. When a client application retrieves an object, the response message can also include an ETag (Entity Tag) which helps to optimize query processing. An ETag is an opaque string that indicates the version of a resource; each time a resource changes the ETag is also modified. This ETag should be cached as part of the data by the client application;

3.5.7.10. A request that might take a long time to process should be performed without blocking the client that submitted the request. The web API can perform some initial checking to validate the request, initiate a separate task to perform the work, and then return a response message with HTTP code 202 (Accepted). The task could run asynchronously as part of the web API processing, or it could be offloaded to a background task;

and

3.5.7.11. The web API should also provide a mechanism to return the results of the processing to the client application. You can achieve this by providing a polling mechanism for client applications to periodically query whether the processing has finished and obtain the result or enabling the web API to send a notification when the operation has completed.

3.5.8. DevArt Upgrade,

3.5.8.1. HANDS 2.0 shall use latest version of Devart dotConnect for database connectivity. The dotConnect is an enhanced data connectivity solution built over ADO.NET architecture and a development framework with several innovative technologies. The dotConnect for Oracle is a high-performance ORM enabled data provider for Oracle that builds on ADO.NET technology to present a complete solution for developing Oracle-based database applications. It also supports a wide range of Oracle-specific features, such as Advanced Queuing, Alerts, Pipes, Direct Path Loading, Change notifications, Transparent Application Failover, REF cursors, objects, packages etc. dotConnect for Oracle also supports Oracle 7 – 19c, .NET Core and Entity Framework Core.

dotConnect for Oracle offers two connection modes to the Oracle server:

connection through the Oracle Call Interface and direct connection over

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

TCP/IP. Applications written with dotConnect for Oracle are easy to deploy, do not require installation of Oracle Client Software, and tend to be faster than those that use other data connectivity solutions.

dotConnect for Oracle combines connected and disconnected data access models in single OracleDataTable component, which allows you to design more flexible application architecture and use full power of data binding.

3.5.9. Error Logging,

3.5.9.1. The primary logging will be to HANDS 2.0 database. However, if the system is unable to write to the database due to any communication failure or network errors, there needs to be an alternate way to persist the error and attempt again before writing to the secondary log. To achieve this, HANDS 2.0 will use a message queue (MSMQ) configured on the EOD server. MSMQ uses store-and-forward to communicate with remote machines. Messages are stored locally, and the MSMQ service repeatedly attempts to deliver them to the destination queue on the remote machine. All error messages will be initially written in the local queue on the application server and then forwarded to the remote queue on EOD server. Due to this, there is no instant feedback if the message communication failed to the remote server. As a result, after the write, system will verify by peeking in the remote server queue to check if the recently written error message exists; and

3.5.9.2. There will be a windows service running on the EOD server that will frequently check for any new error messages in the queue. Once the error message has been written to the remote queue, the Windows service will read the new message and write to the error log table in the database. However, if the database is still unavailable, then the windows service will write the error message to the EOD server event viewer. The reason for writing to EOD Server event viewer is to avoid having to check each application servers’ local logs. If the error message write to remote message queue fails, then the system will log it in the application server’s local event logs as a last resort.

3.5.10. Reporting,

3.5.10.1. Reports are an integral part of any application as they provide an insight into the data and helps in decision making or future planning. HANDS

2.0 shall continue to use SSRS for reporting as there is no built-in control available in .Net Core to render these reports;

3.5.10.2. The Contractor shall develop and host the reports application separately and then embed them in HANDS 2.0 using iframe; and

3.5.10.3. The Contractor shall be using a third party (Syncfusion) report viewer control. The report viewer is a visualization control to view the Microsoft

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

RDL/RDLC format-based report on a web page, and it is powered by HTML5/JavaScript.

3.5.11. Reducing Session Objects,

3.5.11.1. HTTP is a stateless protocol. By default, HTTP requests are independent messages that do not retain user values. Web applications use different approaches to preserve user data between requests.

Session state is one such approach which uses a store maintained by the app to persist data across requests from a client. These values can be stored for the duration of the user’s session. In most cases, they are stored in server memory, although options exist for using persistent and/or distributed storage mechanisms. Storing session data in server memory provides the fastest access. However, storing large amount of session data in server memory can lead to higher memory utilization and excessive paging resulting in performance degradation or run out of memory causing errors. Similarly, if we use external stores to persist session data, there are overhead costs involved in serializing and deserializing the objects and network latency leading to slower response times. Additionally, IIS prevents more than one thread from writing to the session at a time, and it often does this by locking the session. This can cause severe problems in some cases, and merely poor performance in others. So, we should prevent concurrent sessions where possible. It is also ideal that we keep only the relevant data or lightweight objects in session instead of storing every large object in it for future use. Also, Destroy sessions upon timeout, logoff, browser close or log-in from a separate location to free up memory. Session management in ASP.NET Core is implemented via a pluggable component, or "middleware" and is available in a Nuget package called Microsoft.AspNet.Core.Session.

In-memory storage is also available as an optional package called Microsoft.Extensions.Caching.Memory.

3.5.12. Decoupling HTTPContext from Service Layer,

3.5.12.1. The current HANDS implementation uses HttpContext to persist user information such as user id, username, logged in clinic etc. and retrieve them across service calls based on the session. HttpContext is an object that wraps all http related information into one place. HttpContext object will be constructed newly for every request received by asp.net runtime and this object will hold current request specific information like Request, Response, Server, Session, Cache, User etc. which is used during request processing. A new HttpContext object is created at the beginning of a request and destroyed when the request is completed.

Using HttpContext in the service layer creates a dependency on the UI layer and increases tight coupling which is not ideal. HANDS 2.0 will use Web API and the service calls will be stateless. Hence HttpContext will not be used in the service layer. Instead, the base Object can have the

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 necessary properties for user related common information and can be passed while calling the service.

3.5.13. Implementing Application Secrets,

3.5.13.1. HANDS 2.0 shall utilize Secrets Manager. The Secret Manager tool abstracts away the implementation details, and the values are stored in a JSON configuration file in a system-protected user profile folder on the local machine. For production, it’s recommended to use the azure key vault to store and load sensitive app configuration values. Azure Key Vault is a cloud-based service that assists in safeguarding credentials, cryptographic keys and other secrets used by apps and services.

3.5.14. ITextSharp upgrade for .NET Core

3.5.14.1. iText is a library that allows us to create and manipulate PDF documents. It enables developers looking to enhance web- and other applications with dynamic PDF document generation and/or manipulation. Developers can use iText to:

3.5.14.1.1. Serve PDF to a browser,

3.5.14.1.2. Generate dynamic documents from XML files or databases,

3.5.14.1.3. Use PDF's many interactive features,

3.5.14.1.4. Add bookmarks, page numbers, watermarks, etc, and

3.5.14.1.5. Add digital signatures to a PDF file,

3.5.14.2. HANDS system uses iTextSharp libraries to generate checks as PDF documents while printing. Considering HANDS 2.0 may still have to print checks for EMO, it’s essential to retain the check printing functionality. However, iTextSharp has already reached EOL and replaced with iText7.

3.5.15. Data Conversion and Migration

3.5.15.1. Given there will be significant modifications to the HANDS application data model to support HANDS 2.0, a data conversion process will be developed to properly transition data from the HANDS database to the HANDS 2.0 database during scheduled deployments of HANDS 2.0;

3.5.15.2. Given HANDS 2.0 will be deployed in geographic phases over time, a data synchronization process will be developed to keep application data synchronized between HANDS 2.0 database and HANDS database until all phased roll outs are complete, and HANDS can be formally retired.

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.6. HANDS 2.0 Environments;

3.6.1. The Contractor shall support ADHS in setting up the HANDS 2.0 Dev, QA, UAT, Training and Production environments including application servers, database servers, connection to the eWIC system, and networking, and

3.6.2. Training and Production environments shall include Arizona, American Samoa, CNMI, DC, Guam, and Navajo Nation.

3.7. Functional Enhancements;

3.7.1. The Contractor shall provide functional enhancements for the following,

3.7.1.1. WIC Services Search;

3.7.1.1.1. Enhanced search capabilities are needed to better indicate additional information to improve system usability,

3.7.1.1.2. The Program Integrity search shall be modified to display records in an alternate font or color depending on the “resolved” disposition of the record, and

3.7.1.1.3. The WIC Services search results shall be improved to include alternate text color for deceased clients, inclusion of the last date to use and the ability to add family contact numbers.

3.7.1.2. Enhanced Active Records Functionality;

3.7.1.2.1. The Active Record shall be modified to include the “mid-cert” date, a complete screen icon, color change for clients who have been disqualified/terminated due to age and add certification end date to hovering information. When hovering over the client tabs, icons shall appear, and the Mid-cert health check icon will be renamed to Mid- Certification.

3.7.1.3. Enhanced Appointment Scheduling;

3.7.1.3.1. Change to the group scheduler screen, which lists the clients scheduled for the group, to add a hyperlink on the client ID which, when clicked, will redirect the user to the associated client screen,

3.7.1.3.2. The current SMS texting functionality shall be enhanced to include a system-generated auto phone call "next appointment reminder", HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.7.1.3.3. The system shall be modified to stay on the selected date after you cancel a group. Currently, when you need to delete a group, the system re-directs you back to the current calendar day. For example, if a user opens up groups at 1pm and 3pm from July 1st until December 31st, the user needs to go through and delete a few days in August and October due to coverage the calendar resets itself to today’s date every time you cancel a group,

3.7.1.3.4. The current SMS texting functionality shall be modified to incorporate a "confirmation" feature on the text reminders so clients can confirm/reschedule their appointments and the clinics can better manage staff time,

3.7.1.3.5. HANDS shall be modified to add a dialogue box that asks if you want to cancel the appointment when you terminate a certification. Users will have the option to Keep or Cancel future appointments when recertifying a PG mom with new baby, for example,

3.7.1.3.6. HANDS shall be modified to allow users to schedule a family that has an Authorized Rep but not a client in the scheduling function,

3.7.1.3.7. The SMS texting and email appointment reminder

functionality shall be modified to have the Spanish translation available for text and email appointment reminders from HANDS,

3.7.1.3.8. To better promote Group Nutrition Discussions in the scheduling module, system shall be modified to make groups visible on the scheduler as the default view rather than having to check the "Show Groups" box. Instead, having a checkbox to "Hide Groups" would be preferred,

3.7.1.3.9. The system shall be enhanced such that clients can be scheduled in group appointments through the 'Pending Services' module in the clients’ record. Currently group appointments can only be scheduled through the Scheduling tab,

3.7.1.3.10. An indicator shall be added to the Appointments tab to indicate where the scheduled appointment for the family/client is scheduled. This particular issue occurred when a client was transferring to another clinic but the record had not been pulled into the new clinic yet. Since the family was still attached to the old clinic, they had difficulties

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 determining why the family's appointment was not showing on their schedule,

3.7.1.3.11. An enhancement to expand 'Scheduled Group Nutrition

Discussion Appointments' section when group appt is scheduled such that if clients in the family are scheduled for a Group Nutrition Discussion, the Scheduled Group Nutrition Discussion Appointments section should expand by default when the user navigates to the Appointments screen. This enhancement shall be similar to how the Schedule Appointments section is expanded by default if any clients in the family are scheduled for an Appointment,

3.7.1.3.12. The system shall be modified to allow more than one reminder option. This modification shall permit staff the ability to send a combination of email, text, and phone reminders so clients receive multiple reminders,

3.7.1.3.13. The SMS testing functionality shall be modified to create a system-generated text reminder for LDTU of benefits, suggesting 5-15 days before LDTU,

3.7.1.3.14. Similar to the above modification, a system-generated email reminder for LDTU of benefits shall be created,

3.7.1.3.15. The SMS texting functionality shall be modified to also send text message reminders to clients who attend walk-in/open access clinic. These clients do not have set appointments but are in an active certification and need to be reminded to come into the clinic as they are due for food benefits,

3.7.1.3.16. When using the find appointments functionality in the client’s file on the appointments tab, the day of the week (i.e. Wednesday) shall be added in addition to the date and time,

3.7.1.3.17. A helpful hint shall be added when hovering over the Heart icon in the client’s record. When hovering, the system shall show the date and time of next scheduled High Risk appointment,

3.7.1.3.18. HANDS shall be modified such that after clicking the “Add” button on the Appointment Sheet to add an appointment, the user will type in Family ID and then be able to hit Enter on their keyboard to search for the family rather than having to use the mouse to click “Search”, HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.7.1.3.19. Currently, the Active record shows next appointment, however, the date appears ONLY for individual appointments NOT for group appointments. Group appointment dates shall be added, and

3.7.1.3.20. Any of the virtual appointments provided by Agency staff to clients under regular clinics under the same local agency will be scheduled at Virtual Clinic level. Objective is to avoid confusion among staff, so that they do not intermingle virtual services among regular clinics under a local agency.

3.7.1.4. Enhanced Assessments Features;

3.7.1.4.1. Risk indicators will be updated to improve readability including the high-risk heart icon changing when a new code is added during the same certification and medium risk codes will be specified with a yellow heart icon. On the Assessment screen, consistency of the display order will be implemented, the bolding of high-risk codes and ready to feed options will be added. The assessment screen will be expanded to include customizable immunizations and food insecurity questions. Changes will be made to existing standard questions to include ready to feed options and infant formula to water will allow for answers with decimals.

3.7.1.5. Enhanced Breastfeeding Functionality;

3.7.1.5.1. HANDS Breastfeeding functionality shall be expanded to allow issuance of breast pump to an active C1 category. A notification will be added to change the client category when they are no longer reporting breastfeeding activity. Finally, the Breast Pump icon set will be updated to show for all family members.

3.7.1.6. Enhanced Client Portal Functionality;

3.7.1.6.1. To better serve clients via the AZ Participant Portal, WIC staff will be allowed to add upload links or PDF resources on the client record for display to the client in the portal.

Appointment scheduling and rescheduling will be made available to the client.

3.7.1.7. Enhanced Income Eligibility;

3.7.1.7.1. HANDS will be modified to support Cross Edits Between

Certification and Income Page for PG Category, making family adjunctively eligible. Currently staff can say that a

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 mom is PG when she is on Medicaid, but you can certify her as a post-partum woman.

3.7.1.8. Enhanced Financial Processing;

3.7.1.8.1. Modifications will be made that update Breast Pump actual expenditures entered in the Financial Profile screen for both food and NSA will populate in the corresponding boxes (A & B) on line 42 of the FNS 798. In addition, the “Average Migrant Participation (July – June)” (Line 43) of the FNS798 will be automated. The migrants who participate from July 1 through June 30, will be averaged (total migrants for 12 month/12) and reported on the July 798, which is submitted on August 30th of each year,

3.7.1.8.2. Modifications will be made that combine the Local Agency NSA Expenditures vs. Budget Report with a section that shows the state expenditures and then calculates the combined total dollars spent and the percentages spent agency in the cost categories. The cost category totals would match those submitted on the 798A,

3.7.1.8.3. The ability to upload monthly Local Agency Contractor

Expenditure Report (CER) Excel spreadsheets into the system shall be accomplished,

3.7.1.8.4. The Finance Modules will allow for a daily import (into the database) all redemption data, etc. At any one time, the financial information in the models will be aligned with CDP/DATA DIRECT redemptions of the previous day. This allows for ASAP Report upload and allow for reconciliation.

An option for GAD document to be entered in Cash flow will be created,

3.7.1.8.5. The capability to add LOC/GAD PDF documents as

attachments to the cash management detail transactions will be added. Currently the system can scan paper documents, but does not allow for electronic upload directly,

3.7.1.8.6. The system will automatically pull any manual adjustments, program income, and Breast Pump expenses entered into the Cash Flow screen into the FNS798 portion to avoid duplicate data entry and potential errors. Automate information so it is entered once from the Cash Flow screen to the appropriate month and line on the FNS798 Report,

3.7.1.8.7. Program income Post-payment Vendor Collection, Participant Collections, and other credits for both Food and

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

NSA into both Grants and Cash Flow screens and then report/show on the FNS 798/Cash Flow Analysis Screen by month. This information shall be automated so that users can enter this data once from the Cash Flow screen to the appropriate month and line on the FNS798 Report,

3.7.1.8.8. Users manually enter information into the transactions for

40a-c on the Cash Flow Screen, and then must export the FNS798 Report and manually entered the same information on FNS798 page 2. With this, the FNS798 Report will be automated, and lines 40a-c will have the correct amounts shown on report,

3.7.1.8.9. Annual Federal Net Outlays (Line 41) is currently calculated incorrectly. The values do not present correctly on FNS 798 Monthly and Closeout Reports. This will be corrected,

3.7.1.8.10. For Rebate billing, the system will be enhanced to allow users to enter due date and posting date. Further, the auto-calculated due date will be removed so that the system does not show late payments incorrectly. These changes will auto feed to 798-CashFlow analysis, giving user control versus auto filling,

3.7.1.8.11. It has been reported that the eWIC Benefits Paid Report’s formatting is inconsistent and causes format issues for trying to combine over time, even CSV format is not user friendly. This report will be analyzed and adjusted to be more useful,

3.7.1.8.12. In Agency Profile/Agency Budget screen, when entering budget annual cost summary, there are issues with rounding on page 3 of 798(A). Also, in Agency budget, there is currently a single tab to enter expenses. This will be expanded to 4 tabs to enter data quarterly and another for the summation of all 4 quarters. This also entails the ability to create a 798A that is quarterly. Not all State agencies may not want this capability, therefore a configurable setting for this new quarterly ability will be created to turn it on/off as needed. The Forecasting model, Annual Budget Factors, and other impacted reports will need to be adjusted to quarterly and/or monthly Annual Budget Factors (as needed),

3.7.1.8.13. In support of the quarterly enhancements option above, Finance/Grants/Cash Flow/Annual Financial Factors screens are still using average 12-month data from before.

Setting values for Food Package benefit, redemption %, HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 case load percentage, and forecasting off that for Gross Outlays and Rebates and being able to select the quarterly option. Also, the current closed month logic will be replaced with new closed month definition of 60 days as opposed to a “closed” month. This is the current month minus 2 months to ensure that benefit redemption is closed,

3.7.1.8.14. More user-driven control on when a rebate is received and updated is applied to 798 shall be included. This value will auto-feed to Finance-FNS798-CashFlow analysis - Rebate Received-Monthly Total line when the screen is refreshed, not when saved and closing the month,

3.7.1.8.15. Finance/Automated Rebates, when receive payment on

10th of Feb, applies to Feb, required that the amount of payment will be added to estimate rebates for February to override previous forecast, then flow into the 798. FNS 798 changes flow to the report or get added to Financial Profile page Finance/Grants/Cash Flow/Financial Profile,

3.7.1.8.16. Currently, the Financial Profile, Grants Management, Food

Cost Current YTD to be received, calculation is not working.

GRP adjustment capability needs to be added so result will be zero. This defect will be corrected,

3.7.1.8.17. Enhancements to incorporate the capability to input and track data related to Contractor Expenditure Reports (CERs). This new functionality will include enhancements to existing screens, as well as new ones (where needed).

New database tables will also be added (as needed). The new functionality will also include the ability to indicate CERs are paid, thus enabling the 798A to work correctly,

3.7.1.8.18. Enhancements to support the ability to add other programs paid from WICADMIN (i.e. Special Projects, QASS, etc.)

shall be incorporated,

3.7.1.8.19. Enhancements to support the entry of daily WIRE

information and checks against eWIC benefits paid report.

Users will be able to enter the daily WIRE and the system will compare this data against the eWIC benefits from the prior day,

3.7.1.8.20. The current three (3) year weighted average function is not working completely as required. Enhancements will be made to make this more flexible. Primarily, enable the ability to select one (1), two (2), or three (3) years for forecasting and change the definition of closed month as

HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007 previously stated to a new closed definition of sixty (60) days closed. Participation data is confirmed at the second month or weigh the years differently i.e., 60% on 2020 and 40% on the year before. FNS also uses three (3) year weighted average function,

3.7.1.8.21. A new report shall be developed entitled “CER Report”.

When CERs are input into the system, similar to the 798, ADHS needs the ability to report on those CERs up until a point of time. For the report criteria, dates will be able to be selected versus a point in time,

3.7.1.8.22. Enhancements to support the ability to create a cover letter with letterhead for Rebate Billing Distribution. This workflow will be automated so that additional review process can be eliminated,

3.7.1.8.23. The 798 Report, Participation, and eWIC Benefits Paid reports, will be enhanced to allow users to generate the report for only the time period that is being reported according to federal requirements, not only be as of the day the report is requested (today),

3.7.1.8.24. The 798 Report will be updated to print Landscape instead of Portrait,

3.7.1.8.25. A new report will be developed entitled “Monthly Outlay File & Food Package Costs Report”. This report will be used to monitor input into 798 Report,

3.7.1.8.26. A new report will be developed entitled “Rebate Tracking

Report”. This report will aid in monitoring input into 798 Report,

3.7.1.8.27. The Migrant Report will be updated. Currently, monthly July-

June, not on FFY, needs to be an average for reporting, thus it requires staff to perform manual manipulation of the numbers to correct. This will be corrected,

3.7.1.8.28. On the Annual Budget Factors dialog, the calculation logic will be changed to take the current calendar date + sixty (60) days and use that month’s information plus the previous month before that month’s closed months. For example, for the 3-month Redemption Factor Timeframe when working in February, the calculation will use December, November, and October, HEALTH SERVICES

OFFICE OF PROCUREMENT

150 N 18th Ave., Ste. #530 Phoenix, Arizona 85007

3.7.1.8.29. The Annual Budget Factors dialog (and others as needed) will be standardized to have the terms/labels used be consistent across the entire Finance Module,

3.7.1.8.30. On the Forecast dialog, ADHS is able to make adjustments in HANDS to account for changes in women, infant, and children numbers. However, HANDS does not currently take the changes into account when forecasting new months within the Financial module. The ability to enter adjustments into the Forecast module and have them impact future projected months will be created,

3.7.1.8.31. Special formula is sometimes issued and is not redeemed which could impact calculation. If we consider formulas which are redeemed to a greater extent and some which are not redeemed that often and system is using both in redemption rate calculation.