Perioperative fluid management system and method

Abstract

A system for perioperative fluid management is provided. The system includes a plurality of sensors configured to generate measurement data representing fluid input to and output from a subject. A monitoring device generates hemodynamic data representing the subject's cardiac output. A computing device receives the measurement data, computes a fluid balance, and determines, based on the fluid balance and the hemodynamic data, whether adjustment to the infusion rate is required to achieve or maintain the subject's cardiac output. If adjustment is required, the computing device generates a control signal representing an adjusted infusion rate. An infusion pump receives the control signal and delivers fluids to the subject according to the adjusted infusion rate.

Description

PERIOPERATIVE FLUID MANAGEMENT SYSTEM AND METHODCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 652125 entitled PERIOPERATIVE FLUID MANAGEMENT SYSTEM AND METHOD, filed May 27, 2024, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present specification is directed to anesthesiology and surgical practice, specifically to methods and systems for managing a patient’s fluid status before, during, and after surgery.BACKGROUND

[0003] Timely management by anesthesiologists of fluid intake and blood loss during surgery or critical care is critical to maintain adequate cardiac output and tissue perfusion. Anesthesiologists make periodic assessments of a patent’s fluid needs based on visual estimates of fluids in intravenous fluid bags. A few tools are available to assist these periodic assessments including the Stryker™ surgical blood collection unit and sponge counter, however this optical sensor is often confounded by blood foaming. Overreliance on such measurements can lead to significant fluid overload and hemodynamic instability or death, particularly in patients with heart disease or low body mass.SUMMARY

[0004] An aspect of the specification provides a system for perioperative fluid management including a plurality of sensors configured to generate measurement data representing fluid input and output from a subject. The system includes a monitoring device configured to generate hemodynamic data representing the subject’s cardiac output. A computing device is connected to the sensors and configured to compute a fluid balance according to the measurement data. The computing device determines, based on the fluid balance and the hemodynamic data, whether an adjustment to the infusion rate is required to achieve or maintain the subject’s cardiac output. If an adjustment isrequired, the computing device generates a control signal representing an adjusted infusion rate that is effective to achieve or maintain the subject’s cardiac output. An infusion pump is connected to the computing device and is configured to receive the control signal and deliver fluids to the subject according to the adjusted infusion rate.

[0005] In one example, the plurality of sensors includes two or more of the following: an intravenous sensor connected to a fluid bag and configured to measure fluid infusion to the subject from the fluid bag, an irrigation sensor connected to an irrigation apparatus and configured to measure fluids delivered to the subject by the irrigation apparatus, a suction sensor connected to a storage canister of a suction apparatus and configured to measure fluids collected from the subject by the suction apparatus, a sponge counter configured to measure a weight of a surgical sponge before and after use, a urine sensor connected to a catheter and configured to measure urine obtained from the subject via the catheter, and a blood flow sensor connected to an intraoperative blood salvage device and configured to measure blood delivered to the subject by the intraoperative blood salvage device.

[0006] In one example, the sensors include a flow sensor selected from one or more of a turbine sensor, a vortex sensor, a magmeter, an ultrasonic sensor, a positive displacement flow sensor, and a thermal mass flow sensor.

[0007] In one example, the sensors include a volume sensor selected from one or more of an ultrasonic sensor, a capacitive volume sensor, a weight-based sensor, an optical sensor, a float sensor, a hydrostatic pressure sensor, and a radar volume sensor.

[0008] In one example, the computing device is further configured to receive additional measurement data from the sensors. The computing device determines, based on the additional measurement data, whether a further adjustment to the infusion rate is required to achieve or maintain the subject’s cardiac output. If so, the computing device regenerates the control signal to represent a further adjusted infusion rate.

[0009] In one example, the computing device includes a display and is configured to output the fluid balance at the display.

[0010] In one example, a fluid management engine is connected to the computing device via a network. The fluid management engine is configured to receive the fluid balance and the hemodynamic data from the computing device. The fluid management engine retrieves reference data from memory and generates an alert representing a predicted surgical outcome based on a comparison of the fluid balance and the hemodynamic data to the reference data. The alert is transmitted to the computing device, which is configured to generate the control signal responsive to receiving the alert.

[0011] In one example, the hemodynamic data includes one or more of alveolar ventilation, blood oxygen saturation, blood carbon dioxide saturation, oxygen consumption, carbon dioxide production, shunt fraction, dead space, and cardiac output.

[0012] In one example, the fluid management engine is further configured to receive health records associated with the subject from an electronic health records system via the network and to generate the alert based on the health records.

[0013] A further aspect of the specification provides a system for perioperative fluid management including a plurality of sensors configured to generate measurement data representing fluid input and output from a subject. A computing device is connected to the sensors and is configured to compute a fluid balance according to the measurement data. The computing device determines whether adjustment to the infusion rate is required to achieve or maintain a target fluid balance. If an adjustment is required, the computing device generates a control signal representing an adjusted infusion rate effective to achieve or maintain the target fluid balance. An infusion pump is connected to the computing device and is configured to receive the control signal and deliver fluids to the subject according to the adjusted infusion rate.

[0014] In one example, the sensors include two or more of an intravenous sensor, an irrigation sensor, a suction sensor, a sponge counter, a urine sensor, and a blood flow sensor as described above.

