System and method for managing patient hydrogen

Abstract

A method of managing hydration of a patient is provided. The method includes receiving a fluid delivery request including a first programmed amount of a first fluid to be provided by a first medical device. Further, the method includes identifying a second programmed amount of a second fluid provided by or to be provided by the second medical device. Further, the method includes determining that medical device operation should be adjusted based on the first programmed amount and the second programmed amount. Finally, the method includes adjusting medical device operation in response to the determination and based on the fluid delivery request and the first programmed amount and the second programmed amount.

Description

Background Technology

[0001] Fluid overload (also known as hypervolemia) occurs when there is too much fluid in a person's body. It can cause cramps, headaches, abdominal distension, high blood pressure, and even heart failure. This is a common problem in intravenous therapy, especially when someone is receiving fluids from multiple sources (e.g., multiple infusion pumps). When someone is receiving fluids from multiple sources, and especially when these sources are providing fluids at different rates and at different times, it becomes increasingly difficult for healthcare professionals (e.g., nurses, operators, etc.) to keep track of everything. Therefore, there is a significant risk of fluid overload during intravenous therapy. On the other hand, insufficient fluid intake can lead to dehydration. Busy clinical settings, staff shortages, and similar situations make it increasingly difficult to monitor when fluid sources are depleted, and thus, appropriate fluid intake may be overlooked. Dehydration due to lack of fluid intake can cause cramps, headaches, dizziness, and low blood pressure, and in critical situations, can destabilize the patient. Therefore, it is also important to avoid fluid deprivation during intravenous therapy.

[0002] Therefore, it is necessary to effectively monitor and manage patients' hydration levels, especially for those receiving intravenous therapy. Summary of the Invention

[0003] According to various aspects of the subject matter, a method for managing patient hydration includes receiving a fluid delivery request, the fluid delivery request including a first programmed amount of first fluid to be provided by a first medical device; identifying a second programmed amount of second fluid to be provided by or to be provided by a second medical device; determining, based on the first programmed amount and the second programmed amount, that the operation of the medical device should be adjusted; and, in response to the determination, adjusting the operation of the medical device based on the fluid delivery request and the first programmed amount and the second programmed amount.

[0004] According to various aspects of the subject matter, a system includes a first medical device, a second medical device, and an electronic device, the electronic device including one or more processors and a memory storing one or more programs, the one or more programs including instructions that, when executed by the one or more processors, cause the electronic device to perform the methods described in this section.

[0005] According to various aspects of the subject matter, a non-transient computer-readable storage medium stores one or more programs including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform the methods described in this section.

[0006] It will be understood that other configurations of the present subject matter will become apparent to those skilled in the art from the following detailed description, wherein various configurations of the present subject matter are illustrated and described by way of illustration. As will be appreciated, the present subject matter is capable of other and different configurations, and several details thereof can be modified in various other ways, all without departing from the scope of the present subject matter. Therefore, the accompanying drawings and detailed description should be regarded as illustrative in nature and not as limiting. Attached Figure Description

[0007] To better understand the various embodiments described, reference should be made to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings and description, similar reference numerals denote corresponding parts.

[0008] Figure 1 Example infusion devices based on various aspects of the technology in this subject are described.

[0009] Figure 2 Example user interfaces are depicted based on various aspects of the technology in this subject.

[0010] Figure 3 A first example process for managing patient hydration is described based on various aspects of the technology in this subject matter.

[0011] Figure 4 A second example procedure for managing patient hydration is described, based on various aspects of the techniques in this subject matter.

[0012] Figure 5 A conceptual diagram of an example electronic system for managing patient hydration, based on various aspects of the technology in this subject matter, is depicted. Detailed Implementation

[0013] Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following description to provide an understanding of the various embodiments described. However, it will be apparent to those skilled in the art that the various described embodiments can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0014] A hydration management system can acquire data from medical devices (e.g., infusion pumps, smart drips, dialysis machines, catheter systems, fluid monitoring systems, dedicated patient monitoring devices, etc.) to determine a patient's current and projected hydration levels. The system can monitor patient hydration to ensure, for example, that the patient's hydration level never falls below or rises above unsafe limits. The system can also receive fluid administration requests and respond to said requests based on the aforementioned hydration levels. For example, if a patient is at risk of fluid overload, the system can reject the request, modify the request, or adjust the operation of medical devices already administering fluids to the patient.

[0015] Figure 1 An example infusion device 100 (e.g., an infusion pump) according to various aspects of the subject matter is depicted, shown for use in its intended environment. Specifically, the infusion device 100 is shown mounted on an intravenous infusion (IV) stent 112, on which a fluid source 114 containing fluid is mounted. The fluid source 114 is fluidly connected to an upstream portion 116 of a fluid infusion line 121. The fluid infusion line 121 is a conventional IV infusion type tubing commonly used in hospital or medical settings and is made of any type of flexible tubing suitable for infusing therapeutic fluids into a patient, such as silicone. A flexible portion 118 of the fluid infusion line 121 is mounted to operatively engage with a peristaltic pumping mechanism 119 for propelling fluid through a downstream portion 120 of the fluid infusion line 121 into, for example, a patient's arm 122.

[0016] It should be understood that the upstream portion 116, the flexible portion 118, and the downstream portion 120 of the fluid infusion line 121 may be portions of the same continuous flexible tube, wherein these portions are defined by their position relative to the peristaltic pump mechanism 119. For convenience, the continuous length of the flexible tube is referred to herein as the fluid infusion line 121. A roller clamp 123 (e.g., configured to provide mechanical compression of the tube to impede flow) may be positioned on the downstream portion 120 of the fluid infusion line 121 between the infusion device 100 and the patient's arm 122. In this context, the term "upstream" refers to the portion of the flexible tube extending between the fluid source 114 and the peristaltic pump mechanism 119, and the term "downstream" refers to the portion of the flexible tube extending from the peristaltic pump mechanism 119 to the patient's arm 122.

