System to monitor, prescribe, and deliver fluid balance

Abstract

Various examples are provided related to fluid balance management and monitoring. The system can monitor a fluid balance based at least in part on an analysis of fluid intake data, fluid output data, physiological data points, target balance data, or any combination thereof. The system can also continuously or periodically adjust at least one of: a restoration fluid flow rate or a fluid removal flow rate based at least in part on the monitored fluid balance. The system generates a fluid balance graph that indicates fluid balance over time using the fluid intake data, the fluid output data, and at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof. The system can further include alerts, projected fluid balance and fluid balance path, and the ability to incorporate manual and clinical data to identify a fluid balance path to adhere to.

Description

Docket: U24-012 (222119-2270) SYSTEM TO MONITOR, PRESCRIBE, AND DELIVER FLUID BALANCE CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of U.S. Provisional Application entitled “EXTRACORPOREAL FLUID BALANCE MANAGEMENT,” having serial number 63 / 549,772, filed on February 5, 2024, which is incorporated herein by reference in its entirety. BACKGROUND

[0002] Intravascular fluids are one of the most commonly prescribed medications in critically ill patients. When fluids are not properly administered, fluid underdose or fluid overdose leads to negative patient outcomes in critically ill children and adults in cardiac, medical, surgical, and other intensive care units (ICUs). The provision of medications, nutrition, and blood products for critically ill patients is essential. If not properly prescribed and administered, fluid underdose or fluid overdose impacts the underlying physiology and leads to multi-organ failure, morbidity, mortality, increased length of stay and costs.

[0003] Unfortunately, current approaches to achieve desired fluid goals in critically ill patients are antiquated, complicated, and confusing. Tracking a patient’s cumulative fluid balance over time is very difficult. Any clinician or nurse who has cared for critically ill patients can attest that tracking fluid intake and output is labor-intensive, unreliable, and error-prone. Furthermore, in order to achieve the appropriate fluid balance, the clinician must make multiple assumptions about expected inputs / outputs to guess the appropriate fluid intake rate to prescribe in the hopes that the fluid balance desired will be achieved. For these reasons, the clinician’s ability to prescribe, adjust,Docket: U24-012 (222119-2270) or achieve the desired fluid homeostasis is extremely difficult and does not work well. Multiple critical care groups call for better tools that can enhance fluid monitoring and prescription because current technologies do not provide tools to address these issues. SUMMARY

[0004] A system for monitoring and controlling fluid balance is provided, the system having at least one fluid sensor configured to measure fluid intake data or fluid output data for at least one input fluid or output fluid for a patient and at least one computing device comprising at least one processor and at least one memory comprising an application. The application, when executed by the processor, causes the computing device to receive the fluid intake data and the fluid output data, identify target fluid balance data, and generate a fluid balance graph that indicates fluid balance over time and projected fluid balance over a period of time, based at least in part on the fluid intake data and the fluid output data.

[0005] In some examples, the system can further have a fluid restoration pump that provides a restoration fluid flow rate for a patient. In addition, the system can have a fluid removal pump that provides a fluid removal flow rate for the patient. The application within the system can further cause the computing device to generate at least one control signal that continuously or periodically adjusts at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof, based at least in part on an analysis of the fluid intake data, the fluid output data, and the target fluid balance data. The control fluid balance signal can be set by a provider (i.e., leave on 50 ml / hr or take off 100 ml / hr) or can be determined by other means (i.e., target a specific stroke volume or cardiac index). Additionally, the application can further cause the computing device to generate a fluid balance graph that indicatesDocket: U24-012 (222119-2270) fluid balance over a period of time, based at least in part on the fluid intake data, the fluid output data, and the at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof.

[0006] In some examples, the fluid balance for a particular point in fluid balance graph can correspond to a total fluid value relative to a patient weight. The initial fluid balance value can also correspond to at least one of: zero, a predetermined default value, or a user-entered value, or a value derived from patient historic weights, clinical signs, symptoms or sensor data. In some examples, the fluid balance graph is displayed in a user interface that provides an indication of a current fluid balance value and a current fluid balance rate. The fluid balance graph can also be displayed in a user interface that indicates at least one of a fluid value or a fluid flow rate for a respective one of: the at least one input fluid, the at least one output fluid, a restoration fluid of the fluid restoration pump, and a removal fluid of the fluid removal pump. In addition, the fluid balance graph can be displayed in a user interface that provides an indication of at least one projected fluid balance value based at least in part on the current fluid balance value and the current fluid balance rate.

[0007] In some examples, the application can further cause the computing device to identify at least one manually input fluid value that is input using: at least one of a graphical user interface element of a graphical user interface, a physical control device, or any combination thereof. The application can further cause the computing device to generate an estimated value for an insensible fluid output. According to various examples, the application can cause the computing device to trigger an alert in response to patient fluid value data matching at least one of: a target fluid balance value, a target fluid balance relative to the patient weight, an absolute or relative target fluid balance rate. Further, in some examples, the application can cause the computingDocket: U24-012 (222119-2270) device to adjust a fluid balance rate based at least in part on one or more hemodynamic variables. In some examples, one or more hemodynamic variables can comprise at least one of: central venous pressure (CVP) value, heart rate value, stroke volume, stroke volume index (SVI), cardiac output, cardiac index (CI), blood pressure value or any combination thereof. In at least some examples, the application can cause the computing device to suggest or set a component of at least one of: a dry weight value, a fluid balance rate algorithm, and fluid balance projections.

[0008] Also provided is a system for monitoring and prescribing fluid balance. The system can include at least one fluid sensor configured to measure fluid intake data or fluid output data for at least one input fluid or output fluid for a patient and at least one computing device comprising at least one processor and at least one memory comprising an application, wherein the application, when executed by the processor, can cause the computing device to receive the fluid intake data and the fluid output data, monitor the fluid intake data and the fluid output data over a period of time, predict at least one prospective fluid balance prescription required to achieve a specific physiological target or fluid balance based at least in part on the monitored fluid intake data and fluid output data, and generate a fluid balance graph that indicates a monitored fluid balance over a period of time and a projected fluid balance over a period of time based at least in part on the at least one prospective fluid balance prescription required to achieve a specific physiological target or fluid balance.

[0009] In some examples, the system can further include an automated fluid management device that can include a fluid restoration pump that provides a restoration fluid flow rate for a patient, a fluid removal pump that provides a fluid removal flow rate for the patient, and wherein, when executed by the at least one processor, the application further causes the computing device to receive the fluidDocket: U24-012 (222119-2270) intake data and the fluid output data, receive the at least one prospective fluid balance prescription required to achieve a specific physiological target, identify target fluid balance data, and generate at least one control signal that continuously or periodically adjusts at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof, based at least in part on an analysis of the fluid intake data, the fluid output data, the at least one prospective fluid balance prescription, and the target fluid balance data. In some embodiments, the application, when executed by the at least one processor, causes the at least one computing device to identify at least one manually input target fluid balance value that is input using at least one of a graphical user interface element of a graphical user interface, a physical control device, or any combination thereof.

[0010] In other embodiments, the application can further cause the computing device to alert a user if the monitored fluid balance reaches either a specified absolute value or a specified change in the monitored fluid balance, or is diverting from the prescribed fluid balance pathway. In other embodiments, the application can further cause the computing device to alert a user if the predicted future fluid balance reaches either a specified absolute value, a specified change in the monitored fluid balance, a specified predicted patient outcome, or a combination of any thereof.

[0011] In some examples, the system can further include at least one sensor that measures at least one physiological data point obtained from the patient, and when executed by the at least one processor, the application further causes the computing device to at least receive the physiological data point, monitor the physiological data point, and predict at least one prospective fluid balance prescription required to achieve a specific physiological target or target fluid balance based at least in part on the monitored physiological data point.Docket: U24-012 (222119-2270) BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

