System and method for rapid assessment for pre-hospital triage evacuation and intervention using multimodal artificial intelligence

Abstract

A automated triage suggestion can be generated in an ambulance. The system can include an ambulance; an electrocardiogram (EKG) device; a photoplethysmography (PPG) device; and a computing device configured to be removably installed in the ambulance and comprising a display-screen, at least one processor, and memory, the computing device configured to: receive, from the EKG device, the EKG datastream; receive, from the PPG device, the PPG datastream; collect a threshold amount of triage data from the EKG-data points and the PPG-data points for the patient; generate, responsive to collecting the threshold amount of triage data, a triage message on a display-screen using the triage data with an artificial-intelligence model, the triage message comprising a color-coded element and a text element, wherein: the color-coded element is colorable to indicate an urgency value of the triage message; and the text element is displayable to indicate a triage-action suggested to apply.

Description

SYSTEM AND METHOD FOR RAPID ASSESSMENT FOR PRE-HOSPITAL TRIAGE EVACUATION AND INTERVENTION USING MULTIMODAL ARTIFICIAL INTELLIGENCECLAIM OF PRIORITY

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial Nos. 63 / 556,314, filed on February 21, 2024 and 63 / 688,081, filed on August 28, 2024, the entire contents of which are incorporated herein by reference in their entirety.TECHNICAL FIELD

[0002] This document describes computational processes such as artificial intelligence to identify when a subject should receive a lifesaving intervention (LSI) including subjects in a vehicle with limited data connections to outside data sources.BACKGROUND

[0003] Rapid transport of patients from under-resourced environments to the highest level of care is a cornerstone of modem trauma care. Delays in definitive trauma care is a well -documented cause of mortality. When access to definitive care is delayed, early recognition and prompt administration of life saving interventions (LSI) - time-sensitive treatments that define immediate triage needs - at the point of injury can save lives and enhance patient outcomes.SUMMARY

[0004] One challenge in emergency medicine lies in emergency decision-making and triage, which occur in dynamic, resource-constrained environments. Existing triage approaches to predict the impact of LSIs or immediate transfer to trauma and surgical care can be considered inadequate. The poor performance of the existing triage approaches can be associated with reliance on minimal objective data (vital signs) and subjective data (anatomic injuries in the absence of diagnostic modalities) that fail to identify patients that require immediate evacuation and LSIs reliably and rapidly resulting in delays in interventions and transfers. Pre-hospital care settings can benefit from this technology’s improved and automated triage solutions which can facilitate earlier, more accurate triage for life saving intervention and immediate transfer while also reducing the cognitive burden on the clinicians. Furthermore, these triage solutions can be dynamic, able to re-triage patients whose condition changes or when definitive care is further delayed.

[0005] Early recognition of the need for life saving interventions (LSIs) and rapid transfer to trauma and surgical care settings can be vital for improving some patient’s outcomes and reducing mortality. Pre-hospital clinical decision making and triage often happen in a fast-paced, cognitively saturated, and resource constrained environment. As a result, some existing triage approaches are inadequate, at risk of creating both over-triage which wastes precious resources and under-triage resulting in delayed recognition and interventions and potentially increase mortality. Pre-hospital interventions such as hemorrhage control, early administration of blood products and airway management often have the largest magnitude of impact, decreasing preventable deaths for severely injured patients.

[0006] The technology described in this document can incorporate robust multimodal clinical data, including detailed vital sign data and high-dimensional physiologic waveforms simultaneously, and can use multimodal artificial intelligence approaches to predict the need for life-saving interventions and trauma care. To meet the fast paced and resource-constrained environment of the prehospital settings, the technology offers a solution for automated continuous triage by the deployment of the triage algorithm using a short duration of data acquisition. This can include real-time integration of the technology with existing physiological monitoring devices and wearable biosensors, offering a complementary clinical decision tool (CDT). This technology can rapidly convey critical triage information and recommendations to the emergency medical clinicians in prehospital and austere or resource constrained settings.

[0007] In some aspects, the techniques described herein relate to a system for automated triage suggestion generation in an ambulance, the system including: an ambulance configured to receive a patient and transport the patient to a medical-care facility; an electrocardiogram (EKG) device configured to generate an EKG datastream for the patient, the EKG datastream including a plurality of EKG-data points; a photoplethysmography (PPG) device configured to generate a PPG datastream for the patient, the PPG datastream including a plurality of PPG-data points; a computing device configured to be removably installed in the ambulance and including a display-screen, at least one processor, and memory, the computing device configured to: receive, from the EKG device, the EKG datastream; receive, from the PPG device, the PPG datastream; collect a threshold amount of triage data from the EKG-data points and the PPG-data points for the patient; generate, responsive to collecting the threshold amount of triage data, a triage message on a display-screen using the triage data with anartificial -intelligence model, the triage message including a color-coded element and a text element, wherein: the color-coded element is colorable to indicate an urgency value of the triage message; and the text element is displayable to indicate a triage-action suggested to apply to the patient.

[0008] In some aspects, the techniques described herein relate to a triage device for automated triage suggestion generation, the triage device including at least one processor and memory, the triage device configured to: receive, from at least one electrocardiogram (EKG) device, an EKG datastream for a patient, the EKG datastream including a plurality of EKG- data points; receive, from at least one photoplethysmography (PPG) device, a PPG datastream for the patient, the PPG datastream including a plurality of PPG-data points; generate, using an artificial intelligence model and based on a threshold amount of data from a subset of the EKG data points and the PPG data points, a triage message configured to be presented on a display-screen, the triage message including a color-coded element and a text element, wherein: the color-coded element is configured to indicate a level of urgency associated with the triage message; and the text element is configured to indicate a suggested triage-action for the patient.

[0009] In some aspects, the techniques described herein relate to a triage device, wherein generating the triage message using the artificial intelligence model includes: generating a plurality of Heart Rate Variability (HRV) parameters for the patient, the HRV parameters having millisecond-scale granularity; and providing the HRV parameters with the artificialintelligence model.

[0010] In some aspects, the techniques described herein relate to a triage device, wherein the threshold amount includes a first number of EKG-data points, and a second number of PPG- data points, the first number being different than the second number.

[0011] In some aspects, the techniques descnbed herein relate to a triage device, wherein the threshold amount is associated with a time duration determined based at least on a first sampling rate of EKG-data points in the EKG datastream.

[0012] In some aspects, the techniques described herein relate to a triage device, wherein the duration is determined based also on a second sampling rate of PPG-data points in the PPG datastream.

[0013] In some aspects, the techniques described herein relate to a triage device, wherein the triage message is generated without using infonnation from Electronic Health Records (EHR) for the patient.

[0014] In some aspects, the techniques described herein relate to a triage device, wherein: the EKG device is aN lead EKG device; and the PPG device is a pulse oximeter.

[0015] In some aspects, the techniques described herein relate to a triage device, wherein the artificial intelligence model is trained using training data that includes: first records of trauma victims transported to medical-care facilities; second records of life-saving interventions provided to the trauma victims while being transported to the medical-care facilities; and third records of outcomes for the trauma victims.

[0016] In some aspects, the techniques described herein relate to a triage device, wherein the artificial intelligence model includes a plurality of classifiers arranged in a decision-tree ensemble.

[0017] In some aspects, the techniques described herein relate to a triage device, wherein the triage device is further configured to convert one or more risk scores from the artificial intelligence model into a color and the text element.

[0018] In some aspects, the techniques described herein relate to a triage device, further including one or more digital filters configured to remove artifacts caused by rotor noise of a helicopter.

[0019] In some aspects, the techniques described herein relate to a triage device, wherein the threshold amount of data includes data corresponding to interruptions caused by removing from the patient at least one of the EKG device or the PPG device.

[0020] In some aspects, the techniques described herein relate to a triage device, further including a transceiver configured to send a message over a data network to a computing device configured to provide status information to a medical-care facility7, the message including the triage message.

[0021] In some aspects, the techniques described herein relate to a method of automated triage for a patient, the method of automated triage including: receive, from at least one electrocardiogram (EKG) device, an EKG datastream for the patient, the EKG datastream including a plurality of EKG-data points; receive, from at least one photoplethysmography (PPG) device, a PPG datastream for the patient, the PPG datastream including a plurality of PPG-data points; generate, using an artificial intelligence model and based on a threshold amount of data from a subset of the EKG data points and the PPG data points, a triage message configured to be presented on a display-screen, the triage message including a color- coded element and a text element, wherein: the color-coded element is configured to indicatea level of urgency associated with the triage message; and the text element is configured to indicate a suggested triage-action for the patient.

[0022] In some aspects, the techniques described herein relate to a method, wherein the threshold amount includes a first number of EKG-data points, and a second number of PPG- data points, the first number being different than the second number.

[0023] In some aspects, the techniques described herein relate to a method, wherein: the threshold amount is associated with a time duration determined based at least on a first sampling rate of EKG-data points in the EKG datastream; and the duration is determined based also on a second sampling rate of PPG-data points in the PPG datastream.

[0024] In some aspects, the techniques described herein relate to a method, wherein the artificial intelligence model is trained using training data that includes: first records of trauma victims transported to medical-care facilities; second records of life-saving interventions provided to the trauma victims while being transported to the medical-care facilities; and third records of outcomes for the trauma victims.

[0025] In some aspects, the techniques described herein relate to a method, wherein the method further includes converting one or more risk scores from the artificial intelligence model into a color and the text element.

[0026] In some aspects, the techniques described herein relate to a method, wherein the method further includes sending a message over a data network to a computing device configured to provide status information to a medical-care facility ..

[0027] The devices, system, and techniques described herein may provide one or more of the following advantages. For example, the technology can be utilized to address challenges in tactical combat casualty triage. Advances in tactical combat casualty care continue to reduce mortality from combat injuries. Most potentially preventable deaths are related to hemorrhage or airway compromise in the prehospital setting. Up to a quarter of these may be preventable with early recognition and life-saving interventions (LSI) that may not be immediately available in tactical or austere environments. This technology' can operate independently or semi -independently of logistical, medical, and evacuation support capabilities due to a large, geographically dispersed, three-dimensional battlespace and area denial threats. In these environments, new' strategies for clearing the battlespace are provided herein. Military medics can use this technology' to rapidly assess multiple casualties and make critical decisions about triage, tactical evacuation and need for immediate LSI. They must do this w ith limited use of traditional diagnostic tools and allocate limited medical resources. In high threatenvironments, they may lack the ability to call in additional resources. Telemedicine may not be available due to communication limits or the potential of revealing the position of the wounded. The ability to evacuate casualties may be limited in capacity or delayed, particularly in near-peer operations where we lack air superiority making tactical evacuation potentially hazardous. There are finite resources to manage multiple casualties with an uncertain evacuation timeline and anticipated clinical course. Challenges include limited personnel to perform assessment and interventions and medical supplies. However, this technology can be used to overcome some or all these issues, including without manual input from a clinician.

