IMS SOO (2026-09-21 1345).docx

HHS/PSC/SCMS - Enterprise IMS Modernization

STATEMENT OF OBJECTIVES (SOO)

ENTERPRISE INVENTORY MANAGEMENT SYSTEM (IMS) MODERNIZATION

U.S. DEPARTMENT OF HEALTH AND HUMAN SERVICES (HHS)

PROGRAM SUPPORT CENTER (PSC)

SUPPLY CHAIN MANAGEMENT SERVICES (SCMS)

STATEMENT OF OBJECTIVES - FULL-DETAIL MASTER DRAFT

Executive Summary The U.S. Department of Health and Human Services (HHS), Program Support Center (PSC), Supply Chain Management Services (SCMS) seeks to modernize its enterprise Inventory Management System (IMS) and establish a secure, resilient, scalable, interoperable, accessible, and sustainable digital supply chain capability supporting routine operations and emergency-response conditions.

The modernization is intended to achieve more than replacement of aging technology. HHS seeks measurable improvements in inventory accuracy and visibility, warehouse execution, order fulfillment, transportation visibility, customer self-service, financial integration, data quality, auditability, cybersecurity, operational resilience, user productivity, and long-term sustainability.

The Government intends to use a performance-based Statement of Objectives approach. Offerors are expected to apply relevant commercial products, supply-chain, systems-integration, data, cybersecurity, implementation, and federal experience to propose an integrated solution and an Offeror-developed PWS that translates Government objectives into measurable performance requirements. The Government prefers mature commercial capabilities and supported configuration over unnecessary custom development.

The solution must preserve Government ownership and portability of Government data, integrate reliably with Government-designated enterprise systems including UFMS, PRICES, Appian/WorkSmarter, and services, support applicable HHS security and federal compliance requirements, and avoid unreasonable barriers to future competition or transition. Success will be measured by sustained mission improvement rather than by software deployment alone.

The modernized environment must support SCMS personnel and authorized customers with reliable information, efficient workflows, reliable integrations, effective controls, and a sustainable operating model.

1. Purpose and Acquisition Intent The purpose of this acquisition is to obtain both the commercial technology platform (preferably Software-as-a-Service [SaaS] or Platform-as-a-Service [PaaS]) and the professional implementation services, systems-integration expertise, program-management capabilities, cybersecurity support, data-migration services, organizational-change support, training, deployment, operations and maintenance, and related capabilities necessary to modernize and sustain the HHS/PSC/SCMS enterprise IMS. The Government is pursuing a technology-agnostic acquisition to encourage full and open competition; the modernization is not restricted to any single commercial product or platform (e.g., Appian). Offerors shall clearly delineate the proposed commercial software solution from the professional integration services required for configuration, deployment, and sustainment. In both technical and business/pricing volumes, offerors shall structure proposals to distinguish recurring technology licensing/subscription costs from non-recurring implementation, configuration, and data-migration labor services.

The selected Contractor shall be responsible for delivering an integrated modernization outcome within the scope of the resulting contract. Government participation, review, approval, or acceptance does not relieve the Contractor of responsibility for the quality and completeness of Contractor-controlled performance. The Government does not intend this SOO to prescribe every technical component, configuration step, development task, or project-management activity. Offerors shall propose the specific approach that best achieves the Government objectives while complying with mandatory HHS and federal constraints provided in the solicitation.

Where a mature commercial capability can satisfy the underlying business objective, the Government generally prefers use of that capability over unnecessary custom code. Where customization is proposed, the Offeror shall identify the requirement driving customization and describe the associated security, upgrade, regression-testing, maintenance, interoperability, portability, transition, lifecycle-cost, and technical-debt implications. Customization shall not unnecessarily impair supported product upgrades, Government data portability, future competition, or transition to another solution or service provider.

This SOO establishes the Government's mission objectives, outcome expectations, and high-level constraints. The solicitation and its appendices will provide the authoritative Government-furnished baselines, mandatory requirements, interfaces, performance definitions, security and compliance constraints, and other information necessary for equitable competition and accurate pricing. The Offeror-developed PWS shall address and remain consistent with both the SOO and those solicitation requirements.

2. Background and Mission Context SCMS provides inventory, warehousing, transportation, distribution, customer-support, and related supply-chain services in a mission environment that requires both routine efficiency and emergency readiness. Operational effectiveness depends on the accuracy, timeliness, integrity, traceability, and availability of information associated with goods, transactions, customers, facilities, carriers, and related financial processes.

The current legacy environment has exceeded its strategic technology lifecycle and presents increasing operational and technical challenges, including technical debt, rigid dependencies, limited interoperability, fragmented information, manual and duplicative processes, limited real-time visibility, increasing maintenance burden, and difficulty adapting rapidly to changing mission and federal technology requirements.

