Machine-readable programs, systems and methods for assessing patient status and risk

Abstract

The present disclosure is directed to computer-implemented methods, systems and processor-readable tangible non- transient media storing a computer program for assessing the likelihood of a hemodynamic event occurring with respect to a first patient based on analysis of physiological parameters. Some implementations include receiving patient physiological data via processor, performing an analysis of the patient physiological data via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to at least one of patient physiological data of a plurality of additional patients and prior physiological data of the first patient.

Description

[0001] MACHINE-READABLE PROGRAMS, SYSTEMS AND METHODS FOR ASSESSING PATIENT STATUS AND RISK

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] The present patent application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 566,553, filed March 18, 2024. The present patent application is incorporated by reference herein in its entirety for all purposes.

[0004] COPYRIGHT NOTICE

[0005] This application for letters patent disclosure document describes inventive aspects that include various novel innovations (hereinafter “disclosure”) and contains material that is subject to copyright, mask work, and / or other intellectual property protection. The respective owners of such intellectual property have no objection to the facsimile reproduction of the disclosure by anyone as it appears in published Patent Office file / records, but otherwise reserve all rights.

[0006] BACKGROUND

[0007] Various technologies exist for analyzing electronic medical record (“EMR”) data in order to assess patient condition. EMR data typically includes discrete measurements of patients (vital signs, labs, images, and more) made on an episodic basis ranging from once per day to several times per day. In the case of high-risk surgical and critically ill patients, this level of data fidelity does not always provide sufficient and timely resolution to assess patient conditions, which may deteriorate rapidly and require more urgent intervention. The present disclosure improves upon the state of the art, as disclosed herein below.

[0008] SUMMARY OF THE DISCLOSURE

[0009] The purposes and advantages of embodiments of the present disclosure will be set forth in and become apparent from the description that follows. Additional advantages of the disclosed embodiments will be realized and attained by the methods, systems, computer programs and mobile computing devices particularly pointed out in the written description hereof, as well as from the appended drawings.

[0010] In some aspects, the disclosure provides methods, systems and processor-readable tangible non- transient medium storing a computer program for assessing the likelihood of a hemodynamic event occurring with respect to a first patient based on analysis of physiological parameters that includes receiving patient physiological data via processor, performing an analysis of the patient physiological data via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to at least one of patient physiological data of a plurality of additional patients and prior physiological data of the first patient, and generating a signal for presenting a result of the analysis via processor.

[0011] In further accordance with the disclosure, the patient data can be received from a plurality of disparate computer systems, or from similar computer systems, or the same computer system. The patient physiological data can include at least one of patient monitoring data, patient medication data, patient intervention data, patient lab report data, patient imaging report data, patient history data, patient diagnosis data and clinician note data.

[0012] In accordance with some aspects, the patient monitoring data can include a high sampling rate waveform. The high sampling rate waveform can include at least one of an electrocardiogram (ECG) waveform, an invasive arterial blood pressure waveform, a plethysmography waveform, a central venous pressure (“CVP”) waveform, an intracranial pressure (“ICP”) waveform, a pulmonary artery pressure (“PAP”) waveform, and a respiration waveform (“Resp”), and end-tidal CO2 waveform (“EtCO2”).

[0013] In some implementations, the patient monitoring data can include at least one intermittently provided parameter from a patient monitor selected from the group consisting of non-invasive blood pressure (“NBP”), invasive blood pressure (“IBP”), heart rate (“HR”), patient temperature (“Temp”), arterial blood oxygen saturation (“SaO2” or “SpO2”), venous blood oxygen saturation (“SvO2” or “ScvO2”), sinus rhythm status, cardiac output (“CO”), depth of anesthesia (e.g. “BIS”), cerebral oxygen saturation, and alarm status (e.g. “ST” alarm or “QTc” alarm). If desired, the patient monitoring data can include at least one of a urinary output (“UO”) measurement, an echocardiography measurement, and cardiac output. In accordance with some aspects of the disclosure, the patient medication data can include data relating to at least one of medication administered continuously and medication administered intermittently. Medication administered continuously can include at least one of an intravenously administered medication, an intravenously administered fluid, a fluid administered by way of a feeding tube, a gas administered via a mask, endotracheal tube or a nasal cannula. Medication administered intermittently can include at least one of an orally administered medication, a bolus injection, and via the airway.

[0014] In accordance with some aspects of the disclosure, the patient intervention data can include at least one of data relating to administration of a beneficial agent, data relating to wound debridement, data relating to cardiac pacing, data relating to patient pronation, data relating to patient supination, data relating to patient airway changes, data relating to patient ventilation changes, and patient ambulation data.

[0015] In accordance with further aspects of the disclosure, the patient lab report data can include at least one of diagnostic test data, bacterial culture result data, blood analysis result data.

[0016] In accordance with some aspects of the disclosure, the blood analysis result data can include at least one of pH data, lactate data, blood gas analysis data, creatinine data, ion concentration data, protein concentration data, vitamin level data, and mineral level data.

[0017] If desired, the patient imaging report data can include at least one of cardiac mapping data, MRI data, X-ray data, ultrasound data, and echo imaging data. The patient history data can include at least one of previous patient hospitalization data, previous patient medical procedure data, previous patient medical event data, and patient comorbidity data. The patient diagnosis data can include at least one of primary diagnosis data relating to a current hospitalization event and subsequent diagnoses data generated during the current hospitalization event. The clinician note data can include at least one of medical doctor notes, nursing notes, patient mental status notes, patient pain event notes and patient nutrition notes.

[0018] In further accordance with the present disclosure, the signal can be configured to present the result in the form of an electronic medical record (“EMR”) flowsheet. If desired, the signal can be configured to present the result in the form of a graphical user interface.

[0019] In further accordance with the present disclosure, the analysis can be performed by a hemodynamic computation software module that is configured to analyze at least one measured patient parameter present in the patient physiological data to compute at least one advanced hemodynamic parameter. The measured patient parameter can include data from an electrocardiogram (ECG), a blood pressure value, data from a plethysmograph, a blood gas test result, a hemoglobin parameter, a hematocrit parameter, echocardiography data, and data from a Swan-Ganz catheter. At least one advanced hemodynamic parameter can include at least one of a cardiac output value, a stroke volume value, systemic vascular resistance (“SVR”), a delivered oxygen value, an oxygen demand vs supply gap value, a pulmonary vascular resistance (“PVR”) value, and ejection fraction (“EF”).

[0020] If desired, at least one measured patient parameter includes at least one respiration parameter or at least one ventilation parameter. At least one respiration parameter or at least one ventilation parameter can include at least one of an end-tidal carbon dioxide (ETCO2) parameter, a tidal volume parameter, a respiration rate parameter, a positive end-expiratory pressure (PEEP) parameter. At least one advanced hemodynamic parameter can be computed using the first patient’s arterial blood pressure waveform and demographic information of the first patient to compute at least one of cardiac output of the first patient, stroke volume of the first patient and systemic vascular resistance of the first patient. The demographic information of the first patient can include at least one of the age, sex, height, and weight of the first patient. In some implementations, at least one advanced hemodynamic parameter can be computed using pulse contour analysis or impedance cardiography, for example. In some implementations, the method, system, and computer program can include detecting an artifact in the patient physiological data based on the analysis.

[0021] In some implementations, at least one advanced hemodynamic parameter can be computed by analyzing at least one of an electrocardiogram (ECG), a blood pressure value, data from a plethysmography waveform and echocardiography data. If desired, at least one advanced hemodynamic parameter can relate to cardiac contractility. In some implementations, at least one advanced hemodynamic parameter can include at least one of ejection fraction and the maximum rate of arterial blood pressure increase during a single heartbeat (dP / dt(max)).

[0022] In some implementations, at least one advanced hemodynamic parameter can be an arterial elasticity parameter. The arterial elasticity parameter can be computed with reference to at least one of a current diagnosis of the first patient, a patient history of the first patient, a pulse wave velocity measurement, a pulse pressure amplification measurement, and a dynamic arterial elastance (Ea, dyn) measurement. In some implementations, at least one advanced hemodynamic parameter can be a central blood pressure parameter. If desired, the central blood pressure parameter can be computed by analyzing at least one peripheral arterial blood pressure waveform. At least one peripheral blood pressure waveform can be selected from the group consisting of a radial arterial blood pressure waveform, a brachial arterial blood pressure waveform, a femoral arterial blood pressure waveform, and a dorsalis pedis arterial blood pressure waveform. If desired, at least one advanced hemodynamic parameter can be a pulmonary vascular resistance (PVR) parameter. The PVR parameter can be computed with reference to a pulmonary artery pressure (PAP) waveform, for example. If desired, the PVR parameter can be computed by applying a multibeat analysis (“MBA”) algorithm to the PAP waveform. If desired, the method, system and machine-readable program can further include computing cardiac output (CO) using a multi-beat analysis with reference to the PAP waveform.

[0023] In accordance with further implementations of the disclosure, the analysis can be performed at least in part by a circulatory shock software module that is configured to profile a circulatory shock state. If desired, the analysis can be performed at least in part by a circulatory shock software module that is configured to profile a circulatory shock state based at least in part on an output of the hemodynamic computation software module. The circulatory shock software module can profile the circulatory shock state as having a specific endotype. The circulatory shock software module can profile the circulatory shock state as having a contribution from at least one etiology. At least one etiology can be selected from the group consisting of a vasodilatory etiology, a hypovolemic etiology, or a cardiogenic etiology. The circulatory shock software module can be configured to be a self-learning module based on accumulating data of at least one of hemodynamics, respiration, interventions, medications, diagnoses, lab results, patient histories, diagnoses and clinical notes. If desired, the circulatory shock software module can reference a fixed database in order to profile the circulatory shock state.

[0024] In some implementations, the circulatory shock software module can reference a database that accumulates additional data over time in order to profile the circulatory shock state. If desired, the circulatory shock module can be configured to classify a hypotensive event as belonging to a specific etiology class. The circulatory shock module can be configured to associate a dominant etiology class with the hypotensive event. The circulatory shock module can be configured to compute a probability for associating each of a plurality of etiology classes with the hypotensive event. The circulatory shock module can be configured to compute a contribution to the hypotensive event attributable to each of the etiology classes. The circulatory shock module can be configured to determine the contribution to the hypotensive event attributable to each of the etiology classes by classifying the patient physiological data with a software-based classifier. The circulatory shock module can be configured to determine the contribution to the hypotensive event attributable to each of the etiology classes by classifying computed advanced hemodynamic variables including at least one of Cardiac Output (CO), Cardiac Index (CI), Stroke Volume (SV), SV Index (SVI), Systemic Vascular Resistance (SVR), SVR Index (SVRI), Mean Arterial Pressure (MAP), Heart rate (HR), Central Venous Pressure (CVP) and Pulse Pressure Variation (PPV).

[0025] In some implementations, the software-based classifier can include a supervised artificial intelligence (“Al”) classifier. The supervised Al classifier can be implemented using at least one of an artificial neural network, regression trees, and ensemble classification methods. The supervised Al classifier can be trained on at least one of discrete values patient physiological data, waveform patterns and waveform features.

