System and method for monitoring for risk of bleeding using multimodal artificial intelligence

Abstract

Elements such as computer servers can perform operations comprising: receive at least one data stream of biosensor data; receive records of past medical events; submitting, to a medical-event classifier, the data stream of biosensor data and the records of past medical events, wherein the medical-event classifier is configured to operate with a model trained with training data comprising training biosensor data and training records; and receiving, from the medical-event classifier, a prediction record that comprises i) a prediction event and ii) a confidence value that the prediction event will occur in the future.

Description

SYSTEMS AND METHODS FOR MONITORING FOR RISK OF BLEEDINGUSING MULTIMODAL ARTIFICIAL INTELLIGENCECROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 552,531, filed February 12, 2024, the contents of which are incorporated by reference herein.TECHNICAL FIELD

[0002] This document describes computational processes such as machine learning to identify when a subject such as a patient is at risk of a negative medical outcome due to bleeding, e.g., maternal-related hemorrhaging.BACKGROUND

[0003] Bleeding, both external and internal, is a medical condition that may require immediate attention. Bleeding, hemorrhage, hemorrhage or blood loss is blood escaping from the circulatory system from damaged blood vessels. Bleeding can occur internally, or externally either through a natural opening such as the mouth, nose, ear, urethra, vagina or anus, or through a puncture in the skin. Hypovolemia is a massive decrease in blood volume, and death by excessive loss of blood is referred to as exsanguination. The stopping or controlling of bleeding is called hemostasis and is an important part of both first aid and surgery.SUMMARY

[0004] This technology presents an Al-based bleeding detection tool that utilizes physiologic signals captured using patient monitoring techniques, advanced algorithms, and machine learning techniques to identify and assess early bleeding invarious contexts, and forecast clinically significant bleeding. Machine learning (ML) is a field of study in artificial intelligence concerned with the development and study of statistical algorithms that can learn from data and generalize unseen data, and thus perform tasks without explicit instructions. The tool can be designed to work in the context of ongoing active bleeding before it becomes clinically apparent. This situation can be found in several clinical contexts, including but not limited to intraoperative and / or post-operative monitoring in patients undergoing surgery, peripartum and / or post-partum hemorrhage in birthing women, gastrointestinal bleeding, and trauma.

[0005] Signs of bleeding typically manifest as a faster heart rate initially, followed by low blood pressure and other manifestations of increased adrenergic stimulation. The human body typically compensates physiologically for blood loss, making it challenging to detect hemorrhage early, before a typical patient has lost 15% of their blood volume. With blood loss between 15% and 30%, an increase in heart rate and breathing rate typically appears. Conversely, a decrease in blood pressure may not be apparent unless blood loss exceeds 30% of blood volume. AL based processes can detect subtle changes in various metrics computed from high- resolution capture of those vital signs, significantly ahead of elevation of heat rate, respiratory rate, and low blood pressure. Such a process can facilitate detection of sub-clinical physiological response to sub-clinical bleeding, forecasts future significant bleeding, and therefore provides a better opportunity to intervene and hopefully avert the morbid consequences associated with significant hemorrhage.

[0006] Implementations of the Al-based algorithm can include a user-interface for regularly updated and historical display of bleeding risk, a simple scale (green, yellow, red) to interpret the risk, and suggested clinical workflows corresponding tothe level of risk. This interface can be available as a web-based interface, as well as a mobile app.

[0007] Other solutions to detect significant bleeding are based on visual assessment and heuristic estimation of blood loss by clinicians, counting or imaging blood-stained compressed, or measuring blood collected through general-purpose suction devices and canisters or dedicated blood collecting devices. Not only are these methods applicable only when larger visual amounts of blood have already been lost, all lead to significant underestimation of blood loss. The solution herein is the first automated approach to sub-clinical bleeding detection and hemorrhage forecasting, and the first physiology -based approach to this major clinical challenge.

[0008] 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 data stream of biosensor data; receive records of past medical events; submitting, to a medical-event classifier, the data stream of biosensor data and the records of past medical events, wherein the medicalevent classifier is configured to operate with a model trained with training data including training biosensor data and training records; receiving, from the medicalevent classifier, a prediction record that includes i) a prediction event and ii) a confidence value that the prediction event will occur in the future.

[0009] In some aspects, the techniques described herein relate to a system, wherein the operations further include: identifying an intervention based on stored data that identifies possible prediction events and corresponding interventions identified to address the prediction event; and sending a data message with the intervention to be applied to a subject that is monitored in the biosensor data.

[0010] 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) speckle plethysmography (SPG) data.

[0011] In some aspects, the techniques described herein relate to a system, wherein the biosensor data is collected using a body -worn patch by a subject that has undergone a medical procedure having a possible side effect of hemorrhage.

[0012] In some aspects, the techniques described herein relate to a system, wherein receiving the at least one data of biosensor data includes processing raw data to perform at least one of the group consisting of i) altering a format of the data, and ii) removing anomalous data.

[0013] In some aspects, the techniques described herein relate to a system, wherein the medical-event classifier is configured to operate with a model trained with training data including training biosensor data and training records, including: encoding the data stream of biosensor data and the records of past medical events into a input-vector in vector space; and operating on the input-vector to identify i) the prediction event and ii) the confidence value that the prediction event will occur in the future.

[0014] 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 prediction event and one or more recommended interventions for the prediction event.

[0015] In some aspects, the techniques described herein relate to a system, wherein the GUI further includes a risk score in a numeric format that identifies a severity of the risk.

[0016] In some aspects, the techniques described herein relate to a system, wherein the risk score is based on, and not the same as, the confidence value that the prediction event will occur in the future.

[0017] In some aspects, the techniques described herein relate to a system, wherein the risk score is the confidence value that the prediction event will occur in the future.

[0018] In some aspects, the techniques described herein relate to a system for detecting risk of bleeding including: at least one server in communication with WAN or deployed either on local onsite network or on the cloud that is responsible for data collection and synchronization: receiving and storing raw high frequency signals from biosensor devices including ECG, PPG or SPG signals; collecting and storing data from electronic medical records(EMR) using direct integration, ETL, standard protocols and APIs including FHIR, HL7 or any other web based, or HTTP -based, SOAP -based, Restful, or remote procedure call methods, or through data dumps that use any of the formats including JSON, text, BSON; at least one data link system that redirects / push real-time collected data to other parts of the systems or allows pull access to the stored data by other modules; storing and synchronization of physiological signal data and EMR data in a unified data structured using either static file format or database softwares (relational and non-relational); a compute engine that either is on the same server or deployed on at least another server that receives data from the data struct (either push pull), preprocess the data, cleans data and finally utilizes multimodal 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 atleast 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 utilizes pre-stored rules to generate real-time care recommendations: care recommendation rules can use real-time risk predictions and other patient clinical data (e.g. blood pressure) to recommend time-sensitive actions; and a module that utilizes a database system to store recommendation actions at each time based most recent patient bleeding risk scores

[0019] 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 ECG, PPG and SPG signals 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 Medical record software, collected and extracted periodically in equal or irregular windows and during a period of time; cleaning the medical data from EMR by removing error- prone records, converting units, converting variables, normalizing, and etc.; cleaning the signal data using a signal cleaning method; feeding the physiological high- frequency signal data and electronic medical records variables available at the time of assessment to the machine learning models and the artificial intelligence algorithms that can compute: a dense or sparse representation that encodes temporal and nontemporal patterns existing in the both data modalities (high-frequency signal and EMR data) 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 oftime during patient's visit which can either be a fixed window or it can represent the entirety of a patient's hospital stay before discharge.

[0020] In some aspects, the techniques described herein relate to a module that can access the stored risk predictions and the stored recommendations to visualize the stored information on a web-based software access as an independent web portal on any machine including mobile devices, tablets, laptops, computers, monitors or as a part of an embedded interface within existing hospital softwares, compromising at least one of the following features: a risk panel that represents the most recent predicted risk score; a recommendation panel that considers the predicted risk, other patient clinical information and conditions collected in System 1 and standard workflows to provide a list of recommended actions for patient; and a risk dashboard that allows clinicians to investigate related information that resulted in the existing risk predictions.

[0021] Current methods for detecting acute ongoing bleeding may involve serial vital sign assessments, visual inspection, and medical imaging techniques. These methods can be limited by lack of sensitivity, delayed detection, human oversight, and in some cases, may lead to invasive procedures and further risks to patients undergoing such procedures. Delayed detection is associated with significant morbidity, increased resource use, and potentially mortality. Detection of early, not clinically apparent, yet physiologically significant bleeding would constitute a major advance in clinical care, when such early bleeding eventually forecasts clinically significant bleeding. An automated, Al-driven solution could offer faster, more accurate, and non-invasive forecasting of clinically significant bleeding. Other features, aspects and potential advantages will be apparent from the accompanying description and figures.DESCRIPTION OF DRAWINGS

[0022] Fig. 1 shows an example of an overall system design and data flow between the modules to monitor patient’s clinical and physiological signals and provide real-time risk assessment and recommendations to physicians.

[0023] Fig. 2 illustrates use of two data modalities with examples of ECG signal data and a high level view of low frequency and irregularly sampled EMR data and the two step process in representation learning and risk prediction models.

[0024] Fig. 3 demonstrates the process flow diagram for applying rule bases recommendations in accordance to patient context and risk.

