Patent Description:
Preferable embodiments are further laid out in the dependent claims. According to various aspects of the subject technology, a method includes providing an infusion pump with one or more occluder valves comprising a lower occluder valve, the lower occluder valve configured to, when activated, cause a compression of a fluid tubing loaded into the infusion pump, the compression fluidically isolating a downstream portion of the fluid tubing from an upstream portion of the fluid tubing when the lower occluder valve is operating under a normal operating condition; placing the infusion pump in a default mode in which the lower occluder valve is activated; while in the default mode and the lower occluder valve is activated, with a lower pressure sensor, monitoring a pressure within the fluid tubing for a threshold deviation from an expected pressure; determining, before receiving an indication to start an infusion of a fluid through the fluid tubing, whether the threshold deviation was detected; configuring the infusion pump to start the infusion when the indication is received after the threshold deviation is detected; and providing a notification without starting the infusion when the indication is received and the threshold deviation is not detected. Other aspects include corresponding systems, apparatus, and computer program products for implementation of the corresponding method and its features.

According to various aspects of the subject technology, an infusion pump includes one or more occluder valves comprising a lower occluder valve, the lower occluder valve configured to, when activated, cause a compression of a fluid tubing loaded into the infusion pump, the compression fluidically isolating a downstream portion of the fluid tubing from an upstream portion of the fluid tubing when the lower occluder valve is operating under a normal operating condition; a lower pressure sensor downstream of the lower occluder valve; a processor configured to: place the infusion pump in a default mode in which the lower occluder valve is activated; while in the default mode and the lower occluder valve is activated, with the lower pressure sensor, monitor a pressure within the fluid tubing for a threshold deviation from an expected pressure; determine, before receiving an indication to start an infusion of a fluid through the fluid tubing, whether the threshold deviation was detected; configure the infusion pump to start the infusion when the indication is received after the threshold deviation is detected; and provide a notification without starting the infusion when the indication is received and the threshold deviation is not detected. Other aspects include corresponding systems, methods, and computer program products for implementation of the corresponding infusion pump.

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

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.

<FIG> depicts an example infusion pump set-up <NUM>, shown in use in its intended environment, according to various aspects of the subject technology. In particular, the infusion pump set-up <NUM> is shown mounted to an intravenous (IV) pole <NUM> on which a fluid source <NUM> containing an IV fluid is held. The fluid source <NUM> is connected in fluid communication with an upstream fluid line <NUM>. The fluid line <NUM> is a conventional IV infusion type tube typically used in a hospital or medical environment, and is made of any type of flexible tubing appropriate for use to infuse therapeutic fluids into a patient, such as polyvinylchloride (PVC). A flexible pumping fluid line <NUM> is mounted in operative engagement with a peristaltic pumping apparatus <NUM>, for propelling fluid through a downstream fluid line <NUM>, for example, to a patient's arm <NUM>.

It will be understood by those skilled in the art that the upstream fluid line <NUM>, the flexible line <NUM>, and the downstream fluid line <NUM> may be portions of a continuous length of flexible tubing, with the portions defined by the location of the peristaltic pump <NUM>. For convenience, the continuous length of flexible tubing is indicated by numeral <NUM>. A roller clamp <NUM> (e.g., configured to provide for mechanical compression of the line to block the flow) may be positioned on the downstream fluid line <NUM> between the pump <NUM> and the patient's arm <NUM>. In this context, the term "upstream" refers to that portion of the flexible tubing that extends between the fluid source and peristaltic pump, and the term "downstream" refers to that portion of the flexible tubing that extends from the peristaltic pump to the patient.

Also shown in <FIG> is a secondary administration setup generally indicated by numeral <NUM>. The secondary administration setup <NUM> includes a secondary fluid container <NUM> that may be filled with a second therapeutic fluid for infusion into the patient <NUM>. Fluid from the secondary fluid container <NUM> flows through a secondary fluid line <NUM> into the fluid line <NUM> through a connector <NUM>. A manually operated valve <NUM> is located in the secondary line <NUM> to control the flow of fluid flowing out of the secondary container <NUM> into the upstream fluid line <NUM>. The one-way check valve <NUM> is disposed in the upstream fluid line <NUM> between the primary fluid container <NUM> and the connector <NUM>, the one-way check valve is configured so that when the elevation of the fluid in the secondary container <NUM> is greater than that of the primary container, the differential pressure within line <NUM> closes the check valve and prevents secondary fluid from flowing into the primary container <NUM>, and also prevents fluid from flowing out of primary container <NUM>. Thus, the check valve <NUM> generally prevents mixing of the primary and secondary infusion fluids.

