Methods and systems for improved training of a hemodynamic instability cause classification model by improving training data

Abstract

A method (100) for training a hemodynamic instability cause classification model to classify a patient's determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock, the method comprising: (i) receiving (120) a preliminary cause classification model training dataset; (ii) analyzing (130) the received dataset to classify each patient as likely to be hemodynamically unstable; (iii) analyzing (140) the received patient information by an outlier detection model to determine whether that patient's hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; (iv) generating (150) a final cause classification model training dataset by removing each of the patients determined as being an outlier; and (v) training (160) the hemodynamic instability cause classification model to classify a cause of the patient's determined likelihood of future hemodynamic instability.

Description

METHODS AND SYSTEMS FOR IMPROVED TRAINING OF A HEMODYNAMIC INSTABILITY CAUSE CLASSIFICATION MODEL BY IMPROVING TRAINING DATAField of the Disclosure

[0001] The present disclosure relates generally to methods and systems for generating an improved training dataset utilized to train a prediction model.Background

[0002] For critically ill patients, timely intervention to treat or prevent hemodynamic instability is crucial to patient outcomes. Unfortunately, the early warning signs of hemodynamic instability can be easily missed. Clinical expertise to recognize these signs may be scarce, and early signs of instability may not be obvious from simple monitoring of individual vitals.

[0003] Existing methods for detecting hemodynamic instability are primarily focused on simple rules that can be easily used by busy clinicians without automated assistance. For example, the PALS (Pediatric Advanced Life Support) guidelines provide age-adjusted normal ranges for common vitals, including heart rate, respiratory rate, and blood pressure. Vitals outside of normal ranges are considered as a sign of potential hemodynamic instability, requiring additional clinical attention. Another prior art method detects upcoming hypotension for non-cardiac surgery patients in the operating room. However, these prior methods and systems are typically unable to detect potential hemodynamic instability from the simple monitoring of individual vitals, do a poor job distinguishing among age-dependent signs of instability, and some are not implemented in the ICU setting.

[0004] Accordingly, a hemodynamic stability index (HSI) was developed to provide early warnings on the upcoming onset of hemodynamic instability. Although most hemodynamically unstable patients suffer from severe hypotension and inadequate organ perfusion to support normal organ functions, there exist multiple underlying shock types causing the instability, including cardiogenic shock (critical reduction of the heart’s pumping capacity), hypovolemic shock (severe blood loss or loss of fluids) and septic shock (dysregulated response to an infection resulting in life-threatening organ dysfunctions). Other less common shock types include anaphylactic shock and neurogenic shock, although they have a low prevalence in the ICU (less than 5%).

[0005] Patients belonging to different shock types often receive different types of hemodynamic interventions. For example, cardiogenic shock patients receive inotropes, including dobutamine and milrinone, or mechanical cardiac support, including IABP (intra-aortic balloon pump), ECMO (extracorporeal membrane oxygenation), and LV D (left ventricular assistant device). Hypovolemic shock patients receive packed red blood cells transfusion (in cases of hemorrhage) or fluid bolus (in cases of hypovolemia). Septic shock patients receive vasopressors (norepinephrine, phenylephrine, dopamine, vasopressin, epinephrine) and overlapping antibiotics.

[0006] A hemodynamic instability cause classification model can be trained to analyze patient data, for patients determined by the HSI to be likely to experience hemodynamic instability, to determine whether the instability is likely to be caused by one or more of cardiogenic shock, hypovolemic shock, and septic shock. However, training of the hemodynamic instability cause classification model is imperfect since the training data will include historical samples in which the hemodynamic instability was caused by other factors, such as anaphylactic shock and neurogenic shock.Summary of the Disclosure

[0007] Accordingly, there is a continued need for systems and methods that generate an improved training dataset which can be utilized to train a hemodynamic instability cause classification model.

[0008] Various embodiments and implementations herein are directed to a method and system configured to generate an improved training dataset. The system receives a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients, such as historical electronic medical records (EMR) for a plurality of patients. A trained hemodynamic stability index (HSI) model analyzes the received patient information to classify at least some of the plurality of historical patients as likely to be hemodynamically unstable. A trained outlier detection model then analyzes, for each of the plurality of historical patients determined to be likely to be hemodynamically unstable, the received patient information for that patient in order to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier. The system generates a final cause classification model training dataset by removing, from the preliminary cause classification model training dataset, each of the plurality of historical patients determined by the outlierdetection model as being an outlier. The hemodynamic instability cause classification model is then trained using the final cause classification model training dataset.

[0009] Generally, in one aspect, a method for training a hemodynamic instability cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock is provided. The method includes: (i) receiving a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients; (ii) analyzing, by a trained hemodynamic stability index (HSI) model, the received patient information to classify each of the plurality of historical patients as likely to be hemodynamically unstable; (iii) analyzing, for each of the hemodynamically unstable patients, the received patient information by an outlier detection model to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; (iv) generating a final cause classification model training dataset by removing, from the preliminary cause classification model training dataset, each of the plurality of historical patients determined by the outlier detection model as being an outlier; and (v) training, using the final cause classification model training dataset, the hemodynamic instability cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock.

[0010] According to an embodiment, a cause of the determined outlier status for the patient’s hemodynamic instability is one or more of a neurogenic cause, an anaphylactic cause, and a stable patient.

[0011] According to an embodiment, the method further includes training, using a training dataset comprising patient information for a plurality of historical patients, the outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier.

[0012] According to an embodiment, the method further includes receiving patient information about a current patient; analyzing the received patient information by the hemodynamic stability index (HSI) model to classify the current patient as likely to be hemodynamically unstable within a predetermined future time period; (iii) analyzing, for the hemodynamically unstable patient, the received patient information by an outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or anoutlier; and (iv) providing, via a user interface when the outlier detection model determines the patient’s hemodynamic instability to likely to be an outlier, a notification of outlier status for the patient.

[0013] According to an embodiment, the method further includes ordering, by the clinician, an intervention to determine a cause of the outlier status for the patient’s hemodynamic instability.

[0014] According to an embodiment, the user interface is a patient monitor, such as a bedside patient monitor in an intensive care unit.

[0015] According to an embodiment, the method further includes: analyzing, when the outlier detection model determines the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, or hypovolemic shock, the received patient information by a cause classification model to classify the patient’s hemodynamic instability as one or more of cardiogenic shock, septic shock, and hypovolemic shock, wherein the cause classification model is further configured to generate a probability of each of the one or more of cardiogenic shock, septic shock, hypovolemic shock causing the patient’s hemodynamic instability; and providing, via a user interface, the classification of the patient’s hemodynamic instability with the probability of each of the one or more of cardiogenic shock, septic shock, and hypovolemic shock causing the patient’s hemodynamic instability.