[0028] Identifying patients who cannot tolerate prolonged field care but instead benefit from immediate evacuation is a beneficial feature of this technology for the battlefield medic and allow' them to optimize utilization of constrained medical resources and tactical evacuation assets. Triaging combat casualties w ith this technology can allow' for tactical evacuation to distinguish who should undergo immediate evacuation from those who can survive prolonged field care, which can be done by users with limited training, experience, or diagnostic resources. Once the casualties with the greatest need and / or priority are evacuated others can receive continuous re-evaluation and re-triage to monitor for changes in condition and future evacuation needs. Combat medics in most recent conflicts w ere accustomed to relatively short waits for resupply and evacuation of casualties with most achieving evacuation within 2 hours or less. In future conflicts medics may be responsible for wounded for days prior to evacuation opportunities, which can be aided by this technology. Similarly, civilian medics may not be able to reliably predict which patients will benefit from advanced medical resources or rapid transport afforded by air medical transport (AMT), but this technology can improve or overcome this shortcoming. This issue is compounded by a resource constrained setting where multiple casualties make timely allocation of limited medical interventions critical.

[0029] Incorporating high-dimensional physiologic waveform data into artificial intelligence algorithms is used by this technology to provide many benefits.. Obtaining these data from low size, weight and power (SWaP) wearable sensors is a particularly beneficial possibility with this technology for the battlefield and civilian mass casualty incidents. These small wearable devices weigh ounces and have footprints of just a few' inches as opposed to other medical monitors which are dedicated to a single patient and are the size of small appliances and weigh 10-15 lbs. Furthermore, several sensors of this technology can be wirelessly linkedto a common edge computer which can run the CDT tool and infonn a single provider caring for many patients. In addition, the technology can facilitate rapid, automated and simultaneous early triage or re-triage of multiple casualties independently or complementary to the triage by the medics which can be significantly valuable in active combat settings or other similar mass casualty scenarios where access to patients or resources are limited.

[0030] Under austere prehospital conditions in the civilian and military environment, the rapid triage of injured patients for intervention or transport can be essential. Classification for individual -level delivery of life saving interventions (LSI) and the operationalization of logistics may be hindered by limitations of human provider bandwidth and resource availability. This document describes an automated triage and intervention decision support system that can improve triage of traumatic injury. This technology’ can use artificial intelligence and can operate well in urban prehospital setting, and non-urban pre-hospital settings such as combat theaters, remote rural areas, disaster zones, etc.

[0031] This technology' is particularly suited for Future Multi-Domain Operations (MDO), which may require operating independent of logistical, medical, and evacuation support capabilities due to a large battle space without fixed forward medical assets. Area demal threats and a potential lack of air superiority as seen in some conflicts can necessitate evacuation of casualties over long distances, using vehicles of convenience and long delays while waiting for the cover of night, weather, or a combat escort. This example supports new strategies for clearing the battlespace in these contested environments. Military medics and warfighters (with minimal medical training) providing buddy aid may need to rapidly assess multiple casualties and make critical decisions about triage, tactical evacuation, and need for immediate LSI provided by this technology. In LSCO there may be more casualties than can be cared for by the existing medical infrastructure and soldiers with minimal medical training may need to save the lives of some and leave others with non-survivable injuries. With finite resources and limited ability to resupply, medics may need to manage multiple casualties with an uncertain evacuation timeline and an unknown clinical course. The ability’ to monitor casualties and predict deterioration before it occurs may be constrained by monitor size, weight, and dependency on skilled providers. Casualties that die in the prehospital environment may have benefited from early evacuation and frequently required LSI. Identifying patients who will not survive can also free resources for those who can be saved. Predicting those who need immediate LSIs and benefit from immediate evacuation is anadvantage of this technology for the battlefield medic and valuable to improve utilization of constrained medical resources and tactical evacuation assets.

[0032] Civilian medics also may need to make triage and treatment decisions with inadequate information. Trauma can be a time-sensitive condition: a few minutes’ delay to an LSI or definitive surgical management can mean the difference between life and death. Use of air medical transport (AMT) can be a critical decision for civilian medics, analogous to tactical evacuation. Up to a quarter of rural Americans can only reach a trauma center within an hour due to AMT. Medics must often determine whether patients require AMT or can tolerate ground transport and the associated delay to definitive care. In many instances, AMT increases survival after severe injury compared to ground transport. AMT can bring advanced LSI capabilities to the patient within minutes of injury (e.g., advanced airway, blood transfusion) that are not widely available from ground providers. AMT can also reduce time to trauma center arrival when LSI are not available in the prehospital setting (e.g. damage control surgery ). This technology can improve on triage, in part by predicting which patients will need early LSI or benefit from. Inappropriate triage to AMT without this technology can reduce the availability of these assets for patients who would otherwise benefit. AMT also comes with inherent risks of transport that can be mitigated through minimization of over-triage. Under-triage in rural settings may be 3.5 fold higher, but can be mitigated with accurate triage to AMT, and the use of this technology can provide operational feedback to initiate the AMT when it would be beneficial.

[0033] The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features, aspects and potential advantages will be apparent from the accompanying description and figures.DESCRIPTION OF DRAWINGS

[0034] FIG. 1 shows an example system for the collection of patient data and the generation of triage recommendations.

[0035] FIG. 2 shows an example of computational hardware for the collection of patient data and the generation of triage recommendations.

[0036] FIG. 3 shows a schematic diagram of an example data pipeline for patient triage.

[0037] FIG. 4 shows a flowchart of an example process for generating triage messages.

[0038] FIG. 5 shows a graphic user interface (GUI) with a triage message.

[0039] FIG. 6 shows a GUI with triage data including a plurality7of triage messages.

[0040] FIG. 7 shows a swimlane diagram of an example process for providing triage messages.

[0041] FIG. 8 is a schematic diagram that shows an example of a computing device and a mobile computing device.

[0042] FIG. 9 is example data of an example implementation.

[0043] FIG. 10 is example data of an example implementation.

[0044] Like reference symbols in the various drawings indicate like elements.DETAILED DESCRIPTION

[0045] This document describes technology that uses artificial intelligence models for patient triage. Areal-time predictive risk monitoring and alerting system can be provided for prehospital care settings, in order to facilitate improved triage, prioritization of evacuation, and earlier / proactive identification of the need for life saving interventions (LSI). LSI can include time-sensitive interventions that define immediate triage needs. The provision of LSI recommendations from this technology7, at the point of injury7, can save lives and enhance patient outcomes.

[0046] FIG. 1 shows an example system 100 for the collection of patient data and the generation of triage recommendations with a monitor engine 108. System 100 can include hardware devices and data created and moving through the system 100.

[0047] A data relation module 110 can operate to collect data for storage in a data storage module 112. A predictive analytics engine 114 can operate to clean, preprocess, and applying artificial -intelligence based risk models to the data. UI engine 118 and alert recommendation engine 120 can operate to generate user interfaces 122-126 and alerts and / or recommendations.

[0048] In various examples, the user interfaces 122-126 can be available either as embedded interfaces (e.g., into existing emergency medical technician (EMT) software), as a standalone software on the same hardware or on a separate hardware (tablet), or in other configurations. Prompts generated by the alert recommendation engine 120 can be visualized on the patient dashboards in the user interfaces 122-124 and / or communicated through a speaker or other devices applicable in the environment for communication of audible information 126 audibly.

[0049] The system 100 can involve real-time integration with multiple sources of patient information, such as various vital sign monitors or biosensor wearable patches 102-106. For example, vital sign monitors 102-106 can include an TV lead EKG, device (12 lead, 5 lead, 1 lead, etc.,) or any such device that provides a wavefonn signal representing measurements ofheart activity and a pulse oximeter (PPG), or any device that provides a waveform signal representing measurements of vascular blood volume, flow or variations of said measures. The device may be of varying configuration or properties including different signal frequency. This data can be used by the predictive analytics engine 114 that utilizes pretrained artificial intelligence models for prediction of risk of future LSIs. The data relation module 110 can synchronize data, ignore artifacts, and produce a coherent input for the analytic engine. The system improves upon many existing approaches by: (1) providing a more accurate triage solution (2) expediting the evacuation and better allocation of patients to the right level of care and, (3) providing predictive risk of the need for both LSIs in general and the particular LSI types needed, which can reduce the time to intervention and thus improving patient outcomes. (4) real-time, automated and dynamic assessment of risk and communication of information to medics through both visual and audible mechanisms. These improvements can be due, at least in part, to real-time processing of multimodal patient clinical signal data. While various implementations can use various ty pes of input data (e.g., patient demographics, anatomical injury patterns, detailed vital sign data, and highdimensional physiologic waveforms), the technology is capable of working from very limited types of data For example, implementations of the technology can function using only electrocardiogram (EKG) and photoplethysmography (PPG) device. In addition, the technology’s analytics engine is superior to many other monitoring systems in pre-hospital and hospital settings due, at least in part, to its capability of analyzing raw high dimensional waveforms such as ECG and PPG and adoption of a multi-layer artificial intelligence architecture to provide more accurate and earlier risk identification.

[0050] In some implementations, the technology uses raw signal or waveform from just two patient parameters (e.g., cardiac activity and blood volume) and produces triage suggestions using only a limited amount of data (e.g., based on collecting the patient parameters for 2 minutes or less, in some cases). In some implementations, the technology does not require the signals to be synchronized. In some implementations, the data can come from different devices. These can include small wearable biosensor patches that collect two signals (e.g. EKG and PPG) jointly or separately. Other vital signs (e.g., blood pressure) may not be needed to produce high-quality results. This can be particularly important in pre-hospital settings (e.g., in an ambulance or an air-ambulance) where data collection capabilities and / or time is significantly limited. The technology described herein can also result in significant efficiency in emergency settings (e.g., at an accident scene with multiple injured victims)where several triage decisions need to be taken as quickly as possible, potentially with limited resources. The ability to generate accurate and actionable triage decisions efficiently with only limited amount of data from a small number of modalities and limited computational resources (such as that available in an ambulance or air ambulance) presents a stark contrast to systems in hospital settings that have a plethora of data of different modalities available for making triage decisions. In addition, the technology described herein can contribute to reductions in dependency on manual data input which can provide substantial usability value in pre-hospital settings. Other relevant differences between prehospital settings and ED care settings that make this problem substantially more difficult can include the significantly shorter periods of care, lack of historical patient data, and dynamic nature of patients with critical conditions. These differences can result in additional technical challenges related to data availability. For example, the artificial intelligence models need to provide robust triage and recommendation based on substantially smaller amount of data to ensure operationalizability. Other challenges can include possible higher data missingness, faster and more dynamic changes in patient conditions with multiple critical complication episodes, limited real time clinical data and absence of access to patient history due to low resource, rapidly evolving and often chaotic nature of pre-hospital care settings.

[0051] This technology7can produce a triage message with more than one part for display in a user interface 122-126. For example, an urgency value can be provided to indicate need for a particular type of LSIs, or an overall need of one or more multiple LSIs. This urgency value can be used to facilitate general risk assessment and triage of patient’s severity. The triage message can also or alternatively provide a text element related to specific types of LSIs, or relevant patient outcomes related to the LSIs. The text element can be related to, but is not limited to, a need for blood product transfusion, vaso-active medications, occlusive chest seals, needle thoracostomy, amputation, tourniquet, tube thoracostomy, advanced airway devices or use of ventilators (general or specific types of ventilators), craniotomy, cardiopulmonary' resuscitation (CPR), resuscitative endovascular balloon occlusion of the aorta (REBOA), or mortality. The LSI can be based on prioritizing short-term care needs, over long-tenn care needs (e.g., hours instead of days). For example, while a 72-hour window may better indicate patient outcomes, it may not be as useful an indicator of short term interventions and escalation of care. Limiting the prediction window to minutes or hours can allow some implementations of the model to better capture and identify patterns in the waveforms. For example, using a short window can facilitate better triage, better captureof paterns and signals in the waveform data and provide more suitable results for needs and challenges of pre-hospital setings. The short windows also can allow for re-triage, evaluating the need for new LSI and reclassification of triage priorities even after an initial LSI is administered.