Turning now to <FIG>, an infusion pump <NUM> is shown in perspective view with the front door <NUM> open, showing the upstream fluid line <NUM> and downstream fluid line <NUM> in operative engagement with the pump <NUM>. The infusion pump <NUM> directly acts on a tube <NUM> that connects the upstream fluid line <NUM> to the downstream fluid line <NUM> to form a continuous fluid conduit, extending from the respective fluid supply <NUM> and/or <NUM> (<FIG>) to the patient <NUM>, <NUM>, through which fluid is acted upon by the pump to move fluid downstream to the patient. Specifically, a pumping mechanism <NUM> acts as the flow control device of the pump to move fluid though the conduit. The upstream and downstream fluid lines and/or tube <NUM> may be coupled to a pump cassette or cartridge that is configured to be coupled to the pump <NUM>, such <CIT> as the type described in co-pending <CIT>.

The type of pumping mechanism may vary and may be for example, a multiple finger pumping mechanism. For example, the pumping mechanism may be of the "four finger" type and includes an upstream occluding finger <NUM>, a primary pumping finger <NUM>, a downstream occluding finger <NUM>, and a secondary pumping finger <NUM>. The "four finger" pumping mechanism and mechanisms used in other linear peristaltic pumps operate by sequentially pressing on a segment of the fluid conduit by means of the cam-following pumping fingers and valve fingers <NUM>, <NUM>, <NUM>, and <NUM>. The pressure is applied in sequential locations of the conduit, 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 conduit. As a practical matter, one finger does not retract from occluding the tubing until the next one in sequence has already occluded the tubing; thus, at no time is there a direct fluid path from the fluid supply to the patient. The operation of peristaltic pumps including four finger pumps is well known to those skilled in the art and no further operational details are provided here. In this particular embodiment, <FIG> further shows a downstream pressure sensor <NUM> included in the pump <NUM> embodiment at a downstream location with respect to the pumping mechanism. The downstream pressure sensor <NUM> is mounted to the flow control device <NUM> and is located adjacent and downstream in relation to the flow control device. The downstream pressure sensor is located downstream from the flow control device, that is, at a location between the patient <NUM> (<FIG>) and the flow control device, so that the connection of the correct fluid supply with the correct pump may be verified before any fluid is pumped to the patient.

With reference still to <FIG>, an upstream pressure sensor <NUM> may also be included in the pump <NUM>. The upstream pressure sensor is assigned to the flow control device or pumping mechanism <NUM> and, in this example, is further provided as an integral part of the pump <NUM>. It is mounted to the flow control device <NUM> and is located adjacent and upstream in relation to the flow control device. The upstream pressure sensor is located upstream from the flow control device, that is, at a location between the fluid supply <NUM> and/or <NUM> (<FIG>) and the flow control device, so that the connection of the correct fluid supply with the correct pump may be verified before any fluid is pumped to the patient.

<FIG> depicts an example configuration of a pump <NUM> in a home position, according to various aspects of the subject technology. Before an infusion is started, when the pump is powered on, the occluders and the fingers of the pump are reset to default positions before the pump starts. In some implementations, these 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 elements are in their default positions the pump said to be in the "home" position. The home position is defined as the upper occluder being open, the upper finger being half open (e.g., between open and close), the lower occluder is closed (or shut), and the lower finger is half open.

Before an infusion is started, the clinician will typically connect (e.g., spike) the medication bag with a new administration set, at least partially fill a drip chamber, open the roller clamp, and prime the IV line. The clinician uses the roller clamp to control the priming rate, ensuring minimal spillage, and holds the distal end of the set with the other hand. Typically, the clinician closes the roller clamp once the administration set is fully primed. The clinician may then load the set into the pump and start programming the pump. During this step, the pump may be in the home position. The clinician may the open the roller clamp <NUM> and start the infusion. When the roller clamp is opened, fluid begins to move.

According to various implementations, a pump is programmed to detect upstream or downstream occlusions by way of its pressure sensors <NUM>, <NUM>, and to display and/or sound an alert when the occlusion is detected. In some instances, a downstream occlusion alarm may occur if the clinician forgets to open the roller clamp before starting the infusion.