[0016] According to an embodiment, the method further includes ordering, by the clinician, an intervention to treat one or more of the cardiogenic shock, septic shock, and hypovolemic shock determined to cause the patient’s hemodynamic instability.

[0017] According to an embodiment, the intervention for cardiogenic shock comprises one or more of an inotrope and mechanical cardiac support, the intervention for hypovolemic shock comprises one or more of a blood transfusion or fluid bolus, and the intervention for septic shock comprises one or more of a vasopressor and an overlapping antibiotic.

[0018] According to another aspect, a system for training a hemodynamic instability cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock is provided. The system includes: a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients; a trained hemodynamic stability index (HSI) model trained to analyze patient information to classify a patient as likely to be hemodynamically stable or hemodynamically unstable; a trained outlier detection modelconfigured to analyze patient information to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; a cause classification model; and a processor configured to: (i) analyze, with the trained HSI model, the received patient information in the preliminary cause classification model training dataset to classify each of the plurality of historical patients as likely to be hemodynamically stable or hemodynamically unstable; (ii) analyze, for each of the hemodynamically unstable patients, the received patient information by the trained outlier detection model to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; (iii) generate a final cause classification model training dataset by removing, from the preliminary cause classification model training dataset, each of the plurality of historical patients determined by the outlier detection model as being an outlier; and (iv) train, using the final cause classification model training dataset, the cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock. In a clinical setting, a patient may be affected by more than one type of hemodynamic instability.

[0019] According to an embodiment, the processor is further configured to train, using a training dataset comprising patient information for a plurality of historical patients, the outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier.

[0020] According to an embodiment, the processor is further configured to: (i) receive patient information about a current patient; (ii) analyze the received patient information by the hemodynamic stability index (HSI) model to classify the current patient as likely to be hemodynamically unstable within a predetermined future time period; (iii) analyze, for the hemodynamically unstable patient, the received patient information by an outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; and (iv) provide, via a user interface when the outlier detection model determines the patient’s hemodynamic instability to likely to be an outlier, a notification of outlier status for the patient.

[0021] According to an embodiment, the processor is further configured to analyze, when the outlier detection model determines the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, or hypovolemic shock, the received patient information by a causeclassification model to classify the patient’s hemodynamic instability as one or more of cardiogenic shock, septic shock, and hypovolemic shock, wherein the cause classification model is further configured to generate a probability of each of the one or more of cardiogenic shock, septic shock, hypovolemic shock causing the patient’s hemodynamic instability; and provide, via a user interface, the classification of the patient’s hemodynamic instability with the probability of each of the one or more of cardiogenic shock, septic shock, and hypovolemic shock causing the patient’s hemodynamic instability.

[0022] It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein. It should also be appreciated that terminology explicitly employed herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.

[0023] These and other aspects of the various embodiments will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.Brief Description of the Drawings

[0024] In the drawings, like reference characters generally refer to the same parts throughout the different views. The figures showing features and ways of implementing various embodiments and are not to be construed as being limiting to other possible embodiments falling within the scope of the attached claims. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the various embodiments.

[0025] FIG. 1 is a flowchart of a method for generating a training dataset, in accordance with an embodiment.

[0026] FIG. 2 is a schematic representation of a training system, in accordance with an embodiment.

[0027] FIG. 3 is a schematic representation of hemodynamic stability analysis, according to a prior art method.

[0028] FIG. 4 is flowchart of a method for training a model, in accordance with an embodiment.

[0029] FIG. 5 is a flowchart of a method for training a model, in accordance with an embodiment.

[0030] FIG. 6 is a flowchart of a method for hemodynamic stability analysis, in accordance with an embodiment.

[0031] FIG. 7 is a flowchart of a method for hemodynamic stability analysis, in accordance with an embodiment.Detailed Description of Embodiments

[0032] The present disclosure describes various embodiments of a system and method configured to generate an improved training dataset used to train a hemodynamic instability cause classification model. More generally, Applicant has recognized and appreciated that it would be beneficial to generate improved training datasets, thereby training more accurate prediction models. Accordingly, a training system receives a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients. A trained hemodynamic stability index (HSI) model analyzes the received patient information to classify at least some of the plurality of historical patients as likely to be hemodynamically unstable. A trained outlier detection model then analyzes, for each of the plurality of historical patients determined to be likely to be hemodynamically unstable, the received patient information for that patient in order to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier. The system generates a final cause classification model training dataset by removing, from the preliminary cause classification model training dataset, each of the plurality of historical patients determined by the outlier detection model as being an outlier. The hemodynamic instability cause classification model is then trained using the final cause classification model training dataset.

[0033] According to an embodiment, the systems and methods described or otherwise envisioned herein can, in some non-limiting embodiments, be implemented as an element for acommercial product for patient analysis or monitoring, such as the Philips® IntelliVue® systems (available from Koninklijke Philips NV, the Netherlands), or any suitable system. For example, the system and method can be implemented within existing or future clinical decision support systems (CDS), applications, and devices. However, the disclosure is not limited to these devices or systems, and thus disclosure and embodiments disclosed herein can encompass any device or system capable of generating a training dataset for a prediction model.

[0034] Referring to FIG. 1 , in one embodiment, is a flowchart of a method 100 for generating a training dataset using a training system 200. The methods described in connection with the figures are provided as examples only, and shall be understood not limit the scope of the disclosure. The training system can be any of the systems described or otherwise envisioned herein. The training system can be a single system or multiple different systems. According to an embodiment, the training system is a hemodynamic instability cause classification model training system.

[0035] At step 110 of the method, a training system 200 is provided. Referring to an embodiment of a training system 200 as depicted in FIG. 2, for example, the system comprises one or more of a processor 220, memory 230, user interface 240, communications interface 250, and storage 260, interconnected via one or more system buses 212. It will be understood that FIG. 2 constitutes, in some respects, an abstraction and that the actual organization of the components of the system 200 may be different and more complex than illustrated. Additionally, training system 200 can be any of the systems described or otherwise envisioned herein. Other elements and components of training system 200 are disclosed and / or envisioned elsewhere herein.

[0036] At step 120 of the method, the training system receives or obtains a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients. The patient information can be any information about the patient that the training system can or may utilize to generate a training dataset as described or otherwise envisioned herein. According to an embodiment, the patient information comprises one or more of demographic information about the patient, a diagnosis for the patient, medical history of the patient such as treatment information, and / or any other information. For example, demographic information may comprise information about the patient such as age, body mass index (BMI), and any other demographic information. The diagnosis for the patient may be any information about a medical diagnosis for the patient, historical and / or current. The medical history of the patient maybe any historical admittance or discharge information, historical treatment information, historical diagnosis information, historical exam or imaging information, and / or any other information. Other patient information that can be received by the training system includes lab test results. For example, the lab tests may be an analysis of blood gases, electrolytes, biomarkers, and / or any other types of lab tests. Yet another example of patient information received by the training system includes vital sign information for the patient. The vital sign information can be any vital sign of the patient such as heart rate, respiration rate, blood pressure, temperature, and / or any other information.

