TBLD DRAFT PWS dtd 11 June.pdf

CUI

Department of Defense (DOD)

Joint Operational Medicine Information Systems (JOMIS)

Theater Blood-Mobile (TBLD-M) Continuous Improvement, Enhancement, Testing and Fielding, Maintenance and Support

Performance Work Statement (PWS)

Contract Number: HT003825XXXXX

Date: June 2025 Version: 1.0

Controlled by: Defense Health Agency (DHA) Controlled Unclassified Information (CUI) Category: CD-DHMS Limited Dissemination Control: DL only Point of Contact (POC): Elizabeth.m.ruckwardt.civ@health.mil mailto:Elizabeth.m.ruckwardt.civ@health.mil ii

Table of Contents

1 Background

1.1 Description of Services

2 Purpose and Scope 3 Desired Outcomes/Tasks/Objectives

3.1 Capability Continuous Improvement

3.1.1 Transition-In

3.1.2 Capability Enhancement

3.1.3 Design

3.1.4 Application Development and Enhancement

3.2 Working in an Agile Environment

3.2.1 Development Landscape and Future Environment

3.3 Capability Interfaces and Low-Side Repository

3.3.1 Application Interface

3.4 Testing

3.5 Fielding Support

3.6 Training Material Support

3.6.1 Training Development

3.6.2 Functional and Technical Training Documentation

4 Period of Performance 5 Transition Period

5.1 Transition-In Period

5.2 Transition-Out Period

6 Place of Performance 7 Hours of Operation 8 Recognized Federal Holidays 9 Travel 10 Other Direct Costs (ODC) 11 Government Furnished Property (GFP), Equipment (GFE), and Services

11.1 Services

11.2 Facilities

11.3 Equipment

11.4 Materials

12 Contractor Furnished Items and Services

12.1 Services

12.2 General

12.3 Materials

iii

12.4 Equipment

13 Manpower Reporting 14 Data Rights 15 Information Technology and Security

15.1 Training

15.2 Access to DHA IT

15.3 System Authorization Access Request, Defense Department (DD) Form 2875

15.4 Cybersecurity Requirements for Non-DOD IT or Covered Contractor Information Systems ... 20

15.4.1 NIST SP 800-171, DOD Assessment Methodology

15.4.2 Cybersecurity Maturity Model Certification (CMMC)

15.5 Cloud Computing

15.6 Cyber Incident Reporting Requirement

15.7 Malicious Software

15.8 Media Preservation and Protection

15.9 Access to Additional Information or Equipment Necessary for Forensic Analysis

15.10 Cyber Incident Damage Assessment Activities

15.11 Other IS Security Measures

15.12 Maintenance of Government Data

15.13 Supply Chain Risk

15.14 Risk Management Framework (RMF) for DOD IT

16 Definitions 17 Acronyms 18 Other Applicable Publications, DHA Administrative Instructions, etc 19 Contracting Officer Representative 20 Contract Operations Staff 21 Post-Award Conference/Periodic Progress Meetings 22 Contract Kick-Off 23 Personal Conduct 24 Physical Security 25 Security Management 26 Personnel Security 27 Contractor Personnel

27.1 Onboarding and Training

27.2 CAC Requirements

27.3 Non-Disclosure Agreement

27.4 Organizational Conflict of Interest (OCI)

iv

28 Personally Identifiable Information/Protected Health Information, Procurement, and Federal Information Laws

29 Records Management 30 Freedom of Information Act 31 Systems of Records 32 Privacy Impact Assessment (PIA) 33 Data Sharing Agreement (DSA) 34 Privacy Act and HIPAA Training 35 HIPAA Business Associate General Provisions 36 Breach Response

36.1 Definitions Related to Breach Response

36.1.1 Breach

36.1.2 Possible Breach

36.1.3 Confirmed Breach

36.1.4 HHS Breach

36.2 Cybersecurity Incident

36.3 General

36.4 Reporting Provisions

36.5 Individual Notification Provisions

36.6 Application of Breach Requirements

37 Protected Health Information 38 Processing Procurement Sensitive Information 39 Reporting Requirements

39.1 PEO DHMS Cost, Schedule, Performance Report

39.2 Contractor Work Breakdown Structure (CWBS)

39.3 Quality Control (QC)

40 Quality Assurance (QA) 41 Technical Exhibits

41.1 Deliverables Schedule

42 Attachments Appendix A: Relevant Systems Impacted by TBLD-M

Table of Tables

Table 1: Test and Evaluation Severity and Category Code Table 2: Deliverables Schedule

1 Background

1.1 Description of Services

The Program Executive Office, Defense Healthcare Management Systems (PEO DHMS) is a key Federal Health Information Technology (IT) partner responsible for delivering the single Electronic Health Record (EHR) and other Health IT for the Department of Defense (DOD), Department of Veterans Affairs (VA), and the United States Coast Guard (USCG). As part of PEO DHMS, the Joint Operational Medicine Information Systems (JOMIS) Program Management Office (PMO) is responsible for developing, deploying, sustaining, and modernizing operational medicine (OpMed) IT systems that support the delivery of comprehensive health services to deployed forces across the full Range Of Military Operations (ROMO). The OpMed functional areas supported by JOMIS are Medical Command and Control (MedC2), Medical Situational Awareness (MedSA), Medical Logistics (MedLOG), Health Care Delivery (HCD), and Patient Movement.