SCMS business processes are interconnected. A customer requirement can drive validation, allocation, warehouse execution, transportation, delivery confirmation, financial-support transactions, reconciliation, reporting, and customer service. Inventory receipts, adjustments, transfers, recalls, returns, and dispositions can create related operational, financial, records, security, and audit impacts.

The modernized IMS must support routine operating conditions and significant surge conditions. During emergencies, SCMS may need to rapidly identify available and committed inventory, prioritize demand, manage warehouse workload, track fulfillment and shipments, identify exceptions, and provide timely leadership visibility without abandoning required controls.

Modernization shall treat data, security, accessibility, records management, privacy, financial accountability, auditability, user adoption, and continuity as lifecycle concerns rather than activities deferred until deployment.

3. Desired Business Outcomes Improve physical-to-system inventory accuracy and end-to-end visibility across Government-designated inventory populations and locations, including accurate License Plate Number (LPN)/Tag-level control and traceability where applicable.

Improve receiving, inspection, put-away, storage, replenishment, cycle counting, picking, packing, staging, shipment, transfer, return, recall, quarantine, and disposition processes.

Reduce avoidable stockouts, expiration-related losses, excess inventory, manual reconciliation, duplicate data entry, and uncontrolled offline tracking.

Improve order fulfillment from authorized customer request through delivery, including visibility into backorders, partial fulfillment, priority requirements, shipment status, and exceptions.

Improve transportation visibility and interaction with Government-approved carriers and logistics providers, including rates where required, labels, tracking, proof of delivery, exceptions, and transportation-cost information.

Improve visibility into environmental and temperature-monitoring information applicable to refrigerated, temperature-controlled, and other environmentally controlled storage areas and affected inventory.

Improve secure customer self-service for approved catalogs, requisitions, order status, shipment status, tracking, historical transactions, notifications, and other Government-approved information.

Improve integration with UFMS, the HHS Revenue Invoicing Cost Estimation System (PRICES), and other authoritative Government financial processes without duplicating authoritative financial-system functions.

Ensure secure and maintainable interoperability with Government-designated HHS enterprise platforms and services, including the HHS-supported Appian and WorkSmarter environment, while avoiding unnecessary duplication of enterprise capabilities and unnecessary platform lock-in.

Improve data governance, master data, metadata, data quality, reporting, analytics, traceability, and portability.

Materially improve cybersecurity, support the required HHS authorization, align with applicable FedRAMP and Zero Trust requirements, and integrate with HHS security monitoring.

Improve availability, performance, recoverability, continuity, scalability, and surge resilience.

Reduce long-term technical debt, unnecessary custom code, fragile point-to-point integrations, unsupported components, and avoidable vendor dependence.

Improve user productivity and adoption through intuitive, role-appropriate workflows, mobile capabilities where appropriate, effective training, documentation, and change management.

Maintain Government ownership and practical portability of Government data and sufficient documentation and knowledge to support oversight, recompetition, and future transition.

4. Scope The scope encompasses the personnel, management, commercial technology, configuration, integration, approved development, data migration, cybersecurity support, testing, training, deployment, operations, maintenance, documentation, knowledge transfer, and continuous-improvement services necessary to establish and sustain the modernized IMS capability.

4.1 Business Capability Scope

Enterprise inventory management, including Item Master governance, quantity/status/location visibility, lot/batch and serial traceability, expiration and shelf-life controls, reservations/allocation, replenishment, counting, adjustments, transfers, returns, recalls, holds/quarantine, excess/obsolete inventory, and authorized disposition.

Warehouse management, including warehouse/location configuration, receiving, inspection/acceptance, put-away, slotting, internal replenishment, picking, packing, consolidation, staging, shipping, mobile execution, automatic identification, capacity/workload visibility, business continuity, and warehouse performance management.

Order, requisition, fulfillment, and distribution management, including intake, validation, approval, prioritization, allocation, backorder/partial fulfillment, modification/cancellation, exception management, emergency fulfillment, and end-to-end traceability.

Transportation management and carrier integration, including service selection information, shipment creation, labels, tracking, proof of delivery, delivery exceptions, lost/damaged/returned shipments, transportation costs, and performance visibility.

Customer self-service and customer relationship capabilities appropriate to authorized customer organizations.

Financial-support, billing, and reimbursable-service integration with UFMS, PRICES, and other Government-designated financial processes.

Operational, management, executive, customer, financial-support, audit-support, emergency-response, and analytical reporting using governed data definitions.

4.2 Implementation and Lifecycle Scope

Program and project management, integrated scheduling, risk/issue/decision management, stakeholder coordination, and quality management.

Business-process analysis and future-state design that distinguishes mission/policy/internal-control requirements from legacy-system limitations.

Solution architecture, cloud services, configuration, integration, data architecture, identity, cybersecurity, testing, deployment, and operations.

