MTEC-24-09-AutoDocAlgorithm RPP.pdf

Request for Project Proposals

Solicitation Number: MTEC-24-09-AutoDocAlgorithm “Passive Data Collection using Autonomous Documentation (AutoDoc) Project Algorithm

Development from Passive Sensor Suite Data Outputs”

Issued by:

Advanced Technology International (ATI), MTEC Consortium Manager (CM) 315 Sigma Drive

Summerville, SC 29486 for the

Medical Technology Enterprise Consortium (MTEC)

Request Issue Date: April 11, 2024

Proposal Due Date: May 2, 2024 Noon Eastern Time

Request for Project Proposals MTEC-24-09-AutoDocAlgorithm Number W81XWH-15-9-0001

Table of Contents

1 Executive Summary

1.1. The Medical Technology Enterprise Consortium

1.2. Purpose

2 Administrative Overview

2.1. Request for Project Proposals (RPP)

2.2. Funding Availability and Period of Performance

2.3. Acquisition Approach

2.4. Offeror Eligibility

2.5. Proposers Conference

2.6. Proprietary Information

2.7. MTEC Member Teaming

2.8. Intellectual Property (IP)

2.9. Expected Award Date

2.10. Anticipated Solutions Brief Selection Notification

3 Technical Requirements

3.1. Background

3.2. Technical Objective

3.3. Desired Solution Characteristics

3.4. Description of the Initial Dataset Provided to Performers

3.5. Potential Follow-on Tasks

4 Solution Brief Preparation and Process

4.1. Solution Brief Submission

4.2. Instructions for the Preparation of the Stage 1 Solution Brief

4.3. Instructions for the Preparation of the Stage 2 Solution Brief Pitch

4.4. Instructions for the Preparation of the Stage 3 Selection for Award 5 Selection

5.1. General Information

5.2. Solution Brief (Stage 1) - Selection and Evaluation Process

5.3. Solution Brief Pitch (Stage 2) - Selection and Evaluation Process

5.4. Definition of General Terms Used in Evaluations

6 Points-of-Contact 7 Acronyms/Abbreviations 8 Solution Brief Template Addendum 1 – Initial Sensor/Data Aggregator Data Dictionary, Variable Addendum 2 – Initial Sensor/Data Aggregator Data Dictionary, Possible Annotation Values Addendum 3 – Front and Back of the DD Form 1380, TCCC card

1 Executive Summary

1.1. The Medical Technology Enterprise Consortium

The Medical Technology Enterprise Consortium (MTEC) is an enterprise partnership in collaboration with industry and academia to facilitate research and development activities, in cooperation with the Department of Defense (DoD) U.S. Army Medical Research and Development Command (USAMRDC) and other Government agencies in the biomedical sciences (including but not limited to drugs, biologics, vaccines, medical software and medical devices) to protect, treat and optimize the health and performance of U.S. military personnel.

MTEC operates under an Other Transaction Agreement (OTA) for prototype projects with USAMRDC. In accordance with 10 USC 4022, the MTEC OTA enables the Government to carry out prototype projects that are directly relevant to enhancing the mission effectiveness of military personnel and the supporting platforms, systems, components, or materials proposed to be acquired or developed by the Department of Defense, or to improvement of platforms, systems, components, or materials in use by the armed forces. For more information on the MTEC, its mission, and the definition of prototype, see the MTEC website (www.mtec-sc.org).

1.2. Purpose

This solicitation, issued by the MTEC Consortium Manager (CM), Advanced Technology International (ATI), represents a Request for Project Proposals (RPP) for MTEC in support of the USAMRDC Telemedicine and Advanced Technology Research Center (TATRC). Proposals selected for award as a result of this RPP will be awarded under the authority of 10 U.S.C. § 4022. Strategic oversight for the award(s) supported by this RPP will be provided by TATRC.

The purpose of this RPP is focused on the development of a prototype algorithm(s) that will reliably identify and document key elements of a DD Form 1380 (TCCC card) including casualty status, key tasks performed by medics, and real-time resource use in casualty care scenarios under realistic battlefield conditions.

2 Administrative Overview

2.1. Request for Project Proposals (RPP)

MTEC is utilizing a multi-staged acquisition approach for this RPP. This is intended to provide the Government with a robust form of evaluating the best solution. The following sections describe the formats and requirements of solution proposals. Additionally, the Proposal Preparation Guide (PPG) contains several templates required for this RPP. The PPG can be found on the MTEC members only site, https://private.mtec-sc.org/. For information on how to join MTEC, please visit http://mtec-sc.org/how-to-join/.

In Stage 1 of this effort, Offerors are invited to submit Solution Briefs to describe their proposed solutions.

Offerors who submit Solution Briefs in response to this RPP should submit by the date on the cover page of this RPP. Solution Briefs may not be considered under this RPP unless received on or before the due date specified on the cover page.

Each Solution Brief submitted must be in accordance with the mandatory format provided in Section 8 of the RPP. Solution Briefs that fail to follow the mandatory format may be eliminated from the competition during the CM’s preliminary screening stage (see Section 5 for more details on the Selection process).

Note that the terms “Solution Brief” and “Proposal” are used interchangeably throughout this RPP.