[0015] In one example, the sensors include a flow sensor selected from one or more of a turbine sensor, a vortex sensor, a magmeter, an ultrasonic sensor, a positivedisplacement flow sensor, and a thermal mass flow sensor.

[0016] In one example, the sensors include a volume sensor selected from one or more of an ultrasonic sensor, a capacitive volume sensor, a weight-based sensor, an optical sensor, a float sensor, a hydrostatic pressure sensor, and a radar volume sensor.

[0017] In one example, the computing device is configured to receive additional measurement data from the sensors. The computing device determines, based on the additional measurement data, whether a further adjustment to the infusion rate is required to maintain or restore the target fluid balance. If so, the control signal is regenerated to represent the further adjusted infusion rate.

[0018] In one example, the computing device includes a display and is configured to output the fluid balance at the display.

[0019] In one example, the system includes a fluid management engine connected to the computing device via a network. The fluid management engine receives the fluid balance, retrieves reference data from memory, generates an alert representing a predicted surgical outcome based on a comparison of the fluid balance to the reference data, and transmits the alert to the computing device. The computing device generates the control signal responsive to the alert.

[0020] In one example, the system includes a monitoring device configured to generate physiological data representing one or more physiological measurements of the subject. The physiological data is transmitted to the fluid management engine, and the alert is generated according to the physiological data.

[0021] In one example, the physiological data includes one or more of heart rate, blood pressure, respiratory rate, blood oxygenation, blood carbon dioxide, body temperature, and electrocardiography.

[0022] In one example, the fluid management engine is configured to receive health records associated with the subject from an electronic health records system via the network and to generate the alert according to the health records.

[0023] A further aspect of the specification provides a method of perioperative fluidmanagement including receiving, at a computing device, measurement data generated by a plurality of sensors representing fluid input and output from a subject. The computing device computes a fluid balance according to the measurement data and determines whether adjustment to the infusion rate is required to achieve or maintain a target fluid balance. If so, the computing device generates a control signal representing the adjusted infusion rate and transmits the control signal to an infusion pump. The infusion pump delivers fluids to the subject at the adjusted infusion rate.

[0024] In one example, the method includes receiving additional measurement data from the sensors and determining whether a further adjustment to the infusion rate is required based on the additional data. If so, the control signal is regenerated to represent the further adjusted infusion rate.

[0025] In one example, the method includes outputting the fluid balance at a display connected to the computing device.

[0026] In one example, the method includes transmitting the fluid balance from the computing device to a fluid management engine, retrieving reference data from memory at the fluid management engine, generating an alert based on a comparison of the fluid balance to the reference data, and transmitting the alert to the computing device. The control signal is further generated based on the alert.

[0027] In one example, the method includes generating physiological data at a monitoring device, transmitting the physiological data to the fluid management engine, and generating the alert according to the physiological data.

[0028] In one example, the method includes receiving health records associated with the subject at the fluid management engine from an electronic health records system. The alert is further generated according to the health records.

[0029] A further aspect of the specification provides a system for perioperative fluid management including a plurality of sensors configured to generate measurement data representing fluid input and output from a subject. A monitoring device is configured to generate hemodynamic data representing the subject’s cardiac output. A computingdevice is connected to the sensors and is configured to compute a fluid balance according to the measurement data and determine whether adjustment to the infusion rate is required to achieve or maintain the subject’s cardiac output. If so, the computing device generates a control signal representing an adjusted infusion rate. A fluid management engine is connected to the computing device via a network and is configured to receive the fluid balance and cardiac output data, retrieve reference data from memory, generate an alert representing a predicted surgical outcome, and transmit the alert to the computing device. The computing device is configured to generate the control signal responsive to the alert. An infusion pump is connected to the computing device and delivers fluids to the subject according to the adjusted infusion rate.

[0030] These together with other aspects and advantages which will be subsequently apparent, reside in the details of construction and operation as more fully hereinafter described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein like numerals refer to like parts throughout.BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Embodiments are described with reference to the following figures.

[0032] Figure 1 is a schematic diagram showing a system for perioperative fluid management including a sensor and a fluid management engine, according to one embodiment.

[0033] Figure 2 is a front elevation view of the sensor of Figure 1 , according to one embodiment.

[0034] Figure 3A is a graph depicting measurement data generated by the sensor of Figure 1 , according to one embodiment.

[0035] Figure 3B another graph depicting measurement data generated by the sensor of Figure 1 , according to one embodiment.

[0036] Figure 4 is a schematic diagram showing a method of perioperative fluid management using the system of Figure 1 .

[0037] Figure 5 is a schematic diagram showing the fluid management engine of Figure 1 , according to one embodiment.

[0038] Figure 6 is a schematic diagram showing a method of perioperative fluid management using the system of Figure 1 .DETAILED DESCRIPTIONTABLE OF ABBREVIATIONS

[0039] The following abbreviations are used herein:SYSTEM AND METHOD

[0040] Fluid management is critical during anesthesia to maintain adequate cardiac output and tissue perfusion. Anesthetic agents can cause vasodilation and myocardial depression, reducing blood pressure and cardiac output. Hypovolemia can exacerbate hypotension and impair organ perfusion. An improved method of perioperative fluid management is provided herein.