[0025] Fig. 4 is an example of a system diagram for signal integration when vendor specific cloud integration solutions are available.

[0026] Fig. 5 is an example of a system diagram for signal integration when vendor specific cloud integration solutions are not available.

[0027] Figs. 6 and 7 illustrate example UI designs for the patient’s risk dashboard for an example patient for evaluating and examining model recommendations and risk predictions.

[0028] Fig. 8 shows examples of alerts communicated in a mobile platform.

[0029] Fig. 9 shows a swimlane diagram of an example process for predicting maternal hemorrhage and associated interventions.

[0030] Fig. 10 shows a swimlane diagram of an example process for predicting maternal hemorrhage and associated interventions.

[0031] Fig. 11 is a schematic diagram that shows an example of a computing device and a mobile computing device.

[0032] Like reference symbols in the various drawings indicate like elementsDETAILED DESCRIPTION

[0033] The technology described herein provides for Al-based tools that allow for early prediction of, and intervention in, severe and / or clinically significant maternal hemorrhaging conditions — at time points when recognized manifestations of such conditions may not be present — thereby allowing for preemptive steps to be taken against potentially life-threatening events. Trained machine-learning models combine various sensor inputs together with individual patient data (e.g., as automatically obtained from an EMR database) to generate personalized risk assessments pertaining to clinically significant hemorrhaging conditions allowing for decision-making that is based on individuals rather than a general patient population. By allowing for granular intermittent updates as more sensor data and / or EMR data becomes available, the technology described herein facilitates decision making that is relevant, and timely. Further, risk assessments and intervention recommendations can be provided based on configurable thresholds such that a user (e.g., a clinician) is likely to act on the recommendations.

[0034] The technology can be used to monitor for risk of visual or non-visual bleeding at the point of care. It can be used by clinicians to monitor patient’s medical and physiological status, and to provide an early warning sign for acute bleeding which in turn can facilitate early interventions such as administration of medications, invasive and non-invasive procedural and surgical interventions or other means of treating or controlling or preventing bleeding.

[0035] The technology can be used to address complications during childbirth.Maternal hemorrhage is a life-threatening complication of childbirth that happens to nearly 5% of the population and is known as an unpredictable problem. The challenge is that bleeding during birth (vaginal or cesarean) is normal. Therefore, sight of blooditself cannot be used as an alerting mechanism or intervention decision. However, the challenge is to determine if a patient's level of bleeding is or will be leading to significant physiological decompensation that may need a medical intervention to recover. Some existing methods for monitoring and detection of maternal hemorrhage rely on measuring the volume of blood loss using either estimated blood loss or quantitative blood loss techniques and standard pre-defined thresholds for intervention decisions (500cc for vaginal and lOOOcc for cesarean birth). These methods can result in significant underestimation of blood volume, and therefore delayed intervention. In addition, standard blood loss volume thresholds lack personalization and consideration for patient specific physiological characteristics. Therefore, the proposed technology can improve the current clinical practice by providing a personalized monitoring approach that can be completely automated through use of biosignal patches and standard patient data collected through the EMR systems. The technology can facilitate early detection of risk of hemorrhage and detection of early signs of hemodynamic stability based on patient’s characteristics, medical history, current medical information (vital signs, lab results) and current care plan in conjunction with mother’s biosignal data, acting as an early detection and alarm system that can detect risk prior to visual blood loss or changes in patient vital signs. Clinicians can rely on the bleeding risk score do determine early interventions such as administration of uterotonics (e.g. oxytocin or pitocin), antifibrinolytic agent (e.g. Tranexamic acid), early use of control or treatment interventions such as the bakri balloon or the Jada device, escalating patient care to better equip care settings for close monitoring (e.g. intensive care unit) or finally admission to the operating room for surgical intervention. In addition, the system can be used as an early warning sign to expedite or start preparedness measures to intervene as needed when facingsevere bleeding. Such interventions can be based on related hospital protocols such as massive transfusion or maternal hemorrhage management protocols which may include order crossmatch tests, preparing and ordering blood from the blood bank, ordering preparation or use of cell savage device that can facilitate cleansing and transfusion of patient’s own blood, alerting clinical stakeholders and other relevant measures.

[0036] The technology may be of use in the operating room setting. Although bleeding is typically easily observable in the operating theater, the estimated blood loss can go underestimated in some situations. Surgeries where the operating field is large are also associated with evaporative fluid losses, generally estimated as 250cc / hr per quadrant of the abdomen exposed. Further, as previously described, an estimated blood loss may not correlate with the magnitude of the physiological challenge, which is the real measurement of the ability of the body to compensate for this intravascular volume loss. Accordingly, the technology, which measures the extent of physiological response to volume loss, could be a useful adjunct or substitute to other processes that inaccurately measure intraoperative physiologically significant volume loss.

[0037] Physiologically significant volume loss and bleeding are particularly challenging to diagnose in patients outside of the operating room, on hospital floors, step-down units, or intensive care units. Indeed, the source of the bleeding is typically hidden from view, such that blood loss cannot be estimated. This is typically the case with gastrointestinal hemorrhages from esophageal varices of bleeding ulcers, where diagnosis is often much delayed and typically triggered by observable physiological derangements, such as hypotension. Re-bleeding is a frequent occurrence after initial attempts at control of the source of the bleeding. The technology could identify occultbleeding and early rebleeding much more readily than currently available techniques and trigger earlier therapeutic interventions.

[0038] Applications and use of the technology in emergency departments presents a different set of requirements and opportunities. Patients often present with a history of bleeding such as melena, hematochezia, and vomiting of blood, which is impossible to quantify except when there is already hemodynamic instability.Additional factors such as stress could also contribute to tachycardia unrelated to volume loss. Home medications in the form of beta-blockers may blunt a tachycardic response to volume loss and thus obfuscate early diagnosis. The technology could be useful in this setting as well, especially since there is likely a significant a priori probability of physiologically significant volume loss.

[0039] There are additional clinical situations associated with extensive intravascular volume losses not associated with bleeding, such as extensive burn injury, diabetic ketoacidosis, profound diarrhea, sepsis, and acute pancreatitis. A key concern in these patients is to provide the right amount of fluid resuscitation.Insufficient resuscitation leads to inadequate organ perfusion, organ dysfunction and delayed recovery. Excessive resuscitation leads to worsening of acute lung injury, delayed separation from mechanical ventilation, poor healing, and nutrient malabsorption. Current means to determine adequacy of resuscitation include the restoration of blood pressure, normalization of the heart rate, clearance of lactate. For a small group of particularly astute clinicians, imperfect metrics of fluid responsiveness such as pulse pressure variation, pulse variability index, and negative passive leg raising testing can also assist in determining adequacy of fluid resuscitation, but not excessive resuscitation. The technology could be useful in determining, in a dynamic fashion, the sweet spot for resuscitation.

[0040] Some patients present with hypotension which is unrelated to intravascular fluid loss, but rather to an alteration of arterial tone. Sepsis is a combination of altered arterial tone and fluid loss. Medication effect and relative adrenal insufficiency represent two other sets of circumstances where the technology would indicate a different pattern of physiological compensation. A late indicator of insufficient arterial tone is the presence of a low diastolic blood pressure, but the technology has the ability to capture earlier patterns of decreased arterial tone.

[0041] Fig. 1 shows an example of an overall system 100 design and data flow between various modules to monitor patient’s clinical and physiological signals and provide real-time risk assessment and recommendations to physicians.

[0042] The system 100 may provide either or both a general risk score for risk of ongoing or future bleeding event and particular risk scores for bleeding related outcomes, need of interventions or subtypes of bleeding. The general risk score can use the combination of the aforementioned categories. While the subtype risk score can include one or multiple categories. Bleeding related outcomes may be defined by bleeding over a predefined threshold. For example, in maternal patients bleeding may be defined as blood loss of 500cc for vaginal birth or lOOOcc for cesarean births measured using either estimated blood loss or quantitative blood loss. In addition, clinical outcomes may include future hypotensive shock, hemorrhagic shock, sepsis shock, and / or organ failure due to bleeding. Future bleeding related interventions may include blood transfusion either any volume of blood transfusion or a minimum of certain units which may be defined based on patient context and settings, use of cell savage device, or other bleeding stoppage interventions such as use of tourniquet, Thoracotomy, Craniotomy, laparotomy, fasciotomy, medication intervention (i.e.Oxytocin for maternal population), uterine packing (plain gauze or gauze soaked withvasopressin, chitosan, or carboprost [Hemabate]), artery ligation, uterine artery embolization, B-lynch compression sutures, and balloon tamponade. Hysterectomy, use of negative pressure devices (i.e. jada system). In addition, future blood related outcomes may be defined as escalation of care due to hemorrhage such as transfer to intensive care unit and operating room. Other clinical measures (ongoing or future) may include future observable bleeding, change in vital signs, change in lab results (drop in hemoglobin levels).

