Draft PWS_TBLD-M Continued Development and Test Support.pdf

CUI

Department of Defense (DOD) Joint Operational Medicine Information Systems (JOMIS)

Theater Blood-Mobile (TBLD-M) Continued Development and Testing Support 2025

Performance Work Statement (PWS)

Task Order: HT003824R0010

Date: August 2024 Version: DRAFT

DISTRIBUTION LIMITATION/CONTROLLED UNCLASSIFIED INFORMATION (CUI)

Controlled by: Defense Health Agency Controlled by: CD-DHMS CUI Category: CUI//SP-PROCURE/SP-SSEL Control: DL ONLY POC: elizabeth.m.ruckwardt.civ@health.mil ii

Table of Contents

1 General Information

1.1 Description of Services

1.2 Background

1.3 Period of Performance

1.4 Administrative Specifications

1.4.1 Place of Performance

1.4.2 Recognized Federal Holidays

1.4.3 Hours of Operation

1.4.4 Emergency Services

1.4.5 Standards of Conduct

1.4.6 Contractor Travel

1.4.7 Other Direct Costs (ODCs)

1.5 Quality

1.5.1 Quality Assurance Surveillance Plan (QASP)

1.5.2 Quality Control (QC)

1.6 Contractor Personnel

1.6.1 Common Access Card (CAC) Requirements

1.6.2 Training

1.6.3 Certification

1.6.4 Privileged User Requirements

1.6.5 General Cybersecurity Requirements – Information Systems (IT)

1.6.6 Physical Security

1.6.7 Key Control

1.6.8 Lock Combinations

1.7 Reporting

1.7.1 Contractor Manpower Reporting

1.7.2 Non-Disclosure Agreement (NDA)

1.7.3 Government Contracting Officer’s Representative

1.7.4 Post-Award Conference/Periodic Progress Meetings

1.8 Contractor Identification

1.9 Data and Software Rights

1.10 Kickoff Meeting

1.11 Transition Out

1.12 Access Requirements

1.13 Contractor Access to Classified Information

1.14 Contractor Deliverables

1.14.1 CDRL Acceptance Criteria

1.15 Contractor Access to HA/DHA Network(s)

iii

1.16 Personnel Security

2 Definitions and Applicable Publication Instructions

2.1 Definitions

2.1.1 Category D

2.1.2 Category R

2.1.3 CO

2.1.4 COR

2.1.5 Non-Personal Services Contract

2.2 Applicable Publications/Instructions

3 Government Furnished Property, Equipment, Information, and Services

4 Contractor Furnished Items and Service

5 Technical Requirements

5.1 Problem

5.2 Product Vision

5.3 Scope

5.4 Working in an Agile Environment

5.5 Development Landscape and Future Environment

5.6 Technical Specifications

5.6.1 System Architecture

5.6.2 Design and Development

5.6.3 Development Standards

5.6.4 Testing

5.7 Backlog

5.7.1 Application Migration and Refactoring

5.7.2 Application Development and Enhancement

5.7.3 Capability Interfaces and Low-side Repository

5.7.4. Training Material Support

6 IT and Security

6.1 Training

6.1.1 Certification

6.1.2 Privileged User Requirements

6.2 General Cybersecurity IS Requirements

6.2.1 Cyber Incident Reporting Requirement

6.2.2 Malicious Software

6.2.3 Media Preservation and Protection

6.2.4 Access to Additional Information or Equipment Necessary for Forensic Analysis

6.2.5 Cyber Incident Damage Assessment Activities

6.3 Cybersecurity Requirements for Non-DOD IT or Covered Contractor IS

6.3.1 NIST Requirements

6.3.2 NIST SP 800-171, Department of Defense (DOD) Assessment Methodology iv

6.3.3 Assessment Access

6.3.4 Cybersecurity Maturity Model Certification (CMMC)

6.3.5 Requests to Vary from NIST

6.3.6 Adjudicated Requests

6.3.7 Cloud Computing

6.3.8 Cyber Incident Reporting Requirement

6.3.9 Malicious Software

6.3.10 Media Preservation and Protection

6.3.11 Access to Additional Information or Equipment Necessary for Forensic Analysis

6.3.12 Cyber Incident Damage Assessment Activities

6.3.13 Other IS Security Measures

6.3.14 Maintenance of Government Data

6.3.15 Supply Chain Risk Mitigation

6.4 Risk Management Framework (RMF) for DOD IT

6.4.1 NIST Implementation

6.4.2 DISA Security Requirements

6.4.3 Ports, Protocols, and Services Management (PPSM)

6.4.4 Identity Authentication

6.4.5 Public Key Infrastructure (PKI)

6.4.6 Reciprocity