[0037] The patient information may be received or obtained from one or a plurality of different sources. According to an embodiment, the patient information is received from, retrieved from, or otherwise obtained from the electronic medical record database or system 270. The EMR database or system may be local or remote. The EMR database or system may be a component of the training system, or may be in local and / or remote communication with the training system. The received patient information may be utilized immediately, or may be stored in local or remote storage for use in further steps of the method.

[0038] At step 130 of the method, the patient information within the preliminary cause classification model training dataset is analyzed, for each of the plurality of historical patients, by a trained hemodynamic stability index (HSI) model. The HSI model is trained to classify a patient as likely to be hemodynamically stable or likely to be hemodynamically unstable, based on the patient information. The HSI model utilizes features extracted from patient information in order to predict, for a predetermined future time, a patient’s likelihood of experience hemodynamic instability. The predetermined future time may be any time period, such as hours, although other time periods are possible. A common, but non-limiting, example of a predetermined future time may be one (1) hour. The features extracted from patient information and utilized by the HSI model can include, for example, heart rate, blood pressure, hematocrit levels, temperature, blood oxygen levels, and many other possible features. The output of the HSI model can be, for example, an indication that either: (1) the patient is or is likely to be hemodynamically stable within the predetermined future time; or (2) the patient is or is likely to be hemodynamically unstable within the predetermined future time. Or, in other words, the patient is or is likely to experience hemodynamic instability within the predetermined future time. Further information about the HSImodel, including training and implementation, can be found in Rahman, A., Chang, Y., Dong, J. et al., “Early prediction of hemodynamic interventions in the intensive care unit using machine learning,” Crit Care 25, 388 (2021).

[0039] Hemodynamic instability can result from a variety of different causes. For example, there exist multiple hemodynamic shock types causing instability, including cardiogenic shock (critical reduction of the heart’s pumping capacity), hypovolemic shock (severe blood loss or loss of fluids) and septic shock (dysregulated response to an infection resulting in life-threatening organ dysfunctions). According to an embodiment, there may be other shock types causing the instability, such as anaphylactic shock and neurogenic shock, although their prevalence is low.

[0040] Patients belonging to different shock types receive different types of hemodynamic interventions. Specifically: (1) cardiogenic shock patients receive inotropes, including dobutamine and milrinone, or mechanical cardiac support, including IABP (intra-aortic balloon pump), VA- ECMO (venoarterial extracorporeal membrane oxygenation), and / or LVAD (left ventricular assistant device), among other treatments; (2) hypovolemic shock patients receive packed red blood cells (PRBC) transfusion (in cases of hemorrhage) and / or fluid bolus (in cases of hypovolemia), among other treatments; 3) septic shock patients receive vasopressors (norepinephrine, phenylephrine, dopamine, vasopressin, epinephrine) and overlapping antibiotics, among other treatments.

[0041] Accordingly, given the different types of hemodynamic shock types causing instability, and the different hemodynamic interventions corresponding with those causes, it is vital to determine the most likely type or types of hemodynamic shock or instability. Thus, a hemodynamic instability cause classification model can be useful to predict the one or more most likely causes of the patient’s predicted hemodynamic instability.

[0042] Referring to FIG. 3, for example, is a prior art method 300 for analyzing patient information to determine a likelihood of experiencing hemodynamic instability, as well as determining the most likely type or types of hemodynamic shock or instability. At step 310, an analysis system received input data about a patient. This can be any of the patient information described or otherwise envisioned herein, including but not limited to vitals, lab data, ventilation data, and / or any other data. This patient information can be, according to an embodiment,continuously and / or automatically flowing into the analysis system. Thus, predictions can be periodically updated.

[0043] At step 320, the input data is analyzed by the HSI model 312. The HSI model can be any of the models described or otherwise envisioned herein. For example, the HSI model can be utilized to analyze patient information to determine a likelihood of experiencing hemodynamic instability during a predetermined future time period. Thus, the patient will be classified as “STABLE” if the HSI model determines that the patient is unlikely to experience hemodynamic instability during the predetermined future time period, or will be classified as “UNSTABLE” if the HSI model determines that the patient is likely to experience hemodynamic instability during the predetermined future time period. If the patient is determined by the HSI model to be stable, then there is no notification of instability, or there is a notification of the patient’s determined stability, such as on a user interface 320, which can be a patient monitor or other device. If the patient is determined by the HSI model to be unstable, in other words the patient is likely to experience hemodynamic instability during the predetermined future time period, then the patient information is fed to a trained hemodynamic instability cause classification model 314 in order to predict the one or more most likely causes of the patient’s predicted hemodynamic instability including cardiogenic, hypovolemic, and septic cause. Notably, a patient can have multiple causes of instability. In FIG. 3, for example, the hemodynamic instability cause classification model 314 determined that the hemodynamic instability is most likely caused by cardiogenic shock with a probability of 70%. The model also determined that there is a 53% probability of septic shock, and a 12% probability of hypovolemic shock. These are just non-limiting examples, and the actual probabilities will depend on the patient information and the training of the hemodynamic instability cause classification model 314. The determined cause or causes are then provided to the clinician, such as on a user interface 320, which can be a patient monitor or other device. Depending on the predicted causes, the clinician can take specific actions to confirm the diagnosis suggested by the hemodynamic instability cause classification model 314, and can provide differentiated treatments to the patient. TABLE 1 includes non-limiting examples of actions and treatment options that can be enacted by the clinician in response to receiving the determined cause or causes of the patient’s predicted hemodynamic instability.

[0044] TABLE 1. Actions and Treatments for Hemodynamic Instability

[0045] According to an embodiment, given a patient cohort consisting of cardiogenic, hypovolemic, and septic classes, the hemodynamic instability cause classification model can be trained by building three one-vs-the-rest binary classifiers. For example, the cardiogenic cause classifier can be trained to distinguish cardiogenic cause patients from hypovolemic cause patients and septic cause patients. This will allow one patient to be assigned to multiple classes. The positive and negative class of each of those three cause classifiers are summarized in TABLE 2.

[0046] TABLE 2. Positive and Negative Classes for Three Cause Classifiers

