RFO No. HHS0014612v2 Page 1 of 59

Version 2.30

Revision Date 04/28/2025

Cecile E. Young, Executive Commissioner

Request for Offer (RFO) for

Take Charge Texas Support Services

RFO No. HHS0014612v2

Date of Release: November 5, 2025

Responses Due: See Section 3.1 for Schedule of Events

NIGP Class/Item Codes

Class/ Item

Code

AIS

Description

204-29* Yes Data/File Security Hardware/Software, to Include Encryption

209-38* Yes Database Software, Mainframes and Servers

209-54* Yes Internet, Web Site and Mobile Application Software, Mainframes and Servers

915-96* Yes Web Page Design, Management and Maintenance Services

920-24* Yes Data Conversion Services

920-64* Yes System Implementation and Engineering Services

920-66* Yes System, Network, Database, DBA Administration Services

920-91* Yes Training, Computer Based, Software Supported

*The State of Texas has marked certain codes for information technology and related commodities and services as Automated Information System (AIS).

RFO No. HHS0014612v2 Page 2 of 59

Revision Date 04/28/2025

Table of Contents

Article I. Introduction, Definitions, and Authority

1.1 Introduction

1.2 Definitions

1.3 Authority

Article II. Scope of Work

2.1 Description of Services

2.2 Contract Phases

2.3 Phase I – Transition

2.3.1 Transition Deliverables

2.3.2 Key Personnel

2.3.2.1 Account Manager

2.3.2.2 Replacement of Key Personnel

2.4 Phase II – Operations

2.4.1 Scrum Methodology – Agile-Focused Sprints Maintenance, Service Requests, Fixes and Defects

2.4.1.1 Sprint Team Composition

2.4.1.2 Sprint Team Contractor Roles

2.4.1.3 Sprint Activities

2.4.1.4 Sprint Deliverable Acceptance Standard

2.4.2 General Service Requirements

2.4.2.1 Planning and Reporting

2.4.2.2 Informational Requests

2.4.3 Development Modernization and Enhancement Services

2.4.4 Service Request Ticketing Process

2.4.4.1 Levels of Support

2.4.4.2 Incident

2.4.4.3 Service Requests

2.4.4.4 Services Request Process

2.4.4.5 Priority Levels, Service Times

2.4.5 Security Requirements

RFO No. HHS0014612v2 Page 3 of 59

Revision Date 04/28/2025

2.4.6 Key Performance Measures and Associated Remedies

2.4.7 Accessibility Requirements

2.5 Phase III – Turnover

2.5.1 Turnover Plan

2.6 Supplemental Services

2.6.1 Supplemental Services Cost Proposal

2.7 Disaster Recovery Test

2.8 Reduced Services

2.9 Hours of Operation

2.10 Invoicing

2.11 Contract Award, Term, and Historical Compensation

2.11.1 Contract Award and Execution

2.11.2 Contract Term

2.11.3 Historical Compensation

2.12 Data Use Agreement and Security Privacy Inquiry

2.13 No Guarantee of Volume, Usage, or Compensation

Article III. Administrative Information

3.1 Schedule of Events

3.2 Ambiguity, Conflict, or Discrepancy

3.3 Inquiries

3.3.1 Sole Point of Contact

3.3.2 Prohibited Communication

3.3.3 Exception to Sole Point of Contact

3.3.4 Solicitation Questions

3.4 Pre-proposal Conference

3.4.1 Attendance

3.4.2 Conference Logistical Information

3.4.3 Questions at Pre-Proposal Conference

3.5 Solicitation Response Composition

3.5.1 General Information

3.5.2 Page Limit and Supporting Documentation

RFO No. HHS0014612v2 Page 4 of 59

Revision Date 04/28/2025

3.5.3 Discrepancies

3.5.4 Exceptions

3.5.5 Assumptions

3.5.6 Binding Offer

3.6 Solicitation Response Submission and Delivery

3.6.1 Deadline

3.6.2 Submission Option

3.6.3 Submission Checklist

3.6.4 Labeling and Delivery for USB Submission and Other Materials

3.6.5 Modifications and Withdrawals

3.7 Procurement Library

Article IV. Solicitation Response Evaluation and Award Process

4.1 Conformance with State Law

4.2 Best Value Determination

4.2.1 Selection Methodology

4.2.2 Minimum Qualifications

4.2.3 Initial Compliance Screening

4.2.4 Written Solicitation Response Evaluation

4.2.5 Written Response Evaluation Criteria

4.2.6 Best and Final Offer (BAFO)

4.2.7 Final Written Response Score

4.2.8 Summary of Best Value Determination

4.3 Questions or Requests for Clarification

Article V. Narrative/Technical Proposal

5.1 Narrative Proposal

5.1.1 Executive Summary

5.1.2 Key Staffing Profile

5.2 Technical Proposal

5.2.1 Draft Project Plan

5.2.2 System Availability and Capacity

5.2.3 System Administration, Support, and Maintenance

RFO No. HHS0014612v2 Page 5 of 59

Revision Date 04/28/2025

Article VI. Required Respondent Information

6.1 Company Information

6.1.1 Company Narrative

6.1.2 Company Profile

6.2 Authorization to Conduct Business in Texas

6.3 References

6.4 Major Subcontractor Information

6.5 Affirmations and Certifications

6.6 Other Reports

6.6.1 Dun and Bradstreet Reports

6.6.2 Financial Statements and Financial Solvency

6.6.3 Alternate Report

6.7 Corporate Guarantee

6.8 HUB Subcontracting Plan

Article VII. Cost Proposal

7.1 Cost Proposal

Article VIII. General Terms and Conditions

8.1 General Conditions

8.1.1 Changes, Modifications, and Cancellation

8.1.2 Offer Period

8.1.3 Costs Incurred