[0026] In some implementations, the software-based classifier can include an unsupervised Al classifier. The unsupervised Al classifier can be configured to identify at least one endotype of hypotension by way of hierarchical clustering of the patient physiological data. At least one hypotension endotype can correspond to at least one pre-defined endotype cluster. The predefined endotype cluster can correspond to myocardial depression, bradycardia, vasodilation without cardiac index increase, vasodilation with cardiac index increase, hypovolemia or mixed type, for example. If desired, the endotype cluster can be user-selectable. In some implementations, a user can select if a selected endotype cluster is displayed automatically on detection of a hypotensive episode. If desired, a user can select if a selected endotype cluster is displayed. In some cases, the unsupervised Al classifier can be trained based on a population of patients. The population of patients can include at least one of an all-ICU patient population pooled over multiple health care facilities, and a single ICU at a single healthcare facility. If desired, the patient physiological data can be updated over time to include new data. In some implementations, the contribution to the hypotensive event attributable to each of the etiology classes can be determined using at least one of Euclidean distance measures and Mahalanobis distance measures from a pre-determined cluster center, wherein the smallest distance measured corresponds to a dominant endotype or dominant etiology.

[0027] In some implementations, the software-based classifier can include a user-defined classifier. The user-defined classifier can be configured to permit an end-user to define classification rules via a user interface. The user-defined classifier can include a threshold-based classifier wherein a threshold for at least one parameter is configured to be user-selectable. A boolean or a fuzzy logic method can be used to discriminate among different shock types based on the classification rules. The software-based classifier can be configured to act in near-real time on newly presented data to classify a current state of the first patient or to report a probability or confidence level that the first patient falls into one or more specific etiologies or endotypes.

[0028] In further accordance with the present disclosure, the analysis can be performed at least in part by a hemodynamic risk level software module that is configured to compute a risk to the first patient of deterioration based on the patient physiological data and / or planned interventions, such as medication administration. The hemodynamic risk level software module can be configured to compute the risk of deterioration to the first patient based at least in part on at least one cardiovascular parameter selected from the group consisting of blood pressure (BP), mean arterial pressure (MAP), pulse pressure (PP) , heart rate (HR), cardiac output (CO), cardiac index (CI), cardiac stroke volume (SV), cardiac stroke volume index (SVI), systemic vascular resistance (SVR), systemic vascular resistance index (SVRI), arterial pulse pressure variation (PPV), stroke volume variation (SVV), a presence of dysrhythmia, a ECG waveform feature, a blood pressure waveform feature, a plethysmography waveform feature, ejection fraction (EF), dPZdt(max), Eadyn, pulmonary vascular resistance (PVR), pulmonary arterial pressure (PAP), aortic blood pressure, pulse wave velocity (PWV), and pulse pressure (PP) amplification index.

[0029] The hemodynamic risk level software module can be further configured to compute the risk of deterioration to the patient upon receiving information from an infusion pump and / or EMR system about a medication that is about to be infused. Such medications as fluids, vasoactive drugs, inotropic drugs, chronotropic drugs, and others that may have hemodynamic effects can be compared to a patient’s current hemodynamic status to assess their potential effect and risk of inducing hemodynamic instability. For example, midazolam is commonly used as a sedative and can have a vasodilatory effect. Such a medication would be risky to use on a patient who is already vasodilated and borderline hypotensive, for example. The software module, upon receiving the information about the planned medication infusion and comparing this medication to the patient’s hemodynamic status alerts the user about the impending drug-hemodynamic interaction and potential risk for hemodynamic instability.

[0030] The hemodynamic risk level software module can be configured to compute the risk of deterioration to the first patient based at least in part on at least one of hemoglobin data, hematocrit data, lab result data, arterial blood gas (“ABG”) test data, urine output data, respiration data, ventilation data, tidal volume data, positive end-expiratory pressure (PEEP) data, end-tidal carbon dioxide (ETCO2) waveform data, respiration rate data, patient medical history data, current diagnosis data, and patient intervention history data. Data used by the hemodynamic risk level software module can be used as inputs in a machine learning model to determine the risk of deterioration of the first patient. The result can identify the risk, a risk level, and at least one probable cause of the risk in a graphical user interface. The risk can be selected from the group consisting of cardiac arrest, respiratory arrest, stroke, hypotension, and hypovolemia.

[0031] In further accordance with the present disclosure, the analysis can be performed at least in part by a hemodynamic clinical decision support software module that is configured to analyze the patient physiological data via processor and, based on the analysis, issue a recommendation at least one of a therapy, an intervention, and a further test for the first patient. The hemodynamic clinical decision support software module can base the recommendation on an output of at least one of a hemodynamic computation software module, a circulatory shock software module, and a risk profiling software module. The patient physiological data can include aggregated patient data from a single health care institution. The patient physiological data can include aggregated patient data from a plurality of health care institutions. The hemodynamic clinical decision support software module can provide a data summary that compares a result for the first patient to results of other patients from the patient physiological data. The data summary can characterize the success of a specific intervention, therapy or test for the other patients. The result can indicate a risk of a specific diagnosis of the first patient. The result can indicate a high probability of a risk of at least one of sepsis, bleed, myocardial injury and acute kidney injury (AKI). The hemodynamic clinical decision support software module can be configured to recommend a medication for treating a hemodynamic insufficiency of the first patient based at least in part on previous medications administered to the first patient.

[0032] In some implementations, the hemodynamic clinical decision support software module can be configured to provides a user with at least one warning of a known drug-drug interaction or at least one warning relating to a risk of a particular drug specific to a patient’s hemodynamic condition, wherein at least one warning is based at least in part on taking into account at least one drug that was previously administered to the first patient. At least one warning can be based on a drug-drug interaction and / or on pharmaco-kinetic aspects of at least one drug. At least one warning can be based on a device-drug interaction. At least one warning can be based at least in part on a device setting or a rate of fluid administration.

[0033] In accordance with further implementations, the method, system and machine-readable program can further include automatically dispensing a therapy based on the result of the analysis. Dispensing the therapy can be based in order to cause a cardiac parameter to change toward a target value. The target value can include at least one of a target blood pressure, a target cardiac output, a target oxygen delivery, and a target hemoglobin concentration.

[0034] The disclosure further provides systems for assessing likelihood of a hemodynamic event occurring with respect to a first patient based on analysis of physiological parameters. The system includes a first circuit configured and arranged to receive patient physiological data via processor, a second circuit configured and arranged to perform an analysis of the patient physiological data via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to at least one of patient physiological data of a plurality of additional patients and prior physiological data of the first patient, and a third circuit configured and arranged to generate a signal for presenting a result of the analysis via processor. The system can be programmed or otherwise equipped with additional functionality as described above and elsewhere herein.

[0035] The disclosure further provides implementations of a processor-readable tangible nontransient medium storing a computer program for assessing likelihood of a hemodynamic event occurring with respect to a first patient based on analysis of physiological parameters. The computer program includes a first set of instructions to receive patient physiological data via processor, a second set of instructions to perform an analysis of the patient physiological data via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to at least one of patient physiological data of a plurality of additional patients and prior physiological data of the first patient, and a third set of instructions to generate a signal for presenting a result of the analysis via processor. The accompanying drawings, which are incorporated in and constitute part of this specification, are included to illustrate and provide a further understanding of the methods and systems of the disclosure. Together with the description, the drawings serve to explain the principles of the disclosed embodiments.

[0036] BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The accompanying drawings illustrate various non-limiting, example, innovative aspects in accordance with the present descriptions:

[0038] FIGS. 1A-1D are illustrative graphical user interface (GUI) displays to communicate shock -related information to a user in accordance with the present disclosure.

[0039] FIG. 2 is a schematic illustrating aspects of an implementation of a hypotension classifier in accordance with the present disclosure.

[0040] FIG. 3 is a schematic illustrating aspects of an implementation of a compensated circulatory shock detection and etiology classifier n accordance with the present disclosure.

[0041] FIG. 4 is a schematic illustrating aspects of a hierarchical clustering algorithm for unsupervised learning of hypotension endotypes.

[0042] FIG. 5 is a schematic illustrating aspects of a therapy user interface (UI) in accordance with the present disclosure.

[0043] FIG. 6 is a schematic illustrating aspects of a risk level indicator user interface (UI) in accordance with the present disclosure.

[0044] FIG. 7 shows a schematic block diagram illustrating aspects of system use and interactions in some of the disclosed embodiments.

[0045] FIG. 8 illustrates the grouping of data into six clusters that map to six physiological shock states

[0046] FIG. 9 shows a block diagram illustrating some aspects of a system controller in accordance with the present disclosure.

[0047] DETAILED DESCRIPTION

[0048] This disclosure describes apparatuses, methods, systems and machine-readable computer programs for assessing hemodynamic risk, particularly for to critically ill patients based on an analysis of physiological parameters. It will be further appreciated that, while this detailed description section particularly illustrates some aspects of the disclosed systems, the illustrated principles in the figures and related text, etc. relate and enable all disclosed embodiments throughout this disclosure.

[0049] The accompanying drawings, which are incorporated in and constitute part of this specification, are included to illustrate and provide a further understanding of the methods and systems of the disclosure. Together with the description, the drawings serve to explain the principles of the disclosed embodiments.

[0050] Various technologies exist for analyzing electronic medical record (“EMR”) data in order to assess patient condition. An EMR is a digital electronic of medical information about a patient that is stored on a computer. An electronic medical record includes information about a patient’s health history, such as vital signs, diagnoses, medicines, tests, allergies, immunizations, and treatment plans. These records typically represent collections of intermittent “episodic” data that is updated as new data become available. In general, data updates for various parameters range from once every minute (e.g. vital signs) to once every hospitalization stay (e.g. MRI).

[0051] Current technologies, including those based on artificial intelligence (Al), use data from EMRs to find relationships between parameters and characterize a wide variety of patient risks such as infection, vital organ injury, medical errors, etc. However, they are fundamentally limited by the time resolution of the underlying EMR data (at most minute-by-minute). In particular, they are unable to characterize cardio-respiratory physiology due to the faster timescales involved (milliseconds to minutes timescale). For example, rich variation exists in continuous patient waveforms sampled at a high sampling rate (-100 or more samples every second) such as an electrocardiogram or arterial blood pressure. There is a resulting loss of information when this information is summarized and saved in the EMR as a single number every minute.

[0052] In contrast to known systems, Applicant provides herewith improved implementations for collecting and analyzing data to provide insightful guidance to clinicians to help provide more effective patient care. The disclosed embodiments are preferably implemented in a clinical environment such as a hospital to provide close monitoring to patients in an intensive care unit (ICU) as illustrated, for example, in FIG 7. Notably, rather than merely aggregating typical EMR data, various implementations of the disclosed embodiments synthesize additional useful data in the form of advanced hemodynamic parameters from continuously monitored patient biosignals. For example, certain of the disclosed embodiments are configured to extract advanced hemodynamic parameters from high fidelity waveforms that comprise these continuously monitored patient biosignals. These advanced hemodynamic parameters can yield a great deal more information when analyzed either alone, or in combination with traditional EMR data, particularly when compared against a large patient population.

[0053] When so implemented, the disclosed embodiments have demonstrated an uncanny ability to predict various cardiorespiratory events, which permits clinicians to act sooner, thereby leading to considerably improved patient outcomes. To Applicant’s knowledge, the predictive quality of the disclosed implementations is unique and unprecedented in the medical field.