[0041] Referring now to Figure 1 , a system for perioperative fluid management is indicated generally at 100. The system 100 includes a plurality of sensors 104-1 , 104-2...104-n, generically referred to herein as “sensor 104” or collectively as “sensors 104” (this terminology is used elsewhere herein) configured to measure fluid input and output from a subject via one or more surgical apparatuses 106-1 , 106-2, 106-n. The sensors 104 are connected to a computing device 108 which is further connected to an infusion pump 112 for controlling fluid infusion to the subject.

[0042] The plurality of sensors 104 is configured to generate measurement data representing fluid input and fluid output from the subject. The plurality of sensors 104 may include at least one of a sensor configured to measure fluid input, a sensor configured to measure fluid output, and a sensor configured to measure both fluid input and output. The sensors 104 may include one or more different types of sensor for measuring the fluid input and / or output. In specific examples, the sensors 104 include a flow sensor or a volume sensor. Suitable examples of flow sensors include but are not limited to a turbine sensor, a vortex sensor, a magmeter, an ultrasonic sensor, a positive displacement flow sensor, and a thermal mass flow sensor. Suitable examples of volume sensors include but are not limited to an ultrasonic sensor, a capacitive volume sensor, a weight-based sensor, an optical sensor, a float sensor, a hydrostatic pressure sensor, and a radar volume sensor.

[0043] One or more of the sensors 104 may be associated with surgical apparatuses 106 which are configured to deliver or receive fluids from the subject. Suitable examples of surgical apparatuses include but are not limited to an intravenous bag, an irrigation apparatus, a surgical drain, a suction apparatus, a blood transfusion device, a hemodialysis device, a cardiopulmonary-bypass circuit, an extracorporeal membrane-oxygenation (ECMO) circuit, a blood salvage device, a waste receptacle, a catheter, a respirator, and combinations thereof. While the sensor 104 is generally described herein as being separate from the surgical apparatus, it should be understood that the sensor 104 may be integrated with the respective surgical apparatus 106. Furthermore, the plurality of sensors 104 may be associated with one or more different types of surgical apparatuses 106, and therefore the sensors 104 can collect measurements from a plurality of fluid input and output sources.

[0044] In the non-limiting embodiment shown in Figure 1 , the first sensor 104-1 is an intravenous sensor connected to a fluid bag 106-1 and configured to measure fluid infusion from the fluid bag 106-1. The second sensor 104-2 in Figure 1 is a urine sensor connected to a catheter 106-2 and configured to measure urine obtained from the subject via the catheter 106-2. The nth sensor 104-n is a sponge counter comprising a receptable configured to receive a surgical sponge 106-n and measure the weight of said surgical sponge before and after use to compute the weight of fluid absorbed from the subject into the surgical sponge. The examples shown in Figure 1 are non-limiting and other combinations of sensors 104 and surgical apparatuses 106 are contemplated. In further non-limiting embodiments, the sensors 104 include an irrigation sensor connected to an irrigation apparatus and configured to measure fluids delivered from the subject by the irrigation apparatus. In further non-limiting embodiments, the sensors 104 include a suction sensor connected to a storage cannister of a suction apparatus and configured to measure fluids collected from the subject by the suction apparatus. In further non-limiting embodiments, the sensors 104 include a blood flow sensor connected to an intraoperative blood salvage device configured to measure blood delivered to the subject by the blood salvage device.

[0045] Since the plurality of sensors 104 can include multiple types of sensors connected to multiple types of surgical apparatuses, the system 100 is capable of measuring fluid input and output from a variety of different sources. The anesthesiologist therefore can obtain a comprehensive outlook on the overall fluid intake or loss.

[0046] The sensor 104 may further include a power source, and in specific examples, the sensor 104 includes an integrated lithium rechargeable 1 ,500 mAh battery. The sensor 104 may further include an input device for receiving user inputs, an output device for display information, a processor, and a memory.

[0047] Figure 2 shows an example of the sensor 104-1 according to a non-limiting embodiment. In this example, the sensor 104 comprises an enclosure 202 and a display 204 for outputting a measurement obtained by the sensor 104-1 . The sensor 104-1 further includes a microcontroller for executing instructions and storing data in memory. Inspecific non-limiting embodiments, the microcontroller is an ESP32™ microcontroller, however the microcontroller is not particularly limited.

[0048] The sensor 104-1 may further include an input device 208 configured to receive user inputs providing contextual information about the measurements. User inputs may include the type of fluid, the size of surgical sponge, and the like. In some examples, the user input may indicate that a fluid bag or surgical sponge has been replaced or that a waste receptable has been emptied. The user inputs may be transmitted to the computing device 108 and used to calculate the fluid balance.

[0049] In the example shown in Figure 2, the sensor 104-1 is a weight-based sensor and accordingly the sensor 104-1 includes a first attachment means 212 at one end of the enclosure 202 configured to support the sensor 104-1 , and a second attachment means 216 at an opposite end of the enclosure 202 configured to support and measure the weight of a fluid. The fluid may be provided in a fluid bag or other receptacle. The sensor 104-1 may be configured to measure the declining weight of the fluid bag as fluid is delivered to the subject. The sensor 104-1 may be further configured to detect when a fluid bag is removed or replaced.