[0013] FIG. 1 illustrates an example networked environment for extracorporeal fluid balance management in accordance with various embodiments of the present disclosure.

[0014] FIG. 2 illustrates an example of an extracorporeal fluid balance management system in accordance with various embodiments of the present disclosure.

[0015] FIG. 3 illustrates an example fluid balance display generated for extracorporeal fluid balance management, graphed with a simulated value in accordance with various embodiments of the present disclosure.

[0016] FIG. 4 illustrates an example user interface generated for extracorporeal fluid balance management in accordance with various embodiments of the present disclosure.

[0017] FIG. 5 illustrates an example reference net fluid balance graph for extracorporeal fluid balance management in accordance with various embodiments of the present disclosure. DETAILED DESCRIPTION

[0018] Disclosed herein are various examples related to extra-corporeal fluid balance systems for comprehensive monitoring, prescribing, and delivering fluidDocket: U24-012 (222119-2270) balances to a patient. Intravascular fluids are one of the most commonly prescribed medications in critically ill patients. When fluids are not properly administered, fluid underdose or fluid overdose leads to negative patient outcomes in critically ill children and adults in cardiac, medical, surgical, and other intensive care units (ICUs). The provision of medications, nutrition, and blood products for critically ill patients is essential. If not properly prescribed and administered, fluid underdose or fluid overdose impacts the underlying physiology and leads to multi-organ failure, morbidity, mortality, and increased length of stay and costs. Unfortunately, current technologies do not provide tools to address these issues. However, the present disclosure describes mechanisms that can monitor historic, current, and / or projected fluid balance. The disclosure describes a mechanism in which both a net positive or negative fluid flow rates can be tracked. The present disclosure further provides alerts for current absolute fluid balance threshold, fluid balance relative to patient weight and / or projected absolute or relative fluid balances. Additional mechanisms can enable prescription and delivery of a desired fluid balance and / or desired fluid balance rate can be changed seamlessly using corresponding target fluid balance rate setpoints, target fluid balance setpoints, target fluid balance curves, and / or target hemodynamic thresholds.

[0019] The described mechanisms include an extracorporeal fluid balance management device or system, the “Fluid Aviator”. To illustrate how the Fluid Aviator would be used to prescribe fluid balance, the present disclosure includes various examples related to extra-corporeal fluid balance monitoring and prediction. To start, the proposed system can reliably and accurately track and predict patient fluid balance and / or fluid balance rate, based on automated monitoring of all intake and outputs utilizing a combination of sensors, algorithms for calculation of insensible fluid losses,Docket: U24-012 (222119-2270) semi-manual inputs and outputs that utilize system-integrated scales to measure intake / output, and manual input for fluids that in some instances are not monitored with sensors directly (e.g., drinking intake, excrement output, etc.). Furthermore, with integrated infusion delivery systems (restoration / input / intake) and ultrafiltration (output / outtake / fluid removal) pumps, the clinician can reliably achieve and adjust the fluid balance goals seamlessly according to the patient’s fluid balance needs, with a complete consideration of measured and unmeasured (e.g., insensible) fluids intake and output of the patient.

[0020] The fluid balance management system can provide fluid delivery for different conditions (e.g., heart failure) and in different locations (e.g., inpatient, ICU or outpatient units) better than current models by: (1) reducing nursing staff time tracking fluids, (2) eliminating errors (3) tracking cumulative fluid balance reliably, and continuously over time, (4) predicting effects of prospective fluid balance prescriptions for achieving specific physiological data point targets, (5) predicting patient outcomes based at least in part on various prescriptions or time-based prediction of changes in physiological data points, and (6) enabling the clinician to adjust the net fluid balance rate as fluid balance goals change during different phases of critical illnesses. These features can improve efficiency of care, improve clinical outcomes, and reduce costs. The fluid balance management system can achieve accurate and reliable monitoring and control of fluid balance and fluid balance rates.

[0021] The fluid balance management system can include monitoring and prescription of a wide range of net positive or net negative fluid balance rates. The fluid balance management system can achieve the prescribed fluid balance rate. The rate can be tracked and controlled with less than a predetermined error, such as a ±Docket: U24-012 (222119-2270) 5 % error threshold, ± 240 ml / day error threshold, or ± 30 ml / hour error threshold another error threshold.

[0022] The fluid balance management system can be implemented with sufficient algorithmic and component redundancy to detect and safely halt operation due to predefined single point of failure events. The fluid balance management system can include component redundancy for fault-tolerant sensors, actuators, and control systems. The fluid balance management system can provide algorithmic approaches for fault-tolerant monitoring, control, safety margins, and alerts. The fluid balance management system can also provide for recognition and halting of system operation within a predetermined threshold amount of time, such as 10 seconds, for induced single point of failure for any / all software components.

[0023] In many types of clinical conditions such as for heart failure, a very narrow window of appropriate fluid balance exists. Achieving the desired fluid balance goals is very difficult in the current environment. In many patients, diuretics are not sufficient to achieve the desired net negative fluid balance. Furthermore, hospitalized patients require medications, nutrition, and blood products which can exacerbate fluid imbalance and complicate the ability to achieve the desired fluid balance goals whether positive or negative.

[0024] The inability to properly restore the desired fluid balance leads to physiologic deterioration (e.g., pulmonary edema), morbidity, prolonged hospital length of stay, rehospitalization, and mortality. Fluid management in patients is further complicated because patients with a net positive fluid balance, for example heart failure patients, can also have intravascular volume depletion (e.g., blood loss, dehydration, sepsis) that should be treated with precise, timely, fluid resuscitation. The fluid balance goals are very dynamic and differ based on multiple factors (e.g., degreeDocket: U24-012 (222119-2270) of heart and kidney failure) and clinical scenarios. The fluid balance goals are not static, instead the desired fluid balance goals change during the hospitalization and vary by patient and condition. Unfortunately, clinicians have imprecise, error-prone, antiquated, unreliable tools to enable them to prescribe, adjust and achieve a wide range of net positive or negative fluid balance goals.

[0025] Numerous weaknesses exist in the present technologies, workflows, and approaches to monitoring and controlling fluid balance in hospitalized patients. This is a major issue for patients with heart failure, shock, and other maladies, as the rapid but safe alleviation of venous congestion and / or infusion of fluids to resolve shock is critical for patients. Studies in ICU found that up to 25 - 35% of daily input / output documentation have significant errors. More importantly, the current approach does not enable the clinician to easily prescribe, adjust, and achieve the desired fluid homeostasis in a timely, seamless, and effective way. The inability to achieve the desired fluid balance goals negatively impacts hard clinical endpoints (survival, time on ventilator, ICU length of stay, hospital length of stay, readmissions, and quality of life).

[0026] Tracking fluid balance, especially over a prolonged duration of time, is very difficult and unreliable. The proposed fluid balance management system can reliably and accurately track and predict patient fluid balance based on automated monitoring of all intake and outputs using a combination of (1) sensors, (2) scales, (3) algorithms for calculation of the estimated insensible fluid losses such as sweat and respiratory water loss, and (4) manual input from care staff for fluids that cannot be monitored with sensors directly (e.g., drinking or drain output).

[0027] The fluid balance management system can achieve the desired fluid balances and fluid balance rates reliably and accurately; the fluid balances and fluidDocket: U24-012 (222119-2270) balance rates can be adjusted throughout the different phases of critical illness. This can be achieved with an extracorporeal circuit, integrated fluid delivery systems, integrated fluid output sensors, and the system’s integrated pumps for delivery (restoration / infusion) or removal of fluid (ultrafiltration).

[0028] The fluid balance management system can enable a fully integrated, safe, and reliable new approach to fluid monitoring and prescription. The fluid balance management system can provide the critical care treatment team with critical, continuous, precise, new information (i.e., fluid balance and / or fluid balance rate) while decreasing errors. Further, the fluid balance management system can enable the clinician to reliably prescribe and achieve a broad range of positive or negative fluid balances and / or fluid balance rates that can be seamlessly adjusted at any time using corresponding setpoints for desired metrics and / or curves that specify target fluid balances and / or fluid balance rates over time. By addressing the current inefficiencies, inaccuracies, and inabilities to achieve the desired fluid balance goals, the fluid balance management system can revolutionize how fluid is prescribed.