JOMIS is preparing to transition from development to continuous improvement, enhancement, and continued fielding of the Theater Blood-Mobile (TBLD-M) capability for operational blood management, which will be used as an integral part of the blood system and health support capabilities employed during all military operations across the geographic Combatant Commands (CCMDs) and during fleet forces operations. Blood operations span challenging environments where Theater events and limited infrastructure make joint medical response, from first responder care to Theater hospitalization capabilities, difficult to provide across the Joint Forces. These blood support functions track the total life cycle of blood, from the point of origin/donor to the transfused patient or point of destruction, so that quality blood products are available for clinical services. However, in the operational environment, the blood community often works in medical support facilities that have Denied, Degraded, Intermittent, or Limited (DDIL) connectivity to DOD enterprise networks.

This capability marks a transition from the legacy Theater Medical Data Store (TMDS) application which collects data, tracks, and reports on blood activity via a web browser. With the legacy solution, limited connectivity poses a risk to data capture, jeopardizing the integrity of the blood asset supply chain. Blood operation management and communications must work offline in DDIL environments, thus utilizing store and forward capabilities to send data as close to real-time as possible to avoid interrupting or compromising HCD, especially during emergency situations.

Theater Blood (TBLD) will significantly change the method of blood asset collection, tracking, and disposition of blood products data throughout the enterprise, providing a modernized solution to make data and blood quality visible, accessible, and trusted by users supporting the warfighter and other operational stakeholders.

2 Purpose and Scope This is a non-personal services contract to provide TBLD-M capability enhancement, test, fielding, and sustainment, support.

Most Theater settings lack the ability to reliably capture data electronically, maintain automated records at the local facility, and exchange data with the enterprise, thereby limiting global visibility of walking blood banking and blood inventory, consumption, and demand. This impinges on the ability to deliver operational medical logistics support effectively to soldiers downrange. Logistics information regarding blood operations needs to be available in an electronic format for users in the field, independent of available network connections.

3 Desired Outcomes/Tasks/Objectives The key objective of TBLD-M is to capture and organize information related to the collection and inventory−actual and/or predicted consumption, shelf-life, and distribution of blood products according to formats and timelines required by the Armed Services Blood Program Office for Class VIII (B) blood product management. Blood operations include five (5) key sub-capabilities that manage data around blood donors; inventory levels; blood transfusion to patients; facility and enterprise reporting; and system/user administration. The key sub-capabilities are listed below:

1. Donor Management

2. Inventory Management

3. Transfusion Management

4. Report Management – an interface with the Medical Common Operating Picture (MedCOP) for data transfer.

5. Administration Management – user, device, facility configuration, data integrity, and data synchronization management.

The Government is procuring Contractor support to ensure delivery of the right blood operations data into the right hands at the right time so that JOMIS can support Joint Forces and Commander decision-making for MedC2 planning and execution.

The current product design is comprised of three (3) major software components that work together to orchestrate and deliver a coordinated data service. These components include a central data source, an intermediate data source scoped to a given facility or unit, and a thick client for interaction with the capability.

The Contractor shall provide all support required for continuity of application software operations including, but not limited to, ingest the existing program code/data, capability enhancement, release and deployment support, testing, integration, maintenance, and preservation of TBLD-M. Due to the mission critical nature of the product, the JOMIS objective is to ensure the application is operational and accessible without interruption.

3.1 Capability Continuous Improvement

The Contractor will be responsible for the Continuous Integration and Continuous Delivery (CI/CD) of the system. This system shall implement the required operable system interfaces to maintain continuous Authority To Operate (ATO). The Contractor shall ingest all existing program code/data and continue to develop, enhance, and provide support services to TBLD-M capabilities utilizing data sources as determined by the Government. The following areas should be addressed as part of capability continuous improvement:

3.1.1 Transition-In

The Contractor shall ensure a smooth and efficient transition of the TBLD Capability program with no service disruption to vital Government business and no service degradation during and after transition.

This program is critically important to our warfighters and allies globally. The objectives are to ensure the following:

• Successful transition of service, code, hardware, and software for the identified scope of work from the outgoing contractor.

• Zero disruption to current work processes and support.

3.1.2 Capability Enhancement

The Contractor shall enhance or add additional capability to the TBLD-M application, to include, but not limited to, epics/functionality requested by operational stakeholders and approved in accordance with the TBLD User Agreement. Performance will also entail providing ongoing maintenance and operations support after initial fielding of the TBLD capability, including but not limited to, bug fixes, patches, and enhancements required for interoperability. This will require the Contractor to integrate processes with the Deployment Team.

3.1.3 Design

