"Passive Data Collection using Autonomous Documentation (AutoDoc) Project Algorithm Development from Passive Sensor Suite Data Outputs"

From: Federal Government(Federal)
MTEC-24-09-AutoDocAlgorithm

Basic Details

started - 12 Apr, 2024 (18 days ago)

Start Date

12 Apr, 2024 (18 days ago)
due - 02 May, 2024 (Tomorrow)

Due Date

02 May, 2024 (Tomorrow)
Bid Notification

Type

Bid Notification
MTEC-24-09-AutoDocAlgorithm

Identifier

MTEC-24-09-AutoDocAlgorithm
DEPT OF DEFENSE

Customer / Agency

DEPT OF DEFENSE (710030)DEFENSE HEALTH AGENCY (DHA) (2294)ARMY MED RES ACQ ACTIVITY (387)

Attachments (1)

unlockUnlock the best of InstantMarkets.

Please Sign In to see more out of InstantMarkets such as history, intelligent business alerts and many more.

Don't have an account yet? Create a free account now.

The Medical Technology Enterprise Consortium (MTEC) is excited to post this summary announcement for the MTEC-24-09-AutoDocAlgorithm Request for Project Proposals (RPP) 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.As stated at the end of this announcement, the full RPP is posted to the MTEC website (mtec-sc.org); this notice is intended only to notify interested parties of the available solicitation.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) stack 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). 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 an essential requirement to establishing these critical TCCC data sets. 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 absent, poor-quality, or incomplete documentation. The 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:Semi-autonomous casualty care deliveryAutonomous resource triage/assessmentsAutonomous resupplyAutonomous resupply / medical regulatingJust in Time (JIT) decision making across echelons of careJIT situational awareness for military leaders / decision makersTechnical 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).In its entirety, the Government requires the development of autonomous documentation algorithms to address the following 5 core functions:Patient identification and demographic informationIdentification 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.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 SetsThe 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:Patient identification and demographic informationIdentification and description of injury(ies)Collection of physical signs and symptoms including, but not limited to pain scale measurements (e.g., 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)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.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.The algorithm(s) must leverage standard computing language, with the following order of preference:Kotlin: preferably version 1.9.XX and aboveJAVA: If Kotlin isn’t feasible, pure JAVA implementation is the next most desirable computing language, version 17 and abovePython 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.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)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.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.The algorithm(s) must ultimately function independently on an edge computing device without continuous reliance on continuous connectivity to a cloud solution set.The performer will leverage a common data set located on a cloud environment to train their algorithms during the development process.The algorithm(s) must be designed in a manner that is suitable for Government use for the AutoDoc research project.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.Potential Funding Availability and Period of Performance:The U.S. Government (USG) currently has available a total of $982,000 for anticipated awards to be made through this effort during Fiscal Year (FY) 2024. 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.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. Acquisition Approach:The RPP will be conducted using a multi-stage acquisition approach.Stage 1 [Solution Brief]: MTEC Members are invited to submit a Solution Brief using the format contained in the upcoming RPP.Stage 2 [Solution Brief Pitch]: Offerors who are favorably evaluated during Stage 1- Solution Brief based on the RPP criteria 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.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 Proposal Preparation Guide (PPG).MTEC Member Teaming:While teaming is not required for this effort, Offerors are encouraged to consider teaming during the proposal preparation period (prior to 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. Refer to the RPP for resources that may help Offerors form a more complete team for this requested scope of work, such as the MTEC M-Corps, MTEC’s Database Collaboration Tool, and the dedicated MTEC Teaming Connect.MTEC:The MTEC mission is to assist the U.S. Army Medical Research and Development Command (USAMRDC) by providing cutting-edge technologies and supporting life cycle management to transition medical solutions to industry that protect, treat, and optimize Warfighters’ health and performance across the full spectrum of military operations. MTEC is a biomedical technology consortium collaborating with multiple government agencies under a 10-year renewable Other Transaction Agreement (OTA), Agreement No. W81XWH-15-9-0001, with the U.S. Army Medical Research Acquisition Activity (USAMRAA). MTEC is currently recruiting a broad and diverse membership that includes representatives from large businesses, small businesses, “nontraditional” defense contractors, academic research institutions and not-for-profit organizations.Point of Contact:For inquiries, please direct your correspondence to the following contacts:Questions concerning contractual, cost or pricing related to this RPP should be directed to the MTEC Contracts Administrator, mtec-contracts@ati.orgTechnical and membership questions should be directed to the MTEC Research Associate, Dr. Chuck Hutti, Ph.D., chuck.hutti@ati.org All other questions should be directed to the MTEC Program Manager, Mr. Evan Kellinger, mtec-sc@ati.orgTo view the full-length version of this RPP, visit www.mtec-sc.org/solicitations/.

Frederick ,
 MD   USALocation

Place Of Performance : N/A

Country : United StatesState : MarylandCity : Frederick

Office Address : 808 SCHREIDER ST FORT DETRICK , MD 21702 USA

Country : United StatesState : MarylandCity : Frederick

Classification

naicsCode 541715Research and Development in the Physical, Engineering, and Life Sciences (except Nanotechnology and Biotechnology)
pscCode AN43Health R&D Services; Health Care - Other; Experimental Development