8.1.4 Contract Responsibility

8.1.5 Public Information Act - Respondent Requirements Regarding Disclosure

8.1.6 Respondent Waiver – Intellectual Property

8.1.7 Standards of Conduct for Vendors

8.1.8 Disclosure of Interested Parties

8.2 Insurance

8.2.1 Required Coverage

8.2.2 Alternative Insurability

8.3 Protest

Article IX. List of Exhibits

RFO No. HHS0014612v2 Page 6 of 59

Table of Tables

Table 1 – Contractor’s Sprint Team Roles and Responsibilities

Table 2 – Levels of Support

Table 3 – Priority Levels and Service Times

REMAINDER OF THIS PAGE INTENTIONALLY LEFT BLANK

RFO No. HHS0014612v2 Page 7 of 59

Revision Date 04/28/2025

ARTICLE I. INTRODUCTION, DEFINITIONS, AND AUTHORITY

1.1 INTRODUCTION

The Department of State Health Services (DSHS), by and through the Texas Health and Human

Services Commission (HHSC), is seeking a qualified vendor to provide support services and maintenance for the DSHS Take Charge Texas (TCT) application hosted in Texas Department of

Information Resources – Data Center Services.

DSHS is required, pursuant to Texas Health and Safety Code Sections 81.041, 81.043 and 81.044 to maintain a repository and report on all infectious diseases in Texas. TCT is an online system for

Clients, DSHS staff, providers, and pharmacists across Texas. TCT allows Clients and DSHS staff to reduce paperwork and clerical tasks that take time away from connecting Clients to services.

TCT allows Clients to complete one (1) application and upload supporting documents one (1) time for several programs, instead of completing an application for each service or benefit. TCT includes an agency portal, pharmacy portal, and Client portal. The Contractor will maintain and support TCT.

HHSC PCS will administer the procurement process for this Solicitation, which includes RFO publication, handling of communications from vendors, as well as managing the receipt of

Solicitation Responses for review and evaluation.

To be considered for award, a Respondent must execute Exhibit A, HHS Solicitation

Affirmations, and provide all other required information and documentation as set forth in this

Solicitation.

Information regarding DSHS and its programs is available online and can currently be accessed at HIV/STD Program | Texas DSHS or https://www.dshs.texas.gov/hivstd.

1.2 DEFINITIONS

Refer to Exhibit B, Health and Human Services (HHS) Uniform Terms and Conditions

(UTC) – Vendor, Version 3.4, Exhibit C, Health and Human Services (HHS) Additional

Provisions, Version 1.0, and Exhibit D, HHS Data Use Agreement (DUA), Version 8.5 for additional definitions.

As used in this Solicitation, unless a different definition is specified or the context clearly indicates otherwise, the following terms and conditions have the meanings assigned below:

“Acceptance Criteria” means the criteria that must be met by Contractor for a Deliverable to be considered completed under the terms of the Contract.

“Addendum” means a written clarification or revision to this Solicitation issued by HHSC PCS and posted to the ESBD.

https://statutes.capitol.texas.gov/Docs/HS/htm/HS.81.htm#81.041 https://statutes.capitol.texas.gov/Docs/HS/htm/HS.81.htm#81.043 https://statutes.capitol.texas.gov/Docs/HS/htm/HS.81.htm#81.044 https://www.dshs.texas.gov/hivstd https://www.dshs.texas.gov/hivstd

RFO No. HHS0014612v2 Page 8 of 59

Revision Date 04/28/2025

“Award Consideration (AC) Documents” means documents Respondent must submit as part of the Solicitation Response to be considered for negotiations or award.

“Business Day” means Monday through Friday, 7:30 am – 5:30 pm CT, excluding all days designated as “All agencies closed” on the State Holiday Schedule(s) posted on the Texas State

Auditor’s Office website located at www.sao.texas.gov.

"Business Hour" means a clock hour during the standard business hours of a Business Day.

“Calendar Day” includes Saturday, Sunday, a skeleton crew day, and a national, State, and optional holiday listed in Section 662.003 of the Texas Government Code.

“Client” means individual receiving services through agencies throughout the State of Texas.

“Contract Term” means the period of time beginning with the commencement date or Effective

Date of a Contract and ending when the Contract expires in accordance with its terms, or when it has been terminated.

“Defect” means a failure of TCT to comply with the specifications set forth in the Contract or a condition in TCT that does not meet the required specifications or end-user expectation (e.g., an error in coding or logic that causes TCT to malfunction or to produce incorrect or unexpected results).

“DSHS” means the Department of State Health Services.

“Enhancements” means any addition of new features, capabilities, such as optimizing application functionality and workflows.

“ESBD” means the Electronic State Business Daily, the electronic marketplace where State of

Texas bid opportunities over $25,000 are posted. The ESBD may currently be accessed at http://www.txsmartbuy.gov/esbd.

“Extraordinary Event” means a circumstance in which an event or discrete set of events has occurred or is planned with respect to the operations of DSHS that results or will result in a reduction in the nature or volume of the Services that DSHS will require from the Contractor.

“Final Written Response Score” refers to the final scoring of the written response as documented in the Solicitation.

“Fully Functional Feature” means a capability within new or existing software that is developed and implemented in a manner that is fully functional and deployable and meets the business and technical requirements of that feature as determined by DSHS.

“HHSC” means the Health and Human Services Commission.

“HHSC PCS” means Procurement and Contracting Services (PCS), a division of HHSC.

http://www.sao.texas.gov/ https://statutes.capitol.texas.gov/Docs/GV/htm/GV.662.htm#662.003 https://texas-sos.appianportalsgov.com/rules-and-meetings?$locale=en_US&interface=VIEW_TAC_SUMMARY&queryAsDate=04%2F14%2F2025&recordId=208793 https://texas-sos.appianportalsgov.com/rules-and-meetings?$locale=en_US&interface=VIEW_TAC_SUMMARY&queryAsDate=04%2F14%2F2025&recordId=208793 http://www.txsmartbuy.gov/esbd