[0054] Implementations in accordance with the present disclosure utilize a system architecture that can be “on the cloud” and / or on local systems (in a centralized or distributed manner, see FIG. 7) as desired. Data from many patients can be aggregated, for example, to search for additional patterns in the data to improve the accuracy of the predictive nature of the system. Various algorithms can be used to analyze the data, to compute additional variable and to compute the probability of different occurrences in the future for a particular patient. Advanced hemodynamic parameters can be computed for a population of patients based on data of those patients, and those hemodynamic parameters can be correlated with hemodynamic events of those patients. Those same advanced hemodynamic parameters can then be computed, preferably continuously, based at least in part on data of a particular patient. Those hemodynamic parameters can be computed based on extracting data from high fidelity waveforms. The advanced hemodynamic parameters computed for a particular patient can be compared with the same parameters for various patient populations. Depending on how each advanced hemodynamic parameter compares with the data of other patients, it is possible to extract trends that in turn correlate with the probability of a particular cardiorespiratory event occurring in the future, sometimes the near future, for that particular patient. Moreover, ss those advanced hemodynamic parameters are computed over time, a directionality (that is to say, a “vector”) may be observed in one or more of the computed advanced hemodynamic parameters (e.g, whether the parameter is going up or down, and at what rate), from which even more meaningful predictions can be made based on various data analyses.

[0055] For purposes of illustration only, and not limitation, in accordance with the present disclosure, data from 870 critically ill patients in an ICU were analyzed. In ICU patients, hypotension (low BP) is a dangerous cardiorespiratory event that requires prompt treatment. The underlying cause and the appropriate treatment of hypotension is not clear from EMR data. From patients’ high-fidelity arterial BP waveforms, cardiac output and other advanced hemodynamic parameters were computed. An AVmachine learning method called Ward’s hierarchical clustering was used to group data into naturally occurring ‘clusters’, which showed the emergence of six clusters which map to six physiological shock states (FIG. 8). This allows clinicians to identify the shock endotype and make appropriate treatment decisions tailored to the specific cause of shock. Accordingly, implementations of the presently disclosed embodiments can provide additional clinical insight by application of Al to high fidelity waveforms.

[0056] The likelihood that a particular patient is experiencing a specific shock endotype can be obtained by comparing the relative closeness of the current data to each of the six cluster centers (i.e. ‘stereotypical’ shock endotypes) obtained from a larger population of patients. There are multiple ways to compute the relative closeness to each of the six cluster centers, such as the Euclidean distance or the Mahalanobis distance, with a lower distance corresponding to a higher likelihood of the patient experiencing that endotype. The results can be displayed on a user interface (see, e.g., FIGS. 1A-1D) that communicates graphically what hypotension shock type is likely to occur, and what underlying factors are contributing to that event occurring with respect to a particular patient.

[0057] In further accordance with the disclosure, the patient data can be received from a plurality of disparate computer systems, or from similar computer systems, or the same computer system. FIG. 7 illustrates a suitable architecture at a system level. In the illustrated system diagram, a central server may be provided that is located within a hospital, or on the cloud. The server is preferably connected by network connection to a central station within a hospital that collects facility-wide telemetry data from EMRs, clinician inputs and bedside patient monitors. This data is aggregated and analyzed as disclosed herein to compute advanced hemodynamic parameters that can be further analyzed and correlated with patient outcomes in the general patient population to then facilitate computing the probability of similar outcomes for a particular patent based on the continuous computation of that particular patient’s advanced hemodynamic parameters based on continuously extracting data from high-fidelity waveforms as well as more conventional data as described herein below.

[0058] Thus, the disclosed embodiments facilitate assessment of the likelihood of a hemodynamic event occurring with respect to a first patient, and this is based on analysis of physiological parameters that are present in patient physiological data that is received by the system via processor. At a high level, this patient physiological data is then analyzed via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to patient physiological data of a plurality of additional patients and / or prior physiological data of the first patient.

[0059] As alluded to above, the patient physiological data can take on many forms. The term patient physiological data includes data for a particular patent, as well as data from a larger population of patients. This data can include, for example, patient monitoring data (such as from patient bedside monitors or from a central telemetry station in a hospital), patient medication data, patient intervention data, patient lab report data, patient imaging report data, patient history data, patient diagnosis data and clinician note data.

[0060] As mentioned above, the patient monitoring data can also include advanced hemodynamic parameters that are computed from a high fidelity, high sampling rate waveform. Such a waveform is typically collected continuously, thereby facilitation continuously computing and tracking those advanced hemodynamic parameters over time. The high sampling rate waveform can include, for example, an electrocardiogram (ECG) waveform, an invasive arterial blood pressure waveform, a plethysmography waveform, a central venous pressure (“CVP”) waveform, an intracranial pressure (“ICP”) waveform, a pulmonary artery pressure (“PAP”) waveform, and a respiration waveform (“Resp”), and / or an end-tidal CO2 waveform (“EtCO2”), among others.

[0061] The patient monitoring data can additionally include at least one intermittently (episodic) provided parameter from a patient monitor, such as non-invasive blood pressure (“NBP”), invasive blood pressure (“IBP”), heart rate (“HR”), patient temperature (“Temp”), arterial blood oxygen saturation (“SaO2” or “SpO2”), venous blood oxygen saturation (“SvO2” or “ScvO2”), sinus rhythm status, cardiac output (“CO”), depth of anesthesia (e.g. “BIS”), cerebral oxygen saturation, and alarm status (e.g. “ST” alarm or “QTc” alarm). Patient monitoring data can additionally include at least one of a urinary output (“UO”) measurement, an echocardiography measurement, and cardiac output.

[0062] The trend over different time scales of the previously mentioned patient monitoring and lab report data constitutes an additional set of inputs to the analysis. Likewise, trends in computed parameters such as cardiac output or stroke volume are also inputs for analysis of cardiorespiratory events and risks. For example, a deterioration of stroke volume by 30 ml over a period of 1 day may be acceptable in terms of cardiorespiratory risk, but can signal urgent investigation and treatment if the same deterioration happens over 5 minutes.

[0063] The patient medication data can include data relating to at least one of medication administered continuously and medication administered intermittently. Medication administered continuously can include at least one of an intravenously administered medication, an intravenously administered fluid, a fluid administered by way of a feeding tube, a gas administered via a mask, endotracheal tube or a nasal cannula. Medication administered intermittently can include at least one of an orally administered medication, a bolus injection, and via the airway.

[0064] The patient intervention data can include at least one of data relating to administration of a beneficial agent, data relating to wound debridement, data relating to cardiac pacing, data relating to patient pronation, data relating to patient supination, data relating to patient airway changes, data relating to patient ventilation changes, and patient ambulation data. The patient lab report data can include at least one of diagnostic test data, bacterial culture result data, blood analysis result data. The blood analysis result data can include at least one of pH data, lactate data, blood gas analysis data, creatinine data, ion concentration data, protein concentration data, vitamin level data, and mineral level data.

[0065] The patient imaging report data can include cardiac mapping data, MRI data, X-ray data, ultrasound data, and echo imaging data. The patient history data can previous patient hospitalization data, previous patient medical procedure data, previous patient medical event data, and patient comorbidity data. The patient diagnosis data can include primary diagnosis data relating to a current hospitalization event and subsequent diagnoses data generated during the current hospitalization event. The clinician note data can include medical doctor notes, nursing notes, patient mental status notes, patient pain event notes and patient nutrition notes. In further accordance with the present disclosure, the signal can be configured to present the result in the form of an electronic medical record (“EMR”) flowsheet. If desired, the signal can be configured to present the result in the form of a graphical user interface.

[0066] Advanced Hemodynamic Parameter Computation

[0067] In accordance with the present disclosure, advanced hemodynamic parameters can be computed. In some embodiments this can be implemented in a hemodynamic computation software module that is configured to analyze patient physiological data.

[0068] For example, a measured patient electrocardiogram (ECG) can be used to compute an advanced hemodynamic parameter. The parameter can also be computed using a blood pressure value, data from a plethysmograph, a blood gas test result, a hemoglobin parameter, a hematocrit parameter, echocardiography data, and data from a Swan-Ganz catheter, for example.

[0069] Various advanced hemodynamic parameters can be computed in accordance with the present disclosure, including, for example, a cardiac output (“CO”) value, a stroke volume value, systemic vascular resistance (“SVR”), a delivered oxygen value, an oxygen demand vs supply gap value, a pulmonary vascular resistance (“PVR”) value, and / or an ejection fraction (“EF”).

[0070] The advanced hemodynamic parameter can be computed using the first patient’s arterial blood pressure waveform and demographic information of the first patient. For example, these inputs can be used to compute, for example, the cardiac output of a first patient, a stroke volume of the patient and systemic vascular resistance of the patient. The demographic information of the patient can include, for example, the age, sex, height, and weight of the patient. In some embodiments, at least one advanced hemodynamic parameter can be computed using pulse contour analysis or impedance cardiography.

[0071] If desired, at least one advanced hemodynamic parameter can relate to cardiac contractility. In some implementations, at least one advanced hemodynamic parameter can include at least one of ejection fraction and the maximum rate of arterial blood pressure increase during a single heartbeat (dP / dt(max)). The ejection fraction can be computed, for purposes of illustration only, from a BP waveform using an algorithm that is described in U.S. Patent No. . 8,282,569 and U.S. Patent No. 8,235,910, wherein each of said patents is hereby incorporated by reference herein in its entirety for all purposes. By way of further example, additional measured patient parameters can be used to compute advanced hemodynamic parameters, such as a respiration parameter and / or a ventilation parameter. The respiration parameter or ventilation parameter can include, for example, an end- tidal carbon dioxide (ETCO2) parameter, a tidal volume parameter, a respiration rate parameter, a positive end-expiratory pressure (PEEP) parameter.

[0072] Alternatively, the advanced hemodynamic parameter can include an arterial elasticity parameter. The arterial elasticity parameter can be computed with reference to at least one of a current diagnosis of the first patient, a patient history of the first patient, a pulse wave velocity measurement, a pulse pressure amplification measurement, and a dynamic arterial elastance (Ea, dyn) measurement.

[0073] In some implementations, at least one advanced hemodynamic parameter can be a central blood pressure parameter. If desired, the central blood pressure parameter can be computed by analyzing at least one peripheral arterial blood pressure waveform. At least one peripheral blood pressure waveform can be selected from the group consisting of a radial arterial blood pressure waveform, a brachial arterial blood pressure waveform, a femoral arterial blood pressure waveform, and a dorsalis pedis arterial blood pressure waveform. If desired, at least one advanced hemodynamic parameter can be a pulmonary vascular resistance (PVR) parameter. The PVR parameter can be computed with reference to a pulmonary artery pressure (PAP) waveform, for example. If desired, the PVR parameter can be computed by applying a multibeat analysis (“MBA”) algorithm to the PAP waveform. If desired, the method, system and machine-readable program can further include computing cardiac output (CO) using a multi-beat analysis with reference to the PAP waveform. Aspects of a suitable MBA algorithm as well as other algorithms are discussed in U.S. Patent No. 7,666,144, U.S. Patent No. 7,815,578, U.S. Patent No. 8,273,031, U.S. Patent No. 8,282,569, U.S. Patent No. 9,289,133, and U.S. Patent No. 10,349,838. Each of the aforementioned U.S. Patents is hereby incorporated by reference in its entirety for all purposes.