6.4.7 Cyber Incident Reporting Requirement

6.4.8 Information Security Continuous Monitoring (ISCM)

6.4.9 Supply Chain Risk

6.4.10 Commercial Cloud Computing Services

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

6.5.1 DD Form 2875 for System or Network Access

6.5.2 Tier Designation

6.5.3 Account Establishment

6.5.4 Monthly Reviews

6.5.5 Reporting Review Findings

6.6 Establishment of Telecommunications

6.6.1 Telecommunications

6.6.2 Business-to-Business (B2B) Gateway Questionnaire

6.7 Contractors Located on Military Installations

6.8 Open Technology Development Definitions and Contractor Responsibilities

Appendix A: Acronyms

Appendix B: Relevant Systems Impacted by TBLD-M

Appendix C: Deliverables Schedule

1 General Information

1.1 Description of Services

The Contractor shall provide all personnel, equipment, supplies, facilities, transportation, and tools appropriate for a Cloud One (C1) compatible/compliant environment. The Contractor shall also provide for software to be installed in Theater, materials, supervision, other items, and non-personal services necessary to perform continued software capability development, enhancements, product and testing support, and fixes for the Theater Blood-Mobile (TBLD-M) capability, as defined in this Performance Work Statement (PWS) with the exception of those items specified as Government Furnished Property (GFP) and services. The Contractor shall perform to the standards defined in this PWS.

1.2 Background

The TBLD-M capability for operational blood management 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 to all Tri-Service members of the United States (U.S.) Army, Navy (including the Marine Corps), and Air Force. 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 disconnected, intermittent, or low-bandwidth (DIL) connectivity to Department of Defense (DOD) enterprise networks.

This is a shift from the legacy Theater Medical Data Store (TMDS) application that collects data, tracks, and reports on blood activity via a web browser. Due to the lack of connectivity, intermittent data capture threatens the integrity of the blood asset supply chain. Blood operation management and communications must work offline in DIL environments, thus utilizing store and forward capabilities to send data as close to real-time as possible to avoid interrupting or compromising health care delivery, especially during emergency situations.

Currently, there are no automated tools to monitor, forecast, or analyze medical blood logistics and delivery which places a substantial administrative burden on support operations to provide quality blood products at the point of care in Theater, especially when responding to high-casualty events. Blood operations staff dedicate as much as twenty-five (25) times more labor hours to basic blood management activities than are actually required to complete core functional tasks. Administrative burdens and high opportunities for human error detract from blood operations’ focus on life-saving medical logistical support responsibilities and pose potential health and safety risks for blood recipients requiring medical treatment.

TBLD-M would be the first enterprise capability that provides visible blood inventory management operations in DIL environments across all echelons of care, including Roles 1-3 (first responder, forward resuscitative, and Theater hospital care) and in coordination with Role 4/Continental United States (CONUS) or garrison donor centers. TBLD-M requires access to an integrated data environment with user-centered functionality to enable the timely completion of blood management activities, significant reduction in data entry errors and delays, and reduced life cycle sustainment costs. The system should minimize maintenance workload and improve the ability to rapidly develop and deploy updates in response to changing warfighter requirements. Unlike the current paper- or spreadsheet-based approach, all donation screening and acceptance, inventory oversight and management, and transfusion record data needs to be documented electronically and available to Theater medical staff and CCMD area operations for enterprise-level use and reporting. Near real-time global blood inventory is crucial for sustaining and projecting readiness of our military force for both anticipated and unanticipated events. The TBLD-M solution is not subject to certification by the Food and Drug Administration since it operates outside of the U.S.

1.3 Period of Performance

The period of performance (PoP) for this task order begins on Month xx, 2025 and ends xx months thereafter.

1.4 Administrative Specifications

1.4.1 Place of Performance

Work shall be performed at Government and Contractor facilities.

1.4.2 Recognized Federal Holidays

New Year’s Day Labor Day

Martin Luther King Jr.’s Birthday Columbus Day

Presidents Day Veterans Day

Memorial Day Thanksgiving Day

Juneteenth Christmas Day

Independence Day

1.4.3 Hours of Operation

The Contractor is responsible for conducting normal business during the hours of 0800 EST – 1700 EST, Monday through Friday, except for Federal holidays or when the Government facility is closed due to local or national emergencies, administrative closings, or similar Government-directed facility closings.

Normal operations must be maintained to facilitate coordination with Joint Operational Medicine Information Systems (JOMIS) Program Management Office (PMO) personnel. The Contractor must maintain an adequate workforce for the uninterrupted performance of all tasks defined within this PWS when the Government facility is not closed for the previously stated reasons.

1.4.4 Emergency Services

Occasionally, services may be required to support an activation or exercise of contingency plans outside of normal duty hours.