RFO No. HHS0014612v2 Page 9 of 59

Revision Date 04/28/2025

“HUB” means Historically Underutilized Business, as defined by Section 2161.001(2) of the

Texas Government Code.

“HUB Subcontracting Plan” or “HSP” means written documentation regarding the use of subcontractors, which is required by Section 2161.252 of the Texas Government Code, for a purchase with an expected value of $100,000 or more when the State agency has determined subcontracting opportunities are probable. The HSP subsequently becomes a provision of the

Contract and Contractor’s compliance with the HSP will be monitored during the Contract Term.

“Incident” means an unplanned interruption of TCT or a service related to the TCT (e.g., an infrastructure issue, TCT outage, network related latency).

“Jira Software” is a proprietary product developed by Atlassian that allows bug tracking, issue tracking and agile project management.

“Key Personnel” means those Contractor personnel whose positions are essential to the successful performance of Services under the Contract.

“Operations Phase” means the period of time that occurs after the end of the Transition Phase, up until the Contract end date. The Contractor will perform all TCT maintenance services during this phase.

“Procurement Library” means the repository of additional information made available to

Respondents subject to the terms and conditions of this Solicitation. All documents in the

Procurement Library are provided only for background information and are not to be considered requirements for the Solicitation. Unless explicitly incorporated in this Solicitation via an

Addendum, the documents residing in the Procurement Library do not become part of the

Contract.

“Respondent” means the individual or entity responding to this Solicitation.

“Resolution Time” means a measure of how long it takes for the Contractor to place an Incident into “Resolved” status. This includes the time the Contractor has researched the issue, identified a proposed resolution, and communicated it in writing to DSHS for evaluation and then implemented the solution successfully.

“Response Time” means a measure of how long it takes from Incident creation, for the Contractor to place the Incident into “In Progress” status. This measure signifies that a person is actively engaged and investigating the Incident.

“Service Request” or “SR” means a request originating from issues reported by end-users required to correct DSHS applications.

https://statutes.capitol.texas.gov/Docs/GV/htm/GV.2161.htm#2161.001 https://statutes.capitol.texas.gov/Docs/GV/htm/GV.2161.htm#2161.001 https://statutes.capitol.texas.gov/Docs/GV/htm/GV.2161.htm#2161.252

RFO No. HHS0014612v2 Page 10 of 59

Revision Date 04/28/2025

“Service Time” means the Response Time and the Resolution Time based on priority categorization: critical, high, medium or low.

“Solicitation” means this RFO including all exhibits, attachments, forms, and Addenda, if any.

“Solicitation Consideration (SC) Documents” means documents that must be submitted by

Respondent with the Solicitation Response in order to be considered for evaluation and cannot be resubmitted or have errors remedied after the submission due date and time in the Schedule of

Events has passed.

“Sprint” means the activities required for one Sprint Team to complete a Sprint Product after Sprint

Planning is complete, including development, testing or review, and resolution of Defects within a period of twenty (20) Business Days.

“Sprint Planning” means the activities required to determine the Sprint Product to be developed during the Sprint, including discovery, documentation of User Stories and documentation of the

Acceptance Criteria for each User Story. This includes picking up User Stories from the backlog and breaking them down into more manageable tasks.

“Sprint Team” means the personnel provided by Contractor capable of completing one or more

Sprint Products.

“Sprint Product” means the collection of User Stories completed during a Sprint which means a

Fully Functional Feature is developed within a Sprint.

“State” means the State of Texas and its instrumentalities, including HHSC, DSHS, or DFPS, and any other State agency, its officers, employees, or authorized agents.

“Transition Phase” means the period of time between the Contract Effective Date and the start of the Operations Phase.

“Turnover Phase” means the 2-month period, prior to Contract expiration, during which the

Contractor must provide services and activities required for the Contractor to hand over Contract service delivery to a successor contractor, DSHS, or DSHS’s designated resources.

“Unanticipated Change” means a material change in the technologies or processes available to provide all or any portion of the Services which is outside the normal evolution of technology experienced by the Services, that was not generally available as of the Contract Effective Date and that would materially reduce the Contractor's cost of providing the Services.

“User Stories” means the smallest unit of work in an agile framework.

RFO No. HHS0014612v2 Page 11 of 59

Revision Date 04/28/2025

“VPTS” means Vendor Performance Tracking System maintained by the Texas Comptroller of

Public Accounts. The VPTS may be currently accessed at https://comptroller.texas.gov/purchasing/programs/vendor-performance-tracking/.

1.3 AUTHORITY

This Solicitation is issued pursuant to Section 2157.006(a)(2) of the Texas Government Code.

ARTICLE II. SCOPE OF WORK

2.1 DESCRIPTION OF SERVICES

The Contractor must provide on-going TCT support and maintenance services, including the following:

a. Client portal;

b. Agency portal;

c. Application workflow;

d. Eligibility;

e. Contracts;

f. Pharmacy portal;

g. Reporting;

h. Interfaces;

i. TCT ongoing maintenance and security updates; and

j. On-going Enhancement services, as needed.

The Contractor must utilize a collaborative, innovative, cooperative, flexible and process/customer-oriented approach to meet requirements under the Contract. All Client facing elements of the TCT must be delivered in both English and Spanish to ensure that Clients with limited English proficiency are effectively informed and can have access to programs, benefits, and activities.

The Contractor must provide resources sufficient to meet all levels of support detailed in Section

2.4.4.1 (Levels of Support). When the Contractor is not working on critical or high Incidents the

Contractor must use its resources for system improvement activities that include any DME services

