EP4690224A1

EP4690224A1 - Diagnostic cycle for enhanced infusion pump safety

Info

Publication number: EP4690224A1
Application number: EP23719181.2A
Authority: EP
Inventors: Emma Claire KINNISON; Richard Stor Wu
Original assignee: CareFusion 303 Inc
Current assignee: CareFusion 303 Inc
Priority date: 2023-03-30
Filing date: 2023-03-30
Publication date: 2026-02-11
Also published as: AU2023440030A1; CN121002581A; WO2024205593A1

Abstract

An infusion pump is placed in a diagnostic mode in which fluid tubing is installed in the infusion pump but not connected to a patient. While in the diagnostic mode, the infusion pump performs an infusion cycle and determines whether one or more infusion hazards are detected. When an infusion hazard is detected, the infusion pump provides a notification or performs a self-calibration operation. When an infusion hazard is not detected or is no longer detected, the infusion pump exits the diagnostic mode and is configured to start an infusion.

Description

DIAGNOSTIC CYCLE FOR ENHANCED INFUSION PUMP SAFETY

BACKGROUND

[0001] Infusion pumps are complex electromechanical devices used to deliver fluids into a patient’s body in a controlled manner. They typically serve the needs of hospital -bound patients, where life-saving medication is normally delivered via intravenous infusion. Thus, reliability of infusion pumps and patient safety are extremely important.

[0002] Some infusion hazards that negatively affect the reliability of infusion pumps and patient safety include over-infusion and under-infusion. Over-infusion occurs when the pumping mechanism in an infusion pump is mis-calibrated or otherwise defective, thereby causing fluid to be pumped too quickly and endangering the patient. Under-infusion occurs when there is an occlusion in the fluid tubing of an infusion pump, thereby restricting fluid and endangering the patient.

SUMMARY

[0003] Based on the discussion above as well as other problems and disadvantages of the related art, there is a need for improved diagnostic systems and methods that allow infusion pumps to proactively detect and address infusion hazards prior to infusing the patient, thereby increasing patient safety.

[0004] According to various aspects of the subject technology, an infusion pump comprises a hazard sensor; and a processor configured to: confirm a fluid tubing is installed in the infusion pump but not connected to a patient; prior to starting an infusion, place the infusion pump in a diagnostic mode; while in the diagnostic mode and while the fluid tubing is not connected to the patient, cause the infusion pump to perform a first diagnostic infusion cycle using the fluid tubing; while the infusion pump is performing the first diagnostic infusion cycle, determine whether the hazard sensor detects an infusion hazard based on predetermined criteria for performing the first diagnostic infusion cycle when the fluid tubing is installed in the infusion pump but not connected to the patient; provide a notification or perform a self-calibration operation when an infusion hazard is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion when an infusion hazard is not detected or is no longer detected. [0005] According to various aspects of the subject technology, a method of operating an infusion pump includes, at a processor of the infusion pump: confirming a fluid tubing is installed in the infusion pump but not connected to a patient; prior to starting an infusion, placing the infusion pump in a diagnostic mode; while in the diagnostic mode and while the fluid tubing is not connected to the patient, causing the infusion pump to perform a first diagnostic infusion cycle using the fluid tubing; while the infusion pump is performing the first infusion cycle, determining whether a hazard sensor included in the infusion pump detects an infusion hazard based on predetermined criteria for performing the first diagnostic infusion cycle when the fluid tubing is installed in the infusion pump but not connected to the patient; providing a notification or performing a self-calibration operation when an infusion hazard is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion when an infusion hazard is not detected or is no longer detected.

[0006] It is understood that other configurations of the subject technology will become readily apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] For a better understanding of the various described implementations, reference should be made to the Detailed Description below, in conjunction with the following drawings. Like reference numerals refer to corresponding parts throughout the drawings and description.

[0008] FIG. 1 depicts an example infusion pump setup, shown in use in its intended environment.

[0009] FIG. 2 depicts an infusion pump with the front door open, showing the fluid line in operative engagement with the pump.

[0010] FIGS. 3A-3D depict a complete pumping cycle for an infusion pump. [0011] FIG. 4 depicts an example diagnostic workflow for proactively detecting and addressing infusion hazards when operating an infusion pump.

[0012] FIG. 5 depicts an example process for proactively detecting and addressing infusion hazards when operating an infusion pump.

[0013] FIG. 6 is a conceptual diagram illustrating an example electronic system for proactively detecting and addressing infusion hazards when operating an infusion pump.

DETAILED DESCRIPTION

[0014] Reference will now be made to implementations, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth, in order to provide an understanding of the various described implementations. However, it will be apparent to one of ordinary skill in the art that the various described implementations may 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 implementations.

[0015] FIG. 1 depicts an example infusion pump 102, shown in use in its intended environment, according to various aspects of the subject technology. In particular, the infusion pump 102 is shown mounted to an intravenous (IV) pole 104 on which a fluid supply 106 containing an IV fluid is held. The fluid supply 106 is connected in fluid communication with a flexible pumping fluid line (also referred to as fluid tubing) of an administration set 110. As used herein, the terms “fluid line” and “fluid tubing” may refer to the fluid line within an administration set, or to the administration set itself. The fluid line includes an upstream portion 112, a pump-mounted portion 114, and a downstream portion 116. The fluid line comprises IV tubing typically used in a hospital or medical environment, and is made of any type of flexible tubing appropriate for use in infusing therapeutic fluids into a patient, such as polyvinylchloride (PVC). The pump-mounted portion 114 is mounted in operative engagement with a pumping mechanism 108 (e.g., a peristaltic pump), configured to propel fluid from the upstream portion 112 through the downstream portion 116 to a patient 130 (e.g., to the patient’s arm).

[0016] The fluid line portions 112, 114, and 116 of the administration set 110 may be configured as a continuous length of flexible tubing, with the portions defined by the location of the pumping mechanism 108. A roller clamp 118 (e.g., configured to provide for mechanical compression of the fluid line to block the flow of fluid) may be positioned on the downstream portion 116 of the fluid line between the pump 102 and the patient 130. In this context, the term “upstream” refers to that portion of the fluid line that extends between the fluid supply 106 and pumping mechanism 108, and the term “downstream” refers to that portion of the fluid line that extends from the pumping mechanism 108 to the patient 130.

[0017] FIG. 2 depicts the infusion pump 102 with the front door 103 open, showing the fluid line (including portions 112, 114, and 116) in operative engagement with the infusion pump 102. The pumping mechanism 108 directly acts on portion 114 of the fluid line. Portion 114 of the fluid line connects the upstream portion 112 to the downstream portion 116 to form a continuous fluid conduit extending from the fluid supply 106 to the patient 130. As such, the infusion pump 102 causes fluid in the fluid line to move downstream from the fluid supply 106 to the patient 130. Specifically, the pumping mechanism 108 acts as a flow control device of the infusion pump 102 to move fluid though the fluid line to the patient.