1.4.5 Standards of Conduct

Contractor personnel shall adhere to standards of conduct as established by the Defense Health Agency (DHA) Director.

1.4.6 Contractor Travel

The Contractor shall be authorized travel expenses consistent with the cost principles and procedures in Federal Acquisition Regulation (FAR) Part 31.2 and the limitation of funds specified in this contract. All travel requires Contracting Officer (CO) approval/authorization and notification/request shall be via the Contracting Officer’s Representative (COR).

1.4.7 Other Direct Costs (ODCs)

The ODCs in this task order require CO authorization/approval and notification/request via the COR. The primary anticipated use of ODCs is to acquire software licenses and associated tools if required. All products must be included on the DOD Approved Products List.

1.5 Quality

1.5.1 Quality Assurance Surveillance Plan (QASP)

The Government will evaluate the Contractor’s performance under this contract in accordance with the QASP. The QASP provides a systematic method for the Government to evaluate performance and ensure the Contractor has performed in accordance with performance standards. It defines how the performance standards will be applied, the frequency of surveillance, and the minimum acceptable defect rate(s).

1.5.2 Quality Control (QC)

The Contractor shall develop and maintain an effective QC program to ensure services are performed in accordance with this PWS. The Contractor shall develop and implement procedures to identify, prevent, and ensure non-recurrence of defective services. The Contractor’s QC program is the means by which the work complies with stated requirements.

The Contractor shall provide a Quality Control Plan (QCP) (Contract Data Requirements List (CDRL) A001) that documents how the Contractor shall meet and comply with the quality standards established in this PWS. After receiving notification of required revisions from the Contracting Office, a revised QCP plan must be submitted within five (5) working days. Minimally, the QCP shall include the following:

a) A self-inspection plan.

b) An internal staffing plan denoting Contractor QC program staffing responsibilities with required representative experience, education, and certifications, as appropriate for the requirements denoted in this PWS.

c) An outline of the procedures the Contractor shall use to maintain quality, timeliness, responsiveness, customer satisfaction, and any other requirements set forth in this PWS.

1.6 Contractor Personnel

1.6.1 Common Access Card (CAC) Requirements

The Facilities Security Officer (FSO)/company security point of contact (POC) will provide the Government with all required information per the DHA CAC request process (version 2.1, January 2018) for all Contractors who will work in Government facilities or will access Government information systems (IS) through Government Furnished Equipment (GFE) using CAC readers. A CAC is the standard identification used for eligible DOD Contractor personnel. The Contractor shall return all CACs to the COR upon the departure of the Contractor(s) or at the end of the PoP.

1.6.2 Training

The Contractor shall ensure all employees supply a certificate of all completed courses to the COR (CDRL A002). All employees supporting this contract must complete the Cybersecurity Awareness Challenge using the DOD’s Learning Management System, Joint Knowledge Online (JKO) (https://jkodirect.jten.mil). Additionally,

a) The Contractor shall adhere to all DHA personnel security requirements for Contractor personnel.

b) Appropriate training covering Cybersecurity Awareness, the Privacy Act, and the Health Insurance Portability and Accountability Act (HIPAA) shall be maintained by all employees supporting this effort throughout the life of the contract.

1.6.3 Certification

Per DOD Directive (DoDD) 8140.01 and Defense Federal Acquisition Regulation Supplement (DFARS) 252.239-7001, Contractor and associated Subcontractor employees supporting cybersecurity information assurance (IA)/cyberspace functions shall be appropriately certified upon contract/task order award. The baseline certification as stipulated in DOD 8570.01-M must be completed prior to beginning contract support services. In addition, the Contractor shall comply with computing environment (CE) certification requirements as specified in the contract. CE certifications shall be obtained within the timelines specified in DOD 8570.01-M.

1.6.4 Privileged User Requirements

All Contractor employees with privileged user status must comply with the requirements of DHA- Administrative Instruction (DHA-AI) 081.

1.6.5 General Cybersecurity Requirements – Information Systems

The Contractor shall comply with DOD Instruction (DoDI) 8582.01, DoDI 8500.01, and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, NIST SP 800-53a, and NIST SP 800-37, as well as emerging DOD Cybersecurity policies designed to address evolving threats.

1.6.6 Physical Security

The Contractor shall be responsible for safeguarding all Government equipment, information, and property provided for Contractor use.

1.6.7 Key Control

The Contractor shall establish and implement methods of ensuring all keys/key cards issued to the Contractor by the Government are not lost, misplaced, or used by unauthorized persons. (Note: All references to keys includes key cards.) Keys issued to the Contractor by the Government shall not be duplicated. The Contractor shall develop procedures covering key control and include them in the QCP.