Data discovery, profiling, mapping, cleansing, conversion, migration, validation, reconciliation, archival/retention decisions, and legacy-data disposition.

Organizational change management, communications, training, SOP support, user readiness, adoption measurement, deployment, hypercare/stabilization, and transition to steady-state O&M.

Legacy-system transition and decommissioning after Government-approved operational, data, records, financial, security, integration, and continuity criteria are satisfied.

Transition-out and knowledge transfer sufficient to protect Government continuity and future competition.

4.3 Government Planning Baseline

The following Government planning baseline reflects information currently available for acquisition planning. Detailed site inventories, interface specifications, user distributions, data volumes, and other technical particulars may be refined in solicitation appendices or through Government-approved implementation discovery where they are not material to equitable competition.

Operating sites. The modernized IMS shall support three SCMS operating sites: the Frederick Labor and Moving site in Frederick, Maryland; the SCMS warehouse in North East, Maryland; and the SCMS site at Perry Point, Maryland. Detailed internal location hierarchies, including rooms, zones, aisles, racks, shelves, bins, staging areas, and other storage locations, shall be established or validated during implementation and site discovery.

Base operating hours. Base operating hours for the SCMS operating sites are 0700-1600. During emergency-response events, mission surges, continuity events, or other Government-directed priority operations, SCMS may extend operations beyond normal hours, including additional shifts, weekends, holidays, or continuous operations when mission requirements warrant.

Site conditions. Perry Point includes a controlled-substance vault and lockup cage, hazardous areas, controlled-access areas, restricted contractor-access areas, areas requiring Federal escort, and refrigerated storage areas. North East and Frederick include lockup cages, hazardous areas, controlled-access areas, restricted contractor-access areas, areas requiring Federal escort, and refrigerated storage areas. The solution and implementation approach shall also accommodate applicable temperature-controlled or otherwise environmentally controlled storage areas. Site-specific network and wireless conditions remain subject to Government validation.

User baseline. The current IMS supports approximately 50 internal HHS/PSC/SCMS users. For acquisition planning, solution sizing, and performance testing, Offerors shall assume a peak concurrent internal-user population of approximately 40-50 users and shall support at least 50 concurrent internal users while maintaining applicable performance requirements. Final future-state role/location distribution and external/customer-user counts remain to be established.

Scalability baseline. The stated user and concurrency figures are Government planning and performance-sizing baselines, not architectural ceilings. The proposed solution shall provide a practical means to accommodate reasonable growth in authorized users, transactions, integrations, data, storage, reporting, and emergency/surge workload without significant redesign or avoidable reimplementation. Offerors shall disclose material licensing, capacity, or commercial-service thresholds that could constrain such growth.

Warehouse equipment baseline. The Government currently owns eight Zebra handheld scanners distributed across the SCMS warehouse environment. Existing Government-furnished warehouse equipment is expected to remain in service with the modernized IMS where technically compatible, secure, and supportable. Site distribution, model/OS information, and other device details will be validated by SCMS and OCIO. Replacement is not part of the baseline scope unless a compatibility, security, supportability, or lifecycle issue is identified and the Government approves a resolution.

Equipment compatibility. Offerors shall identify known compatibility limitations, required drivers/connectors, operating-system dependencies, security constraints, manufacturer-support limitations, and other lifecycle dependencies associated with retained Government-furnished warehouse equipment. A general assertion of compatibility shall not substitute for identification of material assumptions or constraints. Replacement or material modification of Government-furnished equipment shall require Government approval unless otherwise provided by the resulting contract.

Facility outlook. No locations are currently expected to open, close, relocate, or materially change during the anticipated period of performance. The three identified SCMS operating sites constitute the current Government planning baseline; material changes arising during performance will be addressed under the resulting contract.

5. Business Capability Objectives

5.1 Inventory Management

The IMS shall provide an integrated enterprise capability to control, track, manage, and report Government-designated inventory throughout its lifecycle. The solution shall support timely visibility by item, quantity, unit of measure, location, status, availability, condition, License Plate Number (LPN)/Tag, lot/batch, serial number, expiration/shelf life, reservations, custody, and transaction history as applicable to each inventory population.

The solution shall support governed Item Master and reference data; controlled units of measure; receiving and acceptance; LPN/Tag, lot, and serial traceability; expiration management; reservation and allocation; replenishment; demand information; stockout/backorder management; transfers and internal movements; controlled adjustments; cycle counting and physical inventory; quarantine/holds; damaged inventory; returns; recalls; excess/obsolete inventory; disposition; condition management; and exception management. Material status changes, adjustments, overrides, approvals, and disposition actions shall be traceable.

5.2 Warehouse Management