[0018] The type of pumping mechanism 108 may vary and may be, for example, a multiple-finger peristaltic pump. For example, the pumping mechanism may include an upstream occluding finger 202, a primary pumping finger 204, a downstream occluding finger 206, and a secondary pumping finger 208. Such a pumping mechanism operates by sequentially pressing on segments of the fluid line by means of the fingers 202, 204, 206, and 208, thereby applying pressure in sequential locations of the fluid line beginning at the upstream end of the pumping mechanism and working toward the downstream end. At least one finger is always pressing hard enough to occlude the fluid line. As a practical matter, one finger does not retract from occluding the fluid line until the next one in sequence has already occluded the fluid line; thus, at no time is there a direct fluid path from the fluid supply 106 to the patient 130. Each finger is coupled to a cam, and the cams corresponding to the fingers are coupled to a camshaft, which is controlled by a motor. In some implementations, one complete revolution of the motor causes a single pumping cycle (described in more detail below with reference to FIG. 3).

[0019] The infusion pump 102 further includes at least one pressure sensor. In some implementations, the infusion pump 102 includes an upstream pressure sensor 222 and a downstream pressure sensor 224. The upstream pressure sensor 222 is mounted to the infusion pump 102 at an upstream location with respect to the pumping mechanism 108 (between the fluid supply 106 and the pumping mechanism 108), and the downstream pressure sensor 224 is mounted to the infusion pump 102 at a downstream location with respect to the pumping mechanism 108 (between the pumping mechanism 108 and the patient 130). As such, the connection of the correct fluid supply 106 to the correct infusion pump 102 may be verified before any fluid is pumped to the patient.

[0020] The pressure sensors 222, 224 provide a signal representative of a pressure within the tubing of portion 114 of the fluid line. When there is an occlusion in the fluid line, the signal may exhibit a force spike due to the blocked fluid causing the tubing to expand, which creates a pressure in the tubing. The pressure sensors 222, 224 continually monitor pressure within the fluid line 114 and translate the measured pressure readings to corresponding voltages. These voltages are provided (e.g., by analog-digital converters within the pump) to a processor. The processor detects force spikes based on comparisons of the voltage value readings to predetermined thresholds. In some implementations, the processor monitors readings for a moving window of time. Satisfaction of a threshold may include, for example, an average or mean of the voltage values measured during the window of time satisfying (e.g., meeting and/or exceeding) a threshold value, or a minimum or a maximum value within that window satisfying the threshold value.

[0021] The pressure sensors 222, 224 may be used for occlusion detection (also referred to as under-infusion detection) at the infusion pump 102. An occlusion is a common occurrence during an infusion, which occurs when there is an obstruction or closure of the fluid line. Occlusions cause patients to not receive their medication (or other fluid). In some critical applications involving the use of drugs which have a short half-life and result in an immediate pharmacological or physiological response, the plasma concentrations of drug may drop rapidly following an occlusion. In the case of short half-life vasoactive drugs used to maintain cardiac output, the patient’s condition can deteriorate rapidly if the infusion stops as the result of an occlusion. Occlusions also introduce the risk of a post occlusion bolus, where the pressure in the line builds behind the occlusion and releases suddenly when it clears.

[0022] To optimize occlusion detection, the pressure sensors 222, 224 may be coupled directly to the wall of the tubing of fluid line 114. As the internal fluid pressure increases or decreases, the tubing exerts more or less force on the sensors 222, 224. To ensure adequate coupling, the tubing must be compressed to provide a pre-load force baseline for the pressure sensors 222, 224. When the detected pressure meets or exceeds a predetermined occlusion pressure threshold, the infusion pump 102 outputs an alarm. The positioning of this threshold may be configurable. If set too high, chances of harmful effects on the patient prior to the alarm sounding are increased (longer time to alarm resulting in a delay to medication delivery). If set too low, the number of nuisance alarms may go up, leading to complaints.

[0023] The infusion pump 102 further includes a flow sensor 230. The flow sensor 230 may be used for over-infusion detection at the infusion pump 102. When the detected flow rate meets or exceeds a predetermined threshold, this indicates an over-infusion event. Overinfusion is a major cause of fatal adverse events, and it may occur if the disposable tubing of the administration set is not correctly fitted to the pump, or if the fluid is under the action of gravity without the tubing being correctly pinched or clamped. In either of these cases, there are device alarms which can be used to alert the user or caregiver.

[0024] In some implementations, the flow sensor 230 is mounted in the infusion pump. Alternatively, the flow sensor 230 may be mounted to the administration set 10, which allows the flow sensor to be calibrated to the exact dimensions of the tubing of the administration set. The flow sensor 230 provides a signal representative of a flow rate of fluid within the tubing of portion 114 of the fluid line. The flow sensor 230 continually monitors the flow rate within the fluid line 114 and translates the measured flow rate readings to corresponding voltages. These voltages are provided (e.g., by analog-digital converters within the pump) to a processor. The processor compares the voltage value readings to predetermined thresholds. In some implementations, the processor monitors readings for a moving window of time. Satisfaction of a threshold may include, for example, an average or mean of the voltage values measured during the window of time satisfying (e.g., meeting and/or exceeding) a threshold value, or a minimum or a maximum value within that window satisfying the threshold value.

[0025] The infusion pump 102 further includes an air-in-line detector 240. The air-in-line detector 204 may be used for detection of air in the fluid line, which is important for patient safety because small volumes of air injected intravenously are considered a hazard. If excessive air is detected in the fluid line, the infusion pump 102 stops the infusion and generates an alarm to alert the caregiver. [0026] The air-in-line detector 240 is mounted in the infusion pump. The air-in-line detector 240 provides a signal representative of an amount of air detected within the tubing of portion 114 of the fluid line. The air-in-line detector 240 continually monitors the presence of air within the fluid line 114 and translates the measured readings (e.g., air bubble size, or number of air bubbles) to corresponding voltages. These voltages are provided (e.g., by analog-digital converters within the pump) to a processor. The processor compares the voltage value readings to predetermined thresholds (e.g., an air bubble size threshold, or a cumulative air bubble count within a moving window of time). In some implementations, the processor monitors readings for a moving window of time. Satisfaction of a threshold may include, for example, an average or mean of the voltage values measured during the window of time satisfying (e.g., meeting and/or exceeding) a threshold value, or a minimum or a maximum value within that window satisfying the threshold value.

[0027] In some implementations, the air-in-line detector 240 uses a pair of ceramic ultrasonic sensors in tandem with software algorithms to detect the presence of air in the fluid line. An alarm occurs when the air-in-line detector 240 detects either a series of smaller air bubbles (that equate to a dangerous total sum of air) or a continuous/ single air bubble that is of an unacceptable volume. The acceptable air volume thresholds may be configured to balance the tradeoffs between patient safety and nuisance alarms. Nuisance air-in-line alarms are due to misdetection and may occur due to the air-in-line detector 240 being too sensitive, which can lead to complaints. Conversely, if the air-in-line detector 240 is too insensitive, it may not detect unacceptable volumes of air, which may lead to patient harm.