[0047] However, when deployed in practice, besides receiving inputs belonging to those three cause classes, the hemodynamic instability cause classification model may receive other types of inputs, including but not limited to: (1) hemodynamically stable patients that are false positives of the HSI model; and (2) patients belonging to other types of causes driving the hemodynamic instability, including neurogenic cause and anaphylactic cause. Since the model is not trained using those samples, the model will output incorrect predictions. For example, the model may wrongly assign the sample to one or more of the three cause classes, even though the sample is not properly within those classes.

[0048] While one option may be to train the hemodynamic instability cause classification model by including other types of inputs besides cardiogenic / hypovolemic / septic patients, including stable patients and neurologic / anaphylactic patients, each trained cause classifier willmost likely be driven by the separation between stable patients and each cause class and therefore cannot properly mimic the differential diagnosis of three causes.

[0049] According to an embodiment, therefore, the training system may utilize outlier detection to identify input samples that do not belong to any of those three classes. In this way, the model can avoid misleading clinicians by outputting an incorrect prediction.

[0050] Returning to method 100 in FIG. 1, at step 140 of the method, at least some of the plurality of historical patients have been found to be hemodynamically unstable, or likely to be hemodynamically unstable within the predetermined future time period, by the HSI model. These hemodynamically unstable patients are then analyzed at step 140 of the method by a trained outlier detection model. The outlier detection model is trained to determine, from the patient information, whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier. When the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, the patient and the patient information may be utilized as a training sample for the cause classification model, as described or otherwise envisioned herein. When the patient’s hemodynamic instability is likely to be an outlier, the patient and the patient information may be removed from the training dataset and will not be used as a training sample for the cause classification model.

[0051] Referring to FIG. 4, for example, is a flowchart for a method 400 for training a hemodynamic instability cause classification model 414. As described or otherwise envisioned herein, the training system receives input data about a patient. This can be any of the patient information described or otherwise envisioned herein, including but not limited to vitals, lab data, ventilation data, and / or any other data. According to an embodiment, the input data is historical patient data about a plurality of patients. The input data can be received from a local and / or remote database. For example, the training system may comprise or be in communication with a database of training data, such as a electronic medical record database or system.

[0052] At step 412, the input data is analyzed by the HSI model. The HSI model can be any of the models described or otherwise envisioned herein. For example, the HSI model can be utilized to analyze patient information to determine a likelihood of experiencing hemodynamic instability during a predetermined future time period. Thus, the patient will be classified as “STABLE” if the HSI model determines that the patient is unlikely to experience hemodynamic instability during the predetermined future time period, or will be classified as “UNSTABLE” if the HSI modeldetermines that the patient is likely to experience hemodynamic instability during the predetermined future time period. At step 440, a patient in the plurality of patients being analyzed is determined by the HSI model to be stable, and can optionally be removed from the training dataset.

[0053] For patients identified by the HSI model to be unstable, in other words the patient is likely to experience hemodynamic instability during the predetermined future time period, then the patient information is fed to the outlier detector at 413. The outlier detection model is trained to determine, from the patient information, whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier. When the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, the patient and the patient information may be utilized as a training sample for the cause classification model, as described or otherwise envisioned herein. At step 450, a patient in the plurality of patients being analyzed is determined by the outlier detector to be an outlier. According to an embodiment, when the patient’s hemodynamic instability is likely to be an outlier, the patient and the patient information may optionally be removed from the training dataset such that it would not be used as a training sample for the cause classification model.

[0054] The patients and the accompany patient information that are not identified by the outlier detector as an outlier are then fed to the hemodynamic instability cause classification model 414 in order to train the model to predict the one or more most likely causes of the patient’s predicted hemodynamic instability including cardiogenic, hypovolemic, and septic cause. Notably, a patient can have multiple causes of instability. According to an embodiment, the hemodynamic instability cause classification model 414 comprises a cardiogenic classifier 432, a septic classifier 434, and a hypovolemic classifier 436.

[0055] The outlier detection approach utilized by the outlier detector 413 can vary. According to one non-limiting example, the outlier detection approach utilized by the outlier detector is a simple out-of-distribution detection approach based on the Mahalanobis distance (See, e.g., Lee et al., “A Simple Unified Framework for Detecting Out-of-Distribution Samples and Adversarial Attacks,” In Conference on Neural Information Processing System (NeurlPS) (2018)). Other outlier detection approaches are possible.

[0056] According to this embodiment, let x E IR.Dbe a D -dimensional input sample and y E {1, ••• , C] be its class label. The system can train a deep neural network (DNN) to classify each input sample into one of target classes. The last soft-max layer of the DNN is denoted as:where wcand bcare the weight and bias the soft-max classifier for class c, and / (%) denotes the output of the penultimate layer of the DNN.

[0057] The model can assume the conditional distribution of / (%) within each class should follow Gaussian distribution: p( / (x) I y = c) = N ( / (%) | He, ) (Eq. 2) where He is the mean of the multivariate Gaussian distribution of class c, and 2 is the shared covariance matrix of C classes.

[0058] Each input sample x can be assigned to the class with highest log-likelihood, which can be computed using the Mahalanobis distance as follows:

[0059] The system can compute the distribution of M(x) using all the training samples and derive its 1% percentile value as the decision threshold T. In the deployment phase, any test sample with M(x) lower than T will be treated as outliers.

[0060] According to an embodiment, the system can train an outlier detection model for each of the three cause classifiers disclosed or otherwise envisioned herein. A test sample will be determined as an outlier if the outlier detection model predicts it as an outlier.

[0061] Returning to method 100 in FIG. 1, at step 112 of the method, the outlier detection model can be trained to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier. For example, the outlier detection model can be trained, using a training dataset comprising patient information for a plurality of historical patients, to determine whether the patient’s hemodynamic instability is likely to be an outlier (i.e., a cause other than cardiogenic shock, septic shock, and hypovolemic shock).

[0062] Referring to FIG. 5, in one embodiment, is a flowchart of a method 500 for training the outlier detection model or models. At step 510 of the method, a training system - which may be training system 200 or any other system - receives or obtains the training dataset generatedaccording to the methods and systems described or otherwise envisioned herein, such as via the method described in conjunction with FIG. 1. Thus, the training data can comprise a plurality of patients and associated patient information. The training data may be stored in and / or received from one or more databases. The database may be a local and / or remote database. For example, the training system may comprise a database of training data, such as an electronic medical record database or system 270.

[0063] According to an embodiment, the training system may comprise a data pre-processor or similar component or algorithm configured to process the received training data. For example, the data pre-processor analyzes the training data to remove noise, bias, errors, and other potential issues. The data pre-processor may also analyze the input data to remove low-quality data. Many other forms of data pre-processing or data point identification and / or extraction are possible.