2.2. Funding Availability and Period of Performance

The U.S. Government (USG) currently has available a total of approximately $982,000 for anticipated awards http://www.mtec-sc.org/ http://www.mtec-sc.org/ https://private.mtec-sc.org/ https://private.mtec-sc.org/ http://mtec-sc.org/how-to-join/ to be made through this effort during FY2024. Award and funding from the Government is expected to be limited to the funding specified above and is contingent upon the availability of federal funds for this program.

Cost sharing, including cash and in kind (e.g., personnel or product) contributions are strongly encouraged, have no limit, and are in addition to the Government funding to be provided under the resultant award(s).

MTEC expects to make at least one single award to a qualified Offeror(s) to accomplish the scope of work with a Period of Performance (PoP) not to exceed 18 months.

2.3. Acquisition Approach

As noted above, MTEC is utilizing a multi-stage approach for this effort:

• Stage 1 [Solution Brief]: MTEC Members are invited to submit a Solution Brief using the format contained in Section 8 of this RPP. The Government will evaluate proposed solutions using the criteria listed in Section 5.2 of this RPP.

• Stage 2 [Solution Brief Pitch]: Offerors who are favorably evaluated during Stage 1- Solution Brief will be invited to present and discuss their proposed solution with the Government sponsors via a virtual “pitch” of the proposed project along with a SOW/Milestone Payment Schedule and cost information. The Government will evaluate these pitches using the criteria listed in Section 5.3 of this RPP.

• Stage 3 [Selection for Award]: Upon completion of the Government’s evaluation, Offeror(s) will be notified of the final award decision. Those Offeror(s) selected for award will be invited to submit a detailed Cost Proposal in accordance with the MTEC PPG.

The due date for Solution Briefs is found on the cover page of this RPP. Solution Briefs may not be considered under this RPP unless the Solution Brief was received on or before the due date specified on the cover page.

Pending successful completion of the total effort, the Government may issue a non-competitive follow-on production contract or transaction pursuant to 10 U.S.C. § 4022 section f.

The Government-selected prototype project(s) awarded as a result of this solicitation will be funded under the Other Transaction Agreement for prototype projects (OTA) Number W81XWH-15-9-0001 with MTEC administered by the CM, ATI. The CM will negotiate and execute a Base Agreement with MTEC members (if not yet executed). The same provisions will govern this Base Agreement as the OTA for prototype projects between the Government and MTEC. Subsequently, any proposal that is selected for award will be funded through a Research Project Award issued under the member’s Base Agreement. The MTEC Base Agreement can be found on the MTEC website at www.mtec-sc.org/documents-library/.

At the time of the submission, if Offerors have not yet executed a Base Agreement, then Offerors must certify on the cover page of their Solution Brief that, if selected for award, they will abide by the terms and conditions of the latest version of the MTEC Base Agreement. If the Offeror already has executed an MTEC Base Agreement with the MTEC CM, then the Offeror must state on the cover page of its Solution Brief that, if selected for award, it anticipates the proposed effort will be funded under its executed MTEC Base Agreement.

2.4. Offeror Eligibility

Offerors must be MTEC Members in good standing to be eligible to submit a proposal. Offerors submitting Solution Briefs as the prime performer must be MTEC members of good standing at least 3 days prior to http://www.mtec-sc.org/documents-library/ submission of the Solution Brief. Subcontractors (including all lower tier subawardees) do not need to be MTEC members. To join MTEC, please visit http://mtec-sc.org/how-to-join/.

At the time of the submission, if Offerors have not yet executed a Base Agreement, then Offerors must certify on the cover page of their Proposal that, if selected for an award, they will abide by the terms and conditions of the latest version of the MTEC Base Agreement. If the Offeror already has executed an MTEC Base Agreement with the MTEC CM, then the Offeror must state on the cover page of its Proposal that, if selected for an award, it anticipates the proposed effort will be funded under its executed MTEC Base Agreement.

2.5. Proposers Conference

MTEC intends to host a Proposers Conference that will be conducted via webinar within two (2) weeks of the release of the RPP. The intent of the Proposers Conference is to provide an administrative overview of this RPP and to present further insight into the technical requirements outlined in Section 3 of this RPP. Further instructions will be forthcoming via email. Offerors are advised to check the MTEC website periodically during the proposal preparation period for any clarifications found in Frequently Asked Questions (FAQ) responses.

The presentation slides and a transcript of the questions and answers session of the Proposers Conference will be posted to the MTEC members-only website.

2.6. Proprietary Information

The MTEC CM will oversee submission of Solution Briefs submitted in response to this RPP. The MTEC CM shall take the necessary steps to protect all proprietary information and shall not use such proprietary information for purposes other than the evaluation of an Offeror’s Solution Brief, Solution Brief Pitch, and the Demonstration of a proposed technology. In accordance with the MTEC Proposal Preparation Guide (PPG), please mark all Confidential or Proprietary Information as such. An Offeror’s submission of a Proposal under this RPP indicates concurrence with the aforementioned CM responsibilities.