[0074] In some implementations, the method, system, and computer program can include detecting an artifact in the patient physiological data based on the analysis. Patient monitoring data is sometimes distorted by non-physiological reasons such as sensor movement, sensor dislocation, electromagnetic disturbances etc. The ability to detect and reject these artifacts is important as any analysis performed on artifactual data can result in incorrect results. The ability to detect artifacts can be used to indicate a “signal quality index” to the user.

[0075] Circulatory Shock Computation

[0076] In further accordance with the present disclosure, advanced hemodynamic parameters and additional data can be analyzed to identify when a patient is in a state of circulatory derangement. In some embodiments this can be implemented in a customized a circulatory shock software module.

[0077] Patients are often in a state of circulatory derangement which do not present as obvious signs of shock (e.g. hypotension, low urinary output). These states include ‘compensated’ shock, where the patient compensates to keep mean arterial pressure (“MAP”) in a normal range by increasing heart rate, contractility or vasomotor tone, for example. Implementations in accordance with the present disclosure can detect signs of such circulatory abnormalities. This approach can be based on using advanced hemodynamic monitoring data as inputs, along with other information such as patient demographic data. Compensated circulatory shock is detected by the techniques listed above. Determination of compensated shock also uses trends / changes in the advanced hemodynamic parameters over clinically relevant time periods, in addition to the current values of the parameters.

[0078] As mentioned above, the analysis can be performed at least in part by a circulatory shock software module that is configured to profile a circulatory shock state. Inputs into this module can include outputs of the hemodynamic computation software module described above, and / or additional patient data inputs. This process can typically be expected to result in the circulatory shock state as having a specific endotype. Preferably, the state of the patient can be profiled as having a contribution from one or more etiologies. Examples of etiologies can include, for example, a vasodilatory etiology, a hypovolemic etiology, and a cardiogenic etiology.

[0079] If desired, the circulatory shock module can be configured to classify a hypotensive event as belonging to a specific etiology class. The circulatory shock module can be configured to associate a dominant etiology class with the hypotensive event. The circulatory shock module can be configured to compute a probability for associating each of a plurality of etiology classes with the hypotensive event. The circulatory shock module can be configured to compute a contribution to the hypotensive event attributable to each of the etiology classes. For purposes of illustrate, and not limitation, the outputs of this shock analysis can be displayed graphically to provide a clinician with an intuitive sense of the contributions to the shock state by each applicable etiology. For example, with reference to FIG. 1A, the result can effectively be mapped onto a multidimensional space to indicate how much each of a cardiogenic, vasodilatory and hypovolemic component have contributed to the patient’s state. While the result is expressed in the UI of FIG. 1 A as a point value, it will be appreciated that the state can also be expressed as an arrow, or vector with a direction that is based on computing the state multiple times over a time period to capture the directionality of the patient’s shock state. This element of directionality can provide additional insight to the clinician in understanding the patient’s condition. FIG. IB is an example of a data output in a UI that expresses the relative magnitudes of each etiological component of a hypotension etiology, whereas FIG. 1C expresses these data as a probability components of a hypotensive shock etiology. FIG. ID provides a UI listing the computed magnitude of the probability that each of a plurality of hypotension endotypes contributes to a patient’s condition.

[0080] The circulatory shock module can be configured to determine the contribution to the hypotensive event attributable to each of the etiology classes by classifying the patient physiological data with a software-based classifier. The circulatory shock module can be configured to determine the contribution to the hypotensive event attributable to each of the etiology classes by classifying computed advanced hemodynamic variables including at least one of Cardiac Output (CO), Cardiac Index (CI), Stroke Volume (SV), SV Index (SVI), Systemic Vascular Resistance (SVR), SVR Index (SVRI), Mean Arterial Pressure (MAP), Heart rate (HR), Central Venous Pressure (CVP) and Pulse Pressure Variation (PPV).

[0081] The circulatory shock software module can be configured to be a self-learning module based on accumulating data of at least one of hemodynamics, respiration, interventions, medications, diagnoses, lab results, patient histories, diagnoses and clinical notes. If desired, the circulatory shock software module can reference a fixed database in order to profile the circulatory shock state. If desired, the circulatory shock software module can reference a database that accumulates additional data over time in order to profile the circulatory shock state.

[0082] The software-based classifier can include a supervised artificial intelligence (“Al”) classifier. The supervised Al classifier can be implemented using at least one of an artificial neural network, regression trees, and ensemble classification methods. The supervised Al classifier can be trained on at least one of discrete values patient physiological data, waveform patterns and waveform features.

[0083] For purposes of illustration only, and with reference to FIG. 2 illustrates an example of an Al classifier for hypotension. This classifier includes an input layer that is configured to receive a plurality of inputs including computed advanced hemodynamic parameters (e.g., CI, SVRI. ..) as well as additional patient data (e.g., age, sex, weight.. .).

[0084] The classifier analyzes these inputs via multiple architectures such as an artificial neural network (ANN) (FIG. 2, 3). An ANN consists of multiple ‘nodes’ arranged in a multilayer topology, with the nodes in a layer receiving weighted inputs from the nodes in a previous layer. The nodes typically perform simple non-linear computations, and the ANN ‘learns’ patterns in the data by adjusting the weights between nodes. The end layer is often the output layer which generates the probability of each endotype contributing to the hypotension. Other AVMachine learning architectures such as clustering, fuzzy logic, support vector machines etc. may be used to perform the classification. The hypotensive event attributable to each of the etiology classes can be determined, for example, using at least one of Euclidean distance measures and Mahalanobis distance measures from a pre-determined cluster center, wherein the smallest distance measured corresponds to a dominant endotype or dominant etiology.

[0085] In some implementations, the following steps can be performed from data analysis to shock detection in a particular patient:

[0086] Gather the input data consisting of patient physiological parameters from a plurality of patients.

[0087] Preprocess the data (filtering, artifact detection / removal, alternate domain representation).

[0088] Standardize the data (unspool time series data, principal / independent component analysis, standardizati on / norm al izati on) .

[0089] Create n-dimensional input feature vector.

[0090] Implement Al / machine learning methods (supervised or unsupervised classifiers) on the set of input feature vectors in the population, to create classification rules. An example of a classification rule is: assign the class corresponding to the smallest Euclidean distance to a class center. To classify a patient state in real time: repeat above steps until creation of the n- dimensional feature vector.

[0091] Apply classification rule to the n-dimensional feature vector to obtain class type. This step involves analysis of a single feature vector as is therefore computable in real time.

[0092] Display class type to the user.

[0093] It is also contemplated to use a modified Euclidean distance or Mahalanobis distance that reflects clinical inputs. The algorithm can include an assessment of the direction of the distance to help determined, for example, whether a patient is more strongly within an endotype or whether a patient is borderline between two or more categories.

[0094] FIG. 3 presents an illustrative implementation of a compensated circulatory shock detection and etiology classifier that provides further layers of analysis and algorithms to indicate if it appears that the patient is exhibiting signs of shock based on patterns detected in underlying data that has not yet manifested itself in the form of obviously observable symptoms. In use, the system of FIG. 3 operates in a manner wherein the upper part of the diagram including the first classifier will be operation when hypotension is present. When no hypotension is detected the lower portion of the classifier relating to the compensated shock computations is operational.

[0095] In some implementations, the software-based classifier can include an unsupervised Al classifier. The unsupervised Al classifier can be configured to identify at least one endotype of hypotension by way of hierarchical clustering of the patient physiological data.

[0096] For purpose of illustration only, FIG. 4 presents a hypotensive endotypes dendrogram resulting from a hierarchical clustering algorithm for unsupervised learning of hypotension endotypes. Such an Al classifier can be trained on a suitable dataset. The training data used can be generic, such as an all-ICU patient population pooled over multiple hospitals. Alternatively, the classifier can be trained using specific data from a single ICT at a hospital. This classifier can be updated over time to include new data to enhance the ability of the classifier to uncover additional insights from the data.

[0097] Within the unsupervised Al classifier, at least one hypotension endotype can correspond to at least one pre-defined endotype cluster. The pre-defined endotype cluster can correspond to myocardial depression, bradycardia, vasodilation without cardiac index increase, vasodilation with cardiac index increase, hypovolemia or mixed type, for example. If desired, the endotype cluster can be user-selectable. In some implementations, a user can select if a selected endotype cluster is displayed automatically on detection of a hypotensive episode. If desired, a user can select if a selected endotype cluster is displayed.

[0098] In some implementations, the software-based classifier can include a user-defined classifier. The user-defined classifier can be configured to permit an end-user to define classification rules via a user interface. The user-defined classifier can include a threshold-based classifier wherein a threshold for at least one parameter is configured to be user-selectable. A boolean or a fuzzy logic method can be used to discriminate among different shock types based on the classification rules. The software-based classifier can be configured to act in near-real time on newly presented data to classify a current state of the first patient or to report a probability or confidence level that the first patient falls into one or more specific etiologies or endotypes.

[0099] Hemodynamic Risk Level Computation

[0100] In further accordance with the present disclosure, the hemodynamic risk level of a patient can be computed. In some embodiments this can be implemented in a customized a hemodynamic risk level module. This module can be dependent on the hemodynamic computation software module in that this module can utilize advanced hemodynamic parameters that are computed as inputs in order to assess the risk level of the patient.

[0101] The hemodynamic risk level computes the patient’s risk level due to various cardiovascular or respiratory factors that may elevate patient risk of deterioration. The Risk level module profiles the risk due to various etiologies (e.g. Cardiac / volume / vascular / respiratory) and endotypes, and suggests further tests / interventions to clinicians to further narrow diagnosis and patient status. Natural Language Processing (NLP) is used on clinician notes to improve risk stratification and monitoring. NLP methods include LLMs.

[0102] The output of the hemodynamic risk level analysis can be displayed graphically for observation by the clinician. FIG. 5 presents an illustrative graphical UI displaying the output of the risk level analysis, illustrating that there is an elevated risk of cardiac arrest for the patient that can be indicated by elevated diastolic blood pressure (DBP) combined with a low cardiac index (CI) and an indication of a previous myocardial infarction (MI). The result of this analysis can therefore identify the risk, a risk level, and at least one probable cause of the risk in a graphical user interface (FTG. 5). The risk can include, for example, one or more of cardiac arrest, respiratory arrest, stroke, hypotension, and hypovolemia, among others. By way of further example, the UI can provide guidance to a user or clinician on how to perform the tests within the UI or provide a link to a step-by-step guide for performing such a test or other action.

[0103] The risk of deterioration to the first patient can be computed based at least in part on at least one cardiovascular parameter selected from the group consisting of blood pressure (BP), mean arterial pressure (MAP), pulse pressure (PP) , heart rate (HR), cardiac output (CO), cardiac index (CI), cardiac stroke volume (SV), cardiac stroke volume index (SVI), systemic vascular resistance (SVR), systemic vascular resistance index (SVRI), arterial pulse pressure variation (PPV), stroke volume variation (SVV), a presence of dysrhythmia, a ECG waveform feature, a blood pressure waveform feature, a plethysmography waveform feature, ejection fraction (EF), dP / dt(max), Eadyn, pulmonary vascular resistance (PVR), pulmonary arterial pressure (PAP), aortic blood pressure, pulse wave velocity (PWV), and pulse pressure (PP) amplification index.