[0017] It should also be understood that multiple medical devices (e.g., in addition to infusion device 100) can simultaneously administer fluid to the same patient (e.g., to the patient's arm 122). In some embodiments, multiple medical devices (such as infusion device 100) administer fluid to the patient simultaneously. For example, in some embodiments, the patient receives fluid from multiple different infusion devices (such as infusion device 100). As another example, in some embodiments, the patient receives fluid from a smart dropper, a dialysis machine, and / or a feeding tube.

[0018] Figure 2 An example user interface 200 according to various aspects of the art of this subject is depicted. According to various embodiments, the user interface 200 is displayed by an infusion device, such as... Figure 1 The infusion device 100. In some embodiments, the user interface 200 is displayed on a computing device (e.g., a computer, smartphone, tablet, etc.) or on a device associated with the dispensing device (e.g., a medication dispenser). In such embodiments, the user interface may be operatively connected to the infusion device 100 via an electronic network of the healthcare organization.

[0019] like Figure 2 As depicted, in some embodiments, the user interface 200 includes a header 201, a refresh button 202, a logout button 203, and device information 204. Although not specifically shown, the header 201 may identify the device displaying the user interface 200, or one or more devices (e.g., infusion device 100) to which the user interface 200 is operatively connected. The refresh button 202 may allow a user (e.g., a healthcare professional, operator, etc.) to manually refresh the user interface 200 and / or cause the system to retrieve (and display) updated data from the connected device (e.g., one or more infusion devices 100). The logout button 203 may allow the current user to log out of the account associated with the user interface 200 and / or one or more operatively connected devices. For example, in some embodiments, the user interface 200 displays patient information (e.g., patient hydration, etc.) that can be protected by requiring the user to log in to access it. After using the device, the user can log out via the logout button 203 to protect the information. The device information 204 may also include information identifying the physician currently logged into the device (e.g., “Pat Smith”). The device information 204 may also include information about the care area that the device displaying the user interface 200 is using (e.g., “NICU-4West”).

[0020] As in the illustrated example, user interface 200 includes patient information dashboards 210, 220, 230, 240, and 250 for the respective patient. In some embodiments, the patient information dashboards may be displayed in an expanded view, such as alongside patient information dashboard 210. In some embodiments, the patient information dashboards may be displayed in a collapsed view, such as alongside patient information dashboards 220, 230, 240, and 250. In some embodiments, an expand button allows the user to expand or collapse the patient information dashboards. For example, patient information dashboard 250 is displayed in... Figure 2 The patient information dashboard 250 is depicted as being displayed in a collapsed view. The patient information dashboard 250 includes an expand button 255, which, when selected, causes the patient information dashboard 250 to be displayed in an expanded view.

[0021] According to various embodiments, patient information dashboards 210, 220, 230, 240, and 250 are optional for further expansion or reporting purposes. For example, dashboard 210 is displayed in an expanded state. As will be further described, each dashboard (whether expanded or not) may include a hydration status indicator (e.g., hydration status indicator 211, 241, or 251). The hydration status indicator indicates whether a patient is at risk of fluid overload or fluid deprivation. For example, hydration status indicator 211 of patient information dashboard 210 may indicate that a patient associated with patient information dashboard 210 is at risk of fluid overload. In some embodiments, the hydration status indicator indicates that a patient is at risk of dehydration. For example, in the depicted example, hydration status indicator 241 of patient information dashboard 240 indicates that a patient associated with patient information dashboard 240 is at risk of dehydration. In some embodiments, the hydration status indicator indicates that a patient is neither at risk of fluid overload nor dehydration (i.e., the patient is properly hydrated). For example, the hydration status indicator 251 of the patient information dashboard 250 indicates that the patient associated with the patient information dashboard 250 is properly hydrated.

[0022] Each patient information dashboard 210, 220, 230, 240, and 250 includes a patient name 212 (e.g., “Chris Jones”) associated with the patient whose data is displayed by the dashboard. For example, patient information dashboard 250 includes a patient name 252 (i.e., “BP Brooklyn”).

[0023] In some implementations, the patient information dashboard includes a patient hydration graph (e.g., patient hydration graph 213). In the depicted example, the patient hydration graph is a graph with an x-axis and a y-axis. For example, patient hydration graph 213 has an x-axis corresponding to time (e.g., measured in minutes, hours, etc.) and a y-axis corresponding to fluid volume (e.g., measured in liters). Other implementations may include different types of graphs, such as bar charts, pie charts, and similar graphs.

[0024] In some embodiments, the patient hydration profile 213 includes one or more threshold indicators 214 and 215. In some embodiments, the threshold indicators indicate fluid delivery thresholds. For example, the depicted threshold indicator 214 may indicate a minimum fluid delivery threshold representing the patient's risk of dehydration. For example, the threshold may indicate the hydration level at which the patient is at risk of dehydration. The threshold indicator 214 may alternatively indicate a threshold representing fluid overload or hyperhydration.

[0025] In some embodiments, the patient hydration curve 213 includes a variable threshold. For example, the depicted dashed threshold indicator 215 may represent a dynamically estimated patient hydration threshold based on patient physiological parameters (e.g., weight, BMI, sex, age, hydration level, dehydration level, urine test results (e.g., volume, pH level, analyte content (such as salt), etc.), breathalyzer test, or other patient measurements). Parameters may be received from sensors, from patient medical records, or derived from information received from these sources. Using one or more of the parameters, a hydration level analysis process may be selected, and a dynamic threshold may be generated based on processing one or more of the parameters using a hydration level analysis method. While the hydration threshold 215 is depicted as dynamic, in some embodiments, the threshold 215 may be static.

[0026] The patient hydration curve 213 includes a time-varying waveform 216 (e.g., measured via a urine sample) indicating the patient's current hydration level. This waveform 216 (and / or dynamic threshold 215) can be updated over time as data is collected by the system. In the case where the threshold indicator 215 represents a maximum fluid delivery threshold indicating the risk of fluid overload, the designated patient (i.e., "Chris Jones") may currently be at risk of fluid overload because his current hydration level is above the maximum fluid delivery threshold 215. Therefore, the hydration status indicator 211 can indicate that the patient is currently at risk of fluid overload.

[0027] According to various embodiments, patient information 216, including the patient's age and / or weight, is also displayed. In the depicted example, the information includes current volumes associated with the patient (e.g., current fluid volume in the patient's body, current fluid volume administered to the patient over a specific time period, etc.), average volumes associated with the patient (e.g., average fluid volume provided to the patient over a specific time period, etc.), current minimum fluid volume associated with a time amount (e.g., "hourly") (e.g., minimum fluid delivery threshold), and current maximum fluid volume associated with a time amount (e.g., "hourly") (e.g., maximum fluid delivery threshold). In the depicted example, the patient information dashboard 210 also includes an update button 217 that allows the user to update either the minimum threshold 214 or the maximum threshold 216. Thresholds entered by the user can override dynamic thresholds. For example, if the patient's medical condition (e.g., the patient has diabetes, the patient is receiving chemotherapy, etc.) increases the importance of ensuring the patient does not become dehydrated and / or overloaded, the user can adjust the minimum or maximum amount of fluid (e.g., increase the minimum fluid delivery threshold, decrease the maximum fluid delivery threshold, etc.) to take the patient's medical condition into account.