[0029] To impact as many patients as possible, the fluid balance management system design can be universally compatible with different clinical fluid delivery devices (e.g., IV flow regulators, syringe pumps, etc.) and electronic medical record systems. Besides adults with heart failure, this system may be used in other clinical scenarios including but not limited to those with septic shock, trauma, cardiac failure, organ transplants, pediatric critical care, and burns. Additional applications include patients who require dialysis, hemofiltration, ventricular assist devices (VAD), decarboxylates, adsorption filters, and extracorporeal membrane oxygenation (ECMO). The system can also be integrated into other extra-corporeal devicesDocket: U24-012 (222119-2270) including dialysis, hemofiltration, ventricular assist device (VAD) decarboxylates, adsorption filters, and extracorporeal membrane oxygenation (ECMO).

[0030] The fluid balance management system can provide a number of features in the various embodiments, including the ability to:

[0031] 1. Continuously integrate and display all fluid inputs / outputs (including programmed insensible losses) and input / outputs that are manually entered into the system.

[0032] 2. Continuously calculate and display metrics including fluid provision, cumulative fluid balance, and / or fluid balance rate.

[0033] 3. Enable the clinician to reliably set, adjust, and achieve the desired positive or negative fluid balances and / or fluid balance rates.

[0034] 4. Provide alert systems based on absolute or relative fluid balance thresholds, fluid balance rate thresholds, projected future fluid balances within a predetermined timeframe, safety margins, and / or changes in these metrics over time.

[0035] The device’s extracorporeal circuit can be much smaller than other extracorporeal therapies (e.g., dialysis, hemofiltration, ECMO), and the complication rates can be lower than other technologies. Additionally, the device could be integrated into these and other extracorporeal therapies.

[0036] Referring next to FIG.1, shown is an example implementation according to embodiments of the disclosure. In FIG.1, shown is a networked environment 100 that implements extra-corporeal fluid balance and fluid balance rate monitoring and management. The networked environment 100 can include a computing device or environment 103, sensors 106, fluid pump or fluid regulator devices 109, and client devices 112, which can be in data communication with each other via a network 115.Docket: U24-012 (222119-2270)

[0037] The network 115 can include wide area networks (WANs), local area networks (LANs), personal area networks (PANs), or a combination thereof. These networks can include wired or wireless components or a combination thereof. Wired networks can include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and integrated services digital network (ISDN) networks. Wireless networks can include cellular networks, satellite networks, Institute of Electrical and Electronic Engineers (IEEE) 802.11 wireless networks (i.e., WI-FI®), BLUETOOTH®networks, microwave transmission networks, as well as other networks relying on radio broadcasts. The network 115 can also include a combination of two or more networks. Examples of networks can include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.

[0038] The computing device 103, while referred to in the singular, can include one or more computing devices that include a processor, a memory, and / or a network interface. For example, a computing device 103 can be configured to perform computations on behalf of other computing devices 103 or applications. As another example, such computing devices 103 can host and / or provide content to other computing devices in response to requests for content.

[0039] Moreover, the computing device 103 can refer to a plurality of computing devices 103 that can be arranged in one or more server banks or computer banks or other arrangements. Such computing devices 103 can be located in a single installation or can be distributed among many different geographical locations. For example, the computing device 103 can include a plurality of computing devices 103 that together can include a hosted computing resource, a grid computing resource or any other distributed computing arrangement. In some cases, the computing deviceDocket: U24-012 (222119-2270) 103 can correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time.

[0040] The sensors 106 can each detect one or more (e.g., three or another number) of fluid amounts and rates input into the system, and ultimately to the patient (see FIG.2). The sensors 106 can detect rates of fluid input using gravity drip bags, fluid pumps 109, syringe drivers, pressure bags, and other devices. The fluid inputs can include saline and crystalloid fluids, blood fluids, colloid fluids, nutrition fluids, electrolyte fluids, antibiotic fluids, and others. While these can include intravenous fluids, the fluids can also be pumped into a stomach of the patent. The sensors 106 can also detect fluid amounts and rates output from the patient, for example, urine through a urine flow sensor, blood draws through a blood flow sensor, and so on. The sensors 106 can be so designated whether the metric detected is volume, volume over time, pressure, weight, displacement, motion, angle, or another metric. The metrics detected by the sensors 106 can be representative of, or otherwise mapped to an amount of fluid input and / or output. The sensors 106 can be integrated into the circuit or can be external to the circuit.

[0041] Additional sensors 106 can assist clinicians in setting fluid balance goals or prescriptions. For example, sensors 106 for physiological data 146 can include, but are not limited to, photoplethysmography, impedence cardiology, doppler ultrasound, bioreactance, tonometry, pulse wave analysis, ballistocardiography, and laser doppler flometry, acoustic, vibrations and near-infrared spectroscopy. These sensors 106 can measure physiological data 146 such as heart rate and stroke volume, cardiac output, or cardiac filling over time. In another example, sensors 106 for physiological data 146 obtained from a patient that have key clinical ramifications can assist clinicians inDocket: U24-012 (222119-2270) setting fluid balance goals as well. In some examples, biomarkers for shock, such as lactic acid, other biomarkers, such as brain natriuretic peptide (BNP) level for monitoring cardiac filling, or biomarkers in the extracorporeal system, such as conductivity or pressure, can indicate key physiological conditions that may require different fluid balance goals. Using similar optic technology that is used to detect oxygen saturation non-invasively, hematocrit sensors 106 can monitor and display hematocrit levels over time which help the clinician determine a rate of hemoconcentration during fluid removal (ultrafiltration). In this way, change in hematocrit over time serves as a window into how the patient is refilling the fluid being removed from the vessels with extracellular fluid. If the hematocrit rises quickly (hemoconcentration), the clinician can see that the rate of refill is much slower than the rate of fluid removal. Other sensors 106 that can be transmitted through optics include venous oxygen saturation (SV02) sensors 106 which can provide a measure of oxygen content after perfusion on the venous side. This can be used to determine the degree of perfusion and oxygen consumption. Other helpful metrics that can be achieved with an extra-corporeal sensor include central venous pressure (a surrogate for intravascular volume). In some examples, the system can provide a prospective fluid balance prescription or recommendation, an alert / alarm 138, and / or automatically adjust target fluid balance data 129 or patient fluid balance data 126 based at least in part on the sensor data 151 of any of the sensors listed previously, hematocrit sensors 106, oxygen saturation sensors 106, venous pressure sensors 106, and other sensors 106.

[0042] The fluid pumps 109 can include syringe pumps, infusion pumps, volumetric pumps, fluid regulators, and other fluid delivery systems and devices. The fluid pumps 109 can include a circuit circulation pump 109 that circulates fluid in a fluidDocket: U24-012 (222119-2270) (e.g. blood) circuit of the patient’s fluid balance system, a fluid removal pump 109 that removes fluid from the fluid circuit (and thus from the patient), a fluid restoration pump 109 that adds supplemental fluids to restore fluid to the fluid circuit, as well as other fluid pumps 109 that provide other fluids. Fluid pumps 109 can move fluid including crystalloid fluids, blood fluids, colloid fluids, nutrition fluids, electrolyte fluids, antibiotic fluids, and other fluids. In some examples, a fluid pump 109 can include an integrated or otherwise associated sensor 106.