[0028] FIGS. 3A-3D depict a complete pumping cycle for an infusion pump 102. The example pumping cycle (also referred to as an infusion cycle or a motor cycle) depicted in the figures consists of four phases. When the infusion pump 102 is powered on, the fingers 202, 204, 206, 208 of the pump are reset to default positions before an infusion is started (FIG.

3 A). In some implementations, the finger elements are reset every time the door is opened or closed, or when the pump is powered on or off, or when the pump is placed into a standby mode. When the finger elements are in their default positions, the pump is said to be in the “home” position. The home position is defined as the upper occluder 202 being open, the upper finger 204 being half open (e.g., between open and close), the lower occluder 206 being closed (or shut), and the lower finger 208 being half open. [0029] Before an infusion is started, the clinician connects (e.g., spikes) the medication bag (fluid supply 106) with a new administration set 110, at least partially fills a drip chamber, opens the roller clamp 118, and primes the IV fluid line. The clinician uses the roller clamp 118 to control the priming rate, ensuring minimal spillage, and holds the distal end of the administration set with the other hand. The clinician closes the roller clamp 118 once the administration set is fully primed. The clinician may then load the administration set into the pump and start programming the pump. During this step, the pump may be in the home position. The clinician may then open the roller clamp 118 and start the infusion. When the roller clamp is opened, fluid begins to move.

[0030] With each successive phase of the pumping cycle, adjacent segments of portion 114 of the fluid line are sequentially compressed, allowing a controlled portion of fluid 302 to pass through the pump 102 on its way to the patient 130 at a configurable flow rate. After the final phase of a given pumping cycle (FIG. 3D), the next phase is the first phase of the next pumping cycle (FIG. 3A), allowing the next portion of fluid to pass to the patient 130 in a controlled manner and at the configurable flow rate. Thus, one infusion cycle comprises one full cycle of movement of each of the plurality of fingers 202, 204, 206, and 208. At least one finger operates to compress the fluid line, while at least one finger operates as an occluder to occlude the fluid line. A full cycle of movement for a given finger/occluder includes a fully compressed position (e.g., 206, FIG. 3A), a partially decompressed position (e.g., 206, FIG. 3B), a fully decompressed position (e.g., 206, FIG. 3C), and a partially compressed position (e.g., 206, FIG. 3D), ending just before reaching the same position that occurred at the beginning of the cycle.

[0031] Each finger 202, 204, 206, and 208 is coupled to a corresponding cam, and the cams are coupled to a camshaft, which is controlled by a motor. Generally, each of the fingers completes a full cycle during a full pumping cycle. In some implementations, one full revolution of the camshaft corresponds to a full pumping cycle. Depending on the specifications of the motor (e.g., including the presence of gears or other mechanical elements between the motor and the camshaft), a complete pumping cycle may correspond to less than one full revolution of the motor or more than one full revolution of the motor. In some implementations, one full rotation of the motor corresponds to one full pumping cycle. In any event, a complete pumping cycle may be defined as beginning and ending with the same configuration of finger elements (e.g., 202, 204, 206, and 208). [0032] While the example depicted in FIG. 3 uses four fingers and four phases, other implementations may use fewer than four fingers or greater than four fingers. Likewise, other implementations may use fewer than four phases or greater than four phases. Also, while the example depicted in FIG. 3 uses a finger configuration having two occluder valves (fingers 202 and 206) and two pumping elements (fingers 204 and 208), other implementations may use different configurations and orders of occluder valves and pumping elements, including implementations having only occluder valves, only pumping elements, or combinations of occluder valves and pumping elements. Further, the sizes and shapes of each occluder valve and pumping element may differ in other implementations.

[0033] FIG. 4 depicts an example diagnostic workflow for proactively detecting and addressing infusion hazards when operating an infusion pump 102, according to various aspects of the subject technology. The various implementations of the diagnostic workflow described herein allow the pump 102 to proactively detect infusion hazards (e.g., overinfusion, upstream occlusions, and downstream occlusions) prior to infusing the patient, thereby increasing patient safety. Prior to infusing the patient, the administration set 110 is loaded with fluid from a fluid supply 106 and installed in the pump 102, but the fluid line (portion 116) is not connected to the patient 130. The pump 102 runs a diagnostic infusion cycle while detecting for hazards. If a hazard is detected, the pump 102 notifies the clinician, and in some cases, attempts to self-correct the problem. Thus, hazards can be prevented rather than mitigated, thereby increasing patient safety.

[0034] In the depicted example, a clinician powers on (402) the pump and primes and installs (404) an administration set (e.g., 110). At this point, the primed administration set is connected to a fluid supply (e.g., supply 106 via portion 112) and is installed in the pump (e.g., portion 114), but not connected to a patient. Instead, the downstream portion of the administration set (e.g., 116) may be temporarily inserted into a container for collecting excess fluid.

[0035] In some implementations, the pump may prompt or warn (406) the clinician not to connect the administration set to a patient (e.g., the infusion pump displays: “Warning: Do not connect administration set to patient ”). The pump may wait to receive an acknowledgement or confirmation (408) from the clinician that the warning was noticed (e.g., via an “OK” button being pressed). Optionally, the clinician may override the diagnostic mode, and the system may record the overriding of the diagnostic mode. [0036] The infusion pump proceeds to enter a diagnostic mode (410). Optionally, the infusion pump may warn and display instructions (412) regarding the diagnostic mode (e.g., the infusion pump displays: “Diagnostic Mode: Do not connect administration set to patient. Pump is running automatically. Make sure excess fluid is collected.”).

[0037] The infusion pump proceeds to run a diagnostic infusion cycle (414) (also called a “diagnostic cycle”). In some implementations, the diagnostic cycle is run automatically (without user intervention) in response to the clinician acknowledging/confirming that the infusion line is not connected to the patient. In some implementations, the diagnostic cycle completes during one single pump cycle (e.g., a single rotation of the camshaft). In some implementations, the diagnostic cycle completes in less than a single pump cycle. FIGS. 3A- 3D depict a diagnostic cycle. The diagnostic cycle need only last for one (or less than one) complete infusion cycle and may run at a relatively fast flow rate (e.g., greater than 100 mL/hr), allowing the diagnostic cycle to complete within a relatively short amount of time (e.g., less than 5 seconds), thereby conserving fluid and not significantly delaying treatment.

[0038] The infusion pump proceeds to perform hazard detection (416) during the diagnostic cycle. Specifically, the infusion pump executes one or more hazard detection algorithms configured to detect, for example, over-infusion, upstream occlusions, and/or downstream occlusions. Such algorithms may be run in parallel or in sequence. To the extent the algorithms do not rely on the same sensing hardware, they may be run in parallel.