Also, as part of MTEC’s mission to incorporate philanthropic donations, MTEC frequently makes contact with private entities (e.g., foundations, investor groups, organizations, individuals) that award grants or otherwise co-fund research, and/or operates in research areas that are aligned with those of MTEC. These private entities may be interested in reviewing certain proposals within their program areas, allowing for opportunities to attract supplemental funding sources. Therefore, on your Solution Brief Cover Page, please indicate your willingness to allow MTEC Officers and Directors access to your proposal for the purposes of engaging in outreach activities with these private entities. MTEC Officers and Directors who are granted proposal access have signed Nondisclosure Agreements (NDAs) and Organizational Conflict of Interest (OCI) statements. Additionally, all Technical Evaluation Panel participants, which may include contractor support personnel serving as nongovernmental advisors, will agree to and sign a Federal Employee Participation Agreement or a Nondisclosure/Nonuse Agreement, as applicable.

2.7. MTEC Member Teaming

While teaming is not required for this effort, Offerors are encouraged to consider teaming during the proposal preparation period (prior to Solution Brief submission) if they cannot address the full scope of technical requirements of the RPP or otherwise believe a team may be beneficial to the Government. The following resources may help Offerors form a more complete team for this requested scope of work.

• The MTEC M-Corps is a network of subject matter experts and service providers to help MTEC members address the business, technical, and regulatory challenges associated with medical product development. Please visit https://www.mtec-sc.org/m-corps/ for details on current partners of the M- Corps.

http://mtec-sc.org/how-to-join/ https://www.mtec-sc.org/m-corps/

• MTEC Database Collaboration Tool to help identify potential teaming partners among other MTEC members. Contact information for each organization is provided as part of the member profile in the collaboration database tool to foster follow-up conversations between members as needed. The Collaboration Database Tool can be accessed via the “MTEC Profiles Site” tab on the MTEC members-only website.

• A dedicated Teaming Connect will be held to facilitate direct interaction amongst MTEC members in relation to this active funding opportunity. This will be a virtual “connect” session via ZOOM where MTEC members will be allowed to provide brief pitch presentations regarding to their ongoing work, organizational capabilities, and teaming preferences. More information on this event will be provided after the release of this RPP.

2.8. Intellectual Property (IP)

Baseline IP and Data Rights for MTEC Research Project Awards are defined in the terms of an awardee’s Base Agreement and, if applicable, specifically negotiated terms are finalized in any resultant Research Project Award. MTEC reserves the right to assist in the negotiation of IP, royalties, licensing, future development, etc., between the Government and the individual performers prior to final award decision and during the entire award period.

The Offeror shall comply with the terms and conditions contained in their Base Agreement regarding IP and Data Rights, as modified by the specifically-negotiated IP and Data rights terms herein. Due to this project’s unique requirements, the Government is identifying, in this RPP, the following level of specifically-negotiated IP and Data rights which are required for this project. The Awardee shall grant to and/or obtain for the Government, Government Purpose Rights to all Category A and Category B Data including all documents, software, and materials developed under this award, and those developed prior to award by the Awardee or other entity, which are needed for the purposes of cybersecurity assessments, software updates, upgrades and capability insertions for future enhancements of the project deliverables (this may include but is not limited to executables, source code, algorithms, associated scripts, build procedures, automation scripts, tools, databases, libraries, test results, data sets, firmware, and training materials). The documents, software, and materials developed under this award, as well as those developed prior to award as mentioned in the preceding sentence, shall be Offeror owned, with the Government receiving Government Purpose Rights therein. Any Commercial Computer Software and/or Data needed for the purposes herein described must be delivered with a commercial license granting to the Government rights equivalent to the Government Purpose Rights described herein. The documents, software and materials produced under the Award shall not be sold back to a different Government entity as the Government is receiving Government Purpose Rights therein. All documents, materials and software supplied to the Government under this Award shall be conveyable to other government entities and third parties within the limitations of a Government Purpose Rights license as mentioned above, with no notice to or authorization from the Offeror needed. This right does not abrogate any other Government rights. For purposes of this this section (i.e., paragraph 2.11), the terms “developed” and “government purpose” shall have the same definition as utilized in DFARS 252.227-7014.

See Attachment 6 of the PPG for more detail. Note that as part of the Stage 1 of the RPP process (submission of a Solution Brief), Offerors shall complete and submit Attachment 6 of the PPG (Intellectual Property and Data Rights) as an appendix to the Solution Brief with the Signature of the responsible party for the proposing Prime Offeror.

For more information, the CM has published a resource for Offerors entitled, “Understanding Intellectual Property and Data Rights” on the MTEC members-only website.

2.9. Expected Award Date

Offerors should plan on the POP beginning September 2024 (subject to change). The Government reserves the right to change the proposed POP start date through negotiations via the CM and prior to issuing a Research Project Award.

2.10. Anticipated Solutions Brief Selection Notification

As the basis of selections is completed, the Government will forward its selections to the MTEC CM to notify Offerors. All Proposers will be notified by email from the MTEC CM of the results of the evaluation. Those successful will move forward to the next stage of the process.

Offerors are hereby notified that once a Solution Brief has been submitted, neither the Government nor the MTEC CM will discuss evaluation/status until after the Offeror receives the formal notification with the results of this evaluation.

3 Technical Requirements