[0043] The input clinical modalities 102 that the system can use as input to the analytics system can include low-frequency medical records (e.g., as stored in a data storage 104) and high frequency physiological signals (e.g., as collected by monitoring devices 106 such as biosensor patches and other patient monitors). Low frequency time series data can include patient’s medical records or electronic medical records (EMR - also referred to as Electronic Health Records (EHR)). EMR data elements can include, for example, one or more of: medical history, medical risk factors, demographics, time related information including but not limited to admission time, length of stay, location, length of labor, etc. Other medical records data can include care related data such as lab results (i.e. hemoglobin, WBC, etc.), vital signs (temperature, weight, blood pressure data, heart rate, etc.), patient care progression information such as progression of labor, recovery status from surgery. The second modality of data can include one or multiple high frequency waveform signals that monitor a patient's cardiovascular activity or blood flow such as an electrocardiogram (ECG or EKG) that records the electrical signal from the heart to check for different heart conditions. Photoplethysmography (PPG) is a simple optical technique used to detect volumetric changes in blood in peripheral circulation or Speckle Plethysmography (SPG), an optical signal that measures changes in blood flow usinglaser speckle imaging. Existence of both data modalities allows the machine learning models to learn and capture the relationship between a patient's physiological stability and their medical background, current conditions and interventions. For instance, in absence of EMR data, the models may interpret temporal stability in a patient's waveform as a sign of reduced risk while the temporal stability might have been induced due to administration of vasopressor medications. However, if both modalities are available the model can learn this relationship and consider that in the final output score preventing false negative predictions.

[0044] Training the machine-learning models in generating predictions and recommendations allow for personalization of predictions that can provide significant advantages over generic predictions for larger patient populations. For example, loss of a certain volume of blood may have different clinical significance for two individuals. Specifically, the same amount of blood loss can have no significant effect on one individual while being catastrophic on another (e.g., due to particular combination of health conditions). The technology described herein accounts for such individual conditions, thereby providing predictions and / or recommendations that are clinically more relevant than those generated for larger patient populations.

[0045] The patient’s data modalities can be stored in a datastore (or data structure) that can maintain both high frequency and low frequency data. If needed, the data can be processed to be stored in standard coding terminology such as RxNorm which is a standard coding terminology for medication as part of the Unified Medical Language System (UMLS). In addition, other preprocessing techniques can be adopted to clean the data by removing error values (e.g. NaN which represents Not a Number), unify units (Celsius vs Fahrenheit) and convert time zones. The data construct 112 itself can be stored either on file or a database software. If a databasesoftware is chosen, the database software may include relational databases (e.g. MySQL, PostgreSQL, TimeScaleDB, etc.) or non-relational software (Cassandra, MongoDB, InfluxDB, etc.) or Data Lake houses technologies (Iceberg). Either way, data construct 112 can provide functionality and APIs that allow reading all modalities of patient’s data completely or for specific time-span which can be used for the analytics engine 114 to consume the data and prepare for consumption by the machine learning models. In some implementations, the machine learning model can be disposed within, or in communication with, the analytics engine. The time interval in which the data can be read for consumption by machine learning models can be fine-tuned by model design and compute resource availability. For example, to predict a patient's risk of bleeding at a particular time, the model may use all past EMR data from the time of admission and historical data while only reading (e.g.,) a maximum of one hour of high-frequency waveforms.

[0046] Real-time monitoring of patient’s medical records can take place by monitoring their EMRs that are commonly stored using adopted softwares by the hospitals which may be deployed in either on-premise information technology (IT) infrastructure (local network) or on public cloud infrastructure. Either way, the integration with the EMR system can be done using multiple methods by an EMR integration module 110. First, the integration can be done using direct database access using standard Extract, transform, and load (ETL) processes. Alternatively, data can be accessed through standard hospital IT protocols such as Fast Healthcare Interoperability Resources (FHIR) or Health Level Seven or HL7 is a range of global standards for the transfer of clinical and administrative health data between applications or any other web-based or HTTP -based SOAP-based, Restful, or remote procedure call methods, or through data dumps that use any of the formats includingJSON, text, BSON. In order to track patient’s data in real-time, the EMR database can be queried periodically to obtain newly stored data since the last query time. An overlap time can be used to mitigate for past missing patient data or delays in the database synchronization and ensure data capture consistency. Alternatively, the patient's data can be pushed to a separate process which monitor's new data and pushes that information to a target database which can be part of the datastore or can be using standard Application Programming Interface (APIs) to store the data into the structure.

[0047] The high-frequency waveform signals (ECG, PPG, SPG, etc.) can be collected from either traditional continuous patient monitoring devices (e.g. Philips’s IntelliVue series) or patch based biosensor devices (e.g. LifeSignals, VitalPatch RTM, etc.). Real-time monitoring of high-frequency waveform data can take place through multiple methods. First it can be achieved by integration with a back-end database that stores the signals in real-time. In this approach, the monitor device company offers the means of synchronizing the individual device data into a backend data storage system accessible through the web. Therefore, similar to EMR integration, the real-time data feed can rely either on direct periodic queries to the back-end database system (relational or non-relational database) using the native database language or through vendor specific APIs calls. However, when such existing integrations are not provided by the device manufacturer, integration can happen through locally stored data integration liaison modules such as a signal integration module 108. In some implementations, the signal integration module 108 can integrate with the monitoring devices 106 directly, for example, through wired or wireless communication. The signal integration module 108 can push the retrieved data in real-time to the cloudbased data construct module 112, for example, through a wide-area network (WAN).When wired integration is expected, the connection can be established to the analytics server using either a standard port or an appropriate extension for converting the monitor device’s port to a standard port such as USB 2, or USB 3 and ethemet. Wireless integration can be done through standard wireless signals such as ones conforming to protocols such as Bluetooth® Wifi - IEEE 802.11. . In some implementations, physiologic signal data may be transmitted as digital or analog data streams, the latter being transduced to digital format after receipt by the system.

[0048] The analytics engine 114 can include, or communicate with, a machine learning engine 115 shown in Fig. 2. Specifically, Fig. 2 illustrates an example model 115 that uses two data modalities - ECG signal data and EMR data. The machine learning model 115 can include two modules, that can be implemented, for example, separately as two independent models or simultaneously as different layers of the same machine learning model architecture. The machine learning model 115 shown in Fig.2 includes a representation learning layer 200 that obtains a dense 202 or sparse 204 representation of available patient data (e.g., a dense representation of biosensor data and EMR data, a sparse representation of biosensor data and EMR data, and / or combinations thereof) and encodes the temporal and non-temporal patterns existing in the available modalities of the data into one or more feature vectors 206. and the machine learning architecture also includes a prediction layer 208 that analyzes the one or more feature vectors to output the final risk prediction for future or ongoing bleeding outcomes.

[0049] The feature vector 206 can be obtained using various techniques, such as feature template techniques, automated feature learning techniques, or a combination of the two. Feature template techniques utilize a window based mechanism to summarize the available data in that window into one single featurevalue. Multiple template-based feature learning techniques can be utilized including 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, skewness methods, root mean square of signal, spectral analysis, wavelet absolute mean, wavelet energy, wavelet entropy, wavelet standard deviation, wavelet variance, etc. The statistical template features can be computed either directly from the raw signal or it can be calculated from a secondary lower frequency signal derived from the raw waveform signal. Derived signals include R-R internal, R amplitudes, R wave peaks, Signal Quality Index from each ECG beats and Heart Rate Variability Features over a sliding window from ECG and Signal Quality Index, amplitudes, acceleration, slope, energy and pleth variability index from each PPG beats. A secondary level of feature extraction can happen by reapplying statistical methods over the first layer of feature by using a sliding window technique across the input data and calculating the primary template based feature for each sliding window. The feature vector is obtained by concatenating either all primary template based features or the secondary level features of sliding windows into one dense vector and various lower dimension techniques including principal component analysis, matrix factorization, discriminant analysis, feature selection and elimination techniques can be utilized to learn a more computationally management version of the feature vector. The feature vectors 206 can also be obtained using various automated feature representation learning techniques that utilize one or more neural network layers to summarize raw data into the feature vectors 206. Examples of such neural network layers include recurrent neural network layers, convolutional neural network layers, attention layers,transformer layers, fully connected layers, pooling layers, normalization layers, activation layers, feedforward neural network layers, autoencoders, etc.

[0050] In some implementations, the prediction layer 208 can include one or more machine learning techniques that analyze the vector representation to patient’s output of the risk of future or ongoing bleeding related outcome either in a fixed in the future window defined from the current time or after admission to the hospital or for the entirety of patient hospitalization. The prediction layer 208 can use various machine learning techniques such as regression models, support vector machines, bayesian models, decision tree based models, clustering techniques, nearest neighbor methods, and neural network approaches. When multiple machine learning techniques are utilized, various ensemble methods can be adopted to combine such scores to a single predicted risk score. Ensemble approaches may include but are not limited to such as bagging, voting, boosting, tree based ensembles, neural network based ensembles. To output the general risk of ongoing or future bleeding outcomes or the risk of particular subtypes, either separate machine learning models can be adopted for each risk score or a single multi-label machine learning model can be utilized that outputs all scores simultaneously.

[0051] Referring back to Fig. 1, the recommendation engine 116 can utilize patient risk scores and raw clinical data to generate alerts and recommendations (also referred to as prompts) for the medical teams. In some implementations, the Pprompts can be triggered according to a set of apriori rules which can be activated if multiple conditions are met. Rules can be defined by the users by defining conditions on the values and changes in the values of either certain patient clinical data or bleeding risk scores and can be stored in the module. The recommendation engine 116 can also allow users to delete, update or add new rules as needed either before, during or afterpatient care as deemed justified by the user. These rules could reflect the state of available resources, threats, or probability of evacuation. The recommendation engine 116 can generate appropriate prompts and store such prompts in the database. In some implementations, the recommendation engine 116 can send the notifications though an alerting module 120, for example, using one or more APIs associated with the alerting module 120.