(see Section 2.4.3 (DME Services)) and supplemental services (see Section 2.6 (Supplemental https://comptroller.texas.gov/purchasing/programs/vendor-performance-tracking/ https://statutes.capitol.texas.gov/Docs/GV/htm/GV.2157.htm#2157.006

RFO No. HHS0014612v2 Page 12 of 59

Revision Date 04/28/2025

Services)). See procurement library for additional reference information regarding historical

Enhancement and maintenance hours.

Note that the ability to address Service Requests (SRs) is essential for maintenance and operations as well as system Enhancements in order to implement all software patches and/or required system integrations.

The Contractor must respond to information requests and the ability to address Incidents, allow for additional SRs while ensuring TCT is monitored and maintained on a regular basis to prevent breakdowns and costly repairs in the future.

HHSC will provide all software and licenses to the Contractor in support of the requirements of the Contract. Contractor's personnel must abide by Artifact C, Information Security Acceptable

Use Policy (a copy of which is located in the Procurement Library for reference) in utilizing these provided resources.

For additional clarifications and information regarding the Solicitation, refer to Section 3.7

(Procurement Library), and other documents expressly designated by HHSC as part of this

Solicitation.

2.2 CONTRACT PHASES

Contract Term is comprised of three (3) phases: (1) Transition Phase, (2) Operations Phase, and

(3) Turnover Phase, as explained in more detail in the following subsections.

2.3 PHASE I – TRANSITION

The Contractor must provide transition services in accordance with the approved Transition Plan

(see Exhibit L, Deliverables, DEL-02a). The Transition Phase must be completed within sixty

(60) Calendar Days following the Contract Effective Date with successful achievement of all performance measures. The Transition Phase shall be complete when DSHS provides written approval of all Deliverables and acknowledges successful completion.

The Contractor must:

a. Work with DSHS to effectively leverage the incumbent service provider’s turnover plan.

b. Ensure a smooth transition of responsibilities from the incumbent service provider.

c. Complete knowledge transfer from the incumbent service provider to the Contractor during the Transition Phase.

d. Demonstrate ability to perform all operations activities in all documented environments.

e. Be responsible and accountable for all open SRs reported and logged into the DSHS ticketing system.

RFO No. HHS0014612v2 Page 13 of 59

Revision Date 04/28/2025

2.3.1 Transition Deliverables

The Contractor will provide the following Deliverables during the Transition Phase:

a. Project Kickoff Presentation (see Exhibit L, Deliverables, DEL-01);

b. Project Plan (see Exhibit L, Deliverables, DEL-02), including:

1. Transition Plan (see Exhibit L, Deliverables, DEL-02a);

2. Project Schedule (see Exhibit L, Deliverables, DEL-02b);

3. Configuration Management (see Exhibit L, Deliverables, DEL-02c);

4. Support and Maintenance Plan (see Exhibit L, Deliverables, DEL-02d);

5. Weekly Written Status Reports (see Exhibit L Deliverables, DEL-02e);

6. Monthly Consolidated Status Reports (see Exhibit L Deliverables, DEL-02f);

c. Readiness Assessment Plan (see Exhibit L, Deliverables, DEL-03);

d. Readiness Assessment Results Report (see Exhibit L, Deliverables, DEL-04); and

e. System Security Plan (SSP) (see Exhibit L, Deliverables, DEL-06).

2.3.2 Key Personnel

The Contractor must provide and maintain adequate staffing, with the capacity to adjust its levels of qualified personnel to meet the requirements of the Contract, applicable State and federal requirements and changing DSHS and Client needs.

The Contractor must define each resource role and related responsibilities related to TCT services.

The Contractor must also provide any additional stakeholders (Subcontractors or non-

HHSC/DSHS personnel) roles and responsibilities related to the transition of the TCT functions.

The Contractor must designate Key Personnel and ensure that such personnel are solely dedicated to the performance of the Contract. Key Personnel must be full-time, knowledgeable, experienced, and qualified to perform the responsibilities of the position under the Contract. Key Personnel shall become named resources on the Project and are subject to the following requirements:

a. Key Personnel shall not be transferred or removed without prior approval of DSHS;

b. Key Personnel assigned to the Contract must be approved by DSHS;

c. Key Personnel shall not hold more than one (1) key role unless otherwise approved by

DSHS; and

d. Key Personnel must complete DSHS security and confidentiality training and sign a confidentiality agreement annually and as required by HHSC. DSHS reserves the right to

RFO No. HHS0014612v2 Page 14 of 59 alter the designation of any Contractor personnel as Key Personnel.

2.3.2.1 Account Manager

The Contractor’s Key Personnel must include a dedicated account manager throughout the

Contract Term. The account manager must have a minimum of five (5) years of experience leading and managing maintenance and support team for a tiered request application. The account manager will serve as the Contractor’s primary point of contact to DSHS during the Contract Term, to coordinate and deliver Services, to address any concerns or issues raised by DSHS or the

Contractor’s service providers, for invoicing and payments and for generally managing the business relationship.

2.3.2.2 Replacement of Key Personnel

In the event the Contractor proposes additional or replacement of Key Personnel during the

Contract Term, the Contractor shall provide the DSHS point of contact with the resume(s) of qualified individuals who have experience with a project similar to the requirements of this

Solicitation.

The resume information for the proposed Key Personnel shall be provided to DSHS within ten

(10) Business Days prior to the proposed start date of any additional (e.g., individual filling a new position) or replacement (i.e., individual replacing a removed individual) Key Personnel.

DSHS will have the right to conduct an interview of all proposed Key Personnel, provided such an interview occurs before the commencement of Services by the proposed individual.