The IMS shall support efficient, accurate, safe, and controlled warehouse execution across Government-designated facilities. Warehouse configuration shall support facility/location hierarchies, storage attributes and restrictions, receiving docks, staging areas, secure or special storage, and other Government-defined structures without unnecessary custom development.

The solution shall support receiving, dock-to-stock processing, put-away, slotting, forward-pick/reserve storage, replenishment, multiple picking strategies where appropriate, short-pick exception handling, packing, consolidation, staging, shipping, warehouse transfers, mobile execution, barcode/automatic identification, and controlled degraded-connectivity procedures where required. RFID or other advanced identification technology shall be used only when required or justified by measurable mission benefit.

Warehouse supervisors shall have role-appropriate visibility into capacity, inbound workload, put-away, replenishment, picking, packing, staging, shipment, counts, exceptions, and other operational work queues. Site readiness shall address configuration, master data, labels, devices, network, security, user access, interfaces, migration, training, SOPs, support, testing, continuity, and cutover.

Where Government environmental or temperature-monitoring capabilities are maintained outside the IMS, those designated systems shall remain authoritative for the environmental measurements they produce unless the Government expressly determines otherwise. The IMS shall support Government-approved integration or data exchange sufficient to associate relevant temperature readings, environmental conditions, excursions, alerts, or status information with affected storage locations, inventory, LPNs/Tags, lots/batches, or transactions, as defined by the Government. The IMS is not required to replace an existing Government environmental-monitoring system unless expressly stated in the solicitation.

5.3 Order Fulfillment and Distribution

The solution shall support authorized customer requirements from intake through delivery with controlled validation, approval, prioritization, allocation, backorder/partial fulfillment, warehouse execution, shipment, delivery, cancellation, return, and exception processing. Orders and related transactions shall be uniquely identifiable and traceable through associated inventory, warehouse, shipment, financial-support, and exception events.

The system shall support Government-defined priority mechanisms and emergency fulfillment without bypassing required security, inventory, financial, or audit controls. Backordered demand and unresolved exceptions shall remain visible until resolved or otherwise dispositioned.

5.4 Transportation

The solution shall integrate with Government-approved carriers and logistics providers using secure and maintainable mechanisms. Capabilities shall support applicable shipment creation, labels, tracking, status, proof of delivery, delivery exceptions, return-to-sender processing, transportation-cost visibility, and carrier performance. The Government does not require a standalone transportation-management product when integrated commercial capabilities can satisfy the objectives.

5.5 Customer Self-Service

Authorized customer organizations shall have secure and accessible self-service capabilities appropriate to their role, which may include approved catalog access, requisition submission, order status, shipment tracking, historical transactions, consumption information, notifications, and structured inquiries. Customer access shall maintain appropriate identity, segmentation, privacy, financial, inventory, and approval controls.

5.6 Financial Integration and Reimbursable Services

The IMS shall support accurate, timely, traceable, and reconcilable information needed for approved SCMS financial, billing, and reimbursable-service processes. The solution shall support required integration with the HHS Revenue Invoicing Cost Estimation System (PRICES), including transmission of Government-designated SCMS billing information, and with UFMS and other Government-designated financial capabilities, without duplicating authoritative financial functions assigned to those systems.

Integration shall support Government-approved operational, billing, and financial data; transaction references; error handling; reconciliation; auditability; and appropriate timing. The final interface design shall determine which transactions require immediate processing and which may use asynchronous, batch, or other approved methods based on authoritative HHS financial and system-owner requirements. The future-state system-of-record responsibilities among IMS, PRICES, UFMS, and other financial capabilities shall be defined by the Government.

5.7 Reporting and Analytics

The modernized environment shall provide role-appropriate dashboards, reports, alerts, extracts, and analytical access using governed definitions and authoritative source data. Formal measures shall be consistently defined, traceable to source data, and controlled when logic changes. The solution shall support operational and management reporting, enterprise BI integration, ad hoc analysis for authorized users, accessible reporting, and practical machine-readable export of Government data.

Advanced analytical and machine-assisted capabilities, including artificial intelligence (AI), generative AI, machine learning, predictive analytics, optimization, natural-language assistance, knowledge retrieval, anomaly identification, and similar capabilities, are optional enhancements unless expressly identified by the Government as mandatory requirements in the solicitation or resulting contract.

5.7.1 Optional Advanced Capabilities

Offerors may propose mature commercial advanced capabilities where they provide measurable mission or operational benefit without disproportionately increasing implementation risk, cybersecurity risk, data exposure, vendor dependence, or lifecycle cost. Potential uses may include user assistance, natural-language interaction, knowledge retrieval, report or query assistance, anomaly identification, demand or inventory insights, workflow assistance, and other decision-support functions.