[0052] This integration of operational data can help a clinician make appropriate decisions. In some implementations, the alerting module 120 can utilize API functionality provided by the UI engine 118 to generate appropriate alerts based on prompts generated and communicated from the recommendation engine 116. The generated alerts can be displayed, or example, on a patient risk dashboard, EMR software or other patient monitoring dashboards such as those used in a central monitoring / nursing unit. In some implementations, the alerting module 120 and / or the recommendation engine 116 can display alerts on a screen associated with an EMR repository 128, or communicate the alerts through a mobile integration engine 122 as text messages, email messages, paging messages, etc. In some implementations, the alerts can be delivered to a hospital mobile platform 130 provided by HIPAA compliant vendors (e.g. Voalte, Vocera). The generated alerts can be configured to describe or indicate patient conditions and risk status along with recommended actions (prompts) and the status of such actions. In order to provide a unified API used by the alerting module 120 to send new prompts to various mobile platforms, a mobile integration engine 122 can be utilized. In some implementations, the mobile integration engine 122 can provide a unified API specification that can be utilized by the alerting module 120. Upon use of the API functionality, the mobile integration module 122 can translate calls and messages received from the alerting module 120 tovendor specific APIs calls and messaging protocols provided by various mobile platforms and messaging applications to facilitate a hospital, vendor and workflow independent solutions.

[0053] The system can include an UI engine 118 that can monitor the data and risk scores generated and stored by the analytics engine 114 to render and display a risk dashboard that presents updated risk profiles / scores for a patient, potentially in real time. The risk dashboard can be displayed, for example, on a standalone display or a display integrated with EMR software. The patient risk dashboard can include, for example, a patient risk panel that provides the risk scores or risk stratifications. This interface is designed for simple and unambiguous interpretation using color based risk categories and clear decision support statements. The risk dashboard can also be accompanied with a list of recommended actions generated and stored by the alert and recommendation module. In some implementations, the risk dashboard can include a detailed risk view panel that displays the dynamic risk values for a particular bleeding outcomes subtypes or general outcome over time. 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 demonstrate predicted risk scores values for the selected risk outcome over time along side of related recommended actions to the specific outcome if available. The UI engine 118 may display color coding for clarification. The color palette can be defined according to the risk stratification groups, (i.e. high:red, medium: yellow, low: green, black for expectant / non survivable or standard screen color). The user interface can be displayed and accessed, for example, on a standalone web interface 124 or an embedded interface 126 associated with hospital EMR software. The embedded interface can be provided, for example, through Substitutable Medical Applications,Reusable Technologies (SMART) or Fast Healthcare Interoperability resource (FHIR) app API and protocols or other alternative standardized or vendor specific integration protocols offered by specific EMR vendor providers utilized in the expected health settings.

[0054] Fig. 3 is a flow diagram of an example process 300 for applying rule bases recommendations in accordance to patient context and risk. In some implementations, the rule-based recommendations can be activated according to conditions based on the patient's risk and clinical data and can generate prompts that can be converted to alerts by the alerting module 120. The alerts can be displayed, for example, in the patient’s risk dashboard and hospital EMR and it can be communicated through various mobile communication platforms through an appropriate module. The recommendation engine 116 can check if prompt rule conditions are activated (300). If the prompt rule conditions are activated, the recommendation engine 116 can store recommendation(s) in a database and notify the alerting engine (302). The alerting module 120 can generate an alert according to patient conditions, risk and recommended action (304). The mobile communications module 122 can communicate with active mobile platforms to translate the alert appropriately (306).

[0055] Fig. 4 is a system diagram illustrating a signal integration module 108a when vendor-specific cloud integration solutions are available. The signal integration module 108a can be configured to obtain information from the monitoring devices 106 for example, through a direct database query or API call. The signal integration module 108a can include network interface and / or middleware features to receive data from different types of monitoring devices 106 and convert the received data to acommon format and / or perform other operation to allow for heterogenous data to be received and operated on.

[0056] Fig. 5 is a system diagram 500 for a signal integration module 108b when vendor specific cloud integration solutions are not available. In such cases, information from the monitoring devices 106 can be provided to the signal integration module 108b, for example, through a signal liaison module 502. The signal liaison module 502 can include one or more hardware, software, and / or firmware component to provide network connectivity to monitoring devices 106 that do not have native network connectivity. Example components of signal liaison module 502 can include, but are not limited to, network routers, network switches, firewalls, proxies, and caches.

[0057] Figs 6 and 7 demonstrate the UI designs 600 and 700 for the patient’s risk dashboard for an example patient for evaluating and examining model recommendations and risk predictions.

[0058] UI 600 can be displayed as part of a dedicated application interface, web page, or device interface. The UI 600 can include a maternal hemorrhage window 602 and other windows such as a hypertension window 604. In the maternal hemorrhage window 602, a risk score 606 as described herein can be displayed. In addition, the window 602 can optionally display other scores such as a California Maternal Quality Care Collaborative (CMQCC) score 608. The maternal hemorrhage window can include a recommended actions sub-window 610. The recommended actions sub-window 610 can display one or more recommended action selected based on, for example, the risk score 606.

[0059] UI 700 can be displayed as part of a dedicated application interface, web page, or device interface. The UI 700 can include a hemorrhage risk scorewindow 702. The hemorrhage risk score window 702 can include a risk score 704. In addition, the hemorrhage risk score window 702 can optionally display other scores such as a CMQCC) score 706. The hemorrhage risk score window 702 can include a time sub-window 708 showing how the risk score 706 changes over time. For example, the time sub-window 708 can show how the risk score 706 has changed over a preceding period of time. For example, the time sub-window 708 can show how the risk score 706 is predicted to change over an upcoming period of time.

[0060] Fig. 8 shows an examples of alerts 800 and 802 communicated in a mobile platform 804.

[0061] The alert 800 can be displayed as part of a dedicated application interface, web page, or device interface

[0062] Fig. 9 shows a swimlane diagram of an example process 900 for predicting maternal hemorrhage and associated interventions. In this example, one or more biosensors 902 can be worn or otherwise used by a subject (e.g., a patient such as a pregnant, delivering, or postpartum woman). Example biosensors 902 can include, but are not limited to i) electrocardiogram (ECG) sensors; ii) photoplethysmogram (PPG) sensors, and iii) speckle plethysmography (SPG) sensors such as the patient monitor(s) described with respect to Fig. 1. In this example, the EMR datastore 904 can include on or more databases or other data storage systems hosted by one or more computing devices described above such as the EMR Data Storage described with respect to Fig. 1. The risk system can include one or more computing systems with processors, memory, and other appropriate hardware such as the computing systems described with respect to Fig. 1. In this example, the recommendation interface 908 can include one or more computing systems with processors, memory, and other appropriate hardware such as the phone devicedescribed with respect to Fig. 8. In this example, the automation device 910 can include one or more computing systems with processors, memory, and other appropriate hardware such as the computing device 1100 described with respect to Fig. 11.

[0063] The EMR datastore 904 can maintain EMR data 912. For example, the EMR datastore 904 can receive, store, update, and serve EMR data, including EMR records, to various systems within a computing environment. The EMR datastore 904 can index the EMR records by patient identifier, provider identifier, etc. as appropriate. As a particular patient interacts with a healthcare system, various procedures and events can create new records for their EMRs, and as such the EMR database can receive data for these various procedures and events and create corresponding updates to the EMR records for the particular patient.

[0064] The EMR datastore 904 can transmit the EMR data 914. The risk system 906 can receive the EMR data for the subject 916. The risk system 906 may operate with the EMR datastore 904 to make all or a permitted subset of the patient’s EMR records available to the risk system 906. As will be appreciated, various schemes for patient data protection, confidentiality, etc. can be instituted by the risk system and the EMR datastore 904 to protect the patient.

[0065] The biosensors 902 can sense a phenomena of a subject 918. For example, the biosensors 902 can be worn by the patient is various settings.Depending on the particular types and configurations of the biosensors 902, the biosensors 902 can be worn while in a clinical environment, at home while the patient is pregnant, at home after a patient gives birth or otherwise undergoes an event where a risk of hemorrhage is possible. This example discusses maternal hemorrhage - sometimes referred to as postpartum hemorrhage - but it will be appreciated that othertypes of hemorrhage or outcome can be monitored for, including those not related to pregnancy or birth and those not specific to women etc.

[0066] The biosensors 902 can transmit, to a computing system, a biosensor data based on the sensing of the phenomena 920. The risk management system 906 can receive the biosensor data 922. For example, the biosensors 902 can report readings to a controller or computer. Depending on the types of biosensors 902, this may be across a local, wired data link, across a WiFi, BLUETOOTH, or other wireless datalink, etc. These readings can be transmitted to the risk system 906 over one or more appropriate datalink. For example, for a patient in a hospital, the biosensor may be connected via a wired interface to the risk system 906, while a patient in a home setting may have the same or different biosensor connected via datalink over the Internet or similar wide-area network.