The subject technology provides a hardware-software mechanism that prevents unnecessary alarms by guiding the clinician through a workflow when starting an infusion. In this regard, the subject technology prevents unnecessary downstream occlusion alarms due to, for example, the failure to open a roller clamp.

Before the infusion is started, when a clinician opens the roller clamp, there will be an occlusion in the line because the lower occluder is closed. A backpressure may pump fluid upwards against the closed lower occluder. This backpressure will cause a deviation in a signal seen by the downstream pressure sensor that is greater than a slope of an expected signal (which may be negligible).

<FIG> depicts an example pressure signal response that deviates from an expected response, according to aspects of the subject technology. In various implementations, the downstream pressure sensor <NUM> of the pump provides a signal representative of a pressure within the tubing. When there is an occlusion in the line, the signal may exhibit a force spike <NUM> because the fluid has nowhere to go and so the tubing here expands, and a pressure is created in the tube. The pressure sensor <NUM> will see a voltage spike <NUM>, as depicted in <FIG>. The spike is indicative of everything is working correctly. If the spike is not detected, then the pump may provide an alarm or prevent further operations until the roller clamp <NUM> is opened. Accordingly, the pump <NUM> may utilize the roller clamp pressure profile (which originates from the roller clamp outside the pump) to detect whether it is ok to start an infusion.

The downstream (and upstream) pressure sensor may (e.g., when the infusion pump is turned on and/or activated), constantly monitor pressure within the infusion line <NUM> and translate the measured pressure reading to a voltage. This voltage is then provided (e.g., by analog-digital converters within the pump) to a processor. The processor may then determine whether the force spike occurred based on whether the voltage value readings received satisfy a threshold. In some implementations, the threshold is a (positive or negative) threshold voltage which must be exceeded. In some implementations, the processor monitors readings for a moving window of time. Satisfaction of the threshold may include, for example, an average or mean of the 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.

In some implementations, the force deviating from an expected result may include detecting a (e.g. large) positive or negative slope in the measured values that is greater than an expected slope. The processor may continuously determine a slope of the voltage readings (e.g., within the window), and the threshold is a threshold slope that, when met and/or exceeded, triggers detection of the force spike. In some implementations, determination of the slope involves a <NUM>-point slope calculation. The slope may be negative or positive.

In various implementations of the subject technology, if the pump doesn't see this force spike before an infusion happens, then the pump may determine that the clinician forgot to open the roller clamp. In other words, the pump monitors the pressure sensor for the signal, expecting to see the voltage spike, and if it does not detect the spike before the clinician when the infusion is started then the pump provides an alarm and/or displays a warning message.

The clinician loads the set into the pump and closes the door. Once the door closes, the detection algorithm activates and begins to constantly monitor for the force spike. A potential occlusion hazard arises when the clinician does not open the roller clamp, yet starts the pump. In this regard, the active compression by the roller clamp on the downstream fluid line <NUM> may cause an occlusion, thereby preventing the fluid within the tube to flow and further causing the infusion pump to trigger an alarm and/or terminate the infusion.

The downstream pressure sensor <NUM>, used to determine whether the roller clamp was properly opened, may also be used to determine whether the lower occluder is properly functioning. A leaking occluder valve may lead to an over infusion of the medication. There is a need to verify the proper operation of LVP Infusion pumps with regards to leakage of the occluder valves in pumps. Accordingly, the hardware-software mechanism of the subject technology also identifies whether the lower occluder valve is leaking.

When the infusion device is in the home position, the lower occluder is supposed to be closed which creates the previously described occlusion. However, if there is damage on this lower occluder then the force spike may not be detected. The springs which force the lower occluder downward against the tubing may wear out to the extent that the lower occluder may not close all the way. In an extreme case, if the lower occluder you know doesn't close at all, for example because it is completely broken and doesn't close at all, then no force spike will be detected. Instead, the pressure sensor will measure a (relatively) flat line <NUM>, such as that depicted in <FIG>.

If the lower occluder is broken, then some of the pressure force may trigger an upper force spike at the upstream pressure sensor <NUM>. In this regard, in some implementations, the processor may (e.g., continuously) measure both the upstream pressure sensor <NUM> and the downstream pressure sensor <NUM>. The measurements may be compared, for example, by subtracting one reading from the other to see if the foregoing threshold has been reached. In some implementations, an upper force spike detected by the upper pressure sensor <NUM> may be indicative of a problem with the lower (closed) occluder, regardless of whether a spike is seen at the lower pressure sensor <NUM>. In one example, if an upstream spike is detected but not a downstream spike, the processor may provide an alert for display on the infusion device to check the downstream occluder.

