ESBD_538772_1784210776834_HHS0017637 RFI Federal Funds Tracking System (FFTS).pdf

Texas Health and Human Services Commission RFI for CFO Federal Funds Tracking System (FFTS)

STEPHANIE MUTH, EXECUTIVE COMMISSIONER

Request for Information (RFI) for

Department of State Health Services (DSHS), Chief Financial Officer

(CFO)

Federal Funds Tracking System (FFTS)

RFI No. HHS0017637

Date of Release: July 16, 2026

Response Due: August 6, 2026, at 10:30 am Central Time

NIGP Class/Item Codes:

208/00 - Computer Software For Microcomputers, Systems, Including Cloud-Based (Preprogrammed) 208/10 - Accounting/Financial: Bookkeeping, Billing and Invoicing, Budgeting, Payroll, Taxes, Etc., Microcomputer 208/11 - Application Software, (Not Otherwise Classified), Microcomputer 208/21-Business Intelligence Software, Microcomputer 918/29-Computer Software Consulting 918/32-Consulting Services (Not Otherwise Classified) 918/93-Security and /Safety Consulting 920/03-Application Service Provider (Asp), (Web Based Hosted) 920/05-Application, Infrastructure, Hosting, Data Hosting and

Cloud Computing Services, Vendor Hosted and Internally Hosted 920/14-Applications Software (For Minicomputer Systems), Mainframes and Servers 920/40-Programming Services, Computer, (Including Mobile Device Applications) 920/45-Software Maintenance and Support Services/Support and Updates and Data Hosting Services 920/46-Software Updating Services and Upgrading Services 920/64-System Implementation and Engineering Services 958/77-Project Management Services

Table of Contents

1. Introduction

1.1 Purpose

1.2 Background

1.3 Vision

2. General Instructions and Response Requirements

2.1 Questions

2.1.1 Product / Functional Capabilities

2.1.2 Technical

2.1.3 Service Delivery and Implementation

2.1.4 Cost Structure

2.2 General Information

2.3 Response Submission, Date, Time, and Location

2.4 Designated Point of Contact

2.5 Response Format

2.6 Texas Public Information Act

2.7 Disclaimers

1. Introduction

The Texas Health and Human Services Commission (HHSC), on behalf of the Department of State Health Services (DSHS), is issuing this Request for Information (RFI) to gather information from vendors regarding solutions capable of supporting a Federal Funds Tracking System (FFTS).

This notice is issued solely for information and planning and does not constitute a Request for Offer (RFO) or a commitment on the part of the HHSC to conduct a solicitation in the future. Respondents are advised that HHSC will not pay for information submitted in response to this RFI, nor will it compensate respondents for any costs incurred in the development/furnishing of a response. HHSC will not accept or respond to telephone calls, emails, or questions regarding this RFI. Please note that a vendor’s participation in this RFI will neither preclude nor give advantage to that vendor in any future solicitation. Similarly, a vendor’s decision not to submit a response to this RFI will neither preclude nor disadvantage that vendor in any future solicitation.

HHSC is authorized to engage with vendors through this RFI by Texas Government Code Section 2155.090(b). HHSC will conduct this RFI and engage with the vendor community in accordance with the Health and Human Services (HHS) Vendor Interaction Policy, available on the HHS website at Vendor Resources | Texas Health and Human Services

1.1 Purpose

HHSC seeks information from vendors regarding commercially available solutions that can support the Agency’s need to serve as a system of record for structured, relational data, including the management and association of related records across multiple time periods, as well as internal record tracking, workflow management, and reporting.

Through this RFI, HHSC aims to better understand:

a. Current industry capabilities and best practices for configurable workflow, record management, case management, and tracking solutions;

b. Available Commercial Off-the-Shelf (COTS), Software-as-a-Service (SaaS), and other configurable platform solutions that may support the Agency’s operational, reporting, and compliance-related needs;

c. Vendor approaches to supporting internal lifecycle tracking, workflow automation, reporting, audit readiness, and administrative configurability;

d. The extent to which solutions may be implemented using native functionality or configuration rather than custom development; and

e. Innovation in data management, user experience, analytics, and automation relevant to the Agency’s use case.

Consistent with the FFTS procurement objective, the Agency is interested in solutions capable of supporting end-to-end internal tracking of funding opportunities, related submissions, funding actions, and associated reporting and oversight activities.

HHSC welcomes responses from vendors offering configurable platforms, including but not limited to case management, workflow automation, record management, CRM-style, or similar adaptable solutions that could be configured to support the Agency’s needs.

DSHS may consider information gathered through this RFI in the development of a future solicitation related to FFTS.

1.2 Background

Current Environment