The Contractor shall conduct design, development, enhancements, product and testing support, and enhancement/fix activities with the TBLD Value Team, including collaborative software design, data design, and architecture design. TBLD-M design will accommodate complete integration with Operational Medicine Data Service (OMDS) and other JOMIS solutions.

The Contractor shall deliver technical design documents (Contract Data Requirement List (CDRL) A001) including, but not limited to, Requirements Traceability Matrixes (RTMs), web service architecture, dependencies, data flow, Security Technical Implementation Guide (STIG) requirements, frameworks, and all business logic not captured in other documentation. The Contractor shall participate in requirements identification and decompose requirements into tasks in accordance with the JOMIS Requirements Management Plan. The Contractor shall deliver data design artifacts including a Database Design Document (DBDD) and Data Catalogs (CDRL A002). Data design documents should include all business logic embedded within the database, Entity Relationship Diagrams, and business and technical meta data.

3.1.4 Application Development and Enhancement

3.1.4.1 Application Design

The Contractor shall apply Human-Centered Design practices in conjunction and collaboration with the Government Value Team, leveraging end-user interactive tools to create artifacts (e.g., flow diagrams and wireframes) to design the interface and organization of the TBLD capability, demonstrating the incorporation of customer-driven insights that support usability and interactivity per industry guidelines.

The Contractor shall outline the intended process and techniques to validate alignment of software with required user needs. The Contractor shall use a management process that can respond to changes in requirements (technical and/or schedule), requirements prioritization, and product development or enhancement. The Contractor shall provide recommended optimizations to DDIL design and capabilities including data management, integrations, and operational resilience (work product). The recommendations must not degrade system functionality or interfere with existing interfaces.

3.1.4.2 System Architecture

The Contractor shall use digital engineering architecture tools where the digital architecture model is defined consistently with industry standards. The Contractor shall adhere to DOD Modular Open Systems Approach design principles, emphasizing open standards, loosely coupled modules with high cohesion, and employing a shared services framework accessible through Application Programming Interfaces (APIs) with maximum reuse of code class libraries. Architecture shall incorporate appropriate considerations for reconfigurations, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability for reasonable maintenance and sustainment to feasibly apply Model-Based System Engineering practices.

The tools will output architecture drawings (to include, but not limited to, Department of Defense Architecture Framework (DoDAF) required diagrams), data models, diagrams, spreadsheets, Interface Control Documents (ICDs), and other documentation and artifacts from the model (CDRL A003). The Contractor shall collaborate with the Government to ensure artifact formats meet Government standards.

3.1.4.3 Application Performance

The Contractor shall meet with the Value Team at the close of each sprint to review software development, blood community support, test activities, program schedule, Agile software development trends (i.e., velocity, user story completion, etc.), risks, costs, and issues. The Contractor shall demonstrate how it will integrate updates to its processes to demonstrate improvements in subsequent development efforts.

Updates to development efforts may be a direct result of customer or end-user feedback received during User Assessment Events (UAEs) conducted. The Contractor will support the Value Team execution of such assessments to ensure usability, performance, and utility of software for the blood community operating in Theater contexts. The UAE will represent multiple roles/personas within Roles 1-3/ Continental United States (excludes Alaska and Hawaii) (CONUS) contexts. Feedback will be documented, consolidated, and analyzed by the Solution Team to determine the most appropriate improvements to enhance the user experience. Recommendations will be provided to the Assistant Program Manager (APM) and Product Owner who will be responsible for determining the priority of proposed enhancements to be reflected in the backlog for future development, per iterative Agile development practices.

3.1.4.4 Application Development and Enhancement

The Contractor shall apply Agile methodologies to its internal work processes and to engagements with the Value Team, other vendors supporting the JOMIS portfolio, and interface partners throughout all phases of work. In keeping with Agile best practices, the Contractor shall partner in a cross-functional manner with Government counterparts and team members. Also, the Contractor shall deliver code (CDRL A005) that provides value in a timely manner. Story point estimations must be clear, consistent, and understood by the Government.

The Contractor shall apply Agile Scrum methods to develop and enhance software that meets the functional and technical requirements outlined that will be captured and represented as epics, user stories, and HCD work products. The Contractor shall deliver any software updates required to address test results and/or defects identified. The Contractor will provide input necessary to adjudicate any test findings issued.

The Contractor shall provide the Value Team with real-time access to software development, collaboration tools, and techniques. The epics and user stories developed will cover functionality, features, and user acceptance criteria from the perspective of the user that will serve as the basis for the Value Team to determine satisfactory completion of a product backlog item and approval for development–the “Definition of Done”. The user acceptance criteria includes human factor design and user experience per industry design standards, such as interaction criteria (e.g., usability, utility, learnability, accessibility, reliably repeatable), content design (e.g., information architecture principles including object, choice, and disclosure, data linkages, information content, structure, and organization to support navigation and workflow), and interface criteria (e.g., usability heuristics, visibility of system status and alignment between system and real world experience, visual design principles to include scale, visual hierarchy, balance and contrast, as well as user control, error avoidance, data visualization and typography (CDRL A001)).