[0052] These triage messages, displayed to a user on a display screen 122-124, can allow early awareness of the need for resources to support triage decisions about the patient destination, need for additional field resources (e.g., need for blood that would exceed what is available to the clinician), and priority among multiple patients in multiple casualty incidents. In the event that the patient's injuries are not survivable, it can assist the medic in preventing the commitment of precious resources and puting other patients at risk due to lack of resources. In addition, it can facilitate proactive preparation of medical logistic needs (e.g. therapeutic resources such as blood, durable equipment such as a ventilator, clinical expertise from a specialist, and fixed resources such as an operating room, etc.) at the destination facilitated by predictive anticipation of patient LSI needs. The logistic requirements can be communicated by the device in an automated way when remote network connectivi ty is available or can be communicated by the medics team, enabling faster interventions and beter patient outcomes by maximizing site preparation, logistical preparation, resource deployment, and scheduling.

[0053] Datastreams used by the system can be processed for use in real-time production of a unified, time-synchronized data construct. That is to say, the datastreams can be stored in the data storage module 112 timestamped and adjusted so that data points in the various datastreams with matching timestamps represent readings taken from the patient at the same time or within a small window (e.g., 10 ms, 15 ms). The datastreams may be stored by the data storage module 112 in, for example, either or both of volatile and non-volatile storage. For example, a relational database, in which the patient’s status, physiologic datastreams, and previous and on-going procedures are stored in separate tables related by a common record identifier and other relational rules. Alternatively, the data can also be stored in other types of datastores, such as those that use key-value storage systems, object storage systems, etc. The stored data construct may similarly include a compound "container” data structure such as a MATLAB struct, a Hierarchical Data Format (e.g., HDF5), or European Data Format (EDF). In some examples, the stored data construct may take the form of a single rectangularized ‘flat’ table (e.g., in which all missing values are filled in to rectangularize the table). Various approach may have advantages and disadvantages, depending on the implementation case.Production of the data construct can be handled by a data relation module 110, which can use, for example, predetermined rules and template schemas to organize the data. The data storage construct can be periodically updated by appending additional patient data in realtime in mutable storage systems (e.g., relational databases) and / or by recreating and replacing a new copy / version of the stored data construct in non-mutable storage systems or where appending new data is not efficient.

[0054] For example, in one implementation, the system 100 data sources can include i) a prehospital-patient monitor that can gather ECG, PPG, and BP datastreams recorded at 500Hz; ii) a wearable monitoring patch gathering Near Infrared Spectroscopy estimated Tissue Oxygen Saturation and EEG recorded at 100Hz; and iii) an electronic medical record populated manually by a paramedic as needed during care. In another implementation, the system 100 data sources may be more constrained as only an EKG device 104 and a PPG device 106, for example. The data storage module 112 can store this data in a flat table. In this case the data relation module 110 can identify the data sources, their data types and sample rates, and then associates them via predetermined relational rules for appropriately resampling and synchronizing. This can be used to produce a rectangular data structure incorporating data from all available data sources. In this example, the preset rules involve downsampling data from the monitor to match the sample rate of the lowest-frequency device, and also creating a sparse columnar representation of events captured in the input data.

[0055] The monitoring engine can execute, for example, on a standalone computer system or other technologically appropriate hardware. Various types of computers can be used to execute a monitor engine 108. These computers can include, but are not limited to, standard workstation computers, portable personal computers (laptop or notebook), single board computers (SBC) such as Raspberry Pi, wearable computers, tablets, smart phones etc. Many of these devices can natively provide integration ports and wireless communication modules, or adapting hardware and software can be used. The computer system can also include an internal speaker module, provide a standard port for w ired connection to a speaker module, and / or support wireless connection to a wireless speaker module.

[0056] The monitor engine 108 can include various operations modules: the data relation module 110, the predictive analytics engine 114, the UI engine 118, and the alert recommendation engine 120. These modules can be implemented, for example, as software, hardware, firmware, or another appropriate structure.

[0057] The data relation module 110 can collect various datastreams from multiple input sources. The data relation module 110 can store the data in memory, such as non-volatile storage systems. The collection of the data from the integrated devices can be done, for example using standard network / web protocols ( i.e., HTTP, SOAP, REST, etc.) or device specific software development kits (SDK) and software.

[0058] The predictive analytics engine 114 can use the collected datastreams to process patient's data and provide dynamic triage messages. These triage messages can include, for example, risk assessment for future need of any said LSIs or specific types of LSI. The predictive analytics engine can store the triage messages in memory, for example in a nonvolatile storage system. A patient’s risk of future need of an LSIs can be represented as a numerical format such as probability or ordinal value. For example, a probability can be presented as a value from 0 to 1 inclusive, a percentage, etc. An ordinal can be a numerical value in a range (e.g., 1-4), texts labels from a schema of ordered text labels (e.g., ‘’Low,” “Medium,’' “High,”). Persistence of the risk score after the intervention may be used to evaluate the effectiveness of the intervention. Should the intervention not improve the underlying physiology then a continued alert may prompt the clinician to for example administer more blood or repeat a thoracic decompression. The patient’s risk of LSIs can be computed by directly analyzing high-dimensional vital signal waveforms (ECG, PPG, etc.) and / or other patient data using multi-layer artificial intelligence models, which have been trained previously using past patient data. A dynamic risk assessment can be computed by applying the machine learning models periodically (i.e., every' N minute or seconds such as every’ 10 seconds, every 1 minute). Consecutive risk scores calculated at each cycle can be stored by the risk score storage module 116 in memory’, for example, in anon-volatile storage software (i.e., database software) and made available, for example, via an Application Programming Interface (API).

[0059] The predictive analytics engine 114 can perform one or more processes for identifying a risk of future need for LSIs. This process can include steps such as retrieving and reviewing various modalities of patient clinical-data from the storage system included in the data storage module 112. The data can include datastreams representing one or more waveform signal (e.g., ECG, PPG) and / or non-waveform input data. The non-waveform input data can include, but is not limited to, patient demographics, anatomic injuries information, etc., for example that have been keyed into the system 100 by a medic or EMT. The data waveform signals can be retrieved for a predetennined period of time (e.g., for nolonger than when the device was configured for the current patient, which can ensure all the data being analyzed is from the same patient). The data can undergo multiple analytics and machine learning steps. For example, the input data can be cleaned and preprocessed by the data relation module 110. The cleaning and preprocessing steps can include, but are not limited to, unit conversion, error removal, outlier value removal, waveform filtering(i.e., low pass filter), and value imputation. The predictive analytics engine 114 can include a predictive module that extracts features and / or derived parameters and feature embedding representations from the input data and uses pretrained artificial intelligence models that analyze the cleaned input data, for example, to generate the triage messages described in this document.

[0060] The operations of the artificial intelligence model can include two steps, performed either separately as two independent processes or simultaneously as part of the same process. A feature-representation learning-layer can obtain a dense or sparse representation of received data (e.g., datastreams from various devices). The input data may be collected from the input data and processed to encode temporal and non-temporal patterns into one vector representation. A prediction layer can analyze the feature vector to generate a triage message. This triage message can include a plurality of elements, which can include but is not limited to a color-coded element that is colorable to indicate an urgency value of the triage message. This triage message can include a plurality of elements, which can include but is not limited to a text element that is displayable to indicate a triage-action suggested to apply to the patient. As will be appreciated, the triage-action can include LSI’s. In some implementations, the triage-action can include actions to perform that are not LSI’s, such as diagnostic information about the hardware, non-lifesaving interventions that can comfort the patient without being life-saving, etc.

[0061] The vector representation can be obtained using one or more techniques. These techniques can include, but are not limited to, template techniques, automated feature learning approaches, other techniques, and / or by combining these or other techniques. Feature template techniques can use a window based mechanism to summarize the available data in that window into one single feature value. This can include, but is not limited to, statistical methods such as average, median, trends, first value, last value, peak, autocorrelation, power, area under curve, energy, slope, kurtosis, empirical cumulative distribution function (ECDF), ECDF slope, total time, histogram, entropy, max power spectrum, frequency, negative turning, power bandwidth, positive turning points, skewnessmethods, root mean square of signal, spectral analysis, wavelet absolute mean, wavelet energy, wavelet entropy, wavelet standard deviation, wavelet variance, or any other such techniques, formula or algorithms configured to extract a specific information, pattern or parameter from the signal etc. At least some of the statistical template features can be computed directly from the raw datastreams. At least some of the statistical template features can be generated from a secondary, lower frequency, signal derived from the raw datastreams. Derived signals can include but are not limited to, R-R internal, R amplitudes, R wave peaks, Signal Quality Index from each ECG beat, Heart Rate Variability (HRV) Features over a sliding window from ECG and Signal Quality Index, amplitudes, acceleration, slope, energy and pleth variability index from PPG beat. The system can perform a secondary level of feature extraction. For example, the system can reapply statistical processes over a first layer of feature by using a sliding window across the input datastreams and calculating a primary template-based feature for each sliding window. The system can generate the feature vector by concatenating, for example, primary -template based features and / or the secondary level features of sliding windows into one dense vector. The system can use various lower dimension techniques including, but not limited to, principal component analysis, matrix factorization, discriminant analysis, feature selection. The system can use elimination techniques to generate another version of the feature vector which may be smaller or otherwise more easily analyzed. The system can generate the feature vector using various automated feature-representation learning techniques. These feature-representation operations can include one or multiple neural network layers to summarize the raw data. The summary can include data representing predictable feature-representation vectors. The feature-representation vectors can include, but are not limited to, recurrent neural network layers, convolutional neural network methods, attention layers, transformer layers, fully connected layers, pooling layers, normalization layers, activation layers, feedforward neural networks, and autoencoders.

[0062] The system, in the prediction process, can use one or more artificial intelligence techniques that analyze the vector representation to generate a triage message. This triage message can represent a patient’s risk of needing a future LSIs. This need can be, in various implementations, a fixed in the future window. The future window can be defined from the current time, after admission to a hospital, for the entirety7of patient hospitalization, or other appropriate scheme. The prediction layer can use various artificial intelligence operations such as regression models, support vector machines, Bayesian models, decision tree-basedmodels, clustering techniques, nearest neighbor methods, and neural network approaches. When the system uses multiple machine learning techniques, various ensemble schemes can be adopted to combine such outputs into a single triage message. Ensemble approaches may include, but not limited to, bagging, voting, boosting, tree-based ensembles, decision-tree ensembles, and neural network based ensembles. To output the final triage message, separate artificial intelligence models can be adopted for each element of the triage message. To output the final triage message, a single multi-label artificial intelligence model can be utilized that outputs all elements of the triage message together.

[0063] The UI engine 118 can monitor the data generated by the predictive analytics engine 114, and can render and display the triage message to a patient’s risk dashboard. The risk dashboard can be displayed on a standalone display 122. The risk dashboard can be integrated with other electronic health software interfaces 124 for example on an application on a phone or computer that serves many other functions in addition to triage-messaging. The patient risk dashboard can include a patient risk panel that provides risk scores or risk stratifications. This interface can be configured to have simple and unambiguous interpretation by a human reader even if the reader does not have sophisticated medical training. The interface can be configured to modulate colors of elements based on risk categories. As such, the risk dashboard can support clear decision-support statements. The risk dashboard can include an output of one or more text elements. The text elements can include recommended triage-actions generated and stored by the alert and recommendation module. The risk dashboard can include a detailed risk-view panel that can include dynamic risk values for various particular LSI or outcome over time. In an example, the detailed risk panel can be activated by clicking on a particular risk score and can be deactivated by reclicking on the activated risk score. The detailed risk panel can include display of predicted risk scores for the selected risk outcome over time alongside related recommended actions to the specific outcome if available. The UI engine can display color coding. In various examples, the color palette can be configured according to the risk stratification groups, (i.e., high: red, medium: yellow, low: green, black for expectant / non-survivable or standard screen color).

[0064] The alert recommendation engine 120 can display triage-messages and raw clinical data. The alert and recommendation module can generate alerts and recommendations - sometimes referred to as prompts - for a user. The prompts can be triggered according to a set of pre-determined rules stored in memory. When data stored in memory' matches one ormore of the conditions stored in the pre-determined rules, the prompt may be generated, displayed, etc. The rules can be defined by the users. For example, a user can define conditions based on values, and changes in value, of triage data or triage messages. The rules can be stored in the module. The module also allows users to edit the rules to delete, update or add new rules. The edits can be made by the system before, during, or after patient monitoring with the system has begun. These rules can include conditions based on, for example, a state of available resources, threats, or probability of evacuation. Said another way, these rules can be adjusted by the user to reflect the conditions of the environment in which the triage is occurring. In a more dangerous environment, the user can adjust the rules to be more likely to indicate evacuation, for example. A predicted triage score can include the need for escalation of care, which indicates what kind of hospital or center a patient should go to, etc. A predicted triage score can include the need for escalation of care, which indicates what kind of hospital or center a patient should go to, etc.

[0065] These features can support a clinician making appropriate decisions, or make such decisions earlier or proactively. The clinician may be more inclined to administer blood for a given probability of need if local supply is adequate or evacuation is likely. Thus the system 100 can be configured to support this inclination. Conversely if supplies are critically low and resupply is not likely, the clinician may transfuse at a higher risk threshold, and thus the system can be configured to support this inclination. The alert recommendation engine 120 can use communications such as APIs provided by the UI engine 118 to generate outputs on the patient risk dashboard. In addition, the alert recommendation engine 120 can generate an output for the users (e.g., EMT team) regarding the presence of a new prompt. For example, the system can play a sound (e.g., a beep) or by playing an audio speech related to the prompt (e.g., explaining the text element of a triage message) on the speaker 126. Audio output can facilitate non-visual communication in high threat environments.

[0066] FIG. 2 shows an example of computational hardware 200 for the collection of patient data and the generation of triage recommendations. For example, the computational hardware 200 can include various hardware modules (e.g., EKG device 104, PPG device, computing device 202. display device 214, software device 216, and / or speaker 126) involved in ambulance and helicopter deployment of the system 100. Elements of the computational hardware 200 can be connected via wired or wireless connections 204-212. For example, the computing device 202 can be removably installed in the ambulance and comprise a di splay -screen, at least one processor, and memory.

[0067] This technology can use vital sign monitors 102-106 by a computing device 202 or system of devices. The computing device 202 can include, for example, one or more processors and memory. The vital sign monitors 102-106 can generate datastreams that include, but are not limited to, datastreams for an EKG device 104, PPG device 106, electroencephalogram (EEG), respirator}7rate monitor, ventilator, End-tidal carbon dioxide (ETCO2), temperature, blood pressure (invasive or non-invasive), heart rate etc. With these and / or other collected datastreams, the data relation module 110 can generate other generated parameters that can include, but are not limited to, heart rate variability parameters, pulse pressure variation, or stroke volume variation to name a few. Vital sign monitors 102-104 may involve separate or standalone devices. In some situations in which multiple vital sign monitors are incorporated into one device 102, integration with the device can provide multiple vital sign data. However, in limited device environments such as an ambulance (helicopter ambulance, road ambulance, etc.) this technology can operate with very7few inputs and no data connection to outside servers. For example, with only an EKG device 104 and PPG device 106 (and no data connection to a remote server, no other data source such as blood-pressure cuffs or the like), this technology' is able to operate to produce a triage message in as little as two minutes, in an implementation.