[0064] At step 520 of the method, the system trains the model, which will be the algorithm utilized in analyzing the input information as described or otherwise envisioned. The model is trained using the training data set according to known methods for training a model. According to an embodiment, the model is trained, using the processed training dataset, to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier.

[0065] At step 530 of the method, the trained model of the system is stored for future use. According to an embodiment, the model may be stored in local or remote storage.

[0066] Returning to method 100 in FIG. 1, at step 150 of the method, the training system generates a final cause classification model training dataset, from the preliminary cause classification model training dataset. In this embodiment, the system removes those patients and accompanying patient information that are identified by the outlier detection model as being an outlier. Thus, the final cause classification model training dataset will not incorporate outliers into the training of the cause classification model.

[0067] Removing patients and accompanying patient information from the preliminary cause classification model training dataset can take many forms. According to one embodiment, a new dataset - that is, the final cause classification model training dataset - is generated comprising only patients that are not identified as outliers. Thus, the final cause classification model training dataset will comprise a subset of the patients within the preliminary cause classification modeltraining dataset. According to another embodiment, the final cause classification model training dataset comprises the entirety of the preliminary cause classification model training dataset, but with labels or other designations that inform the training system not to utilize any patient that has been identified as an outlier.

[0068] At step 160 of the method, the hemodynamic instability cause classification model is trained using the final cause classification model training dataset. The hemodynamic instability cause classification model is trained, with the dataset, to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock. According to an embodiment, the hemodynamic instability cause classification model is trained, with the dataset, to generate probabilities of each of one or more of cardiogenic shock, septic shock, and hypovolemic shock causing a patient’s hemodynamic instability. The hemodynamic instability cause classification model can be a variety of different models, algorithms, or classifiers, including but not limited to the classifiers specifically described or otherwise envisioned herein. According to an embodiment, the model is trained using the training data set according to known methods for training a model.

[0069] Thus, following step 160 of the method, the training system comprises a trained hemodynamic instability cause classification model, trained with the final cause classification model training dataset. The trained hemodynamic instability cause classification model is significantly improved compared to prior models, as the model is trained with patients and accompanying patient information that does not comprise outliers, thus improving the predictions generated by the model. The trained model may be static, or it may be periodically or continually updated with new patient information, following the process described in FIG. 1, including identification and removal of outliers.

[0070] Referring to FIG. 6, according to an embodiment, the trained outlier model and the trained hemodynamic instability cause classification model may be utilized in a deployment system. The deployment system may be any system, including but not limited to the systems described or otherwise envisioned herein.

[0071] Accordingly, during deployment, at step 170 of the method, the system receives or obtains patient information for a current patient, for which a hemodynamic stability analysis will be performed. The patient information can be any information about the patient that the system can or may utilize to perform a hemodynamic stability analysis as described or otherwiseenvisioned herein. The patient information may be received or obtained from one or a plurality of different sources. According to an embodiment, the patient information is received from, retrieved from, or otherwise obtained from the electronic medical record database or system 270. The EMR database or system may be local or remote. The EMR database or system may be a component of the training system, or may be in local and / or remote communication with the training system.

[0072] At step 172 of the method, the patient information is analyzed by a trained HSI model. The HSI model is trained to classify a patient as likely to be hemodynamically stable or likely to be hemodynamically unstable, based on the patient information. The HSI model utilizes features extracted from patient information in order to predict, for a predetermined future time, a patient’s likelihood of experience hemodynamic instability. The predetermined future time may be any time period, such as hour(s). A common, but non-limiting, example of a predetermined future time may be one (1) hour. The features extracted from patient information and utilized by the HSI model can include, for example, heart rate, blood pressure, hematocrit levels, temperature, blood oxygen levels, and many other possible features. The output of the HSI model can be, for example, an indication that either: (1) the patient is or is likely to be hemodynamically stable within the predetermined future time; or (2) the patient is or is likely to be hemodynamically unstable within the predetermined future time. Or, in other words, the patient is or is likely to experience hemodynamic instability within the predetermined future time.

[0073] At step 174 of the method, the HSI model has determined that the patient is unstable, and thus trained outlier detection model analyzes the received patient information to determine whether the patient’s hemodynamic instability is likely to be caused by cardiogenic shock, septic shock, hypovolemic shock, or is likely to be an outlier. If the patient’s hemodynamic instability is determined by the trained outlier detection model to be likely to be caused by an outlier situation, the method is terminated and a notification can be provided to notify the patient does not have any of those three shock types.

[0074] Thus, at step 176 of the method, a notification is provided to a healthcare provider, such as via a user interface, that the patient’s hemodynamic instability to likely to be caused by an outlier condition. The notification can be any of the information as described or otherwise envisioned herein. The system may provide the information to a user via any mechanism, including but not limited to a visual display, an audible notification, a page, or any other method of notification. The information may be communicated by wired and / or wireless communication to another device.For example, the system may communicate the information to a mobile phone, computer, laptop, wearable device, and / or any other device configured to allow display and / or other communication of the information.

[0075] At step 180 of the method, a clinician can order a medical test, a diagnostic test, or an intervention to determine a cause of the outlier status for the patient’s hemodynamic instability. The medical test, diagnostic test, or intervention can be any medical test, diagnostic test, or intervention that may be utilized to determine or analyze a patient’s hemodynamic status. For example, the medical test, diagnostic test, or intervention may be a lab test, vitals information, or any other treatment that is appropriate to analyze outlier status. For example, since the outlier status may be anaphylactic shock and / or neurogenic shock, among other possibilities, the ordered medical test, diagnostic test, or intervention can be a test to determine or analyze anaphylactic shock and / or neurogenic shock.

[0076] Alternatively, the outlier detection model may determine at step 174 that the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, or hypovolemic shock. Thus, at step 178 of the method, the patient information is analyzed by the trained cause classification model to classify the patient’s hemodynamic instability as one or more of cardiogenic shock, septic shock, and hypovolemic shock. According to an embodiment, the classification model is trained to generate a probability of each of the one or more of cardiogenic shock, septic shock, hypovolemic shock causing the patient’s hemodynamic instability.

[0077] At step 190 of the method, the output of the cause classification model is provided to a healthcare provider, such as via a user interface. The notification can be any of the information as described or otherwise envisioned herein. The system may provide the information to a user via any mechanism, including but not limited to a visual display, an audible notification, a page, or any other method of notification. The information may be communicated by wired and / or wireless communication to another device. For example, the system may communicate the information to a mobile phone, computer, laptop, wearable device, and / or any other device configured to allow display and / or other communication of the information.