[0067] The risk system 906 can identify, using the EMR data, one or more records to be used in determining a susceptibility -rating for the subject to characterize a susceptibility of the subject to maternal hemorrhaging 924. For example, using one or more data engines, the risk system 906 can search for and identify a subset of all available EMR records for the patient that match rules defining the types of records that can be used in the process 900, while discarding records that do not match the rules (e.g., records expected to have little or no impact on maternal hemorrhage such as records of childhood dental cleanings). As described above, this process may involve the use of one or more machine-learning models, although non-machine- leaming techniques may also be used.

[0068] The risk system 906 can receive an update for the subject based at least on one of the group comprising i) the biosensor data; and ii) a change to the EMR data 926. For example, as the patient receives treatment, records for those treatmentevents can be added to their EMR data. Existing conditions may change in intensity, and / or new conditions may be added to their EMR data. Similarly, when the biosensors 902 are worn, their readings - and analysis from those readings - may be added to the patients EMR data. For example, raw readings of a PPG sensor may be added. In addition or in the alternative, human or automated analysis or tagging of the PPG sensor readings can be added to the patients EMR data.

[0069] As such, the risk system 906 can receive the updates in various ways. For example, the risk system 906 can utilize a software ‘listener’ to listen for the changes in the EMR data that have been created by another system. For example, the risk system 906 can continuously monitor data streams of the biosensor data responsive to receipt of the data streams to identify new data points (new trends, continuations of existing trends, etc.) In various example, the update for the subject can include any or all of i) a blood test result, ii) administration of a medication, iii) a cervix measurement, iv) a record of a fetal position, v) a record of a contemporaneous blood-loss event that occurs before pre-defined the time window, vi) a record of a trauma event, v) the use of forceps in delivery, vi) vital signs, vii) intake questionnaires, and viii) elapse time.

[0070] The risk system 906 can generate a maternal-hemorrhaging metric for the subject 928. For example, the maternal-hemorrhage metric can indicate if or that a maternal hemorrhage event is predicated to occur with a first time window, which can be pre-defined as the next N hours or minutes. As will be understood, the first time window can be personalized based on patient or clinical preference and can be pre-defined to match a time window of currently actionable information. For example, a patient at home may have a time window of 4 hours to allow time to travel to a clinic if there is a prediction of a problem, while the same patient may have ashorter time window of 1 or 0.5 hours while in a clinic where care can be provided much more quickly.

[0071] The risk system 906 can generate, using a machine learning model, a maternal hemorrhaging metric that indicates a likelihood of occurrence of a maternal hemorrhaging event within a first time window, wherein the machine learning model is configured using a corpus of training data comprising information on maternal hemorrhaging events and associated EMR data. For example, to determine the maternal-hemorrhage metric for the subject, the risk system 906 can provide, to a machine-learning model, at least some of the EMR data and the biosenser data. For example, the risk system 906 can supply the records identified 924 and / or from the received update 926 to the machine learning model as input parameters.

[0072] The machine-learning model can be a technologically-appropriate model or models as described in this document that has been trained on training data representative of hemodynamic instability related complications. For example, the training data may include historic EMR records for other subjects, and tagging data that tags the records with hemodynamic instability related complications - and other tags including a lack of hemodynamic instability related complications. As will be appreciated, the hemodynamic instability related complications may occur later than a timestamp in an EMR record, and as such the machine-learning model can be used by the risk system 906 on current (e.g., true real-time, or after a short delay due to computational and networking delay) EMR data and biosensor data for a subject to predict a likelihood or not of a hemodynamic instability related complications.

[0073] The risk system 906 can receive back, from the machine-learning model, a maternal-hemorrhage metric indicating that a maternal hemorrhage event i) is predicted to occur within a first time window for the subject and ii) can include anintervention within a second time window. The maternal-hemorrhaging metric may take various technologically-appropriate formats. In some examples, the maternal- hemorrhaging metric may be a simple text value that is human-readable (e.g., “low- risk,” “medium-risk,” and “high-risk.”) In some examples, the maternal- hemorrhaging metric may be a numeric value on a fixed scale (e.g., 0.0-0.1 or 1-5). Some of these numeric values can be linear risk or confidence values where a value of 0.50 indicates twice the risk or confidence of 0.25. Some of these numeric values can be monotonically-increasing that do not have a linear constraint (e.g., where a 0.50 indicates a higher risk than a 0.25, but does not indicate twice the risk.). Some of the maternal-hemorrhaging metrics representative of the probably or is correlated with the probability of a maternal-hemorrhage event. Some of the maternal-hemorrhaging metrics can be a numerical value, a probably or a discrete risk scale (e.g. 1- 10).

[0074] In some instances, the machine-learning model can post-process the maternal-hemorrhaging metrics or a portion of the maternal-hemorrhaging metrics (e.g., for a multi-field maternal-hemorrhaging metrics). For example, a monotonically-increasing discrete scale from 0-5 can be post processed to create discrete labels, with a value of 0 being assigned a label “no predicted event,” a value of 1 being assigned a label “low-risk,” values of 2-4 being assigned a label “mediumrisk,” and a value of 5 being assigned a label “high-risk.” As will be appreciated, the type of post-processing can be configured based on the native output of the machinelearning model, and the data requirements of other elements in a computational system.

[0075] In addition or in the alternative, a generalized risk of an event can be provided. This generalized risk determination can represent a risk that, at some unknown point in the future, the patient may experience the problem. As will beappreciated, while this generalized risk determination may have many uses, the immediate provision of specific interventions may in some cases be more possible only with the use of the time window.

[0076] The risk system 906 can generate a recommendation for a health-care provider to prepare to provide an intervention to the subject for the maternal- hemorrhaging event 930. The recommendation interface 908 can display the recommendation 932. For example, as described previously, the risk system 906 can generate one recommendations for intervention for the patient. Then, a recommendation interface 908 can display that for the health-care provider or other user. Some example messages are shown with respect to Figs 6-8 on various types of devices, though it will be appreciated that other types of recommendations and / or other types of devices can be used.

[0077] The risk system 906 can generate, using the maternal-hemorrhaging metric, a computer-readable instruction for an automation device; and cause the automation device to execute the computer-readable instruction to engage an automation action 934. The automation device 910 can execute the computer- readable instruction to engage an automation actionl036. For example, the risk system 907 may be configured to control home-automation or room-automation devices that can change the environment of the patient. In one example, heating or cooling in the patient’s room can be engaged to increase or decrease ambient temperature as appropriate. In another example, automated medication dispensers can be engaged to prepare a medication for a clinician to retrieve for the patient if they deem it appropriate. In such a situation, the clinician may be able to provide their interventions faster because they do not need to wait for a prescription that is preallocated and awaiting their retrieval. In some cases, the computer-readableinstructions can modify the operation of one of the elements of the system that performs part of the process 900. For example, in response to determining that a hemorrhage event is predicted, the risk system 906 can instruct the biosensors 902 to increase the frequency or sensitivity of their sensing, etc.

[0078] Fig. 10 shows a swimlane diagram of an example process 1000 for predicting maternal hemorrhage and associated interventions. In this example, one or more biosensors 1002 can be worn or otherwise used by a subject (e.g., a patient such as a pregnant, delivering, or postpartum woman). Example biosensors 1002 can include, but are not limited to i) electrocardiogram (ECG) sensors; ii) photoplethysmogram (PPG) sensors, and iii) speckle plethysmography (SPG) sensors such as the patient monitor(s) described with respect to Fig. 1. In this example, the EMR datastore 1004 can include on or more databases or other data storage systems hosted by one or more computing devices described above such as the EMR Data Storage described with respect to Fig. 1. The risk system can include one or more computing systems with processors, memory, and other appropriate hardware such as the computing systems described with respect to Fig. 1. In this example, the recommendation interface 1008 can include one or more computing systems with processors, memory, and other appropriate hardware such as the phone device described with respect to Fig. 8. In this example, the automation device 1010 can include one or more computing systems with processors, memory, and other appropriate hardware such as the computing device 1100 described with respect to Fig. 11.

[0079] The EMR datastore 1004 can maintain EMR data 1012. For example, the EMR datastore 1004 can receive, store, update, and serve EMR data, including EMR records, to various systems within a computing environment. The EMRdatastore 1004 can index the EMR records by patient identifier, provider identifier, etc. as appropriate. As a particular patient interacts with a healthcare system, various procedures and events can create new records for their EMRs, and as such the EMR database can receive data for these various procedures and events and create corresponding updates to the EMR records for the particular patient.

[0080] The biosensors 1002 can sense a phenomena of a subject 1014. For example, the biosensors 1002 can be worn by the patient is various settings. Depending on the particular types and configurations of the biosensors 1002, the biosensors 1002 can be worn while in a clinical environment, at home while the patient is pregnant, at home after a patient gives birth or otherwise undergoes an event where a risk of hemorrhage is possible. This example discusses maternal hemorrhage - sometimes referred to as postpartum hemorrhage - but it will be appreciated that other types of hemorrhage or outcome can be monitored for, including those not related to pregnancy or birth and those not specific to women etc.

[0081] The biosensors 1002 can transmit, to the EMR datastore 1004, a biosensor data based on the sensing of the phenomena 1016. The EMR datastore 1004 can receive the biosensor data 1018. For example, the biosensors 1002 can report readings to a controller or computer. Depending on the types of biosensors 1002, this may be across a local, wired data link, across a WiFi, BLUETOOTH, or other wireless datalink, etc. These readings can be transmitted to the EMR datastore 1004 over one or more appropriate datalink. For example, for a patient in a hospital, the biosensor may be connected via a wired interface to the EMR datastore 1004, while a patient in a home setting may have the same or different biosensor connected via datalink over the Internet or similar wide-area network. The EMR datastore 1004 can then update the maintained EMR data based on the received biosensor data 1016.