[0068] Integration can take place using wired and / or wireless connections 204-212. When wired integration is used, for example, the connections can be established using either a standard port, or an appropriate extension for converting a monitor device’s non-standard port to a standard port such as USB and ethemet. Wireless integration can be done through, for example, standard wireless signals such as Bluetooth (i.e., Bluetooth 5.3) and wireless network protocols (Wi-Fi IEEE 802.11), for example through a central wireless Wi-Fi router. In various cases, datastreams may be transmitted as digital or analog data streams, the latter being transduced to digital format after receipt by various elements of the system. In combat field environments, the system can be robust enough to function with intermittent, low' bandwidth, or total loss of wireless technologies as these resources may be constrained by the vehicle (helicopter, ground ambulance), environment (no Wi-Fi signal) or combat threat (possibility of detection). Similarly, some civilian ambulances and medical helicopters have Wi-Fi systems they are still constrained by bandwidth and available networks. In the case of mass casualty' events or disasters, the networks may be unavailable, unreliable, or jammed with traffic. In military7environments casualties are often evacuated by vehicles of convenience (CASEVAC) which may not have advanced communications systems.Therefore, this technology can be configured to operate in these field or ambulance conditions, for example by being operable with only datastreams from local devices (an EKG device 104 and a PPG device 106, for example) without the need to communicate with a remote server or data source.

[0069] FIG. 3 shows a schematic diagram of an example data pipeline 300 for patient triage. For example, the data pipeline 300 can be used to facilitate an overall clinical workflow and decision-making process when the system 100 is used, for example, inside an ambulance 310 (helicopter ambulance, road ambulance, or other vehicle). Real-time patient data sources 302 can include, but are not limited to, datastreams from the vital sign monitors 102-106. These patient data sources 302 can be analyzed with artificial intelligence model 304 such as in the predictive analytics engine 114.

[0070] The artificial intelligence model 304 can include relationship information generated from training data of historic medical incidents, for use in triaging new patients not included in the training data. For example, the training data can include first records of trauma victims transported to medical-care facilities, for example by ambulance. For example, the training data can include second records of life-saving interventions provided to those same trauma victims while being transported to the medical-care facilities. For example, the training data can include third records of outcomes for those same trauma victims. Deep learning features can directly learn from the raw high-frequency signal, which can be valuable because engineering features can use domain expert-based features that can summarize the characteristics of the signal. By avoiding engineering of features in some implementations, the system (1) can avoid on loss of details related to more subtle changes in the waveforms, (2) deep learning features can learn to become more robust to noise and artifacts since the model can be guided to directly learn to detect these behaviors and differentiate reliable and predictive segments, or information.

[0071] Learning directly from waveforms can occur in three steps. For example, steps 2 and 3 can be applied in an end-to-end fashion to allow the model to learn patterns related to the prediction of the target outcome, while step 1 can be executed and used as part of the end-to- end mechanism or independently. In an example step 1, convert the signal to time-domain view (use signal as is) and / or frequency-domain view by applying an algorithm or technique including, but not limited to, Fourier analysis and spectral analysis or other methods that can break down a signal to its underlying frequency components and the amplitude of those frequency components. In an example step 2, use one temporal feature learning componentthat compromises one or multiple layers of architecture layers that can be trained to identify specific or a series of related local patterns (whether used serially, in parallel, or a combination of) to extract multi-layer temporal features (patterns) at each timestamp based on the available data at that timestamp, before or even after (in case of past timestamps) the end-to-end learning of these features. Such layers can include convolutional layers, embedding learning layers, and even a combination of those with recurrent layers. In an example step 3, an end-to-end deep learning model component capable of learning to obtain a temporal summarization of the temporal features extracted from the final layer of Step 2 or the concatenation of such multiple final layers. The temporal summarization component can utilize model architectures that can leam to summarize the output of Step 2 by learning to create the feature summary by doing any of the functions, including (1) learning the importance of individual features, the importance or usefulness of timestamps of sampling times which can utilize one or combination of DL layers types such as recurrent neural network (RNN), single or multi-head attention, transformer architectures, pooling layers, or other embodiment of neural network layers designed to perform such functions.Independence can be achievable by driving complex multi-layer and non-linear features using ECG and PPG data. Instead of extracting blood pressure from those signals; the technology can extract complex features to assess patients’ conditions without reliance on blood pressure data. The technology can use statistical functions (average, median, etc.) to summarize feature calculations over time for the engineering features. The technology can allow the use of temporal layers that take in the engineering features, the moving average (or other similar techniques) of summarization of the engineering features over time, and deep learning features extracted to allow the model to leam what to use and what is more important across time. Instead of feeding one set or an overall summary’ of one or a combination of different features. Various machine learning model, including logistic regression, SVM, a linear deep neural network layer, decision trees, random forest, and any’ Bayesian method, can be used. The technology’ can use sampling techniques to improve an imbalance problem. The technology can use a modality fusion mechanism that can combine the features at the end by, for example, concatenating them. Fusing modalities can be used in between the samples allowing the model to leam from correlated information embedded inside each modality and how it correlates and relates to other modalities at that time.

[0072] The artificial intelligence model 304 can use an optimization step to make the artificial intelligence model 304 suitable for deployment in low-power, low-resource, andedge-friendly hardware devices. This can include use of an algorithm that optimizes the artificial intelligence model 304 (e.g., feature generation layers) by applying one or multiple of these steps: (1) model architecture, (2) parameters, (3) use a variable, (4) assembly, and device code conversation to make the model suitable for high-performance execution on low and limited computation devices (FPGA, edge Al accelerators, etc.). In highly low-resource settings, where the storage of complete signal data is infeasible, the artificial intelligence module 304 can use a data partitioning embodiment such as a sliding window, data stream bugger, or other data or similar techniques only to keep the required data.

[0073] The pipeline 300 can track model performance in a periodic way. For example, the pipeline 300 can rely on spontaneous communication and physical memory or data storage to collect the data, model performance data, outcomes, predictions, and operational and quality data in a compressed way. The pipeline 300 can asynchronously and periodically check connection availability and send the data to a remote performance monitoring system. The data can be transmitted in one or multiple attempts depending on signal quality and duration of connection availability. The remote system can process edge device perfonnance data byconsidering environmental (weather, locational, etc.) variables, patient outcome information and cross-reference with model performance and behavior data. The pipeline 300 can use outlier detection techniques to evaluate if the system has performed as expected. Performance data or device status monitoring can be communicated to the edge device during the same connection. Communications can rely on various embodiments of wireless data networks such as Wi-Fi networks, cellular networks (5G, 4G, etc.), satellite networks (e g., Starlink®), or any other technology that can facilitate wireless internet connection in remote or urban areas.