3.1. Background

The Military Health System (MHS) lacks a robust, accurate, and reliable methodology to collect, store, and track tactical combat casualty care (TCCC) data. Establishing a prehospital environment medical data set is an essential, foundational step to modernizing Military TCCC medical care. Without a means to collect and seamlessly transmit data reliably and passively from the point of need/care (e.g. point of injury [POI] through higher echelons of care), the MHS will continue to lack the essential data to develop a trustworthy artificial intelligence (AI) stack1,2 to support future concepts that will sustain Military medical operations in the various environments of Multi-Domain Operations (MDO), including, but not limited to Large Scale Combat Operations (LSCO). By leveraging trustworthy AI in future conflicts, the MHS can reduce the caregiver cognitive load and mitigate impacts of a LSCO medical asset overburden, enabling greater efficiencies and capabilities.

Military prehospital care often occurs in austere, chaotic environments.

Military medics and combat lifesavers in the battlespace are focused on prioritizing casualty severity and managing a large patient load with limited supplies and assistance. During times of intense activity, they must prioritize their patients over documenting delivering care to save the lives of their fellow warfighters. Medical documentation for these providers is challenging, if not impossible in many instances. Being able to capture the medical care being delivered in these venues may be secondary to saving lives in that moment; however, the need for timely, accurate medical documentation remains. In the near term, this data generates valuable information to higher echelons of care, medical resupply/logistics systems, and Command situational awareness (SA).

The additional, long-term benefit is the ability to leverage machine learning (ML) and AI to enhance care delivery in the tactical environment in the future based on lessons learned from current care requirements (see Figure 1).

1 Cindy Crump, Loretta M. Schlachta-Fairchild, "Achieving a trusted, reliable, AI-ready infrastructure for military medicine and civilian care," Proc. SPIE 11413, Artificial Intelligence and Machine Learning for Multi-Domain Operations Applications II, 114130C (21 April 2020); doi: 10.1117/12.2557514 2 Carnegie Mellon University School of Computer Science, “AI Stack,” (2019).

Figure 1. Automation Stack1,2

*Note: Adapted from the Carnegie Mellon

University School of Computer Science

To enhance TCCC and improve medical documentation in the MHS, a passive, (e.g., with minimal human effort) autonomous documentation solution of medical care in operational environments is essential. Furthermore, it is vital that the processes in collecting this data does not distract the medic/caregiver’s capability and capacity to deliver care.

Current medical IT capabilities rely on combat medics diverting their attention away from care delivery to document their efforts. This either detracts from the medics’ capability and capacity for performing essential care tasks or necessitates documentation in a delayed manner, often under significant time constraints, that reduce the quality and accuracy of the documentation. In future LSCO engagements, medical assets will be significantly stressed, increasing the likelihood of poor-quality documentation, whether incomplete or completely absent.

At present, the MHS has two programs of record (POR)/program instructions that focus on providing resources to document combat casualty care:

(1) The Joint Operational Medicine Information Systems (JOMIS) under the Program Executive Office, Defense Healthcare Management Systems (PEO DHMS) provides interoperable medical information technology (IT) capabilities across the full spectrum of military operations using tactical communication networks. The JOMIS portfolio includes capabilities for Medical Mission Command, MHS Genesis Theater electronic health record (EHR), Operational Medical Data cloud, and a virtual health capability. A recent addition to the JOMIS portfolio is a medical IT software solution to document combat causality care called Battlefield Assisted Trauma Distributed Observation Kit (BATDOK). BATDOK’s software tools were developed by the Air Force Research Laboratory (AFRL) and are leveraged at the POI and lower echelons of care (e.g., Roles 1-2).

(2) The Medical Communications for Combat Casualty Care (MC4) under the Program Executive Office, Enterprise Information Systems (PEO EIS), which will transition to Operational Medical Information System – Army (OMIS-A) in fiscal year (FY) 24. The OMIS-A Role 1 and 2 centered portfolios include the MC4 semi-ruggedized system of systems containing fielded medical software systems, for initial EHR documentation, medical logistic ordering, and medic screening.

Thus, both the JOMIS and MC4 programs could benefit from the research, development and use of passive, autonomous documentation in tactical military medical care, largely independent of caregiver interactions, will lead to opportunities to inform and potentially achieve the following modernizations (see Figures 2):

• Semi-autonomous casualty care delivery

• Autonomous resource triage/assessments

• Autonomous resupply

• Autonomous resupply / medical regulating

• Just in Time (JIT) decision making across echelons of care

• JIT situational awareness for military leaders / decision makers

Figure 2. Operational Viewpoint (OV-1):

High Level Operational Concept Graphic for the AC2 Portfolio

3.2. Technical Objective

To augment and supplement the current processes of medical documentation for TCCC, it is necessary to develop passive data inputs into the medical IT systems of record to reduce and or eliminate the need for manual entry of care delivery into these systems. This will allow the medic/combat lifesaver to remain focused on their primary task, saving lives. The Autonomous Casualty Care (AC2) Research Portfolio and the Passive Data Collection using AutoDoc project is already underway developing systems of sensor suites that passively collect data observing casualty status, caregiver (e.g., medic and/or combat lifesaver) actions, and real time resource usage.