[0039] During the diagnostic cycle, the infusion pump may detect for occlusions (418). In some implementations, the infusion pump detects upstream and/or downstream occlusions using one or more pressure sensors (e.g., 222 and/or 224) as described above with reference to FIG. 2. Additionally, or alternatively, the infusion pump may detect occlusions using any suitable occlusion detection process and/or occlusion detection sensors (regardless of whether they are pressure sensors). According to various implementations, the infusion pump measures a force generated by a force sensor (e.g., downstream force sensor 224) during the diagnostic cycle and compares the force to predetermined force criteria for the diagnostic cycle (e.g., measured for one rotation of the camshaft at a high speed during manufacturing and testing). In some implementations, a waveform of the force measured during the diagnostic cycle may be compared to a predetermined expected waveform for the diagnostic cycle (e.g., for one or less of a cam revolution while the fluid tubing is installed in the infusion pump but not connected to the patient). [0040] If an occlusion is detected during operation 418, the infusion pump warns (420) the clinician that an occlusion was detected (e.g., the infusion pump displays: “Warning: occlusion detected, please check administration set line for occlusions.”). At this point, the clinician may perform troubleshooting steps, including double checking the placement of various portions of the administration set, removing and re-installing the administration line, re-priming the administration set, or replacing the administration set. Optionally, the infusion pump displays instructions (422) regarding next steps (e.g., the infusion pump displays: “Click OK to re-run diagnostic cycle ”). The infusion pump receives acknowledgement or confirmation (424) of the instructions and/or an instruction to repeat the diagnostic cycle (e.g., an “OK” button is pressed). Upon receiving the acknowledgement or confirmation of the instructions, the workflow re-runs the diagnostic cycle (414), including detecting hazards during the diagnostic cycle (416) as described above.

[0041] If an occlusion is not detected during operation 418, the diagnostic workflow is complete with respect to occlusion detection. If no other hazards were detected, the infusion pump optionally notifies (426) the clinician that the diagnostic is complete (e.g., the infusion pump displays: “Diagnostic Complete, all systems normal.”), and receives acknowledgement or confirmation (428) of the notice (e.g., an “OK” button is pressed). The infusion pump then resumes (430) normal startup procedures (e.g., the clinician enters a flow rate and volume to be infused (VTBI) for the infusion being programmed). As part of these startup procedures, the clinician attaches the downstream portion of the administration set (e.g., 116) to the patient and proceeds with the infusion.

[0042] During the diagnostic cycle, the infusion pump may detect for over-infusion (432). In some implementations, the infusion pump detects over-infusion using a flow sensor (e.g., 230) as described above with reference to FIG. 2. According to various implementations, the pump detects an over-infusion for the diagnostic cycle if the flow measured by the flow sensor during the diagnostic cycle varies from a predetermined flow criteria (e.g., for one or less of a cam revolution while the fluid tubing is installed in the infusion pump but not connected to the patient). Additionally, or alternatively, the infusion pump may detect over-infusion using any suitable over-infusion detection process and/or over-infusion detection sensor (regardless of whether it is a flow sensor). [0043] If over-infusion is detected during operation 432, the infusion pump may attempt to self-correct the flow rate or warn the clinician and disable startup procedures, depending on how many times an over-infusion event has been detected.

[0044] Upon detecting an over-infusion event for a first time (e.g., since powering up the infusion pump and running the first diagnostic), the infusion pump detects an over-infusion percentage by comparing the measured flow rate during the diagnostic cycle to the programmed (or otherwise predetermined) diagnostic flow rate. Based on the percentage of over-infusion, the infusion pump may automatically (without user intervention) self-calibrate (436) the motor speed to reduce the over-infusion percentage. For example, if fluid was overinfused by 10% (the measured flow rate was 10% higher than an expected predetermined flow rate threshold for the diagnostic cycle), the infusion pump may decrease the motor by 10%, or decreases the motor enough to effectively reduce the flow rate by 10%. After selfcalibrating, the infusion pump may proceed to repeat the diagnostic cycle operations beginning with operation 414.

[0045] Upon detecting an over-infusion event for a second time (e.g., any time after a first detection), the infusion pump warns (438) the clinician that over-infusion was detected (e.g., the infusion pump displays: “Warning: hardware malfunction, replace or repair pump before use.”) and automatically disables (440) the infusion setup process by, for example, disabling programming options. In some implementations, the infusion setup process (including programming options) may be re-enabled during a maintenance process. Such a maintenance process may be accessible only to individuals who are authorized to perform maintenance operations on the infusion pump. It is important to disable the infusion pump as a result of uncorrectable over-infusion events, because the cause of such events is likely defective components (e.g., the motor) that must be serviced by a qualified technician. Occlusions, on the other hand, are typically solved by addressing issues with the disposable administration set, and as a result, the infusion pump may remain operational while the clinician attempts to troubleshoot the detected occlusion.

[0046] In some implementations, self-calibration operations 434-436 may be performed more than once before warning and disabling operations 438-440 are performed. In general, the infusion pump may repeat the diagnostic cycle N times (where N > 1) and attempt to selfcalibrate each time before switching to warning and disabling operations 438-440. [0047] If over-infusion is not detected during operation 432, the diagnostic workflow is complete with respect to over-infusion detection. If no other hazards were detected, the infusion pump optionally notifies (426) the clinician that the diagnostic is complete (e.g., the infusion pump displays: “Diagnostic Complete, all systems normal.”), and receives acknowledgement or confirmation (428) of the notice (e.g., an “OK” button is pressed). The infusion pump then resumes (430) normal startup procedures (e.g., the clinician enters a flow rate and volume to be infused (VTBI) for the infusion being programmed). As part of these startup procedures, the clinician attaches the downstream portion of the administration set (e.g., 116) to the patient and proceeds with the infusion.

[0048] For implementations in which a plurality of hazard detection algorithms are performed (e.g., occlusion detection 418 and over-infusion detection 432), diagnostic completion operations 426-430 are not performed until each hazard detection algorithm completes with no hazards detected.

[0049] FIG. 5 depicts an example process 500 for proactively detecting and addressing infusion hazards when operating an infusion pump, according to aspects of the subject technology. For explanatory purposes, the various blocks of example process 500 are described herein with reference to FIGS. 1-4, and the components and/or processes described herein. The one or more of the blocks of process 500 may be implemented, for example, by one or more computing devices including, for example, pump 102. In some implementations, one or more of the blocks may be implemented based on one or more algorithms (e.g., a machine learning algorithm). In some implementations, one or more of the blocks may be implemented apart from other blocks, and by one or more different processors or devices. Further for explanatory purposes, the blocks of example process 500 are described as occurring in serial, or linearly. However, multiple blocks of example process 500 may occur in parallel. In addition, the blocks of example process 500 need not be performed in the order shown and/or one or more of the blocks of example process 500 need not be performed.

[0050] Process 500 begins when, prior to starting an infusion, the infusion pump enters a diagnostic mode (502) in which fluid tubing is installed in the infusion pump but not connected to a patient. In some implementations, operation 502 (FIG. 5) corresponds to one or more of operations 402-408 (FIG. 4). [0051] While in the diagnostic mode, the infusion pump performs a first infusion cycle (504) using the fluid tubing. For example, the first infusion cycle is one complete infusion cycle (e.g., FIGS. 3A-3D). In some implementations, operation 504 (FIG. 5) corresponds to one or more of operations 410-414 (FIG. 4).

[0052] While the infusion pump is performing the first infusion cycle, the infusion pump determines whether a hazard sensor detects an infusion hazard (506). In some implementations, operation 506 (FIG. 5) corresponds to one or more of operations 416, 418, and 432 (FIG. 4).