Such procedures shall include turn-in of any issued keys by personnel no longer requiring access to locked areas. The Contractor shall immediately report any occurrences of lost or duplicate keys/key cards to the CO.

In the event that keys, other than master keys, are lost or duplicated, the Contractor shall, upon the direction of the CO, re-key or replace the affected lock or locks; however, the Government, at its option, may replace the affected lock or locks or perform re-keying. When the Government replaces or re-keys locks, the total cost of re-keying or replacing locks shall be deducted from the monthly payment due to the Contractor. In the event that a master key is lost or duplicated, the Government shall replace all locks and keys for that system and the total cost shall be deducted from the monthly payment due to the Contractor.

The Contractor shall prohibit the use of Government issued keys by any persons other than the Contractor’s employees. The Contractor shall prohibit the opening of locked areas by Contractor employees to permit entrance of persons other than Contractor employees engaged in the performance of assigned work in those areas (including personnel authorized entrance by the CO).

1.6.8 Lock Combinations

The Contractor shall establish and implement methods of ensuring that lock combinations are not revealed to unauthorized persons. The Contractor shall ensure that lock combinations are changed when personnel who have access to the combinations no longer have a need to know such combinations. These procedures shall be included in the Contractor’s QCP.

1.7 Reporting

1.7.1 Contractor Manpower Reporting

The Office of the Secretary of Defense for Personnel and Readiness operates and maintains a secure data collection site where the Contractor shall report all Contractor manpower (including Subcontractor manpower) required for performance of this contract. The Contractor shall complete all required information using https://www.sam.gov. The required information includes:

CO, Contracting Officer’s Technical Representative (COTR) also known as the COR

Contract number, including task and delivery order number

Beginning and ending dates covered by reporting period

Contractor’s name, address, phone number, email address, and the identity of the Contractor employee entering the data

Estimated direct labor hours (including Subcontractors)

Estimated direct labor dollars paid this reporting period (including Subcontractors)

Total payments (including Subcontractors)

Predominant Federal Service Code (FSC) reflecting services provided by Contractor (and separate predominant FSC for each Subcontractor, if different)

Estimated data collection cost

Organizational title associated with the Unit Identification Code (UIC) for the requiring activity.

The requiring activity is responsible for providing the Contractor with its UIC to report this information.

Locations where the Contractor and Subcontractors perform the work (specified by zip code in the U.S. and by nearest city and country when in an overseas location, using standardized nomenclature provided on the website).

Presence of deployment or contingency contract language

Number of Contractor and Subcontractor employees deployed in Theater during the reporting period (by country).

As part of its submission, the Contractor shall provide the estimated total cost (if any) incurred to comply with this reporting requirement. The reporting period shall be the PoP, not to exceed twelve (12) months ending September 30 of each Government fiscal year and must be reported by October 31 of each calendar year. Contractors may use a direct extensible markup language (XML) data transfer to the database server or fill in the fields on the website. The XML direct transfer is a format for transferring files from a Contractor’s system to the secure website without separating data entries for each required data element at the website. The specific formats for the XML direct transfer may be downloaded from the website.

1.7.2 Non-Disclosure Agreement (NDA)

All Contractor personnel obtaining access to proprietary, classified, oconfidential information, or any information release protected or governed by law or regulation associated with DHA acquisitions shall be required to complete and sign DHA Form 49, Contractor Non-Disclosure Agreement (NDA) (CDRL A003) prior to beginning work on the subject contract. The Contractor shall execute an NDA on behalf of the company and shall ensure that all assigned staff, including all Subcontractors, Consultants, or other personnel performing on the contract/task order, execute an NDA protecting the Government’s sensitive procurement information and the proprietary information of other Contractors. The NDA shall be executed no later than the first day of employment and be renewed upon exercising a contract option period. Assignment of staff who have not executed this statement or failed to adhere to this statement shall constitute default on the part of the Contractor. The Contractor shall maintain the original signed NDAs of individual employees and provide copies to the COR.

1.7.3 Government Contracting Officer’s Representative

The COR monitors all technical aspects of the contract and assists in contract administration. The COR is authorized to perform the following functions:

Ensure the Contractor performs the technical requirements of the contract.

Perform required inspections in connection with contract performance.

Maintain written and oral communications with the Contractor concerning technical aspects of the contract.

Issue written interpretations of technical requirements, including Government drawings, designs, and specifications.

Monitor the Contractor’s performance and notify both the CO and Contractor of any deficiencies.

Coordinate availability of GFP.

Provide site entry for Contractor personnel.

A letter of designation issued to the COR, with a copy sent to the Contractor, states the responsibilities and limitations of the COR, especially regarding changes in cost, estimates, or delivery dates. The COR is not authorized to change any of the terms and conditions of the resulting contract.