DSHS is exploring the replacement of an legacy internal system that no longer meets operational, sustainability, workflow, or reporting requirements. As a state public health agency, DSHS operates as a federal grantee. The team seeking this solution performs an internal coordination and oversight function, supporting the tracking and management of funding opportunities, applications, and awards across Agency programs, and does not directly apply for funding or act as a grantor. The future solution is intended to support internal business processes associated with tracking and managing related records used to monitor, oversee, and report on externally funded awards and activities across multiple time periods.

To clarify how key terms are used in this RFI, the table and diagram below illustrate the relationship between the record types referenced throughout this document. The terminology is intended to describe the Agency’s business context and information needs, rather than prescribe a specific vendor data model or product structure.

For purposes of this RFI, a funding opportunity serves as the initiating record, while related submissions and funding actions represent associated downstream records that may be linked and tracked over time.

Term Meaning in RFI Relationship

Funding opportunity

The initiating or parent record representing an external funding opportunity or similar source record

May relate to one or more submissions and associated funding actions

Submission A child record representing an internal request, response, or application-type effort associated with a funding opportunity

Linked to a funding opportunity; may lead to one or more funding actions

Funding action

A downstream child record representing an award, amendment, allocation, or similar funding-related action

Linked to the relevant funding opportunity and/or submission

The Agency is interested in understanding how available solutions may support functions such as:

a. Tracking funding opportunities or other initiating records (parent records), including system-generated unique identifiers for record management and linkage;

b. Tracking the type and number of applications processed for performance measures;

c. Reviewing categorical funding from prior applications;

d. Managing related submissions, requests, or application-type records (Child Records, “Stream 1”);

e. Tracking funding actions, awards, or comparable downstream records across multiple cycles, periods, or years (Child Records, “Stream 2”);

f. Representing multi-level award or funding structures, including related programs, components, funding years, and other associated records, with visibility from summary-level information to supporting detail;

g. Tracking, comparing, categorizing, and reporting funding values across related records and time periods, such as requested, awarded, amended, allocated, expended, or remaining amounts; and

h. Supporting internal workflow, approvals, monitoring, reporting, and audit readiness.

The solution must improve:

a. Data accuracy and accessibility;

b. Reporting and audit readiness;

c. Operational efficiency;

d. Visibility across related records and lifecycle stages; and

e. Compliance with applicable federal and state requirements.

1.3 Vision

DSHS seeks a modern, scalable Software-as-a-Service (SaaS) solution that:

a. Enhances visibility and accountability across internal tracking, workflow, and reporting processes;

b. Supports configurable workflows, statuses, business rules, and notifications;

c. Provides configurable, holistic, multi-year summary views with the ability to drill down into detailed record-level data;

d. Supports audit readiness, traceability, and compliance-related reporting;

e. Enables efficient management of related records across multiple lifecycle stages, including initiating records, tracking funding actions and awards, and ongoing monitoring of internal business activities; and

f. Can be configured and maintained by authorized agency administrators with minimal reliance on custom development.

2. General Instructions and Response Requirements

Respondents are requested to provide detailed responses aligned to the categories below.

In addition to addressing the high-level vision items, Respondents are encouraged to provide specific information responsive to the following inquiries. Respondents may answer one or more questions and are not required to answer every question.

Responses should reflect current trends and developments in technologies, methodologies, and tools. If Respondents describe a theoretical approach that has not been applied in a large-scale state government implementation, they should explain their experience with the approach and how it may support this project’s objectives.

2.1 Questions

For each capability described, in addition to a general response, Respondents should clearly indicate whether the capability is:

a. Natively Supported — available out-of-the-box without configuration or custom development;

b. Configurable Without Custom Development — achievable through system configuration, administration tools, or settings without writing custom code;

c. Not Supported — not available in the proposed solution, either natively or through configuration

Where a capability is configurable, Respondents should briefly describe the configuration approach and identify any required tools, modules, or administrative roles. Where a capability is not supported, Respondents may describe any available alternative approaches or workarounds.

2.1.1 Product / Functional Capabilities

For each functional capability, Respondents should indicate whether the capability may be configured and maintained by Agency administrators and identify any tools, vendor support, custom development, modules, limitations, dependencies, or workarounds required.

HHSC welcomes responses from vendors whose solutions use terminology differently from those used in this RFI. Where applicable, Respondents should map the requested capabilities to the closest equivalent concept within their solution (for example, case, record, object, entity, request, intake, workflow item, or funding record).

a. Initiating Record / Funding Opportunity Management

Describe how the system supports creation, management and tracking of an initiating record, such as a funding opportunity, notice, request, or similar parent record. Including a description of the system’s ability to:

1. Initiate , structure, store, display, and manage records through configurable system objects or record types; explain how these objects or record types can be created, modified, and managed by Agency Administrators without requiring custom development;

examples included, but are not limited to configurable objects, cases, tables, record types and entities.