[0050] Figures 3A and Figure 3B show graphs depicting the measurement data collected by the sensors 104 according to one embodiment. In Figure 3A, the y-axis is fluid infusion measured in milliliters, and the x-axis is time. In this example, the sensors 104 include two weight-based sensors supported by an IV pole and configured to weigh respective fluid bags suspended therefrom. The dot-dash line represents measurement data generated by a first weight-based sensor and the dashed line represents measurement data generated by a second weight-based sensor. The first and second sensors record the weight of the respective fluid bags and generate measurement data representing the weight of said fluid bags. The sensor may convert the weight into volumes according to a pre-programmed specific density. In some examples, the sensor 104 receives user inputs indicating the volume and specific density of the fluid. In other examples, the sensor 104 receives user inputs representing a unique identifier used to retrieve the specific density from memory at the sensor. It should be understood that thecomputing device 108 may convert the measurement data from weight to volume using similar methods.

[0051] In Figure 3B, the y-axis is cumulative fluid infusion measured in milliliters, and the x-axis is time. The cumulative fluid infusion is calculated by the computing device 108 which combines the inputs received from two or more sensors 104. Cumulative fluid infusion may be combined with cumulative fluid loss to determine fluid balance.

[0052] Returning now to Figure 1 , the computing device 108 is configured to receive the measurement data from the plurality of sensors 104 and compute a fluid balance based on the measurement data. According to a specific, non-limiting example, the computing device 108 is an operating room data integration system such as the Masimo Root™ System. The computing device 108 is electronically connected to the sensors 104 via a wireless transmitter or wired connection. Suitable examples of a wireless transmitter include a Wi-Fi module, a Bluetooth™ module, radiofrequency identification (RFID) tag, and the like. In specific non-limiting examples, the computing device 108 and sensors 104 communicate via the Esspressif ESP-NOW™ communication which operates over the 2.4 GHz band to enable low-latency, connectionless, and encrypted data transmission between devices. The ESP-NOW™ protocol is a low-cost option that improves battery life and operates even in the absence of a Wi-Fi network. It is simple to set-up and operates on 915 MHz bandwidth, which makes it less susceptible to electromagnetic interference in the operating room environment.

[0053] Responsive to the fluid balance, the computing device 108 controls the infusion pump 112 to control fluid infusion to the subject from one or more intravenous bags. The infusion pump 112 may comprise a compact, portable housing that encloses a motor-driven pumping mechanism — such as a peristaltic roller cassette or a plunger-actuated syringe — fluidly coupled to a replaceable sterile infusion set terminating in a patient catheter or vascular access line. An electronic controller, in communication with a flow sensor or step-count feedback encoder, may regulate the motor to deliver user-selected volumetric flow rates and total infused volumes, while integrated pressure and air-in-line detectors generate occlusion and air-embolism alarms. An output devicemay provide programming and status display, and wired or wireless data interfaces permit communication with the computing device 108 for real-time documentation and remote adjustment of infusion parameters.

[0054] Referring now to Figure 4, a method of perioperative fluid management in accordance with an embodiment is represented as a flowchart and shown generally at 400. In order to assist in the explanation of the method, it will be assumed that method 400 is performed using system 100. Furthermore, the following discussion of method 400 will lead to further understanding of system 100, and / or method 400 can be varied and need not work exactly as discussed herein in conjunction with each other, and that such variations are within the scope of the present specification.

[0055] Block 404 comprises receiving measurement data from a plurality of sensors, the measurement data representing fluid input and output from the subject. In system 100, block 404 is performed by the computing device 108 which receives the measurement data from the plurality of sensors 104. The sensors 104 may transmit the measurement data in response to generating the measurement data, or the sensors 104 may store the measurement data in memory and transmit the accumulated measurement data periodically. The measurement data may comprise a plurality of measurements expressed as an integer associated with a volumetric, weight-based, or flow rate unit. Once received, the measurement data is stored in memory at the computing device 108. Block 404 may be performed on a continual or periodic basis.

[0056] Block 406 comprises computing a fluid balance based on the measurement data. In system 100, block 406 is performed by the computing device 108 which calculates the fluid balance by combining the fluid inputs and outputs measured by the sensors 104. The fluid balance may be indicated as an integer using the same units associated with the measurement data. Generally, the fluid balance represents the difference between all fluid inputs and all fluid outputs, however in some examples, the fluid balance represents the balance for one or more particular fluids or biological components. As part of block 406, the computing device 108 may convert the measurement data into a common unit.

[0057] As a further part of block 406, the computing device 108 may be configured tooutput the fluid balance at a display. The fluid balance may be displayed as an integer associated with a unit of measurement. The fluid balance may be displayed on a graph where fluid balance is represented as a function of time. The fluid balance may be displayed as a colour, symbol, or graph. The fluid balance may be displayed as “very high”, “high”, “normal”, “low”, or “very low”. The computing device 108 may further display the measurement data on the user interface. In addition to the fluid balance, the computing device 108 may output the measurement data at the display. In a specific nonlimiting embodiment, the display shows the fluid balance (mL), total sponge count, total fluid infusion (ml), total urine output (ml), total blood loss (ml), rate of electrolyte infusion (ml / min), projected rate of urine output (ml / hr), rate of blood loss (ml / min), saline balance (ml), electrolyte balance (ml), lactate (ml), dextrose 5% in water (D5W) (ml), albumin (ml), platelet (ml), PBRC (ml), and cell counts (ml). By compiling the measurement data from various sensors onto a centralized display, this step may streamline workflow and support faster decision-making by anesthesiologists and other members of a surgical team.