[0074] When direct communication by a device is not possible or is considered to be rare (e.g., tactical environments), but the local connection with a regional center is available, the device can communicate the data to the local center (communication hub). The communication hub can be equipped with local computation power to conduct performance monitoring and outlier detection. Alternatively, the device can perform the same periodic connection checks to communicate with a cloud-based server during periods that connection can be established.

[0075] The device can request either from the central serv er (on the cloud or other central network systems) or the local hub to periodically check if any instructions (including software updates, fixes, or even instructions for device malfunction and out of order) areavailable and can display or apply the instructions periodically. To achieve data integrity, security, and authenticity, communications can be encrypted and validated using appropriate encryption and data integrity techniques such as use of data encryption, parity checks, publicprivate keys, etc.

[0076] A series of techniques can be adopted and applied during pre-processing, as part of model training, or as a post-processing step to facilitate artificial intelligence model robustness and reliability. A wide range of data sampling-based techniques, such as undersampling, oversampling, or balancing methods, can be utilized to facilitate learning from imbalanced data. For example, the Synthetic Minority Oversampling Technique (SMOTE) algorithm can be used prior to model training. Other techniques for addressing the data imbalance in target LSI can be incorporating cost-based learning mechanisms in the optimization function utilized during the training process. Other sampling techniques may be used to consider the imbalance ratio of various LSI types and the cross-LSI and inter-LSI correlation to address the imbalance ratio problem. Model robustness can also be improved using various data augmentation techniques that may leverage various approaches for creating synthetic data from real data, including but not limited to adding data missingness, noise, and data segmentation can be utilized. Artificial intelligence model algorithms can also be adapted to leam from data missingness as a functionality by incorporating information in input data during using feature augmentation or data encoding of missingness during preprocessing steps or adapting the algorithm parameter learning mechanism to facilitate learning from missing during training by changing incorporating loss missingness as an optimization goal in the loss function. Artificial intelligence models can also be trained as one model for all LSI types, separate independent models or by imposing relationships between separate models one can facilitate training on robust models in multi-task settings. Similar goals can also be achieved by imposing cross-LSI relationships during the training of a single model through a cost mechanism as part of the optimization function. Other techniques that can be used is using pre-training steps, that involve training the model or parts of the models on separate, related or considerably unrelated problems followed with a model finetuning steps that leverage methodologies including but not limited to retraining of all or some layers, parameter adaptation.

[0077] Proactive risks of LSIs can be identified and scored 306 to be provided to notify an EMT team 308 or other user. Then, the user can communicate (e.g., over radio, wireless data connection) with destination medical-care facilities 310 and / or the user can instruct anotherperson (e.g., another EMT 312) to administer an LSI or other action. As such, the data pipeline 300 can be used, for example, by an EMT team in an ambulance to both provide LSIs to the patient in the ambulance, and to communicate to a destination medical-care facility to prepare for reception of the patient.

[0078] FIG. 4 shows a flowchart of an example process 400 for generating triage messages on prem. For example, the process 400 can generate prompts according to predefined rules. Rules will be activated if required conditions are enabled. Conditions can include risk based and / or patient condition based conditions.

[0079] If prompt rules are activated 402, if a triage message is generated with an urgency value above an urgency threshold, or if a new triage message is generated, prompt rules stored by the alert recommendation engine 120 can trigger. The alert recommendation engine can assemble or access a triage message that includes a color-coded element and a text element, where the color-coded element is colorable to indicate an urgency value of the triage message; and the text element is display able to indicate a triage-action suggested to apply to the patient. As will be appreciated, the triage-action may be an LSI, or a non-LSI action such as alerting a medical-care facility, providing an intervention that may not be lifesaving (e.g., providing comfort for a patient in pain, administering a non-lifesaving but clinically indicated medication).

[0080] If a screen is available 404, the prompt can be displayed 406 visually. For example, the alert recommendation engine 120 can display the prompt on a standalone display 122 and / or other electronic health software interface 124. The display can color the color-coded element to indicate an urgency value of the triage message. The display can render the text element of the triage-action for visual reading. Examples of displays are shown in FIG. 5 and FIG. 6.

[0081] the prompt can be played 410 to announce the prompt audibly, for example if a speaker or other hardw are for audible communication is available such as a headset. For example, the speaker 126 can be engaged to audibly recite the color of the color-coded element to indicate an urgency value of the triage message. The speaker 126 can be engaged to produce and audio recording or synthesis of the text element of the triage-action for auditory reception.

[0082] FIG. 5 shows a graphic user interface (GUI) 500 with a triage message that can be displayed, for example, on the standalone display 122.

[0083] The GUI 500 can include a triage display 502 to show a triage message. The triage display 502 can color the triage display 502 to indicate an urgency value of the triage message. The triage display 502 can render the text element of the triage-action representing at least one recommended interventions or decisions for visual reading for visual reading.

[0084] The GUI 500 can include visualization elements 506, 508, 509 to show relevant clinical variables that may or may not be input of the model along with the risk prediction to provide relevant clinical content to the user. Said medical information can be displayed using a text, representative of the variable identifier such as name that may be abbreviated, and a value which can be a text, a number, a color, etc. Examples may include pulse 506, respiratory rate 508, oxygen saturation or SpO2, 510

[0085] The GUI 500 can include a settings section to facilitate configuration parameters on the same view as the risk screen or a separate window that allow the device to be configured to provide recommendation according to availability of resources 512, and time to evacuation 514. Said configurations may or may not require admin permissions. In addition, the configurations can be set to a fixed value and the option may be disabled in settings that may not require the option. The said feature, can facilitate customization that may be necessary in some use settings such as combat environments to allow optimized use of resources and maximizing outputs.

[0086] FIG. 6 shows a GUI 600 with triage data including a plurality of triage messages 602- 606 that can be displayed, for example, on the other electronic health software interface 124. For example, GUI 600 can provide a detailed dashboard including patient’s risk of LSI and sub types of LSI, recommended actions and interventions such as administration of medications and other critical patient information such as SpO2 values.

[0087] The GUI 600 can include a triage display 602 to show a triage message related to medication. The GUI 600 can include a triage display 604 to show a triage message related to infusions. The GUI 600 can include a triage display 606 to show a triage message related to actions. Each of the triage displays 602-606 can colored to indicate an urgency value of the triage message. The triage displays 602-606 can render the text element of the triage action for visual reading.

[0088] The GUI 608 may also include medical information such as mode of injury, whether is provided to the algorithm or not. The information can facilitate remote evaluation by clinical experts when remote connectivity is possible.

[0089] The GUI 610 can be used by the user to facilitate rapid and intuitive recording of location of injury and remote communication with medical experts when remote connectivity is available.

[0090] The GUI 612 can include a scale representing global cardiovascular stability or other related patient characteristics, mainly developed to communicate the information with remote users when remote connectivity is available.

[0091] The GUI 614 can include one or multiple (or none) medical records of the patient for means of communication with remote users when remote connectivity is feasible. Such data may be automatically collected using integrations when possible or manually be entered by the medics and local users.

[0092] The GUI 616 can include other scale measure such as vasomotor tone, entered manually or collected automatically when integrations are possible. The information will facilitate improved clinical decision making by remote users when remote connectivity is available.

[0093] The GUI 618 can include cardiac scale measures such as cardiac power range for communication of the information to the remote users. Data can be collected manually using user input or through integration with other devices when possible. The information will facilitate improved clinical decision making by remote users when remote connectivity' is available.

[0094] The GUI 620 can include one or multiple numerical, discrete or textual medical information for display with remote users such as medical experts to facilitate.

[0095] The GUI 622 can include a scale measure representing pre-load responsiveness or other related measures that may be entered manually or collected automatically using integrations. The information will facilitate improved clinical decision making by remote users when remote connectivity is available.

[0096] FIG. 7 shows a swimlane diagram of an example process 700 for providing triage messages. For example, the process 700 can be used to provide automated triage for a patient in an ambulance in which data resources are constrained, the environment causes problems with patient monitoring, information about patients can be limited to non-existent due to the need to triage and evacuate unknown patients (e.g., accident victims, warfighters, disaster victims).

[0097] The PPG device 106 generates a PPG datastream 702, and the computing device 202 receives the PPG datastream. For example, a PPG device 106 can be affixed to the patient byan EMT, and the computing device 202 installed in the EMT’s ambulance can begin collecting a PPG datastream for the patient. In some implementations, the PPG datastream comprises a plurality of PPG-data points that each record, for example, a datapoint of a waveform of the PPG data at a timestamp. In some cases, the PPG datastream can include interruptions caused by removing the PPG device from the patient, for example, while being moved into or out of an ambulance, when a PPG device 106 accidently is pulled from the patient, etc.

[0098] The EKG device 104 generates the EKG datastream 706, and the computing device 202 receives the EKG datastream. For example, an EKG device 104 can be affixed to the patient by an EMT, and the computing device 202 installed in the EMT’s ambulance can begin collecting an EKG datastream for the patient. In some implementations, the EKG datastream comprises a plurality of EKG-data points that each record, for example, a datapoint of a waveform of the EKG data at a timestamp. In some cases, the EKG datastream can include interruptions caused by removing the EKG device from the patient, for example, while being moved into or out of an ambulance, when the EKG device 104 accidently is pulled from the patient, etc.

[0099] The computing device 202 receives and / or calculates other patient parameters 710. For example, the EMT’s ambulance may have other patient monitors such as respiratory7rate monitor, ventilator. End-tidal carbon dioxide (ETCO2) monitor, temperature monitor, blood pressure (invasive or non-invasive) monitor, heart rate monitor, etc. Each or any of these can provide associated datastreams of data points that can also be used in the process 700.

[0100] In some implementations, derivative parameters can be generated. For example, a respiration can be classified into hyperventilating, respiratory depression, and normal breathing. For example, a user’s cardiac activity can be used to generate a plurality7of Heart Rate Variability7(HRV) parameters for the patient. In some cases, the HRV parameters can have millisecond-scale granularity7.

[0101] As described above, many ambulance, emergency, combat, and other environments do not permit the EMT to know the patient’s identity, look up Electronic Health Records (EHR) for the patient, etc. However, the process 700 can advantageously be performed using only the equipment in the EMT’s ambulance (e.g., the EKG device 104, PPG device 1 6, computing device 202, and user interface(s) 122-126).

[0102] The computing device 202 collects triage data 712. For example, the computing device 202 can begin with no information or data about the patient, and store the incomingdatastreams until a sufficient amount of data is available to generate triage messages. This amount of data can be defined in terms of number of data points or size in bits or bytes of data. For example, in some implementations, the threshold amount comprises a first number of EKG-data points, and a second number of PPG-data points, the first number being different than the second number. This amount of data can be defined in terms of a length of time (e.g., seconds or minutes, such as 2 minutes). For example, the threshold amount comprises a duration of collecting determined based at least on a first frequency of EKG-data points in the EKG datastream and / or the duration of collecting is further determined by a second frequency of PPG-data points in the PPG datastream. As such, higher frequency datastreams may only need to be collected for less time than lower frequency data streams due to the rate at which data points are collected. Various examples have shown good results with even 2 minutes of data. This is significant since it can be vital for pre-hospital and tactical environments. Think of a setting where there are multiple casualties in an accident, a tactical scenario in which you have dozens of wounded soldiers in a high-stakes battle environment. Rapid results can be a crucial need in such settings.