1.7.4 Post-Award Conference/Periodic Progress Meetings

The Contractor agrees to attend any post-award conference convened by the contracting activity or Contract Administration Office in accordance with FAR Subpart 42.5. The CO, COR, and other Government personnel, as appropriate, may meet periodically with the Contractor to review the Contractor’s performance. At these meetings, the CO will apprise the Contractor of how the Contractor’s performance is viewed, and the Contractor shall apprise the Government of any problems experienced.

Appropriate action shall be taken to resolve outstanding issues. These meetings shall take place at no additional cost to the Government.

1.8 Contractor Identification

Contractor personnel performing services in a Contractor capacity in a Government facility are required to possess and wear an identification badge that displays his or her name and the name of their company.

All Contractor personnel shall identify themselves as Contractor support personnel in all forms of communication with all entities with whom the DHA/Deputy Assistant Director for Acquisition (DAD- A)/Head of the Contracting Activity (HCA) does business.

The Contractor shall:

Answer all telephone calls and have a personalized voice message with an introductory statement that includes the fact that the person is Contractor support personnel.

Ensure that all those with whom the person interacts in a face-to-face manner while supporting the DAD-A understand that the person is Contractor support personnel.

Include a title block in all emails stating the person is Contractor support personnel.

Ensure that all those with whom the person interacts in a face-to-face manner while supporting DHA/DAD-A/HCA understand that the person is Contractor support personnel.

Require Contractor personnel to attend meetings or otherwise communicate with Government and/or other contract representatives to meet the requirements of this order. Contractor personnel shall make their Contractor status known during introductions. Contractor personnel, while performing in a Contractor capacity, are prohibited from using their retired or reserve component military rank or title in any written or verbal communication associated with the contracts in which they provide services.

1.9 Data and Software Rights

The Government will acquire rights for all data, software, and software documentation produced, acquired, and/or delivered under the task order in accordance with the DFARS clauses included in the task order. These items include, but are not limited to, compiled code, data stored in TBLD-M repositories, analyses, evaluations, models, reports, services, and other products or information. Records and data shall be documented in deliverable reports (electronically). Databases and code shall be delivered electronically.

All contract participants shall sign a non-disclose and non-compete agreement to restrict use and protect confidential and proprietary information. The Government will retain sole rights to any data, in whatever form, provided to the Contractor for its use in performance of this task order.

1.10 Kickoff Meeting

The Contractor shall meet with the COR and TBLD-M Value Team, including the Assistant Program Manager (APM), Product Owner, engineering, test, and other team members, no later than five (5) working days after contract award. Meeting topics shall include project scope, cadence, collaboration tools, POCs, project procedures (e.g., onboarding, etc.), access control, and scheduling of follow-on meetings.

1.11 Transition Out

The Contractor shall provide a Transition Out Plan (CDRL A004) for the orderly transition of services and support from an active task order to a follow-on contract/order or Government entity. A transition period will occur no earlier than thirty (30) days prior to the end of the PoP.

1.12 Access Requirements

The Contractor may require access to the Health Affairs (HA)/DHA Network/DOD Systems to perform tasks under this order.

1.13 Contractor Access to Classified Information

TBLD-M support requires only unclassified data access under this task order.

1.14 Contractor Deliverables

The Contractor shall provide deliverables in accordance with the task order.

1.14.1 CDRL Acceptance Criteria

The Contractor’s performance of the contract is dependent on timely acceptance from the Government.

Unless otherwise agreed, services will be reviewed under the following process:

a) Within thirty (30) calendar days (or on a case-by-case basis through mutual agreement between the parties) after delivery of any service, the Government will evaluate such service and provide written notice of acceptance or rejection to the Contractor. CDRLs delivered will be reviewed within ten (10) business days (or on a case-by-case bases through mutual agreement between the parties) after delivery and the Government will provide written notice of acceptance or rejection to the Contractor. Except in the case of latent defects, services will be considered approved if no response is received after the Government’s thirty (30) calendar day review period. CDRLs will be considered approved if no response is received after the Government’s ten (10) business day review period.

b) Except in cases involving latent defects, the Government may reject a service or deliverable if it fails to materially conform to the applicable documented specifications or requirements, and any notice of rejection must indicate the specific basis for the rejection. The Contractor will resolve nonconformities and resubmit any rejected deliverable within five (5) business days.

c) The revised service or deliverable will be reviewed within five (5) business days (or case-by-case bases through mutual agreement between the parties) after the Contractor’s resubmission. The Government’s review under step c) will be limited to those items addressed in the resubmission.

Any delay(s) in the responsibilities, to include approval(s) for services and/or deliverables, may result in an impact to price, and/or schedule.