[0058] Block 416 comprises determining, based on the fluid balance, whether adjustment to the infusion rate is required to maintain or restore a target fluid balance. In system 100, block 416 is performed by the computing device 108. The target fluid balance may be programmed in memory at the computing device 108 or input by the user. In some examples, the target fluid balance is computed at the computing device 108 based on the hemodynamic measures received from the monitoring device. Generally, the target fluid balance reflects the required fluids necessary to maintain the subject’s condition, and particularly to maintain the subject’s cardiac output. As part of block 416, the computing device 108 may receive infusion data from the infusion pump representing the current infusion rate.

[0059] If the fluid balance is above or below the target fluid balance, the computing device 108 may determine that an adjustment to the infusion rate is required. In some examples, the computing device 108 is programmed with the target fluid balance. If the fluid balance meets or exceeds the target fluid balance, the computing device 108 determines that an adjustment to the infusion rate is required. If the fluid balance doesnot meet the target fluid balance, the computing device 108 determines that no adjustment is required. In some examples, the target fluid balance is a range of acceptable values.

[0060] If the computing device 108 determines that no adjustment is required, the method returns to block 404. Thus, the method may be repeated continually or periodically as measurement data is received from the sensors 104. If the computing device 108 determines that adjustment is required, the method advances to block 420.

[0061] Block 420 comprises controlling the infusion pump to adjust the infusion rate. In system 100, block 420 is performed by the computing device 108 which generates a control signal representing an adjusted infusion rate effective to achieve or maintain the target fluid balance. Block 420 is performed in response to the determination at block 416. As part of block 420, the computing device 108 may calculate the adjusted infusion rate effective to achieve or maintain the target fluid balance.

[0062] In response to receiving the control signal, the infusion pump 112 delivers fluids to the subject according to the adjusted infusion rate. In some examples, the control signal includes an instruction for the infusion pump 112 to increase or decrease the infusion rate. In some examples, the control signal causes the infusion pump 112 to display a notification on an output device connected to the computing device or infusion pump, requesting user confirmation, and the infusion pump adopts the adjusted infusion rate in response to receiving user confirmation.

[0063] After controlling the infusion pump 112 at block 420, the method may return to block 404. Thus, the method 400 may be performed periodically or continuously as measurement data is received from the sensors 104. When the method 400 is performed in real-time during the performance of a surgery, the computing device 108 can provide the surgical anesthesia team with near instantaneous updates on the total fluids lost and received by a subject, thus increasing the accuracy and responsiveness of fluids delivered to the subject during surgery.

[0064] Since fluid input and output is not the only variable affecting a subject’s needs,the system 100 may include additional components configured to predict a surgical outcome and adjust the infusion rate accordingly.

[0065] Returning to Figure 1 , the system 100 may further include a monitoring device 114 in communication with the computing device 108. Generally, the monitoring device 114 is configured to generate physiological data representing a measurement of one or more physiological statuses of the subject. The monitoring device 114 transmits the physiological data to the computing device 108 continually or periodically. Suitable examples of physiological data include but are not limited to heart rate, blood pressure, respiratory rate, body temperature, hemodynamic data, and electrocardiography. In examples where the physiological data includes hemodynamic data, the hemodynamic data may include alveolar ventilation, saturation of oxygen in the blood, saturation of carbon dioxide in the blood, oxygen consumption (VO2), carbon dioxide production (VCO2), shunt fraction, dead space, cardiac output, the like, and combinations thereof. A specific, non-limiting example of the monitoring device is the Philips™ Vital Signs Monitor.

[0066] The system 100 may further include an anesthesia device 115 in communication with the computing device 108. The anesthesia device 115 is configured to deliver anesthesia to the subject and generate anesthesia data representing the amount of anesthesia delivered to the subject. The anesthesia device 115 may transmit the anesthesia data to the computing device 108 continually or periodically. Since anesthetic agents can cause vasodilation and myocardial depression, the amount and type of anesthesia may affect the target fluid balance and the subject’s cardiac output.

[0067] The system 100 may further include a network 116 connecting the computing device 108 to a fluid management engine 124. The network 116 may further connect with an electronic health records (EHR) system 120. The network 116 can be wired or wireless, or based on combinations thereof, and based on any type of known network architecture or platform, (e.g. the Internet or a wide area network) or combinations thereof. Generally, network 116 provides an infrastructure to interconnect the fluid management engine 124 and the EHR system 120 to the computing device 108. In some embodiments, the system includes a plurality of computing devices 108 connected to the fluid management engine124 and the EHR system 120 via the network.

[0068] The fluid management engine 124 is shown in greater detail at Figure 5. The fluid management engine 124 is typically a server or mainframe with a housing containing an arrangement of one or more processors 504, volatile memory 520 (i.e. random-access memory), non-volatile memory 516 (i.e. hard disk devices) and a network interface 532 (to allow the fluid management engine 124 to communicate over the network 116) all of which are interconnected by a bus. Programming instructions in the form of applications 524 are typically maintained, persistently, in non-volatile memory 516 and used by the processor 504 which reads from and writes to volatile memory 520 during the execution of applications 524. One or more tables or databases 528 are maintained in non-volatile memory 516 for use by applications 524. The fluid management engine 124 may further include a user interface 508 for receiving inputs and displaying outputs. In some embodiments, the fluid management engine 124 is a virtual server. As explained in detail below, the fluid management engine 124 is configured to receive the fluid balance from the computing device 108 and make predict surgical outcomes accordingly.