[0078] At step 192 of the method, a clinician can order a medical test, a diagnostic test, or an intervention to treat the determined cause or causes of the patient’s hemodynamic instability. The medical test, diagnostic test, or intervention can be any intervention that may be utilized to treat or prevent or analyze a patient’s hemodynamic instability. According to an embodiment, treatmentfor cardiogenic shock includes inotropes, including dobutamine and milrinone, or mechanical cardiac support, including IABP (intra-aortic balloon pump), VA-ECMO (venoarterial extracorporeal membrane oxygenation), and / or LVAD (left ventricular assistant device), among other treatments. According to an embodiment, treatment for hypovolemic shock includes packed red blood cells (PRBC) transfusion (in cases of hemorrhage) and fluid bolus (in cases of hypovolemia), among other treatments. According to an embodiment, treatment for septic shock includes vasopressors (norepinephrine, phenylephrine, dopamine, vasopressin, epinephrine) and overlapping antibiotics, among other treatments.

[0079] Referring to FIG. 7, in one embodiment, is a flowchart for a method 700 for utilizing the trained outlier model and the trained hemodynamic instability cause classification model in a deployment system. The deployment system may be any system, including but not limited to the systems described or otherwise envisioned herein.

[0080] At step 712 of the method, received patient information is analyzed by a trained HSI model. The patient information can be any information about the patient that the system can or may utilize to perform a hemodynamic stability analysis as described or otherwise envisioned herein. The patient information may be received or obtained from one or a plurality of different sources. The HSI model is trained to classify a patient as likely to be hemodynamically stable or likely to be hemodynamically unstable, based on the patient information. The HSI model utilizes features extracted from patient information in order to predict, for a predetermined future time, a patient’s likelihood of experience hemodynamic instability. The predetermined future time may be any time period, such as hour(s). A common, but non-limiting, example of a predetermined future time may be one (1) hour. The features extracted from patient information and utilized by the HSI model can include, for example, heart rate, blood pressure, hematocrit levels, temperature, blood oxygen levels, and many other possible features. The output of the HSI model can be, for example, an indication that either: (1) the patient is or is likely to be hemodynamically stable within the predetermined future time (i.e., numeral 740 in FIG. 7); or (2) the patient is or is likely to be hemodynamically unstable within the predetermined future time. Or, in other words, the patient is or is likely to experience hemodynamic instability within the predetermined future time.

[0081] When the HSI model has determined that the patient is unstable, trained outlier detection model 713 analyzes the received patient information to determine whether the patient’s hemodynamic instability is likely to be caused by cardiogenic shock, septic shock, hypovolemicshock, or is likely to be an outlier. If the patient’s hemodynamic instability is determined by the trained outlier detection model to be likely to be caused by an outlier situation, such as at 750, the method is terminated and a notification can be provided.

[0082] When the trained outlier detection model 713 determines that the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, or hypovolemic shock, the patient information is analyzed by the trained cause classification model 714 to classify the patient’s hemodynamic instability as one or more of cardiogenic shock, septic shock, and hypovolemic shock. According to an embodiment, the classification model comprises a cardiogenic classifier 732, a septic classifier 734, and a hypovolemic classifier 736. According to an embodiment, the classification model is trained to generate a probability of each of the one or more of cardiogenic shock, septic shock, hypovolemic shock causing the patient’s hemodynamic instability.

[0083] In practice or during training, the output of the hemodynamic instability cause classification model 714 may then be fed to a risk notification filter 730. The risk notification filter 430 can be a threshold filter or any other filter that utilizes one or more predetermined parameters or thresholds to determine whether the probability or probabilities generated by the hemodynamic instability cause classification model should be reported. For example, in FIG. 7, the 12% probability of hypovolemic cause is below a predetermined threshold and thus is not reported.

[0084] At 720, the probability or probabilities generated by the hemodynamic instability cause classification model are reported to a healthcare provider. The reported information may be provided by a user display such as a patient monitor or other device. In this instance, the hemodynamic instability cause classification model determines that cardiogenic causes have a 70% probability of causing the hemodynamic instability, and a 53% probability of septic causes. The notification can be any of the information as described or otherwise envisioned herein. The system may provide the information to a user via any mechanism, including but not limited to a visual display, an audible notification, a page, or any other method of notification. The information may be communicated by wired and / or wireless communication to another device. For example, the system may communicate the information to a mobile phone, computer, laptop, wearable device, and / or any other device configured to allow display and / or other communication of the information.

[0085] Referring to FIG. 2 is a schematic representation of system 200. System 200 may be any of the systems described or otherwise envisioned herein, and may comprise any of the components described or otherwise envisioned herein. It will be understood that FIG. 2 constitutes, in some respects, an abstraction and that the actual organization of the components of the system 200 may be different and more complex than illustrated.

[0086] According to an embodiment, system 200 comprises a processor 220 capable of executing instructions stored in memory 230 or storage 260 or otherwise processing data to, for example, perform one or more steps of the method. Processor 220 may be formed of one or multiple modules. Processor 220 may take any suitable form, including but not limited to a microprocessor, microcontroller, multiple microcontrollers, circuitry, field programmable gate array (FPGA), application-specific integrated circuit (ASIC), a single processor, or plural processors.

[0087] Memory 230 can take any suitable form, including a non-volatile memory and / or RAM. The memory 230 may include various memories such as, for example LI, L2, or L3 cache or system memory. As such, the memory 230 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices. The memory can store, among other things, an operating system. The RAM is used by the processor for the temporary storage of data. According to an embodiment, an operating system may contain code which, when executed by the processor, controls operation of one or more components of system 200. It will be apparent that, in embodiments where the processor implements one or more of the functions described herein in hardware, the software described as corresponding to such functionality in other embodiments may be omitted.

[0088] User interface 240 may include one or more devices for enabling communication with a user. The user interface can be any device or system that allows information to be conveyed and / or received, and may include a display, a mouse, and / or a keyboard for receiving user commands. In some embodiments, user interface 240 may include a command line interface or graphical user interface that may be presented to a remote terminal via communication interface 250. The user interface may be located with one or more other components of the system, or may located remote from the system and in communication via a wired and / or wireless communications network.

[0089] Communication interface 250 may include one or more devices for enabling communication with other hardware devices. For example, communication interface 250 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. Additionally, communication interface 250 may implement a TCP / IP stack for communication according to the TCP / IP protocols. Various alternative or additional hardware or configurations for communication interface 250 will be apparent.

[0090] Storage 260 may include one or more machine-readable storage media such as readonly memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. In various embodiments, storage 260 may store instructions for execution by processor 220 or data upon which processor 220 may operate. For example, storage 260 may store an operating system 261 for controlling various operations of system 200.