The development pipeline should at a minimum cover the areas of code creation and management, questions and answers, staging, and production execution. The result of the pipeline should cover artifacts that can be placed into production and should cover all requirements for code execution without requiring external processes. The pipeline should be capable of branching/merging to control introduction of feature sets.

Phases of the pipelines should address:

a) Tracking the build progress

b) Security scans of any dependencies

c) Unit testing

d) Functional code testing

e) Acceptance testing and behavioral change tracking

f) Security penetration/black box testing

g) Accessibility requirements verification

h) Continuous compliance/ATO requirements (reports and/or compliance scans)

i) Deployment and promotion automation

j) Joint Interoperability Test Command (JITC) or other test finding resolution to ensure application can be deployed/fielded

Automation reviews should be included in any demos and be planned around reuse wherever possible.

Any automation code created should be included in a review and the source control should be checked.

Focus should center on configuration wherever possible, more than writing code for the pipeline. The Contractor shall report on all testing automation and deliver all test scripts and test results (CDRL A004) for the types and levels of testing conducted. The Contractor shall develop code using commercial best practices, including:

• Formal code inspection

• Flaw and vulnerability detection

• A continuous test execution process (software, infrastructure, systems)

In accordance with an Agile partnership, the Contractor shall support the independent Government Test Team’s (third-party Government or Contractor) verification and validation of the software application development.. The Contractor shall use a Government-approved tool for managing the backlog and day-to-day development. The Contractor shall ensure the Government has full access to the tool, within a Government-approved environment. Where needed, plug-ins will be allowed by the Contractor to link acceptable instances with the JOMIS test infrastructure tools to support JOMIS’ overall life cycle management of the capability.

3.1.4.1.1 Development

The Contractor shall construct the development environment, using the Government-provided development lab (currently Cloud One, but subject to change) with network and system access. The Contractor shall integrate security practices within the Continuous Integration/Continuous Delivery (CI/CD) pipeline aligned with the DOD Enterprise and Development, Security, and Operations (DevSecOps) initiative.

The Contractor shall perform software engineering and architecture design to ensure the development environment delivers acceptable functionality in accordance with Government approved technical requirements. The Contractor shall work within the JOMIS One Solution Development Life Cycle (SDLC) software development approach, based on Agile CI/CD to a pre-production environment.

The Contractor shall build source code with dependencies in an operations pipeline (handles compiled code check-in, scanning, and deployment to environments, including production) that are deployable on the hosting platform. Wherever possible and appropriate, the Contractor shall apply Open Container Initiative, building containers for software development. The Contractor shall provide source code (CDRL A005), compile binaries and dependencies (CDRL A006), build instructions and artifacts (CDRL A007), and Version Description Documents (VDDs) (CDRL A008) as deliverables.

3.1.4.1.1.1 Development Standards

TBLD development standards outline the accepted methodology for development practices under this effort.

• The Contractor shall develop all system interfaces (CDRL A003) conforming to open and industry-based standards.

• The Contractor shall develop solutions and architecture in accordance with the zero trust principles outlined in NIST SP 800-207 and utilize and Cyber-Resilience and Survivability best practices.

• The Contractor shall provide authorized access, retention, integration, sharing, transfer, and conversion of Internet Protocol deliverables.

• The Contractor shall ensure that processes and tools are in place to support product Configuration Management (CM) and release management.

• The Contractor shall ensure that processes and tools are in place to support data loss prevention, sharing, and exchange.

• The Contractor shall ensure the system shall be backward compatible for at least two versions/releases.

• The Contractor shall use Test-Driven Development as a development technique.

3.2 Working in an Agile Environment

The Contractor shall work in a team-based, Agile environment that applies a cross-functional matrix model consisting of the Contractor, JOMIS Government, and JOMIS Contract Support personnel. The Contractor will be required to coordinate and collaborate effectively with other contract companies performing interrelated work. Successful performance will depend on proactive communications, alignment of schedules, and seamless integration of interdependent project components. Tasks will likely require coordination activities with one or more stakeholders, including the Value Team, PEO Developmental Test & Evaluation (DT&E), PEO Cybersecurity, and other JOMIS Contractors.

Collectively, the Development Team (Contractor) and Value Team (JOMIS Government and JOMIS Contract Support) will comprise the TBLD-M Solution Team. The Product Owner, with support from the APM, will communicate requirements and determine the direction for project features by providing a backlog of high-level requirements/capabilities. As with typical Scrum-based and Agile processes, the TBLD-M Product Owner will work with the Solution Team to develop and estimate user stories and establish the acceptance criteria to populate the Product Team backlog. The backlog will undergo further decomposition to reflect functional requirements, technical requirements, and (user) acceptance criteria.

The Contractor is responsible for ensuring that user stories specify expected functionalities and/or feature details including any non-functional requirements that must be met in the development of the story. The TBLD-M Product Owner, supported by the APM, Subject Matter Experts (SMEs) and Business Analysts will determine whether the acceptance criteria have been satisfied (“Definition of Done”).