2. Capture and maintain key attributes such as source organization, program, cycle or period, deadlines, status, identifiers and other user identified fields.

3. Establish and maintain a link between a single parent record and multiple related child records ; and

4. Provide configurable dashboards, reporting, alerts, and status visibility associated with these records.

b. Submission / Request Tracking

Describe the system’s ability to support child records connected to the initiating record (as described in a.), including the ability to:

1. Link such records to one or more related parent records;

2. Track record status over time, including across multiple periods or cycles, while retaining status history; and

3. Support multiple related submission or request records under a single parent record.

Describe:

1. How record statuses are defined, configured, and updated over time;

2. The ability to capture, store, and track both structured data fields and narrative or unstructured content within records;

3. Workflow capabilities such as routing, approvals, reassignment, and automated notifications for internal users, including whether both linear and conditional workflow logic is supported;

4. Unique identifier generation and association across related records; and

5. Available reporting capabilities related to these records, including standard and ad hoc reporting.

c. Funding Action and Related Record Tracking

Describe how the solution supports an initiating record (parent record) that may be associated with two distinct categories of child records: (1) submission, request, or other application-type records; and (2) funding action, award, amendment, allocation, or other downstream funding-related records. Include support for:

1. Configurable hierarchical relationships between related records (for example, parent-child or multi-level structures spanning initiating records, records, funding records, and downstream tracking records);

2. Consolidated views of active and historical data across multiple time periods;

3. Navigation from summary-level data to underlying detailed records;

4. Tracking and comparing values across related records;

5. Approaches for displaying, relating, calculating, or reporting funding balances across periods, including carry-forward, carryover, roll-forward, or similar cross-period funding concepts, while maintaining visibility into original and adjusted funding amounts;

6. How the solution can represent funding offsets or similar cross-period funding relationships, including scenarios where prior-period funds remain visible for later use while preserving visibility into original awarded amounts;

7. Categorizing and filtering records using configurable fields such as program, funding source, cost category, or other agency-defined attributes; and

8. Combined active and historical reporting.

d. Workflow and Automation

Respondents should describe how alerts, reminders, notifications, or escalations may be configured based on dates, deadlines, statuses, reporting events, compliance-related conditions, or other record attributes, including support for notifying appropriate roles or groups.

Describe configurable, rules-based workflows for:

1. Intake or initiation of records;

2. Internal review and approval processes;

3. Funding action or downstream record tracking; and

4. Ongoing monitoring, follow-up, and record management.

Include a description of alerts, reminders, notifications, escalations, and other automation capabilities.

e. Reporting and Analytics

Describe:

1. Standard and ad hoc reporting capabilities;

2. Integration with analytics platforms (e.g., Power BI, Tableau, etc.); and

3. Automated report scheduling and distribution.

f. Additional Notes

Respondents may use this section to include any relevant clarifications, assumptions, constraints, or dependencies that would help DSHS understand how the proposed solution supports the data tracking, workflow, and reporting needs described in this RFI.

Respondents should note any capabilities that require additional modules, third-party integrations, or significant configuration effort to achieve the functionality described above, including any associated implementation or cost implications.

2.1.2 Technical

In addition to describing general technical capabilities, Respondents should provide sufficient detail to enable the Agency to assess technical fit, compliance readiness, interoperability, and operational sustainability.

As applicable, responses should address current TX-RAMP status or roadmap;

hosting model and data residency; access control approach; audit logging granularity and traceability; supported integration methods and API maturity;

identity and access management support, including single sign-on; bulk import and export capabilities; data retention and records support;

environment structure, including development, test, and production; and any technical constraints, assumptions, or dependencies relevant to a Texas public-sector implementation.

Describe the system’s ability to meet the following:

a. Security and Compliance

1. TX-RAMP Level 2 readiness;

2. Data encryption standards (in transit and at rest); and

3. Role-based access control and audit logging.

b. Integration and Interoperability

1. Data exchange mechanisms (API, SFTP, etc.) and approach;

2. Integration with identity access management; and

3. Compatibility with enterprise reporting tools.

c. Data Management

1. Data migration approach (including legacy data);

2. Data retention and audit traceability; and

3. Bulk data import/export capabilities.

d. System Architecture

1. SaaS vs. hosted architecture;

2. Environment support (UAT, staging, production); and

3. Scalability and performance.

2.1.3 Service Delivery and Implementation

Respondents should describe a typical implementation approach for a comparable public-sector or similarly regulated client, including anticipated phases, typical timeline ranges, key assumptions and dependencies, data migration complexity, allocation of vendor and agency responsibilities, and the post-go-live support model.

Respondents should also identify which requested capabilities typically require the greatest implementation effort, specialized services, or third-party products or integrations.

Describe your approach to the following:

a. Implementation approach for a comparable client

1. Typical timeline;

2. Key dependencies;

3. Migration complexity; and