[0028] In some implementations, when the patient information dashboard is displayed in an expanded view, the patient hydration curve 213, patient information 216, and update button are visible 217 (e.g., they are not visible when the patient information dashboard is displayed in a collapsed view). For example, when the patient information dashboard 210 is displayed in an expanded view, the patient hydration curve 213, patient information 216, and update button 217 of the patient information dashboard 210 are visible. In contrast, when the patient information dashboard 250 is displayed in a collapsed view, the corresponding patient hydration curve, patient information, and update button associated with the patient information dashboard 250 are not visible.

[0029] In some implementations, when the patient information dashboard is displayed in a collapsed view, the hydration status indicator, the patient's name, a portion of the patient information, and the expand button (e.g., expand button 255) are visible (e.g., they are visible regardless of whether the patient information dashboard is displayed in an expanded or collapsed view). For example, the patient information dashboard 250 is displayed in a collapsed view, and the hydration status indicator 251, the patient's name 252, the current volume 253 (e.g., the current fluid volume in the patient's body, the current fluid volume administered to the patient within a specific time period, etc.), the maximum and minimum fluid volumes 254 (e.g., the minimum fluid delivery threshold, the maximum fluid delivery threshold, etc.), and the expand button 255 of the patient information dashboard 250 are all visible.

[0030] Figure 3A first example process 300 for managing patient hydration, based on various aspects of the technology described herein, is presented. One or more blocks of process 300 may be implemented, for example, by one or more computing devices, such as… Figure 1 Infusion equipment 100 or Figure 5 One or more processing units 512. In some embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be implemented separately from other blocks and implemented by one or more different processors or devices. Furthermore, for illustrative purposes, the blocks of example process 300 are described as occurring serially or linearly. However, multiple blocks of example process 300 may occur in parallel. Moreover, the blocks of example process 300 do not need to be executed in the order shown, and one or more blocks in example process 300 do not need to be executed.

[0031] like Figure 3 As depicted, process 300 may include receiving (301) a fluid delivery request comprising a first programmed amount of fluid to be provided by a first medical device. The amount of fluid may represent the amount of fluid to be administered per unit time (e.g., 1051 ml per hour), or may identify the amount of fluid already administered or administered within a predetermined previous time window (e.g., during the last 30 or 60 minutes). The request may originate from an infusion pump, which is a result of a clinician programming the pump to initiate fluid infusion. In some embodiments, the first medical device may be an automated dispensing machine (ADM), and the request may be a request to dispense the first fluid (e.g., in the first programmed amount) from the ADM. According to various examples herein, the request may be received electronically by a system responsible for implementing process 300. For example, a computing device (e.g., a server) may be operatively connected via a network to the disclosed first and second medical devices, receive the fluid delivery request and other programmed amounts from these devices, and determine whether one or more of the medical devices should be adjusted as described herein.

[0032] In some embodiments, upon receiving the (301) fluid delivery request, the first medical device is already providing or has provided (e.g., if dispensed by an ADM) a first fluid. In some embodiments, the fluid delivery request also includes a medication order for delivery of a drug to a patient by the first medical device. For example, a pharmacist may receive this order at a pharmacy system terminal in a healthcare organization. The first programmed quantity may include, for example, the volume of the first fluid (e.g., measured in milliliters) and / or the amount of the drug (e.g., 400 mg of dopamine). In some embodiments, the first and / or second fluids include intravenous infusion fluids (e.g., saline solution, Ringer's solution, etc.). In some embodiments, the first and / or second fluids include drugs (e.g., vancomycin, hydromorphone, etc.).

[0033] In some embodiments, the first medical device includes a first infusion pump configured to deliver a first programmed amount of first fluid over a first programmed time period. In some embodiments, adjusting the operation of the medical device includes adjusting the first programmed time period. For example, the first infusion pump may be configured to deliver the first programmed amount of first fluid over a sixty-minute time period. However, the first programmed time period can be adjusted by increasing it from sixty minutes to ninety minutes (e.g., by delaying further administration of the first fluid by thirty minutes, or by reducing the rate at which the first fluid is delivered).

[0034] like Figure 3 The described process 300 may include identifying (302) a second programmed amount of fluid provided or to be provided by a second medical device. For example, the system may be connected via an electronic network of a healthcare organization (e.g., via...). Figure 5 One or more network interfaces 516) communicate with the second medical device (e.g., via Wi-Fi, Bluetooth, etc.). In some embodiments, identifying (302) the second programming quantity includes receiving the second programming quantity from the second medical device. In some embodiments, identifying (302) the second programming quantity includes a database (such as...) Figure 5 The system retrieves the volume of fluid injected or to be injected by the device from its memory (502). For example, a second programmed quantity can be received from an electronic medical record (EMR) system, which is reported to the EMR system by the medical device or an associated clinician.

[0035] In some embodiments, the second medical device has already provided a second programmed amount of second fluid, or some of a second programmed amount of second liquid, and is programmed to continue providing the second fluid until the second medical device has provided all of the second fluid. In other embodiments, the second medical device has not yet provided any second fluid, but is designated or programmed to provide a second programmed amount of second fluid at a future point in time.

[0036] In some embodiments, the second programmed quantity includes the volume of the second fluid (e.g., measured in milliliters). In some embodiments, the second programmed quantity includes the amount of a drug (e.g., 400 mg of dopamine). In some embodiments, the second fluid includes an intravenous infusion fluid (e.g., saline solution, Ringer's solution, etc.). In some embodiments, the second fluid includes a drug (e.g., vancomycin, hydromorphone, etc.).

[0037] In some embodiments, the second medical device includes a second infusion pump configured to deliver a second programmed amount of second fluid over a second programmed time period. In some embodiments, adjusting the operation of the medical device includes adjusting the second programmed time period. For example, the second infusion pump may be configured to deliver a second programmed amount of second fluid over a 45-minute time period. However, the second programmed time period can be adjusted by reducing it from 45 minutes to 30 minutes (e.g., by increasing the rate at which the second fluid is delivered).

[0038] Example process 300 includes determining (303) whether the medical device operation should be adjusted. As will be further described, the medical operation to be adjusted may include, for example, adjusting the volume of fluid administered to or programmed by the infusion device 100 to the patient per unit time. The medical device operation may include an alarm mechanism by which the adjustment includes displaying an alarm. In the case of ADM, the medical device operation may be the dispensing of a drug or fluid, and the determination (303) may include determining whether the dispensing should be permitted or prevented, or whether the amount dispensed should be increased or decreased.

[0039] According to various implementations, the determination (303) made by the system is based on a first programmed amount and a second programmed amount. For example, the system may determine that the sum of the first programmed amount and the second programmed amount satisfies a fluid delivery threshold (see, for example...). Figure 2 The threshold indicator 214) determines that the operation of the medical device should be adjusted. In some embodiments, the sum of the first programmed amount and the second programmed amount meeting the fluid delivery threshold means that the two fluids together pose a risk of fluid overload (e.g., the patient will soon be fluid overloaded). In some embodiments, the sum of the first programmed amount and the second programmed amount meeting the fluid delivery threshold means that the two fluids together are insufficient to eliminate the risk of dehydration (e.g., the patient is already dehydrated).

[0040] According to some implementations, medical device operation includes instructing the sum of a determined first programmed amount and a second programmed amount to satisfy a fluid delivery threshold (e.g., Figure 2 Alarms with thresholds 214 and 215. For example, alarms can be triggered on the user interface of the first or second medical device (e.g., Figure 2 The user interface 200), the ADM responsible for dispensing the first or second fluid, the total fluid monitoring device, or the system responsible for managing the patient's electronic medical records are provided. In some implementations, the alarm is indicated (e.g., Figure 2The hydration status indicator (211, 241, or 251) includes the amount of time the patient will subsequently experience fluid overload or dehydration (e.g., a countdown timer), which can also be indicated in the graph 213. In some embodiments, an alert indicating a risk of dehydration is provided regardless of whether a fluid request is received. For example, in some embodiments, the hydration level is determined intermittently, and an alert is generated whenever the hydration level meets a fluid delivery threshold.

[0041] In some implementations, process 300 further includes estimating the patient's water loss relative to the patient's weight, height, sex, disease state, body temperature, or body surface area. In such implementations, the fluid delivery threshold may be based on a threshold of water loss before the risk to the patient becomes significant. The patient's water loss may be related to the rate at which fluids are delivered to the patient. For example, if the patient's water loss is low (e.g., if the patient has anhidrosis), the amount of fluid that can be safely delivered to the patient may be reduced. As another example, if the patient's water loss is high (e.g., if the patient is overweight), the amount of fluid that can be safely delivered to the patient may be increased. In fact, the amount of fluid that must be delivered to the patient to avoid dehydration may also be increased.

[0042] In some implementations, determining whether medical device operation should be adjusted includes determining the patient's hydration. For example, the patient's hydration can be determined based on measurements from a fluid monitoring system, such as the fluid container monitoring system shown and described in U.S. Patent No. 9,995,619, entitled "Fluid Container Measurement System Employing Load Cell Linkage Member," the entire contents of which are incorporated herein by reference. For example, a catheter-based fluid container monitoring system can measure a patient's urine output and periodically update the system with such measurement information. The system can communicate directly with the fluid monitoring system (e.g., "paired") or indirectly with it via a network or an intermediate medical information system (such as an electronic health record system). For example, using the patient's identifier, the system can retrieve information about the patient from an electronic health record system.

[0043] like Figure 3As depicted, process 300 continues by adjusting the operation of the medical device in response to a determination (304) based on a fluid delivery request and a first programmed amount and a second programmed amount. In some embodiments, adjusting the operation of the medical device includes delaying the fluid delivery request. For example, upon receiving a request to initiate fluid administration, infusion device 100 may prevent such administration until a clinician acknowledges the alarm and confirms administration and / or until a second clinician acknowledges and confirms administration. In some embodiments, adjusting the operation of the medical device includes rejecting the fluid delivery request. For example, if the first medical device is a drug dispensing machine, the dispensing machine may refuse to dispense the first fluid. In some embodiments, the dispensing machine may also notify the user of the risks to the patient (e.g., the risk of fluid overload).

[0044] In some embodiments, adjusting the operation of the medical device includes adjusting a first programmed volume. In some embodiments, adjusting the operation of the medical device includes adjusting a second programmed volume. In some embodiments, adjusting the operation of the medical device includes the first or second medical device (e.g., infusion device 100) adjusting the dilution of the first fluid during fluid administration. In some embodiments, adjusting the operation of the medical device includes adjusting the dilution of the second fluid. In some embodiments, adjusting the medical device includes recommending adjustments to the operation of the medical device to the user via a display associated with the device. For example, in some embodiments, the user is advised to reduce the dilution of the second fluid because otherwise the patient would be at risk of fluid overload. As another example, in some embodiments, the user is advised to mix the first and second fluids (e.g., at a specific dilution rate, a specific mixing rate, etc.) and provide both fluids together in a single administration. As yet another example, in some embodiments, the user is advised to reduce either the first or second volume of the first or second fluid, respectively.

[0045] Figure 4 A second example process 400 for managing patient hydration according to various aspects of the subject matter is described. According to various embodiments, process 400 operates similarly to process 300 and / or can replace or enhance process 300. One or more blocks of process 400 may be implemented, for example, by one or more computing devices, including, for example... Figure 1 Infusion equipment 10 or Figure 5One or more processing units 512. In some embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be implemented separately from other blocks and implemented by one or more different processors or devices. Furthermore, for illustrative purposes, the blocks of example process 400 are described as occurring serially or linearly. However, multiple blocks of example process 400 may occur in parallel. Moreover, the blocks of example process 400 do not need to be executed in the order shown, and one or more blocks in example process 400 do not need to be executed.

[0046] like Figure 4 As depicted, in some embodiments, process 400 includes receiving (301) a fluid delivery request including a first programmed amount of first fluid to be provided by a first medical device, identifying (302) a second programmed amount of second fluid to be provided by or to be provided by a second medical device, and determining (303) whether the operation of the medical devices should be adjusted. For variations of these steps in process 400, see the discussion of process 300 above.

[0047] In the depicted example, process 400 includes determining (401) whether a first treatment has a higher priority than a second treatment. Adjustments may be made to accommodate the priority, depending on the priority of the corresponding drug delivery request. For example, a patient may receive multiple treatments in short durations (e.g., simultaneously). The patient may receive a first treatment comprising receiving a first amount of a first fluid from a first medical device. The patient may also receive a second treatment comprising receiving a second amount of a second fluid from a second medical device.

[0048] If the first treatment has a higher priority than the second treatment, the system can determine that adjustments can be made to the second medical device to prioritize the first treatment. For example, if no fluid has been administered and administration of both fluids would result in overhydration of the patient, the system can reduce the administration of the second fluid. In some implementations, the reduction of the two fluids can be based on a priority-weighted amount. For example, the first fluid may be reduced less than the second fluid because it has a higher priority (and therefore a greater weight).

[0049] Therefore, in the depicted example, if it is determined that (401-Y) the first treatment has a higher priority than the second treatment, process 400 includes adjusting (402) the second medical treatment. In other words, when the second medical treatment is a lower priority treatment, it can be adjusted. In some embodiments, if it is determined that (401-N) the first treatment does not have a higher priority than the second treatment, process 400 includes adjusting (403) the first medical treatment. In other words, when the second medical treatment is not a lower priority treatment, it may not be adjusted.

[0050] The prioritization described above (401) allows the process to prioritize higher-priority treatments over lower-priority treatments. For example, a patient may be receiving a saline solution to maintain hydration, which may constitute a first treatment. Upon receiving a request for a second treatment, the second treatment is determined to have a higher priority than the first treatment. The first treatment involves only the administration of saline, while the second treatment includes a critical medication. Therefore, the first treatment may be delayed, canceled, slowed down, or otherwise modified to allow the second treatment without posing a risk of fluid overload.

[0051] Many of the example processes 300 and 400 above, along with their related features and applications, can also be implemented as software processing, specified as a set of instructions recorded on a computer-readable storage medium (also known as a computer-readable medium), and can be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause one or more processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard disk drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

[0052] The term "software" is intended to include, where appropriate, firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processor processing. Furthermore, in some embodiments, the multiple software aspects disclosed herein may be implemented as sub-parts of a larger program while maintaining the distinct software aspects disclosed herein. In some embodiments, the multiple software aspects may also be implemented as separate programs. Finally, any combination of separate programs that collectively implement the software aspects described herein is within the scope of this disclosure. In some embodiments, a software program, when installed for operation on one or more electronic systems, defines one or more specific machine implementations of the operations performed and executed by the software program.

[0053] Computer programs (also referred to as programs, software, software applications, scripts, or code) can be written in any programming language (including compiled or interpreted languages, declarative or procedural languages) and can be deployed in any form (including as standalone programs or as modules, components, subroutines, objects, or other units suitable for use in a computing environment). A computer program can, but does not necessarily, correspond to a file in a file system. A program can be stored as a portion of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinating files (e.g., a file storing one or more modules, subroutines, or code sections). A computer program can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communication network.

[0054] Figure 5 This is a conceptual diagram of an example electronic system 500 for managing patient hydration, based on various aspects of the subject matter technology. The electronic system 500 may be implemented by a computing device for executing software associated with one or more parts or steps of processes 300 and / or 400, or for executing software related to… Figures 1 to 4 The software associated with the provided components and methods. In this regard, electronic system 500 may include infusion device 100, total fluid monitoring device (e.g., Figure 2 The display user interface 200) and / or the computing device within or connected to the infusion device 100.

[0055] Electronic system 500 may include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, electronic system 500 includes a bus 508, one or more processing units 512, system memory 504, read-only memory (ROM) 510, permanent storage device 502, one or more input device interfaces 514, one or more output device interfaces 506, and one or more network interfaces 516. In some embodiments, electronic system 500 may include or be integrated with other computing devices or circuitry for operating the various components and methods described above.

[0056] Bus 508 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 500. For example, bus 508 communicatively connects one or more processing units 512 to ROM 510, system memory 504, and permanent storage device 502.

[0057] From these various memory units, one or more processing units 512 retrieve instructions to be executed and data to be processed in order to perform the processes disclosed in this subject matter. In different embodiments, the one or more processing units 512 may be a single processor or a multi-core processor.

[0058] ROM 510 stores static data and instructions required by one or more processing units 512 and other modules of the electronic system. On the other hand, permanent storage device 502 is a read-write memory device. This device is a non-volatile memory cell that can store instructions and data even when the electronic system 500 is powered off. Some embodiments disclosed in this subject matter use mass storage devices (such as magnetic disks or optical disks and their corresponding disk drives) as permanent storage device 502.

[0059] Other embodiments use removable storage devices (such as floppy disks, flash drives, and their corresponding disk drives) as permanent storage device 502. Like permanent storage device 502, system memory 504 is a read-write memory device. However, unlike storage device 502, system memory 504 is volatile read-write memory, such as random access memory (RAM). System memory 504 stores some instructions and data required by the processor during operation. In some embodiments, the processes disclosed in this subject matter are stored in system memory 504, permanent storage device 502, and / or ROM 510. From these various memory units, one or more processing units 512 retrieve instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0060] Bus 508 is also connected to one or more input device interfaces 514 and one or more output device interfaces 506. The one or more input device interfaces 514 enable users to communicate information and select commands to the electronic system. Input devices used with the one or more input device interfaces 514 include, for example, alphanumeric keypads and pointing devices (also known as "cursor control devices"). The one or more output device interfaces 506 are capable of displaying, for example, images generated by the electronic system 500. Output devices used with the one or more output device interfaces 506 include, for example, printers and display devices such as cathode ray tube (CRT) or liquid crystal displays (LCDs). Some implementations include devices such as touchscreens, which serve as both input and output devices.

[0061] In addition, such as Figure 5As shown, bus 508 also couples electronic system 500 to a network (not shown) via one or more network interfaces 516. Network interface 516 may include, for example, a wireless access point (e.g., Bluetooth or Wi-Fi) or radio circuitry for connecting to a wireless access point. One or more network interfaces 516 may also include hardware (e.g., Ethernet hardware) for connecting a computer to a computer network (such as a local area network (LAN), wide area network (WAN), wireless LAN, intranet) or a part of a network of networks (such as the Internet). Any or all components of electronic system 500 may be used in conjunction with the disclosure of this subject matter when specifically configured with one or more of the features described.

[0062] The functions described above can be implemented in computer software, firmware, or hardware. This technology can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. Processes and logic flows can be executed by one or more programmable processors and one or more programmable logic circuits. General-purpose and special-purpose computing devices and storage devices can be interconnected through communication networks.

[0063] Some implementations include electronic components, such as microprocessors, memories, and storage devices, that store computer program instructions in a machine-readable or computer-readable medium (also referred to as a computer-readable storage medium, machine-readable medium, or machine-readable storage medium). Examples of such computer-readable media include RAM, ROM, read-only optical discs (CD-ROM), recordable optical discs (CD-R), rewritable optical discs (CD-RW), read-only digital versatile optical discs (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini SD cards, micro SD cards, etc.), magnetic and / or solid-state hard disk drives, read-only and recordable... Disks, high-density optical discs, other optical or magnetic media, and floppy disks. Computer-readable media may store computer programs executable by at least one processing unit and include a set of instructions for performing various operations. Examples of computer programs or computer code include machine code (such as that generated by a compiler), and files that include higher-level code executed by a computer, electronic components, or microprocessor using an interpreter.

[0064] While the above discussion primarily refers to microprocessors or multi-core processors that execute software, some implementations are performed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions stored on the circuit itself.

[0065] As used in this specification and any claim of this application, the terms "computer," "server," "processor," and "memory" refer to an electronic or other technical device specifically configured with one or more of the fluid tracking features described herein. These terms do not include people or groups of people. For the purposes of this specification, the terms "displayed" or "being displayed" mean displayed on an electronic device. As used in this specification and any claim of this application, the term "computer-readable medium" is entirely limited to a tangible physical object that stores information in a computer-readable form. These terms do not include any wireless signals, wired download signals, or any other transient signals.

[0066] To provide interaction with the user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) and a keyboard and pointing device (e.g., a mouse or trackball) for displaying information to the user, through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in the form of sound, speech, gestures, or tactile input. Furthermore, the computer can interact with the user by sending and receiving documents from the device used by the user, for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0067] The embodiments of the subject matter described in this specification can be implemented in a specially configured computing system, including back-end components (e.g., as a data server), or including specially configured middleware components (e.g., an application server), or including specially configured front-end components (e.g., a client computer with a graphical user interface or a web browser, allowing users to interact with the embodiments of the subject matter described in this specification), or any combination of one or more such back-end, middleware, or front-end components. Components of the system can be interconnected via one or more forms or media of digital data communication (e.g., a communication network). Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), the Internet (e.g., the Internet) and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0068] A computing system may include specially configured clients and servers. Clients and servers are typically geographically separated but can interact via a communication network. The client-server relationship arises from computer programs running on respective computers and having a client-server relationship with each other. In some implementations, the server transmits data (e.g., HTML pages) to the client device (e.g., to display data to a user interacting with the client device and to receive user input from the user interacting with the client device). Data generated at the client device (e.g., the result of user interaction) can be received from the client device at the server.