Furthermore, DSHS will have the right to contact references of proposed Key Personnel. DSHS will provide the Contractor with written notice of approval or rejection of proposed Key Personnel within five (5) Business Days of receipt of the resume. DSHS shall have the right to reject assignment of any of the Contractor’s proposed Key Personnel by providing the Contractor a basis for such rejection. Within five (5) Calendar Days of DSHS’s written notification of rejection, the

Contractor shall provide DSHS with a minimum of three (3) additional resumes of proposed qualified individuals for review. This process shall be repeated until DSHS provides written approval to the Contractor of the individual selected. The approved individual shall commence

Services within thirty (30) Calendar Days of the Contractor’s receipt of the DSHS written approval.

DSHS, at its sole discretion, may require that the Contractor remove or replace a Key Personnel.

No cost will be incurred by DSHS for required or requested personnel changes.

The Contractor will replace the Key Personnel within sixty (60) Calendar Days of DSHS written request to remove the Key Personnel.

RFO No. HHS0014612v2 Page 15 of 59

Revision Date 04/28/2025

2.4 PHASE II – OPERATIONS

The Operations Phase begins immediately following DSHS’s written approval of completion of the Transition Phase and continues through the optional Contract extensions up through the

Turnover Phase.

2.4.1 Scrum Methodology – Agile-Focused Sprints Maintenance, Service Requests, Fixes and Defects

2.4.1.1 Sprint Team Composition

The Contractor must provide the appropriate staffing levels to complete a Sprint Product within a Sprint, aligning with Agile Software Development Lifecyle (SDLC) best practices. The standard Sprint Team is considered to be a combination of five (5) developers or analysts, a product owner liaison, a scrum master, and two (2) testers consistent with Section 2.4.1.2

(Sprint Team Contractor Roles). The Sprint Team must be based in the contiguous United

States and no information regarding TCT will be shared outside of the contiguous United States.

The composition of the Sprint team (roles and number of personnel) may be adjusted to meet the needs of the anticipated Sprint Product. The Contractor shall work with DSHS to utilize an agile methodology with iterative or incremental processes to implement SR fixes, Defects, and other

TCT maintenance. More than one (1) Sprint Team may be running in parallel to complete the

DSHS approved Sprint within the requisite timeframe.

2.4.1.2 Sprint Team Contractor Roles

Contractor’s Sprint Team roles and responsibilities are specified in Table 1 – Contractor’s

Sprint Team Roles and Responsibilities.

Contractor’s Sprint Team must have a demonstrated experience in the following as applicable to their roles:

a. React;

b. Next.js;

c. Lift – UI framework used for React applications;

d. Decisions – Business validation;

e. JavaOracle – Document scanning;

f. GlobalScape – File transfer;

g. OpCon – Batch jobs;

h. Jira;

i. Developing and Deploying UI and backend API separately;

j. Version control for large projects for frontend UI and backend API; and

RFO No. HHS0014612v2 Page 16 of 59

k. Upgrading third party software integrated with large scale applications.

Table 1 – Contractor’s Sprint Team Roles and Responsibilities

Role Responsibilities

Product

Owner

Liaison

a. Provides alignment of Work Products from features to User Stories.

b. Defines User Stories and gather requirements based on stakeholder consensus.

c. Maintains accountability for User Stories and acceptance of them.

d. Reviews the testing results to ensure the quality of the design and solution prior to User Acceptance Testing (UAT).

e. Ensures demos are provided during UAT.

f. Coordinates with project managers and other roles, as appropriate, to identify workstream tasks and dependencies.

g. Works directly with stakeholders.

Scrum

Master

a. Co-owns and manages the Sprint backlog in Jira Software with the functional lead.

b. Coordinates the assignment of the DevOps Engineers and is responsible for the overall quality of the Sprint Products.

c. Reviews the testing results to confirm the quality of the design and solution prior to UAT.

d. Maintains and/or improves data quality, integrity, and completeness.

Identifies and removes duplicate Sprint backlog items.