[0104] The hemodynamic risk level software module can be further configured to compute the risk of deterioration to the patient upon receiving information from an infusion pump and / or EMR system about a medication that is about to be infused. Such medications as fluids, vasoactive drugs, inotropic drugs, chronotropic drugs, and others that may have hemodynamic effects can be compared to a patient’s current hemodynamic status to assess their potential effect and risk of inducing hemodynamic instability. For example, midazolam is commonly used as a sedative and can have a vasodilatory effect. Such a medication would be risky to use on a patient who is already vasodilated and borderline hypotensive, for example. The software module, upon receiving the information about the planned medication infusion and comparing this medication to the patient’s hemodynamic status alerts the user about the impending drug-hemodynamic interaction and potential risk for hemodynamic instability.

[0105] The hemodynamic risk level software module can be configured to compute the risk of deterioration to the first patient based at least in part on at least one of hemoglobin data, hematocrit data, lab result data, arterial blood gas (“ABG”) test data, urine output data, respiration data, ventilation data, tidal volume data, positive end-expiratory pressure (PEEP) data, end-tidal carbon dioxide (ETCO2) waveform data, respiration rate data, patient medical history data, current diagnosis data, and patient intervention history data. Similar in concept to FIG. 2 and FIG. 3, data used by the hemodynamic risk level software module can be used as inputs in a machine learning model to determine the risk of deterioration of the first patient. The machine learning model can thus be trained on a larger dataset to then permit it to analyze data for a particular patient to evaluate that patient’s risk.

[0106] Hemodynamic Clinical Decision Support Computation

[0107] In further accordance with the present disclosure, the disclosed embodiments can be configured to make a determination of one or more of a recommended therapy, an intervention or a further test. This determination may be made by a hemodynamic clinical decision support module that is configured to analyze patient data including the results from the hemodynamic computation, shock diagnostics and risk profiling modules. The module may be an Al or other model that can be trained on aggregated data from the same institution, or aggregated data from multiple institutions. The output can further include a data summary relating the status of the current patient similar conditions observed in the aggregated datasets and the success of specific interventions / therapies / tests in those patients.

[0108] For purposes of illustration only, FIG. 6 presents a graphical user interface (UI) displaying an output of such a hemodynamic clinical decision support module. As indicated, the module illustrates that a previous infusion of vasopressors caused an elevation in SVR at the expense of low CI, and to treat the current episode of hypotension, an inotrope may be more appropriate. For example, administering midazolam to a patient who is already vasodilated risks the patient decompensating into circulatory shock due to the further vasodilatory effects of midazolam. By way of further example, the hemodynamic clinical decision support module could recommend against giving additional fluids when it is known that the lungs are already stiff due to lung edema.

[0109] While not illustrated in FIG. 6, the data summary can characterize the success of a specific intervention, therapy or test for the other patients in a group. The result can indicate a risk of a specific diagnosis of the first patient. The result can indicate a high probability of a risk of at least one of sepsis, bleed, myocardial injury and acute kidney injury (AKI). The hemodynamic clinical decision support software module can be configured to recommend a medication for treating a hemodynamic insufficiency of the first patient based at least in part on previous medications administered to the first patient. In some implementations, the hemodynamic clinical decision support software module can be configured to provides a user with at least one warning of a known drug-drug interaction or at least one warning relating to a risk of a particular drug specific to a patient’s hemodynamic condition, wherein at least one warning is based at least in part on taking into account at least one drug that was previously administered to the first patient. At least one warning can be based on a drug-drug interaction and / or on pharmaco-kinetic aspects of at least one drug. At least one warning can be based on a device-drug interaction. At least one warning can be based at least in part on a device setting or a rate of fluid administration.

[0110] Automatic Application of Therapy Based on System Outputs

[0111] Systems, methods and computer programs in accordance with the present disclosure can further include automatically dispensing a therapy based on the result of the analysis. Dispensing the therapy can be based in order to cause a cardiac parameter to change toward a target value. The target value can include at least one of a target blood pressure, a target cardiac output, a target oxygen delivery, and a target hemoglobin concentration.

[0112] The disclosed embodiments can be used to compute the endotype or phenotype of a critical illness, such as septic shock, vasoplegia, vasodilatory shock, bradycardia, myocardial depression, tachycardia, cardiogenic shock, low cardiac output syndrome, myocardial infarction, hypovolemia, obstructive shock, arrhythmia, and other forms of hemodynamic instability.

[0113] The disclosed embodiments can also be used to compute an imbalance of oxygen delivery and metabolic demand. As a specific example, the delivered oxygen content (DO2) may be calculated from CO, Hb, SaO2 and compared to the ‘unused’ 02 in the blood measured via venous oxygen saturation (SvO2). For example, a normal value of D02 in isolation may not raise an alarm, but in combination with a low SvO2, it may indicate an increased oxygen demand that is not being met. In some implementations, a risk assessment can be performed to estimate the risk of injury to one or more vital organs, for example, due to insufficient oxygen delivery or perfusion through the organ. This can be facilitated through use of local oximetry data proximate the organ. For example, one or more hemodynamic flow parameters can be analyzed with additional reference to cerebral oximetry readings to assess brain perfusion. It is also contemplated to combine the assessment of current low CI with a patient history of increased cholesterol measurement elevating the risk of low cardiac perfusion and a potential myocardial infarction. ARGOS ™ Controller

[0114] FIGURE 9 shows a block diagram illustrating embodiments of a ARGOS™ controller that can correspond to the Argos Infinity Server of FIG. 9. In this embodiment, the ARGOS ™ controller 901 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and / or facilitate interactions with a computer through internet technologies, and / or other related data. The controller 901 is connected to various sources of patient data including patient bedside monitors, central telemetry stations and the like.

[0115] Typically, users, which may be clinicians, nursing staff and / or other systems (e.g., bedside monitors and telemetry stations), may engage information technology systems (e.g., computers) to facilitate information processing. In turn, computers employ processors to process information; such processors 903 may be referred to as central processing units (CPU). CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations. These instructions may be operational and / or data instructions containing and / or referencing other instructions and data in various processor accessible and operable areas of memory 929 (e.g., registers, cache memory, random access memory, etc ). Such communicative instructions may be stored and / or transmitted in batches (e.g., batches of instructions) as programs and / or data components to facilitate desired operations. These stored instruction codes, e.g., programs, may engage the CPU circuit components and other motherboard and / or system components to perform desired operations. One type of program is a computer operating system, which, may be executed by CPU on a computer; the operating system enables and facilitates users to access and operate computer information technology and resources. Some resources that may be employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed. These information technology systems may be used to collect data for later retrieval, analysis, and manipulation, which may be facilitated through a database program. These information technology systems provide interfaces that allow users to access and operate various system components.

[0116] In one embodiment, the ARGOS ™ controller 901 may be connected to and / or communicate with entities such as, but not limited to: one or more users from user input devices 911; peripheral devices 912; an optional cryptographic processor device 928; and / or a communications network 913 that can also correspond to different elements illustrated, for example, in FIG. 9.

[0117] Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term “server” as used throughout this application refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting “clients.” The term “client” as used herein refers generally to a computer, program, other device, user and / or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network. A computer, other device, program, or combination thereof that facilitates, processes information and requests, and / or furthers the passage of information from a source user to a destination user is commonly referred to as a “node.” Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked with furthering the passage of information from a source to a destination is commonly called a “router.” There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is generally accepted as being an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate with one another.

[0118] The ARGOS ™ controller 901 may be based on computer systems that may comprise, but are not limited to, components such as: a computer systemization 902 connected to memory 929.

[0119] A computer systemization 902 may comprise a clock 930, central processing unit (“CPU(s)” and / or “processor(s)” (these terms are used interchangeable throughout the disclosure unless noted to the contrary)) 903, a memory 929 (e.g., a read only memory (ROM) 906, a random access memory (RAM) 905, etc.), and / or an interface bus 907, and most frequently, although not necessarily, are all interconnected and / or communicating through a system bus 904 on one or more (mother)board(s) 902 having conductive and / or otherwise transportive circuit pathways through which instructions (e.g., binary encoded signals) may travel to effectuate communications, operations, storage, etc. The computer systemization may be connected to a power source 986; e.g., optionally the power source may be internal. Optionally, a cryptographic processor 926 and / or transceivers (e.g., TCs) 974 may be connected to the system bus. In another embodiment, the cryptographic processor and / or transceivers may be connected as either internal and / or external peripheral devices 912 via the interface bus I / O. In turn, the transceivers may be connected to antenna(s) 975, thereby effectuating wireless transmission and reception of various communication and / or sensor protocols. Such transmission and reception of instructions embodying information throughout a computer systemization may be commonly referred to as communications. These communicative instructions may further be transmitted, received, and the cause of return and / or reply communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and / or the like such as those illustrated in FIG. 9. It should be understood that in alternative embodiments, any of the above components may be connected directly to one another, connected to the CPU, and / or organized in numerous variations employed as exemplified by various computer systems.

[0120] The CPU comprises at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. Often, the processors themselves will incorporate various specialized processing units, such as, but not limited to: integrated system (bus) controllers, memory management control units, floating point units, and even specialized processing sub-units like graphics processing units, digital signal processing units, and / or the like. Additionally, processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 929 beyond the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a memory address space that is accessible via instruction address, which the processor can construct and decode allowing it to access a circuit path to a specific memory address space having a memory state. The CPU may be a microprocessor such as: AMD’s Athlon, Duron and / or Opteron; ARM’s application, embedded and secure processors; IBM and / or Motorola’s DragonBall and PowerPC; IBM’s and Sony’s Cell processor; Intel’s Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s). The CPU interacts with memory through instruction passing through conductive and / or transportive conduits (e.g., (printed) electronic and / or optic circuits) to execute stored instructions (i.e., program code) according to conventional data processing techniques. Such instruction passing facilitates communication within the ARGOS ™ controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed and / or capacity, distributed processors (e.g., Distributed ARGOS™ embodiments), mainframe, multi-core, parallel, and / or supercomputer architectures may similarly be employed. Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed.

[0121] Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and / or some combination of both hardware / software solutions. For example, ARGOS™ features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and / or the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the ARGOS ™ embodiments features. A hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the ARGOS ™ embodiments system designer / administrator, somewhat like a one-chip programmable breadboard.

[0122] The power source 986 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and / or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy.

[0123] Interface bus(ses) 907 may accept, connect, and / or communicate to a number of interface adapters, conventionally although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I / O) 908, storage interfaces 909, network interfaces 910, and / or the like. Optionally, cryptographic processor interfaces 927 similarly may be connected to the interface bus. The interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters conventionally connect to the interface bus via a slot architecture. Storage interfaces 909 may accept, communicate, and / or connect to a number of storage devices such as, but not limited to: storage devices 914, removable disc devices, and / or the like. Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and / or the like.