[0069] Those skilled in the art will understand that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability between hardware and software, the various illustrative blocks, modules, elements, components, methods, and algorithms have been described above in general terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. For each specific application, the described functionality can be implemented in different ways. Various components and blocks can be arranged differently (e.g., in different orders or partitioned in different ways), all without departing from the scope of the subject matter.

[0070] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an illustrative approach. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps may be performed simultaneously. The appended method requires that the elements of each step be presented in the illustrative order, but does not imply limitation to the specific order or hierarchy presented.

[0071] Description of the subject matter technology in the form of clauses:

[0072] For convenience, various examples of aspects of this disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided as examples and do not limit the technical scope of the subject matter. The illustrations and reference numerals provided below are for illustrative purposes only, and the clauses are not limited by these references.

[0073] Clause 1. A method for managing patient hydration, the method comprising: receiving a fluid delivery request, the fluid delivery request including a first programmed amount of first fluid to be provided by a first medical device; identifying a second programmed amount of second fluid to be provided by or to be provided by a second medical device; determining, based on the first programmed amount and the second programmed amount, that medical device operation should be adjusted; and, in response to the determination, adjusting medical device operation based on the fluid delivery request and the first programmed amount and the second programmed amount.

[0074] Clause 2, the method described in Clause 1, wherein adjusting the operation of the medical device includes delaying or refusing a fluid delivery request.