[0091] It will be apparent that various information described as stored in storage 260 may be additionally or alternatively stored in memory 230. In this respect, memory 230 may also be considered to constitute a storage device and storage 260 may be considered a memory. Various other arrangements will be apparent. Further, memory 230 and storage 260 may both be considered to be non-transitory machine-readable media. As used herein, the term non-transitory will be understood to exclude transitory signals but to include all forms of storage, including both volatile and non-volatile memories.

[0092] While system 200 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, processor 220 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where one or more components of system 200 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, processor 220 may include a first processor in a first server and a second processor in a second server. Many other variations and configurations are possible.

[0093] According to an embodiment, the system comprises an electronic medical record (EMR) database or system 270. Alternatively, the EMR database or system 270 may be a local or remotedatabase or system and thus the system may be in direct and / or indirect communication with the EMR database or system 270.

[0094] According to an embodiment, storage 260 of system 200 may store one or more algorithms, modules, and / or instructions to carry out one or more functions or steps of the methods described or otherwise envisioned herein. For example, the system may comprise, among other instructions, modules, or data, a trained hemodynamic stability index model 262, an outlier detection model 263, a cause classification model 264, training instructions 265, and / or reporting instructions 266.

[0095] According to an embodiment, the hemodynamic stability index model 262 is trained to classify a patient as likely to be hemodynamically stable or likely to be hemodynamically unstable, based on the patient information. The HSI model utilizes features extracted from patient information in order to predict, for a predetermined future time, a patient’s likelihood of experience hemodynamic instability. The predetermined future time may be any time period, such as minutes, hours, or days. A common, but non-limiting, example of a predetermined future time may be one (1) hour. The features extracted from patient information and utilized by the HSI model can include, for example, heart rate, blood pressure, hematocrit levels, temperature, blood oxygen levels, and many other possible features. The output of the HSI model can be, for example, an indication that either: (1) the patient is or is likely to be hemodynamically stable within the predetermined future time; or (2) the patient is or is likely to be hemodynamically unstable within the predetermined future time. Or, in other words, the patient is or is likely to experience hemodynamic instability within the predetermined future time.

[0096] According to an embodiment, outlier detection model 263 analyzes patient information for hemodynamically unstable patients. The outlier detection model is trained to determine, from the patient information, whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier. When the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, the patient and the patient information may be utilized as a training sample for the cause classification model, as described or otherwise envisioned herein. When the patient’s hemodynamic instability is likely to be an outlier, the patient and the patient information may be removed from the training dataset and will not be used as a training sample for the cause classification model. Alternatively, duringdeployment when the patient’s hemodynamic instability is likely to be an outlier, the patient and the patient information may not be analyzed by the cause classification model.

[0097] According to an embodiment, cause classification model 264 is trained to classify the patient’s hemodynamic instability as one or more of cardiogenic shock, septic shock, and hypovolemic shock when the trained outlier detection model determines that the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, or hypovolemic shock. According to one non-limiting embodiment, the classification model comprises a cardiogenic classifier, a septic classifier, and a hypovolemic classifier. According to an embodiment, the classification model is trained to generate a probability of each of the one or more of cardiogenic shock, septic shock, hypovolemic shock causing the patient’s hemodynamic instability.

[0098] According to an embodiment, training instructions 265 direct the system to train one or more of the outlier detection model 263 and the cause classification model 264, using a training dataset as described or otherwise envisioned herein. The training data can comprise any of the described patient information. The training data may be stored in and / or received from one or more databases. The database may be a local and / or remote database. The system trains the model, which will be the model utilized in analyzing the input information as described or otherwise envisioned. The model is trained using the training data set according to known methods for training a model. Following training, the trained model of the system is stored for future use. According to an embodiment, the model may be stored in local or remote storage. Thus, following training, system 200 comprises a trained outlier detection model 263 and / or a trained cause classification model 264.

[0099] According to an embodiment, reporting instructions 266 direct the system to provide the output of the system to a user, such as a clinician, via a user interface. The provided output can be any of the information as described or otherwise envisioned herein. The system may provide the information to a user via any mechanism, including but not limited to a visual display, an audible notification, a page, or any other method of notification. The information may be communicated by wired and / or wireless communication to another device. For example, the system may communicate the information to a mobile phone, computer, laptop, wearable device, and / or any other device configured to allow display and / or other communication of the information.

[0100] Within the context of the disclosure herein, aspects of the embodiments may take the form of a computer program product embodied in one or more non-transitory computer-readable media having computer readable program code embodied thereon. Thus, according to one embodiment is a non-transitory computer-readable storage medium comprising computer program code instructions which, when executed by a processor, enables the processor to carry out a method including: (i) receiving a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients; (ii) analyzing, by a trained hemodynamic stability index (HSI) model, the received patient information to classify each of the plurality of historical patients as likely to be hemodynamically unstable; (iii) analyzing, for each of the hemodynamically unstable patients, the received patient information by an outlier detection model to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; (iv) generating a final cause classification model training dataset by removing, from the preliminary cause classification model training dataset, each of the plurality of historical patients determined by the outlier detection model as being an outlier; and (v) training, using the final cause classification model training dataset, the hemodynamic instability cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock.

[0101] It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein. It should also be appreciated that terminology explicitly employed herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.

[0102] All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and / or ordinary meanings of the defined terms.

[0103] The indefinite articles “a” and “an,” as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.”

[0104] The phrase “and / or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and / or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and / or” clause, whether related or unrelated to those elements specifically identified.

[0105] As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified.

[0106] As used herein, although the terms first, second, third, etc. may be used herein to describe various elements or components, these elements or components should not be limited by these terms. These terms are only used to distinguish one element or component from another element or component. Thus, a first element or component discussed below could be termed a second element or component without departing from the teachings of the inventive concept.

[0107] Unless otherwise noted, when an element or component is said to be “connected to,” “coupled to,” or “adjacent to” another element or component, it will be understood that the element or component can be directly connected or coupled to the other element or component, or intervening elements or components may be present. That is, these and similar terms encompass cases where one or more intermediate elements or components may be employed to connect two elements or components. However, when an element or component is said to be “directly connected” to another element or component, this encompasses only cases where the two elements or components are connected to each other without any intermediate or intervening elements or components.

[0108] In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of’ and “consisting essentially of’ shall be closed or semi-closed transitional phrases, respectively.

[0109] It should also be understood that, unless clearly indicated to the contrary, in any methods claimed herein that include more than one step or act, the order of the steps or acts of the method is not necessarily limited to the order in which the steps or acts of the method are recited.

[0110] The above-described examples of the described subject matter can be implemented in any of numerous ways. For example, some aspects can be implemented using hardware, software or a combination thereof. When any aspect is implemented at least in part in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single device or computer or distributed among multiple devices / computers.