[0069] Returning to Figure 1 , the EHR system 120 is generally a server or virtual server configured to store health records in one or more databases. The health records may be stored in association with a unique identifier corresponding to a particular subject. The health records may include but are not limited to demographics, medical history, diagnostic results, medication lists, physician orders, billing data, procedural notes, and combinations thereof. The health records may be associated with time data indicate the date and time associated with the health record. The EHR system 120 may be configured to transmit the health records to the fluid management engine 124. The EHR system 120 may be further configured to generate health records in response to receiving measurement data and physiological data from the computing device 108. In a specific, non-limiting embodiment, the EHR system 120 comprises the EPIC™ EHR platform.

[0070] Referring now to Figure 6, a method of predicting surgical outcomes is shown generally at 600. In order to assist in the explanation of the method, it will be assumed that method 600 is performed using the fluid management engine 124 of system 100.Furthermore, the following discussion of method 600 will lead to further understanding of the fluid management engine 124, and / or method 600 can be varied and need not work exactly as discussed herein in conjunction with each other, and that such variations are within the scope of the present specification. In some examples, method 600 is performed by computing device 108.

[0071] Block 604 comprises receiving the fluid balance from the computing device 108. In fluid management engine 124, block 604 is performed by the network interface 532 which receives the fluid balance via the network 116. Block 604 may be performed in response to the computing device 108 computing the fluid balance at block 406 of method 400. As a further part of block 604, the fluid management engine 124 may receive the measurement data from the computing device 108. As part of block 604, the fluid balance may be stored in the database 528 in association with a unique identifier representing the subject.

[0072] Block 606 comprises receiving physiological data from the monitoring device 114. In the fluid management engine 124, block 606 is performed by the network interface 532 which receives the physiological data via the network 116. Block 606 may be omitted in some examples, including examples where the monitoring device 114 does not transmit physiological data and examples where the system 100 does not include the monitoring device 114. As part of block 516, the physiological data may be stored in the database 528 in association with the unique identifier representing the subject.

[0073] Block 608 comprises receiving a health record from the EHR system 120. In the fluid management engine 124, block 608 is performed by the network interface 532 which receives the health record via the network 116. Block 608 may be omitted in some examples, including examples where the EHR system 120 does not transmit the health record and examples where the system 100 does not include the EHR system 120. As part of block 608, the health record may be stored in the database 528 in association with the unique identifier representing the subject.

[0074] Block 610 comprises retrieving reference data from memory. In the fluid management engine 124, block 610 is performed by the processor 504 which executesinstructions to retrieve reference data from the non-volatile memory 516. The reference data generally represents data related to previously performed surgeries and may include measurement data, fluid balance, physiological data, health records, and surgical outcome data. Specific non-limiting examples of measurement data include medication boluses, infusions, fluid loss, and blood product administration. Specific non-limiting examples of surgical outcome data include both pre-operative and post-operative data such as acute kidney injury (AKI), time spent in the intensive care unit (ICU), graft failure, delirium, blood biomarkers, hemodynamic data, discharge time, 30-day mortality rate, transfusion rate, the like, and combinations thereof. The reference data may be collected from the user interface 508, the EHR system 120, the monitoring device 114, the computing device 108, or combinations thereof. From time to time, the EHR system 120 may be updated with confirmatory data representing a surgical outcome for a particular subject.

[0075] Block 616 comprises generating an alert representing a predicted surgical outcome based on a comparison of the fluid balance to the reference data. If the physiological data was received at block 606, the comparison may be based on the physiological data. If the health record was received at block 608, the comparison may be based on the health record. In some examples, the alert includes an adjusted infusion rate. In other examples, the alert represents an adjusted target fluid balance.

[0076] In the fluid management engine 124, block 616 is performed by the processor 504 which compares the fluid balance to the reference data retrieved from memory. The comparison may be based on an artificial intelligence or machine learning model which is trained on the reference data to predict surgical outcomes. Any suitable artificial intelligence or machine learning model may be used including a deep learning model, Transformer Neural Network, Times-Series Transformer, Recurrent Neural Network (RNN), Long Short-Term Memory (LSTM) network, Gated Recurrent Unit (GRU) network, and combinations thereof.

[0077] Block 620 comprises transmitting the alert. In the fluid management engine 124, block 620 is performed by the network interface 532 which transmits the alert to thecomputing device 108 via the network 116. In response to receiving the alert at block 620, the computing device 108 may perform block 416. Based on the alert and the fluid balance, the computing device 108 determines whether or not to adjust the infusion rate.

[0078] In view of the above, it will now be apparent that variants, combinations, and subsets of the foregoing embodiments are contemplated. For example, while the computing device 108, infusion pump 112, monitoring device 114, and anesthesia device 115 are described as separate computing devices with respective displays, it should be understood that the functionality of these devices may be combined into one device or machine. In another example, the computing device 108 receives measurement data for a plurality of different fluids and calculates the fluid balance for each fluid. In a further example, the subject receives more than one type of fluid through the infusion pump, and the computing device 108 controls the infusion rate for each fluid.