[0043] The client device 112 is representative of a plurality of client devices 112 that can be coupled to the network 115. The client device 112 can include a processor- based system such as a computer system. Such a computer system can be embodied in the form of a personal computer (e.g., a desktop computer, a laptop computer, or similar device), a mobile computing device (e.g., personal digital assistants, cellular telephones, smartphones, web pads, tablet computer systems, music players, portable game consoles, electronic book readers, and similar devices), media playback devices (e.g., media streaming devices, BluRay®players, digital video disc (DVD) players, set-top boxes, and similar devices), a videogame console, medical equipment or other devices with like capability. The client device 112 can include one or more displays such as liquid crystal displays (LCDs), gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (“E-ink”) displays, projectors, or other types of display devices. In some instances, the displays 184 can be a component of the client device 112 or can be connected to the client device 112 through a wired or wireless connection.

[0044] The client device 112 can be configured to execute various applications such as a client application or other applications. The client application can be executed in a client device 112 to access network content served up by the computingDocket: U24-012 (222119-2270) device(s) 103 or servers, thereby rendering a user interface on a display of the device. To this end, the client application can include a browser, a dedicated application, or other executable, and the user interface can include a network page, an application screen, or other user mechanism for obtaining user input. The client device 112 can be configured to execute client applications 190 such as browser applications, chat applications, messaging applications, email applications, social networking applications, word processors, spreadsheets, or other applications.

[0045] The client device 112 can include applications and other executable instructions that enable a user such as a doctor or other medical practitioner to receive and view alerts from the computing device 103. The client device 112 can also enable a user to view patient fluid balance data 126, set target fluid balance data 129, view projected fluid balance data 135, set and view fluid balance alerts 138, view and edit insensible fluid data 141 (e.g., estimated), enter manually entered fluid data 142, and view fluid balance graphic data 144, among other functions.

[0046] Various applications or other functionality can be executed in the computing device 103. The components executed on the computing device 103 include a fluid balance management application 117, or “Fluid Aviator”, and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. Various data is stored in a data store 120 that is accessible to the computing device 103. The data store 120 can be representative of a plurality of data stores 120, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. Moreover, combinations of these databases, data storage applications, and / or data structures may be used together to provide a single, logical, data store. The data stored in the data store 120Docket: U24-012 (222119-2270) is associated with the operation of the various applications or functional entities described below. This data can include patient data 123 and potentially other data.

[0047] Patient data 123 can include patient fluid balance data 126, target fluid balance data 129, projected fluid balance data 135, fluid balance alerts 138, insensible fluid data 141, manually entered fluid data 142 including inputs, outputs, and insensible fluid data 141 edits, physiological data 146, and other data such as a user identifier, user weight, and other information. The fluid balance goals are not static, instead the desired fluid balance goals change during the hospitalization and vary by patient and condition currently calculated based on measurements and estimations.

[0048] The patient fluid balance data 126 can include calculated real-time or near- real-time patient fluid balances (e.g., by volume, weight, or other appropriate measure), and patient fluid balance rates (e.g., volume over time, weight over time, or other appropriate measure). In this context, real time and near real time can refer to times with negligible or minimal delay in processing and display / use of the value in the system. For the purposes of the document, real time can refer to time under a centisecond, and near real time can refer to time under one second. Fluid balance data 126 can be timestamped, and a set of datapoints can indicate fluid balance rate curves and / or fluid balance curves over time.

[0049] The various types of timestamped patient fluid balance data 126 can be calculated using sensor data 151, fluid pumping instructions 154, and previous patient fluid balance data 126. This information can be used to calculate a sum of fluid inputs and fluid outputs, where inputs are positive and outputs are negative. In some examples, the patient fluid balances and patient fluid balance rates can further be divided by patient weight, or a value identified based at least in part on patient weight.Docket: U24-012 (222119-2270)

[0050] The target fluid balance data 129 can refer to fluid balances and fluid balance rates that are set by a user such as a doctor, nurse, or other medical practitioner as a target for the patient. The target fluid balance data 129 can also include a desired fluid balance path, such a predetermined fluid balance rate until a predetermined fluid balance value, after which another fluid balance rate is maintained to another fluid balance value, and so on. The fluid balance path can also include maintaining a particular fluid balance value for a predetermined amount of time or indefinitely, in view of all fluids input and / or output. A target fluid balance data 129 path can also include a predetermined curve of fluid balance over time (see FIG.5), whether manually input, preset for a particular medical condition, or selected from a list of paths. The paths can include paths generated from clinical data and other sources. The target fluid balance data 129 can include one or more target setpoints, to indicate target fluid balance rates, target fluid balances, target fluid balance rate curves and / or target fluid balance curves over time. Multiple target setpoints can be combined as a logical entity that indicates target fluid balance rate curves and / or target fluid balance curves over time.

[0051] The projected fluid balance data 135 can refer to projected values of fluid balances and / or fluid balance rates that are projected for a future time. The projected fluid balance data 135 can be calculated based at least in part on the current patient fluid balance data 126, the prescribed fluid balance rate as well as sensor data 151 or physiological data 146. A subset of sensor data 151 can be received in association with fluid pumps 109, and can be used as feedback to regulate the fluid pumping instructions 154. In another embodiment, a subset of physiological data 146 can be received in association with physiological sensors 106, and can be used as feedback to regulate the fluid pumping interactions 154.Docket: U24-012 (222119-2270)

[0052] The fluid pumping instructions 154 can include instructions or commands generated by the fluid balance management application 117 to control one or more of the fluid pumps 109. In some examples, a first subset of the fluid pumps 109 are controlled by the fluid balance management application 117, and a second subset of the fluid pumps 109 are controlled separately or are set at a predetermined rate. For example, some fluids such as a drug fluid or nutritional fluid may be set at a predetermined rate or controlled separately. However, in order to maintain a target fluid balance rate or achieve a target fluid balance setting in the target fluid balance data 129, the fluid balance management application 117 can control a fluid removal pump 109 (e.g., for ultrafiltration and removal), and / or a fluid infusion pump 109 (e.g., for supplemental fluid resuscitation). However, in other examples all fluid pumps can be controlled using the fluid pumping instructions 154 generated by the fluid balance management application 117.

[0053] The fluid balance alerts 138 can include user-set and predetermined alerts that indicate a predetermined fluid balance level is currently reached. The fluid balance alerts 138 can include user-set and predetermined alerts that indicate a predetermined fluid balance level has been attained and / or is projected within a predetermined time. As one example, an alert can trigger once a total fluid balance is reached, a total fluid balance relative to the patient weight or similar is reached, an absolute or relative rate of change (fluid balance rate) is reached, or a certain change in the fluid balance rate is reached.

[0054] The insensible fluid data 141 can refer to fluid losses that are insensible or undetected by the sensors 106. The insensible fluid data 141 can include predetermined rates of insensible fluid gain and loss for factors such as breathing, sweating, and other insensible fluid gains and losses. This data can includeDocket: U24-012 (222119-2270) adjustments for age, weight, height, blood pressure, known diseases or maladies, patient temperature, environmental temperature, elevation, humidity and other patient and environmental parameters. In one example, under nominal conditions (no fever, normal humidity) the system can indicate that an adult patient can lose 400 ml / m2of fluid a day. The average size adult male is around 1.73 m2. Based on the foregoing nonlimiting example values, the system can account for insensible fluid loss of 692 ml a day to account for losses from sweat and breath droplets. In some examples, the application 117 can cause the computing device 103 to generate an estimated value for insensible fluid data 141 based on algorithms that include formulas and clinical variables (for example, fever or use of humidified air).

[0055] The manually entered fluid data 142 can include user-entered information entered by a doctor, nurse, or other medical practitioner. This manually entered fluid data 142 can be used to adjust for gains and losses, including items such as input by drinking, output by vomit, excrement, and so on. It is noted that in some examples, manually entered fluid data 142 can include manually assisted system generated data.

