H2FMS Request for White Papers Final 04SEP2025.docx

H2FMS Request for White Papers (RWP) Vendors’ white paper submissions shall address the contents of the Statement of Objectives (SOO) and shall be structured as follows. See detailed section descriptions following this table. NOTE: White papers SHALL NOT CONTAIN CLASSIFIED INFORMATION and proprietary information shall be clearly marked as such.

Annex B – Delivery Schedule Plan of Action and Milestones (POA&M)*

*See Annex descriptions later in this document.

1. Cover Sheet: Vendors shall include the following information on the cover sheet of their white paper:

Vendor's company name

Vendor’s address

Points of contact name, phone number, and e-mail address

Commercial and Government Entity (CAGE) Code

Unique Entity ID (created in SAM.gov)

Business size/type (large business, small business, small-disadvantaged business, 8(a) certified small-disadvantaged business, HUBZone small business, woman-owned small business, very small business, veteran-owned small business, service-disabled veteran-owned small business)

Primary NAICS code.

Non-Traditional Defense Contractor (NTDC) designation, as defined in section 3014 of Title 10 US Code §3014? (Yes or No)

Is vendor capable of providing a live software demonstration within 7 days of white paper submission? (Yes or No)

2. Executive Summary: The Executive Summary shall provide a one-page digest of the offeror’s white paper contents and proposed H2FMS solution. The Executive Summary shall only summarize information provided in further detail in the white paper submission and shall not be used to supplement or add to the information provided elsewhere in the white paper.

3. White Paper Narrative: The White Paper Narrative shall address the SOO and provide responses addressing the following:

a) Describe how the solution will ensure compliance with applicable cybersecurity and accreditation requirements, including FedRAMP (for cloud service components), the Army Risk Management Framework (RMF) process, Intermediate Authority to Test (IATT), Authority to Operate (ATO), DISA Security Technical Implementation Guides (STIGs), DISA Provisional Authorization (PA), and DoD Impact Level standards. The solution must demonstrate a path to achieving Army ATO through RMF-aligned controls and documentation, including traceable artifacts supporting security categorization, control implementation, and continuous monitoring (refer to SOO para 5.5).

b) Describe how scalability will be designed to meet operational demands, ensuring seamless functionality and adaptability, and structured to scale to the initial user base in FY26 and the total user base by FY28 (refer to SOO para 5.1).

c) Describe the implementation of a consumption-based, enterprise-level licensing strategy that optimizes cost efficiency and supports scalability. Describe any commercial license products included in the architecture and their alignment with the overall solution (refer to SOO para 5.10).

d) Describe the delivery of core application features while prioritizing the physical, sleep, and nutrition domains. Describe the agile development approach (DevSecOps) to ensure iterative delivery and rapid deployment. Describe mechanisms for third-party developers to add component services or applications to architecture, with vendor support to ensure seamless integration (refer to SOO para 5.3).

e) Describe how your capability will ensure seamless integration of Application Program Interface (API) requirements to enable interoperability and data exchange based on your proposed solution architecture and its impact levels (IL2/4/5). Describe how the solution will tie into the Data Lake, focusing on wearable integration to capture real-time data and facilitate automated data entry. Describe how the system will support efficient data ingestion, storage, and retrieval to enhance operational and analytical capabilities (refer to SOO para 5.0/5.1).

f) Describe solution partners and teammates, clearly defining their roles and contributions. Describe the Government's role in oversight and decision-making regarding integrated software applications, devices, and/or other interfaces. Describe the approach to managing the H2FMS solution through prototyping, including mechanisms for Government involvement in adjustments to teaming arrangements during prototype development and delivery (refer to SOO para 5.11).

g) Describe how the Government will approach data rights in relation to the H2FMS Solution and all subsequent iterations of updates throughout the prototyping phase. The Government assumes it will receive unlimited rights to emergent reference architecture/software/algorithms (refer to SOO para 5.10).

h) Describe how the solution will meet rigorous compliance and data protection standards, ensuring user acceptance and trust in the system. Assumption: Team Lead may establish Public Prive Partnership (P3) with ECMA (or other government agency) to cover compute/store costs or other larger enterprise components of the solution (reference SOO para 2.0).

i) Assumption: The total Period of Performance (PoP) shall not exceed 36 months.

4. Annex Descriptions:

Annex A – Software System Architecture: Vendor shall provide a software system architecture description and diagram that integrates with a IL5 data Lakehouse in cARMY, supports structured and unstructured data, ensures FedRAMP compliance, enables seamless API connectivity with Army systems of record, and adheres to IL2/IL4/IL5 standards for security and performance.

Annex B – Delivery Schedule: Vendor shall provide an H2FMS prototype solution milestone schedule, in vendor format, as Annex B. The milestone schedule shall include all major activities identified in the draft H2FMS SOO plus the vendor’s concurrent internal major activities. Vendors shall use 15 November 2025 as the tentative award date.

Annex C – Rough Order of Magnitude (ROM) Cost: The below table (next page) should be used as the basic framework for Annex C. Vendors may expand on this to provide additional details as they see fit, however the table below identifies the minimum information that the Government desires in the white paper ROMs.

Labor Costs

Software Licenses (Enterprise, Consumption-based rates, etc.)

Other Costs

Total Costs

Less: Cost Share (Optional)

Total Price to Government with Cost Share Included (Optional)

Labor costs consist of the number of Full Time Equivalents (FTEs) at the appropriate annual FTE rate(s).

Non-Labor costs consist of 1) Software licensing costs, and 2) all other costs (e.g., IP/GPR-related costs, other direct costs, travel, G&A, and any other relevant costs).

Note: Cost share is generally considered to include forward-looking costs directly associated with the prototype project under consideration and does not include prior investments.

Annex D – Data Rights Assertions: Vendors. Vendors shall describe their Data Rights approach for their H2FMS solution, which shall address the data rights objectives included in the SOO provided with the RFS. Narrative shall describe how their data rights approach:

· Supports MOSA objectives.

· Supports software sustainment objectives.

· Supports integration/extensibility objectives, to include discussion of the vendor’s proposed approach to providing SDK (software and documentation) to 3rd party application developers and support for integration with third-party devices, modules, etc.

In addition, the vendor shall identify any software license and/or software subscriptions that the Government would be expected to pay, either during the prototype project or in follow-on sustainment.

In addition, vendors shall extract and fill out the Data Rights Assertion Table (next page) and submit as part of Annex D. As appropriate, vendors may add rows to address additional data types and assertions for Government consideration.

Table 1. Data Rights Assertion Table Data Rights Assertion Table

Software

Technical Data Package

Interface Control Documents (to include all modular interfaces)

Software Development Kit (SDK)

Software Documentation

Form, Fit, and Function (FFF) Data

Operation, Maintenance, Installation and Training Data (OMIT)

Studies, Analyses, and Test Data

Data Collected within H2FMS

For definitions of Data Types and Data Rights refer to DFARS 252.227-7013, -7014, -7018, available at https://www.acquisition.gov image1.png