[0082] The EMR datastore 1004 can transmit the EMR data 1020. The risk system 1006 can receive the EMR data for the subject 1022. he risk system 1006 may operate with the EMR datastore 1004 to make all or a permitted subset of the patient’s EMR records available to the risk system 1006. As will be appreciated, various schemes for patient data protection, confidentiality, etc. can be instituted by the risk system and the EMR datastore 1004 to protect the patient.

[0083] The risk system 1006 can identify, using the EMR data, one or more records to be used in determining a susceptibility-rating for the subject to characterize a susceptibility of the subject to maternal hemorrhaging 1024. For example, using one or more data engines, the risk system 1006 can search for and identify a subset of all available EMR records for the patient that match rules defining the types of records that can be used in the process 1000, while discarding records that do not match the rules (e.g., records expected to have little or no impact on maternal hemorrhage such as records of childhood dental cleanings). As described above, this process may involve the use of one or more machine-learning models, although non- machine-leaming techniques may also be used.

[0084] The risk system 1006 can receive an update for the subject based at least on one of the group comprising i) the biosensor data; and ii) a change to the EMR data 1026. For example, as the patient receives treatment, records for those treatment events can be added to their EMR data. Existing conditions may change in intensity, and / or new conditions may be added to their EMR data. Similarly, when the biosensors 1002 are worn, their readings - and analysis from those readings - may be added to the patients EMR data. For example, raw readings of a PPG sensor may be added. In addition or in the alternative, human or automated analysis or tagging of the PPG sensor readings can be added to the patients EMR data.

[0085] As such, the risk system 1006 can receive the updates in various ways. For example, the risk system 1006 can utilize a software ‘listener’ to listen for the changes in the EMR data that have been created by another system. For example, the risk system 1006 can continuously monitor data streams of the biosensor data responsive to receipt of the data streams to identify new data points (new trends, continuations of existing trends, etc.) In various example, the update for the subject can include any or all of i) a blood test result, ii) administration of a medication, iii) a cervix measurement, iv) a record of a fetal position, v) a record of a contemporaneous blood-loss event that occurs before pre-defined the time window, vi) a record of a trauma event, and v) the use of forceps in delivery.

[0086] The risk system 1006 can generate a maternal-hemorrhaging metric for the subject 1028. For example, the maternal -hemorrhage metric can indicate if or that a maternal hemorrhage event is predicated to occur with a first time window, which can be pre-defined as the next N hours or minutes. As will be understood, the first time window can be personalized based on patient or clinical preference and can be pre-defined to match a time window of currently actionable information. For example, a patient at home may have a time window of 4 hours to allow time to travel to a clinic if there is a prediction of a problem, while the same patient may have a shorter time window of 1 or 0.5 hours while in a clinic where care can be provided much more quickly.

[0087] The risk system 1006 can generate, using a machine learning model, a maternal hemorrhaging metric that indicates a likelihood of occurrence of a maternal hemorrhaging event within a first time window, wherein the machine learning model is configured using a corpus of training data comprising information on maternal hemorrhaging events and associated EMR data. For example, to determine thematernal-hemorrhage metric for the subject, the risk system 1006 can provide, to a machine-learning model, at least some of the EMR data and the biosenser data. For example, the risk system 1006 can supply the records identified 1024 and / or from the received update 1026 to the machine learning model as input parameters.

[0088] The machine-learning model can be a technologically-appropriate model or models as described in this document that has been trained on training data representative of hemodynamic instability related complications. For example, the training data may include historic EMR records for other subjects, and tagging data that tags the records with hemodynamic instability related complications - and other tags including a lack of hemodynamic instability related complications. As will be appreciated, the hemodynamic instability related complications may occur later than a timestamp in an EMR record, and as such the machine-learning model can be used by the risk system 1006 on current (e.g., true real-time, or after a short delay due to computational and networking delay) EMR data and biosensor data for a subject to predict a likelihood or not of a hemodynamic instability related complications.

[0089] The risk system 1006 can receive back, from the machine-learning model, a maternal-hemorrhage metric indicating that a maternal hemorrhage event i) is predicted to occur within a first time window for the subject and ii) can include an intervention within a second time window. The maternal-hemorrhaging metric may take various technologically-appropriate formats. In some examples, the maternal- hemorrhaging metric may be a simple text value that is human-readable (e.g., “low- risk,” “medium-risk,” and “high-risk.”) In some examples, the maternal- hemorrhaging metric may be a numeric value on a fixed scale (e.g., 0.0-0.1 or 1-5). Some of these numeric values can be linear risk or confidence values where a value of 0.50 indicates twice the risk or confidence of 0.25. Some of these numeric values canbe monotonically-increasing that do not have a linear constraint (e.g., where a 0.50 indicates a higher risk than a 0.25, but does not indicate twice the risk.). Some of the maternal-hemorrhaging metrics representative of the probably or is correlated with the probability of a maternal-hemorrhage event. Some of the maternal-hemorrhaging metrics can be a numerical value, a probably or a discrete risk scale (e.g. 1- 10).

[0090] In some implementations, the first time window and / or the second time window can be configurable. For example, the first time window can be configured to provide predictions that are not too distant in the future - such that the predictions are likely to change as updated data becomes available. For example, the first time window can be configured to predict the risk of hemorrhaging events that is within a threshold time, e.g., 15 minutes, 30 minutes, 45 minutes, 1 hour, or 2 hours from a given time point. The second time window can be configured such that at least a portion of the second time window precedes the first time window such that a preemptive action can be taken in light of the event predicted for the first time window. In some implementations, the second time-window can be configurable based on user-preferences (e.g., based on a clinician’s choice). Some clinicians may not want to adhere to the provided recommendations if the recommendations are related to a predicted event more than a threshold distance into the future, and / or if the recommendations are provided more than a threshold time before a predicted event. As such, the first time window and / or the second time window can be configured based on user-preferences to increase the likelihood of the user adhering to the provided recommendations - which in turn can contribute to potentially favorable medical outcomes.

[0091] In some instances, the machine-learning model can post-process the maternal-hemorrhaging metrics or a portion of the maternal-hemorrhaging metrics(e.g., for a multi-field maternal-hemorrhaging metrics). For example, a monotonically-increasing discrete scale from 0-5 can be post processed to create discrete labels, with a value of 0 being assigned a label “no predicted event,” a value of 1 being assigned a label “low-risk,” values of 2-4 being assigned a label “mediumrisk,” and a value of 5 being assigned a label “high-risk.” As will be appreciated, the type of post-processing can be configured based on the native output of the machinelearning model, and the data requirements of other elements in a computational system.

[0092] In addition or in the alternative, a generalized risk of an event can be provided. This generalized risk determination can represent a risk that, at some unknown point in the future, the patient may experience the problem. As will be appreciated, while this generalized risk determination may have many uses, the immediate provision of specific interventions may in some cases be more possible only with the use of the time window.

[0093] The risk system 1006 can generate a recommendation for a health-care provider to prepare to provide an intervention to the subject for the maternal- hemorrhaging event 1030. The recommendation interface 1008 can display the recommendation 1032. For example, as described previously, the risk system 1006 can generate one recommendations for intervention for the patient. Then, a recommendation interface 1008 can display that for the health-care provider or other user. Some example messages are shown with respect to Figs 6-8 on various types of devices, though it will be appreciated that other types of recommendations and / or other types of devices can be used.

[0094] The risk system 1006 can generate, using the maternal -hemorrhaging metric, a computer-readable instruction for an automation device; and cause theautomation device to execute the computer-readable instruction to engage an automation action 1034. The automation device 1010 can execute the computer- readable instruction to engage an automation actionl036. For example, the risk system 1007 may be configured to control home-automation or room-automation devices that can change the environment of the patient. In one example, heating or cooling in the patient’s room can be engaged to increase or decrease ambient temperature as appropriate. In another example, automated medication dispensers can be engaged to prepare a medication for a clinician to retrieve for the patient if they deem it appropriate. In such a situation, the clinician may be able to provide their interventions faster because they do not need to wait for a prescription that is preallocated and awaiting their retrieval. In some cases, the computer-readable instructions can modify the operation of one of the elements of the system that performs part of the process 1000. For example, in response to determining that a hemorrhage event is predicted, the risk system 1006 can instruct the biosensors 1002 to increase the frequency or sensitivity of their sensing, etc.

[0095] Example embodiments include a method of identifying the risk of future bleeding or identifying levels of future bleeding comprising the steps: receiving and reviewing at least one of the raw ECG, PPG and SPG signals 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 Medical Record software, collected and extracted periodically in equal or irregular windows and during a period of time; cleaning the medical data from EMR by removing error prune records, converting units, converting variables, normalizing, and etc.; leaning the signal data using a signal cleaning method; feeding the physiological high-frequency signal data andelectronic medical records variables available at the time of assessment 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 both data modalities (high-frequency signal and EMR data) of the data into a vector representation; 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 which can either be a fixed window or it can represent the entirety of a patient’s hospital stay before discharge.