The current aim of the AutoDoc project being solicited for in this RPP is the development of algorithms that leverage passive sensor suite data collection to identify casualty status, caregiver actions and resource usage.

Developed algorithms are expected to autonomously render this information into discrete data that can be used to autonomously populate a digital DD Form 1380 (TCCC card) (See Addendum 3).

In its entirety, the Government requires the development of autonomous documentation algorithms to address the following 5 core functions:

• Patient identification and demographic information

• Identification and description of injury(ies)

• Collection of physical signs and symptoms including, but not limited to pain scale measurements

(e.g., Alert, Voice, Pain, Unresponsive (AVPU) scale et al.)

• Identification and documentation of care provided (e.g., procedures/treatments) rendered (and when applicable, how aligned to standards [CPT codes, ICD-10, et al.])

• Identification and documentation of additional notes and care provider identification (Note: this includes associating documentation data with the correct patient and caregivers, especially in multi-casualty/multi-caregiver scenarios)

This RPP is designed to allow the offerors to propose algorithm work based on their areas of expertise and experience. Offerors are encouraged to propose solutions that meet as many of the desired core functions (listed above) as possible at the time of proposal submission. If applicable, Offerors should provide clear strategies for incorporating all other desired Core functions during the POP. While teaming is not required for this effort, Offerors are encouraged to consider teaming during the proposal preparation period (prior to Solution Brief submission) if they cannot address each of the core functions required for this effort.

Furthermore, the Government reserves the right to encourage teaming arrangements between any or all of the awardees to collaborate during the POP to maximize the number of the core functions addressed.

Additionally, the awardees will be expected to collaborate with awardees from a prior OTA on sensor suites (MTEC-24-05-AutoDocSensor), specifically to leverage the data collected from the sensor suites for the purposes of enhancing data sets that will support more robust models. See Figure 3 for more information on the expected structure for the proposed POP.

Figure 3. Passive Data Collection using Autonomous Documentation (AutoDoc) Project Phases

Note: Performers for Task 1 have already been solicited for through the MTEC-24-05-AutoDocSensor effort. As such, Offerors responding to this RPP will only be required to propose solutions for Task 2.

At the end of the POP phases (See Figure 3 - e.g., 6 month, 12 months and/or 18 months), the Offeror is expected to deliver to the Government a Technical Data Package to include a software design description, computer software product (e.g., executables, source code, and algorithms), software test plan, and verification and validation support documentation. At these times, the Government will conduct independent peer review and assessments of the prototype algorithms that have been developed using a data set not previously provided to the performers. The specific process of the independent Government assessment would include a time limited, competitive “challenge” related to the proposed development concepts for the next phase/task (e.g., Task 2B/2C) to assess the validity of the approach prior to “go-no go” decision by Government. This independent assessment “challenge” will be specific to the core functions of the selected performer, but generally focuses on the following elements when reviewing the design and performance of the algorithms:

• Scientific merit of the existing phase of algorithm deliverables and results of the competitive “challenge” focused on proposed future development phases with respect to:

o Value: ability to passively document care and autonomously populate DD Form 1380 (TCCC card) fields accurately, efficiently, and reliably (see further metrics).

o Accuracy (including but not limited to sensitivity, specificity, false positive/false negative results) and robustness of algorithms across varied conditions/use cases.

o Complexity of code: time (how long it takes to run) and space complexity (how much memory and storage use) o Efficiency of code: to include, but not limited to, appropriateness for future edge computing use cases o Reliability to run full length of task o The simplicity of updating software and incorporating new features.

o Approach to data quality and potential bias (e.g., performers approach to data processing, algorithm development and validation) o Compatibility with other existing AutoDoc algorithms, as applicable

3.3. Desired Solution Characteristics

Proposed solution sets should expect to conform to the following desired solution characteristics to satisfy a Minimum Viable Product (MVP), including Documentation Requirements outlined below. Offerors are encouraged to propose solutions that meet as many of the desired solution characteristics (listed below) as possible at the time of proposal submission with clear strategies for incorporating all other desired characteristics during the POP.

Desired solution characteristics of the Algorithm Solution Sets

1. The algorithm development work must address a one or more specific autonomous functions to leverage passive sensor suite data collection that identify casualty status, caregiver actions and resource usage and autonomously renders this information into discrete data that can be used to autonomously populate a digital DD Form 1380 (TCCC card). These include:

i. Patient identification and demographic information

ii. Identification and description of injury(ies)

iii. Collection of physical signs and symptoms including, but not limited to pain scale measurements (e.g., AVPU scale et al.)

iv. Identification and documentation of care provided (e.g., procedures/treatments) rendered (and when applicable, how aligned to standards [CPT codes, ICD-10, et al.])

v. Identification and documentation of additional notes and care provider identification (Note:

this includes associating documentation data with the correct patient and caregivers, especially in multi-casualty/multi-caregiver scenarios)

2. The algorithm(s) must be designed for integration into a single software solution, requiring a modular design, with the ability to be combined with others and managed by orchestrating software developed and managed by USATATRC to achieve an overall function of autonomous documentation process in one solution.