[0124] Network interfaces 910 may accept, communicate, and / or connect to a communications network 913. Through a communications network 913, the ARGOS ™ embodiments controller is accessible through remote clients 933b (e.g., computers with web browsers) by users 933a. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet, and / or the like. Should processing requirements dictate a greater amount speed and / or capacity, distributed network controllers (e.g., Distributed ARGOS™ embodiments), architectures may similarly be employed to pool, load balance, and / or otherwise increase the communicative bandwidth required by the ARGOS ™ controller. A communications network may be any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), Lmode, and / or the like); and / or the like. A network interface may be regarded as a specialized form of an input output interface. Further, multiple network interfaces 910 may be used to engage with various communications network types 913. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and / or unicast networks. Input Output interfaces (I / O) 908 may accept, communicate, and / or connect to user input devices 911, peripheral devices 912, cryptographic processor devices 928, and / or the like. User input devices 911 often are a type of peripheral device 912 (see below) and may include, for example,: card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, microphones, mouse (mice), remote controls, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors (e.g., accelerometers, ambient light, GPS, gyroscopes, proximity, etc.), styluses, and / or the like. Peripheral devices 912 may be connected and / or communicate to I / O and / or other facilities of the like such as network interfaces, storage interfaces, directly to the interface bus, system bus, the CPU, and / or the like. Peripheral devices may be external, internal and / or part of the ARGOS ™ controller. Peripheral devices may include: antenna, audio devices (e.g., line-in, line-out, microphone input, speakers, etc.), cameras (e.g., still, video, webcam, etc ), dongles (e.g., for copy protection, ensuring secure transactions with a digital signature, and / or the like), external processors (for added capabilities; e.g., crypto devices 928), force-feedback devices (e.g., vibrating motors), network interfaces, printers, scanners, storage devices, transceivers (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources, visors, and / or the like. Peripheral devices often include types of input devices (e.g., cameras).

[0125] It should be noted that although user input devices and peripheral devices may be employed, the ARGOS ™ controller may be embodied as an embedded, dedicated, and / or monitor-less (i.e., headless) device, wherein access would be provided over a network interface connection.

[0126] Cryptographic units such as, but not limited to, microcontrollers, processors 926, interfaces 927, and / or devices 928 may be attached, and / or communicate with the ARGOS ™ controller. Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions.

[0127] Generally, any mechanization and / or embodiment allowing a processor to affect the storage and / or retrieval of information is regarded as memory 929. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another. It is to be understood that the ARGOS ™ controller and / or a computer systemization may employ various forms of memory 929. In a typical configuration, memory 929 will include ROM 906, RAM 905, and a storage device 914. A storage device 914 may be any conventional computer system storage. Storage devices may include a drum; a (fixed and / or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray, CD ROM / RAM / Recordable (R) / ReWritable (RW), DVD R / RW, HD DVD R / RW etc.); an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state memory devices (USB memory, solid state drives (SSD), etc.); other processor- readable storage mediums; and / or other devices of the like. Thus, a computer systemization generally requires and makes use of memory. The memory 929 may contain a collection of program and / or database components and / or data such as, but not limited to: operating system component(s) 915 (operating system); information server component(s) 916 (information server); user interface component s) 917 (user interface); Web browser component(s) 918 (Web browser); database(s) 919; mail server component s) 921; mail client component(s) 922; cryptographic server component(s) 920 (cryptographic server); the ARGOS ™ embodiments component(s) 935; and / or the like (i.e., collectively a component collection). These components may be stored and accessed from the storage devices and / or from storage devices accessible through an interface bus. Although non- conventional program components such as those in the component collection, typically, are stored in a local storage device 914, they may also be loaded and / or stored in memory such as: peripheral devices, RAM, remote storage facilities through a communications network, ROM, various forms of memory, and / or the like.

[0128] The operating system component 915 is an executable program component facilitating the operation of the ARGOS ™ controller. An operating system may communicate to and / or with other components in a component collection, including itself, and / or the like. Most frequently, the operating system communicates with other program components, user interfaces, and / or the like. For example, the operating system may contain, communicate, generate, obtain, and / or provide program component, system, user, and / or data communications, requests, and / or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, VO, peripheral devices, program components, memory, user input devices, and / or the like. The operating system may provide communications protocols that allow the ARGOS ™ controller to communicate with other entities through a communications network 913. Various communication protocols may be used by the ARGOS ™ controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP / IP, UDP, unicast, and / or the like.

[0129] An information server component 916 is a stored program component that is executed by a CPU. The information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation’s Apache, Microsoft’s Internet Information Server, and / or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols and / or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components. After a Domain Name System (DNS) resolution portion of an HTTP request is resolved to a particular information server, the information server resolves requests for information at specified locations on the ARGOS ™ controller based on the remainder of the HTTP request. An information server may communicate to and / or with other components in a component collection, including itself, and / or facilities of the like. Most frequently, the information server communicates with the ARGOS ™ database 919, operating systems, other program components, user interfaces, Web browsers, and / or the like.

[0130] Access to the ARGOS ™ database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels. Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the ARGOS ™ embodiments. In one embodiment, the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and / or fields. In one embodiment, the parser may generate queries in standard SQL by instantiating a search string with the proper join / select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the ARGOS ™ embodiments as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser.

[0131] Computer interfaces in some respects are similar to automobile operation interfaces. Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, and status. Computer interaction interface elements such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) similarly facilitate the access, capabilities, operation, and display of data and computer hardware and operating system resources, and status. Operation interfaces are commonly called user interfaces. Graphical user interfaces (GUIs) provide a baseline and means of accessing and displaying information graphically to users.

[0132] A user interface component 917 is a stored program component that is executed by a CPU. The user interface may be a conventional graphic user interface as provided by, with, and / or atop operating systems and / or operating environments such as already discussed. The user interface may allow for the display, execution, interaction, manipulation, and / or operation of program components and / or system facilities through textual and / or graphical facilities. The user interface provides a facility through which users may affect, interact, and / or operate a computer system. A user interface may communicate to and / or with other components in a component collection, including itself, and / or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and / or the like. The user interface may contain, communicate, generate, obtain, and / or provide program component, system, user, and / or data communications, requests, and / or responses.

[0133] A Web browser component 918 is a stored program component that is executed by a CPU. The Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. Secure Web browsing may be supplied with 128bit (or greater) encryption by way of HTTPS, SSL, and / or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., FireFox, Safari Plug-in, and / or the like APIs), and / or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and / or other mobile devices. A Web browser may communicate to and / or with other components in a component collection, including itself, and / or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and / or the like; e.g., it may contain, communicate, generate, obtain, and / or provide program component, system, user, and / or data communications, requests, and / or responses. Also, in place of a Web browser and information server, a combined application may be developed to perform similar operations of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and / or the like from the ARGOS ™ embodiments enabled nodes. The combined application may be nugatory on systems employing standard Web browsers. A mail server component 921 is a stored program component that is executed by a CPU 903. The mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and / or the like. The mail server can route, forward, and process incoming and outgoing mail messages that have been sent, relayed and / or otherwise traversing through and / or to the ARGOS ™ embodiments.

[0134] Access to the ARGOS ™ embodiments mail may be achieved through a number of APIs offered by the individual Web server components and / or the operating system.

[0135] Also, a mail server may contain, communicate, generate, obtain, and / or provide program component, system, user, and / or data communications, requests, information, and / or responses.

[0136] A mail client component 922 is a stored program component that is executed by a CPU 903. The mail client may be a conventional mail viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, and / or the like. Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and / or the like. A mail client may communicate to and / or with other components in a component collection, including itself, and / or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and / or the like; e.g., it may contain, communicate, generate, obtain, and / or provide program component, system, user, and / or data communications, requests, information, and / or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages.

[0137] A cryptographic server component 920 is a stored program component that is executed by a CPU 903, cryptographic processor 926, cryptographic processor interface 927, cryptographic processor device 928, and / or the like. Cryptographic processor interfaces will allow for expedition of encryption and / or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a conventional CPU. The cryptographic component allows for the encryption and / or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and / or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and / or the like. The cryptographic component will facilitate numerous (encryption and / or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash operation), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and / or the like. Employing such encryption security protocols, the ARGOS ™ embodiments may encrypt all incoming and / or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network. The cryptographic component facilitates the process of “security authorization” whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component may provide unique identifiers of content, e g., employing and MD5 hash to obtain a unique signature for an digital audio file. A cryptographic component may communicate to and / or with other components in a component collection, including itself, and / or facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable the ARGOS ™ embodiments component to engage in secure transactions if so desired. The cryptographic component facilitates the secure accessing of resources on the ARGOS ™ embodiments and facilitates the access of secured resources on remote systems; i.e., it may act as a client and / or server of secured resources. Most frequently, the cryptographic component communicates with information servers, operating systems, other program components, and / or the like. The cryptographic component may contain, communicate, generate, obtain, and / or provide program component, system, user, and / or data communications, requests, and / or responses.

[0138] The ARGOS ™ database component 919 may be embodied in a database and its stored data. The database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored data. The database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the “one” side of a one-to-many relationship.

[0139] Alternatively, the ARGOS ™ database may be implemented using various standard data- structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and / or the like. Such data-structures may be stored in memory and / or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and / or the like. Object databases can include a number of object collections that are grouped and / or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of capabilities encapsulated within a given object. If the ARGOS ™ database is implemented as a data-structure, the use of the ARGOS ™ database 919 may be integrated into another component such as the ARGOS ™ embodiments component 935. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and / or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and / or imported and thus decentralized and / or integrated.

[0140] In one embodiment, the database component 919 includes several tables 919a-d. A first table 919a includes fields such as, but not limited to: non invasive BP, invasive BP, heart rate, patient temperature, arterial blood oxygen saturation, venous blood oxygen saturation, sinus rhythm status, cardiac output, depth anesthesia, cerebral 02 sat, alarm status, urinary output, and the like. The personnel table may support and / or track multiple entity accounts on the ARGOS ™ embodiments. Further tables 919b-d can include additional suitable fields relating to other parameters or computed values as discussed elsewhere herein.

[0141] In some embodiments, the ARGOS ™ database may interact with other database systems. For example, employing a distributed database system, queries and data access by search ARGOS™ component may treat the combination of the ARGOS ™ database, an integrated data security layer database as a single database entity.

[0142] In one embodiment, user programs may contain various user interface primitives, which may serve to update the ARGOS ™ embodiments. Also, various accounts may require custom database tables depending upon the environments and the types of clients the ARGOS ™ embodiments may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and / or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and / or distributing the various database components 919a-d. The ARGOS ™ embodiments may be configured to keep track of various settings, inputs, and parameters via database controllers.

[0143] The ARGOS ™ database may communicate to and / or with other components in a component collection, including itself, and / or facilities of the like. Most frequently, the ARGOS ™ database communicates with the ARGOS ™ component, other program components, and / or the like. The database may contain, retain, and provide information regarding other nodes and data.

[0144] The ARGOS ™ component 935 is a stored program component that is executed by a CPU. In one embodiment, the ARGOS ™ component incorporates any and / or all combinations of the aspects of the ARGOS ™ embodiments that were discussed in the previous figures or other portions of the present disclosure. As such, the ARGOS ™ embodiments affect accessing, obtaining and the provision of information, services, transactions, and / or the like across various communications networks. The ARGOS ™ embodiments transform physiological parameter that are measured, recorded, or computed via ARGOS components 941-945 and 919a-d into useful data outputs as discussed herein.