[0096] Example embodiments include a module that can access the stored risk predictions and the stored recommendations to visualize the stored information on a web-based software access as an independent web portal on any machine including mobile devices, tablets, laptops, computers, monitors or as a part of an embedded interface within existing hospital softwares, compromising at least one of the following features; a risk panel that represents the most recent predicted risk score; a recommendation panel that considers the predicted risk, other patient clinical information and conditions collected in System 1 and standard workflows to provide a list of recommended actions for patient; A risk dashboard that allows clinicians to investigate related information that resulted in the existing risk predictions.

[0097] FIG. 11 shows an example of a computing device 1100 and an example of a mobile computing device that can be used to implement the techniques described here. The computing device 1100 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The mobile computing device is intended to represent various forms of mobile devices, such aspersonal digital assistants, cellular telephones, smart-phones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the technologys described and / or claimed in this document.

[0098] The computing device 1100 includes a processor 1102, a memory 1104, a storage device 1106, a high-speed interface 1108 connecting to the memory 1104 and multiple high-speed expansion ports 1110, and a low-speed interface 1112 connecting to a low-speed expansion port 1114 and the storage device 1106. Each of the processor 1102, the memory 1104, the storage device 1106, the high-speed interface 1108, the high-speed expansion ports 1110, and the low-speed interface 1112, are interconnected using various busses, and can be mounted on a common motherboard or in other manners as appropriate. The processor 1102 can process instructions for execution within the computing device 1100, including instructions stored in the memory 1104 or on the storage device 1106 to display graphical information for a GUI on an external input / output device, such as a display 1116 coupled to the high-speed interface 1108. 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 server bank, a group of blade servers, or a multi -processor system).

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

[0100] The storage device 1106 is capable of providing mass storage for the computing device 1100. In some implementations, the storage device 1106 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 memory device, 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 memory 1104, the storage device 1106, or memory on the processor 1102.

[0101] The high-speed interface 1108 manages bandwidth-intensive operations for the computing device 1100, while the low-speed interface 1112 manages lower bandwidth-intensive operations. Such allocation of functions is exemplary only. In some implementations, the high-speed interface 1108 is coupled to the memory 1104, the display 1116 (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports 1110, which can accept various expansion cards (not shown). In the implementation, the low-speed interface 1112 is coupled to the storage device 1106 and the low-speed expansion port 1114. The low- speed expansion port 1114, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) can be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

[0102] The computing device 1100 can be implemented in a number of different forms, as shown in the figure. For example, it can be implemented as astandard server 1120, or multiple times in a group of such servers. In addition, it can be implemented in a personal computer such as a laptop computer 1122. It can also be implemented as part of a rack server system 1124. Alternatively, components from the computing device 1100 can be combined with other components in a mobile device (not shown), such as a mobile computing device 1150. Each of such devices can contain one or more of the computing device 1100 and the mobile computing device 1150, and an entire system can be made up of multiple computing devices communicating with each other.

[0103] The mobile computing device 1150 includes a processor 1152, a memory 1164, an input / output device such as a display 1154, a communication interface 1166, and a transceiver 1168, among other components. The mobile computing device 1150 can also be provided with a storage device, such as a microdrive or other device, to provide additional storage. Each of the processor 1152, the memory 1164, the display 1154, the communication interface 1166, and the transceiver 1168, are interconnected using various buses, and several of the components can be mounted on a common motherboard or in other manners as appropriate.

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

[0105] The processor 1152 can communicate with a user through a control interface 1158 and a display interface 1156 coupled to the display 1154. The display 1154 can be, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display) display or an OLED (Organic Light Emitting Diode) display, or other appropriate display technology. The display interface 1156 can comprise appropriate circuitry for driving the display 1154 to present graphical and other information to a user. The control interface 1158 can receive commands from a user and convert them for submission to the processor 1152. In addition, an external interface 1162 can provide communication with the processor 1152, so as to enable near area communication of the mobile computing device 1150 with other devices. The external interface 1162 can provide, for example, for wired communication in some implementations, or for wireless communication in other implementations, and multiple interfaces can also be used.

[0106] The memory 1164 stores information within the mobile computing device 1150. The memory 1164 can be implemented as one or more of a computer- readable medium or media, a volatile memory unit or units, or a non-volatile memory unit or units. An expansion memory 1174 can also be provided and connected to the mobile computing device 1150 through an expansion interface 1172, which can include, for example, a SIMM (Single In Line Memory Module) card interface. The expansion memory 1174 can provide extra storage space for the mobile computing device 1150, or can also store applications or other information for the mobile computing device 1150. Specifically, the expansion memory 1174 can include instructions to carry out or supplement the processes described above, and can include secure information also. Thus, for example, the expansion memory 1174 can be provide as a security module for the mobile computing device 1150, and can beprogrammed with instructions that permit secure use of the mobile computing device 1150. 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.

[0107] 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 1164, the expansion memory 1174, or memory on the processor 1152. In some implementations, the computer program product can be received in a propagated signal, for example, over the transceiver 1168 or the external interface 1162.

[0108] The mobile computing device 1150 can communicate wirelessly through the communication interface 1166, which can include digital signal processing circuitry where necessary. The communication interface 1166 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 1168 using a radiofrequency. In addition, short-range communication can occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, a GPS (GlobalPositioning System) receiver module 1170 can provide additional navigation- and location-related wireless data to the mobile computing device 1150, which can be used as appropriate by applications running on the mobile computing device 1150.

[0109] The mobile computing device 1150 can also communicate audibly using an audio codec 1160, which can receive spoken information from a user and convert it to usable digital information. The audio codec 1160 can likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of the mobile computing device 1150. 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 1150.

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

[0111] 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, software, 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.

[0112] 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.

[0113] 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.

[0114] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systemsand techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0115] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0116] Example embodiments include a system for detecting risk of bleeding comprising: at least one server in communication with WAN or deployed either on local onsite network or on the cloud that is responsible for data collection and synchronization: receiving and storing raw high frequency signals from biosensor devices including ECG, PPG or SPG signals; collecting and storing data from electronic medical records(EMR) using direct integration, ETL, standard protocols and APIs including FHIR, HL7 or any other web based, or HTTP -based, SOAP- based, Restful, or remote procedure call methods, or through data dumps that use any of the formats including JSON, text, BSON; at least one data link system that redirects / push real-time collected data to other parts of the systems or allows pull access to the stored data by other modules; storing and synchronization of physiological signal data and EMR data in a unified data structured using either static file format or database softwares (relational and non-relational); a compute engine that either is on the same server or deployed on at least another server that receives data from the data struct (either push pull), preprocess the data, cleans data and finallyutilizes multimodal 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 utilizes pre-stored rules to generate real-time care recommendations: care recommendation rules can be using real-time risk predictions and other patient clinical data (e.g. blood pressure) to recommend time-sensitive actions; a module that utilizes a database system to store recommendation actions at each time based most recent patient bleeding risk scores.

[0117] A number of other possible embodiments are possible.

[0118] Embodiment 1. A system comprising: 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 comprising: receive at least one data stream of biosensor data; receive records of past medical events; submitting, to a medical-event classifier, the data stream of biosensor data and the records of past medical events, wherein the medical-event classifier is configured to operate with a model trained with training data comprising training biosensor data and training records; and receiving, from the medical-event classifier, a prediction record that comprises i) a prediction event and ii) a confidence value that the prediction event will occur in the future.

[0119] Embodiment 2. The system of Embodiment 1, wherein the operations further comprise: identifying an intervention based on stored data that identifies possible prediction events and corresponding interventions identified to address theprediction event; and sending a data message with the intervention to be applied to a subject that is monitored in the biosensor data.

[0120] Embodiment 3. The system of Embodiment 1, wherein the biosensor data comprises at least one of the group consisting of i) electrocardiogram (ECG) data; ii) photoplethysmogram (PPG) data, and iii) speckle plethysmography (SPG) data.

[0121] Embodiment 4. The system of Embodiment 1, wherein the biosensor data is collected using a body -worn patch by a subject that has undergone a medical procedure having a possible side effect of hemorrhage.

[0122] Embodiment 5. The system of Embodiment 1, wherein receiving the at least one data of biosensor data comprises processing raw data to perform at least one of the group consisting of i) altering a format of the data, and ii) removing anomalous data.

[0123] Embodiment 6. The system of Embodiment 1, wherein the medicalevent classifier is configured to operate with a model trained with training data comprising training biosensor data and training records, comprising: encoding the data stream of biosensor data and the records of past medical events into a inputvector in vector space; and operating on the input-vector to identify i) the prediction event and ii) the confidence value that the prediction event will occur in the future.

[0124] Embodiment 7. The system of Embodiment 1, wherein the operations further comprise provide a graphic user interface (GUI) configured to display the prediction event and one or more recommended interventions for the prediction event.

[0125] Embodiment 8. The system of Embodiment 7, wherein the GUI further comprises a risk score in a numeric format that identifies a severity of the risk.

[0126] Embodiment 9. The system of Embodiment 8, wherein the risk score is based on, and not the same as, the confidence value that the prediction event will occur in the future.

[0127] Embodiment 10. The system of Embodiment 8, wherein the risk score is the confidence value that the prediction event will occur in the future.