3. The algorithm(s) must be provided either as raw source code or packaged as executables, application programming interfaces (APIs), or docker containers, aligning with the strategy to containerized algorithm models and integrate them with the AutoDoc main software pipeline.

4. The algorithm(s) must leverage standard computing language, with the following order of preference:

i. Kotlin: preferably version 1.9.XX and above

ii. JAVA: If Kotlin isn’t feasible, pure JAVA implementation is the next most desirable computing language, version 17 and above

iii. Python and C/ C++ with static Java Native Interface (JNI). Performer should wrap other languages, preferable Python 3.8 or above, along with GNU Compiler Collection (GCC) 7.X or higher, or any compatible version with selected JetPack, Kotlin APIs and provide static JNI libraries, as applicable.

iv. Python and C/C++ with Dynamic JNI. Dynamic JNI libraries are acceptable, but the least desirable due to potential complexities (e.g., when using platform specific libraries such as NVIDIA CUDA libraries)

5. The algorithm(s) must be designed to run in a Linux environment, preferably Ubuntu 20.04 for desktop and Linux for Tegra (L4T) based on JetPack 5.0+ for NVIDIA Jetson device, with optional compatibility for Windows.

6. The algorithm(s) must be designed and developed as a continuous learning algorithm (e.g., an adaptive algorithm) that can learn and improve performance over time and the introduction of additional data sources.

7. The algorithm(s) must ultimately function independently on an edge computing device without continuous reliance on continuous connectivity to a cloud solution set.

8. The performer will leverage a common data set located on a cloud environment to train their algorithms during the development process.

9. The algorithm(s) must be designed in a manner that is suitable for Government use for the AutoDoc research project.

Documentation requirements: Documentation for the algorithm development should include, but is not limited to:

Proposal Documentation Requirements:

• Describe the research methodologies utilized in designing, developing, and validating the algorithmic model for specific tasks related to elements of a digital DD Form 1380. This should include a project plan /approach to development of the algorithm(s) and determining their features, including type of model (e.g., linear, tree-based, neural network, etc.), loss function, optimizer, network layer structure (if relevant), and other relevant components, during the data processing/curation/randomization.

• Describe possible sources of model bias (e.g., medic/patient characteristics, input down sampling, environmental conditions) and efforts taken to mitigate associated risks.

• Propose a plan for tracking and maintaining model performance post-deployment.

• Proposed constructs and/or instructions for running and retaining models.

• Describe the model training and assessment process (e.g., additional data processing, training iterations, fine-tuning procedures, data splitting, performance test, and other relevant aspects, as applicable)

Algorithm Deliverable Documentation Requirements:

• Provide an overview of the full algorithm development pipeline, ideally as a diagram clearly delineating inputs and output with data types, specified formats, frequencies, and process timing management (if multi-processing).

• Provide the minimum hardware specifications required for running the algorithm(s)

• Provide step-by-step instructions to manually run the algorithm(s) on pre-collected data.

• Provide detailed instructions to integrate the algorithm(s) with the AutoDoc main software pipeline to run on real-time, live data.

Additional requirements of note:

• Selected performer(s) will be expected to participate in interoperability working group meetings

(approximately 2 times per month) to ensure that the data outputs from the algorithm efforts result in standardization/interoperability.

• Selected performer(s) will be expected to optimize their developed algorithms to run on edge computing devices and share computing resources with other concurrently running algorithms in an integrated solution.

• Selected performer(s) will be required to provide the Government with specific networking details (e.g., IP addresses of specific computer systems) to gain access (whitelisting et al) to the cloud based AC2 research data repository at the time of award.

Selected performer(s) will be required to submit an DoD Institutional Agreement for Institutional Review (IAIR) application with USATATRC. This includes having a designated Institutional signatory official, an active Federal Wide Assurance (FWA) number, signed Conflict of Interest (COI) forms from all team members engaged in the effort, CITI training certificates from all team members engaged in the effort, and a Delegation of Authority Log (DoAL) listing all team members and their roles for the TATRC regulatory research team members.

3.4. Description of the Initial Dataset Provided to Performers USATATRC is actively building a dataset of recorded, simulated TCCC patient care scenarios for the expressed aim of developing algorithms and solutions to automate patient documentation. These datasets are collected using multi-modal suites of sensors which record ego-centric video of the care provider, audio of the care scenario, accelerometry of the care provider’s hands, and direct vitals acquired from patient placed devices.

Datasets throughout the POP may include additional sensor modalities. The TCCC patient care scenarios are conducted in varied settings and with both high-fidelity mannequin and live actors as injured causalities.

Initial datasets are annotated with metadata from the structured scenario, the care provider task start and stop times from clinical subject matter experts (SMEs). Additional annotations of the data specific to the performer’s algorithms will need to be annotated/labeled by the performers. The data will be made available through the AGENT RAPIDS platform (Figure 4). For more information on AGENT RAPIDS, please visit the following website: https://rapids.ll.mit.edu/home.

Figure 4. Agent RAPIDS Platform: AC2 Cloud Repository Resource for Algorithm Development https://rapids.ll.mit.edu/home

Additionally, information on the early-stage sensor suite prototype available at the time of publishing this RPP is based on a relational database, described in the tables found in Addendum 1 and 2 of this RPP.