[0053] The infusion pump provides a notification or performs a self-calibration operation when an infusion hazard is detected (508). In some implementations, providing a notification in operation 508 (FIG. 5) corresponds to one or more of operations 420-424 (FIG. 4), and performing self-calibration in operation 508 (FIG. 5) corresponds to one or more of operations 434-436 (FIG. 4).

[0054] The infusion pumps exits the diagnostic mode and is configured to start the infusion when an infusion hazard is not detected or is no longer detected (510). In some implementations, operation 510 (FIG. 5) corresponds to one or more of operations 426-430 (FIG. 4).

[0055] In some implementations, the hazard sensor is a flow sensor, the infusion hazard is over-infusion, and operation 508 includes performing a self-calibration operation when over-infusion is detected (e.g., 434-436, FIG. 4). In some implementations, the selfcalibration operation includes: detecting a flow rate during the first infusion cycle; comparing the detected flow rate to a predetermined flow rate to determine an over-infusion amount; and recalibrating a motor speed of the infusion pump to reduce the over-infusion amount (e.g., 434-436, FIG. 4).

[0056] In some implementations, while in the diagnostic mode, the infusion pump performs a second infusion cycle using the recalibrated motor speed (e.g., 414, FIG. 4). In some implementations, while the infusion pump is performing the second infusion cycle, the infusion pump determines whether the flow sensor detects a subsequent over-infusion (e.g., 432 “Yes 2nd time,” FIG. 4). In some implementations, the infusion pump provides a notification (e.g., 438, FIG. 4) and disables configuration of the infusion pump for infusion (e.g., 440, FIG. 4) based on a determination that a subsequent over-infusion is detected (e.g., 432 “Yes 2nd time,” FIG. 4). In some implementations, the infusion pump exits the diagnostic mode and is configured to start the infusion based on a determination that a subsequent over-infusion is not detected (e.g., 426-430, FIG. 4).

[0057] In some implementations, the hazard sensor is a pressure sensor, the infusion hazard is an occlusion of the fluid tubing, and operation 508 includes providing a notification when an occlusion is detected (e.g., 420, FIG. 4). In some implementations, the infusion pump provides an instruction for a clinician to remove the fluid tubing for occlusion checking (e.g., 422, FIG. 4), and receives an indication that the fluid tubing has been reinstalled in the infusion pump (e.g., 424, FIG. 4).

[0058] In some implementations, while in the diagnostic mode, the infusion pump performs a second infusion cycle subsequent to receiving the indication that the fluid tubing has been reinstalled (e.g., 414, FIG. 4). In some implementations, while the infusion pump is performing the second infusion cycle, the infusion pump determines whether the pressure sensor detects a subsequent occlusion of the fluid tubing (e.g., 418, FIG. 4). In some implementations, the infusion pump provides a notification (e.g., 420, FIG. 4) and instruction to remove the fluid tubing (e.g., 422, FIG. 4) based on a determination that a subsequent occlusion of the fluid tubing is detected. In some implementations, the infusion pump exits the diagnostic mode and is configured to start the infusion based on a determination that a subsequent occlusion of the fluid tubing is not detected (e.g., 426-430, FIG. 4).

[0059] In some implementations, the hazard sensor is one of a plurality of hazard sensors included in the infusion pump, including a flow sensor and a pressure sensor; and the infusion pump determines whether the flow sensor detects over-infusion while the infusion pump is performing the first infusion cycle (e.g., 432, FIG. 4) and determines whether the pressure sensor detects an occlusion of the fluid tubing while the infusion pump is performing the first infusion cycle (e.g., 418, FIG. 4). In some implementations, the infusion pump performs a self-calibration operation when over-infusion is detected (e.g., 434-436, FIG. 4), provides a notification when an occlusion is detected (e.g., 420-424, FIG. 4), and exits the diagnostic mode and is configured to start the infusion when neither over-infusion nor an occlusion is detected (e.g., 426-430).

[0060] In some implementations, the infusion pump is a peristaltic pump comprising a plurality of finger valves (e.g., 202, 204, 206, 208, FIGS. 2-3); and the first infusion cycle comprises one full cycle of movement of each of the plurality of finger valves (e.g., FIGS. 3A-3D).

[0061] In some implementations, prior to placing the infusion pump in the diagnostic mode, the infusion pump receives an indication that the fluid tubing is not connected to a patient (e.g., 408, FIG. 4). In some implementations, after exiting the diagnostic mode, the infusion pump receives an indication that the fluid tubing is connected to a patient (e.g., 430, FIG. 4). In some implementations, the infusion pump is placed in the diagnostic mode based on receiving the indication that the fluid tubing is not connected to a patient; and the infusion pump is configured to start the infusion based on receiving the indication that the fluid tubing is connected to a patient.

[0062] Many of the above-described example process 500, and related features and applications, may also be implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium), and may be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) 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 drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0063] The term “software” is meant to include, where appropriate, firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some implementations, multiple software aspects of the subject disclosure can be implemented as sub-parts of a larger program while remaining distinct software aspects of the subject disclosure. In some implementations, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software aspect described here is within the scope of the subject disclosure. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs. [0064] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds 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 coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0065] FIG. 6 is a conceptual diagram illustrating an example electronic system 600 for proactively detecting and addressing infusion hazards when operating an infusion pump, according to aspects of the subject technology. Electronic system 600 may be a computing device for execution of software associated with one or more portions or steps of method 500, or components and methods provided by FIGS. 1-5, including but not limited to computing hardware within infusion pump 102 and/or any computing devices or associated terminals disclosed herein. In this regard, electronic system 600 may include the infusion pump 102 and/or a computing device within or connected to the infusion pump 102.

[0066] Electronic system 600 may include various types of computer readable media and interfaces for various other types of computer readable media. In the depicted example, electronic system 600 includes a bus 608, processing unit(s) 612, a system memory 604, a read-only memory (ROM) 610, a permanent storage device 602, input device interface(s) 614, output device interface(s) 606, and network interface(s) 616. In some implementations, electronic system 600 may include or be integrated with other computing devices or circuitry for operation of the various components and methods previously described.

[0067] Bus 608 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 600. For instance, bus 608 communicatively connects processing unit(s) 612 with ROM 610, system memory 604, and permanent storage device 602. [0068] From these various memory units, processing unit(s) 612 retrieves instructions to execute and data to process, in order to execute the processes of the subject disclosure. The processing unit(s) can be a single processor or a multi-core processor in different implementations.

[0069] ROM 610 stores static data and instructions that are needed by processing unit(s) 612 and other modules of the electronic system. Permanent storage device 602, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when electronic system 600 is off. Some implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device 602.

[0070] Other implementations use a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) as permanent storage device 602. Like permanent storage device 602, system memory 604 is a read-and-write memory device. However, unlike storage device 602, system memory 604 is a volatile read-and-write memory, such as random access memory. System memory 604 stores some of the instructions and data that the processor needs at runtime. In some implementations, the processes of the subject disclosure are stored in system memory 604, permanent storage device 602, and/or ROM 610. From these various memory units, processing unit(s) 612 retrieves instructions to execute and data to process, in order to execute the processes of some implementations.