In the event of conflict between the aforementioned information and the DD Form 1423s and Inspection clause(s) in the contract, the DD Form 1423s and Inspection clause(s) take precedence.

1.15 Contractor Access to HA/DHA Network(s)

The Company’s FSO/Security POC shall notify the DHA Personnel Security Office after being awarded a contract that requires access to a DOD system. Contractor personnel requiring access to the HA/DHA networks for performance of their tasks require a background investigation and security awareness training. The Contractor shall be prepared for this process as it could take two (2) or more weeks.

The FSO Security POC shall submit a Standard Form (SF) 85/86 to the DHA’s Personnel Security Office to initiate a background investigation. The Company’s FSO/Security POC must notify the Personnel Security Office when the Contractor has submitted the SF-85/86. The FSO, Security POC, or the COR must notify the DHA Personnel Security Office in writing of a Contractor’s termination from the contract, including the termination date.

1.16 Personnel Security

The Contractor shall comply with DOD 8570.01-M, DoDI 8500.01, DOD Manual (DoDM) 6025.18, and DoDM 5200.02. Contractor responsibilities for ensuring personnel security include, but are not limited to, meeting the following requirements:

Follow DHA Personnel Security Office guidelines for submittal of security clearances.

Contact the DHA Personnel Security Office for guidance on the appropriate background investigation required for personnel on the contract.

Initiate, maintain, and document personnel security investigations appropriate to the responsibilities of the individual and required access to Controlled Unclassified Information

(CUI).

The DHA Personnel Security Office will deny access to any automated information system, network, or CUI if a Contractor receives an unfavorable adjudication, or if information resulting in an unfavorable adjudication becomes available.

2 Definitions and Applicable Publication Instructions

2.1 Definitions

2.1.1 Category D

Information Technology (IT) and Telecommunications Services (called D-Services)

2.1.2 Category R

Support (Professional/Administrative/Management) Services (called R-Services)

2.1.3 CO

The CO has the authority to enter into, administer, and/or terminate contracts and make related determinations and findings.

2.1.4 COR

An individual, including a possible COTR, designated and authorized in writing by the CO to perform specific technical or administrative functions. This individual does NOT have the authority to change the terms and conditions of the contract.

2.1.5 Non-Personal Services Contract

A contract under which the personnel rendering the services are not subject, either by the contract’s terms or by the manner of its administration, to the supervision and control usually prevailing in relationships between the Government and its employee.

2.2 Applicable Publications/Instructions

Documentation dates as referenced or most recent updates as applicable.

Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B, “Cyber Incident Handling Program,” July 10, 2012

Committee on National Security Systems Instruction (CNSSI) 1253, “Security Categorization and Control Selection for National Security Systems,” March 27, 2014

Defense Department (DD) 254, “Department of Defense Contract Security Requirement List”

DFARS 239.7602-2(a), “Required Storage of Data within the United States or Outlying Areas”

DFARS 252.239-7001, “Information Assurance Contractor Training and Certification,” January 10, 2008

DHA Interim Procedures Memorandum (IPM) 18-015, “Cybersecurity Program Management,” September 28, 2020

DHA Procedures, Guidance and Information (PGI) 224.90, “Protection of Privacy and Freedom of Information,” October 27, 2020

DHA-AI 042, “Security of Unclassified DOD Information Systems”

DHA-AI 081, “Employee Use of Information Technology,” September 15, 2015

DOD 8500.01, “Cybersecurity,” March 14, 2014

DOD 8570.01-M, “Information Assurance Workforce Improvement Program,” amended December 19, DOD Enterprise, Development, Security, and Operations (DevSecOps) Reference Design

DoDD 8140.01, “Cyberspace Workforce Management,” October 5, 2020

DoDI 6025.18, “Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule Compliance in DOD Health Care Programs,” March 13, 2019

DoDI 8100.04, “DOD Unified Capabilities (UC)”

DoDI 8500.01, “Cybersecurity,” Change 1, Effective October 7, 2019

DoDI 8510.01, “Risk Management Framework (RMF) for DOD Information Technology (IT),” March

DoDI 8520.02, “Public Key Infrastructure (PKI) and Public Key (PK) Enabling,” May 24, 2011

DoDI 8520.03, “Identity Authentication for Information Systems,” July 27, 2017

DoDI 8551.01, “Ports, Protocols, and Services Management (PPSM),” July 27, 2017

DoDI 8582.01, “Security of Unclassified DOD Information on Non-DOD Information Systems,” June 6, DoDM 5200.02 “Procedures for the DOD Personnel Security Program (PSP),” October 29, 2020

DoDM 6025.18, “Implementation of the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule in DOD Health Care Programs,” March 13, 2019