However, the more mature data set is anticipated to migrate to common standards such as the FHIR (Fast Healthcare Interoperable Resources) model. As such, the information provided in Addendum 1 and 2 is intended to provide an example summary of the initially available data inputs and annotations to populate a DD Form 1380 (TCCC card) properly and autonomously, but it is not an exhaustive list. TATRC will passively collect data from their sensor suites to generate a feature set for performers that will serve as a source to leverage and model features for algorithms.

3.5. Potential Follow-on Tasks

Under awards resulting from this RPP, there is the potential for award of one or more non-competitive follow-on tasks based on the success of the project (subject to change depending upon Government review of completed work and successful progression of milestones). Potential follow-on work may be awarded based on the advancement in prototype maturity during the PoP.

Offerors are encouraged, as appropriate, to discuss potential follow-on work in Solution Brief submission to demonstrate the ability to further advance the project maturity beyond the proposed PoP. This will also allow the Offeror to highlight the potential capabilities that can be explored/achieved through short term and/or long-term advancement of the project in a way that is beneficial to the Government. In particular, the government encourages Offerors to discuss potential refinements their solution set with the following use cases in mind: (1) single caregiver and casualty; (2) multiple caregivers and causalities; (3) mass causality use cases and (4) enroute and higher echelons of care.

4 Solution Brief Preparation and Process

4.1. Solution Brief Submission

Solution Briefs shall be submitted by the date and time specified on the cover page using BIDS:

https://ati2.acqcenter.com/ATI2/Portal.nsf/Start?ReadForm. Include the MTEC-24-09-AutoDocAlgorithm on each Solution Brief submitted. See Attachment 7 of the PPG for further information regarding BIDS registration and submission.

An automated BIDS receipt confirmation will be provided by email. Offerors may submit in advance of the deadline. Neither MTEC nor ATI will make allowances/exceptions for submission problems encountered by the Offeror using system-to-system interfaces. If the Offeror receives errors and fails to upload the full submission prior to the submission deadline, the submission may not be accepted. It is the Offeror’s responsibility to ensure a timely and complete submission.

All eligible Offerors may submit proposals for evaluation according to the criteria set forth herein. Offerors are encouraged to contact the Points-of-Contact (POCs) identified herein until the Proposal due date/time to clarify requirements (both administrative and technical in nature).

4.2. Instructions for the Preparation of the Stage 1 Solution Brief Offerors submitting Solution Briefs in response to this RPP should prepare all documents in accordance with the following instructions:

Offerors should submit files in Microsoft Office formats or Adobe Acrobat (PDF – portable document format) as indicated below. ZIP files and other application formats are not acceptable. All files must be print-capable and without a password required. Filenames must contain the appropriate filename extension (.docx, .doc, .pptx, .ppt .xlsx, .xls or .pdf). Filenames should not contain special characters. Apple users must ensure the https://ati2.acqcenter.com/ATI2/Portal.nsf/Start?ReadForm entire filename and path are free of spaces and special characters.

Required Submission Documents (5): Submitted via BIDS. Individual submission documents must be 5MB or lower.

• Solution Brief: One Word or PDF document (Required template is provided in Section 8 of this RPP)

• Warranties and Representations: one Word or PDF document (See Attachment 3 of the PPG)

• Current and Pending Support: one Word or PDF document (Attachment 5 of the PPG) summarizing other sponsored research for each person who will contribute significantly to the proposed prototype project. The information for previous support should include the past five (5) years, unless otherwise specified in the request.

• Intellectual Property and Data Rights Assertions: one signed Word or PDF document (See Attachment 6 of the PPG)

• Documentation: one Word or PDF document including the following information:

a. Summary of current solution capabilities with regards to the specific core functions the Offeror is proposing to develop from the list below:

• Patient identification and demographic information

• Identification and description of injury(ies)

• Collection of physical signs and symptoms including, but not limited to pain scale measurements (e.g., Alert, Voice, Pain, Unresponsive (AVPU) scale et al.)

• Identification and documentation of care provided (e.g., procedures/treatments) rendered (and when applicable, how aligned to standards [CPT codes, ICD-10, et al.])

• Identification and documentation of additional notes and care provider identification (Note: this includes associating documentation data with the correct patient and caregivers, especially in multi-casualty/multi-caregiver scenarios)

Solution Briefs must be prepared according to the mandatory format provided in Section 8 of this RPP. The Solution Brief is limited to seven pages (plus a cover page for a total of eight pages). References may be included in the Solution Brief and are excluded from the page limitation. Appendices are also excluded from the page limitation. Formatting requirements include 11-point font (or larger), single-spaced, single-sided, inches x 11 inches. Smaller type may be used in figures and tables but must be clearly legible. Margins on all sides (top, bottom, left, and right) should be at least 0.5 inch. Solution Briefs exceeding the page limit may not be accepted.

FOR INFORMATION ONLY: Additional attachments/appendices (henceforth referred to as supplemental information) to the Solution Brief submission may be requested after completion of the Stage 1 Solution Brief evaluation. The exact requirements of any such attachment/appendix are subject to change and will be provided at the time (or immediately following) the Stage 1 evaluation summary is provided.