4. Vendor vs. agency responsibilities.

b. Implementation phases, including:

1. Discovery and planning;

2. Configuration and build;

3. Testing and training; and

4. Go-live and support.

c. Project governance and deliverables, including:

1. Project work plan;

2. Communication and change management plans; and

3. Training and readiness assessment.

d. Ongoing support, including:

1. Post-go-live support model;

2. Help desk and issue resolution;

3. Maintenance and upgrades; and

4. SLA management (availability, response times).

2.1.4 Cost Structure

Without including pricing or dollar figures, Respondents should describe the principal cost drivers associated with the proposed solution, including licensing structure, required and optional modules, implementation services, integrations, migration, reporting and analytics capabilities, environment support, administrative model, and ongoing operations and support.

Respondents should distinguish between required cost drivers and those that are optional or scenario dependent.

Responses should not include pricing or dollar figures.

Respondents should describe:

a. Licensing model (user-based, concurrent users, etc.);

b. Optional vs. required modules;

c. Reporting/analytics capabilities;

d. Implementation cost drivers;

e. Ongoing operational cost drivers; and

f. Key variables affecting total cost of ownership.

2.2 General Information

All materials received by HHSC become the property of HHSC and will not be returned. HHSC will not acknowledge receipt of submitted information.

Acceptance of responses to this RFI places no obligation on HHSC. Any information or ideas received from Respondents in any form may be used by HHSC without restriction for any purpose determined by HHSC.

It is not the intent of HHSC to provide answers, but if additional information is issued relating to the RFI, it will be made available on the Electronic State Business Daily (http://www.txsmartbuy.com/sp).

a. Assumptions, constraints, or dependencies;

b. Required third-party tools or integrations; and

c. Optional capabilities not explicitly requested.

2.3 Response Submission, Date, Time, and Location

HHSC welcomes written responses and comments related to this RFI by:

Thursday, August 6, 2026, at 10:30 am Central Time

Responses must be submitted via email to HHSC’s designated point of contact identified in Section 2.4, Designated Point of Contact. Faxed responses and verbal inquiries will not be accepted. If additional information is issued relating to this RFI, it will be made available on the Electronic State Business Daily.

2.4 Designated Point of Contact

HHSC’s official single point of contact for this RFI and the delivery point for all responses and correspondence is:

Andrick Reese, MBA, CTCD, CTCM HHS Procurement and Contracting Services Texas Health & Human Services Commission

1100 W 49th Street Austin, TX 78756 Mail Code: 2020

Phone: (512) 406-2606 email: Andrick.Reese@hhs.texas.gov

All communications relating to this RFI must be directed to the HHSC contact person named above. All communications between Respondents and other HHSC staff members concerning this RFI are strictly prohibited.

2.5 Response Format

For numbered questions, responses should be organized and mapped to the applicable RFI section and question. To promote consistency and facilitate review, Respondents should address the following, as applicable:

a. Capability status

b. Description

c. Configuration approach

d. Required modules

e. Implementation dependencies

f. Limitations/workarounds

For any question Respondents choose not to answer, please indicate “N/A.”

All responses must be:

a. Clearly legible;

b. Sequentially page-numbered and include Respondent’s name at the top of each page;

c. Correctly identified with the RFI number and RFI title in either the footer or header of each page;

d. In Verdana font, size twelve (12) for normal text, no less than size ten

(10) for tables, graphs, and appendices;

e. Less than twenty (20) pages, this does NOT include attachments and/or reference material;

f. 6. Submitted by Respondents via email;

g. In Word or searchable PDF format;

h. Submitted without any portion of the submission containing a copyright or marking of “confidential” or “proprietary”; and

i. Signed by Respondent’s authorized representative.

Vendors should submit supporting material, if any, as attachments with their RFI responses. All responses become the property of HHSC upon submission.

2.6 Texas Public Information Act

Copyrighted responses or responses marked “Confidential” or “Proprietary” are not acceptable and will be rejected as non-responsive.

Respondent acknowledges that HHSC is obligated to strictly comply with the Texas Public Information Act, Texas Government Code Chapter 552, in responding to any request for public information pertaining to this RFI, as well as any other disclosure of information required by applicable Texas law.

HHSC will process any request from a member of the public in accordance with the procedures outlined in the Act. Respondents should consult the Texas Attorney General’s website (www.oag.state.tx.us) for information concerning the Act’s procedures and application to proprietary information, as well as any potential exceptions to public disclosure that may be available to Respondents.

2.7 Disclaimers

Any information received from respondents to the RFI in any form may be used by HHSC without restriction for any purpose determined by HHSC.

By issuing this RFI and receiving responses, HHSC does not commit to issue a future RFO regarding the subject matter of this RFI.

HHSC may, at its sole discretion, withdraw or cancel this RFI at any time.