[0103] The computing device 202 generates a triage message 714. For example, the computing device 202 can generate the triage message as soon as, and in response to, collecting the threshold amount of triage data using a subset of the triage data. Then, the computing device 202 can interactively generate new triage messages (or detennine no triage message is needed) continually. This can allow the EMT to receive updated triage messages as the patient’s condition changes. For example, if a condition worsens (e g. the patient begins to go into shock) the EMT can receive a notification that a new triage action is needed. For example, if a condition improves (e.g., a hyperthermic patient begins to wann) the EMT can receive a notification that a previous triage action is no longer needed. Various examples have shown good results with even 2 minutes of data. This is significant since it can be vital for pre-hospital and tactical environments. Think of a setting where there are multiple casualties in an accident, atactical scenario in which you have dozens of wounded soldiers in a high-stakes battle environment. Rapid results can be a crucial need in such settings to expedite rapid treatments and triage of patients. It also facilitates dynamic and continuous reevaluation of patient’s status which is important in pre-hospital and trauma environments to enable medics or other relevant operators of the system treat patients sequentially based on their immediate needs and rapidly evolving conditions. This is especially of advantage since compared to other care settings such as emergency department or inpatient settings, pre-hospital care often involves short care episodes and / or rapidly evolving patient conditions. The ability of the device to produce dynamic reassessments of patient's triage scores while relying on considerably shorter amount of signal streams also facilitates the device to provide assessments, triage and recommendations to medics for subsequent events, sequentially, or simultaneously, independently of other possible patient complications (LSI events) and past recommendations acting as a robust solution for providing insights to patient’s LSI needs and clinical decision support for treatment(LSI) needs. These features allow a force multiplication, freeing the clinician from time intensive evaluations by allowing the clinician to place connected monitors and rapidly return to patients with the highest needs. Given the continuous risk stratification the clinician can use that information to prioritize evacuation resources and LSIs.

[0104] The computing device 202 can generate the triage message using the triage data with an artificial -intelligence model. For example, the computing device 202 can submit the triage data to the artificial intelligence module 304 and receive back, zero, one, or more tirage messages.

[0105] In some cases, to generate the triage message on the display-screen, the triage device is further configured to convert one or more risk scores from the artificial-intelligence model into a color and the text element. For example, the computing device 202 can store a ruleset that defines a conversion from raw output of the artificial intelligence model 304 into a numeric or ordinal urgency value. The triage message can include a color-coded element, for example, based on the urgency value. In various examples, the color-coded element is colorable to indicate the urgency value of the triage message (e.g., red for high urgency value, green for low).

[0106] The triage message can include a text element that is displayable to indicate a triage-action suggested to apply to the patient. For example, the triage-action may be the infusion of a fluid, and the text element may be the name of the fluid. For example, the triage-action may be the administration of a medication, and the text element may be the name of that medication. For example, the triage-action may be an action for the EMT to perform, and the text element may be the name of that action (e.g., applying a tourniquet or active rewarming).

[0107] In some implementations, the triage device can send a message over a data network to a computing device configured to provide status information to users at a medical-care facility of incoming patients. For example, in situations in which there is a data connectionthat is available and safe to use (which is only some situations and not all situations) the EMT's computing device 202 can send a message to a routing or paging server of a hospital that the ambulance is driving to. The computing device 202 can send a notification of the patient status, expected time of arrival (ETA), location, etc.

[0108] The user interface(s) 122-126 output the triage message 716. Example user interfaces are show in FIG. 5 and FIG. 6. The computing device 202 can send one or more instructions to various available user interface(s) 122-126 to display the triage message.

[0109] A triage risk score can be output for the short-term need of LSI - which is indicative of the short-term intervention needs that directly facilitate the decision-making needed for prioritizing a patient to the right level of care (e.g., Trauma center) and appropriate mode of transportation (air transfer vs. ambulance vs personal vehicle, vs. none), including for interfacility transport. The triage risk score can provide pro-active recommendations on the type of actions needed in pre-hospital settings for the prevention of patient conditions worsening. The triage recommendation can include instructions to administer at least one of blood transfusion, advanced airway, or immediate evacuation, based on a real-time LSI- classifier operating locally. This score can be a dynamic triage and continuous monitoring score that is updated in real-time, so it’s a risk monitoring system not a onetime triage compared to the patent. This can enable use of the technology7not only as a prioritization tool but also as a continuous monitoring tool that can recommend proactive interventions in an environment in which the caregivers often are not clinical experts. In some implementations, the system can be configured to recalculate a triage risk score at intervals of, for example, less than 5 minutes based on newly captured waveforms from a wearable patch. This time window can be different in different implementations, and in some cases can be user configurable.

[0110] FIG. 8 shows an example of a computing device 800 and an example of a mobile computing device that can be used to implement the techniques described here. The computing device 800 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, and other appropriate computers. The mobile computing device is intended to represent various fonns of mobile devices, such as personal digital assistants, cellular telephones, smart-phones, and other similar computing devices. The components show n here, their connections and relationships, and their functions, are meant to be exemplary7only, and are not meant to limit implementations of the inventions described and / or claimed in this document.

[0111] The computing device 800 includes a processor 802, a memory 804, a storage device 806, a high-speed interface 808 connecting to the memory 804 and multiple highspeed expansion ports 810, and a low-speed interface 812 connecting to a low-speed expansion port 814 and the storage device 806. Each of the processor 802, the memory 804, the storage device 806, the high-speed interface 808, the high-speed expansion ports 810, and the low-speed interface 812, are interconnected using various busses, and can be mounted on a common motherboard or in other manners as appropriate. The processor 802 can process instructions for execution within the computing device 800, including instructions stored in the memot}' 804 or on the storage device 806 to display graphical information for a GUI on an external input / output device, such as a display 816 coupled to the high-speed interface 808. In other implementations, multiple processors and / or multiple buses can be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices can be connected, with each device providing portions of the necessary' operations (e.g., as a multi-processor system).

[0112] The memory 804 stores information within the computing device 800. In some implementations, the memory 804 is a volatile memory unit or units. In some implementations, the memory 804 is a non-volatile memory7unit or units. The memory' 804 can also be another form of computer-readable medium, such as a magnetic or optical disk.

[0113] The storage device 806 is capable of providing mass storage for the computing device 800. In some implementations, the storage device 806 can be or contain a computer- readable medium, such as a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory7device, or an array of devices, including devices in a storage area network or other configurations. A computer program product can be tangibly embodied in an information carrier. The computer program product can also contain instructions that, when executed, perform one or more methods, such as those described above. The computer program product can also be tangibly embodied in a computer- or machine-readable medium, such as the memory7804, the storage device 806, or memory on the processor 802.

[0114] The high-speed interface 808 manages bandwidth-intensive operations for the computing device 800, while the low-speed interface 812 manages lower bandwidthintensive operations. Such allocation of functions is exemplary7only. In some implementations, the high-speed interface 808 is coupled to the memory7804, the display 816 (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports 810,which can accept various expansion cards (not shown). In the implementation, the low-speed interface 812 is coupled to the storage device 806 and the low-speed expansion port 814. The low-speed expansion port 814, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, w ireless Ethernet) can be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a netw orking device such as a switch or router, e.g.. through a network adapter.

[0115] The computing device 800 can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as a personal computer such as a laptop computer 822. Alternatively, components from the computing device 800 can be combined with other components in a mobile device (not shown), such as a mobile computing device 850. Each of such devices can contain one or more of the computing device 800 and the mobile computing device 850, and an entire system can be made up of multiple computing devices communicating with each other.

[0116] The mobile computing device 850 includes a processor 852, a memory7864, an input / output device such as a display 854, a communication interface 866, and a transceiver 868, among other components. The mobile computing device 850 can also be provided with a storage device, such as a micro-drive or other device, to provide additional storage. Each of the processor 852, the memory7864, the display 854, the communication interface 866, and the transceiver 868, are interconnected using various buses, and several of the components can be mounted on a common motherboard or in other manners as appropriate.

[0117] The processor 852 can execute instructions within the mobile computing device 850, including instructions stored in the memory 864. The processor 852 can be implemented as a chipset of chips that include separate and multiple analog and digital processors. The processor 852 can provide, for example, for coordination of the other components of the mobile computing device 850, such as control of user interfaces, applications run by the mobile computing device 850, and wireless communication by the mobile computing device 850.

[0118] The processor 852 can communicate w ith a user through a control interface 858 and a display interface 856 coupled to the display 854. The display 854 can be. for example, a TFT (Thin-Film-Transistor Liquid Cry stal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology7. The display interface 856 can comprise appropriate circuitry for driving the display 854 to present graphical and other information to a user. The control interface 858 can receive commands from a user andconvert them for submission to the processor 852. In addition, an external interface 862 can provide communication with the processor 852, so as to enable near area communication of the mobile computing device 850 with other devices. The external interface 862 can provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces can also be used.

[0119] The memory 864 stores infonnation within the mobile computing device 850. The memory 864 can be implemented as one or more of a computer-readable medium or media, a volatile memory unit or units, or anon-volatile memory unit or units. An expansion memory' 874 can also be provided and connected to the mobile computing device 850 through an expansion interface 872, which can include, for example, a SIMM (Single In Line Memory' Module) card interface. The expansion memory 874 can provide extra storage space for the mobile computing device 850, or can also store applications or other information for the mobile computing device 850. Specifically, the expansion memory' 874 can include instructions to carry' out or supplement the processes described above, and can include secure information also. Thus, for example, the expansion memory 874 can be provide as a security’ module for the mobrle computing device 850, and can be programmed with instructions that permit secure use of the mobile computing device 850. In addition, secure applications can be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

[0120] The memory can include, for example, flash memory and / or NVRAM memory (non-volatile random access memory), as discussed below. In some implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The computer program product can be a computer- or machine-readable medium, such as the memory 864, the expansion memory 874, or memory on the processor 852. In some implementations, the computer program product can be received in a propagated signal, for example, over the transceiver 868 or the external interface 862.

[0121] The mobile computing device 850 can communicate wirelessly through the communication interface 866, which can include digital signal processing circuitry where necessary'. The communication interface 866 can provide for communications under various modes or protocols, such as GSM voice calls (Global System for Mobile communications), SMS (Short Message Service). EMS (Enhanced Messaging Service), or MMS messaging(Multimedia Messaging Service), CDMA (code division multiple access), TDMA (time division multiple access), PDC (Personal Digital Cellular), WCDMA (Wideband Code Division Multiple Access), CDMA2000, or GPRS (General Packet Radio Service), among others. Such communication can occur, for example, through the transceiver 868 using a radio-frequency. In addition, short-range communication can occur, such as using a Bluetooth, WiFi, or other such transceiver (not show n). In addition, a GPS (Global Positioning System) receiver module 870 can provide additional navigation- and location- related wireless data to the mobile computing device 850, which can be used as appropriate by applications running on the mobile computing device 850.

[0122] The mobile computing device 850 can also communicate audibly using an audio codec 860, which can receive spoken information from a user and convert it to usable digital information. The audio codec 860 can likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of the mobile computing device 850. Such sound can include sound from voice telephone calls, can include recorded sound (e.g., voice messages, music files, etc.) and can also include sound generated by applications operating on the mobile computing device 850.

[0123] The mobile computing device 850 can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as a cellular telephone 880. It can also be implemented as part of a smart-phone 882, personal digital assistant, or other similar mobile device.