4.3. Instructions for the Preparation of the Stage 2 Solution Brief Pitch Upon review of the Solution Briefs, Offerors may be invited into Stage 2 of this effort. Offerors that are recommended for Stage 2 will receive notification letters which serve as formal requests for Stage 2 (Solution Brief Pitches) and may contain requested revisions or supplemental information. These letters will contain specific submission requirements if there are any changes to those contained in this RPP. However, it is anticipated that the following will be required:

Required Submission Documents (2): Submitted via BIDS. Individual submission documents must be 5MB or lower.

1) Solution Pitch: One PDF document.

2) Statement of Work: One Word or PDF document (See Attachment 4 of the PPG)

In Stage 2, the Offeror(s) will provide a virtual “pitch” of the proposed project during a meeting with the Government. The solution brief pitch should provide more details about the proposed technology outlined in Stage 1 (Solution Brief). The information discussed during the solution brief pitch provides a means for the Government to engage in a discussion with the Offeror to gain a greater understanding of the proposal and the Offeror’s capabilities. The solution brief pitch should be restricted to a maximum of 20 minutes for the presentation by the Offeror with a total time of 45 minutes to include questions from the Government. Any materials that will be presented during the solution brief pitch or included as supplementary material must be provided in advance of the meeting date. Briefing slides or documents or a combination thereof can be used to support this effort.

The Solution Brief Pitch is expected to include the following:

• Technology Description and Approach: A more robust description of the technology, approach and emphasize why this approach is expected to result in a successful outcome. This discussion should include relevance to the military use cases.

• Development Strategy (including timing and regulatory): Feasibility of the Offeror’s product development strategy, including regulatory pathway (as applicable), indication of use and designation, strategy for obtaining regulatory approvals or clearances. Offerors are also encouraged to include costs associated with their development strategy.

• Interoperability: The Offeror will convey details related to product interoperability with compatible systems and plans for future algorithm inclusion.

• Relevant Experience: The Offeror will convey details related to key personnel and past performance(s) that demonstrate relevance to the program objective and solution requirements described in Section 3 of this RPP and build confidence in the team’s capabilities.

• Effectiveness (Opportunity and Risk): The Offeror will identify, assess, evaluate, and clearly convey items for opportunities (e.g., reduction in cost or schedule, and/or improvement in performance) and risks within each appropriate project measure, and the mitigation plan for each identified risk item.

• Partnerships/Collaborations: The Offeror will describe any current or potential partnerships or collaborations that may be of use when developing this product, especially in regards to algorithm development. Partnering with Government laboratories may be required downstream.

• Competitive Advantage: A clearly defined competitive advantage of the proposed solution over already existing solutions and other solutions in development by others in the field.

• Military Transition: Offeror will describe the pathway to developing this into a product that can be used by the military.

4.4. Instructions for the Preparation of the Stage 3 Selection for Award Offerors that are recommended for award will receive notification letters which will serve as the formal request for a full Cost Proposal (and may contain a request for revisions and/or supplemental information based on the results of the technical evaluation). These letters will contain specific submission requirements if there are any changes to those contained in this RPP. However, it is anticipated that the following will be required:

Required Submission Documents (2): Submit to mtec-contracts@ati.org

• Section I: Cost Proposal Narrative as one Word or PDF document.

• Section II: Cost Proposal Formats as one Excel or PDF document.

See the PPG for additional instructions for submission requirements. Also refer to Attachment 7 of the PPG for details on how the full Cost Proposals will be evaluated.

5 Selection

5.1. General Information

Evaluations at all stages of the Solution Brief acquisition process shall be based on an independent, comprehensive review and assessment of the work proposed against stated evaluation factors. A rating consistent with these evaluation factors will be derived from the ability of the Offeror to perform the work in accordance with all aspects of requirements outlined in this RPP. The Offeror shall clearly state how it intends to meet the RPP requirements. Mere acknowledgement or restatement of a RPP requirement is not acceptable.

The Solution Brief and/or the Solution Brief Pitch process may involve the use of contractors as subject matter experts (SME) serving as nongovernmental advisors. Where appropriate, MTEC will employ NDAs to protect information contained in submissions. All members of the technical evaluation panel, to include contractor SMEs, will agree to and sign a Federal Employee Participation Agreement or a Nondisclosure/Nonuse Agreement, as appropriate, prior to accessing any proposal submission to protect information as outlined in Section 2.6. The adjectival merit ratings that will be used for all evaluation factors are shown in Table 1.

TABLE 1- GENERAL MERIT RATING ASSESSMENTS

RATING DESCRIPTION

OUTSTANDING Proposal meets requirements and indicates an exceptional approach and understanding of the requirements. Strengths far outweigh any weaknesses.

Risk of unsuccessful performance is very low.

GOOD Proposal meets requirements and indicates a thorough approach and understanding of the requirements. Proposal contains strengths which outweigh any weaknesses. Risk of unsuccessful performance is low.

ACCEPTABLE

Proposal meets requirements and indicates an adequate approach and understanding of the requirements. Strengths and weaknesses are offsetting or will have little or no impact on contract performance. Risk of unsuccessful performance is no worse than moderate.

MARGINAL…