[0071] Bus 608 also connects to input and output device interfaces 614 and 606. Input device interface 614 enables the user to communicate information and select commands to the electronic system. Input devices used with input device interface 614 include, e.g., alphanumeric keyboards and pointing devices (also called “cursor control devices”). Output device interfaces 606 enables, e.g., the display of images generated by the electronic system 600. Output devices used with output device interface 606 include, e.g., printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.

[0072] Also, as shown in FIG. 6, bus 608 also couples electronic system 600 to a network (not shown) through network interfaces 616. Network interfaces 616 may include, e.g., a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. Network interfaces 616 may also include hardware (e.g., Ethernet hardware) for connecting the computer to a part of a network of computers such as a local area network (“LAN”), a wide area network (“WAN”), wireless LAN, or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system 600 can be used in conjunction with the subject disclosure.

[0073] These functions described above can be implemented in computer software, firmware, or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.

[0074] Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (also referred to as computer-readable storage media, machine- readable media, or machine-readable storage media). Some examples of such computer- readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of 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 drives, read-only and recordable Blu- Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media can store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0075] While the above discussion primarily refers to microprocessor 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 that are stored on the circuit itself.

[0076] As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium” and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0077] To provide for interaction with a user, implementations 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, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; e.g., feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; e.g., by sending web pages to a web browser on a user’s client device in response to requests received from the web browser.

[0078] Implementations of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks). [0079] The computing system can include clients and servers. A client and server are generally remote from each other and may interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some implementations, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.

[0080] Those of skill in the art would appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software, depends upon the particular application and design constraints imposed on the overall system. The described functionality may be implemented in varying ways for each particular application. Various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology.

[0081] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0082] Illustration of Subject Technology as Clauses:

[0083] Various examples of aspects of the disclosure are described as numbered clauses (1, 2, 3, etc.) for convenience. These are provided as examples, and do not limit the subject technology. Identifications of the figures and reference numbers are provided below merely as examples and for illustrative purposes, and the clauses are not limited by those identification. [0084] Clause 1 : An infusion pump, comprising: a hazard sensor; and a processor configured to: confirm a fluid tubing is installed in the infusion pump but not connected to a patient; prior to starting an infusion, based on the confirmation, place the infusion pump in a diagnostic mode; while in the diagnostic mode and while the fluid tubing is not connected to the patient, cause the infusion pump to perform a first diagnostic infusion cycle using the fluid tubing; while the infusion pump is performing the first diagnostic infusion cycle, determine whether the hazard sensor detects an infusion hazard based on predetermined criteria for performing the first diagnostic infusion cycle when the fluid tubing is installed in the infusion pump but not connected to the patient; provide a notification or perform a selfcalibration operation when an infusion hazard is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion when an infusion hazard is not detected or is no longer detected.

[0085] Clause 2: The infusion pump of clause 1, wherein: the hazard sensor is a flow sensor; the infusion hazard is over-infusion; and the processor is configured to perform a selfcalibration operation when over-infusion is detected.

[0086] Clause 3 : The infusion pump of clause 2, wherein the self-calibration operation includes: detecting a flow rate during the first infusion cycle; comparing the detected flow rate to a predetermined flow rate to determine an over-infusion amount; and recalibrating a motor speed of the infusion pump to reduce the over-infusion amount.

[0087] Clause 4: The infusion pump of clause 3, wherein the processor is further configured to: while in the diagnostic mode, cause the infusion pump to perform a second infusion cycle using the recalibrated motor speed; while the infusion pump is performing the second infusion cycle, determine whether the flow sensor detects a subsequent over-infusion; provide a notification and disable configuration of the infusion pump for infusion based on a determination that a subsequent over-infusion is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion based on a determination that a subsequent over-infusion is not detected.

[0088] Clause 5: The infusion pump of clause 1, wherein: the hazard sensor is a pressure sensor; the infusion hazard is an occlusion of the fluid tubing; and the processor is configured to provide a notification when an occlusion is detected. [0089] Clause 6: The infusion pump of clause 5, wherein the processor is further configured to: provide an instruction for a clinician to remove the fluid tubing for occlusion checking; and receive an indication that the fluid tubing has been reinstalled in the infusion pump.

[0090] Clause 7: The infusion pump of clause 6, wherein the processor is further configured to: while in the diagnostic mode, cause the infusion pump to perform a second infusion cycle subsequent to receiving the indication that the fluid tubing has been reinstalled; while the infusion pump is performing the second infusion cycle, determine whether the pressure sensor detects a subsequent occlusion of the fluid tubing; provide a notification and instruction to remove the fluid tubing based on a determination that a subsequent occlusion of the fluid tubing is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion based on a determination that a subsequent occlusion of the fluid tubing is not detected.

[0091] Clause 8: The infusion pump of any one of clauses 1-7, wherein: the hazard sensor is one of a plurality of hazard sensors included in the infusion pump, including a flow sensor and a pressure sensor; and the processor is configured to: determine whether the flow sensor detects over-infusion while the infusion pump is performing the first infusion cycle; determine whether the pressure sensor detects an occlusion of the fluid tubing while the infusion pump is performing the first infusion cycle; perform a self-calibration operation when over-infusion is detected; provide a notification when an occlusion is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion when neither overinfusion nor an occlusion is detected.

[0092] Clause 9: The infusion pump of any one of clauses 1-8, wherein: the infusion pump is a peristaltic pump comprising a plurality of finger valves; and the first infusion cycle comprises no more than one full cycle of movement of each of the plurality of finger valves.

[0093] Clause 10: The infusion pump of any one of clauses 1-9, wherein: the processor is further configured to: prior to placing the infusion pump in the diagnostic mode, receive an indication that the fluid tubing is not connected to any patient; place the infusion pump in the diagnostic mode based on receiving the indication that the fluid tubing is not connected to any patient; after exiting the diagnostic mode, receive an indication that the fluid tubing is connected to a patient; and configure the infusion pump to start the infusion based on receiving the indication that the fluid tubing is connected to the patient.

[0094] Clause 11 : A method of operating an infusion pump, the method comprising: at a processor of the infusion pump: confirming a fluid tubing is installed in the infusion pump but not connected to a patient; prior to starting an infusion, placing the infusion pump in a diagnostic mode; while in the diagnostic mode and while the fluid tubing is not connected to the patient, causing the infusion pump to perform a first diagnostic infusion cycle using the fluid tubing; while the infusion pump is performing the first infusion cycle, determining whether a hazard sensor included in the infusion pump detects an infusion hazard based on predetermined criteria for performing the first diagnostic infusion cycle when the fluid tubing is installed in the infusion pump but not connected to the patient; providing a notification or performing a self-calibration operation when an infusion hazard is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion when an infusion hazard is not detected or is no longer detected.

[0095] Clause 12: The method of clause 11, wherein: the hazard sensor is a flow sensor; the infusion hazard is over-infusion; and the method comprises performing a self-calibration operation when over-infusion is detected.