FAR Part 31.2, “Contract Cost Principles and Procedures: Contracts with Commercial Organizations”

FAR Subpart 42.5, “Post Award Orientation”

International Standards Organization (ISO)/International Electrotechnical Commission (IEC) 25010, “Systems and Software Engineering – Systems and Software Quality Requirements and Evaluation (SQuaRE) – System and Software Quality Models,” March 2011

NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” September 2011

NIST SP 800-17, “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations,” June 7, 2018 (withdrawn February 21, 2021)

NIST SP 800-171, “Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations,” Revision 2, March 9, 2021

NIST SP 800-207, “Zero Trust Architecture,” August 2020

NIST SP 800-37, “Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy,” Rev. 1, June 5, 2014

NIST SP 800-53, “Security and Privacy Controls for Information Systems and Organizations,” January 22, 2021

NIST SP 800-53a, “Assessing Security and Privacy Controls in Information Systems and Organizations,” August 2021

3 Government Furnished Property, Equipment, Information, and Services

GFP, GFE, Government Furnished Information, and Services may be provided, but none are being offered via the solicitation and should not be relied on for proposal preparation or performance purposes.

The Contractor shall maintain an inventory of all GFE and GFP received and shall be ready for turn-in or turn-over at the end of its services.

4 Contractor Furnished Items and Service

The Contractor shall furnish all supplies, equipment, facilities, and services required to perform the work listed in Section 5 of this PWS.

5 Technical Requirements

5.1 Problem

Most Theater settings lack the ability to reliably capture data electronically. Automated records are maintained 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 hinders the ability to effectively deliver operational medical logistics support 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.

Operational forces require the capability to perform electronic or automated blood management operations with store and forward ability in DIL environments that:

Avoid incomplete data capture and costs associated with paper records, transcription, and error reconciliation.

Enable accurate blood asset visibility and integrity throughout the blood product life cycle (e.g., collection, inventory, shelf-life, consumption, distribution and resupply, and disposition) across the enterprise.

Generate blood resupply based on the disposition of blood assets.

Support walking blood bank activity.

Provide automated algorithms and tools for timely forecasting of blood support requirements in deployed environments for synchronized and integrated medical logistics information to support CCMD sustainment planning and execution.

Enable management of blood data in an automated electronic format in the field, independent of network connection availability.

Unavailable data that cannot be aggregated across Theater or the enterprise seriously inhibits the ability to plan, monitor, execute, and evaluate blood operations support to deployed forces and mission sustainment.

5.2 Product Vision

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. TBLD will establish a capability to deliver the right blood operations data into the right hands at the right time so that JOMIS can support all Tri-Service operational forces and Commander decision-making for medical command and control (MedC2) planning and execution.

The current product design is one in which three major software components work together to orchestrate and deliver a coordinated data service. These are composed of a central data source, an intermediate data source scoped to a given facility or unit, and a thick client for interaction with the capability.

5.3 Scope

The key objective is to capture and organize information related to the collection, 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 key sub-capabilities that manage data around blood donors, inventory levels, blood transfusion to patients, facility and enterprise reporting, and system/user administration:

Donor Management

Inventory Management

Transfusion Management

Report Management – a web user interface component and interface with the medical common operating picture (MedCOP) for data transfer

Administration Management – User, Device, Facility Configuration, Data Integrity, and Data Synchronization Management

Minimum Viable Capability Release (MVCR) functionality for TBLD will be developed and the application will enter the testing and evaluation phase during this contract performance period. The Contractor shall provide support to operational assessment and testing, resolution of any software defects or issues identified, and written documentation required to adjudicate findings to ensure receipt of authorization to field the application and connect to required systems. This section highlights the major technical aspects of this contract, and what the Contractor shall accomplish during this PoP. Regardless of the specific events delineated in the following sections, the Contractor shall ensure that critical software, authorization, help desk, and other continuity of services supporting TBLD-M are not disrupted during this PoP.

The JOMIS PMO, Armed Services Blood Program Division, Services stakeholders, and end user community desire the capability enhancement, deployment, maintenance, and preservation of TBLD-M.

This effort will result in 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 continue to develop, enhance, and provide support services to TBLD-M capabilities utilizing data sources as determined by the Government.

If not already complete in the prior period or if updates are deemed necessary, the Contractor shall finalize implementation of independent analysis of DIL requirements to include, but not limited to, various form factors, capability sets, and store and forward design patterns at the direction of the Government. The vendor shall execute the approved strategy that supports the JOMIS disconnected, intermittent, and low-bandwidth strategy.

The Contractor shall deliver code that provides value in a timely manner. Story point estimations must be clear, consistent, and understood by the Government. The Government anticipates a minimum of sixty-five (65) story points per two-week Sprint.