[0056] For example, the system can include one or more scales for semi-manual liquid, food, excrement and other fluid input and output measurements. The user interface can provide a selection of a type of fluid (e.g., as simple as liquid, solid food, or as specific as a particular type of liquid or food). A medical practitioner can use a system-integrated scale to weigh the food or liquid product before and after ingestion, and the system can automatically generate and apply an appropriate fluid intake as a lump sum or a line or curve over the time from the weighing time before and after ingestion. In some examples, excrement, vomit, and other outputs can be semi- manually weighed and identified, for example with a system-integrated diaper scale, and the system can then automatically generate and apply an appropriate fluidDocket: U24-012 (222119-2270) balance to the patient fluid balance data 126 and the fluid balance graphing data 144. Direct manual inputs where a value is entered without a system-integrated measurement is also provided through the user interface.

[0057] The fluid balance graphing data 144 can include one or more types of graphs generated by the fluid balance management application 117. The fluid balance graphing data 144 can represent fluid balance information over time for a patient. This can include a plot of fluid balance amounts, graphed over a predetermined or use- selected amount of time. A user can modify the period of time represented in a graph, and the fluid balance management application 117 can update a display to match the selection. The fluid balance graphing data 144 can include graphs that represent all or a subset of patient fluid balance data 126, target fluid balance data 129, projected fluid balance data 135, fluid balance alerts 138, insensible fluid data 141, and manually entered fluid data 142 (not shown), in a graphical or visual format for display.

[0058] The physiological data 146 can include calculated real-time or near-real- time patient physiological measurements (e.g., stroke volume, cardiac output, lactic acid, etc.). In this context, real time and near real time can refer to times with negligible or minimal delay in processing and display / use of the value in the system. In various examples, real time can refer to time under a centisecond, and near real time can refer to time under one second. Physiological data 146 can be timestamped, and a set of datapoints can indicate physiological data change rate curves and / or physiological data curves over time.

[0059] The various types of timestamped patient physiological data 146 can be calculated using sensor data 151, manually entered physiological data from generated user interface elements, and previous patient physiological data 146. This information can be used to calculate effects of prospective fluid balance prescriptions for achievingDocket: U24-012 (222119-2270) specific physiological data targets or to calculate fluid balance prescriptions based at least in part on physiological data 146.

[0060] The fluid balance management application 117 can be executed to perform various actions. The fluid balance management application 117 can receive and monitor sensor data 151 from the sensors 106. The fluid balance management application 117 can generate all or a subset of patient fluid balance data 126, projected fluid balance data 135, and insensible fluid data 141 using this information. The fluid balance management application 117 can also generate user interface elements through which a medical practitioner can enter and / or confirm default target fluid balance data 129, fluid balance alerts 138, insensible fluid data 141, physiological data 146, and manually entered fluid data 142.

[0061] The fluid balance management application 117 can also automatically adjust target fluid balance data 129, projected fluid balance data 135, fluid balance alerts 138, insensible fluid data 141, and fluid balance graphing data 144, based at least in part on a physiological data 146 value or a hemodynamic parameter or a hemodynamic parameter indexed to the patient size, including at least one of: a central venous pressure (CVP) value, heart rate value, blood pressure value, stroke volume, stroke volume index (SVI), cardiac output, cardiac index (CI), or any combination thereof. Further, in some examples, the application 117 can automatically adjust target fluid balance data 129, projected fluid balance data 135, fluid balance alerts 138, insensible fluid data 141, and fluid balance graphing data 144, based at least in part on a clinical parameter of at least one of: hematocrit, venous oxygen saturation, or any combination thereof. The fluid balance management application 117 can also consider other patient and environmental factors including age, weight, height, known diseasesDocket: U24-012 (222119-2270) or maladies, patient temperature, environmental temperature, elevation, humidity and other patient and environmental parameters.

[0062] The fluid balance management application 117 can also generate and display the fluid balance graphing data 144. This can include generating visual and audible alerts based on the fluid balance alerts 138, and transmitting notifications over the network 115, for example, to a client device 112. The fluid balance graphing data 144 can also be transmitted to a client device 112 over the network 115, in addition to being displayed on a display local to the patient and / or the computing device 103.

[0063] The fluid balance management application 117 can also include algorithms for automated monitoring of an array of sensors 106 for accurate and reliable calculation of patient fluid balance data 126, patient physiological data 146, and other patient data 123; algorithms and associated components for accurate and reliable control of fluid balance rate adjustments (for example, accurate fluid pumping instructions 154 in view of sensor data 151, patient fluid balance data 126, patient physiological data 146, and other patient data 123); and algorithms and associated components for fail-safe operation, including failure conditions for any of the components such as sensors 106, fluid pumps 109, computing device 103, network 115, and default fluid balance alerts 138.

[0064] The fluid balance management application 117 can include a graphical user interface (GUI) which is capable of working with a controller area network (CAN) bus. A CAN bus can refer to a specialized internal communications network designed to interconnect microcontrollers and devices to communicate with each application without a host computer. The advantage of this approach is that data from multiple inputs communicate serially but in such a way that if more than one device transmits at the same time, the highest priority device can continue while the others back off.Docket: U24-012 (222119-2270) The GUI can incorporate multiple sensors 106, pumps 109, and intelligent input devices which can operate in an autonomous, bi-directional way. The GUI controls these devices and can allow system-based-governing and self-governing control based on the individual needs. The end-user can see and enter information with simple instructions in mobile phones or hand-held computers.

[0065] The fluid balance management application 117 can provide a fluid balance over time graph and fluid balance rate controllers which can be denoted as “ascent / climb / or leaving on” vs. a “descend / lower / take off” rate controller”. In addition the user interface contain elements that control the quantity of the fluid rate (ascend / descend) desired. The fluid balance volume and time can be set individually (for example liters and hours; respectively) or in combination (for example liters per hour). These controllers can be easily adjusted to achieve the desired fluid balance goals during different phases of illness in critically ill patients. This device offers a degree of precision in fluid management, both in terms of performance and in regard to improved patient safety.

[0066] FIG.2 shows an example of an extracorporeal fluid balance management system 200. This figure can provide an example arrangement of the various components of the networked environment 100 of FIG.1, as well as other components in an example fluid balance management system 200. As shown in the equipment legend, this example of the fluid balance management system 200 can include multiple types of sensors 106 including pressure sensors, flow meters, load cells for weight, physiological data sensors, and others. This example of the fluid balance management system 200 can include fluid pumps 109 such as syringe pumps, flow regulators, peristaltic pumps (or other positive displacement pumps). The fluid balance management system 200 and associated fluid balance management application 117Docket: U24-012 (222119-2270) (FIG. 1) can monitor and control complete fluid balance for a patient using this arrangement. The fluid balance management system 200 can provide a fluid circuit for patient blood, and can also provide monitoring of both fluids input and output at multiple locations in the circuit. The fluid balance management system 200 can also monitor other fluids including urine and sweat, or oral intake using both sensors, predetermined or user-entered values if the fluid cannot be detected using sensors 106. Some examples can also include outputs for testing certain fluids for analysis (i.e. blood) at various positions in the fluid circuit.

[0067] The fluid balance management system 200 can draw blood from the patient and return it via a double lumen central venous catheter. Blood moved through the blood circuit with a first pump (e.g., circuit circulation pump) such as roller pump, peristaltic pump, or other pump at blood flow of, for example,~ 50 ml / min or other system-set or variable value. A second pump (e.g., removal pump) can be placed on the hemofilter for fluid removal and / or ultrafiltration . A third pump (supplemental fluid restoration or resuscitation pump) can be placed to deliver general supplemental fluids to achieve fluid balance. The blood circuit have one or more ports for lab sampling (e.g., one located near the initial patient blood draw output and one near the return).

[0068] The example fluid balance management system 200 can include syringe or other fluid flows input into the system. The fluid balance management system 200 can include a urine flow sensor out of the system (not part of the blood circuit). Not shown, are other hardware features necessary to ensure safety in all extra-corporeal devices including air detector on the return line, and a blood leak detectors on the ultrafiltration line and access, return and filter pressures sensors.