The Government will provide an initial prioritized backlog consisting of epics and user stories to provide the Contractor with context for the requested work. The prioritized backlog will evolve and change as work continues. Updated and additional user stories, epics, use cases, as well as any other artifacts necessary for documenting requirements and their fulfillment, will be developed collaboratively between the Value Team and the Contractor. The Contractor shall deliver a release plan (CDRL A009) prior to the start of each release that identifies the functional and non-functional requirements to be delivered in that release. The Contractor shall determine the release plan scope based on the scale of the release and confirm the scope with the Government prior to delivery.

Work will be accomplished in sprints lasting two to four weeks and focus on completing a defined subset of project deliverables or usable functionality. The overall project “Definition of Done” shall be based on the user stories to be completed and the functionality to be delivered. Each sprint will include the planning, design, development, integration, testing, and demonstration of working software to the Product Owner, APM, users, and other stakeholders.

The Contractor shall work closely with the TBLD-M APM, Product Owner, and Value Team to ensure that the product backlog, specified by the Product Owner or JOMIS, is continually and regularly maintained in alignment with the established Agile cadence such that Sprint backlog items – epics and user stories defined with acceptance criteria – are ready to be prioritized by the Product Owner prior to the start of each sprint and release. The Contractor shall prioritize development in accordance with how the Product Owner balances business and technical priorities which are reflected in the backlog. The current project status shall be represented on a project dashboard, indicating current work, blockers, and project velocity in the format and location to be agreed upon by the APM. This process for maintaining and monitoring productivity is defined in the JOMIS SDLC process documentation as identified in the JOMIS Technical Execution Plan (TEP).

The Contractor will ensure that specified features and requirements are consistent with Agile and sprint-based development. The Contractor shall provide a Sprint Plan (CDRL A010) that reflects the working rhythm or cadence to include, but not limited to, the following:

• Sprint goals

• Estimations (e.g., story points, et al.)

• Demonstrations at the end of every sprint

• Overall productivity and sprint burn-down measures

• Running account of any GFE in the Contractor’s possession and any administrative-level access assigned to a Contractor working in production environments

Additionally, as the Contractor establishes norms around the overall velocity of work, the Contractor shall develop and deliver a Project Schedule leading up to product delivery to the Government (to include, but not limited to, sprint schedule and other product milestones) (CDRL A011) to project the scope of work that can be accomplished utilizing, for example, a three-month, six-month and twelve-month roadmap.

The APM will discuss and approve the schedule which will serve as a roadmap for forthcoming delivery over the course of the Period of Performance (PoP) which will be updated as the backlog is refined, and reprioritization impacts the roadmap. The approach provides the expectation that the Contractor Development Team and JOMIS Value Team will work in partnership as a cohesive Solution Team to deliver the TBLD-M capability.

3.2.1 Development Landscape and Future Environment

The Contractor shall assess the current approach and determine the best viable, feasible, and desirable format for short-term and long-term development, maintenance, and adaptability of the application prior to the migration of the existing portion of the application to a Government-approved Cloud compliant/compatible environment.Appendix A contains descriptions of existing systems. Additional interfaces may be required in the future.

TBLD-M will initially operate in a DevSecOps pipeline in or compatible with the Government-approved Cloud One environment. The Contractor shall provide solutions capable of integrating with this platform, leveraging the development-to-production environments and available hosting services. Additionally, the Contractor shall propose the best pipeline (work product) to construct within the Government-approved Cloud development environment that accounts for downstream considerations for packaging and installation of the application in DDIL Theater contexts for delivery to deployed assets. Software distribution and installation procedures will be confirmed during the course of the project.

3.2.1.1 Technical Specifications

The following sections provide details on the work scoped within this document: the implementation of store and forward capabilities for near real-time data synchronization locally and with the enterprise; data management and flows that support a JOMIS solution for TBLD-M integration with other key systems and vendor development integration; and migration of the current TBLD capability into the Government-approved Cloud DevSecOps environment for the CI/CD of software. At a high level, the work includes the review and analysis of existing systems and architecture, and the modernization of the IT stack and services.

The Contractor shall ensure the system accommodates the following items (as further described in the PWS) to meet all JOMIS technical standards for modern information technology systems:

• Migration of code to function within the Government-approved Cloud One trusted Cloud computing platform.

• Ongoing development via a CI/CD pipeline, created and maintained in accordance with industry standards for code quality, configuration and enhancement through the pipeline, and Government ATO requirements to support ongoing development and deployment.

• A common repository built for data sourced from the field, whether provided through the Web or from DDIL-connected facilities and maintain the data in its raw or native form (limit curating/processing).

• Automated data collection and interfaces that improve data reliability and integrity for ingested, structured, and unstructured data from multiple prime facility devices.

• Data synchronization required from local field facilities to the Government-approved Cloud hosting solution to support improved data currency and visibility.

• Data accessibility and discoverability that supports end-user needs in DDIL environments.

• Data export capability to specified formats.