e. Defines the technical implementation details (“the how") leveraging the User

Stories.

Analysts a. Provides alignment of Work Products from features to User Stories

b. Defines User Stories and gathers requirements based on stakeholder consensus.

c. Works with the functional lead of the project and any relevant product owners to maintain consistency on the products related to the Work.

Developers a. Works with the product owner and developer lead to groom the User Stories within the backlog prior to committing to development in a Sprint.

b. Estimates the level of effort needed to deliver the expected Work.

c. Provides sufficient testing and monitoring of the Work through completion to ensure that quality changes are being promoted to UAT and production.

RFO No. HHS0014612v2 Page 17 of 59

Revision Date 04/28/2025

Table 1 – Contractor’s Sprint Team Roles and Responsibilities

Role Responsibilities

Testers Assess the functionality developed by the developers in an integrated environment to ensure quality of delivery, expected Acceptance Criteria is met, and cohesion across the teams’ efforts prior to the Work entering UAT.

2.4.1.3 Sprint Activities

The Contractor must complete each Sprint within twenty (20) Business Days from start to finish and provide a Sprint Product in accordance with this section.

a. Sprint Planning. The Contractor must conduct a Sprint Planning session(s) with DSHS and identified members of the TCT stakeholder/program team at the beginning of each

Sprint to identify and document User Stories and the Acceptance Criteria (e.g., definition of done) for each User Story.

b. Sprint Development. Following DSHS’s approval of Sprint plan in Jira Software, the

Contractor must ensure adequate quality assurance testing is completed prior to release to DSHS for UAT. The Contractor’s quality assurance testing must ensure there are no critical or high Defects. At the sole option of DSHS, UAT may begin with critical or high

Defects.

c. Test Scenarios. The Contractor must receive written approval from DSHS for test scenarios prior to UAT. The approved test scenarios must be provided to DSHS end-users to submit their testing responses. DSHS shall determine the end-users to participate in

UAT.

d. UAT. The Contractor must provide and update the test scenario Defect in Jira Software.

The Contractor must review and confirm Defects by end-users. The Contractor must provide a log of confirmed Defects identified in each individual end-user’s test scenario.

The Contractor must provide DSHS the ability to indicate the priority and severity of

Defects in Jira Software. Jira Software must also include any reported Defects that could not be confirmed. Exhibit K, Key Performance Measures and Liquidated Damages –

KPM-003.

e. Defect Resolution and Deployment. The Contractor must provide Sprint Products that are deployable. For a Sprint Product to be considered deployable, all critical and high severity Defects must be resolved. Medium and low severity Defects must be resolved after deployment and approved by DSHS. The Defect Severity Classification is as follows:

1. Severity 1 Critical: A Defect that renders the application inoperable, or unable to complete eligibility determination, or unable to fulfill medication services.

RFO No. HHS0014612v2 Page 18 of 59

Revision Date 04/28/2025

2. Severity 2 High: A Defect has impaired the application in such a manner that a key feature (core business component) is unavailable without a workaround and impacting

Client benefit.

3. Severity 3 Medium: A Defect where a feature of the application is impacted, but the application can still be used, and there is an acceptable workaround.

4. Severity 4 Low: A Defect that is cosmetic in nature without functional or business impact.

2.4.1.4 Sprint Deliverable Acceptance Standard

The Contractor shall be required to resolve all Defects in Jira Software, including medium and low Defects, for all Sprint Products related to the features identified in the Sprint Planning.

Payment for the final Sprint will not be made until all Defects are determined by DSHS to be resolved and communicated to Contractor by DSHS in writing.

2.4.2 General Service Requirements

The Contractor is required to maintain and support TCT in a hosted environment. The Contractor is only required to support TCT. The network and hardware support will be supplied by the

Texas Data Center Services.

The Contractor must provide support and maintenance for a services-oriented architecture (SOA) or web services architecture, as required by DSHS. The State requires SOA capabilities for all communication with constituent third party applications.

The Contractor shall monitor the DSHS TCT tiered request application and respond to all SRs to minimize service interruption to TCT.

The Contractor shall provide the following IT support services and Deliverables associated with

TCT.

The Contractor must:

a. Ensure all Work Product conforms to Contract requirements;

b. Ensure changes are properly evaluated, authorized, and implemented; and

c. Ensure all information, data, and necessary documents including but not limited to release notes, data dictionary, schema changes, reports parameter changes, are kept current, and in a shared location as required by DSHS (i.e., SharePoint).

2.4.2.1 Planning and Reporting

The Contractor shall provide planning and reporting services which include the following:

RFO No. HHS0014612v2 Page 19 of 59

Revision Date 04/28/2025

a. Conduct bi-weekly planning meetings with DSHS to review accomplishments and planned activities;

b. Provide Weekly Written Status Reports (see Exhibit L, Deliverables, DEL-02e) to include the status of open SRs by priority level, recently closed SRs, Deliverables, and any perceived issues and risks;

c. Provide Monthly Consolidated Status Reports (see Exhibit L, Deliverables, DEL-02f);

and

d. On an as needed basis, as determined by DSHS, hold analysis and design sessions for new

SRs.

2.4.2.2 Informational Requests

For informational requests, the Contractor shall, within timeframes specified by DSHS, provide responses and information to DSHS in connection with:

a. Questions from DSHS staff related to functional aspects of TCT;

b. Legislative inquiries;

c. Inquiries sent by DSHS Government Affairs; and

d. Audit requests from DSHS IT federal/State reporting coordination as well as other DSHS designated entities.

2.4.3 Development Modernization and Enhancement Services

The Contractor shall provide development, modernization, and Enhancement (DME) services, which may include an addition to, or alteration of, existing software application functionality.

DME Services may also include the development of integrations with third party software associated with the addition to, or alteration of, existing software functionality. The Contractor shall work with DSHS to utilize an agile methodology with iterative or incremental processes to document, design, develop, test, and implement TCT Enhancements. The Contractor will produce the DSHS-approved Enhancements from the Sprint Products approved by DSHS in Sprint

Planning. Section 2.4.4.4 (Services Request Process) outlines the process to deliver DME services.

2.4.4 Service Request Ticketing Process

DSHS will create, assign the level of support as either (1) Level 1 Support; (2) Level 2 Support;

or (3) Level 3 Support, and prioritize each SR. The Contractor shall have the following capabilities regarding the assigned tickets:

a. Modify an SR ticket;

b. Add attachments;

RFO No. HHS0014612v2 Page 20 of 59

Revision Date 04/28/2025

c. Download a report of SR tickets;

d. View system documentation and information; and

e. Include email addresses of additional parties who should be automatically notified when a

SR ticket is updated.

2.4.4.1 Levels of Support

The Contractor will provide resources sufficient to meet the support levels and maintenance activities set forth in this Contract.

The Contractor will comply with all the following support levels as shown in Table 2 – Levels of

Support. See the Procurement Library for additional reference information regarding historical enhancement and maintenance hours.

Table 2 – Levels of Support

DSHS TCT Maintenance and Support

Levels of Support

DSHS will assign each SR as either a Level 1 Support; Level 2 Support; or Level 3 Support.

Level 1 Support

SRs designated as Level 1 Support will be resolved by DSHS. Level 1 Support SRs include, but are not limited to, SR requesting support regarding general usage of TCT, questions regarding navigation of TCT, or questions regarding DSHS-specific process or procedures associated with using the applications within the DSHS environment.

DSHS Level 1 support staff will triage agency issues and enter issues into the DSHS approved ticketing system for Level 1 Support assistance, only if DSHS is unable to resolve the issue. It is DSHS responsibility to report Level 1 Support issues in Jira Software.

Level 2 Support

SRs designated as Level 2 Support will be resolved by the Contractor.

SRs designated as Level 2 SRs include, but are not limited to, SRs regarding Incident and information requests. In Level 2 Support, the Contractor will assign the SR to one of its TCT resources performing application support. Additionally, the Contractor shall be responsible for providing the following services applicable to the SR tracking system, which includes, but are not limited to:

RFO No. HHS0014612v2 Page 21 of 59

Revision Date 04/28/2025

Logging, managing, and resolving Level 2 Support SRs;

Researching and analyzing technical issues related to Level 2 Support SRs; and

Performing problem management (analysis and permanent resolution of systemic application or system Defects).

Level 3 Support

SRs designated as Level 3 Support will be provided by the Contractor resources and/or third-party vendors supplying hardware, software outside of TCT or other infrastructure components integrated with TCT.

Level 3 Support will be accessed when Contractor’s Level 2 analysts have determined that the problem resides in:

a. Hardware;

b. Software; or

c. Other system components not supported by the Contractor.

For all Level 3 Support, the Contractor will enter tasks in Jira Software with the appropriate third-party vendor or section for resolution of these Incidents.

DSHS TCT Production – Support Services

Support Target Metric

Regular DSHS TCT Support

Hours

Business Days 7:30 a.m.to 5:30 p.m. CT. TCT will be staffed on skeleton crew days.

Additional DSHS TCT

Support Hours

Handled on a case-by-case basis where reasonable and DSHS has given five (5) Business Days advance notice to

Contractor.

2.4.4.2 Incident

For Incidents, the Contractor shall perform services which include, but are not limited to, the following:

a. Trouble-shoot and resolve problems encountered by system end-users in TCT;

b. Resolve integration issues with agencies and subcontracted agencies to facilitate uploading electronic data from those agencies or Clients into TCT;

RFO No. HHS0014612v2 Page 22 of 59

Revision Date 04/28/2025

c. Resolve issues for the integration of other systems utilizing TCT functionality; and

d. Resolve issues for maximizing the speed of the Texas specific Extract, Transform and Load

(ETL) code.

2.4.4.3 Service Requests

The Contractor must respond to SRs in accordance with the Response Times noted in Table 3 –

Priority Levels and Services Times (see Section 2.4.4.5 (Priority Levels, Service Times)), which include but are not limited to the following;

a. Upgrade or implement software patches received from TCT;

b. Customize configurable reports to be used by TCT users;

c. Customize TCT routes to implement new TCT data integrations;

d. Customize configurable data extractions to be used by TCT users;

e. Support TCT users who are developing new SRs in the ticketing system;

f. Support TCT system integration adapters, enabling DSHS to quickly integrate services or make updates to existing integrations, including but not limited to Pharmacy Inventory

Management System (PIMS); and

g. Ensure TCT securely interfaces with external systems using DSHS provisioned credentials in accordance with DSHS standards.

2.4.4.4 Services Request Process

The Contractor must manage SRs using the following process:

a. DSHS staff shall open a SR ticket and provide a high-level description of the service(s) to be performed within a designated timeline.

b. The Contractor shall provide DSHS staff with a High-Level Estimate (HLE) of the level of effort required to complete the requested services within the requested timeline. Each

Contractor estimate, at a minimum, shall include the following information: requirements, tasks, Deliverables, resources, anticipated timeline, and a not-to-exceed cost that does not exceed the rate(s) set forth on the cost proposal to the Contract. DSHS shall not pay any investigatory charges related to the Contractor’s development of the HLE.

c. DSHS shall review the estimate and proposed solution and, at its discretion, may:

1. Decline to pursue the solution;

2. Modify the approach of the solution and require a revised HLE; or

3. Approve the estimate and proposed solution without modification.

RFO No. HHS0014612v2 Page 23 of 59

Revision Date 04/28/2025

d. At the bi-weekly planning meetings, the Contractor shall keep DSHS staff informed on the progress being made for each SR. Topics regarding SRs to be covered during the weekly meetings include:

1. Written summary of status, resources, schedule, tasks, activities, milestones, and risks;

2. Written summary of all opened and closed SRs for the week;

3. List of tasks that were delayed and reasons for delay, with expected revised completion date, planned activities for the next scheduled period; and

A SR is not complete until DSHS staff conduct user acceptance testing, and the change is moved into production.

2.4.4.5 Priority Levels, Service Times

The Contractor must provide Response, Resolution and Service Times updates on reported SRs based on Incident priority according to the standards set forth in Table 3 – Priority Levels and

Service Times.

The Contractor must resolve all SRs, Defects, and data fixes in production. See Exhibit K – Key

Performance Measures and Liquidated Damages, KPM-003 - Service Request and

Enhancement Quality.

Table 3 – Priority Levels and Service Times

Incident

Priority Response Time Resolution Time Service Time

1-Critical Less than one (1)

Business Hour

Less than eight (8) clock hours from the time assigned to the

Contractor or at a later date as agreed by DSHS in writing.

Update the service record every two (2)

Business Hours.

2-High Less than two (2)

Business Hours

Less than one (1) Business Day. Update the service record every four (4)

Business Hours.

3-Medium Less than one (1)

Business Day

Less than three (3) Business Days from the time assigned to the

Contractor or at a later date as agreed by DSHS in writing.

Update the service record every eight (8)

Business Hours.

RFO No. HHS0014612v2 Page 24 of 59

Revision Date 04/28/2025

Table 3 – Priority Levels and Service Times

Incident

Priority Response Time Resolution Time Service Time

4-Low Less than two (2)

Business Days

Less than two (2) weeks from the time assigned to the Contractor or at a later date as agreed by DSHS in writing.

Update the service record every sixteen

(16) Business Hours.

2.4.5 Security Requirements

The Contractor, at a minimum, shall comply with the following security requirements:

a. All requirements in Exhibit I, HHS Information Security and Privacy Requirements;

b. Contractor must provide integration services to integrate TCT into the HHSC's integration platform for single sign-on and federated identity management by working collaboratively with HHSC;

c. The Contractor must provide monitoring services to prevent and detect intrusion, hacking, unusual activity, or compromise of TCT. The Contractor shall immediately report any

Incidents of such, regardless of the outcome to HHSC, activate an HHSC-approved communication strategy, perform mitigation activities, and provide continuous status updates to HHSC until the issues are resolved to the HHSC's satisfaction. Only authorized

Contractor personnel may override system security alerts and edits;

d. Provide to HHSC, upon request, a listing of all users having access to TCT components and/or data with details regarding the access granted to each user;

e. Comply with the Harmonized Security and Privacy Framework - Exchange Reference

Architecture Supplement Version 1.0 and as required by CMS;

f. Provide scalable services to integrate other solutions for security and regulatory purposes in the future;

g. Comply with the OASIS Web Services Security - Simple Object Access Protocol (SOAP)

Message Security Version 1.1 Specifications as required by CMS to build secure web services to implement message content integrity and confidentiality;

h. Provide training to Contractor and Subcontractor personnel providing services under the

Contract on the business associate agreement and the privacy and security policies included in the Contract;

i. Provide logical segregation of TCT components, and network connections with to prevent any unauthorized disclosure of the State’s data;

RFO No. HHS0014612v2 Page 25 of 59

Revision Date 04/28/2025

j. Track disclosures of electronic protected health information (ePHI); provide authorized users access to and reports on the disclosures;

k. Collaborate with HHSC in meeting the requirements in Exhibit I, HHS Information

Security and Privacy Requirements;

l. The Contractor must comply with established HHSC-approved processes for any

Contractor remote workers to ensure compliance with all security and privacy requirements, including the work-from-home guidelines and work-from-home agreement, which specifically address adherence to HIPAA and IT security guidelines. Staff will be required to sign the Contractor inventory agreement acknowledging the use of Contractor issued computers and mandatory return of issued computers to the Contractor in the event of termination of employment;

m. The Contractor must coordinate security management across all Contractor business and technical functions of TCT including, but not limited to, the following:

1. Participate and collaborate with HHSC in evaluation and risk assessment for impact of security vulnerabilities of Contractor’s HHSC-approved third-party software and to:

i. Provide updates and security patches in accordance with the Contractor’s

HHSC-approved System Security Plan; and

ii. Remediate moderate to critical issues of the security evaluation and assessment, as approved by HHSC.

2. Perform security audits, provide Incident investigation support, including reports, and initiate corrective actions to minimize and prevent data and security breaches in accordance with the Contractor’s HHSC-approved System Security Plan.

2.4.6 Key Performance Measures and Associated Remedies

DSHS will monitor the performance of the Contractor. Although all requirements of the Contract are subject to performance evaluation by DSHS, DSHS has identified specific Key Performance

Measures (KPMs) in Exhibit K, Key Performance Measures and Liquidated Damages.

For the contractual obligations subject to a KPM, the KPM will be used to gauge the Contractor’s commitment to successful performance, its willingness to stand behind its products and services during the Contract Term, as well as its confidence in its ability to perform. In the event the

Contractor fails to perform or complete its obligations in a timely manner, DSHS may, in addition to the remedies set forth elsewhere in the Contract, impose remedies which include the following:

a. Compliance by the Contractor, at no cost to DSHS, with the performance improvement activities and timelines specified in a written corrective action plan(s) approved by DSHS;

RFO No. HHS0014612v2 Page 26 of 59

Revision Date 04/28/2025

b. Additional or ad hoc reporting by the Contractor, at no cost to DSHS, to address performance issues; and

c. Assessment of liquidated damages (LDs) See Exhibit K, Key Performance Measures and Liquidated Damages.

The Contractor agrees that (1) the liquidated damages and any amounts assessed in connection therewith are neither a penalty nor a forfeiture, and (2) the amount of liquidated damages is a reasonable forecast of just compensation. HHSC is not required to provide the Contractor with notice and opportunity to resolve issues prior to HHSC’s assessment of liquidated damages.

Liquidated damages will not be assessed if HHSC determines that Contractor is not responsible for the delay or failure of the applicable KPM.

2.4.7 Accessibility Requirements

The contractor in their maintenance and enhancement to the Take Charge Texas (TCT) application, shall provide services that meet the accessibility requirements in accordance with the current published accessibility standards and must apply any changes that may occur throughout the Contract term. The Contractor must meet the accessibility requirements included in the

American with Disabilities Act, Web Content Accessibility Guidelines (WCAG), and Sections

504 and 508 of the Rehabilitation Act of 1973 (revised), outlined at VPAT – Information

Technology Industry Council.

2.5 PHASE III – TURNOVER

The Contractor must provide turnover services in accordance with the approved Turnover Plan

(see Exhibit L, Deliverables, DEL-05). The Turnover Phase shall begin one-hundred and eighty

(180) Calendar Days prior to the end of the Contract Term, which may include optional extension periods or at DSHS’s written request. The Contractor shall perform Turnover services concurrently with regular Operations services.

The Contractor shall take all steps necessary, at no additional cost to DSHS, to ensure that both

Turnover services and Operations services are performed without interruption or diminished performance, including, if necessary, adding additional personnel, temporarily relocating personnel, and other increases in resources to ensure the Contractor’s complete and uninterrupted performance of all Contract obligations. The Contractor will fully cooperate with DSHS or its designee to provide any assistance and actions necessary for DSHS or its designee to close out the

Contract and transfer all applicable Work. This obligation survives the termination, regardless of whether for cause…