[0096] Clause 13: The method of clause 12, wherein the self-calibration operation includes: detecting a flow rate during the first infusion cycle; comparing the detected flow rate to a predetermined flow rate to determine an over-infusion amount; and recalibrating a motor speed of the infusion pump to reduce the over-infusion amount.

[0097] Clause 14: The method of clause 13, further comprising: while in the diagnostic mode, causing the infusion pump to perform a second infusion cycle using the recalibrated motor speed; while the infusion pump is performing the second infusion cycle, determining whether the flow sensor detects a subsequent over-infusion; providing a notification and disabling configuration of the infusion pump for infusion based on a determination that a subsequent over-infusion is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion based on a determination that a subsequent over-infusion is not detected. [0098] Clause 15: The method of clause 11, wherein: the hazard sensor is a pressure sensor; the infusion hazard is an occlusion of the fluid tubing; and the method comprises providing a notification when an occlusion is detected.

[0099] Clause 16: The method of clause 15, further comprising: providing an instruction for a clinician to remove the fluid tubing for occlusion checking; and receiving an indication that the fluid tubing has been reinstalled in the infusion pump.

[0100] Clause 17: The method of clause 16, further comprising: while in the diagnostic mode, causing the infusion pump to perform a second infusion cycle subsequent to receiving the indication that the fluid tubing has been reinstalled; while the infusion pump is performing the second infusion cycle, determining whether the pressure sensor detects a subsequent occlusion of the fluid tubing; providing a notification and instruction to remove the fluid tubing based on a determination that a subsequent occlusion of the fluid tubing is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion based on a determination that a subsequent occlusion of the fluid tubing is not detected.

[0101] Clause 18: The method of any one of clauses 11-17, wherein: the hazard sensor is one of a plurality of hazard sensors included in the infusion pump, including a flow sensor and a pressure sensor; and the method comprises: determining whether the flow sensor detects over-infusion while the infusion pump is performing the first infusion cycle; determining whether the pressure sensor detects an occlusion of the fluid tubing while the infusion pump is performing the first infusion cycle; performing a self-calibration operation when over-infusion is detected; providing a notification when an occlusion is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion when neither over-infusion nor an occlusion is detected.

[0102] Clause 19: The method of any one of clauses 11-18, wherein: the infusion pump is a peristaltic pump comprising a plurality of finger valves; and the first infusion cycle comprises no more than one full cycle of movement of each of the plurality of finger valves.

[0103] Clause 20: The method of any one of clauses 11-19, further comprising: prior to placing the infusion pump in the diagnostic mode, receiving an indication that the fluid tubing is not connected to any patient, wherein the infusion pump is placed in the diagnostic mode based on receiving the indication that the fluid tubing is not connected to any patient; after exiting the diagnostic mode, receiving an indication that the fluid tubing is connected to a patient, wherein the infusion pump is configured to start the infusion based on receiving the indication that the fluid tubing is connected to the patient.

[0104] Further Consideration:

[0105] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0106] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention described herein.

[0107] The predicate words “configured to”, “operable to”, and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be used interchangeably. For example, a processor configured to monitor and control an operation or a component, may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation. Likewise, a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code.

[0108] The term automatic, as used herein, may include performance by a computer or machine without user intervention; for example, by instructions responsive to a predicate action by the computer or machine or other initiation mechanism. The word “example” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0109] A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “implementation” does not imply that such implementation is essential to the subject technology or that such implementation applies to all configurations of the subject technology. A disclosure relating to an implementation may apply to all implementations, or one or more implementations. An implementation may provide one or more examples. A phrase such as an “implementation” may refer to one or more implementations and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. A phrase such as a “configuration” may refer to one or more configurations and vice versa.

[0110] As used herein a “user interface” (also referred to as an interactive user interface, a graphical user interface or a UI) may refer to a network based interface including data fields and/or other control elements for receiving input signals or providing electronic information and/or for providing information to the user in response to any received input signals. Control elements may include dials, buttons, icons, selectable areas, or other perceivable indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiates an exchange of data for the device presenting the UI. A UI may be implemented in whole or in part using technologies such as hyper-text mark-up language (HTML), FLASH™, JAVA™, .NET™, C, C++, web services, or rich site summary (RSS). In some implementations, a UI may be included in a stand-alone client (for example, thick client, fat client) configured to communicate (e.g., send or receive data) in accordance with one or more of the aspects described. The communication may be to or from a medical device or server in communication therewith. [OHl] As used herein, the terms “determine” or “determining” encompass a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, generating, obtaining, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like via a hardware element without user intervention. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like via a hardware element without user intervention. “Determining” may include resolving, selecting, choosing, establishing, and the like via a hardware element without user intervention.

[0112] As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” may include storing a value in a location of a storage device for subsequent retrieval, transmitting a value directly to the recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, and the like. “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like via a hardware element.

[0113] As used herein, the term “message” encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information. A message may include a machine-readable aggregation of information such as an XML document, fixed field message, comma separated message, JSON, a custom protocol, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.

[0114] As used herein, the term “selectively” or “selective” may encompass a wide variety of actions. For example, a “selective” process may include determining one option from multiple options. A “selective” process may include one or more of: dynamically determined inputs, preconfigured inputs, or user-initiated inputs for making the determination. In some implementations, an n-input switch may be included to provide selective functionality where n is the number of inputs used to make the selection.

[0115] As user herein, the terms “correspond” or “corresponding” encompasses a structural, functional, quantitative and/or qualitative correlation or relationship between two or more objects, data sets, information and/or the like, preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, information and/or the like so to appear to be the same or equal. Correspondence may be assessed using one or more of a threshold, a value range, fuzzy logic, pattern matching, a machine learning assessment model, or combinations thereof.

[0116] In some implementations, data generated or detected can be forwarded to a “remote” device or location, where “remote,” means a location or device other than the location or device at which the program is executed. For example, a remote location could be another location (e.g., office, lab, etc.) in the same city, another location in a different city, another location in a different state, another location in a different country, etc. As such, when one item is indicated as being “remote” from another, what is meant is 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. “Communicating” information references transmitting the data representing that information as electrical signals over a suitable communication channel (e.g., a private or public network). “Forwarding” an item refers to any means of getting that item from one location to the next, whether by physically transporting that item or otherwise (where that is possible) and includes, at least in the case of data, physically transporting a medium carrying the data or communicating the data. Examples of communicating media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the internet or including email transmissions and information recorded on websites and the like.

Claims

CLAIMS What is claimed is:

1. An infusion pump, comprising: a hazard sensor; and a processor configured to: confirm a fluid tubing is installed in the infusion pump but not connected to a patient; prior to starting an infusion, based on the confirmation, place the infusion pump in a diagnostic mode; while in the diagnostic mode and while the fluid tubing is not connected to the patient, cause the infusion pump to perform a first diagnostic infusion cycle using the fluid tubing; while the infusion pump is performing the first diagnostic infusion cycle, determine whether the hazard sensor detects an infusion hazard based on predetermined criteria for performing the first diagnostic infusion cycle when the fluid tubing is installed in the infusion pump but not connected to the patient; provide a notification or perform a self-calibration operation when an infusion hazard is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion when an infusion hazard is not detected or is no longer detected.