<FIG> depicts an example configuration of a pump <NUM> in a maintenance position, according to various aspects of the subject technology. In some implementations, the pump <NUM> may include a control to switch the pump into a maintenance mode. This control may be made available to authorized individuals for maintenance of the pump <NUM>. In this mode, a further control may allow a technician to switch the occluder positions. For example, the upper occluder may close and the lower occluder may open, as depicted in <FIG>.

During a maintenance check, the fluid tubing <NUM> may be primed with fluid, the roller clamp closed, and the pump switched into maintenance mode. Then the processor of the pump may begin monitoring for a lower force spike, as previously described above. Additionally, or in the alternative, the occluder positions may be switched, and the roller clamp may be opened to determine whether a force spike is detected by the upper pressure sensor <NUM>. If the upper force spike is detected, then an alert may be provided indicating to check the upper occluder and/or that the upper occluder may be damaged or defective.

<FIG> depicts an example maintenance workflow for diagnosing an infusion pump <NUM> and/or its occluders, according to various aspects of the subject technology. A pump maintenance technician loads an administration set into the pump <NUM> and closes the door <NUM>. The pump is then set to the maintenance mode, as described with regard to <FIG>. The detection algorithm activates upon the set being loaded and the door closure. The technician then proceeds to open the roller clamp <NUM>. If the processor (and algorithm) detects the force spike then the occluder may be presumed to be functioning correctly, and a notification may be displayed to indicate normal operation. If the processor does not detect the force spike, then an alert may be displayed that the occluder is faulty. The technician may then proceed to configure the pump, as described with regard to <FIG>, to test the other occluder.

<FIG> and <FIG> depict a example clinician workflows for preventing hazardous operation of an infusion pump <NUM>, according to various aspects of the subject technology. In the depicted example, the clinician loads a fluid administration set into the pump <NUM> and closes the door <NUM>. The processor activates the detection algorithm upon the set being loaded and/or the door being closed. If the clinician does not open the roller clamp <NUM> before the infusion is started then, as described previously, a force spike will not be detected. In some implementations, a warning message will be displayed on the clinician starting the infusion pump <NUM> (e.g., when the clinician presses the start button).

The warning message may include asking whether the roller clamp <NUM> was opened. If the clinician confirms that the roller clamp <NUM> was not opened (remains closed) then the pump <NUM> may instruct the clinician to open the roller clamp and restart the infusion. If the clinician confirms that the roller clamp was indeed opened, and a force spike has not been detected then the pump <NUM> may display a message asking whether the administration set was loaded properly. If the clinician answers that the administration set was not loaded properly then the pump <NUM> may request reloading of the set and the process may restart. Additionally, or in the alternative, the pump <NUM> may recycle the prompts as depicted in <FIG>.

If the clinician confirms proper loading of the set and a force spike is still not detected, then the pump <NUM> may determine that the lower occluder valve is not functioning correctly. A message may be displayed by the pump <NUM> that there is a potential issue with the lower occluder and instruct the clinician to replace the pump or flag it for maintenance.

<FIG> depicts an example process <NUM> for preventing hazardous operation of an infusion pump, according to aspects of the subject technology. For explanatory purposes, the various blocks of example process <NUM> are described herein with reference to <FIG>, and the components and/or processes described herein. The one or more of the blocks of process <NUM> may be implemented, for example, by one or more computing devices including, for example, pump <NUM>. In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms. 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 <NUM> are described as occurring in serial, or linearly. However, multiple blocks of example process <NUM> may occur in parallel. In addition, the blocks of example process <NUM> need not be performed in the order shown and/or one or more of the blocks of example process <NUM> need not be performed.

An infusion pump is provided with one or more occluder valves comprising a lower occluder valve. The lower occluder valve is configured to, when activated, cause a compression of a fluid tubing loaded into the infusion pump. When the pump element is operating under a normal operating condition, the compression fluidically isolates a downstream portion of the fluid tubing from an upstream portion of the fluid tubing.