[0075] Clause 3. The method described in Clause 1, wherein adjusting the operation of the medical device includes adjusting a first programmed value or a second programmed value.

[0076] Clause 4. The method described in Clause 1, wherein adjusting the operation of the medical device includes adjusting the dilution of the first fluid or the dilution of the second fluid.

[0077] Clause 5. The method described in Clause 1, wherein adjusting the operation of the medical device includes refusing to dispense the first fluid by the dispensing machine.

[0078] Clause 6. The method according to any one of Clauses 1 to 5, wherein the first medical device includes a first infusion pump configured to provide a first programmed amount of first fluid during a first programmed time period.

[0079] Clause 7. The method according to any one of Clauses 1 to 6, wherein the second medical device includes a second infusion pump configured to deliver a second amount of second fluid during a second programmed time period.

[0080] Clause 8. The method according to any one of Clauses 1 to 7, wherein adjusting the operation of the medical device includes adjusting the duration of the time programmed into the corresponding infusion pump for administering the corresponding fluid to the patient.

[0081] Clause 9. The method according to any one of Clauses 1 to 8, wherein determining that the operation of the medical device should be adjusted includes determining that the sum of the first programmed amount and the second programmed amount satisfies the fluid delivery threshold.

[0082] Clause 10, the method according to Clause 9, wherein adjusting the operation of the medical device includes providing an alarm indicating that the sum of a first programmed amount and a second programmed amount meets a fluid delivery threshold.