[0128] Embodiment 11. A system for detecting risk of bleeding comprising: at least one server in communication with WAN or deployed either on local onsite network or on the cloud that is responsible for data collection and synchronization: receiving and storing raw high frequency signals from biosensor devices including ECG, PPG or SPG signals; collecting and storing data from electronic health records (EMR) using direct integration, ETL, standard protocols and APIs including FHIR, HL7 or any other web based, or HTTP -based, SOAP -based, Restful, or remote procedure call methods, or through data dumps that use any of the formats including JSON, text, BSON; at least one data link system that redirects / push real-time collected data to other parts of the systems or allows pull access to the stored data by other modules; storing and synchronization of physiological signal data and EMR data in a unified data structured using either static file format or database softwares (relational and non-relational); a compute engine that either is on the same server or deployed on at least another server that receives data from the data struct (either push pull), preprocess the data, cleans data and finally utilizes multimodal 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 computinginfrastructure; a module that can access the stored risk predictions and utilizes prestored rules to generate real-time care recommendations: care recommendation rules can use real-time risk predictions and other patient clinical data (e.g. blood pressure) to recommend time-sensitive actions; and a module that utilizes a database system to store recommendation actions at each time based most recent patient bleeding risk scores

[0129] Embodiment 12. A method of identifying the risk of future bleeding or identifying levels of future bleeding comprising the steps: receiving and reviewing at least one of the raw ECG, PPG and SPG signals 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 Medical Record software, collected and extracted periodically in equal or irregular windows and during a period of time; cleaning the medical data from EMR by removing error prune records, converting units, converting variables, normalizing, and etc.; cleaning the signal data using a signal cleaning method; feeding the physiological high-frequency signal data and electronic medical records variables available at the time of assessment to the machine learning models and the artificial intelligence algorithms that can compute: a dense or sparse representation that encodes temporal and non-temporal patterns existing in the both data modalities (high-frequency signal and EMR data) 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 which can either be a fixed window or it can represent the entirety of a patient's hospital stay before discharge.

[0130] Embodiment 13. A module that can access the stored risk predictions and the stored recommendations to visualize the stored information on a web-based software access as an independent web portal on any machine including mobile devices, tablets, laptops, computers, monitors or as a part of an embedded interface within existing hospital softwares, compromising at least one of the following features: a risk panel that represents the most recent predicted risk score; a recommendation panel that considers the predicted risk, other patient clinical information and conditions collected in System 1 and standard workflows to provide a list of recommended actions for patient; and a risk dashboard that allows clinicians to investigate related information that resulted in the existing risk predictions.

[0131] Embodiment 14. A system that includes: a computer system comprising at least one processor and memory, the computer system configured to: receive biosensor data for a subject from one or more biosensors; receive Electronic Medical Record (EMR) data for the subject; receive an update for the subject based at least on one of: i) the biosensor data; or ii) a change to the EMR data; and responsive to receiving the update, generate, using a machine learning model, a hemorrhaging metric that indicates a likelihood of occurrence of a hemorrhaging event within a first time window, wherein the machine learning model is configured using a corpus of training data comprising information on hemorrhaging events and associated EMR data.

[0132] Embodiment 15. A method that includes: receiving biosensor data for a subject from one or more biosensors; receiving Electronic Medical Record (EMR) data for the subject; receive an update for the subject based at least on one of: i) the biosensor data;or ii) a change to the EMR data; and responsive to receiving the update, generate, using a machine learning model, a hemorrhaging metric that indicates a likelihood of occurrence of a hemorrhaging event within a first time window, wherein the machine learning model is configured using a corpus of training data comprising information on hemorrhaging events and associated EMR data.

Claims

WHAT IS CLAIMED IS:

1. A system comprising: a computer system comprising at least one processor and memory, the computer system configured to: receive biosensor data for a subject from one or more biosensors; receive Electronic Medical Record (EMR) data for the subject; receive an update for the subject based at least on one of: i) the biosensor data; or ii) a change to the EMR data; and responsive to receiving the update, generate, using a machine learning model, a maternal hemorrhaging metric that indicates a likelihood of occurrence of a maternal hemorrhaging event within a first time window, wherein the machine learning model is configured using a corpus of training data comprising information on maternal hemorrhaging events and associated EMR data.

2. The system of claim 1, wherein the computer system is further configured to, responsive to generating the maternal-hemorrhaging metric: generate a recommendation for an intervention within a second time window.

3. The system of claim 1, wherein the computer system is further configured to, responsive to generating the maternal-hemorrhaging metric: generate based on the maternal-hemorrhaging metric , computer- readable instructions configured to cause a device to execute one or more automated actions.

4. The system of claim 1, wherein the system further comprises the one or more biosensors, the one or more biosensors each configured to: sense a phenomena of the subject; and transmit, to the computing system, the biosensor data based on the sensing of the phenomena.

5. The system of claim 1, wherein: the biosensor data comprises at least one of the group consisting of i) electrocardiogram (ECG) data; ii) photoplethysmogram (PPG) data, and iii) speckle plethysmography (SPG) data; the EMR data comprises a record of at least one of the group consisting of i) a history of bleeding, and ii) a number of previous births; and the update for the subject comprises at least one of the group consisting of i) a blood test result, ii) administration of a medication, iii) a cervix measurement, iv) a record of a fetal position, v) a record of a contemporaneous blood-loss event that occurs before pre-defined the time window, vi) a record of a trauma event, v) use of forceps in delivery, vi) vital signs, vii) intake questionnaires, and viii) elapse time.

6. The system of claim 1, wherein to receive an update for the subject based at least on one of the group comprising i) the biosensor data; and ii) a change to the EMR data, the computer system is further configured to: continuously monitor data streams of the biosensor data responsive to receipt of the data streams; and listen for the change in the EMR data that have been created by another system.

7. The system of claim 1, wherein the training data comprises i) hemodynamic outcomes and ii) associated training-EMR data.

8. The system of claim 1, wherein the subject is one of the group consisting of i) a peri-partum patient and ii) a post-partum patient.

9. A system comprising: a computer system comprising at least one processor and memory, the computer system configured to: receive Electronic Medical Record (EMR) data for a subject, the EMR data comprising biosensor data of the subject; receive an update for the subject based at least on one of: i) the biosensor data; or ii) a change to the EMR data; and responsive to receiving the update, generate, using a machinelearning model, a maternal hemorrhaging metric that indicates a likelihood of occurrence of a maternal hemorrhaging event within a first time window, wherein the machine learning model is configured using a corpus of training data comprising information on maternal hemorrhaging events and associated EMR data.

10. The system of claim 9, wherein the computer system is further configured to, responsive to generating the maternal-hemorrhaging metric: generate a recommendation for an intervention within a second time window.

11. The system of claim 9, wherein the computer system is further configured to, responsive to generating the maternal-hemorrhaging metric: generate based on the maternal-hemorrhaging metric , computer- readable instructions configured to cause a device to execute one or more automated actions.

12. The system of claim 9, wherein the system further comprises: one or more EMR datastores configured to: receive biosensor data of a subject; and update EMR data for the subject; and one or more biosensors, the one or more biosensors each configured to: sense a phenomena of the subject; and transmit, to the one or more EMR datastores, the biosensor data based on the sensing of the phenomena.

13. The system of claim 9, wherein: the biosensor data comprises at least one of the group consisting of i) electrocardiogram (ECG) data; ii) photoplethysmogram (PPG) data, and iii) speckle plethysmography (SPG) data; the EMR data comprises a record of at least one of the group consisting of i) a history of bleeding, and ii) a number of previous births; and the update for the subject comprises at least one of the group consisting of i) a blood test result, ii) administration of a medication, iii) a cervixmeasurement, iv) a record of a fetal position, v) a record of a contemporaneous blood-loss event that occurs before pre-defined the time window, vi) a record of a trauma event, v) use of forceps in delivery, vi) vital signs, vii) intake questionnaires, and viii) elapse time.

14. The system of claim 9, wherein to receive an update for the subject based at least on one of the group comprising i) the biosensor data; and ii) a change to the EMR data, the computer system is further configured to: continuously monitor data streams of the biosensor data responsive to receipt of the data streams; and listen for the change in the EMR data that have been created by another system.

15. The system of claim 9, the training data comprises i) hemodynamic outcomes and ii) associated training-EMR data.

16. The system of claim 9, wherein the subject is one of the group consisting of i) a peri-partum patient and ii) a post-partum patient.

17. A method comprising: receiving biosensor data for a subject from one or more biosensors; receiving Electronic Medical Record (EMR) data for the subject; receive an update for the subject based at least on one of: i) the biosensor data; or ii) a change to the EMR data; and responsive to receiving the update, generate, using a machine learning model, a maternal hemorrhaging metric that indicates a likelihood of occurrence of a maternal hemorrhaging event within a first time window, wherein the machine learning model is configured using a corpus of training data comprising information on maternal hemorrhaging events and associated EMR data.

18. The method of claim 17, wherein the method further comprises, responsive to generating the maternal-hemorrhaging metric for the subject: generating a recommendation for an intervention within a second time window.

19. The method of claim 17, wherein the method further comprises: monitoring data streams of the biosensor data responsive to receipt of the data streams; and listening for the change in the EMR data that have been created by another system.

20. The method of claim 17, wherein training data representative of hemodynamic instability related complications comprises hemodynamic outcomes and associated with training-EMR data.

Images