[0124] Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, softw are, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0125] These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and / or object-oriented programming language, and / or in assembly / machine language. As used herein, the terms machine-readable medium and computer-readable medium refer to any computer program product, apparatus and / or device(e.g., magnetic discs, optical disks, memory. Programmable Logic Devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine- readable medium that receives machine instructions as a machine-readable signal. The term machine-readable signal refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0126] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0127] Example 1

[0128] In one example, case data from 2,809 critically ill trauma patients transported by a large helicopter emergency medical services system was used to train and validate an artificial intelligence model for the prediction of need for LSI. Model data included basic demography, initial physical and physiologic presentation, summary7serial vital state values and changes, and features derived from non-invasive continuous physiologic waveforms recorded throughout care and transport to hospital. This implementation explored a panel of decision tree-based model approaches, considering area under the receiver operating characteristics curve (AU-ROC) for prediction of LSI. This implementation considered area under the precision recall curve (AUPRC). Performance of the model was compared to a multivariable logistic regression model using the same outcome and non-waveform predictors. This implementation determined that an artificial intelligence-based triage system trained on delivery7of lifesaving intervention to critically ill transported patients provided an advantageous level of accuracy for austere prehospital conditions.

[0129] Example 2

[0130] In one example, this technology was implemented to identify both military and civilian trauma patients that require immediate evacuation and rapid access to air medical transport (AMT) by developing a clinical decision tool (CDT) to predict which patients would require Life Saving Interventions (LSI). Identifying the need for LSIs to facilitate rapid triage and treatment can reduce mortality and morbidity. A quarter of mortality fromcombat injuries is potentially preventable with timely hemorrhage control and airway management. Future large scale combat operations (LSCO) will tax resources for triage, initial management, evacuation, and prolonged field care. Units may need to operate semi autonomously and distant from resource rich environments. This implementation to uses ensemble artificial intelligence (Al) approaches to develop a predictive model of the need for LSIs within 30 minutes and 120 minutes of injury relying on continuous physiologic waveform data with minimal potential input from medics. The implementation also aims to validate this prediction model on a wearable device while developing a CDT for medics. The technology can empower combat medics to make initial assessments, triage, initial stabilization, and evacuation decisions for more patients with limited resources and opportunities for evacuation. The CDT can be a force multiplier that can inform rapid decisions and interventions for immediate lifesaving and can prioritize patients for evacuation. Using wearable monitors networked with the medic’s device can allow- for continuous, ongoing triage updates that can identify patients requiring LSIs before they decompensate allowing time for interventions as well as secondary triage for re-evaluation of evacuation priorities through Role 2 medical treatment facilities.

[0131] This implementation developed a CDT to identify patients benefiting from early tactical evacuation using high dimensional continuous physiologic data and anatomic injurypatterns to predict the need for LSI. This example derived and tuned multimodal ensemble Al models based on patient derived waveforms and raw clinical data. This example employed feature learning development that adopted multiple levels of feature generation techniques, including w indow -based time-domain features from the waveform signals (electrocardiogram [ECG] and photoplethysmography [PPG]) and statistical summarization techniques to create patient feature representations that ML models could employ. This example resulted in an over 5,000-dimensional feature vector representation for each patient sample. This example evaluated multiple sampling strategies with regular samples generated every 2 minutes. Al models w ere trained to predict future LSI using multimodal input from waveform, physiological measurements, vital signs, and demographics to predict LSI (including LSI category) outcomes for individual patients (Fig. 9, data 9000). This example used a 30% hold-out strategy for training and testing. After tuning and refining the hyperparameters, this example developed a model that outperforms initial goals (AUROC>0.8). Models including all features performed best (AUROC 0.85, AUPRC0.63) but models using only vital sign trend and waveform data (AUROC 0.82, AUPRC 0.58) or waveform data alone (AUROC0.77, AUPRC 0.51) performed well while requiring little to no input from a medic. This example further developed ensemble models which improved some performance characteristics. As a base model, random forest performed best with a AUROC (0.85) and AUPRC (0.63), while the ensemble method had slightly improved AUPRC (0.66) Subsequent testing using deep learning techniques (Long Short-Term Memory' [LSTM]) demonstrated similar performance for predicting LSI. When informed by trend and waveform data the model performed with an AUROC 0.85 and AUPRC 0.68. When limited to waveform data only, performance only minimally declined to AUROC 0.78 and AUPRC 0.55. This example evaluated the addition of anatomic injury data from patients charts; however, these data offered little benefit and, in some cases, worsened the performance of the models. Thus, this example anatomic injury patterns from consideration in the CDT This may be ultimately favorable from an operationalization standpoint, potentially eliminating the need for medics to recognize and input this into the CDT in this example. This example’s secondary objective was to validate patterns of waveform physiologic data to predict the need for early LSI using low weight and size, noninvasive wearable sensor technology. This example prospectively collected data on trauma patients flown to trauma centers a low weight and size, non-invasive sensor placed on the chest, with more than 50% of enrollment completed. Flight crews are simultaneously monitoring patients using other monitors. These data are being compared to the waveform data extracted from the wearable sensor and the previously derived models can be run substituting the waveform data derived from the wearable for the wavefonn from the other monitor. An additional objective was to validate the CDT to discriminate injured patients that benefit from immediate evacuation evidenced by lower early mortality or shorter prehospital time. This example applied the model to patients in a cohort. To operationalize into a CDT, this example preliminarily evaluated the distribution of LSI probabilities in this cohort. This example assigned patients with an LSI probability of >5% in the first 2-minute sample of data obtained to early evacuation and those with <5% LSI probability to delayed evacuation. This example then evaluated the association between risk-adjusted 24-hour mortality and prehospital time controlling for age, ISS, admission vital signs, and resuscitation requirements separately by immediate versus delayed evacuation assignment while clustering by treating trauma center. Among injured patients assigned to early evacuation, each additional 1 -minute of prehospital time was associated with a 1.3% increase in the odds of 24-hour motility (aOR 1.013; 95%CI 1.010 — 1.017, p<0.001), while among injured patients assigned to delayed evacuation prehospital time was not associated with 24-hour mortality (aOR 1.001; 95%CI 0.999 — 1.003, p=0.124). This preliminary validation confirms predicting the need for early LSI in our CDT is associated with early mortality and the need for time-dependent early evacuation.

[0132] This example demonstrated functionality to collect high resolution, multidimensional data during civilian air medevac operations and leverage these data for other uses such as major military’ and civilian health priorities. This technology’ has accrued more than 150 patients in this phase, using wearable data demonstrating reliable capture of high-quality physiologic data under a variety of conditions including in-flight during helicopter transport in real-world trauma patients.

[0133] This example carried out pioneering work on data analysis of cardiorespiratory instability (CRI) to cluster wearable data to define morbidity, mortality, resource use and the need for LSI. This example’s algorithm predicts LSIs with an overall AUROC of 0.81 when using only physiologic waveform data captured from monitors, which can be considered highly accurate, with no further input needed from prehospital clinicians. Further, this example maintains a comparable high AUROC when looking at 2-minute data epoch samples out to 15 minutes preceding the LSI, regardless of whether later sample information (i.e., more proximate to the LSI) was included or not (Fig. 10, data 1000). We produced similar time-series results when using only first patient LSI as an outcome.

[0134] Among 2,868 patients in this example's cohort, those that required an LSI within 30 minutes had a 12. 1% 24-hour mortality rate compared to 2.6% for those without an LSI within 30 minutes (p<0.001). Similarly, 24-hour mortality7remained significantly higher among patients that required an LSI within 2 hours compared to those that did not (9.0% vs. 1.8%, pO.001). The need for critical care and ICU admission also was substantially higher in those requiring an LSI versus those that did not within 30 minutes (81.6% vs. 44.2%. p<0.001) or within 2 hours (83.3% vs 37.5%, p<0.001). As noted above, we operationalized our CDT preliminarily as assigning early evacuation to patients with an LSI probability of >5%. Overall an LSI probability’ of 5% corresponded to approximately the 75thpercentile of all LSI probabilities, and the 50thpercentile among patient that did undergo an LSI within 2 hours. Among injured patients assigned to early evacuation, each additional 1-minute of prehospital time was associated with a 1.3% increase in the odds of 24-hour motility (aOR 1.013; 95%CI 1.010 — 1.017, p<0.001), while among injured patients assigned to delayed evacuation prehospital time was not associated with 24-hour mortality’ (aOR 1.001; 95%CI 0.999 — 1.003, p=0.124). This demonstrates that LSI are an appropriate target to predict anduse to make evacuation triage decisions, as prehospital time per each additional minute is associated with increased mortality in those that should undergo early evacuation based on the CDT.

[0135] As will be appreciated, different examples may produce different findings.

[0136] In some aspects, the techniques described herein relate to a system including: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: receive at least one datastream of a biosensor data for a subject in transit to a medical facility'; submit, to an LSI-classifier, the datastream of biosensor data, wherein the LSI-classifier is configured to operate with a model trained with training data including training biosensor data and target LSI classifications: receiving, from the LSI-classifier. a suggested LSI to provide to the subject in transit.

[0137] In some aspects, the techniques described herein relate to a system, wherein the operations further include: identify ing one or more LSI parameters based on stored data that identifies possible suggested LSIs and corresponding LSI parameters that specify a detail of the suggested LSI; and sending a data message with the suggested LSI and the one or more LSI parameters to provide to the subject in transit.

[0138] In some aspects, the techniques described herein relate to a system, wherein the biosensor data includes at least one of the group consisting of i) electrocardiogram (ECG) data; ii) photoplethysmogram (PPG) data, and iii) non-signal data points.

[0139] In some aspects, the techniques described herein relate to a system, wherein the suggested LSI is at least one of the group consisting of i) evacuation of the subject and ii) non-evacuation of the subject.

[0140] In some aspects, the techniques described herein relate to a system, wherein the biosensor data is collected using a body -worn patch applied to the subject after the subject has received a traumatic injury'.

[0141] In some aspects, the techniques described herein relate to a system, wherein the operations further include provide a graphic user interface (GUI) configured to display the suggested LSI.

[0142] In some aspects, the techniques described herein relate to a system, wherein the GUI further includes current vital signs for the subject in addition to the suggested LSI.

[0143] In some aspects, the techniques described herein relate to a system, wherein the subject is in transit in a vehicle selected from the group consisting of i) an EMT ambulance and ii) a helicopter.

[0144] In some aspects, the techniques described herein relate to a system, wherein the system further includes local data connections to the biosensor and is free of connection to external data sources outside the vehicle.

[0145] In some aspects, the techniques described herein relate to a system wherein the external data sources outside the vehicle include the Internet.