The Contractor shall develop Interface Control Documents (ICDs) that detail the previously listed interfaces. The ICDs will be updated when data flow, data elements, or architecture changes occur.

The Contractor may be called upon to add additional capability to the TBLD-M application post-MVCR, to include, but not limited to, epics/functionality identified in the Capability Needs Statement expanding the Inventory Management module with enhancements requested by Tri-Service customers, and loading test data from alternate authoritative sources. Performance may also entail providing ongoing maintenance and operations support after initial fielding of the TBLD capability. Should schedules and Government resources allow, the Contractor may be asked to provide additional support.

In accordance with the Adaptive Acquisition Framework, products utilizing the software pathway will regularly report metrics to document the value or impact of the software on operation. The Contractor will provide (or support – denoted by “S”) metrics (CDRL A005) to address the following factors, as well as other metrics identified in the Program Executive Office (PEO) Defense Healthcare Management Systems (DHMS) Metrics Plan:

a) Overall user satisfaction (S).

b) Increase in Mission Effectiveness: Mission effectiveness measures the extent to which the system contributes to mission accomplishment. Ideally, mission effectiveness is evaluated using quantitative or statistical measures, although in some cases it may be evaluated through a qualitative user assessment. Examples of mission-based metrics include lethality, survivability, accuracy, etc.

c) Cost Efficiencies: Cost savings apply to the system, related systems, and mission operations.

Programs should use quantitative data if possible.

d) User Workload Reduction: Workload reduction is the reduction in the amount of effort required by an operator to accomplish a mission task. Effort relates to the number of operations required to perform the task or the cognitive ability required to perform the task. This measure can be qualitative or quantitative.

e) User Manpower Reduction: Manpower reduction is a reduction in the number of operators required to accomplish a mission task. This measure should be quantitative.

f) Equipment Footprint Reduction: Footprint reduction is a reduction in the amount of equipment required in the field in order to accomplish the mission. Equipment includes computers, racks, servers, vehicles, support equipment, or any other items that deploy with the system. Programs should use quantitative data if possible.

g) Number and Significance of Field Reports (S) (software trouble reports): Field reports document problems that the end users experience with the software. Problems can include software defects, missing features, inadequate performance, etc. Programs should use quantitative data.

h) Software Development Performance: Enhancing responsiveness to warfighter needs can include increasing software deployment frequency to provide new capabilities, add features, or address defects on a faster cycle. Other metrics such as quality (based on change fail rate) can also be used to demonstrate if the program is meeting its software development potential as part of delivering a high level of value to the user.

i) Enhanced Alignment With “To-Be” Architectures: Aligning to “to-be” architectures can enable interoperability, update to commonly used data standards, render product solutions more adaptable, and better support broader mission architectures and threads.

j) User Adoption (S) and User Satisfaction: User adoption is a quantitative measure that considers how many military units use the software in the field. Some software applications are fielded but not used, so user adoption measures how useful the military units find the software. User satisfaction is a subjective assessment by the end user that considers usability, suitability, reliability, and the overall impact the software has on performing the mission.

k) Net Promoter Score (NPS) (S): A simple and effective method to determine if customers/end-users are happy with the value generated by the product/service. Customers/end-users rate the product/service on a scale of 1-10 by answering the question, “How likely are you (the customer/end-user) to recommend this product/service to a friend or colleague?” The goal is for the NPS to increase over time.

5.4 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.

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, 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.

User stories will 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, 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 furnish 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.

Work will be accomplished in Sprints lasting two 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 One Solution Delivery Lifecycle (OneSDLC) process documentation.

While specified features and requirements (see Section 5.6) are consistent with Agile and Sprint-based development, the working rhythm or cadence will be maintained between the TBLD-M Value Team and the Contractor. As part of that cadence, the Contractor shall provide a Sprint Plan (CDRL A006) that includes, but is 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, a Project Schedule (CDRL A007) leading up to product delivery to the Government (to include, but not limited to, Sprint Schedule and other product milestones) will be developed to project the scope of work that can be accomplished within both the three (3)- and six (6)-month periods. The APM will discuss and approve the schedule which will serve as a roadmap for forthcoming delivery over the course of the PoP; it 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, per the OneSDLC process developed and maintained by JOMIS (to be provided to the Contractor).

5.5 Development Landscape and Future Environment

Migration of the existing portion of the application to a C1 compliant/compatible environment presents an opportunity to assess the current approach and determine the best viable, feasible, and desirable format for the short-term and long-term development, maintenance, and adaptability of the application.

Appendix B contains descriptions of existing systems. Additional interfaces may be required in the future.

TBLD-M will operate in a Development, Security, and Operations (DevSecOps) pipeline in the C1 environment.