[0083] Clause 11. The method according to Clause 9 or 10, further comprising: estimating the patient’s water loss relative to the patient’s weight, the patient’s height, the patient’s sex, the patient’s disease state, the patient’s body temperature, or the patient’s body surface area; and wherein the fluid delivery threshold is based on the patient’s estimated water loss.

[0084] Clause 12. The method according to Clause 11, further comprising: receiving the patient's hydration; and wherein the fluid delivery threshold is based on the patient's hydration.

[0085] Clause 13. The method according to Clause 12, wherein receiving the patient's hydration includes receiving the patient's hydration information from the catheter system.

[0086] Clause 14. The method according to any one of Clauses 1 to 13, further comprising: determining that a first treatment has a higher priority than a second treatment, wherein the first treatment includes a first fluid provided by a first medical device in a first programmed amount, and the second treatment includes a second fluid provided by a second medical device in a second programmed amount; and wherein adjusting the operation of the medical devices includes adjusting the operation of the second medical device.

[0087] Clause 15. The method according to any one of Clauses 1 to 13, further comprising: determining that a second treatment has a higher priority than a first treatment, wherein the first treatment includes a first fluid supplied with a first programmed amount by a first medical device, and the second treatment includes a second fluid supplied with a second programmed amount by a second medical device; and wherein adjusting the operation of the medical devices includes adjusting the operation of the first medical device.