[0069] One example of the fluid balance management system 200 can include one or more of the following:Docket: U24-012 (222119-2270)

[0070] 1. One port of a double lumen catheter (i.e., 7 F 10 cm) can connect to tubing that can connect to a hemofilter that can connect to tubing which can then return blood to the other port of the catheter.

[0071] 2. The system can use low-dose anticoagulant (i.e., heparin) that can be delivered through one of fluid infusion ports of the circuit.

[0072] 3. A small hemofilter with an ultrafiltration port can be connected to a pump that can allow and can control the ultrafiltration rate.

[0073] 4. The system can have 3 or another number of access ports for infusion of fluids. Each can have fluid flow sensors 106. Each can report information from multiple (up to 3 fluids) that are delivered by standard fluid delivery systems (i.e., pumps 109).

[0074] 5. The system can have 1 or another number of external patient fluid flow output sensors 106 that can measure urine flow or other outputs (i.e. colostomy).

[0075] 6. The system can allow insensible losses (i.e., sweat and respiratory water loss) to be programmed into the system (i.e., 400 ml / m2body surface area) as user- inputs and / or predetermined default values.

[0076] 7. The system can allow manual accounting of other intake (i.e., drinking) or output (i.e., chest tube losses) as single-timestamp additions or intake over a short period of time with a predetermined distribution over time.

[0077] 8. The system can integrate items 4, 5, 6, and 7 (and other data) to calculate the fluid balance.

[0078] 9. These inputs (items 4-8) (and other data) can provide systematic repeated inputs into a graphical user interface (GUI).Docket: U24-012 (222119-2270)

[0079] 10. The GUI can be able to communicate these inputs to the electronic medical record (EMR) (if desired). Alternatively, the input from the EMR can communicate the inputs to the GUI.

[0080] 11. The system can enable the clinician to accurately prescribe a fluid balance rate (as opposed to the current model which only allows a prescribed fluid intake rates).

[0081] 12. The circuit tubing can have multiple access ports for lab draws.

[0082] Table 1 shows one example calculation to achieve a net positive fluid balance prescription. The total measured fluid intake rate is (30+200+70) = 300 ml / hr. The total measured fluid output rate is (70+30) = 100 ml / hr. Prescribed “Net Fluid balance Goal” to LEAVE ON a positive 1000 ml / hr. To achieve this fluid balance, the system makes the Ultrafiltration pump rate set to 0 ml / hr and the Resuscitation pump rate set to 800 ml / hr. Table 1: Calculations for net positive fluid balance = 1000 ml / h Imputation Rates (ml / hr)

[0083] Table 2 shows calculations to achieve a net negative fluid balance prescription. The total measured fluid intake rate is (30+200+70) = 300 ml / hr. The totalDocket: U24-012 (222119-2270) measured fluid output rates is (70+30) = 100 ml / hr. Prescribed “Net Fluid Balance Goal” to TAKE OFF 200 ml / hr. To achieve this, the system would set the ultrafiltration pump rate to 400 ml / hr and the Resuscitation pump rate set to 0 ml / hr. Table 2: Calculations for net negative fluid balance = 200 ml / hr Imputation Rate (ml / hr)

[0084] FIG.3 illustrates an example display that includes fluid balance graphing data 144 generated for extracorporeal fluid balance management, graphed with a simulated value in accordance with various embodiments of the present disclosure. This figure shows that a graph generated using an example fluid balance management system 200 matches the ground truth (weight of a bag that represents the patient) expected graph values for fluid balance as volume graphed over time. A root mean square error (RMSE) in this example is 1.61 ml. However, this is showing general accuracy, and greater (or lesser) accuracies can be achieved in other examples. The plot of the expected ground truth value is not typically shown in a user interface of the fluid balance management system 200 (e.g., in the computing device 103), the fluid “aviator” value can refer to a fluid volume balance over time. In this example, the fluid volume balance graph can start at 0. However, a fluid balance management systemDocket: U24-012 (222119-2270) 200 can alternatively start at a predetermined positive or negative value (which can be set based on the estimated dry weight of the patient) or mapped to entry weight of a patient, or a user-entered value, or symptoms based value.

[0085] FIG. 4 illustrates an example user interface that includes fluid balance graphing data 144 for extracorporeal fluid balance management in accordance with various embodiments of the present disclosure. The main fluid balance line in this example can be the same as shown in FIG.3, but in this example, the fluid balance graphing data 144 further indicates a plurality of different fluid inputs and fluid outputs that affect the net fluid balance. In this example, they are shown graphically individual volumes over time, and overlayed with the net fluid balance over time. The supplemental and syringe values can generally be positive values that increase fluid balance, while the ultrafiltration and urine values can be negative values that decrease fluid balance.

[0086] FIG. 5 illustrates an example reference net fluid balance graph for extracorporeal fluid balance management in accordance with various embodiments of the present disclosure for different phases of shock. The fluid balance management system 200 will help facilitate attainment of the different goals of care independent of the amount of fluid intake needed for medications, blood products, or nutrition, and the patient’s urine or other outputs.

[0087] FIG.5 can correspond to a reference graph that depicts the fluid balance trajectory goals which have been proposed for different stages of critical illness in patients with sepsis. The fluid balance management system 200, including the fluid balance management application 117 and the computing device 103, can use to identify predetermined target fluid balance data 129 and fluid balance alerts 138, for example, as opposed to user-entered versions. This example corresponds to aDocket: U24-012 (222119-2270) Resuscitation, Optimization, Stabilization, Evacuation (ROSE) framework graph, but other predetermined graphs can be used. For the ROSE example, the user can set clinical targets, fluid balance targets, or targets based on sensors (i.e. changes in Hematocrit or Central venous pressure) to shift from one phase to another.

[0088] The fluid balance management application 117 can provide an on-screen recommendation of a target fluid balance or target fluid balance rate based on the reference graph and / or other data. A medical practitioner can select a user interface element to accept the recommendation, or can modify the recommendation and then select an element that implements the recommendation. The system can compare the patient’s actual patient fluid balance data 126 to the reference graph. Generally, if the medical practitioner sets the target as the reference graph, then the fluid balance management application 117 can control the fluid pumps 109 and other components to match the reference graph. Additionally, or alternatively, if the patient fluid balance data 126 differs, then a fluid balance alert 138 can trigger and a notification can be transmitted to a doctor or other medical practitioner.

[0089] In this example, the ROSE reference graph can indicate the following:

[0090] • Resuscitation - For the first 6-8 hours the patient requires aggressive fluid resuscitation and net positive fluid balance goal to maximize cardiac output and organ perfusion.

[0091] • Optimization - During this stage, excessive fluid delivery must be avoided to prevent fluid overload and its consequences, which include pulmonary, cardiac, and renal congestion. Prevention of a net positive fluid balance here is essential.

[0092] • Stabilization – During this phase the patient may not be ready for fluid removal. A net even fluid balance is needed to maintain organ perfusion.Docket: U24-012 (222119-2270)

[0093] • De-escalation – During this phase the patient is ready for the fluids to come off with a net negative fluid balance.

[0094] Avoidance of fluid overload is important as excessive fluid leads to organ congestion and impaired organ function which aggravate morbidities such acute respiratory distress syndrome (ARDS) or congestive heart failure. Careful fluid administration of the right fluid balance rate can reduce the need prolonged ventilatory and cardiac support interventions, decrease extended ICU and hospital stays, decrease costs, and prevent deaths in neonatal, pediatric and adult ICU patients.

[0095] The term "substantially" is meant to permit deviations from the descriptive term that does not negatively impact the intended purpose. Descriptive terms are implicitly understood to be modified by the word substantially, even if the term is not explicitly modified by the word substantially.