[0145] The ARGOS ™ embodiments component enabling access of information between nodes may be developed by employing standard development tools and languages such as, but not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI) (Objective-) C (++), C# and / or .NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, procedural and object oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, web application server extensions, web development environments and libraries (e.g., Microsoft’s ActiveX; Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo! User Interface; and / or the like), WebObjects, and / or the like. In one embodiment, the ARGOS ™ server employs a cryptographic server to encrypt and decrypt communications. The ARGOS ™ component may communicate to and / or with other components in a component collection, including itself, and / or facilities of the like. Most frequently, the ARGOS ™ component communicates with the ARGOS ™ database, operating systems, other program components, and / or the like. The ARGOS ™ embodiments may contain, communicate, generate, obtain, and / or provide program component, system, user, and / or data communications, requests, and / or responses.

[0146] The structure and / or operation of any of the ARGOS ™ node controller components may be combined, consolidated, and / or distributed in any number of ways to facilitate development and / or deployment. Similarly, the component collection may be combined in any number of ways to facilitate deployment and / or development. To accomplish this, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion.

[0147] The component collection may be consolidated and / or distributed in countless variations through standard data processing and / or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and / or across numerous nodes to improve performance through load-balancing and / or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and / or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques.

[0148] The configuration of the ARGOS ™ controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and / or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and / or integrated program components, results in a more distributed series of program components, and / or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and / or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and / or provide data. This may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and / or the like.

[0149] If component collection components are discrete, separate, and / or external to one another, then communicating, obtaining, and / or providing data with and / or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and / or the like), Common Object Request Broker Architecture (CORBA), Jini local and remote application program interfaces, JavaScript Object Notation (JSON), Remote Method Invocation (RMI), SOAP, process pipes, shared fdes, and / or the like. Messages sent between discrete component components for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using development tools such as lex, yacc, XML, and / or the like, which allow for grammar generation and parsing capabilities, which in turn may form the basis of communication messages within and between components.

[0150] In order to address various issues and advance the art, the entirety of this application for MACHINE-READABLE PROGRAMS, SYSTEMS AND METHODS FOR ASSESSING PATIENT STATUS AND RISK (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, Appendices, and otherwise) shows, by way of illustration, various embodiments in which the claimed innovations may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and / or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed innovations. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the innovations or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the innovations and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, operational, organizational, structural and / or topological modifications may be made without departing from the scope and / or spirit of the disclosure. As such, all examples and / or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and / or topological structure of any combination of any program components (a component collection), other components and / or any present feature sets as described in the figures and / or throughout are not limited to a fixed operating order and / or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and / or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and / or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the innovations, and inapplicable to others. In addition, the disclosure includes other innovations not presently claimed. Applicant reserves all rights in those presently unclaimed innovations including the right to claim such innovations, file additional applications, continuations, continuations in part, divisions, and / or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, operational, organizational, structural, topological, and / or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims. It is to be understood that, depending on the particular needs and / or characteristics of a ARGOS™ embodiments individual and / or enterprise user, database configuration and / or relational model, data type, data transmission and / or network framework, syntax structure, and / or the like, various of the ARGOS ™ embodiments, may be implemented that enable a great deal of flexibility and customization.

[0151] All statements herein reciting principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure. Descriptions herein of circuitry and method steps and computer programs represent conceptual embodiments of illustrative circuitry and software embodying the principles of the disclosed embodiments. Thus the functions of the various elements shown and described herein may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software as set forth herein.

[0152] In the disclosure hereof any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements and associated hardware which perform that function or b) software in any form, including, therefore, firmware, microcode or the like as set forth herein, combined with appropriate circuitry for executing that software to perform the function. Applicants thus regard any means which can provide those functionalities as equivalent to those shown herein.

[0153] Similarly, it will be appreciated that the system and process flows described herein represent various processes which may be substantially represented in computer-readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. Moreover, the various processes can be understood as representing not only processing and / or other functions but, alternatively, as blocks of program code that carry out such processing or functions.

[0154] It will be apparent to those skilled in the art that various modifications and variations can be made in the devices, methods, software programs and mobile devices of the present disclosure without departing from the spirit or scope of the disclosure. Thus, it is intended that the present disclosure include modifications and variations that are within the scope of the subject disclosure and equivalents.

Claims

CLAIMSWhat is claimed is:

1. A method of assessing likelihood of a hemodynamic event occurring with respect to a first patient based on analysis of physiological parameters, the method comprising: receiving patient physiological data via processor; performing an analysis of the patient physiological data via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to at least one of patient physiological data of a plurality of additional patients and prior physiological data of the first patient; and generating a signal for presenting a result of the analysis via processor.

2. The method of Claim 1, wherein the patient data is received from a plurality of disparate computer systems.

3. The method of Claim 1, wherein the patient physiological data includes at least one of patient monitoring data, patient medication data, patient intervention data, patient lab report data, patient imaging report data, patient history data, patient diagnosis data and clinician note data.

4. The method of Claim 3, wherein the patient monitoring data includes a high sampling rate waveform.

5. The method of Claim 4, wherein the high sampling rate waveform includes at least one of an electrocardiogram (ECG) waveform, an invasive arterial blood pressure waveform, a plethysmography waveform, a central venous pressure (“CVP”) waveform, an intracranial pressure (“ICP”) waveform, a pulmonary artery pressure (“PAP”) waveform, and a respiration waveform (“Resp”), and end-tidal CO2 waveform (“EtCO2”).

6. The method of Claim 3, wherein the patient monitoring data includes at least one intermittently provided parameter from a patient monitor selected from the group consisting of non-invasive blood pressure (“NBP”), invasive blood pressure (“IBP”), heart rate (“HR”), patient temperature (“Temp”), arterial blood oxygen saturation (“SaO2” or “SpO2”), venous blood oxygen saturation (“SvO2” or “ScvO2”), sinus rhythm status, cardiac output (“CO”), depth of anesthesia (e.g. “BIS”), cerebral oxygen saturation, and alarm status (e.g. “ST” alarm or “QTc” alarm).

7. The method of Claim 3, wherein the patient monitoring data includes at least one of a urinary output (“UO”) measurement, an echocardiography measurement, and cardiac output.

8. The method of Claim 3, wherein the patient medication data includes data relating to at least one of medication administered continuously and medication administered intermittently.

9. The method of Claim 8, wherein the medication administered continuously includes at least one of an intravenously administered medication, an intravenously administered fluid, a fluid administered by way of a feeding tube, a gas administered via a mask, endotracheal tube or a nasal cannula.

10. The method of Claim 8, wherein the medication administered intermittently includes at least one of an orally administered medication, a bolus injection, and via the airway.1 1 . The method of Claim 3, wherein the patient intervention data includes at least one of data relating to administration of a beneficial agent, data relating to wound debridement, data relating to cardiac pacing, data relating to patient pronation, data relating to patient supination, data relating to patient airway changes, data relating to patient ventilation changes, and patient ambulation data.

12. The method of Claim 3, wherein the patient lab report data includes at least one of diagnostic test data, bacterial culture result data, blood analysis result data.

13. The method of Claim 12, wherein the blood analysis result data includes at least one of pH data, lactate data, blood gas analysis data, creatinine data, ion concentration data, protein concentration data, vitamin level data, and mineral level data.

14. The method of Claim 3, wherein the patient imaging report data includes at least one of cardiac mapping data, MRI data, X-ray data, ultrasound data, and echo imaging data.

15. The method of Claim 3, wherein the patient history data includes at least one of previous patient hospitalization data, previous patient medical procedure data, previous patient medical event data, and patient comorbidity data.

16. The method of Claim 3, wherein the patient diagnosis data includes at least one of primary diagnosis data relating to a current hospitalization event and subsequent diagnoses data generated during the current hospitalization event.

17. The method of Claim 3, wherein the clinician note data includes at least one of medical doctor notes, nursing notes, patient mental status notes, patient pain event notes and patient nutrition notes.

18. The method of Claim 1, wherein the signal is configured to present the result in the form of an electronic medical record (“EMR”) flowsheet.

19. The method of Claim 1 , wherein the signal is configured to present the result in the form of a graphical user interface.

20. The method of Claim 1, wherein the analysis is performed by a hemodynamic computation software module that is configured to analyze at least one measured patient parameter present in the patient physiological data to compute at least one advanced hemodynamic parameter.

21. The method of Claim 20, wherein the at least one measured patient parameter includes data from an electrocardiogram (ECG), a blood pressure value, data from a plethysmograph, a blood gas test result, a hemoglobin parameter, a hematocrit parameter, echocardiography data, and data from a Swan-Ganz catheter.

22. The method of Claim 20, wherein the at least one advanced hemodynamic parameter includes at least one of a cardiac output value, a stroke volume value, systemic vascular resistance (“SVR”), a delivered oxygen value, an oxygen demand vs supply gap value, a pulmonary vascular resistance (“PVR”) value, and ejection fraction (“EF”).

23. The method of Claim 20, wherein the at least one measured patient parameter includes at least one respiration parameter or at least one ventilation parameter.

24. The method of Claim 23, wherein the at least one respiration parameter or at least one ventilation parameter includes at least one of an end-tidal carbon dioxide (ETCO2) parameter, a tidal volume parameter, a respiration rate parameter, a positive end-expiratory pressure (PEEP) parameter.

25. The method of Claim 20, wherein the at least one advanced hemodynamic parameter is computed using the first patient’s arterial blood pressure waveform and demographicinformation of the first patient to compute at least one of cardiac output of the first patient, stroke volume of the first patient and systemic vascular resistance of the first patient.

26. The method of Claim 25, wherein the demographic information of the first patient includes at least one of the age, sex, height, and weight of the first patient.

27. The method of Claim 20, wherein the at least one advanced hemodynamic parameter is computed using pulse contour analysis.

28. The method of Claim 20, wherein the at least one advanced hemodynamic parameter is computed using impedance cardiography.

29. The method of Claim 1, further comprising detecting an artifact in the patient physiological data based on the analysis.

30. The method of Claim 20, wherein the at least one advanced hemodynamic parameter is computed by analyzing at least one of an electrocardiogram (ECG), a blood pressure value, data from a plethysmography waveform and echocardiography data.

31. The method of Claim 30, wherein the at least one advanced hemodynamic parameter relates to cardiac contractility.

32. The method of Claim 31, wherein the at least one advanced hemodynamic parameter includes at least one of ejection fraction and the maximum rate of arterial blood pressure increase during a single heartbeat (dP / dt(max)).

33. The method of Claim 32, wherein the ejection fraction is computed using a BP waveform.

34. The method of Claim 30, wherein the at least one advanced hemodynamic parameter is an arterial elasticity parameter.

35. The method of Claim 34, wherein the arterial elasticity parameter is computed with reference to at least one of a current diagnosis of the first patient, a patient history of the first patient, a pulse wave velocity measurement, a pulse pressure amplification measurement, and a dynamic arterial elastance (Ea,dyn,) measurement.