These capabilities are not required to satisfy the core IMS objectives unless expressly designated as mandatory by the Government. The absence of an optional advanced capability shall not, by itself, render an otherwise compliant solution unacceptable. Offerors shall clearly identify whether proposed optional capabilities are included as standard commercial functionality, configurable functionality, separately priced options, or potential future enhancements.

Any advanced capability implemented under the resulting contract shall be subject to Government approval and applicable HHS and federal requirements for cybersecurity, privacy, records management, accessibility, data governance, information protection, human oversight, and acceptable use. Government data shall not be used to train or improve publicly available or shared models without express Government authorization.

Machine-generated recommendations, summaries, predictions, or other outputs shall not replace required Government judgment, approvals, internal controls, or inherently Governmental decision-making. Where practical, optional capabilities should be capable of being enabled, limited, or disabled without materially impairing required core IMS functionality.

The modernized architecture and governed data foundation should avoid unnecessary barriers to future adoption of Government-approved advanced analytical and machine-assisted capabilities as mission needs, technology, policy, and risk considerations evolve.

5.8 DSCSA and EPCIS Interoperability Comment by Boggs, Richard (OS/ASA/PSC/RLO): I added this DSCSA/EPCIS interoperability section to clearly document the compliance requirements our new IMS must meet to support safe, lawful handling of serialized pharmaceuticals. This capability is essential for maintaining full traceability and ensuring we can exchange EPCIS data with McKesson and other trading partners without manual workarounds. Including it now helps set accurate expectations for offerors and prevents gaps that have historically caused operational delays and compliance risk. Overall, this addition strengthens the SOO by aligning the modernization effort with the regulatory obligations our program must uphold.

To ensure full compliance with the Drug Supply Chain Security Act (DSCSA) and enable electronic, interoperable traceability of prescription drug products at the package level with wholesale distributors (e.g., McKesson), trading partners, and regulatory authorities, the modernized IMS shall natively incorporate a purpose-built DSCSA compliance capability operating within the core FedRAMP boundary. The solution shall support:

a) EPCIS 1.2+ / 2.0 Ingestion & Transmission Native, automated ingestion, parsing, validation, and transmission of Electronic Product Code Information Services (EPCIS) XML and JSON-LD data files capturing Object, Aggregation, Transaction, and Transformation events.

b) Secure AS2 Communication Built-in Applicability Statement 2 (AS2) secure transport protocols for encrypted certificate-authenticated business-to-business (B2B) data exchanges with commercial pharmaceutical distributors and manufacturers.

c) Verification Router Service (VRS) Integration Direct integration with industry VRS networks to execute real-time verification of product identifiers (SNI) for saleable returns and suspect product investigations.

d) GS1 DataMatrix Serialization Support Native scanning, parsing, and data validation of 2D DataMatrix barcodes capturing Global Trade Item Numbers (GTIN), National Drug Codes (NDC), alphanumeric serial numbers, lot/batch numbers, and expiration dates at the individual package level.

e) Aggregation & De-Aggregation Management of parent-child relational inference (Pallet SSCC Case SSCC Package SGTIN-96) without requiring physical breakdown or individual scanning of sealed outer containers.

f) EPCIS Exception Management Automated quarantine workflows and discrepancy resolution for operational exceptions (e.g., physical product received prior to corresponding EPCIS data file arrival, data mismatches, or missing transaction records).

g) DSCSA Verification & Investigation Workflows Structured, auditable workflows capable of rapidly generating and transmitting compliant Transaction Information (TI) and Transaction Statements (TS) within 24–48 hours upon official request from the FDA, state authorities, or trading partners.

h) Authorized Trading Partner (ATP) Credentialing Automated capture, verification, and management of Global Location Numbers (GLN), state licensing, and FDA registration credentials across all supply chain trading partners.

i) Six-Year Immutable Record Retention Secure, tamper-evident cloud archival of all DSCSA transaction data, event logs, exception resolutions, and digital pedigrees for a mandatory minimum of six (6) years.

j) Modern Interoperability Middleware Secure, document-based RESTful APIs to expose serialized event data and status information to authorized external systems without manual re-keying or data transformation.

k) Shipment Visibility & Event Management Real-time visibility and chain-of-custody tracking across all electronic custody-transfer milestones and product status transitions throughout the distribution lifecycle.

l) Native Compliance Engine Delivery of all DSCSA/EPCIS functionality natively within the authorized SaaS/PaaS platform boundary, eliminating reliance on non-FedRAMP third-party plug-ins or unvetted external services.

6. Technical Architecture, Cloud, and Integration Objectives The Contractor shall propose a secure, resilient, scalable, interoperable, maintainable, observable, and sustainable architecture that supports the business objectives and reduces dependence on obsolete technology, specialized infrastructure, fragile integrations, excessive customization, and other sources of technical debt.

Use mature commercial capabilities and supported configuration where they can satisfy Government objectives; identify material third-party and proprietary dependencies and capabilities dependent on future vendor releases.