In the depicted example, the infusion pump is placed in a default mode in which the lower occluder valve is activated (<NUM>). While in the default mode and the lower occluder valve is activated, with a lower pressure sensor <NUM>, the processor monitors a pressure within the fluid tubing for a threshold deviation from an expected pressure (<NUM>). As described previously, the processor may be monitoring to detect a force spike in the signal provided from the lower pressure sensor <NUM> (a "lower force spike").

With brief reference to <FIG>, the lower pressure sensor <NUM> is downstream of the lower occluder valve. As described previously, the force spike may be caused by opening a roller clamp downstream of the infusion pump to open a fluid path between the infusion pump and a patient to which the fluid tubing is fluidically connected for infusion of a fluid by the infusion pump. In this regard, the opening of the roller clamp may occur after the fluid tubing has been primed with the fluid prior to prior to the infusion pump being placed in the default mode.

The processor determines, before receiving an indication to start an infusion of a fluid through the fluid tubing, whether the lower force spike was detected (<NUM>). This determination may be made on activation of an infusion start control or, in some implementations, the start control may be provided upon the fore spike being detected. According to various implementations, the lower force spike may include a voltage spike in a plurality of voltage readings over a period of time. For example, the upper and lower pressure sensors <NUM>, <NUM> may continuously monitor pressure and the voltage readings may be values measured within a moving window of time.

The processor then configures the infusion pump to start the infusion when the lower force spike is detected (<NUM>), and provides a notification without starting the infusion when the lower force spike is not detected (<NUM>). Accordingly, hazardous operation of an infusion pump is prevented.

In some implementations, a slope of the voltage readings is determined (e.g., in the moving window) and if the slope satisfies a threshold slope then a force spike is determined to occur. In some implementations, a force spike is determined to occur when at least one reading of the plurality of the voltage readings satisfies a threshold voltage.

In some implementations, the processor receives the indication to start the infusion of the fluid through the fluid tubing and configures the infusion pump to start the infusion based on receiving the indication. In some implementations, configuring the infusion pump to start the infusion may include, for example, presenting, for display on a display screen associated with the infusion pump, a graphical start control that, when activated, causes the infusion to start, wherein the graphical start control is not displayed until the lower force spike is detected. For example, the pump <NUM> may hid the option to start until the pump detects the spike. At that point a soft key may be presented on the pump for initiating the infusion programmed into the pump.