[0088] Clause 16. The method according to any one of Clauses 1 to 15, wherein the fluid delivery request includes a drug order for delivery of a drug from the first medical device to a patient.

[0089] Clause 17. The method according to any one of Clauses 1 to 16, wherein the first medical device includes a first infusion pump configured to administer a first fluid to a patient, the second medical device includes a second infusion pump configured to administer a second fluid to a patient, the second fluid including a saline solution, and adjusting the operation of the medical devices includes automatically reducing a second programmed amount.

[0090] Clause 18. The method according to any one of Clauses 1 to 15, wherein the first medical device includes an automatic dispensing machine, and the fluid delivery request includes a request to dispense the first fluid from the dispensing machine.

[0091] Clause 19. An electronic device comprising: one or more processors; and a memory storing one or more programs, the one or more programs including instructions that, when executed by the one or more processors, cause the electronic device to perform any one of Clauses 1 to 18.

[0092] Clause 20. A non-transitory computer-readable storage medium storing one or more programs, the programs including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform any one of Clauses 1 to 18.

[0093] Further consideration:

[0094] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an exemplary approach. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps may be performed simultaneously. The claims of the appended method present the elements of various steps in a sample order, but this does not imply limitation to the specific order or hierarchy presented.

[0095] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. The foregoing description provides various examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but are to be given the full scope consistent with the language of the claims, wherein, unless specifically stated otherwise, singular references are not intended to mean “one and only one,” but rather “one or more.” Unless otherwise specifically stated, the term “some” means one or more. Masculine pronouns (e.g., his) include feminine and neutral genders (e.g., her and its), and vice versa. Titles and subtitles (if any) are used for convenience only and do not limit the invention described herein.

[0096] The predicates “configured as,” “operable as,” and “programmed as” do not imply any specific tangible or intangible modification to the subject, but are intended to be used interchangeably. For example, a processor configured to monitor and control operations or components can also mean a processor programmed to monitor and control operations or an operable processor to monitor and control operations. Similarly, a processor configured to execute code can be interpreted as a processor programmed to execute code or an operable processor to execute code.

[0097] As used herein, the term "automatic" can include actions performed by a computer or machine without user intervention; for example, by instructions initiated by a computer, machine, or other initiation mechanism in response to a predicate action. The word "example" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as an "example" is not necessarily to be construed as preferential or superior to other aspects or designs.

[0098] Phrases such as "aspect" do not imply that such aspect is essential to the subject matter or that such aspect applies to all configurations of the subject matter. Disclosures relating to an aspect may apply to all configurations or one or more configurations. An aspect may provide one or more examples. Phrases such as "aspect" may refer to one or more aspects, and vice versa. Phrases such as "implementation" do not imply that such implementation is essential to the subject matter or that such implementation applies to all configurations of the subject matter. Disclosures relating to an implementation may apply to all implementations or one or more implementations. An implementation may provide one or more examples. Phrases such as "implementation" may refer to one or more implementations, and vice versa. Phrases such as "configuration" do not imply that such configuration is essential to the subject matter or that such configuration applies to all configurations of the subject matter. Disclosures relating to a configuration may apply to all configurations or one or more configurations. A configuration may provide one or more examples. Phrases such as "configuration" may refer to one or more configurations, and vice versa.

[0099] As used herein, a “user interface” (also referred to as an interactive user interface, graphical user interface, or UI) can refer to a web-based interface that includes data fields and / or other control elements for receiving input signals or providing electronic information, and / or providing information to the user in response to any received input signals. Control elements may include dial pads, buttons, icons, selectable areas, or other perceptible markings presented via the UI, which initiate data exchange for the device presenting the UI when interacted with (e.g., clicked, touched, selected, etc.). The UI may use, in whole or in part, technologies such as Hypertext Markup Language (HTML), Flash, etc. TM JAVA TM .NET TM The implementation uses technologies such as C, C++, web services, or Rich Site Summary (RSS). In some implementations, the UI may be included in a separate client (e.g., a thick client, a fat client) configured to communicate (e.g., send or receive data) according to one or more of the described aspects. Communication may be communication with or from the medical device or a server communicating with it.

[0100] As used herein, the term "determine" or "determined" encompasses a wide variety of actions. For example, "determined" can include calculations, operations, processing, derivations, generation, retrieval, lookups (e.g., searching in tables, databases, or other data structures), and determinations performed via hardware components without user intervention. Furthermore, "determined" can include receiving (e.g., receiving information) and accessing (e.g., accessing data in memory) via hardware components without user intervention. "Determined" can also include parsing, selecting, picking, and building via hardware components without user intervention.