[0111] The present disclosure can be implemented as a system, a method, and / or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0112] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non- exhaustive list of more specific examples of the computer readable storage medium comprises the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves,electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0113] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0114] Computer readable program instructions for carrying out operations of the present disclosure can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, comprising an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions can execute entirely on the user’s computer, partly on the user’s computer, as a standalone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, comprising a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some examples, electronic circuitry comprising, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0115] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to examples of the disclosure. It will be understood that each block of theflowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0100] The computer readable program instructions can be provided to a processor of a, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture comprising instructions which implement aspects of the function / act specified in the flowchart and / or block diagram or blocks.

[0101] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0102] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various examples of the present disclosure. In this regard, each block in the flowchart or block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the Figures. For example, two blocks shown in succession can, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0103] Other implementations are within the scope of the following claims and other claims to which the applicant can be entitled.

[0104] While several inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and / or structures for performing the function and / or obtaining the results and / or one or more of the advantages described herein, and each of such variations and / or modifications is deemed to be within the scope of the inventive embodiments described herein. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and / or configurations will depend upon the specific application or applications for which the inventive teachings is / are used. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific inventive embodiments described herein. It is, therefore, to be understood that the foregoing embodiments are presented by way of example only and that, within the scope of the appended claims and equivalents thereto, inventive embodiments may be practiced otherwise than as specifically described and claimed. Inventive embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods, if such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent, is included within the inventive scope of the present disclosure.

Claims

ClaimsWhat is claimed is:

1. A computer-implement method for training a hemodynamic instability cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock, the method comprising: receiving a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients; analyzing, by a trained hemodynamic stability index (HSI) model, the received patient information to classify each of the plurality of historical patients as likely to be hemodynamically unstable; analyzing, for each of the hemodynamically unstable patients, the received patient information by an outlier detection model to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; generating a final cause classification model training dataset by removing, from the preliminary cause classification model training dataset, each of the plurality of historical patients determined by the outlier detection model as being an outlier; and training, using the final cause classification model training dataset, the hemodynamic instability cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock.

2. The computer- implement method of claim 1, wherein a cause of the determined outlier status for the patient’s hemodynamic instability is one or more of a neurogenic cause and an anaphylactic cause.

3. The computer- implement method of claims 1 or 2, further comprising the step of training, using a training dataset comprising patient information for a plurality of historical patients, the outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier.

4. The computer-implement method of any of claims 1-3, further comprising: receiving patient information about a current patient; analyzing the received patient information by the hemodynamic stability index (HSI) model to classify the current patient as likely to be hemodynamically unstable within a predetermined future time period; analyzing, for the hemodynamically unstable patient, the received patient information by an outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; providing, via a user interface when the outlier detection model determines the patient’s hemodynamic instability to likely to be an outlier, a notification of outlier status for the patient.

5. The computer-implement method of claim 4, further comprising: ordering, by the clinician, an intervention to determine a cause of the outlier status for the patient’s hemodynamic instability.

6. The computer-implement method of claims 4 or 5, wherein the user interface is a patient monitor.

7. The computer-implement method of any of claims 4-6, further comprising: analyzing, when the outlier detection model determines the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, or hypovolemic shock, the received patient information by a cause classification model to classify the patient’s hemodynamic instability as one or more of cardiogenic shock, septic shock, and hypovolemic shock, wherein the cause classification model is further configured to generate a probability of each of the one or more of cardiogenic shock, septic shock, hypovolemic shock causing the patient’s hemodynamic instability; providing, via a user interface, the classification of the patient’s hemodynamic instability with the probability of each of the one or more of cardiogenic shock, septic shock, and hypovolemic shock causing the patient’s hemodynamic instability.

8. The computer-implement method of claim 7, further comprising: ordering, by the clinician, an intervention to treat one or more of the cardiogenic shock, septic shock, and hypovolemic shock determined to cause the patient’s hemodynamic instability.

9. The computer-implement method of claim 8, wherein the intervention for cardiogenic shock comprises one or more of an inotrope and mechanical cardiac support, the intervention for hypovolemic shock comprises one or more of a transfusion or fluid bolus, and the intervention for septic shock comprises one or more of a vasopressor and an antibiotic.

10. A system for training a hemodynamic instability cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock, the system comprising: a preliminary cause classification model training dataset comprising patient information for each of a plurality of historical patients; a trained hemodynamic stability index (HSI) model trained to analyze patient information to classify a patient as likely to be hemodynamically stable or hemodynamically unstable; a trained outlier detection model configured to analyze patient information to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; a cause classification model; a processor configured to: (i) analyze, with the trained HSI model, the received patient information in the preliminary cause classification model training dataset to classify each of the plurality of historical patients as likely to be hemodynamically stable or hemodynamically unstable; (ii) analyze, for each of the hemodynamically unstable patients, the received patient information by the trained outlier detection model to determine whether that patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; (iii) generate a final cause classification model training dataset by removing, from the preliminary cause classification model training dataset, each of the plurality of historical patientsdetermined by the outlier detection model as being an outlier; and (iv) train, using the final cause classification model training dataset, the cause classification model to classify a patient’s determined likelihood of future hemodynamic instability as caused by one or more of cardiogenic shock, septic shock, and hypovolemic shock.

11. The system of claim 10, wherein a cause of the determined outlier status for the patient’s hemodynamic instability is one or more of a neurogenic cause and an anaphylactic cause.

12. The system of claims 10 or 11, wherein the processor is further configured to train, using a training dataset comprising patient information for a plurality of historical patients, the outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier.

13. The system of any of claims 10-12, wherein the processor is further configured to: (i) receive patient information about a current patient; (ii) analyze the received patient information by the hemodynamic stability index (HSI) model to classify the current patient as likely to be hemodynamically unstable within a predetermined future time period; (iii) analyze, for the hemodynamically unstable patient, the received patient information by an outlier detection model to determine whether the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, hypovolemic shock, or an outlier; and (iv) provide, via a user interface when the outlier detection model determines the patient’s hemodynamic instability to likely to be an outlier, a notification of outlier status for the patient.

14. The system of claim 13, wherein the processor is further configured to analyze, when the outlier detection model determines the patient’s hemodynamic instability is likely to be cardiogenic shock, septic shock, or hypovolemic shock, the received patient information by a cause classification model to classify the patient’s hemodynamic instability as one or more of cardiogenic shock, septic shock, and hypovolemic shock, wherein the cause classification model is further configured to generate a probability of each of the one or more of cardiogenic shock, septic shock, hypovolemic shock causing the patient’s hemodynamic instability; and provide, via a user interface, the classification of the patient’s hemodynamic instability with the probability of eachof the one or more of cardiogenic shock, septic shock, and hypovolemic shock causing the patient’s hemodynamic instability.

15. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of claims 1-9.

Images