36. The method of Claim 30, wherein the at least one advanced hemodynamic parameter is a central blood pressure parameter.

37. The method of Claim 36, wherein the central blood pressure parameter is computed by analyzing at least one peripheral arterial blood pressure waveform.

38. The method of Claim 37, wherein the at least one peripheral blood pressure waveform is selected from the group consisting of a radial arterial blood pressure waveform, a brachial arterial blood pressure waveform, a femoral arterial blood pressure waveform, and a dorsalis pedis arterial blood pressure waveform.

39. The method of Claim 30, wherein the at least one advanced hemodynamic parameter is a pulmonary vascular resistance (PVR) parameter.

40. The method of Claim 39, wherein the PVR parameter is computed with reference to a pulmonary artery pressure (PAP) waveform.

41. The method of Claim 40, wherein the PVR parameter is computed by applying a multibeat analysis (“MBA”) algorithm to the PAP waveform.

42. The method of Claim 41, further comprising computing cardiac output (CO) using a multi-beat analysis with reference to the PAP waveform.

43. The method of Claim 1, wherein the analysis is performed at least in part by a circulatory shock software module that is configured to profile a circulatory shock state.

44. The method of Claim 20, wherein the analysis is performed at least in part by a circulatory shock software module that is configured to profile a circulatory shock state based at least in part on an output of the hemodynamic computation software module.

45. The method of Claim 43 or Claim 44, wherein the circulatory shock software module profiles the circulatory shock state as having a specific endotype.

46. The method of Claim 43 or Claim 44, wherein the circulatory shock software module profiles the circulatory shock state as having a contribution from at least one etiology.

47. The method of Claim 46, wherein the at least one etiology is selected from the group consisting of a vasodilatory etiology, a hypovolemic etiology, or a cardiogenic etiology.

48. The method of Claims 43 or 44, wherein the circulatory shock software module is configured to be a self-1 earning module based on accumulating data of at least one of hemodynamics, respiration, interventions, medications, diagnoses, lab results, patient histories, diagnoses and clinical notes.

49. The method of Claims 43 or 44, wherein the circulatory shock software module references a fixed database in order to profile the circulatory shock state.

50. The method of Claims 43 or 44, wherein the circulatory shock software module references a database that accumulates additional data over time in order to profile the circulatory shock state.

51. The method of Claim 46, wherein the circulatory shock module is configured to classify a hypotensive event as belonging to a specific etiology class.

52. The method of Claim 51, wherein the circulatory shock module is configured to associate a dominant etiology class with the hypotensive event.

53. The method of Claim 52, wherein the circulatory shock module is configured to compute a probability for associating each of a plurality of etiology classes with the hypotensive event.

54. The method of Claim 53, wherein the circulatory shock module is configured to compute a contribution to the hypotensive event attributable to each of the etiology classes.

55. The method of Claim 54, wherein the circulatory shock module is configured to determine the contribution to the hypotensive event attributable to each of the etiology classes by classifying the patient physiological data with a software-based classifier.

56. The method of Claim 55, wherein the circulatory shock module is configured to determine the contribution to the hypotensive event attributable to each of the etiology classes by classifying computed advanced hemodynamic variables including at least one of Cardiac Output(CO), Cardiac Index (CI), Stroke Volume (SV), SV Index (SVI), Systemic Vascular Resistance (SVR), SVR Index (SVRI), Mean Arterial Pressure (MAP), Heart rate (HR), Central Venous Pressure (CVP) and Pulse Pressure Variation (PPV).

57. The method of Claim 55, wherein the software-based classifier includes a supervised artificial intelligence (“Al”) classifier.

58. The method of Claim 57, wherein the supervised Al classifier is implemented using at least one of an artificial neural network, regression trees, and ensemble classification methods.

59. The method of Claim 57, wherein the supervised Al classifier is trained on at least one of discrete values patient physiological data, waveform patterns and waveform features.

60. The method of Claim 55, wherein the software-based classifier includes an unsupervised Al classifier.

61. The method of Claim 58, wherein the unsupervised Al classifier is configured to identify at least one endotype of hypotension by way of hierarchical clustering of the patient physiological data.

62. The method of Claim 61, wherein the at least one hypotension endotype corresponds to at least one pre-defined endotype cluster.

63. The method of Claim 62, wherein the pre-defined endotype cluster corresponds to myocardial depression, bradycardia, vasodilation without cardiac index increase, vasodilation with cardiac index increase, hypovolemia or mixed type.

64. The method of Claim 63, wherein the endotype cluster is user-selectable.

65. The method of Claim 64, wherein a user can select if a selected endotype cluster is displayed automatically on detection of a hypotensive episode.

66. The method of Claim 64, wherein a user can select if a selected endotype cluster is displayed.

67. The method of Claim 58, wherein the unsupervised Al classifier is trained based on a population of patients.

68. The method of Claim 67, wherein the population of patients includes at least one of an all-ICU patient population pooled over multiple health care facilities, a single ICU at a single healthcare facility.

69. The method of Claim 59, wherein the patient physiological data is updated over time to include new data.

70. The method of Claim 58 wherein the contribution to the hypotensive event attributable to each of the etiology classes is determined using at least one of Euclidean distance measures and Mahalanobis distance measures from a pre-determined cluster center, wherein the smallest distance measured corresponds to a dominant endotype or dominant etiology.

71. The method of Claim 55, wherein the software-based classifier includes a user-defined classifier.

72. The method of Claim 71, wherein the user-defined classifier is configured to permit an end-user to define classification rules via a user interface.

73. The method of Claim 72, wherein the user-defined classifier includes a threshold-based classifier wherein a threshold for at least one parameter is configured to be user-selectable.

74. The method of Claim 73, wherein a boolean or a fuzzy logic method is used to discriminate among different shock types based on the classification rules.

75. The method of Claim 55, wherein the software-based classifier is configured to act in near-real time on newly presented data to classify a current state of the first patient or to report a probability or confidence level that the first patient falls into one or more specific etiologies or endotypes.

76. The method of Claim 1, wherein the analysis is performed at least in part by a hemodynamic risk level software module that is configured to compute a risk to the first patient of deterioration based on the patient physiological data.

77. The method of Claim 76, wherein the hemodynamic risk level software module is configured to compute the risk of deterioration to the first patient based at least in part on at least one cardiovascular parameter selected from the group consisting of blood pressure (BP), mean arterial pressure (MAP), pulse pressure (PP) , heart rate (HR), cardiac output (CO), cardiac index (CI), cardiac stroke volume (SV), cardiac stroke volume index (SVI), systemic vascular resistance (SVR), systemic vascular resistance index (SVRI), arterial pulse pressure variation (PPV), stroke volume variation (SW), a presence of dysrhythmia, a ECG waveform feature, a blood pressure waveform feature, a plethysmography waveform feature, ejection fraction (EF), dP / dt(max), Eadyn, pulmonary vascular resistance (PVR), pulmonary arterial pressure (PAP), aortic blood pressure, pulse wave velocity (PWV), and pulse pressure (PP) amplification index.

78. The method of Claim 77, wherein the hemodynamic risk level software module is configured to compute the risk of deterioration to the first patient based at least in part on at least one of hemoglobin data, hematocrit data, lab result data, arterial blood gas (“ABG”) test data, urine output data, respiration data, ventilation data, tidal volume data, positive end-expiratory pressure (PEEP) data, end-tidal carbon dioxide (ETCO2) waveform data, respiration rate data, patient medical history data, current diagnosis data, and patient intervention history data.

79. The method of Claim 78, wherein data used by the hemodynamic risk level software module are used as inputs in a machine learning model to determine the risk of deterioration of the first patient.

80. The method of Claim 76, wherein the result identifies the risk, a risk level, and at least one probable cause of the risk in a graphical user interface.

81. The method of Claim 76, wherein the risk is selected from the group consisting of cardiac arrest, respiratory arrest, stroke, hypotension, and hypovolemia.

82. The method of Claim 1, wherein the analysis is performed at least in part by a hemodynamic clinical decision support software module that is configured to analyze the patient physiological data via processor and, based on the analysis, issue a recommendation at least one of a therapy, an intervention, and a further test for the first patient.

83. The method of Claim 82, wherein the hemodynamic clinical decision support software module bases the recommendation on an output of at least one of a hemodynamic computation software module, a circulatory shock software module, and a risk profiling software module.

84. The method of Claim 82, wherein the patient physiological data includes aggregated patient data from a single health care institution.

85. The method of Claim 82, wherein the patient physiological data includes aggregated patient data from a plurality of health care institutions.

86. The method of Claim 82, wherein the hemodynamic clinical decision support software module provides a data summary that compares a result for the first patient to results of other patients from the patient physiological data.

87. The method of Claim 86, wherein the data summary characterizes the success of a specific intervention, therapy or test for the other patients.

88. The method of Claim 82, wherein the result indicates a risk of a specific diagnosis of the first patient.

89. The method of Claim 88, wherein the result indicates a high probability of a risk of at least one of sepsis, bleed, myocardial injury and acute kidney injury (AKI).

90. The method of Claim 82, wherein the hemodynamic clinical decision support software module is configured to recommend a medication for treating a hemodynamic insufficiency of the first patient based at least in part on previous medications administered to the first patient.

91. The method of Claim 90, wherein the hemodynamic clinical decision support software module is configured to provides a user with at least one warning of a known drug-drug interaction or at least one warning relating to a risk of a particular drug specific to a patient’shemodynamic condition, wherein the at least one warning is based at least in part on taking into account at least one drug that was previously administered to the first patient.

92. The method of Claim 91, wherein the at least one warning is based on a drug-drug interaction, and further wherein the at least one warning is based at least in part on pharmacokinetic aspects of at least one drug.

93. The method of Claim 91, wherein the at least one warning is based on a device-drug interaction.

94. The method of Claim 93, wherein the at least one warning is based at least in part on a device setting or a rate of fluid administration.

95. The method of Claim 1, further comprising automatically dispensing a therapy based on the result of the analysis.

96. The method of Claim 95, wherein dispensing the therapy is based in order to cause a cardiac parameter to change toward a target value.

97. The method of Claim 95, wherein the target value includes at least one of a target blood pressure, a target cardiac output, a target oxygen delivery, and a target hemoglobin concentration.

98. A system for assessing likelihood of a hemodynamic event occurring with respect to a first patient based on analysis of physiological parameters, the system comprising: a first circuit configured and arranged to receive patient physiological data via processor;a second circuit configured and arranged to perform an analysis of the patient physiological data via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to at least one of patient physiological data of a plurality of additional patients and prior physiological data of the first patient; and a third circuit configured and arranged to generate a signal for presenting a result of the analysis via processor.

99. A processor-readable tangible non- transient medium storing a computer program for assessing likelihood of a hemodynamic event occurring with respect to a first patient based on analysis of physiological parameters, the computer program comprising: a first set of instructions to receive patient physiological data via processor; a second set of instructions to perform an analysis of the patient physiological data via processor to determine the likelihood of a hemodynamic event occurring with respect to a first patient by comparing patient physiological data of the first patient to at least one of patient physiological data of a plurality of additional patients and prior physiological data of the first patient; and a third set of instructions to generate a signal for presenting a result of the analysis via processor.

Images