[0096] A number of software components previously discussed are stored in the memory of the respective computing devices and are executable by the processor of the respective computing devices. In this respect, the term "executable" means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be a compiled program that can be translated into machine code in a format that can be loaded into a random-access portion of the memory and run by the processor, source code that can be expressed in proper format such as object code that is capable of being loaded into a random-access portion of the memory and executed by the processor, or source code that can be interpreted by another executable program to generate instructions in a random-access portion of the memory to be executed by the processor. An executable program can be stored in any portion or component of the memory, including random-access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, Universal Serial Bus (USB)Docket: U24-012 (222119-2270) flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

[0097] The memory includes both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. Thus, the memory can include random-access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, or other memory components, or a combination of any two or more of these memory components. In addition, the RAM can include static random-access memory (SRAM), dynamic random-access memory (DRAM), or magnetic random-access memory (MRAM) and other such devices. The ROM can include a programmable read-only memory (PROM), an erasable programmable read- only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device.

[0098] Although the applications and systems described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same can also be embodied in dedicated hardware or a combination of software / general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-Docket: U24-012 (222119-2270) programmable gate arrays (FPGAs), or other components, etc. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein.

[0099] The flowchart shows the functionality and operation of an implementation of portions of the various embodiments of the present disclosure. If embodied in software, each block can represent a module, segment, or portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that includes human- readable statements written in a programming language or machine code that includes numerical instructions recognizable by a suitable execution system such as a processor in a computer system. The machine code can be converted from the source code through various processes. For example, the machine code can be generated from the source code with a compiler prior to execution of the corresponding application. As another example, the machine code can be generated from the source code concurrently with execution with an interpreter. Other approaches can also be used. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function or functions.

[0100] Although the flowchart shows a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession can be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in the flowchart can be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performanceDocket: U24-012 (222119-2270) measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure.

[0101] Also, any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system. In this sense, the logic can include statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a "computer-readable medium" can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system. Moreover, a collection of distributed computer- readable media located across a plurality of computing devices (e.g., storage area networks or distributed or clustered filesystems or databases) may also be collectively considered as a single non-transitory computer-readable medium.

[0102] The computer-readable medium can include any one of many physical media such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium can be a random-access memory (RAM) including static random-access memory (SRAM) and dynamic random-access memory (DRAM), or magnetic random-access memory (MRAM). In addition, the computer-readable medium can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.Docket: U24-012 (222119-2270)

[0103] Further, any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more applications described can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices in the same computing device 103.

[0104] In addition to the foregoing, the various embodiments of the present disclosure include, but are not limited to, the embodiments set forth in the following clauses.

[0105] Clause 1 - A system for monitoring fluid balance, comprising: at least one fluid sensor configured to measure fluid intake data or fluid output data for at least one input fluid or output fluid for a patient; and at least one computing device comprising at least one processor and at least one memory comprising an application, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: receive the fluid intake data and the fluid output data; identify target fluid balance data; and generate a fluid balance graph that indicates fluid balance over time and projected fluid balance over a period of time, based at least in part on the fluid intake data and the fluid output data.

[0106] Clause 2 - The system of clause 1, further comprising a fluid restoration pump that provides a restoration fluid flow rate for the patient; a fluid removal pump that provides a fluid removal flow rate for the patient; and wherein the application, when executed by the at least one processor, further causes the at least one computing device to at least: generate at least one control signal that continuously or periodically adjusts at least one of: the restoration fluid flow rate, the fluid removal flowDocket: U24-012 (222119-2270) rate, or any combination thereof, based at least in part on an analysis of the fluid intake data, the fluid output data, and the target fluid balance data; and generate the fluid balance graph that indicates fluid balance over a period of time, based at least in part on the fluid intake data, the fluid output data, and the at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof.

[0107] Clause 3 - The system of clause 1 or 2, wherein the fluid balance for a particular point in fluid balance graph corresponds to a total fluid value relative to a patient weight.

[0108] Clause 4 - The system of any one of clauses 1-3, wherein the initial fluid balance value corresponds to at least one of: zero, a predetermined default value, or a user-entered value, or a value derived from patient historic weights, clinical signs, symptoms or sensor data.

[0109] Clause 5 - The system of any one of clauses 1-4, wherein the fluid balance graph is displayed in a user interface that provides an indication of a current fluid balance value and a current fluid balance rate.

[0110] Clause 6 - The system of any one of clauses 2-5, wherein the fluid balance graph is displayed in a user interface that indicates at least one of a fluid value or a fluid flow rate for a respective one of: the at least one input fluid, the at least one output fluid, a restoration fluid of the fluid restoration pump, and a removal fluid of the fluid removal pump.

[0111] Clause 7 - The system of clause 5 or 6, wherein the fluid balance graph is displayed in a user interface that provides an indication of at least one projected fluid balance value based at least in part on the current fluid balance value and the current fluid balance rate.Docket: U24-012 (222119-2270)

[0112] Clause 8 - The system of any one of clauses 1-7, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: identify at least one manually input fluid value that is input using: at least one of a graphical user interface element of a graphical user interface, a physical control device, or any combination thereof.

[0113] Clause 9 - The system of any one of clauses 1-8, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: generate an estimated value for an insensible fluid output.

[0114] Clause 10 - The system of any one of clauses 1-9, wherein the application, when executed by the at least one processor, causes the at least one computing device to trigger an alert in response to patient fluid value data matching at least one of: a target fluid balance value, a target fluid balance relative to the patient weight, an absolute or relative target fluid balance rate.

[0115] Clause 11 – The system of any one of claims 1-10, wherein the application, when executed by the at least one processor, causes the at least one computing device to: adjust a fluid balance rate based at least in part on at least one hemodynamic variable.

[0116] Clause 12 - The system of clause 11, wherein the at least one hemodynamic variable comprises: central venous pressure (CVP) value, hematocrit test (HCT) value, heart rate value, stroke volume, stroke volume index (SVI), cardiac output, cardiac index (CI), blood pressure value, or any combination thereof.

[0117] Clause 13 - The system of any one of clauses 1-12, wherein the application, when executed by the at least one processor, causes the at least one computing device to suggest or set a component of at least one of: a dry weight value, a fluid balance rate algorithm, and fluid balance projections.Docket: U24-012 (222119-2270)

[0118] Clause 14 - A system for monitoring and prescribing fluid balance, comprising: at least one fluid sensor configured to measure fluid intake data or fluid output data for at least one input fluid or output fluid for a patient; and at least one computing device comprising at least one processor and at least one memory comprising an application, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: receive the fluid intake data and the fluid output data; monitor the fluid intake data and the fluid output data over a period of time; predict at least one prospective fluid balance prescription required to achieve a specific physiological target or fluid balance based at least in part on the monitored fluid intake data and fluid output data; and generate a fluid balance graph that indicates a monitored fluid balance over the period of time and a projected fluid balance over a period of time based at least in part on the at least one prospective fluid balance prescription required to achieve a specific physiological target or fluid balance.

[0119] Clause 15 - The system of clause 14, further comprising an automated fluid management device comprising: a fluid restoration pump that provides a restoration fluid flow rate for a patient; a fluid removal pump that provides a fluid removal flow rate for the patient; and wherein, when executed by the at least one processor, the application further causes the computing device to at least: receive the fluid intake data and the fluid output data; receive the at least one prospective fluid balance prescription required to achieve a specific physiological target; identify target fluid balance data; and generate at least one control signal that continuously or periodically adjusts at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof, based at least in part on an analysis of the fluid intake data, theDocket: U24-012 (222119-2270) fluid output data, the at least one prospective fluid balance prescription, and the target fluid balance data.

[0120] Clause 16 - The system of clause 15, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: identify at least one manually input target fluid balance value that is input using: at least one of a graphical user interface element of a graphical user interface, a physical control device, or any combination thereof.

[0121] Clause 17 - The system of any one of clauses 14-16, wherein the application, when executed by the at least one processor, further causes the at least one computing device to at least alert a user if the monitored fluid balance reaches either a specified absolute value or a specified change in the monitored fluid balance.