[0079] It will now be apparent to a person of skill in the art that the present specification affords certain advantages over the prior art. Firstly, the sensors which collect measurement data from a variety of fluid sources allow the computing device 108 to compute accurate and real-time calculations of the subject’s net fluid loss, leading to improved patient outcomes. Secondly, the computing device 108 communicates directly with the EHR system 120, seamlessly compiling data collected from patient monitoring machines, infusion pumps, anesthesia devices, and sensors. This system eliminates manual inputs and potential data discrepancies. Thirdly, displaying the fluid balance and measurement data on a centralized display in real-time reduces cognitive load, and enables timely decision-making by anesthesiologists. Fourthly, the predictive alerts generated at the fluid management engine can optimize fluid management, ultimately improving patient safety and surgical outcomes. Lastly, the reference data collected at the fluid management engine can be used for virtual simulations of surgeries to train anesthesiologists and residents.

[0080] The many features and advantages of the invention are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the invention that fall within the true spirit and scope of theinvention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.

Claims

CLAIMSWhat is claimed is:1 . A system for perioperative fluid management comprising: a plurality of sensors configured to generate measurement data representing fluid input and output from a subject; a monitoring device configured to generate hemodynamic data representing the subject’s cardiac output; a computing device connected to the plurality of sensors and configured to: compute a fluid balance according to the measurement data received from the plurality of sensors; determine, based on the fluid balance and the hemodynamic data, whether adjustment to the infusion rate is required to achieve or maintain the subject’s cardiac output; and if adjustment to the infusion rate is required, generate a control signal representing an adjusted infusion rate effective to achieve or maintain the subject’s cardiac output; and an infusion pump connected to the computing device and configured to: receive the control signal; and deliver fluids to the subject according to the adjusted infusion rate.

2. The system of claim 1 wherein the plurality of sensors includes two or more of: an intravenous sensor connected to a fluid bag and configured to measure fluid infusion to the subject from the fluid bag; an irrigation sensor connected to an irrigation apparatus and configured to measure fluids delivered to the subject by the irrigation apparatus. a suction sensor connected to a storage cannister of a suction apparatus andconfigured to measure fluids collected from the subject by the suction apparatus; a sponge counter configured measure a weight of a surgical sponge before and after use; a urine sensor connected to a catheter and configured to measure urine obtained from the subject via the catheter; and a blood flow sensor connected to an intraoperative blood salvage device and configured to measure blood delivered to the subject by the intraoperative blood salvage device.

3. The system of claim 1 or 2 wherein the plurality of sensors includes a flow sensor selected from a group consisting of a turbine sensor, a vortex sensor, a magmeter, an ultrasonic sensor, a positive displacement flow sensor, and a thermal mass flow sensor.

4. The system according to any one of claims 1 to 3 wherein the plurality of sensors includes a volume sensor selected from a group consisting of an ultrasonic sensor, a capacitive volume sensor, a weight-based sensor, an optical sensor, a float sensor, a hydrostatic pressure sensor, and a radar volume sensor.

5. The system according to any one of claims 1 to 4 wherein the computing device is further configured to: receive further measurement data from the plurality of sensors; determine, based on the further measurement data, whether further adjustment to the infusion rate is required to achieve or maintain the subject’s cardiac output; and if further adjustment to the infusion rate is required, regenerate the control signal to represent a further adjusted infusion rate.

6. The system according to any one of claims 1 to 5 wherein the computing device further includes a display, and the computing device is configured to output the fluid balance at the display.

7. The system according to any one of claims 1 to 6 further comprising a fluid management engine connected to the computing device via a network, the fluid management engine configured to: receive the fluid balance and the hemodynamic data from the computing device; retrieve reference data from memory at the fluid management engine; generate an alert representing a predicted surgical outcome based on a comparison of the fluid balance and the hemodynamic data to the reference data; and transmit the alert to the computing device; wherein computing device is configured to generate the control signal responsive to receiving the alert.

8. The system of claim 7 wherein the hemodynamic data represents one or more of: alveolar ventilation, saturation of oxygen in the blood, saturation of carbon dioxide in the blood, oxygen consumption (VO2), carbon dioxide production (VCO2), shunt fraction, dead space, and cardiac output.

9. The system of claim 7 or 8 wherein the fluid management engine is further configured to: receive health records associated with the subject from an electronic health records system via the network; and generate the alert according to the health records.

10. A system for perioperative fluid management comprising: a plurality of sensors configured to generate measurement data representing fluidinput and output from a subject; a computing device connected to the plurality of sensors and configured to: compute a fluid balance according to the measurement data received from the plurality of sensors; determine, based on the fluid balance, whether adjustment to the infusion rate is required to achieve or maintain a target fluid balance; and if adjustment to the infusion rate is required, generate a control signal representing an adjusted infusion rate effective to achieve or maintain a target fluid balance; and an infusion pump connected to the computing device and configured to: receive the control signal; and deliver fluids to the subject according to the adjusted infusion rate.11 . The system of claim 10 wherein the plurality of sensors includes two or more of: an intravenous sensor connected to a fluid bag and configured to measure fluid infusion to the subject from the fluid bag; an irrigation sensor connected to an irrigation apparatus and configured to measure fluids delivered to the subject by the irrigation apparatus. a suction sensor connected to a storage cannister of a suction apparatus and configured to measure fluids collected from the subject by the suction apparatus; a sponge counter configured measure a weight of a surgical sponge before and after use; a urine sensor connected to a catheter and configured to measure urine obtained from the subject via the catheter; anda blood flow sensor connected to an intraoperative blood salvage device and configured to measure blood delivered to the subject by the intraoperative blood salvage device.