In some implementations, the notification instructs a user to check a roller clamp coupled to the fluid tubing, for example, to see whether the roller clamp is the cause of an occlusion in the tubing. The processor may then receive an indication (e.g., from a user via the pump's input) that the roller clamp is open. In some instances, particularly when a force spike has not been detected, the confirmation may provide an indication that the roller clamp is not the issue. The pump may then request that the user check placement of the fluid tubing in the infusion pump. Upon receiving confirmation of the placement of the fluid tubing (e.g., that it is correctly loaded in the pump), the processor may provide an alert regarding the lower occluder valve. For example, the pump may indicate that the lower occluder valve may be faulty, and the pump should be serviced. In some implementations, the pump is locked and prevented from being serviced until it is authorized to return to service by a maintenance technician.

In some implementations, while in the default mode, the processor (e.g., executing the algorithm) may also monitor an upper pressure sensor <NUM> of the infusion device for an upper force spike. In this regard, the upper pressure sensor <NUM> may be positioned upstream of an upper occluder valve. The processor determines, based on receiving the indication to start the infusion, whether the upper force spike was detected. If the upper force spike is detected, then an indication may be provided that the lower occluder valve is not functioning. This is because, in the default mode, the lower occluder valve is supposed to be closed while the upper occluder valve is expected to be open. If the lower occluder valve is faulty and cannot fully compress the tubing, then the fluid may backflow to and past the upper occluder valve where it may be detected by the upper pressure sensor <NUM>.

As described previously, the infusion pump <NUM> may include a maintenance mode. Upon receiving an indication to enter a maintenance mode, the lower occluder valve may be deactivated while an upper occluder of the one or more occluder valves is activated. Under normal circumstances, the upper occluder being activated causes a compression of the fluid tubing at the upper occluder. The process <NUM> continues by the processor receiving an indication that the fluid tubing is primed with the fluid. This may be by way of a clinician confirming the priming via an input on the pump. Additionally, or in the alternative, the pump <NUM> may include a control for initiating the priming which, when activated, performs the priming and includes the indication. In the same manner, the pump <NUM> may receive an indication that a roller clamp downstream of the pump is opened. After the roller clamp is opened, the pump <NUM> may determine whether an upper force spike is detected by the upper pressure sensor <NUM>, upstream of the upper occluder, and provide a notification regarding failure of the upstream occluder valve when the upper force spike is detected.

Many of the above-described example process <NUM>, 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.

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.

<FIG> is a conceptual diagram illustrating an example electronic system <NUM> for preventing hazardous operation of an infusion pump, according to aspects of the subject technology. Electronic system <NUM> may be a computing device for execution of software associated with one or more portions or steps of method <NUM>, or components and methods provided by <FIG>, including but not limited to computing hardware within patient care device <NUM>, or syringe pump <NUM>, and/or any computing devices or associated terminals disclosed herein. In this regard, electronic system <NUM> may include the infusion pump <NUM>, a computing device within or connected to the infusion pump <NUM>.

Electronic system <NUM> may include various types of computer readable media and interfaces for various other types of computer readable media. In the depicted example, electronic system <NUM> includes a bus <NUM>, processing unit(s) <NUM>, a system memory <NUM>, a read-only memory (ROM) <NUM>, a permanent storage device <NUM>, an input device interface <NUM>, an output device interface <NUM>, and one or more network interfaces <NUM>. In some implementations, electronic system <NUM> may include or be integrated with other computing devices or circuitry for operation of the various components and methods previously described.

Bus <NUM> collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system <NUM>. For instance, bus <NUM> communicatively connects processing unit(s) <NUM> with ROM <NUM>, system memory <NUM>, and permanent storage device <NUM>.

From these various memory units, processing unit(s) <NUM> 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.

ROM <NUM> stores static data and instructions that are needed by processing unit(s) <NUM> and other modules of the electronic system. Permanent storage device <NUM>, 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 <NUM> 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 <NUM>.

Other implementations use a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) as permanent storage device <NUM>. Like permanent storage device <NUM>, system memory <NUM> is a read-and-write memory device. However, unlike storage device <NUM>, system memory <NUM> is a volatile read-and-write memory, such as random access memory. System memory <NUM> 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 <NUM>, permanent storage device <NUM>, and/or ROM <NUM>. From these various memory units, processing unit(s) <NUM> retrieves instructions to execute and data to process, in order to execute the processes of some implementations.

Bus <NUM> also connects to input and output device interfaces <NUM> and <NUM>. Input device interface <NUM> enables the user to communicate information and select commands to the electronic system. Input devices used with input device interface <NUM> include, e.g., alphanumeric keyboards and pointing devices (also called "cursor control devices"). Output device interfaces <NUM> enables, e.g., the display of images generated by the electronic system <NUM>. Output devices used with output device interface <NUM> 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.

Also, as shown in <FIG>, bus <NUM> also couples electronic system <NUM> to a network (not shown) through network interfaces <NUM>. Network interfaces <NUM> 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 <NUM> 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 <NUM> can be used in conjunction with the subject disclosure.

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.

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.

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.

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.

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.

A client and server are generally remote from each other and may interact through a communication network. 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).

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.

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.

The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. 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.

Headings and subheadings, if any, are used for convenience only.

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.

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.

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" may refer to one or more configurations and vice versa.

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.

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.

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.

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.

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.

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.

Claim 1:
A non-transitory machine-readable storage medium storing instructions thereon that, when executed by one or more processing units, perform a process, comprising:
operating an infusion pump (<NUM>) with one or more occluder valves comprising a lower occluder valve, the lower occluder valve configured to, when activated, cause a compression of a fluid tubing (<NUM>) loaded into the infusion pump (<NUM>), the compression fluidically isolating a downstream portion of the fluid tubing from an upstream portion of the fluid tubing when the lower occluder valve is operating under a normal operating condition;
placing the infusion pump (<NUM>) in a default mode in which the lower occluder valve is activated;
while in the default mode and the lower occluder valve is activated, with a lower pressure sensor (<NUM>), monitoring a pressure within the fluid tubing for a threshold deviation from an expected pressure;
determining, before receiving an indication to start an infusion of a fluid through the fluid tubing (<NUM>), whether the threshold deviation was detected;
configuring the infusion pump (<NUM>) to start the infusion when the indication is received after the threshold deviation is detected; and
providing a notification without starting the infusion when the indication is received and the threshold deviation is not detected.