Provide appropriate environment separation for configuration/development, testing, training, staging, production, recovery, and other required environments, with appropriate protection of non-production data.

Maintain controlled configuration, versioning where supported, release management, technical documentation, architecture baselines, and lifecycle management of significant components.

Use a Government-approved cloud approach, preferably SaaS/PaaS or an appropriate combination, consistent with final HHS architecture and security requirements. Identify any IaaS components and why they are required.

Satisfy the Government-determined FedRAMP impact level and identify the actual authorization status of proposed services. A service shall not be represented as FedRAMP authorized solely because its hosting provider offers other authorized services.

Support normal and emergency scalability for users, transactions, APIs, data, storage, reporting, warehouse scanning, customer portal use, and integrations, and disclose commercial-service or licensing constraints affecting scale.

Support the approved availability and geographic-resilience objectives and maintain Government data location consistent with HHS/federal requirements.

Provide secure, reliable, maintainable, observable integration with Government-designated systems. Use modern APIs or other standards-based patterns where appropriate; do not force a single integration protocol where another approved pattern better meets business, security, reliability, or lifecycle needs.

Interface classification and net-new integration baseline. Offerors are advised that the legacy Tecsys Elite v9.4.4 system currently operates in a siloed architecture and does not maintain automated electronic interfaces with the HHS Unified Financial Management System (UFMS), the PRISM procurement system, or the PRICES revenue invoicing system. Consequently, establishing integration with these federal systems represents net-new interface development and integration engineering under this contract, rather than the migration of existing interfaces.

Confirmed Government integration requirements for the modernized IMS include:

1. UFMS (Financials: reimbursable billing, general ledger adjustments, inventory valuation synchronization);

2. PRICES (Reimbursable billing and customer cost estimation);

3. PRISM (Procurement: purchase orders, vendor catalog mapping, contract data consolidation);

4. Appian/WorkSmarter (Required enterprise platform compatibility and workflow interoperability);

5. Government-designated enterprise identity and access management services (SSO/MFA/PIV); and

6. Government-designated cybersecurity logging and monitoring capabilities (HHS SOC telemetry).

Anticipated IOC integrations requiring final Government/system-owner validation include Prime Vendor ordering interface(s), commercial transportation/carrier services required for shipment processing, tracking, and hazardous-materials documentation, and designated environmental/temperature-monitoring systems or data sources. Enterprise BI/data/analytics, IT service-management, notification, API/integration, and other HHS/PSC services shall be treated as mandatory, future, or optional only when designated by the Government. The final interface inventory developed during implementation shall define classification, ownership, data schemas, transmission direction, technical protocol (REST/JSON, EDI ANSI X12), volume, frequency/trigger, latency thresholds, security controls (mTLS, OAuth 2.0), reconciliation and error-handling procedures, test resources, and respective Government and Contractor responsibilities.

6.1 HHS Enterprise Platform Interoperability

The modernized IMS shall operate effectively within the HHS enterprise technology environment. Compatibility with and secure, maintainable interoperability across the IMS solution with the HHS-supported Appian/WorkSmarter platform is a Government requirement. Compatibility shall not be limited to a single IMS module or business function; however, compatibility does not mean that every IMS transaction must pass through Appian/WorkSmarter.

The proposed solution shall support standards-based integration and information exchange with Appian/WorkSmarter for Government-designated business processes, workflows, approvals, notifications, user interactions, data exchanges, and other enterprise processes. Offerors shall identify material assumptions, dependencies, licensing considerations, interface requirements, commercial-product constraints, and Government-furnished services associated with achieving and maintaining this interoperability.

This interoperability requirement does not, by itself, prescribe Appian as the underlying IMS product, hosting environment, or development platform unless the solicitation expressly establishes such a requirement. The specific business-process boundary, system-of-record responsibilities, interfaces/APIs/events, authentication methods, Government-furnished Appian/WorkSmarter environments and licenses, and related technical/support responsibilities remain cross-functional Government decisions. Offerors shall demonstrate that their proposed architecture can support the required interoperability and shall clearly identify material assumptions, dependencies, constraints, and Government actions on which that approach relies. Offerors shall not be required to infer unresolved Government-owned workflow, system-of-record, licensing, environment, or platform-resource decisions; the solicitation shall provide sufficient resolved requirements, assumptions, ranges, or Government-furnished baselines for equitable competition and pricing.

Maintain an interface inventory and controlled error handling, retry/reprocessing, reconciliation, monitoring, and transaction-integrity mechanisms appropriate to interface criticality.

Provide sufficient observability through metrics, logs, events, health indicators, and alerts to support operations, performance management, security, troubleshooting, and Government oversight.