[0101] As used herein, the term “provide” or “provide” encompasses a wide variety of actions. For example, “providing” can include storing a value at a location on a storage device for later retrieval, transmitting a value directly to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, etc. “Providing” can also include encoding, decoding, encrypting, decrypting, acknowledging, verifying, etc., via hardware components.

[0102] As used herein, the term "message" encompasses a variety of formats used to convey (e.g., transmit or receive) information. A message may include machine-readable summaries such as XML documents, fixed-field messages, comma-separated messages, JSON, custom protocols, etc. In some implementations, a message may include signals of one or more representations used to transmit information. Although stated in the singular, it is understood that a message may consist of multiple parts, be transmitted, stored, received, etc.

[0103] As used herein, the terms “optionally” or “selective” can cover a wide variety of actions. For example, “selective” processing may include determining an option from a plurality of options. “Selective” processing may include one or more of the following: dynamically determined input, pre-configured input, or user-initiated input for making the determination. In some implementations, n input switches may be included to provide selective functionality, where n is the number of inputs used to make the selection.

[0104] As used herein, the term "correspondence" or "corresponding to" encompasses a structural, functional, quantitative, and / or qualitative association or relationship between two or more objects, datasets, information, and / or the like, preferably wherein the correspondence or relationship can be used to transform two or more objects, information, and / or the like to appear identical or equal. Correspondence can be evaluated using one or more of the following: thresholds, value ranges, fuzzy logic, pattern matching, machine learning evaluation models, or combinations thereof.

[0105] In some implementations, the generated or detected data can be forwarded to a “remote” device or location, where “remote” means a location or device other than the one where the program is executed or the device. For example, a remote location could be another location in the same city (e.g., an office, laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. Therefore, when an item is indicated as being “remote” to another item, it means that the two items can be in the same room but separated, or at least in different rooms or different buildings, and can be at least one mile, ten miles, or at least one hundred miles apart. “Transmitting” information refers to the transmission of data representing that information as electrical signals via an appropriate communication channel (e.g., a private or public network). “Forwarding” an item refers to any means of moving the item from one location to another, whether by physical transfer or other means (if possible), and at least in the case of data, includes the physical transfer of the medium carrying or transmitting the data. Examples of communication media include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet, or include email transmissions and information recorded on websites, etc.

Claims

1. A method of managing hydration in a patient, the method comprising: receiving a fluid delivery request including a first programmed amount of a first fluid to be provided by a first medical device; identifying a second programmed amount of a second fluid provided or to be provided by a second medical device; determining, based on the first programmed amount and the second programmed amount, that medical device operation should be adjusted; as well as In response to the determination, the medical device operation is adjusted based on the fluid delivery request and the first programmed amount and the second programmed amount.

2. The method according to claim 1, wherein: Adjusting the operation of the medical device includes delaying or denying the fluid delivery request.

3. The method according to claim 1, wherein: Adjusting the medical device operation includes adjusting the first programmed amount or the second programmed amount.

4. The method according to claim 1, wherein: Adjusting the operation of the medical device includes adjusting a dilution of the first fluid or a dilution of the second fluid.

5. The method according to claim 1, wherein: Adjusting the operation of the medical device includes denying dispensing of the first fluid by the dispenser.

6. The method according to any one of claims 1 to 5, wherein: The first medical device includes a first infusion pump configured to provide the first programmed amount of a first fluid for a first programmed time period.

7. The method according to any one of claims 1 to 6, wherein: The second medical device includes a second infusion pump configured to provide the second programmed amount of a second fluid for a second programmed time period.

8. The method according to any one of claims 1 to 7, wherein: Adjusting the medical device operation includes adjusting the duration of time programmed into the corresponding infusion pump for administering the corresponding fluid to the patient.

9. The method according to any one of claims 1 to 8, wherein: Determining that operation of the medical device should be adjusted includes determining that a sum of the first programmed amount and the second programmed amount satisfies a fluid delivery threshold.

10. The method according to claim 9, wherein: Adjusting the medical device operation includes providing an alert indicating that a sum of the first programmed amount and the second programmed amount satisfies the fluid delivery threshold.

11. The method according to claim 9 or 10, further comprising: estimating the patient's water loss based on the patient's weight, the patient's height, the patient's gender, the patient's disease state, the patient's body temperature, or the patient's body surface area; and Wherein the fluid delivery threshold is based on an estimated water loss of the patient.

12. The method according to claim 11, further comprising: receiving hydration of said patient; and Wherein the fluid delivery threshold is based on the hydration of the patient.

13. The method according to claim 12, wherein: Receiving hydration from the patient includes receiving hydration from the patient from a catheter system.

14. The method according to any one of claims 1 to 13, further comprising: determining a priority of a first therapy over a second therapy, wherein the first therapy includes providing the first programmed amount of a first fluid by the first medical device and the second therapy includes providing the second programmed amount of a second fluid by the second medical device; and Wherein, adjusting the operation of the medical device includes adjusting the operation of the second medical device.

15. The method according to any one of claims 1 to 13, further comprising: determining a priority of a second therapy over a first therapy, wherein the first therapy includes providing the first programmed amount of a first fluid by the first medical device and the second therapy includes providing the second programmed amount of a second fluid by the second medical device; and Wherein, adjusting the operation of the medical device includes adjusting the operation of the first medical device.

16. The method according to any one of claims 1 to 15, wherein: The fluid delivery request includes an order for a medication for delivery of the medication to a patient by the first medical device.

17. The method according to any one of claims 1 to 16, wherein: The first medical device includes a first infusion pump configured to administer the first fluid to a patient, the second medical device includes a second infusion pump configured to administer the second fluid to the patient, the second fluid includes a saline solution, and adjusting the operation of the medical devices includes automatically reducing the second programmed amount.

18. The method according to any one of claims 1 to 15, wherein: The first medical device comprises an automatic dispenser, and the fluid delivery request comprises a request to dispense the first fluid from the automatic dispenser.

19. A system, comprising: First Medical Devices; Second medical device; and An electronic device comprising one or more processors and a memory storing one or more programs, wherein the one or more programs include instructions that, when executed by the one or more processors, cause the electronic device to perform the method of any one of claims 1 to 18.

20. A non-transitory computer-readable storage medium storing one or more programs, the programs comprising instructions which, when executed by one or more processors of an electronic device, cause the electronic device to perform the method of any one of claims 1 to 18.

Images