[0122] Clause 18 - The system of any one of clauses 14-17, wherein the application, when executed by the at least one processor, further causes the at least one computing device to at least alert a user if the projected fluid balance reaches either a specified absolute value, a specified change in the monitored fluid balance, a specified predicted patient outcome, or a combination of any thereof.

[0123] Clause 19 - The system of any one of clauses 14-18, further comprising: at least one sensor that measures at least one physiological data point obtained from the patient; and wherein, when executed by the at least one processor, the application further causes the computing device to at least: receive the physiological data point; monitor the physiological data point; and predict at least one prospective fluid balance prescription required to achieve the specific physiological target or fluid balance based at least in part on the monitored physiological data point.

[0124] Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used inDocket: U24-012 (222119-2270) general to present that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X; Y; Z; X or Y; X or Z; Y or Z; X, Y, or Z; etc.). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

[0125] It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described embodiments without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

[0126] Various embodiments of the present disclosure are described in the following clauses. Although the following clauses describe some embodiments of the present disclosure, other embodiments of the present disclosure are also set forth above.

[0127] It should be noted that ratios, concentrations, amounts, and other numerical data may be expressed herein in a range format. It is to be understood that such a range format is used for convenience and brevity, and thus, should be interpreted in a flexible manner to include not only the numerical values explicitly recited as the limits of the range, but also to include all the individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly recited. To illustrate, a concentration range of “about 0.1% to about 5%” should be interpreted to include not only the explicitly recited concentration of about 0.1 % to about 5 %, but also include individual concentrations (e.g., 1%, 2%, 3%, and 4%) and the sub-ranges (e.g., 0.5%, 1.1%, 2.2%, 3.3%, and 4.4%) within the indicated range.Docket: U24-012 (222119-2270) The term “about” can include traditional rounding according to significant figures of numerical values. In addition, the phrase “about ‘x’ to ‘y’” includes “about ‘x’ to about ‘y’”.

Claims

Docket: U24-012 (222119-2270) CLAIMS Therefore, at least the following is claimed:

1. A system for monitoring fluid balance, comprising: at least one fluid sensor configured to measure fluid intake data or fluid output data for at least one input fluid or output fluid for a patient; and at least one computing device comprising at least one processor and at least one memory comprising an application, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: receive the fluid intake data and the fluid output data; identify target fluid balance data; and generate a fluid balance graph that indicates fluid balance over time and projected fluid balance over a period of time, based at least in part on the fluid intake data and the fluid output data.

2. The system of claim 1, further comprising: a fluid restoration pump that provides a restoration fluid flow rate for the patient; a fluid removal pump that provides a fluid removal flow rate for the patient; and wherein the application, when executed by the at least one processor, further causes the at least one computing device to at least: generate at least one control signal that continuously or periodically adjusts at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof, based at least in part on an analysis of the fluid intake data, the fluid output data, and the target fluid balance data; and generate the fluid balance graph that indicates fluid balance over a period of time, based at least in part on the fluid intake data, the fluid output data, and the at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof.Docket: U24-012 (222119-2270) 3. The system of claim 1 or 2, wherein the fluid balance for a particular point in fluid balance graph corresponds to a total fluid value relative to a patient weight.

4. The system of any one of claims 1-3, wherein the initial fluid balance value corresponds to at least one of: zero, a predetermined default value, or a user-entered value, or a value derived from patient historic weights, clinical signs, symptoms or sensor data.

5. The system of any one of claims 1-4, wherein the fluid balance graph is displayed in a user interface that provides an indication of a current fluid balance value and a current fluid balance rate.

6. The system of any one of claims 2-5, wherein the fluid balance graph is displayed in a user interface that indicates at least one of a fluid value or a fluid flow rate for a respective one of: the at least one input fluid, the at least one output fluid, a restoration fluid of the fluid restoration pump, and a removal fluid of the fluid removal pump.

7. The system of claim 5 or 6, wherein the fluid balance graph is displayed in a user interface that provides an indication of at least one projected fluid balance value based at least in part on the current fluid balance value and the current fluid balance rate.Docket: U24-012 (222119-2270) 8. The system of any one of claims 1-7, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: identify at least one manually input fluid value that is input using: at least one of a graphical user interface element of a graphical user interface, a physical control device, or any combination thereof.

9. The system of any one of claims 1-8, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: generate an estimated value for an insensible fluid output.

10. The system of any one of claims 1-9, wherein the application, when executed by the at least one processor, causes the at least one computing device to trigger an alert in response to patient fluid value data matching at least one of: a target fluid balance value, a target fluid balance relative to the patient weight, an absolute or relative target fluid balance rate.

11. The system of any one of claims 1-10, wherein the application, when executed by the at least one processor, causes the at least one computing device to: adjust a fluid balance rate based at least in part on at least one hemodynamic variable.

12. The system of claim 11, wherein the at least one hemodynamic variable comprises: central venous pressure (CVP) value, hematocrit test (HCT) value, heart rate value, stroke volume, stroke volume index (SVI), cardiac output, cardiac index (CI), blood pressure value, or any combination thereof.Docket: U24-012 (222119-2270) 13. The system of any one of claims 1-12, wherein the application, when executed by the at least one processor, causes the at least one computing device to suggest or set a component of at least one of: a dry weight value, a fluid balance rate algorithm, and fluid balance projections.

14. A system for monitoring and prescribing fluid balance, comprising: at least one fluid sensor configured to measure fluid intake data or fluid output data for at least one input fluid or output fluid for a patient; and at least one computing device comprising at least one processor and at least one memory comprising an application, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: receive the fluid intake data and the fluid output data; monitor the fluid intake data and the fluid output data over a period of time; predict a projected fluid balance over a period of time based at least in part on the monitored fluid intake data and fluid output data; prescribe at least one prospective fluid balance prescription required to achieve a specific physiological target or fluid balance based at least in part on the monitored fluid intake data and fluid output data and the projected fluid balance; and generate a fluid balance graph that indicates the monitored fluid balance over the period of time and the projected fluid balance over the period of time based at least in part on the at least one prospective fluid balance prescription.Docket: U24-012 (222119-2270) 15. The system of claim 14, further comprising an automated fluid management device comprising: a fluid restoration pump that provides a restoration fluid flow rate for a patient; a fluid removal pump that provides a fluid removal flow rate for the patient; and wherein, when executed by the at least one processor, the application further causes the computing device to at least: receive the fluid intake data and the fluid output data; receive the at least one prospective fluid balance prescription required to achieve a specific physiological target; identify target fluid balance data; and generate at least one control signal that continuously or periodically adjusts at least one of: the restoration fluid flow rate, the fluid removal flow rate, or any combination thereof, based at least in part on an analysis of the fluid intake data, the fluid output data, the at least one prospective fluid balance prescription, and the target fluid balance data.

16. The system of claim 15, wherein the application, when executed by the at least one processor, causes the at least one computing device to at least: identify at least one manually input target fluid balance value that is input using: at least one of a graphical user interface element of a graphical user interface, a physical control device, or any combination thereof.

17. The system of any one of claims 14-16, wherein the application, when executed by the at least one processor, further causes the at least one computing device to atDocket: U24-012 (222119-2270) least alert a user if the monitored fluid balance reaches either a specified absolute value or a specified change in the monitored fluid balance.

18. The system of any one of claims 14-17, wherein the application, when executed by the at least one processor, further causes the at least one computing device to at least alert a user if the projected fluid balance reaches either a specified absolute value, a specified change in the monitored fluid balance, a specified predicted patient outcome, or a combination of any thereof.

19. The system of any one of claims 14-18, further comprising: at least one sensor that measures at least one physiological data point obtained from the patient; and wherein, when executed by the at least one processor, the application further causes the computing device to at least: receive the physiological data point; monitor the physiological data point; and predict the at least one prospective fluid balance prescription required to achieve the specific physiological target or fluid balance based at least in part on the monitored physiological data point.

Images