7. Data Governance and Migration Objectives Government data shall be managed as a strategic Government asset. HHS shall retain ownership and practical access to Government information, including the ability to analyze, export, retain, archive, transfer, and migrate information without unreasonable vendor restrictions.

The Contractor shall support a governed data architecture covering significant data domains, authoritative sources, stewardship, master/reference data, metadata, lineage, quality, retention, archival, deletion/disposition, masking/protection where required, and appropriate analytical use. Master data such as items, customers, locations, organizations, units of measure, status codes, reason codes, and other shared values shall be controlled to reduce duplication and inconsistent definitions.

Authoritative-source principle. For each material data domain, workflow state, and transaction, the Government shall designate or approve an authoritative source/system of record. The solution shall avoid uncontrolled duplicate maintenance of authoritative data across systems and shall use governed interfaces, synchronization, reconciliation, and stewardship controls where information must be replicated or shared. Unresolved authoritative-source decisions shall be documented and elevated for Government resolution rather than embedded as undocumented solution assumptions.

Data migration shall include discovery, profiling, mapping, Government-approved cleansing and duplicate resolution, transformation, rehearsal, validation, reconciliation, exception management, security, cutover, and evidence. The Government and Contractor shall determine whether each in-scope legacy information population is migrated to production, retained in an accessible historical repository, archived, transferred, retained temporarily, or disposed of under approved authority.

The Government has limited vendor-provided documentation for the legacy IMS. Available information includes help documentation contained within the existing system, available Government-developed SOPs/reports/operational materials, Government-owned data and approved data extracts, administrative access to the current system, and reasonable access to knowledgeable SCMS personnel and other Government SMEs with institutional, technical, and operational knowledge. The Government does not represent that complete vendor user guides, technical documentation, data dictionaries, interface specifications, architecture documentation, source code, or other vendor-developed artifacts are available or releasable. Proprietary, licensed, security-sensitive, or otherwise restricted information will be furnished only to the extent the Government is authorized to disclose it. Offerors shall account for reasonable legacy-system discovery, knowledge capture, and documentation activities.

Legacy discovery and knowledge capture. Offerors shall distinguish material assumptions based on available legacy information from facts that require post-award validation. The Contractor shall use discovery activities to convert relevant institutional knowledge, observed legacy behavior, configuration information, interface behavior, data definitions, business rules, and operational procedures into current Government-usable documentation. Discovery shall not be used to recreate undocumented legacy constraints without validating whether they remain necessary future-state requirements.

The migration objective is 100 percent approved disposition accountability for Government-designated in-scope legacy information; this does not mean that 100 percent of legacy information must be migrated into the production IMS database. For acquisition planning and proposal pricing, Offerors shall assume the following data migration baseline: (1) Active Master & Operational Data: 100% of governed master data (Item Master, locations, customers, vendors), all active on-hand inventory balances, open purchase orders, and open customer fulfillment requisitions shall be cleansed, reconciled, and migrated into the production IMS; (2) Historical Transaction Data: Exactly three (3) years of closed historical transaction records (receipts, orders, adjustments, and cycle counts) shall be migrated into the modernized IMS reporting repository; and (3) Cold Storage / Archival: All historical transaction records and legacy logs older than three years shall be extracted, formatted into non-proprietary flat-file extracts (e.g., CSV/JSON), and archived to a Government-designated secure cloud storage repository.

Data migrated into the modernized environment shall satisfy Government-approved completeness, accuracy, relationship, control-total, inventory, financial, and other acceptance criteria. The Government shall approve final inventory opening balances, migrated lot/serial quantities, and applicable financial reconciliation at cutover prior to legacy system decommissioning.

8. Identity, Cybersecurity, Privacy, Records, and Accessibility Objectives

8.1 Identity and Access

The IMS shall integrate with Government-designated identity and access-management capabilities and support approved enterprise SSO, phishing-resistant MFA where required, PIV/CAC for applicable Government users, secure external-user identity where needed, role-based or attribute-based authorization, least privilege, segregation of duties, privileged-access controls, service-account governance, provisioning/deprovisioning, periodic access review, and appropriate session security.

8.2 Cybersecurity and Authorization

The Contractor shall design, implement, operate, and maintain the solution in accordance with applicable HHS cybersecurity policy, FISMA, NIST guidance, FedRAMP requirements, the Government-approved system categorization, and the HHS authorization process. Security shall be integrated throughout the lifecycle and shall reflect the actual production architecture and shared-responsibility model.

Support the HHS assessment and authorization process and maintain required security artifacts and evidence.

Implement assigned security controls and identify inherited, shared, Government-implemented, provider-implemented, and Contractor-implemented responsibilities.

Perform continuous vulnerability management, approved security testing, remediation, incident support, logging, monitoring, encryption, key/certificate management, secure configuration, patch management, malicious-code protections, and data-exfiltration protections as applicable.