• Ability for users to fully operate in DDIL environments with ongoing deploy/release of capability or enhancements to Theater facility desktops.

• A common user experience (whether for those connected or disconnected) developed to enable all roles and personnel supporting blood operations management to share functionality.

• An architecture that favors DOD-approved open-source software and tools that provide flexibility to future adaptations to changes in platform and/or associated services.

• Digital experience/end-user experience monitoring to shape forthcoming service development efforts and usage.

• Security scans and checks of the environments involved with developing and deploying the capability.

• Windows-based application with Common Access Card (CAC), 2-D bar code, and Quick Response code scanning ability.

• Documentation to support operations, training, and Service Desk functions, as required.

3.3 Capability Interfaces and Low-Side Repository

3.3.1 Application Interface

The Contractor shall develop an interface that will be an unclassified version, which must be interoperable with the JOMIS OMDS infrastructure components, such as the API Gateway. In addition, TBLD-M will need to leverage the OMDS interface with the Defense Enrollment Eligibility Reporting System (DEERS) check service (call API Gateway for the refactored DEERS service).

3.3.1.1 TBLD Data Hosting and Repository Infrastructure

The Contractor shall manage a TBLD-M central repository (currently Government-approved Cloud, but subject to change) with the ability to ingest and/or federate data from heterogeneous information sources located in Theater at the local facility level across Roles 1-3 (first responder, forward resuscitative, and Theater hospital care). The repository shall share data seamlessly, synchronizing incoming data from local facilities with the enterprise repository and making near real-time updates and adjustments when connectivity is established and available with DDIL facilities, such that the blood community has current, accurate, and reliable data for all service personnel supporting blood operations along the supply chain and Command and Control operations. The repository shall ensure governance and compliance via unified methods to secure, monitor, and manage access to data. Solutions may consider all database types:

• Ingest structured and unstructured data from multiple data sources (which may need to accommodate for compatibility with OMDS and dependent systems within the JOMIS portfolio

• Data export capability to specified formats

• Cloud-based using currently supported DOD-sanctioned environments

• Government-approved Cloud native or Cloud agnostic solution

• Scalability should be factored into the solution

The Contractor shall demonstrate successful data migration from the current TMDS Blood Module to the new Government-approved Cloud repository. The entire TMDS legacy blood data set should be kept in cold storage and the latest one (1) year of data must be accessible to TBLD-M users that must respond to ad hoc queries.

3.3.1.2 Enterprise Monitoring

The Contractor shall coordinate with the enterprise monitoring solution provider to support the implementation of a comprehensive enterprise monitoring solution for the Government-approved Cloud hosting environment that provides real-time operational visibility across network, software, infrastructure, and applications. This solution shall include real-time visualizations (e.g., system and infrastructure health) via dashboards and a centralized logging repository capable of providing visibility across multiple services and Government-approved Cloud endpoints. The monitoring solution must support all environments throughout the CI/CD pipeline in production.

The Contractor shall integrate with the enterprise solution monitoring provider to facilitate the ongoing management and administration of the TBLD-M monitoring solution, ensuring its reliability, scalability, and effectiveness. Additionally, the Contractor shall analyze TBLD-M infrastructure and associated services and propose methods for implementing self-healing architecture to enhance system resiliency.

Any enhancements shall be fully compatible with the existing monitoring solution.

To ensure seamless integration and operational efficiency, all vendors providing services or components that interact with the Government-approved Cloud hosting environment shall collaborate and cooperate with the enterprise monitoring solution provider to:

• Support and integrate log analysis and visualization capabilities.

• Configure and enhance the development pipeline.

• Align development pipeline configurations with Enterprise Monitoring requirements.

• Ensure that all application enhancements remain compatible with and enhance the monitoring solution.

The Contractor is expected to work proactively with the enterprise monitoring solution provider to facilitate seamless interoperability, data sharing, and adherence to monitoring standards, ensuring a fully integrated and optimized enterprise monitoring framework.

3.3.1.3 Implement Data Services

The Contractor shall implement inbound, outbound, or bi-directional services that transmit data through the OMDS API Gateway and accommodate for delays related to the availability of the gateway, in accordance with the JOMIS ICDs and enterprise architecture

The Contractor shall provide both data in transit and data at rest encryption.

The Contractor shall ensure all services are built according to specifications agreed upon and captured in an ICD that represents data flows internally and externally with respect to data exchanges and synchronization. The TBLD-M Value Team will coordinate requirements and agreements with interface partners, as needed. Given the DDIL environment for data capture and exchange, the Contractor shall describe how data will be reconciled across and between facility devices, how data will synchronize between local devices and the local Facility Prime (bi-directional), and how data will be exchanged between the Facility Prime and Government-approved Cloud Prime (bi-directional).

Given that data is aggregated from various sources, the Contractor shall analyze the service for security considerations to assess whether the aggregated data changes the security classification. Additionally, for aggregated data that must pass through different security domains, the Contractor shall ensure that data is transmitted in a contextual manner.

3.4 Testing

The Contractor shall leverage Agile/DevSecOps testing best practices as outlined in the JOMIS Test and Evaluation (T&E) Program Strategy document.

The Contractor shall support Developmental Testing (DT) and potentially Operational Testing (OT) to include Cyber T&E, which includes Cyber Tabletops (CTTs) and Adversarial Assessments (AAs). DT requires Automation Test Cases and Test Scripts (both automated and manual) and Test Evidence (CDRL A004).

Test evidence should include screen captures or visible evidence of the passed/failed test case.

User stories and test results shall be stored in a Government-approved tool (e.g., TI Jira).

The Contractor shall conduct continuous and automated testing within the CI/CD pipeline(s), such as unit, functional, performance, and security tests.

The Contractor shall support testing in an integrated development environment provided by the Government.

The Contractor shall collaborate with the Solution Delivery team to use centralized tools for test management and data management to track and report testing efforts and overall project tracking such as Jira.

The Contractor shall conduct a formal Contractor Integration Test (CIT) of the application with other interfacing systems and in accordance with the Agile delivery plan. CIT should occur in a Government Integrated Environment. The Contractor shall coordinate all formal test activities with the Government.

Under no circumstances shall the Contractor commit Government resources to a test event or test schedule prior to Government approval.

For each CIT, the Contractor shall develop and deliver a Test Plan (CDRL A012) specifically addressing the test objectives, test approach, test environment, success criteria, participant roles and responsibilities, documentation requirements, schedule, and other items as identified in the International Electrotechnical Commission (IEEE) standard.

For each test, the Contractor shall also develop and deliver test procedures that identify discrete events to be accomplished and actions and processes to be followed in the test activity. All functions to be tested shall be tied directly to the RTM. Test procedures shall ensure that any new or changed interface is fully tested.

The Contractor shall resolve discrepancies and problems found during the CIT prior to release to the Government for the Systems Integration Test (SIT). Upon the Contractor’s determination that CIT has been successfully completed, they shall document and deliver the results in a Test Report (CDRL A013).

The report shall contain a detailed summary of test events and test findings, to include application of JOMIS Severity Levels to problems, action items, and recommendations for remediation.

The Contractor shall be prepared to provide typical deliveries associate with test events:

i. Test plan

ii. Test Procedures

iii. Test Report

iv. Test Readiness Review

v. Requirements Traceability Matrix

vi. Version Description Document

vii. Interface Control Document

a. The Contractor shall provide real-time availability of engineering staff to support troubleshooting.

b. The Contractor shall perform critical fixes and updates as required for mission performance.

c. The Contractor shall participate in daily status meetings and End-of-Test meetings and shall address test issues and problems found.

e. The Contractor shall provide test reports at the end of each development sprint or release; on-demand access to various systems and facilities; and real-time availability of engineering staff to support troubleshooting as required. The Contractor shall assist in setting up Interface emulator tools as required; perform critical fixes and updates as required for mission performance;

participate in daily status meetings and End-of-Test meetings; and address test issues and problems found.

In certain circumstances such as compressed delivery schedules, environmental limitations, or when an early look at the integrated product is necessary, the Contractor shall allow Government Test Agents to view the CIT in an Over-the-Shoulder review or allow them to test along with the Contractor in a Shoulder-to-Shoulder test, or in rare instances, utilize the Contractor’s environment to conduct the SIT. This type of testing shall only be conducted with prior Government approval.

The Government has the right to conduct "smoke" testing of the application and utilize the results in a preliminary user satisfaction survey. The Contractor shall submit cybersecurity scans to JOMIS. There should be no CAT 1 or CAT 2 findings in these submissions.

Results of both installation and smoke shall be utilized to determine whether the Government agrees to move forward with the Test Readiness Review (TRR).

At the conclusion of the CIT, the Contractor shall conduct or support a TRR for the Government in order to present findings and to turn over the developed function to CM for subsequent Government testing. The Contractor shall prepare for the meeting and present final versions of all system documentation at the TRR. In addition, all tool(s) and/or emulator(s) developed by the

Contractor specifically to test interfaces as a result of this development effort and associated documentation shall be delivered to the Government for use in Government testing.

After completion of the TRR and upon Government approval, the Contractor shall support formal Government software testing. Test events will include the SIT.

The Government will have ten (10) working days to provide approval/rejection of test artifacts delivered by the Contractor.

Contractor support shall include providing on-demand access to various systems and facilities, real-time availability of engineering staff to support troubleshooting, explaining nuances of system design, assisting in setting up Interface emulator tools, and performing quick fixes as needed based on test requirements. In addition, the Contractor shall participate in daily status meetings and End-of-Test Meetings to address test issues and problems found.

Table 1 describes error severity levels.

Table 1: Test and Evaluation Severity and Category Code

Defect Severity Level Description

• Prevents the accomplishment of an essential capability.

• Jeopardizes the safety, security, or other requirements designated

“Critical”.

• Causes loss of a patient’s life or seriously degrades the overall quality of a patient’s health.

• Adversely affects the accomplishment of an essential capability and no workaround is known.

• Adversely affects performance, cost, or schedule risks to the project or to life cycle support of the system, and no workaround is known.

• Adversely affects the accomplishment of an essential capability, but a workaround has been identified.

• Severely affects performance, cost, or schedule risks to the project or to life cycle support of the system, but a workaround has been identified.

• Results in user inconvenience or annoyance, but does not affect a required or mission essential capability.

• Results in inconvenience or annoyance for development or maintenance personnel, but does not prevent the accomplishment of responsibilities.

Software products tendered that include Severity Level 1, 2, or clusters of 3 defects will be returned to the Contractor for remediation and retest. A comprehensive Contractor test (with an accompanying test report) is required of all software each time it is offered to the Government.

The Contractor shall perform Software Code Quality Checks (SCQCs) in a Government-directed environment per release throughout the life cycle of all JOMIS products utilizing automated tools that are equivalent to those currently used by the Government. The Contractor shall deliver a technical report that identifies any residual vulnerability in the software under development in accordance with International Standards Organization (ISO)/International Electrotechnical

Commission (IEC) 25010:2011. The Government defines SCQC as a review of the source code, executables, and related artifacts. SCQC encompasses the use of static code analysis, static security analysis, dynamic code analysis, dynamic security analysis, and architectural analysis and is usually performed using automated tools. The Contractor shall perform SCQC using automated tools as well as manual reviews of application source code. The tools will scan the application source code (static analysis) or a deployed application in the SCQC environment (dynamic analysis). Furthermore, the tools may generate security metrics that detail the security of the application, and/or provide quality metrics that depict the quality of the source code.

The Contractor shall enable public key information systems and implement digital signatures and encryption requirementsas as specified in Department of Defense Instruction (DoDI) 8520.02.

3.5 Fielding Support

The Contractor shall provide technical reach back (SME) support to fielding and user event support for the TBLD application.

The Contractor shall comply with support and integration requests from IT Operations, including ensuring that JOMIS Service Desk Tier 3 and JOMIS System Monitoring duties for the developed product are aligned with the established JOMIS Service Desk and JOMIS System Monitoring Teams.

Tier 3 support will primarily occur within normal business hours (0800-1700 Eastern Standard Time (EST)). Support may occasionally be required outside normal (EST) business hours on an as needed basis. To facilitate this, the Contractor shall:

• Support escalated technical and functional incidents and requests.

This includes responding to and updating incidents and requests while adhering to the following Service Desk Service Level Agreements (SLAs) for update frequency:

o Priority = Low/Sev 4 = 24 hours o Priority = Medium/Sev 3 = 4 Hours o Priority = High/Sev 2 = 30 minutes o Priority = Critical/Sev 1 = 15 minutes

Communicate scheduled maintenance windows.

• Planned Maintenance:

o High-Impact (Major) Maintenance: Anticipated once per quarter.

o Low Impact (Regular) Maintenance: At least three-to-seven (3-7) day’s notice (minor updates, patches).

• Emergency Maintenance:

o As soon as possible, ideally immediately upon decision to proceed.

• Reminder Notifications:

o High-Impact: thirty (30) days prior, plus seven (7)-day and twenty-four (24)-hour reminders.

o Low-Impact: forty-eight (48) hours or twenty-four (24) hours prior.

• Notify stakeholders of planned downtime to prevent unnecessary engagement of JOMIS System Monitoring and JOMIS Service Desk Teams (see Major/High Impact Maintenance Sub Bullet above).

• Include the JOMIS Service Desk and JOMIS System Monitoring Teams in any communications or meetings detailing infrastructure changes that may impact monitoring solutions or support.

3.6 Training Material Support

3.6.1 Training Development

The Contractor shall support continuous training materials development in coordination with the Customer X as a Service training support Contractor and the JOMIS Value Team, adhering to JOMIS clinical deployed business processes in the areas of application use, quality data entry, reporting, training system software development, business process improvement, and clinical policy establishment for the training of the TBLD-M application. Training materials (CDRL A014) shall be expected to support improved JOMIS business processes and subsequently produce detailed task inputs and outputs based upon growing experience in the JOMIS domain.

3.6.2 Functional and Technical Training Documentation

The Contractor shall develop, deliver, and maintain system administrator and end-user training plans and materials that optimize the user’s experience and facilitate rapid adoption of the Minimum Viable Product (MVP) and/or Minimum Viable Capability Release (MVCR). These include, but are not limited to, Quick Reference Guides (QRGs), System User Manual (SUM), Software Installation Guide (SIG), System Administrator Manual (SAM), instructor guides, and student guides (CDRL A014). Training should focus on a realistic operational perspective and shall be updated to keep pace with capability development. Additionally, the Contractor shall support demonstration events, user engagements, and hands-on feedback sessions.

The Contractor shall provide job aids, QRGs, and other training materials (CDRL A014). The Contractor shall work collaboratively with JOMIS training teams, and with development vendors when applicable, to provide TBLD-M end-user training materials.

• The Contractor shall provide SUMs, SIGs, and SAMs no later than…