12. The system of claim 10 or 11 wherein the plurality of sensors includes a flow sensor selected from a group consisting of a turbine sensor, a vortex sensor, a magmeter, an ultrasonic sensor, a positive displacement flow sensor, and a thermal mass flow sensor.

13. The system according to any one of claims 10 to 12 wherein the plurality of sensors includes a volume sensor selected from a group consisting of an ultrasonic sensor, a capacitive volume sensor, a weight-based sensor, an optical sensor, a float sensor, a hydrostatic pressure sensor, and a radar volume sensor.

14. The system according to any one of claims 10 to 13 wherein the computing device is further configured to: receive further measurement data from the plurality of sensors; determine, based on the further measurement data, whether further adjustment to the infusion rate is required to achieve or maintain the target fluid balance; and if further adjustment to the infusion rate is required, regenerate the control signal to represent a further adjusted infusion rate.

15. The system according to any one of claims 10 to 14 wherein the computing device further includes a display, and the computing device is configured to output the fluid balance at the display.

16. The system according to any one of claims 10 to 15 further comprising a fluid management engine connected to the computing device via a network, the fluid management engine configured to: receive the fluid balance from the computing device; retrieve reference data from memory at the fluid management engine;generate an alert representing a predicted surgical outcome based on a comparison of the fluid balance to the reference data; and transmit the alert to the computing device; wherein computing device is configured to generate the control signal responsive to receiving the alert.

17. The system of claim 16 further comprising a monitoring device configured to: generate physiological data representing a measurement of one or more physiological statues of the subject; and transmit the physiological data to the fluid management engine; wherein the fluid management engine is further configured to generate the alert according to the physiological data.

18. The system of claim 17 wherein the physiological data represents one or more of: heart rate, blood pressure, respiratory rate, blood oxygenation, blood carbon dioxide, body temperature, and electrocardiography.

19. The system of claim 17 or 18 wherein the fluid management engine is further configured to: receive health records associated with the subject from an electronic health records system via the network; and generate the alert according to the health records.

20. A method of perioperative fluid management comprising: receiving at a computing device, measurement data generated by a plurality of sensors, the measurement data representing fluid input and output from a subject; computing at the computing device, a fluid balance according to the measurement data;determining at the computing device, whether adjustment to the infusion rate is required to achieve or maintain a target fluid balance; if adjustment to the infusion rate is required, generating at the computing device a control signal representing the adjusted infusion rate; and transmitting the control signal to an infusion pump connected to the computing device, the infusion pump configured to deliver fluids to the subject at the adjusted infusion rate in response to the control signal.21 . The method of claim 20 further comprising: receiving at the computing device further measurement data from the plurality of sensors; determining at the computing device whether further adjustment to the fusion rate is required to maintain or restore the fluid balance, based on the further measurement data; and if further adjustment to the infusion rate is required, regenerating the control signal to represent the further adjusted infusion rate.

22. The method of claim 20 or 21 further comprising: outputting the fluid balance at a display connected to the computing device.

23. The method according to any one of claims 20 to 22 further comprising: transmitting the fluid balance from the computing device to a fluid management engine; retrieving reference data stored in memory at the fluid management engine; generating an alert representing a predicted surgical outcome based on a comparison of the fluid balance to the reference data; and transmit the alert from the fluid management engine to the computing device; wherein the control signal is further generated based on the alert.

24. The method of claim 23 further comprising: generating physiological data at a monitoring device connected to the computing device, the physiological data representing a measurement of one or more physiological statuses of the subject; and transmitting the physiological data to the fluid management engine; wherein the alert is further generated according to the physiological data.

25. The method of claim 24 further comprising receiving health records at the fluid management engine from an electronic health records system, the health records associated with the subject; wherein the alert is further generated according to the health records.

26. A system for perioperative fluid management comprising: a plurality of sensors configured to generate measurement data representing fluid input and output from a subject; a monitoring device configured to generate hemodynamic data representing the subject’s cardiac output; a computing device connected to the plurality of sensors and configured to: compute a fluid balance according to the measurement data received from the plurality of sensors; determine, based on the fluid balance, whether adjustment to the infusion rate is required to achieve or maintain the subject’s cardiac output; and if adjustment to the infusion rate is required, generate a control signal representing an adjusted infusion rate effective to achieve or maintain the subject’s cardiac output; a fluid management engine connected to the computing device via a network, the fluid management engine configured to: receive the fluid balance and the subject’s cardiac output from thecomputing device; retrieve reference data from memory at the fluid management engine; generate an alert representing a predicted surgical outcome based on a comparison of the fluid balance and the subject’s cardiac output to the reference data; and transmit the alert to the computing device, wherein computing device is configured to generate the control signal responsive to receiving the alert; and an infusion pump connected to the computing device configured to: receive the control signal; and deliver fluids to the subject according to the adjusted infusion rate.

Images