Integrate required telemetry and security-relevant logs with Government-designated monitoring capabilities.

Support applicable HHS Zero Trust objectives across identity, devices, applications/workloads, networks, and data. Zero Trust shall not be treated as a single commercial product.

Use secure and controlled delivery practices, including version control, automated pipelines where technically appropriate, security testing of custom code, dependency management, secrets management, and separation of duties in production deployment.

Support applicable Cybersecurity Supply Chain Risk Management requirements, including SBOM information to the extent required and available, third-party dependency visibility, and monitoring of material supplier risks.

Planning security objective: no unresolved Critical vulnerabilities at production deployment unless expressly accepted by authorized Government security officials. Treatment and remediation timelines for High and other findings shall follow final HHS requirements and Government risk decisions.

8.3 Privacy

The IMS processes standard federal employee user-account PII, vendor contact/account data, and customer account records for ordering and billing, but does not process, store, or act as a system of record for patient Protected Health Information (PHI). Offerors shall design role-appropriate privacy controls, data minimization, and protection of non-production data calibrated to this user-account baseline. The Contractor shall support privacy analysis, data minimization, role-appropriate privacy controls, protection of non-production data, appropriate logging practices, privacy documentation, incident support, and secure export based on the approved data inventory and Government privacy requirements.

8.4 Federal Records Management

The IMS shall support Government-approved records schedules, retention, retrieval, preservation, holds, transfer, export, archival, authorized disposition, and associated metadata. The Contractor shall not independently determine whether information is a federal record or establish retention periods. Legacy transition and contract transition shall not result in loss of records HHS is required to retain.

Government planning baseline for historical accessibility: financial records are expected to remain accessible in perpetuity. Other IMS records are expected to remain accessible for a minimum of seven years, with ten years preferred where technically and economically practicable without materially affecting system performance, capacity, security, or lifecycle cost. Final retention periods and disposition authorities remain subject to Records Management and Finance validation and applicable approved records schedules. Records may reside in the production IMS, another authoritative Government system, or a Government-approved archive/repository, provided required security, integrity, auditability, search, retrieval, export, legal-hold, and authorized-disposition capabilities are maintained.

8.5 Section 508 Accessibility

Applicable information and communication technology delivered under the contract shall conform to Government-defined Section 508 requirements. Accessibility shall be addressed throughout design, configuration, development where applicable, testing, documentation, training, reporting, customer-facing capabilities, mobile capabilities, acceptance, regression testing, and maintenance.

9. Testing, Performance, Support, and Continuity Objectives

9.1 Testing and Acceptance

The Contractor shall establish a comprehensive risk-based test program with traceability from approved requirements/objectives through design/configuration, test cases, results, defects, and acceptance. Contractor quality assurance shall precede Government UAT and acceptance.

The Contractor shall maintain practical bidirectional traceability among applicable SOO objectives, solicitation requirements, the accepted PWS, solution configuration/design, test evidence, defects, deliverables, and Government acceptance decisions so that material requirements can be verified throughout implementation and transition.

Functional and end-to-end business-process testing, including meaningful exception scenarios.

Integration testing with Government-designated connected systems or approved test environments, including error handling, duplicate prevention, reprocessing, reconciliation, and security.

UFMS, PRICES, Appian/WorkSmarter, Prime Vendor, carrier/transportation, identity, environmental/temperature-monitoring, security-monitoring, and other Government-designated critical-interface testing as applicable.

Data-migration and reconciliation testing using representative control totals, record counts, inventory quantities, financial values, relationships, and Government-approved sampling.

Security, role/access, Section 508 accessibility, performance, load, surge/stress, endurance where appropriate, failover, backup/restore, disaster-recovery, regression, UAT, and operational-readiness testing.

Defined entry/exit criteria and Government-approved defect-severity definitions. A calendar date alone shall not constitute completion of a test phase.

Acceptance principle. Government review or acceptance of an individual deliverable, test result, increment, or deployment decision shall not by itself constitute acceptance of the entire system or relieve the Contractor of unresolved contractual requirements, latent defects, security obligations, data-reconciliation responsibilities, or other continuing obligations. Final contractual acceptance terms and remedies shall be established by the Contracting Officer in the solicitation and resulting contract.

9.2 Performance and Availability

Formal service levels shall be stated as measurable requirements only after the Government defines the service population, calculation method, measurement point, workload assumptions, exclusions, reporting period, data source, and responsibility for validation.

Until those definitions are finalized in the solicitation or resulting contract, numeric values shown in this SOO are planning targets or candidate performance levels and shall not, solely by their appearance in this SOO, be interpreted as fully defined contractual SLAs. The final requirement shall control once the Government establishes the applicable population, formula, measurement point, workload assumptions, exclusions, reporting period, authoritative data source, and validation responsibility.