[0146] In some aspects, the techniques described herein relate to a system for prediction patient's risk of needing lifesaving interventions and requiring immediate evacuation in emergency medicine settings: at lease on local deployed (in ambulance or helicopter or handheld) compute device including but not limited to server, laptop, tablet, mobile computer, single board computers, etc.) establishing in communication with sources of patient real-time clinical data: receiving and storing raw high frequency signals from biosensor devices including ECG, PPG through wireless (e.g. Wi-Fi, Bluetooth, etc.) or wired (e.g. ethemet, USB, ) communication methods; collecting and storing data periodically from patients medical records entered by the medical team using a computer software either directly on the compute device or integrated externally either through wireless or wired communication using HTTP / Web protocols, SOAP or other remote procedure call methods, or vendor specific Application Programming Interface (API) calls; a data struct that combines and synchronize the real-time multimodal time-series data from patient's medical records and high frequency signal data (ECG, PPG signals, heart rate, ETCO2, blood pressure; a compute engine that either is on the same server or deployed on at least another server that receives data through the data link system (either push pull) and combines the different data modalities and feeds them to artificial intelligence algorithms or machine learning models that can predict the probability of experiencing bleeding or the probability of experiencing different degrees of bleeding in the remaining time of patient's care; a module that stores the predicted risk scores and probability that can run on the same server or at least one server or more servers on the on-site network or on an offsite network or on a cloud computing infrastructure; a module that can access the stored risk predictions and visualize the stored information on a user software access for example as an independent web portal on any machine including mobile devices, tablets, laptops, computers, monitors as a part of an embedded interface within existing EMT softwares, compromising at least one of thefollowing features: a risk panel that represents the most recent predicted risk score and immediacy of evacuation; a risk dashboard that allows clinicians to investigate related information that resulted in the existing risk predictions for general need of LSI, urgency of evacuation, particular types of LSI such as blood transfusion, medication administration, cardiopulmonary resuscitation, needle decompression, etc. and related recommended actions.

[0147] In some aspects, the techniques described herein relate to a method of identifying the risk of future bleeding or identifying levels of future bleeding including the steps: receiving and reviewing at least one of the raw high frequency patient physiological signals including electrocardiogram(ECG) monitor, Photoplethysmography (PPG) monitor, electroencephalogram (EEG), respiratory' rate monitor, ventilator, End-tidal carbon dioxide (ETCO2), temperature, blood pressure (invasive or non-invasive), heart rate and during a period of time originated from bedside monitoring devices, biosensor patches, wearable devices, etc.; receiving multiple measures of various patient clinical information from patient's medical data stored in Electronic Health record software, collected and extracted periodically in equal or irregular windows and during a period of time; cleaning the medical data from EHR by removing error prune records, converting units, converting variables, normalizing, and etc.; cleaning the signal data using a signal cleaning method; feeding the entirety7of all of the available modalities of data to the machine learning models and the artificial intelligence algorithms that will compute: a dense or sparse representation that encodes temporal and non-temporal patterns existing in the available modalities of the data into a vector representation; and feed the dense vector representation to a machine learning model that uses the dense representation to predict patient outcomes risk of bleeding or levels of bleeding in a future period of time during patient's visit w hich can either be a fixed window or it can represent the entirety of a patient's hospital stay before discharge.

[0148] Implementations can include any, all, or none of the following features.

[0149] The technology7introduces a risk score to facilitate the triage of patients by identifying the need for life saving interv entions in prehospital settings or post-transfer to hospital settings. This information can be used to inform the medics about the urgency and need for rapid intervention, transfer to high resource settings or prioritization for evaluation.

[0150] The technology7can address shortcomings in current triage solutions for civilian emergency medical services. Civilian medics also make triage and treatment decisions with inadequate infonnation. Trauma is a time-sensitive condition: a few minutes' delay to LSI can mean the difference between life and death. Use of air medical transport (AMT) is a criticaldecision for civilian medics, analogous to tactical evacuation. Medics must determine whether patients require AMT or can tolerate ground transport and the associated delay to definitive care. Multiple studies demonstrate AMT increases survival after severe injury compared to ground transport. AMT brings advanced LSI capabilities to the patient within minutes of injury (e.g., advanced airway, blood transfusion) that are not widely available from ground providers. AMT also provides access to resources at specialized centers and reduces time to trauma center arrival when LSI are not available in the prehospital setting or at local health care facilities (e.g., damage control surgery). Current approaches to predict which patients will need early LSI or benefit from AMT are inadequate, evidenced by frequent over-triage to AMT, an expensive and limited resource. Inappropriate triage to AMT reduces availability of these assets for patients who would otherwise benefit. Additionally, civilian medics cannot reliably predict which patients will benefit from advanced medical resources or rapid transport afforded by AMT. During mass casualty events this is compounded by a resource constrained setting where multiple patients make allocating limited medical interventions critical. Mass casualty is defined as a situation where the number of patients exceeds the resources of the community to care for them. In rural environments where EMS systems may only have one paramedic covering dozens of square miles, this could be a single motor vehicle accident with tw o patients if there is only one clinician to care for them. The technology can improve civilian pre-hospital emergency care by improving accuracy of triage, identifying the need for life saving interventions and definitive trauma care. Additionally, the technology can facilitate early interventions, expedited patient transfer, improved use of resources including the air medical assets, and constrained clinical resources such as blood products. Additionally, the clinical decision tool (CDT) can facilitate better triage of patients and assignment of patients to the appropriate level of hospital care. Inaccurate triage may result in transfer of critical or trauma patients to inadequate care settings which in turn may require subsequent re-triage, delayed intervention and poor patient outcomes. Thus, improved triage can prevent misallocation, reduce costs and improve patient outcomes via earlier intervention, prevention of secondary injury (due to hypoperfusion and organ damage) and transfers to high resource care settings. Similarly, the proposed technology can address challenges related to emergency department (ED) and trauma care overcrowding by improving accuracy of patient triage and reducing cases of over triaging. Overcrowding refers to the condition leading to the dysfunction of the emergency department due to the fact that the number of patients exceeds the capacity of the facility,which is proven to result in longer ED stays, increased mortality rate, poorer patient outcomes, increased cost of care and patient redirections. Over-triage can contribute to overcrowding at specialty centers by increasing the number of presenting patients from EMS and community hospitals.

[0151] The foregoing detailed description and some embodiments have been given for clarity of understanding only. No unnecessary limitations are to be understood therefrom. It will be apparent to those skilled in the art that many changes can be made in the embodiments described without departing from the scope of the invention. Thus, the scope of the present invention should not be limited to the exact details and structures described herein, but rather by the structures described by the language of the claims, and the equivalents of those structures. Any feature or characteristic described with respect to any of the above embodiments can be incorporated individually or in combination with any other feature or characteristic, and are presented in the above order and combinations for clarity only.

[0152] A number of embodiments of the inventions have been described. Nevertheless, it will be understood that various modifications can be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.

Claims

WHAT IS CLAIMED IS:

1. A system for automated triage suggestion generation in an ambulance, the system comprising: an ambulance configured to receive a patient and transport the patient to a medical-care facility; an electrocardiogram (EKG) device configured to generate an EKG datastream for the patient, the EKG datastream comprising a plurality of EKG-data points; a photoplethysmography (PPG) device configured to generate a PPG datastream for the patient, the PPG datastream comprising a plurality of PPG-data points; and a computing device configured to be removably installed in the ambulance and comprising a display -screen, at least one processor, and memory, the computing device configured to: receive, from the EKG device, the EKG datastream; receive, from the PPG device, the PPG datastream; collect a threshold amount of triage data from the EKG-data points and the PPG-data points for the patient; generate, responsive to collecting the threshold amount of triage data, a triage message on a display-screen using the triage data with an artificial-intelligence model, the triage message comprising a color-coded element and a text element, wherein: the color-coded element is colorable to indicate an urgency value of the triage message; and the text element is displayable to indicate a triage-action suggested to apply to the patient.

2. A triage device for automated triage suggestion generation, the triage device comprising at least one processor and memory, the triage device configured to: receive, from at least one electrocardiogram (EKG) device, an EKG datastream for a patient, the EKG datastream comprising a plurality of EKG-data points; receive, from at least one photoplethysmography (PPG) device, a PPG datastream for the patient, the PPG datastream comprising a plurality’ of PPG-data points; generate, using an artificial intelligence model and based on a threshold amount of data from a subset of the EKG data points and the PPG data points, a triage message configured to be presented on a display-screen, the triage message comprising a color-coded element and atext element, wherein: the color-coded element is configured to indicate a level of urgency associated with the triage message; and the text element is configured to indicate a suggested triage-action for the patient.

3. The triage device of claim 2, wherein generating the triage message using the artificial intelligence model comprises: generating a plurality of Heart Rate Variability (HRV) parameters for the patient, the HRV parameters having millisecond-scale granularity; and providing the HRV parameters with the artificial-intelligence model.

4. The triage device of claim 2, wherein the threshold amount comprises a first number of EKG-data points, and a second number of PPG-data points, the first number being different than the second number.

5. The triage device of claim 2, wherein the threshold amount is associated with a time duration determined based at least on a first sampling rate of EKG-data points in the EKG datastream.

6. The triage device of claim 5, wherein the duration is detennined based also on a second sampling rate of PPG-data points in the PPG datastream.

7. The triage device of claim 2, wherein the triage message is generated without using information from Electronic Health Records (EHR) for the patient.

8. The triage device of claim 2, wherein: the EKG device is a N lead EKG device; and the PPG device is a pulse oximeter.

9. The triage device of claim 2, wherein the artificial intelligence model is trained using training data that comprises: first records of trauma victims transported to medical-care facilities; second records of life-saving interventions provided to the trauma victims while beingtransported to the medical-care facilities; and third records of outcomes for the trauma victims.

10. The triage device of claim 2, wherein the artificial intelligence model comprises a plurality of classifiers arranged in a decision-tree ensemble.

11. The triage device of claim 2, wherein the triage device is further configured to convert one or more risk scores from the artificial intelligence model into a color and the text element.

12. The triage device of claim 2, further comprising one or more digital filters configured to remove artifacts caused by rotor noise of a helicopter.

13. The triage device of claim 2, wherein the threshold amount of data comprises data corresponding to interruptions caused by removing from the patient at least one of the EKG device or the PPG device.

14. The triage device of claim 2, further comprising a transceiver configured to send a message over a data network to a computing device configured to provide status information to a medical-care facility, the message comprising the triage message.

15. A method of automated triage for a patient, the method of automated triage comprising: receive, from at least one electrocardiogram (EKG) device, an EKG datastream for the patient, the EKG datastream comprising a plurality of EKG-data points; receive, from at least one photoplethysmography (PPG) device, a PPG datastream for the patient, the PPG datastream comprising a plurality’ of PPG-data points; generate, using an artificial intelligence model and based on a threshold amount of data from a subset of the EKG data points and the PPG data points, a triage message configured to be presented on a display-screen, the triage message comprising a color-coded element and a text element, wherein: the color-coded element is configured to indicate a level of urgency associated withthe triage message; and the text element is configured to indicate a suggested triage-action for the patient.

16. The method of claim 15, wherein the threshold amount comprises a first number of EKG-data points, and a second number of PPG-data points, the first number being different than the second number.

17. The method of claim 15, wherein: the threshold amount is associated with a time duration determined based at least on a first sampling rate of EKG-data points in the EKG datastream; and the duration is determined based also on a second sampling rate of PPG-data points in the PPG datastream.

18. The method of claim 15, wherein the artificial intelligence model is trained using training data that comprises: first records of trauma victims transported to medical-care facilities; second records of life-saving interventions provided to the trauma victims while being transported to the medical-care facilities; and third records of outcomes for the trauma victims.

19. The method of claim 15, wherein the method further comprises converting one or more risk scores from the artificial intelligence model into a color and the text element.

20. The method of claim 15, wherein the method further comprises sending a message over a data network to a computing device configured to provide status information to a medical-care facility.

Images