2. The infusion pump of claim 1, wherein: the hazard sensor is a flow sensor; the infusion hazard is over-infusion; and the processor is configured to perform a self-calibration operation when over-infusion is detected.

3. The infusion pump of claim 2, wherein the self-calibration operation includes: detecting a flow rate during the first infusion cycle; comparing the detected flow rate to a predetermined flow rate to determine an overinfusion amount; and recalibrating a motor speed of the infusion pump to reduce the over-infusion amount.

4. The infusion pump of claim 3, wherein the processor is further configured to: while in the diagnostic mode, cause the infusion pump to perform a second infusion cycle using the recalibrated motor speed; while the infusion pump is performing the second infusion cycle, determine whether the flow sensor detects a subsequent over-infusion; provide a notification and disable configuration of the infusion pump for infusion based on a determination that a subsequent over-infusion is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion based on a determination that a subsequent over-infusion is not detected.

5. The infusion pump of claim 1, wherein: the hazard sensor is a pressure sensor; the infusion hazard is an occlusion of the fluid tubing; and the processor is configured to provide a notification when an occlusion is detected.

6. The infusion pump of claim 5, wherein the processor is further configured to: provide an instruction for a clinician to remove the fluid tubing for occlusion checking; and receive an indication that the fluid tubing has been reinstalled in the infusion pump.

7. The infusion pump of claim 6, wherein the processor is further configured to: while in the diagnostic mode, cause the infusion pump to perform a second infusion cycle subsequent to receiving the indication that the fluid tubing has been reinstalled; while the infusion pump is performing the second infusion cycle, determine whether the pressure sensor detects a subsequent occlusion of the fluid tubing; provide a notification and instruction to remove the fluid tubing based on a determination that a subsequent occlusion of the fluid tubing is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion based on a determination that a subsequent occlusion of the fluid tubing is not detected.

8. The infusion pump of any one of claims 1-7, wherein: the hazard sensor is one of a plurality of hazard sensors included in the infusion pump, including a flow sensor and a pressure sensor; and the processor is configured to: determine whether the flow sensor detects over-infusion while the infusion pump is performing the first infusion cycle; determine whether the pressure sensor detects an occlusion of the fluid tubing while the infusion pump is performing the first infusion cycle; perform a self-calibration operation when over-infusion is detected; provide a notification when an occlusion is detected; and exit the diagnostic mode and configure the infusion pump to start the infusion when neither over-infusion nor an occlusion is detected.

9. The infusion pump of any one of claims 1-8, wherein: the infusion pump is a peristaltic pump comprising a plurality of finger valves; and the first infusion cycle comprises no more than one full cycle of movement of each of the plurality of finger valves.

10. The infusion pump of any one of claims 1-9, wherein: the processor is further configured to: prior to placing the infusion pump in the diagnostic mode, receive an indication that the fluid tubing is not connected to any patient; place the infusion pump in the diagnostic mode based on receiving the indication that the fluid tubing is not connected to any patient; and after exiting the diagnostic mode: receive an indication that the fluid tubing is connected to a patient; and configure the infusion pump to start the infusion based on receiving the indication that the fluid tubing is connected to the patient.

11. A method of operating an infusion pump, the method comprising: at a processor of the infusion pump: confirming a fluid tubing is installed in the infusion pump but not connected to a patient; prior to starting an infusion, placing the infusion pump in a diagnostic mode; while in the diagnostic mode and while the fluid tubing is not connected to the patient, causing the infusion pump to perform a first diagnostic infusion cycle using the fluid tubing; while the infusion pump is performing the first infusion cycle, determining whether a hazard sensor included in the infusion pump detects an infusion hazard based on predetermined criteria for performing the first diagnostic infusion cycle when the fluid tubing is installed in the infusion pump but not connected to the patient; providing a notification or performing a self-calibration operation when an infusion hazard is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion when an infusion hazard is not detected or is no longer detected.

12. The method of claim 11, wherein: the hazard sensor is a flow sensor; the infusion hazard is over-infusion; and the method comprises performing a self-calibration operation when over-infusion is detected.

13. The method of claim 12, wherein the self-calibration operation includes: detecting a flow rate during the first infusion cycle; comparing the detected flow rate to a predetermined flow rate to determine an overinfusion amount; and recalibrating a motor speed of the infusion pump to reduce the over-infusion amount.

14. The method of claim 13, further comprising: while in the diagnostic mode, causing the infusion pump to perform a second infusion cycle using the recalibrated motor speed; while the infusion pump is performing the second infusion cycle, determining whether the flow sensor detects a subsequent over-infusion; providing a notification and disabling configuration of the infusion pump for infusion based on a determination that a subsequent over-infusion is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion based on a determination that a subsequent over-infusion is not detected.

15. The method of claim 11, wherein: the hazard sensor is a pressure sensor; the infusion hazard is an occlusion of the fluid tubing; and the method comprises providing a notification when an occlusion is detected.

16. The method of claim 15, further comprising: providing an instruction for a clinician to remove the fluid tubing for occlusion checking; and receiving an indication that the fluid tubing has been reinstalled in the infusion pump.

17. The method of claim 16, further comprising: while in the diagnostic mode, causing the infusion pump to perform a second infusion cycle subsequent to receiving the indication that the fluid tubing has been reinstalled; while the infusion pump is performing the second infusion cycle, determining whether the pressure sensor detects a subsequent occlusion of the fluid tubing; providing a notification and instruction to remove the fluid tubing based on a determination that a subsequent occlusion of the fluid tubing is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion based on a determination that a subsequent occlusion of the fluid tubing is not detected.

18. The method of any one of claims 11-17, wherein: the hazard sensor is one of a plurality of hazard sensors included in the infusion pump, including a flow sensor and a pressure sensor; and the method further comprises: determining whether the flow sensor detects over-infusion while the infusion pump is performing the first infusion cycle; determining whether the pressure sensor detects an occlusion of the fluid tubing while the infusion pump is performing the first infusion cycle; performing a self-calibration operation when over-infusion is detected; providing a notification when an occlusion is detected; and exiting the diagnostic mode and configuring the infusion pump to start the infusion when neither over-infusion nor an occlusion is detected.

19. The method of any one of claims 11-18, wherein: the infusion pump is a peristaltic pump comprising a plurality of finger valves; and the first infusion cycle comprises no more than one full cycle of movement of each of the plurality of finger valves.

20. The method of any one of claims 11-19, further comprising: prior to placing the infusion pump in the diagnostic mode, receiving an indication that the fluid tubing is not connected to any patient, wherein the infusion pump is placed in the diagnostic mode based on receiving the indication that the fluid tubing is not connected to any patient; and after exiting the diagnostic mode, receiving an indication that the fluid tubing is connected to a patient, wherein the infusion pump is configured to start the infusion based on receiving the indication that the fluid tubing is connected to the patient.