Devices, methods, and systems for accurate delivery irrigation infusion

Abstract

The syringe pump, upon receiving a new syringe, determines that at least a first portion of the predetermined amount of the first fluid has been previously delivered by the syringe pump according to the first fluid delivery order before the new syringe is loaded into the syringe pump, and determine a second portion of the remaining first fluid to be delivered of the predetermined amount of first fluid to be completed for the first fluid delivery order. Delivery of the second fluid is initiated by the syringe pump, and when an amount of second fluid delivered from a new syringe satisfies a second portion of the remaining first fluid to be delivered, the pump automatically indicates the first fluid delivery order as complete without user intervention, disassociates the first fluid delivery order from the syringe pump, and when the amount of second fluid delivered from the new syringe satisfies the remaining second portion of the first fluid to be delivered. And associating the syringe pump with the second fluid delivery order.

Description

Technical Field

[0001] The present disclosure generally relates to drug delivery and irrigation from a syringe pump. Background Art

[0002] In many cases, the infusion of medical fluids (such as parenteral fluids) into human body is accomplished by means of a syringe pump in which a syringe containing parenteral fluids is installed. Syringe pumps typically fix barrels in fixed positions, and utilize a driving head to push plungers or "drive" into barrels to discharge fluids at a controlled rate. When administering medicines to a patient by a syringe, once the pump has pressed plungers to the bottom of the syringe barrel, further pressure can not be applied. However, there may still be medicines in the infusion pipeline that need to be delivered to the patient. Typically, a syringe loaded with flushing fluid (such as saline) will be used to administer the second infusion from the same pump. When flushing fluid is pumped into the pipeline, any residual medicine from the first syringe will be delivered to the patient. Summary of the invention

[0003] The subject technology provides an infusion system, including: a syringe pump including a reservoir for receiving a syringe; one or more sensors configured to generate sensor data related to the syringe within the reservoir of the syringe pump; and one or more processors configured to execute instructions and perform operations, including: receiving an indication that a new syringe is loaded into the syringe pump based on the sensor data; determining, upon receiving the indication, based on electronically stored information associated with the syringe pump, that the syringe pump is currently associated with a first fluid delivery order for a predetermined amount of a first fluid, and determining that at least a first portion of the first fluid has been previously delivered by the syringe pump according to the first fluid delivery order before the new syringe is loaded into the syringe pump; determining that a second portion of the first fluid remains to be delivered to complete the predetermined amount of the first fluid for the first fluid delivery order; initiating, by the syringe pump, delivery of the second fluid from the new syringe according to the second fluid delivery order; and automatically, without user intervention, when the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered: electronically indicating the first fluid delivery order as completed, disassociating the first fluid delivery order from the syringe pump, and associating the syringe pump with the second fluid delivery order. Other aspects include corresponding methods, apparatus, and computer program products for implementing corresponding systems and features thereof.

[0004] A machine-implemented method includes: receiving an indication from one or more sensors associated with a syringe pump that a new syringe is loaded into the syringe pump; upon receiving the indication, determining based on electronically stored information associated with the syringe pump that the syringe pump is currently associated with a first fluid delivery order for a predetermined amount of a first fluid, and determining that at least a first portion of the first fluid has been previously delivered by the syringe pump in accordance with the first fluid delivery order before the new syringe is loaded into the syringe pump; determining a second portion of the first fluid remaining to be delivered to complete the predetermined amount of the first fluid for the first fluid delivery order; initiating delivery of the second fluid from the new syringe by the syringe pump in accordance with the second fluid delivery order; and when the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, automatically and without user intervention: electronically indicating the first fluid delivery order as completed, disassociating the first fluid delivery order from the syringe pump, and associating the syringe pump with the second fluid delivery order. Other aspects include corresponding systems, apparatus, and computer program products for implementing corresponding methods and features thereof.

[0005] Although the method and system disclosed herein are described about syringe pumps, the subject technology is applicable to all infusion pumps. For example, these methods can detect whether the container volume of the supply infusion fluid (such as medicine) is empty. It is understood that other configurations of the subject technology will easily become apparent to those skilled in the art from the following detailed description, wherein the various configurations of the subject technology are shown and described by way of illustration. As will be appreciated, the subject technology can have other and different configurations and several of its details can be modified in various other aspects, all of which do not deviate from the scope of the subject technology. Therefore, the accompanying drawings and detailed description should be considered to be illustrative in nature and not to be restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] For a better understanding of the various described embodiments, reference should be made to the following description of the embodiments in conjunction with the following drawings. Throughout the drawings and description, like reference numerals refer to corresponding parts.

[0007] Figure 1A An example patient care system including a syringe pump mounted to a control unit in accordance with various aspects of the subject technology is depicted.

[0008] Figure 1B Described are various aspects of the subject technology for use in Figure 1A A first example syringe pump is used in a patient care system.

[0009] Figure 2 A second example syringe pump in accordance with various aspects of the subject technology is depicted.

[0010] Figure 3 An example of an institutional patient care system for a healthcare organization in accordance with aspects of the subject technology is depicted.

[0011] Figure 4 Example systems for automatically programming medical devices in accordance with aspects of the subject technology are depicted.

[0012] Figure 5 An example process for accurately delivering a flush infusion in accordance with aspects of the subject technology is depicted.

[0013] Figure 6 is a conceptual diagram illustrating an example electronic system for accurately delivering a flush infusion in accordance with aspects of the subject technology. DETAILED DESCRIPTION

[0014] Reference will now be made to embodiments, examples of which are shown in the accompanying drawings. In the following description, many specific details are set forth in order to provide an understanding of the various described embodiments. However, it will be apparent to one of ordinary skill in the art that the various described embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks are not described in detail in order to avoid unnecessarily obscuring aspects of the embodiments.

[0015] In today's syringe-based infusion systems, the two syringes are treated as two separate orders to the infusion pump without any relationship to each other. This can lead to problems documenting in the patient record when the full drug dose was delivered and completed and when the flush was administered (and how much). This is due in part to the lack of documented connection between the medication order and the flush order and the delay between the clinical administration steps.

[0016] When a syringe is used to flush an infusion line, the user manually programs the syringe pump to deliver the flush. The system may be completely unaware that the clinician is flushing a medication line. Additionally, existing systems may only recognize the flush fluid without understanding the flush fluid's connection to the primary medication. For certain medications, safe administration of the flush fluid may vary depending on the medication being flushed.

[0017] The subject technology relates to how to accurately and securely program, manage, and electronically record flushes for syringe-type infusion pumps. The subject technology provides a syringe flush programming feature that includes a) electronically accounting for volumes from primary and flush syringes; b) message timing for confirming flush APR orders without initiation; and providing linkage between medication orders and flush orders.

[0018] The subject technology provides more accurate reporting of the volume infused, the time of infusion, and the infusion status for both medication and flushing orders to an electronic medical record (EMR) system, avoiding underdosing or overdosing in a patient's chart. The described features also allow for association of flushing orders with medication orders. When a new syringe is loaded into a syringe pump, the pump determines that at least a first portion of a predetermined amount of medication has been previously delivered by the pump according to a medication delivery order before the syringe was loaded, and determines a second portion of the medication remaining to be delivered to complete the medication delivery order. Delivery of a second fluid (e.g., flushing) is initiated by the syringe pump, and when the amount of the second fluid delivered from the new syringe satisfies the second portion of the medication remaining to be delivered, the pump automatically indicates that the medication delivery order has been completed without user intervention, disassociates the medication delivery order from the syringe pump, and associates the syringe pump with the second fluid delivery order.

[0019] The subject technology further improves the safety of medication administration for flushing orders by generating a programming confirmation when any flushing automation programming request is transmitted. Unlike manually programmed infusions, automated programming request infusions can be evaluated by clinical safety parameters to ensure that the right medication is delivered to the right patient via the right route at the right time.

[0020] Figure 1A An example patient care system 122 including a syringe pump 30 mounted to a control unit 14 according to various aspects of the subject technology is depicted. According to various embodiments, the control unit 14 can provide control and monitoring functions for the syringe pump 30. In this regard, the control unit can include: a display 4 for visually conveying various information such as operating parameters and alarm indications of the connected pump and alarm messages; and control keys 6 for selecting and / or setting control parameters and / or options for controlling the connected module (such as the syringe pump 30). The control unit 30 can also include a speaker to provide an audible alarm. In some embodiments, the display 4 can be implemented as a touch screen display. In such an embodiment, the control keys 6 can be omitted or reduced in number by providing corresponding interactive elements via a graphical user interface (presented via the display 4). In some embodiments, each control key 6 can select a corresponding option displayed in the display 4.

[0021] The syringe pump 30 may include a control panel 76 that provides a plurality of buttons 78 for controlling the pump 26 and a display 80 for presenting pump-specific information to the operator (see also FIG. Figure 1B ). Button 78 may allow the operator to program pump 26 for flow rate, volume to be infused, and other pump parameters. Display 80 may present the programmed flow rate, the amount of fluid remaining to be infused, as well as alarms and other information.

[0022] The control unit 14 may include a communication system (not shown) with which the control unit 14 can communicate with external devices such as a medical facility server or other computer and with a portable processor such as a handheld communication device or a portable computer or a device that a clinician may have for transferring information and for downloading a drug library to the control unit such as a pump 30 or, for example, Figure 3 The communication module can be used to communicate with other information devices of the control unit (such as the control unit 30 or the barcode scanner). The communication module can be used to pass access and interactive information to clinicians who encounter the control unit or a device coupled thereto (e.g., the pump 30 or a barcode scanner). The communication system may include a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH TM The barcode scanner and communication system may alternatively be included integrally with the infusion pump 30, such as in the absence of a control unit, or in addition to one of the control units 14. Additionally, the information input device need not be hardwired to the medical instrument, and information may also be transmitted via a wireless connection. Additionally, other types of modules may be connected to the pump module or control unit, such as a syringe pump module, a patient-controlled analgesia module, an end-tidal CO2 monitoring module, an oximeter monitoring module, or the like.

[0023] In some embodiments, pressure measurements from upstream and / or downstream pressure sensors are transmitted to a server or other coordination device, and the methods disclosed herein are implemented on the server or other coordination device. For example, a pressure sensor can be used to determine the pressure or force within an infusion line downstream of a pump (e.g., between a patient and a pump). More complex and computationally intensive methods, such as machine learning, can be implemented on a server (or on a control unit with greater memory and / or CPU resources). In some embodiments, machine learning is used to identify an empty condition based on a pressure signal received from a pump.

[0024] Figure 1B An example syringe pump infusion system including a first example syringe pump 30 according to various aspects of the subject technology is depicted. A syringe pump can be used to infuse medical fluids (such as parenteral fluids) into a human body. In many cases, smooth delivery of medical fluids is desired. For example, where the medical fluid includes a drug, delivery at a consistent or predictable flow rate allows medical professionals to correctly plan and perform treatment. Mechanical interactions between parts of an infusion system can create resistance to smooth delivery. Aspects of the embodiments disclosed herein address these issues to provide a more consistent and predictable flow during driver operation.

[0025] According to various embodiments, the depicted infusion syringe pump 30 includes a powertrain subsystem. For clarity of illustration, the syringe 32 is shown beside the pump rather than being installed in the pump. The syringe pump 30 includes a bracket / receptacle 34, in which the barrel 236 can lean when being installed in the syringe pump 30. The bracket 34 can include a fixture 38 to securely hold the barrel 36 in a fixed position in the bracket 34 to resist axial and lateral movement. The fixture 38 can be pivoted so that it can be moved to an open position to allow the loading or removal of the syringe 32, and to a closed position in which the fixture 38 extends above the bracket 34 to hold the installed barrel 36. The barrel flange 40 of the syringe 32 can be located in the barrel flange groove 42 in the syringe pump 30 to fix the barrel 36 during the movement of the plunger 44 in the barrel 36, free from axial movement.

[0026] The syringe 32 may include a barrel 36 and a plunger 44. The plunger 44 may include a push button 46 having an inner side 48 and interconnected by a piston 50 with a stopper 62 of the plunger 44. The plunger 44 may include a stopper 62 to sealingly engage the inner wall of the barrel 36 to prevent fluid from leaking past the stopper 62. When installed in the syringe pump 30, the push button 46 may be retained by the drive head 54 using a plunger retainer including a pair of pivotally mounted jaws, a first retainer jaw 56 and a second retainer jaw 58, as shown in FIG. Figure 1B When installed in the syringe pump 30, the retainer claws 56 and 58 can be bent inwardly toward each other to grasp the push button 46. The rotation knob 64 can be used to control the position of the first retainer claw 56 and the second retainer claw 58 to allow removal and insertion of the push button 46 and release the split nut from the drive shaft to permit axial positioning of the drive head 54. The syringe can be provided for use with syringe pumps with different amounts of fluid, and the plunger can be located at different positions relative to the barrel.

[0027] The drive head 54 can allow manual adjustment to accommodate syringes with different starting plunger positions. A syringe inserted into the carriage 34 can be aligned with the drive head 54 within a specific axial range. The point at which the axial centerline of the syringe intersects the driver can be changed depending on the size of the syringe, but only in one direction along the drive head 54. The guide device 65 can extend from the drive head 54 to a point within the body of the syringe pump 30.

[0028] According to some embodiments, the system may include an assembly for controlling the advancement of the plunger 44 within the barrel 36 of the syringe 32. The drive head 54 engaging the push button 46 of the syringe 32 may be moved by a power transmission system (not shown). For example, the pump 30 may include a motor that operates to rotate a lead screw engaged by a screw drive mechanism (such as a split nut) that converts the rotary motion of the lead screw into linear motion. The drive head 54 is connected to the screw drive mechanism and drives the plunger 44 into the barrel 36 to discharge the fluid from the barrel 36 according to the movement of the lead screw.

[0029] According to some embodiments, the motor may include a stepper motor, a brushed DC motor, a brushless DC motor, a servo motor, an AC motor, or another type of motor. The powertrain may include appropriate gears, axles, shafts, chains, hydraulic devices, and / or any other components for converting the rotary motion of the motor into the linear motion of the drive head 54. According to some embodiments, the powertrain including the motor may include a linear actuation component, such as a linear stepper motor. For example, a linear motor may be used directly as a drive head or as a component attached thereto to control its linear motion.

[0030] Drive head 54 may interact with syringe 32 in a manner that facilitates rapid, consistent, and predictable infusion of fluid from syringe 32 into a patient. The features described herein may be used alone or in combination to enhance the system's ability to deliver medication rapidly and smoothly at low flow rates.

[0031] In some embodiments, the syringe pump 30 includes a carriage sensor positioned in or near the carriage 34. For example, the carriage sensor can be configured to detect whether the syringe is loaded in the carriage. In some embodiments, the syringe pump 30 includes a cartridge sensor positioned on or near the clamp 38. For example, the cartridge sensor 348 can be configured to detect the movement of the clamp 310. As another example, the cartridge sensor can be configured to detect whether the clamp 38 clamps the barrel of the syringe 32 or how tight it is (e.g., corresponding to the size of the syringe). As yet another example, the cartridge sensor can be configured to detect the degree of displacement of the clamp. A fully displaced clamp can indicate that the clamp is open (e.g., for loading or unloading of a syringe). In contrast, a clamp that is only slightly displaced from a fully closed position can indicate that the clamp is clamping a syringe (e.g., with a degree of displacement corresponding to the diameter of the syringe).

[0032] In some embodiments, the syringe pump 30 includes a drive head sensor positioned on or near the drive head 54. For example, the drive head sensor can be configured to detect the movement of the drive head. As another example, the drive head sensor 350 can be configured to detect the position of the drive head. This position can be used to detect when the syringe is empty (for example, the plunger 44 is fully inserted). In some embodiments, the syringe pump module includes a plunger retainer sensor positioned on or near the retainer claw. For example, the retainer sensor can be configured to detect the opening and / or closing of the retainer claw. As another example, the retainer sensor can be configured to detect whether the retainer claw clamps the push button of the plunger 44 or how tight it is. One or more of the aforementioned sensors can be used to detect when a new syringe is loaded into the syringe pump 30, or when the syringe is unloaded from the pump. In some embodiments, the sensor can be used to optically detect when the syringe is emptied (for example, by detecting the piston 50 at the end of the cylinder 36).

[0033] When loading the syringe 32, the clinician releases and lifts the drive head upward. Such physical interaction can be detected by the drive head sensor. The clinician can then pull out and / or twist the collet to activate the collet sensor. The clinician loads the syringe, and when the syringe is loaded into the bracket / receptacle, the bracket sensor detects the barrel of the syringe. When the flange is fixed by the barrel flange, the barrel flange sensor detects the flange. The clinician twists the collet back into place to fix the syringe in the bracket / receptacle 34, and the collet sensor can detect that the fixture has fixed the syringe 32. The clinician opens the retainer claw and lowers the drive head onto the button of the plunger, releasing the claw to fix the plunger when the claw surrounds the button. Such physical interaction can be detected by the drive head sensor and the retainer sensor, respectively.

[0034] like Figure 1A As shown, a syringe pump 30 can be mounted to a control unit 14, together forming a modular patient care system. The control unit can perform various functions such as programming and communication for the pump. Control elements and functions can be included with the control unit 14 and at least partially performed by the control unit 14. In addition to the syringe pump 30 mounted to the control unit 14, other modules, such as those providing patient monitoring or treatment, can also form part of the patient care system. The control unit 14 can provide a centralized interface for various attached modules. One or more syringe pumps can be mounted to the control unit 14 and / or to each other.

[0035] Figure 2A second example syringe pump 30 infusion device is depicted in accordance with various aspects of the subject technology. Although the example syringe pump 30 is shown as a stand-alone device, the syringe pump may be configured as a functional module of a modular infusion infusion system, such as for BD Alaris TM The injector module of the system.

[0036] When syringe 32 is loaded into syringe pump 30, plunger flange (or push button) 46 at the end of syringe plunger piston 44 is held in or against plunger drive head 103 by flange fixture 104. Syringe barrel 36 is fixed by syringe fixture 108. Drive head 103 includes a push surface, and as drive head 103 moves forward toward syringe barrel 36, plunger flange 46 will lean against this push surface, thereby pushing plunger piston 44 into the barrel 36 of syringe to discharge syringe contents to patient through administration conduit 110. As will be further described, drive head 103 can be connected to a screw drive mechanism including a motor for connecting the linear motion of the screw drive mechanism to the syringe plunger so as to empty the syringe. Rate is controlled by syringe pump 100 based on programmed parameters (e.g., desired rate, type of syringe).

[0037] Syringe pumps typically do not experience any upstream pressure conditions, as the fluid to be infused is contained in the syringe barrel 106 and is pushed into the administration device 110 by way of the plunger piston 44. Downstream pressure conditions may be detected by a force sensor contained in or on the pump system 112. In some embodiments, the force sensor measures the force exerted on the syringe plunger piston 44 by the drive head 103 of the syringe pump.

[0038] In some embodiments, the syringe pump 100 can include a high-resolution pressure / force sensor that interfaces with a pressure disk (not shown) on the syringe applicator. The pressure disk provides a relatively large area of ​​contact with the pressure sensor. This allows the pressure sensor to measure the pressure inside the applicator more directly (not through the syringe plunger head) and with higher resolution and higher accuracy than a drive head force sensor. Measurements from such a pressure sensor and a drive head force sensor can be used independently or in conjunction with each other to detect an empty condition in a syringe pump.

[0039] In addition to the operating buttons or switches (which the operator can use to activate and program the syringe pump 100), there is also a display screen 114. The display screen 114 can be an LCD (liquid crystal display) with a small number of segments, such as seven segments with each character configured in a figure eight, suitable for displaying a small number of alphanumeric characters. The display can be monochrome, for example, it can only display red, green, or gray / black characters. Alternatively, the display 114 can be a more complex liquid crystal display capable of displaying more characters or more complex characters. The LCD can be backlit, for example, using light emitting diodes (LEDs). In some embodiments, the infusion pump may include a TFT LCD. TFT is an LCD technology based on thin film transistors. In some embodiments, the display screen 114 is also a touch screen such as a capacitive touch screen.

[0040] When programming the syringe pump 30, the user can input the type of syringe being used. The syringe pump 100 can store a database of known syringe types in internal memory, which contains information such as syringe diameter and stroke. The infusion pump firmware calculates the position of the syringe plunger and syringe piston based on the movement of the syringe drive head and the type and size of the syringe. This allows the machine to display calculations of the volume infused, the time elapsed, the remaining volume, and the remaining time. As the infusion continues and the drive head moves, these calculations can be updated and the displayed information is changed.

[0041] The syringe pump 30 may be provided with an input interface having controls operable to enter, increase, or decrease pumping parameters, such as a mass flow rate setting shown on the display, or a VTBI (volume to be infused) shown on the display. In some cases, the input keys may be physically present on the device (as depicted) or may be graphically displayed in the touch screen display 114.

[0042] In some embodiments, the syringe pump 30 can be configured to identify (eg, using a sensor) the disposable container loaded by the device. Figure 2 The syringe pump 30 may include one or more (or all) of the above Figure 1B The same or similar sensors discussed above. In this regard, the processor of the syringe pump (e.g., in the control unit 14 or internally) can detect when the syringe becomes empty (e.g., by using a drive head sensor, a piston sensor, or a pressure sensor), and when the user loads or unloads the syringe from the syringe pump.

[0043] The syringe pump 30 can perform electromechanical measurements on the loaded syringe to identify certain features about the loaded container. For example, the syringe pump can include a sensor that measures the size of the syringe inserted into the pump, for example, based on the degree to which the syringe is held. The clock position can determine the size of the barrel (e.g., whether it is a 6, 10, 50 ml syringe, etc.). Based on the physical measurements performed by the pump, the syringe pump can determine a list of possible candidate syringes. The device can then request confirmation via a display whether the container is in the list. During infusion, the volume and / or flow rate of infusion can be calculated based on the syringe type (e.g., based on the size of the syringe barrel).

[0044] Figure 3 An example of an institutional patient care system 120 of a healthcare organization according to aspects of the subject technology is depicted. Patient care devices (or commonly referred to as "medical devices") 122 are connected to a hospital network 124 via a LAN / WAN 126. The term patient care device or patient care unit can be used interchangeably with a control unit attached to a pump, any of which can include a variety of auxiliary medical devices, such as an infusion pump, a vital sign monitor, a drug dispensing device (e.g., a cabinet, a suitcase), a drug preparation device, an automatic dispensing device, a module coupled to one of the foregoing (e.g., a syringe pump module configured to be attached to an infusion pump), or other similar devices. Each element 122 is connected to an internal healthcare network 124 via a transmission channel 131. The transmission channel 131 is any wired or wireless transmission channel, for example, an 802.11 wireless local area network (LAN). In some embodiments, the network 124 also includes computer systems located in various departments throughout the hospital. For example, network 124 optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers, and / or a medical decision support system. As further described below, network 124 may include separate sub-networks. In the depicted example, network 124 includes a device network through which patient care devices 122 (and other devices) communicate in accordance with normal operation.

[0045] In addition, the institutional patient care system 120 may include a separate information system server 130. Furthermore, although the information system server 130 is shown as a separate server, the functionality and programming of the information system server 130 may be incorporated into another computer if this is desired by the engineers designing the institution's information system. The institutional patient care system 120 may also include one or more device terminals 132 for connecting and communicating with the information system server 130. The device terminals 132 may include personal computers, personal data assistants, and mobile devices (such as laptops, tablets, augmented reality devices, or smartphones) configured with software for communicating with the information system server 130 via the network 124.

[0046] Patient care devices 122 include systems for providing patient care, such as BD Alaris TM system. The patient care device 122 may include or contain a pump, a physiological monitor (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter and other patient monitors), a therapeutic device, and other drug delivery devices that can be used according to the teachings set forth herein. In the depicted example, the patient care device 122 includes a control unit 14 connected to one or more functional modules 16, 18, 20, 22, also referred to as an interface unit or programming module. The control unit 14 includes a central processing unit (CPU) 150 connected to a memory (e.g., a random access memory (RAM) 158), and one or more interface devices, such as a user interface device 154, an encoded data input device 60, a network connection 152, and an auxiliary interface 162 for communicating with additional modules or devices. The control unit 14 also (although not necessarily) includes a main non-volatile storage unit 156 (such as a hard drive or non-volatile flash memory) for storing software and data, and one or more internal buses 64 for interconnecting the aforementioned elements.

[0047] In various embodiments, the user interface device 154 is a touch screen for displaying information to the user and allowing the user to input information by touching a defined area of ​​the screen. Additionally or alternatively, the user interface device 154 may include any device for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen (e.g., Figure 1ADisplay 4). The data input device 160 can be a bar code reader capable of scanning and interpreting data printed in a bar code format. Additionally or in the alternative, the data input device 160 can be any device for inputting encoded data into a computer, such as one or more devices for reading a magnetic stripe, a radio frequency identification (RFID) device, whereby digital data encoded in an RFID tag or smart tag (defined below) is captured by the reader 60 via radio waves, a PCMCIA smart card, a radio frequency card, a memory stick, a CD, a DVD, or any other analog or digital storage medium. Other examples of the data input device 160 include a voice activation or recognition device or a portable personal data assistant (PDA). Depending on the type of interface device used, the user interface device 154 and the data input device 160 can be the same device. Although the data input device 160 is shown as being disposed within the control unit 14, it is recognized that the data input device 160 can be integrally located within the pharmacy system 34, or located externally and communicate with the pharmacy system 34 via an RS-232 serial interface or any other appropriate communication device. The auxiliary interface 162 may be an RS-232 communication interface, however any other means for communicating with peripheral devices such as printers, patient monitors, infusion pumps or other medical devices may be used without departing from the subject technology. Additionally, the data input device 160 may be a separate functional module, such as modules 16, 18, 20 and 22, and configured to communicate with the controller 14, or any other system on the network, using appropriate programming and communication protocols.

[0048] The network connection 152 may be a wired or wireless connection, such as via Ethernet, WiFi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem, or a cable modem. Any direct or indirect network connection may be used, including but not limited to a telephone modem, a MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link, or a WLANS connection or other wireless connection.

[0049] Functional modules 16, 18, 20, 22 are any devices used to provide care to a patient or to monitor a patient's condition. At least one of functional modules 16, 18, 20, 22 may be an infusion pump module for delivering medication or other fluids to a patient, such as a syringe pump 30 ( Figure 1B or Figure 2). For the purposes of this discussion, functional module 116 is an infusion pump module. Each of functional modules 16, 18, 20, 22 can be any patient treatment or monitoring device, including but not limited to an infusion pump, a syringe pump, a PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, an intracranial pressure monitor, etc. Functional modules 16, 18, 20 and / or 22 can be a printer, a scanner, a barcode reader, a near field communication reader, an RFID reader, or any other peripheral input, output, or input / output device.

[0050] Each functional module 16, 18, 20 and / or 22 communicates directly or indirectly with the control unit 14, which provides overall monitoring and control of the device 122. The functional modules 16, 18, 20 and / or 22 can be physically and electronically connected to one or both ends of the control unit 14 in a serial manner. However, it is recognized that there are other means for connecting the functional modules to the interface unit, which can be used without departing from the subject technology. It will also be appreciated that devices (such as pumps or patient monitoring devices) that provide sufficient programmability and connectivity may be able to operate as stand-alone devices and communicate directly with the network without being connected through a separate interface unit or control unit 14. As described above, additional medical devices or peripheral devices can be connected to the patient care device 122 via one or more auxiliary interfaces 162.

[0051] Each functional module 16, 18, 20, 22 may include module-specific components 176, a microprocessor 170, a volatile memory 172, and a non-volatile memory 174 for storing information. It should be noted that although four functional modules are shown, any number of devices may be connected directly or indirectly to the control unit 14. The number and type of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. The module-specific components 176 include any components necessary to operate a particular module, such as a pumping mechanism for an infusion pump module 116.

[0052] Although each functional module may be capable of at least some degree of independent operation, control unit 14 monitors and controls the overall operation of device 122. For example, control unit 14 provides programming instructions to functional modules 16, 18, 20, 22 and monitors the status of each module, as will be described in greater detail below.

[0053] Medical devices incorporating aspects of the subject technology may be equipped with a network interface module (NIM) to allow the medical device to participate as a node in a network. Although for purposes of clarity, the subject technology will be described as operating in an Ethernet network environment using the Internet Protocol (IP), it will be understood that the concepts of the subject technology are equally applicable to other network environments, and such environments are intended to be within the scope of the subject technology.

[0054] Data to and from various data sources can be converted into network-compatible data with existing technology, and information movement between medical devices and networks can be realized by various means. For example, patient care equipment 122 and network 124 can communicate via automatic interaction, manual interaction, or a combination of automatic and manual interaction. Automatic interaction can be continuous or intermittent, and can occur through direct network connection 154, or through RS232 link, MIB system, RF link (such as BLUETOOTH), IR link, WLANS, digital cable system, telephone modem or other wired or wireless communication means. Manual interaction between patient care equipment 122 and network 124 involves using, for example, user interface device 154, coded data input device 160, bar code, computer disk, portable data assistant, memory card or any other medium for storing data to transfer data intermittently or periodically between systems. The communication means in various aspects are bidirectional, where data is accessed from as many points of distributed data sources as possible. Decision making can occur in various places within network 124. For example, and not by way of limitation, decisions may be made at a health information system (HIS) server 130, a decision support, remote data server, a hospital department or unit station, or within the patient-care device 122 itself.

[0055] All direct communications with medical devices operating on network 124 according to the subject technology may be performed through information system server 130, referred to as a remote data server (RDS). According to aspects of the subject technology, a network interface module incorporated into a medical device (such as, for example, an infusion pump or a vital sign measurement device) ignores all network traffic that does not originate from an authenticated RDS. The primary responsibility of the RDS of the subject technology is to track the location and status of all networked medical devices with a NIM and maintain open communications.

[0056] In some embodiments, the server 30 may represent or include multiple servers. In some embodiments, the server 30 may include an EMR system (e.g., EMR server 202). According to some embodiments, the server 30 includes a prescription set and / or a pharmacy information system. The pharmacy information system can make the doctor's drug order process safer. The pharmacy website (e.g., provided by the server) can provide the doctor with a list of available drugs from which the doctor can choose. The pharmacy website can include a drug library with a list of available drugs, but it can also include and present to the doctor the drug name associated with the recommended dose and dose limit established or adopted by the medical and health facilities. In such cases where the doctor only needs to select an item from the computer screen without having to manually type in the drug name and drug administration number (such as infusion rate, time, etc.) associated with the administration of the drug, this should produce a more accurate administration process.

[0057] If the clinical order is for the administration of a specific drug regimen, the order will be transmitted to the pharmacy information system 130 of the facility. The pharmacy reviews the order, and once the order is ready, the order can be transmitted to the nurse station for matching with the appropriate patient. A prescription set is a list of approved drugs used in a medical facility (e.g., available for patient ordering). In the prescription set, there may be instructions for use information and / or concentrations and drug ranges approved for the facility. As will be further described, a prescription set may be used to define one or more medical device drug libraries, which may then be provided to infusion pumps within the hospital network. In the library, there is drug information, such as drug name, concentration, diluent volume, strength, minimum or maximum infusion parameters of the drug, and other parameters. Establishing these parameters via system 130 together with the parameters for off-prescription orders is useful for maintaining consistency throughout the healthcare environment and ensuring that orders are understandable and executed as expected by other devices (e.g., infusion pumps) within the system 130.

[0058] Further references Figure 3, the patient care device 122 can operate in a variety of different modes or personalities, each personality being defined by a configuration database. The configuration database can be a database 156 inside the patient care device, or an external database 137. A specific configuration database is selected based at least in part on patient-specific information (such as patient location, age, physical characteristics, or medical characteristics). Medical characteristics include, but are not limited to, patient diagnosis, treatment prescriptions, medical history, medical records, patient care provider identity, physiological characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., doctor identity) or the location of the patient care device 122 in a hospital or hospital computer network. Patient care information can be entered through interface devices 152, 154, 160, or 162, and can originate from anywhere in the network 124, such as, for example, from a pharmacy server, an admission server, a laboratory server, and the like.

[0059] The memory 156, 158 of the control unit 14 may contain one or more drug libraries, one or more event logs, and pump configuration settings, such as, but not limited to, profiles to be used in specific practice areas such as ICU, PED, etc. The memory may be an electronically loadable memory such as a non-volatile memory (e.g., EEPROM). The drug library stored on the pump (which illustratively contains information such as drug names, ranges of delivery parameter values, such as appropriate concentrations, dosage units, and dosage limits) may be used to perform drug calculation-based infusions in a clinical setting.

[0060] The drug library stored in the memory of the pump may include clinical order settings, such as limits set by clinical institutions for each drug in the library (also referred to herein as "guardrails"). Such limits may take the form of maximum and minimum doses for each drug, which may depend on patient factors or other factors associated with the delivery of the drug. For example, dose limits may vary, depending on the patient's weight or body surface area (BSA), depending on the unit or ward of the medical institution where the drug is being used (e.g., neonatal care unit (NCU), intensive care unit (ICU), etc.), and depending on other factors. If a nurse sets the pump to operate outside the range between the limits of a particular drug, an alarm may be provided. In some cases, the alarm may be overturned, while in other cases it may not. A medical facility may establish a "soft" limit for each drug, which may be overturned by a nurse, while a "hard" limit may not. In either case of exceeding the limit, a pump data log or other processor communicating with the infusion pump may record each such limit event for subsequent analysis when the attempted setting is higher than the maximum dose or lower than the minimum dose.

[0061] The pump also includes a display for displaying a user interface, including: a control panel through which a user can program the programmable controller, and a display screen for displaying drug entries from a drug library. Each of the associated drug delivery parameter sets includes: information selected from a group of parameters including drug concentration, drug delivery rate, drug dosage, and bolus size. The electronically loaded drug library contains a list of available mode options specifying units that can be used to express drug delivery information, and the drug infusion pump provides the list of available mode options to the user, from which the user makes a selection when the electronically loaded drug library is in the pump. In the case of a syringe pump, the electronically loaded drug library may include a list of names of syringe manufacturers that identify syringes that can be used in the drug infusion pump, and the drug infusion pump provides the list of names of the syringe manufacturers to the user, from which the user makes a selection when the electronically loaded drug library is in the pump. The loaded drug library may include a list of syringe sizes that can be used in the drug infusion pump, and the drug infusion pump provides the list of syringe sizes to the user, from which the user makes a selection when the electronically loaded drug library is in the pump. In the case of a peristaltic pump, the electronically loaded drug library may include a list of infusion device manufacturers. The loaded drug library may include a set of features, each of which is either switched on or switched off, and the pump provides the user with only those features from the set of features that are switched on when the electronically loaded drug library is in the pump.

[0062] Figure 4 An example system 200 for automatically programming a medical device according to aspects of the subject technology is depicted. Interoperability between a hospital's electronic medical record (EMR) 202 and a medical device, such as an infusion device 122, enables pre-filling of infusion parameters. Pre-filling of infusion parameters can reduce the number of programming screens and keystrokes required to manually program a pump. Implementations of interoperability do not preclude a clinician from manually programming an infusion device. Manual programming may be required in the event of a failure of any component of the interface system.

[0063] Although the feature may be described with reference to an EMR, the feature is applicable to providing automatic programming for medical devices that use similar hospital information systems, such as a pharmacy data management system (PDMS). In addition, although the feature may be described using an infusion pump as an example medical device, the feature is applicable to providing automatic programming for other medical devices that use barcodes for association, such as patient monitors, patient association management systems, or alarm management systems.

[0064] The formulary 204 determines which drugs can be dispensed within the hospital network. A hospital committee may be formed to determine how the drugs within the formulary will be applied to the patient care devices 122. Figure 4The system is described with respect to a patient care device 122, but the system can be applicable to stand-alone infusion devices (e.g., syringe pumps 30). Configuration definitions are agreed upon (e.g., by hospital department such as ICU, NICU, pediatrics, oncology, surgery, etc.), and medications and typical infusion protocols are established in a medical device drug library ("drug library"). In addition, restrictions, or guardrail conditions, are defined in the drug library. When the definitions are complete, the configuration including the drug library can be released. The pumps at the institution are then updated by passing the configuration database to some or all of its pumps. Corresponding updates to the prescription set can be shared with other hospital systems, such as a pharmacy order system or an electronic medical record system, which can use the prescription set information to generate patient orders to deliver specific medications to specific patients (e.g., 2.1).

[0065] In the clinical arena, a clinician may scan a medical item, such as an infusion package, using a scanner associated with a medical device, such as an infusion device 122. For example, a barcode reader (or other data entry device) is used to scan coded medication labels, patient coded ID bands, and caregiver ID badges, as well as refill prescription information or medical device configuration instructions (including a configuration database ID) optionally printed on a label or accompanying order form. The reader / scanner need not be integrated with the medical device. The scanner may be part of a separate device, such as a medical record terminal 206 (e.g., part of one or more computing devices), that is connected to the same network 124 as the infusion device 122 and configured with software to function in an overall workflow involving the infusion device 122. The scan initiates a process by which information related to the item (e.g., scanned from a code affixed to or transmitted by the item) is automatically sent (e.g., 2.2) to the hospital's EMR 202 (e.g., at a centralized processor 30) via the network 124. The EMR 202 may validate the item and generate (e.g., at 2.3) a Figure 2 ) and sends an automated programming request (APR) to the medical device 122 to load parameters related to the item. The parameters may be stored in the medical device 122, but are loaded in response to the identifier received from the server. Although the examples herein relate to infusion devices, any medical device may be configured in the same or similar manner and employ the automated programming error mitigation described herein.

[0066] In the depicted embodiment, the coordination engine 208 coordinates messages sent from the EMR 202 to the infusion device 122. In the depicted embodiment, the EMR 202 transmits an APR with a device identifier (ID) of the infusion device (for receiving the APR) to the pump coordination engine 208 (e.g., 2.4). The coordination engine then determines whether the infusion device 122 identified by the EMR is available and, if available, forwards the APR to the device 122 (e.g., 2.5). When the infusion device 122 receives the APR, the infusion device 122 programs itself according to the parameters of the APR. In some embodiments, the APR activates a drug library stored on the device and programs the infusion device for the drug identified in the APR according to the parameters stored in the drug library. In some embodiments, after successful programming, the infusion device can automatically start operation based on the parameters. In some embodiments, the infusion device can confirm the automatically entered parameters (e.g., 2.6). The confirmation may include presenting one or more user interface screens including parameters and values ​​along with control elements (e.g., buttons) that, when activated, cause the infusion device to begin operating based on the parameters. The user interface may include additional or alternative control elements to allow the clinician to adjust the automatically entered parameters based on, for example, professional judgment or changes in the patient's condition.

[0067] Figure 5 Depicted is an example process for accurately delivering flush infusion according to aspects of the subject technology. For the purpose of illustration, each block of the example process 500 is described herein with reference to components and / or processes described herein in FIG. 1. One or more blocks of process 500 may be implemented, for example, by one or more computing devices, including, for example, an internal processor of a control unit 14 or a syringe pump. In some embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be implemented separately from other blocks and may be implemented by one or more different processors or devices. Further for the purpose of explanation, the blocks of the example process 500 are described as occurring serially or linearly. However, multiple blocks of the example process 500 may occur in parallel. In addition, the blocks of the example process 500 do not need to be executed in the order shown, and / or one or more blocks in the example process 500 do not need to be executed.

[0068] The subject technology ties together multiple infusion delivery orders to ensure delivery of each fluid associated with the order. For purposes of this disclosure, each "fluid delivery order" refers to an order for a quantity of fluid to be delivered by an infusion device, including any fluid associated with the order that remains in a syringe or has been pushed out of a delivery syringe and resides in a downstream segment of IV line 110 (e.g., but has not yet been delivered to a patient). According to various embodiments described herein, a first fluid delivery order for a medication is associated with at least a portion of a second fluid delivery order for a flush-type infusate that is used to flush the remaining amount of medication for the first delivery order out of IV line 110 to complete the first delivery order. The first delivery order is not recognized as completed by the syringe pump until the remaining amount of medication in the IV line is flushed.

[0069] Although the subject technology is described with respect to a drug and a non-drug flush infusion, the subject technology can be configured for two drugs. In such embodiments, when sufficient second drug is delivered to push the remaining first drug through the IV line 110, the first drug is reported as complete.

[0070] Prior to (or optionally in part of) the depicted process 500, a first syringe is loaded into a syringe pump and a first fluid is delivered from the first syringe. The first fluid may include, for example, a prescription drug delivered in accordance with a first fluid delivery order. When the syringe is loaded, a sensor associated with the syringe pump (e.g., a fixture sensor and / or a drive head sensor) detects the loading action and an indication that the syringe is loaded is received by a control unit (e.g., an internal processor of the control unit 14 or syringe pump). The syringe pump 30 (operated by the control unit) is caused to deliver the first fluid from the first syringe until an indication that the first syringe is emptied is received. During the infusion, the volume infused is measured and stored in a memory. The pump may detect (e.g., by means of one or more sensors) when the syringe becomes empty. When the first syringe becomes empty, the first fluid delivery order is suspended. An empty condition for the first fluid delivery order may be generated. In some embodiments, the empty condition and / or the volume infused is reported (e.g., via network 124) to an EMR server.

[0071] In the depicted example, a new syringe 32 is loaded / received into the reservoir 34 of the syringe pump 30 (while the first fluid delivery order is paused). According to various embodiments, the new syringe contains a second fluid, e.g., a non-medicinal flush infusate for flushing remaining first fluid remaining in the IV line 110. Sensors associated with the syringe pump (e.g., a clamp sensor and / or a drive head sensor) detect the loading action and an indication that the syringe is loaded is received by the control unit (502).

[0072] Upon receiving an indication that a new syringe is loaded, the syringe pump 30 determines that the syringe pump is currently associated with a first fluid delivery order for a predetermined amount of the first fluid, and determines that at least a first portion of the first fluid has been previously delivered by the syringe pump according to the first fluid delivery order before the new syringe is loaded into the syringe pump (504). According to various embodiments, the determination (504) is made by the control unit based on electronically stored information associated with the syringe pump 30. For example, data for each infusion (and its progress) can be stored in an internal memory and / or uploaded to a server (e.g., an EMR server). The data can then be accessed / queried when the syringe is loaded or when the infusion is started (e.g., by way of user input at the control unit). In some embodiments, the determination can be made based on measuring the fluid being delivered. In some embodiments, the determination can be made based on receiving an indication that a syringe associated with the first fluid delivery order becomes empty during the infusion of the first fluid (e.g., based on sensor data).

[0073] The control unit determines a second portion of the first fluid remaining to be delivered to complete the predetermined amount of the first fluid for the first fluid delivery order (506). In some embodiments, the control unit determines that the predetermined amount of the first portion was previously delivered by the syringe pump according to the first fluid delivery order before a new syringe was loaded into the syringe pump, and the remaining, second portion is determined based on the first portion. In some embodiments, the remaining second portion is determined based on receiving a flush command or flush order after delivering the first fluid, and the remaining second portion is based on an amount specified for the flush.

[0074] Delivery of the second fluid from the new syringe is initiated by the syringe pump in accordance with the second fluid delivery order (508). Up to this point, the second portion of the first fluid remaining to be delivered resides in the IV line 110 but has not been delivered to the patient. Simultaneously with initiating delivery of the second fluid, the syringe pump 30 may generate a restart condition (which may be sent to the EMR server).

[0075] The syringe pump is caused to deliver the second fluid (510).

[0076] The syringe pump monitors the delivery of the second fluid to determine when the amount of the second fluid meets (eg, is equal to or greater than) the portion of the first fluid remaining to be delivered (eg, in the downstream IV line 110).

[0077] When the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, the syringe pump automatically indicates the first fluid delivery order as completed without user intervention, disassociates the first fluid delivery order from the syringe pump, and associates the syringe pump with the second fluid delivery order. Simultaneously with associating the syringe pump with the second fluid delivery order, the syringe pump 30 can generate a start condition for the second fluid delivery order (which can be reported to the EMR server). In this way, the start condition for the second fluid delivery order is not generated until the first fluid delivery order is determined to be completed only by the second remaining portion having been removed from the IV line 110.

[0078] In some embodiments, indicating the first fluid order as complete includes associating a type of the second fluid (e.g., a non-medicinal flush infusate) and a flush complete event with the first fluid delivery order. In some embodiments, the syringe pump 30 can provide an indication of the second fluid delivery complete when the new syringe is emptied. In some embodiments, the syringe pump 30 can provide an indication of the second fluid delivery complete when the flush is indicated as complete (e.g., when the first fluid is purged from the IV line before the new syringe is emptied).

[0079] In some embodiments, when the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, the syringe pump automatically (e.g., without user intervention) prompts the user to confirm to continue delivering the second fluid from the new syringe, and in response to receiving the confirmation from the user, continues to deliver the second fluid from the new syringe.

[0080] According to various embodiments, the syringe pump 30 is caused to deliver the second fluid by driving the motor of the syringe pump in response to initiating delivery of the second fluid from the syringe, and delivery of the second fluid from the new syringe is continued by driving the motor of the syringe pump. In this regard, indicating the first fluid delivery order as completed, disassociating the syringe pump from the first fluid delivery order, associating the syringe pump with the second fluid delivery order, and continuing delivery of the second fluid are performed without stopping the motor.

[0081] According to various embodiments, the first fluid and the second fluid are measured in volume units. For the first fluid delivery order, the syringe pump 30 is based on the delivery of the first fluid from the first syringe before the empty state is generated, and by the delivery of the second fluid from the new syringe until the amount of the second fluid delivered from the new syringe meets the second part of the remaining first fluid to be delivered, and the total volume of the first fluid is continuously measured. When the total volume is reached (by the way that the remaining part of the first fluid has been excluded from the IV line 110), the syringe pump confirms that the measured total volume has been delivered according to the first fluid delivery order. The total volume can be displayed by the syringe pump, for example, on a display 6, a display 114 or other associated displays. Unlike conventional pumps, the total volume is only confirmed as being delivered (and / or reported to the EMR server) after enough second fluid (from the new syringe) has been infused by the infusion pump to exclude the IV line 110.

[0082] Brief reference Figure 4 , the syringe pump 30 can receive an automated programming command from the remote computing system to configure the syringe pump to deliver a second fluid (e.g., a non-medicinal flush infusate) according to the second fluid delivery order. In response to receiving the automated programming command, the syringe pump can automatically program the syringe pump to initiate delivery of the second fluid from a new syringe by the syringe pump according to the second fluid delivery order without user intervention. In some embodiments, the automated programming command can disable a syringe empty alarm that is currently set to be provided when a first syringe loaded in the syringe pump is emptied.

[0083] In some embodiments, the automated programming command causes the syringe pump to automatically program the syringe pump to initiate delivery of the first fluid from the first syringe by the syringe pump according to the first fluid delivery order and prompt the user to unload the first syringe and load a new syringe when the first syringe is emptied. When the amount of the second fluid delivered from the new syringe satisfies the second portion of the remaining first fluid to be delivered, the syringe pump 30 can automatically stop the delivery of the second fluid.

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

[0085] The term "software" means, where appropriate, firmware residing in a read-only memory or applications stored in a magnetic storage device that can be read into a memory for processing by a processor. In addition, in some embodiments, multiple software aspects disclosed in the subject matter can be implemented as sub-parts of a larger program while retaining the different software aspects disclosed in the subject matter. In some embodiments, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that implement the software aspects described herein together are within the scope of the subject matter disclosure. In some embodiments, the software program, when installed to operate on one or more electronic systems, defines one or more specific machine implementations that implement and execute the operations of the software program.

[0086] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and may 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 may 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, subroutines, or portions of code). A computer program may be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communications network.

[0087] As used herein, Dose Volume may be synonymous with Diluent Volume. Dose Volume / Diluent Volume may be different from Volume to be Infused (VTBI). In some embodiments, flush (PRN) orders and medication orders are not linked in a health information system (HIS). In some embodiments, flush orders and medication orders are linked and the link may be based on, for example, the device providing the order response, the patient associated with the order, or the time the order response is received at the HIS.

[0088] It is understood that the volume infused by the syringe pump refers to the volume that the pump has pushed into the administration kit (e.g., the intravenous (IV) line downstream of the pump). In this regard, the term "infused volume" as used herein may not be the same as the volume that the patient connected to the pump has received.

[0089] Other acronyms or terms used in this article:

[0090] eMAR – electronic medical administrative record for patients

[0091] HIS - Health Information System. The HIS may include partners within the eMAR and pump interoperable ecosystem. The HIS may include, for example, an EMR server 202 or other server 130 within a healthcare organization.

[0092] KVO - Keep veins open

[0093] Dedicated Medication Line - A clinical technology configuration in which the IV line is dedicated to any prescription order for the patient. This line remains connected to the patient and uses fluids such as saline to maintain the set and IV site.

[0094] The following example scenario shows a method for Figure 5 The described aspects improve the features of flushing administration. The first four example scenarios generally illustrate how manual flushing can be accurately and safely reported using a syringe pump. The second four scenarios generally illustrate how manual flushing can be accurately and safely reported using a syringe pump. Figure 4 The automated programming request (APR) described herein safely and accurately automatically programs and reports flushes. The doses in the following example scenarios are for illustration only and may be replaced with "first amount," "second amount," "first portion," "second portion," etc., representing any predetermined amount. As described below, control of the pump may be performed by one or more processors within the pump, or a control unit, or a terminal associated with the pump. Reporting, programming, and monitoring of the pump may be performed via a user interface on the pump or control unit, or a terminal associated with the pump (e.g., terminal 132 and / or EMR terminal 206). Scenario 1 - Manual flush, dose volume greater than available disposable volume

[0095] In a first example, a disposable IV set 110 is filled with a first amount of medication (e.g., approximately 0.5 ml) from the total amount of fluid in a first fluid delivery order (e.g., 2 ml of medication in a disposable syringe). In this example, the IV set 110 is filled from the disposable syringe corresponding to the order. Once the IV set 110 is filled, the syringe is loaded into the pump once and the remaining medication begins to be infused. The infusion results in the medication container running to the syringe empty, the dose volume remaining to be infused and the medication remaining in the pipeline waiting to go to the patient.

[0096] When a previously programmed infusion has reached syringe empty (drug remaining in the line), the syringe pump 30 can execute instructions (e.g., firmware, software stored in non-volatile memory, remote control message, or the like) or be otherwise configured to perform the following process to ensure that the correct dose is fully delivered and properly recorded.

[0097] In one example, the clinician uses a specific flushing workflow on the syringe pump 30 (or control unit), programs a volume of 0.9 ml as the VTBI and selects START (e.g., activates a control element on the user interface, activates a soft key, activates an electromechanical button) to initiate an infusion according to the programmed parameters. During and / or after programming, the pump can communicate information about its parameters or values ​​to an infusion pump administration system or other HIS.

[0098] The pump (or pump module) may then resume the clindamycin infusion and transmit a (re)start infusion event using a new start code indicating that the infusion has been restarted but will transition to flush at a later time. The report may be one or more messages to the HIS including information about the infusion. An example report may be as follows:

[0099]

[0100] A. When the infusion volume counter reaches 2 mL = dose volume, this triggers the pump or control unit to transmit an infusion complete event indicating that the dose has been infused. The report can be one or more messages transmitted to the HIS including information about the infusion. An example report can be as follows:

[0101]

[0102]

[0103] B. The pump or control unit may transmit a Start event (e.g., to the EMR server 202, 137) for flushing immediately after or near the Complete event and without stopping the motor, indicating the name of the new infusate (if known) and including an identifier for the active order, such as an order ID for the medication. A report may be one or more messages including information about the infusion. An example report may be as follows:

[0104]

[0105]

[0106] When the programmed VTBI of 0.9 mL (0.4879 of drug + 0.4121 of flush) is reached, the pump or pump module may stop and transmit (directly or via the control unit) a flush complete event indicating that the programmed VTBI is complete. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0107]

[0108]

[0109] Within the HIS, a clinician reviewing the I / O chart (such as via eMAR) will see two entries: one for the 2 mL of clindamycin and one for the 0.4121 mL of the infusate named in the flush report. The flush infusate will have an active and clear association with the primary administration of clindamycin.

[0110] Scenario 2 - Manual flush, dose volume is less than the available disposable volume

[0111] In another example, the disposable tubing is pre-filled with 0.5 mL of solution. The disposable syringe is loaded into the pump and the drug begins to be infused. The drug infusion causes the drug container to run until the infusion is complete, all the dose volume is infused, but there is drug left in the tubing waiting to go to the patient.

[0112] Since the previously programmed infusion has reached infusion completion and the drug remains in the line, the syringe pump can execute instructions (e.g., firmware, software stored in non-volatile memory, remote control message, or the like) or be otherwise configured to perform the following process to ensure that the correct dose is fully delivered and properly recorded.

[0113] In this example, the clinician programs a volume of 0.9 mL as the VTBI using a specific flushing workflow on the device and selects START (e.g., activates a control element on a user interface, activates a soft key, activates an electromechanical button) to initiate an infusion according to the programmed parameters. During and / or after programming, the pump can communicate information about its parameters or values ​​to an infusion pump administration system or other HIS.

[0114] The pump (or pump module) may then start the infusion and transmit (via the pump or control unit) a start event for the flush, which indicates the name of the new infusate (if known), and includes an identifier for the active order, such as an order ID for the medication. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0115] <![CDATA[ Report data ]]> Active flushing step Infusion Events: start Step Type: rinse Step Status: Infusion Status change reason: Start Drug Reference ID: Clindamycin + Pump ID Flush Order ID: NULL Infusion Name: unknown Amount of medicine: ---- Diluent volume (mL): ---- Rate (mL / h): 1.3333 VTBI(mL): 0.9000 Volume to be infused (mL): 0.0000

[0116] When a VTBI of 0.9 mL is reached, the pump or pump module may stop and transmit (directly or via the control unit) a flush complete event indicating that the programmed VTBI is complete. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0117]

[0118]

[0119] Within the HIS, a clinician reviewing the I / O chart (such as via eMAR) will see two entries: one for the 2 mL of clindamycin and one for the 0.9 mL of the infusate named in the flush report. The flush infusate will have an active and clear association with the primary administration of clindamycin.

[0120] Scenario 3 - Manual flushing of microvolume infusions

[0121] In one example, syringe pump 30 fills disposable tubing 110 with a small volume of medication (dose volume less than tubing volume) and requires a one-time flush to be started immediately. The flush results in a one-time run until the infusion is complete, all dose volumes are infused and no medication is left in the tubing.

[0122] 1. After manually pushing the medication into the IV line, the clinician loads the syringe pump 30 with a new flush disposable.

[0123] 2. The syringe pump 30 prompts the clinician to select a medication from the drug library and program the infusion parameters.

[0124] 3. The syringe pump 30 (or control unit 14) may proceed to the main infusion setup screen and display the following setup parameters:

[0125] a. Drug Name = Clindamycin

[0126] b. Rate = 1.333 mL / h

[0127] c. VTBI = 2 mL

[0128] d. Available volume = 3.015 mL

[0129] 4. In this example, the clinician reviews the parameters and selects START (eg, activates a control element on a user interface, activates a soft key, activates an electromechanical button) to initiate the infusion according to the programmed parameters.

[0130] 5. The pump (or pump module) starts infusing, and the infusion pump 30 (eg Figure 1B Module or Figure 2 A control unit (stand-alone) or associated with the pump can report multiple infusion events for the program (e.g., via a display or to a server 202, 137).

[0131] 6. Once the infusion is complete on the pump and within the HIS, the clinician reviewing the I / O chart (such as via eMAR) will see an entry for 2 mL of clindamycin in the patient's chart.

[0132] 7. In this example, the clinician programs an additional volume of 1 mL as VTBI using a specific flushing workflow on a syringe pump or control unit and selects START (e.g., activates a control element on a user interface, activates a soft key, activates an electromechanical button) to initiate an infusion according to the programmed parameters. During and / or after programming, the pump can communicate information about its parameters or values ​​to an infusion pump administration system or other HIS (e.g., to EMR server 202 or server 137).

[0133] 8. The pump 30 (or pump module) starts the infusion and the pump or control unit or server / client terminal associated with the pump module may report the start event of the flush order (e.g., via a display and / or to a server). The report may include references to previous medications, such as the order ID, drug name and concentration pair, and flush solution (if known). The report may be one or more messages to the HIS including information about the infusion. An example report may be as follows:

[0134]

[0135]

[0136] 9. When a VTBI of 1 mL is reached, the pump 30 may stop and report (on the display or to the server) a flush complete event. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0137]

[0138]

[0139] 10. Within the HIS, the clinician reviewing the I / O chart (such as via eMAR) will see two entries: one for the 2 mL of clindamycin and one for the 1 mL of the infusate named in the flush report. The flush infusate will have an active and clear association with the primary administration of clindamycin.

[0140] Scenario 4 - Manual flush, push the filled volume first

[0141] In this example, a dedicated medication line connected to the patient is currently on standby. A time-critical order of vancomycin can be determined for delivery to the patient. For this dose, a peak lab draw can be ordered. The clinician can load the medication all at once and push the vancomycin to the bottom of the line to avoid any delayed administration and know the exact time that medication administration will begin.

[0142] There are three prerequisites that can exist before a workflow can be executed.

[0143] • The pump is loaded with a dedicated medication line 110 with disposable saline but is set on standby for the next medication order.

[0144] The tubing volume between the pump and the patient is 1.1 mL

[0145] The order flow rate is 1.25mL / h

[0146] It may also be desirable to end the workflow in a known state. In this example, after the workflow, the post-condition is that the dedicated medication line is loaded with a disposable saline solution and returned to standby for subsequent medication reference.

[0147] 1. The clinician replaces the disposable saline solution with a disposable medication in the pump or pump module.

[0148] 2. The clinician selects 2.5 mL of vancomycin from the drug library on the device and continues programming.

[0149] 3. The pump 30 (or control unit) may proceed to the main infusion setup screen and display the following setup parameters:

[0150] a. Drug Name = Vancomycin

[0151] b. Rate = 1.25 mL / h

[0152] c. VTBI = 2.5 mL

[0153] d. Duration = 2 hours 0 minutes

[0154] e. Available volume = 2.49 mL

[0155] 4. In this example, the clinician reviews the parameters and selects PRIME (e.g., activates a control element on a user interface, activates a soft key, activates an electromechanical button) to initiate the loading of a single-use vancomycin into the tubing using the software fill feature and fills the patient with vancomycin medication.

[0156] 5. The pump (or pump module) starts filling at 250 mL / h and the pump or control unit associated with the pump module or the server / client terminal reports the filling start event to the HIS. The report can be one or more messages to the HIS including information about the filling. An example report can be as follows:

[0157]

[0158]

[0159] 6. Once the vancomycin reaches the patient, the clinician can stop filling. Stopping filling can include activating a control element of the pump or an associated control unit to transmit a control signal to stop filling. In some embodiments, the clinician can deactivate (e.g., stop pressing, depressing) a control element to control the pump to stop filling.

[0160] 7. The pump, pump module, or control unit associated with the pump may indicate (e.g., display) the filled 1.1 mL volume and report the fill stop event to the HIS. The report may be one or more messages to the HIS including information about the fill. An example report may be as follows:

[0161]

[0162]

[0163] 8. In this example, the clinician can exit the priming feature and activate or return to the infusion programming interface.

[0164] 9. The pump or control unit may proceed to the main infusion step setup screen and display the following setup parameters:

[0165] f. Drug Name = Vancomycin

[0166] g. Rate = 1.25 mL / h

[0167] h.VTBI=2.5mL

[0168] i. Duration = 2 hours 0 minutes

[0169] j. Available volume = 1.39 mL

[0170] 10. In this example, the clinician reviews the parameters and selects START (eg, activates a control element on a user interface, activates a soft key, activates an electromechanical button) to initiate the primary infusion according to the set parameters.

[0171] 11. The pump (or pump module) starts infusing vancomycin and the pump or control unit associated with the pump module or the server / client terminal may report the start event. The report may be one or more messages to the HIS including information about the infusion. An example report may be as follows:

[0172]

[0173]

[0174] 12. Within the HIS, the clinician reviews the entry reporting an infusion of 0 mL of vancomycin in, for example, the patient's eMAR. The clinician may be prompted to record a vancomycin fill volume of 1.1 mL.

[0175] 13. Via the HIS (eg, eMAR), the clinician can associate the 1.1 mL volume with the normal saline for the patient. In some embodiments, the association can be suggested or identified by the HIS based on incoming infusion event reports and other information in the patient's electronic medical record.

[0176] 14. After 1 hour and 15 minutes, the pump or pump module may report (e.g., alarm) a one-time empty, stop, and report (directly or via the control unit) an infusion stop event. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0177]

[0178]

[0179] 15. The workflow of Example Scenario 1 may be executed to complete the dose and return the drug line to standby.

[0180] Scenario 4 - Alternative Solution

[0181] In one example, the following steps can be changed:

[0182] 4. The clinician selects the flushing workflow for the device from the on-device drug library and proceeds with programming.

[0183] 5. The pump or control unit displays the main infusion step setup screen as shown below:

[0184] a.Title bar = Main flush

[0185] b. Rate = ____mL / h

[0186] c.VTBI=____mL

[0187] d. Available volume = 2.49 mL

[0188] 6. The clinician programs 250 mL / h and 1.1 mL of VTBI and starts the infusion.

[0189] 7. The syringe pump 30 starts the infusion and the pump or control unit reports an infusion start event which includes a unique ID to be included with the medication report as follows:

[0190]

[0191]

[0192] 8. The module stops infusing, switches to KVO, and the pump or control unit reports a major stop event as follows:

[0193] <![CDATA[ Report data ]]> Active loading steps Infusion Events: stop Step Type: loading Step Status: Finish Status change reason: End the program Order ID: Rinse 19 Infusion Name: Filling-Rinsing Rate (mL / h): 250.0000 VTBI(mL): 1.1000 Volume to be infused (mL): 1.1000

[0194] 9. The clinician completes the KVO procedure and returns within 30 minutes to manually start the vancomycin infusion.

[0195] Scenario 5 – Flushing the APR, dose volume greater than available disposable volume

[0196] In some embodiments, the syringe pump 30 can be configured to deliver the primary fluid delivery order and the flush order using an automated programming request (APR). In one example, the IV line 110 is filled with about 0.5 mL of the drug from the 2 mL disposable syringe. The disposable syringe is loaded into the pump and the remaining drug begins to be infused. The infusion results in the drug container running to the syringe empty, the dose volume remaining to be infused and the drug left in the pipeline waiting to go to the patient.

[0197] In this example, three prerequisites can exist before the workflow is executed.

[0198] · PRN flushing order exists in HIS

[0199] The dosage volume is larger than that of a single-use dose

[0200] · A previously programmed infusion is close to the syringe empty

[0201] 1. In contrast to example scenario 1, the clinician can send (directly or indirectly) a FLUSHAPR PRN-order for saline to the pump (e.g., using Figure 4 The EMR terminal 206) is not selected and programmed to flush. An example APR may be as follows:

[0202]

[0203] In some embodiments, the flush APR may include an "additional volume" parameter instead of or in addition to the VTBI parameter. The additional volume parameter will indicate how much additional volume of fluid is pushed into the administration line 110. This may help to more accurately reflect the volume actually delivered to the patient.

[0204] 2. The pump or associated control unit may validate the order and accept the APR request as a Flush Request upon successful validation.

[0205] 3. The pump or associated control unit can silence any syringe empty alarm and prompt to load the one-time flush. This will stop the infusion if it has not already been stopped due to syringe empty or completion of volume infusion.

[0206] 4. In this example, the clinician unloads the medication syringe and connects and loads a flush syringe containing approximately 2 mL of normal saline and continues programming.

[0207] 5. The pump or control unit may proceed to the rinse step setup screen and display the following setup parameters:

[0208] a. Drug Title = Clindamycin 2 --rinse 1

[0209] b. Flush Name = Normal Saline 1

[0210] c. Rate = 1.333 2 mL / hr

[0211] d. VTBI = 1 1 mL

[0212] e. Available volume = 1.956 2 mL

[0213] Note:

[0214] 1. Fill from APR data

[0215] 2. Fill from pump data

[0216] 6. In this example, the clinician reviews the program and selects START (e.g., activates a control element on a user interface (e.g., of the pump, terminal 132, 206), activates a soft key, activates an electromechanical button) to initiate an infusion according to the programmed parameters. During and / or after programming, the pump may communicate information about its parameters or values ​​to an infusion pump administration system or other HIS.

[0217] 7.A. The pump 30 may then resume the infusion and transmit a report to the HIS (via the pump or control unit). The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0218]

[0219]

[0220] Note that the programmed VTBI is 1.0 mL but is reported here as 0.5121 mL. This is because the system will take into account the flush volume actually required for the associated primary infusion. In this example, the reported flush VTBI = programmed VTBI - remaining dose volume (i.e., for this example, 1 mL - 0.4879 mL = 0.5121 mL).

[0221] B. The pump or control unit may transmit a flush "Procedure Confirmation Event" to the HIS (e.g., server 130, 202) immediately before, after, or near the start event to acknowledge that the APR is confirmed and pending on the module. In some embodiments, a report may be included as part of the start event report. The report may be one or more messages that include information about the infusion. An example report may be as follows:

[0222]

[0223]

[0224] 8.A. When the infusion volume counter reaches 2 mL = dose volume, the pump or a control unit associated with the pump module or a server / client terminal may transmit an infusion complete event to the HIS. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0225] <![CDATA[ Report data ]]> Active Main Steps Pending rinse steps Infusion Events: Finish Step Type: Intermittent rinse Step Status: Finish Pending Status change reason: rinse Order ID: MED0101 FLUSHIE2000 Infusion Name: Clindamycin Normal saline Amount of medicine: 200.0000mg ---- Diluent volume (mL): 2.0000mL ---- Rate (mL / h): 1.3333 1.3333 VTBI(mL): 2.0000 0.5121 Volume to be infused (mL): 2.0000

[0226] The step state may be represented using different states, such as switching the container. The selection of the step state may be based on the original APR or subsequent parameters received at the pump or pump module or control unit.

[0227] B. The infusion completion report may be followed in time by the start event of the flush with the order ID of the medication. The report may be one or more messages to the HIS including information about the infusion. An example report may be as follows:

[0228] <![CDATA[ Report data ]]> Active flushing step Infusion Events: start Step Type: rinse Step Status: Infusion Status change reason: Start Drug Reference ID: MED0101 Flush Order ID: FLUSHIE2000 Infusion Name: Normal saline Amount of medicine: ---- Diluent volume (mL): ---- Rate (mL / h): 1.3333 VTBI(mL): 0.5121 Volume to be infused (mL): 0.0000

[0229] The pump may stop and report (directly or via the control unit) a flush complete event. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0230]

[0231]

[0232] 10. The clinician reviewing the I / O chart (such as via eMAR) will see an entry for the 2 mL of clindamycin and the 0.5121 mL of the infusion named in the flush report. The flush infusion will have a positive and clear connection to the primary administration of clindamycin.

[0233] Scenario 6 – Flushing the APR, dose volume is less than the available disposable volume

[0234] In some embodiments, the pump can be configured to use APR to deliver the primary delivery order and the flush order. The disposable tubing can be pre-filled with, for example, 0.5 mL of solution from a syringe. The syringe can be loaded into the pump and the drug begins to infuse. The drug step causes the drug container to run until the infusion is complete, all the dose volume is infused by the pump, but there is a volume of drug left in the tubing waiting to go to the patient.

[0235] In this example, three prerequisites can exist before the workflow is executed.

[0236] · PRN washout is present in HIS.

[0237] The dose volume is smaller than that in a single use.

[0238] • Previously programmed infusions have just completed infusion of all programmed VTBIs.

[0239] 1. Unlike Example Scenario 2, the clinician may (directly or indirectly) send a FLUSHAPR order to the pump for dilution of the heparin (as a flush request) instead of selecting and programming a flush. An example APR may be as follows:

[0240]

[0241] 2. In some embodiments, the flush APR may include an "additional volume" parameter instead of or in addition to the VTBI parameter. The additional volume parameter will indicate how much additional volume of fluid is pushed into the administration line. This may help to more accurately reflect the volume actually delivered to the patient. The pump or associated control unit may validate the order and accept the APR request as a flush request upon successful validation.

[0242] 3. The pump or associated control unit may silence any alarms related to the stopped infusion and prompt to load the one-time flush. This will stop the infusion if it has not already been stopped due to syringe empty or volume infusion completed.

[0243] 4. The pump or associated control unit can warn the user that heparin is scanned as a flush solution based on the configuration. In addition, the pump can warn the user that there may be a drug interaction between the flush solution and the medication. Finally, the pump can prompt the user to load a disposable flush.

[0244] 5. In this example, the clinician unloads the medication syringe and connects and loads the flush syringe containing approximately 2 mL of diluted heparin.

[0245] 6. The pump or associated control unit may proceed to the rinse step setup screen and display the following setup parameters:

[0246] a. Title bar = Clindamycin 2 --Flush w / diluted heparin 1

[0247] b. Rate = 1.333 2 mL / h

[0248] c. VTBI = 0.5 1 mL

[0249] d. Available volume = 2.091 2 mL

[0250] Note:

[0251] 1. Fill from APR data

[0252] 2. Fill from pump data

[0253] 7. In this example, the clinician reviews the program and selects START (e.g., activates a control element on a user interface, activates a soft key, activates an electromechanical button) to initiate an infusion according to the programmed parameters. During and / or after programming, the pump may transmit information about its parameters or values ​​to an infusion pump administration system or other HIS.

[0254] 8. The pump 30 may then start the infusion and transmit (via the pump or control unit) a report of the flush start event to the HIS (e.g., server 130, 202). The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0255]

[0256]

[0257] 9. When 0.5 mL of VTBI is reached from the APR, the pump may stop and report (directly or via the control unit) a flush complete event. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0258] <![CDATA[ Report data ]]> Active flushing step Infusion Events: Finish Step Type: rinse Step Status: Finish Status change reason: End the program Drug Reference ID: 5121064 Flush Order ID: FLUSHIE2000 Infusion Name: Diluted heparin Amount of medicine: ---- Diluent volume (mL): ---- Rate (mL / h): 1.3333 VTBI(mL): 0.5000 Volume to be infused (mL): 0.5000

[0259] 10. Within the HIS (e.g., via server 130, terminal 132, 206, or on pump display 6, 80, 114), the clinician reviewing the I / O chart (such as via eMAR) will see an entry for 2 mL of clindamycin and 0.5 mL of diluted heparin. The flush infusate will have a positive and clear association with the primary administration of clindamycin.

[0260] Scenario 7 - Flush APR for Microvolume Infusion

[0261] In some embodiments, the syringe pump 30 can be configured to deliver a primary fluid delivery order and a flush order using APR. In one example, the IV line 110 is primed with a small volume of medication (dose volume is less than the line volume) and the flush is initiated from a one-time flush. The flush results in a one-time run to infusion completion, all dose volumes are infused, and no medication (e.g., from a previous order) remains in the IV tubing.

[0262] In this example, three prerequisites can exist before the workflow is executed.

[0263] The dose volume is smaller than the pipe volume

[0264] The dose volume is manually pushed into the tubing between the pump and the patient

[0265] 1. After manually pushing the medication into the IV line and unlike example scenario 3, the clinician scans (e.g., a barcode or other wireless identifier) ​​the empty disposable medical device, the patient, and the pump. The clinician may use, for example, a barcode scanner associated with the EMR terminal 206, as described in connection with Figure 4 as described.

[0266] 2. The clinician confirms the medication order in the HIS and sends the medication APR to the pump.

[0267] 3. The clinician discards the empty disposable medication and loads the disposable flush into the pump or pump module.

[0268] 4. The pump or control unit may proceed to the main infusion setup screen and display the following setup parameters:

[0269] a. Drug Name = Clindamycin

[0270] b. Rate = 1.333 mL / h

[0271] c. VTBI = 2 mL

[0272] d. Available volume = 3.015 mL

[0273] 5. In this example, the clinician reviews the parameters and selects START (eg, activates a control element on the user interface of the display 6, 80, 114, activates a soft key, activates an electromechanical button) to initiate the primary infusion according to the set parameters.

[0274] 6. The pump 30 starts the infusion and the pump, or a control unit associated with the pump module, or a server / client terminal, may report the start event. The report may be one or more messages to the HIS including information about the infusion. An example report may be as follows:

[0275] <![CDATA[ Report data ]]> Active Main Steps Infusion Events: start Step Type: Intermittent Step Status: Infusion Status change reason: Start Order ID: 1984BYGO Infusion Name: Clindamycin Amount of medicine: 200.0000mg Diluent volume (mL): 2.0000 Rate (mL / h): 1.3333 VTBI(mL): 2.0000 Volume to be infused (mL): 0.0000

[0276] 7. When the programmed VTBI of 2 mL is reached, the pump may stop and report (directly or via the control unit or terminal) an infusion complete event. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0277]

[0278]

[0279] 8. Within the HIS, the clinician reviewing the I / O chart (such as via eMAR) will see an entry for 2 mL of clindamycin in the patient's chart.

[0280] 9. To provide flush instructions, the clinician may send (directly or indirectly via the terminal) a flush APR instruction for saline to the pump. An example APR may be as follows:

[0281]

[0282] In some embodiments, the flush APR may include an "additional volume" parameter instead of or in addition to the VTBI parameter. The additional volume parameter will indicate how much additional volume of fluid is pushed into the administration line. This may help to more accurately reflect the volume actually delivered to the patient.

[0283] 10. The pump or associated control unit may validate the order and accept the APR request as a flush request upon successful validation.

[0284] 11. The pump or associated control unit may prompt the user to load a disposable flush.

[0285] 12. Because the one-time flush is already loaded, the clinician can simulate unloading and reloading for the one-time flush. In some embodiments, the pump or a control unit or terminal associated with the pump can provide a load reload option. The reload option can be presented dynamically, such as based on the primary drug, the volume to be infused, etc.

[0286] 13. The pump or control unit or associated terminal proceeds to the flush step setup screen. An example set of displayed parameters and values ​​is as follows:

[0287] a. Drug name = Clindamycin - flushing

[0288] b. Rate = 1.333 mL / h

[0289] c. VTBI = 0.5 mL

[0290] d. Available volume = 1.015 mL

[0291] 14. In this example, the clinician can review the parameters and select START (eg, activate a control element on a user interface, activate a soft key, activate an electromechanical button) to initiate an infusion according to the programmed parameters.

[0292] 15. The pump 30 starts the infusion and the pump or a control unit associated with the pump module or a server / client terminal may report the start event. The report may include the order ID of the medication, if known. The report may be one or more messages to the HIS including information about the infusion. An example report may be as follows:

[0293]

[0294]

[0295] 16. When the programmed VTBI of 1 mL is reached, the pump or pump module may stop and report (directly or via a control unit or terminal associated with the pump) an infusion complete event. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0296]

[0297]

[0298] 12. Within the HIS, the clinician reviewing the I / O chart (such as via eMAR) will see two entries: one for the 2 mL of clindamycin and one for the 1 mL of the infusate named in the flush report. The flush infusate will have an active and clear association with the primary administration of clindamycin.

[0299] Scenario 8 - Flushing the APR, pushing the fill volume first

[0300] The syringe pump 30 can be configured to deliver both primary fluid delivery orders and flush delivery orders using APR. A dedicated medication line can be connected to a 1 kg neonate on standby. A time critical order of 0.2 mg of indomethacin in 0.4 mL over 30 minutes needs to be given as quickly as possible. The tubing volume between the pump and the patient is 0.3 mL, and the infusion rate is only 0.8 mL / h. The clinician will load the disposable medication and push 0.3 mL of indomethacin to the bottom of the tubing to avoid any further delays in administration.

[0301] In this example, the condition can exist before and after the workflow is executed.

[0302] A pump module with a dedicated medication line can be loaded with a single-use saline solution but always ready for the next medication order.

[0303] For some pumps performing this workflow, once completed, the dedicated medication line may be retained with disposable saline and returned to standby for the next medical order.

[0304] 1. Unlike example scenario 4, the clinician may cause an indomethacin APR to be sent to the pump (or pump module). The APR may include a flush first step that specifies a sufficient flush fluid volume so that indomethacin infusion will begin almost immediately. An example APR may be as follows:

[0305]

[0306]

[0307] The rate of flushing is shown as N / A in this example. However, in some embodiments, the rate can be defined by one or more of: a drug dose error reduction system (DERS); a one-time limit; a user or care area profile limit; a specific limit in the drug library (e.g., as a uniform value (rate / duration)); based on a percentage of the ordered drug rate or other dynamic value (e.g., 10x the ordered drug rate); or included in the flushing step APR.

[0308] 2. The pump or a control unit associated with the pump module may prompt the clinician to load the disposable medication.

[0309] 3. Once loaded, the pump or control unit or terminal can proceed to the Prime / Flush Infusion Step Setup Screen and display the following setup parameters:

[0310] a. Title bar = Indomethacin - Filling / Flushing

[0311] b. Rate = 120 mL / h

[0312] c. VTBI = 0.3 mL

[0313] d. Duration = 15 seconds

[0314] d. Available volume = 0.41 mL

[0315] 4. Following or in conjunction with the Prime / Flush Infusion Step Setup Screen, the pump or control unit or terminal may present the Main Infusion Step Setup Screen as follows:

[0316] f. Title bar = Indomethacin

[0317] g. Rate = 0.8 mL / h

[0318] h.VTBI=0.1mL

[0319] i. Duration = 30 minutes

[0320] J. Available volume = 0.11 mL

[0321] 5. VTBI can be a dynamically generated value that indicates the remaining dose volume after the fill / flush step. In this case, the value is the order VTBI (0.4) - fill / flush VTBI (0.1) to produce a value of 0.1 mL.

[0322] 6. In this example, the clinician reviews the parameters and selects START (eg, activates a control element on a user interface, activates a soft key, activates an electromechanical button) to begin priming / flushing.

[0323] 7. The pump 30 starts filling at 120 mL / h and the pump or a control unit or terminal associated with the pump may display the incremental filling volume and report the filling start event to the HIS. The report may be one or more messages to the HIS including information about the filling. An example report may be as follows:

[0324]

[0325]

[0326] 8.A. When the infused volume counter reaches 0.3 mL, the pump 30 or a control unit or terminal associated with the pump may present a transition alert on the UI (e.g., on a display). One of these devices may also report the PLUSH transition event to the HIS. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0327] <![CDATA[ Report data ]]> Active loading steps Infusion Events: stop Step Type: PLUSH Step Status: stop Status change reason: Switching steps Drug Reference ID: MED42 Flush Order ID: FLUSH007PRN Infusion Name: Normal saline Amount of medicine: ---- Diluent volume (mL): ---- Rate (mL / h): 120.0000 VTBI(mL): 0.3000 Filling volume (mL): 0.3000

[0328] The state change reason may be indicated using different states, such as "switch container". The selection of the step state may be based on the original APR or subsequent parameters received at the pump or pump module or control unit.

[0329] B. Infusion Complete Report A start event may be transmitted in time with the pump (or pump module) to indicate that the pump (or pump module) has started infusing the primary step, indomethacin. The report may be one or more messages to the HIS including information about the infusion. An example report may be as follows:

[0330] <![CDATA[ Report data ]]> Active Main Steps Infusion Events: start Step Type: Intermittent Step Status: Infusion Status change reason: Start Order ID: MED42 Infusion Name: Indomethacin Amount of medicine: 0.2000mg Diluent volume (mL): 0.4000 Rate (mL / h): 0.8000 VTBI(mL): 0.1000 Volume to be infused (mL): 0.0000

[0331] 9. Once a volume of 0.1 mL has been infused, the pump (or pump module) may stop and report (directly or via the control unit or terminal) an infusion complete event. The report may be one or more messages transmitted to the HIS including information about the infusion. An example report may be as follows:

[0332]

[0333]

[0334] 10. The clinician may load another flush syringe to complete the dose to the patient and continue another workflow, such as discussed in Example Scenario 1, to complete the dose and return the drug line to standby.

[0335] 11. Within the HIS, the clinician will see two entries: one corresponding to the 0.4 mL volume of indomethacin infused in the eMAR, and one corresponding to the 0.3 mL general flush. The clinician may be prompted to record the 0.3 mL of normal saline as the indomethacin fill volume.

[0336] 12. Using the HIS, clinicians can associate a volume of 0.3 mL with a PRN flush order in the eMAR.

[0337] Figure 61-1 is a conceptual diagram illustrating an example electronic system 600 for accurately delivering flush infusion according to aspects of the subject technology. The electronic system 600 may be a system for performing one or more portions or steps of the method 600 or by FIG. Figure 5 The components and methods associated with the provided computing devices include, but are not limited to, computing hardware within the medical device 122, or the syringe pump 30, the control unit 14, and / or any computing device or associated terminal disclosed herein. In this regard, the electronic system 600 can be a personal computer or a mobile device such as a smartphone, a tablet, a laptop, a PDA, an augmented reality device, a wearable device (such as a watch or band or glasses), or a combination thereof, or other touch screen or television having one or more processors embedded therein or coupled thereto, or any other class of computer-related electronic devices with network connectivity.

[0338] The 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, the electronic system 600 includes a bus 608, one or more processing units 612, a system memory 604, a read-only memory (ROM) 610, a permanent storage device 602, an input device interface 614, an output device interface 606, and one or more network interfaces 616. In some embodiments, the electronic system 600 may include or be integrated with other computing devices or circuits for operating the various components and methods described previously.

[0339] Buses 608 collectively represent all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 600. For example, bus 608 communicatively connects one or more processing units 612 with ROM 610, system memory 604, and permanent storage device 602.

[0340] From these various memory units, the one or more processing units 612 retrieve instructions to execute and data to process in order to perform the processes of the subject disclosure. In various implementations, the one or more processing units may be a single processor or a multi-core processor.

[0341] ROM 610 stores static data and instructions required by one or more processing units 612 and other modules of the electronic system. On the other hand, permanent storage device 602 is a read-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 600 is turned off. Some embodiments of the subject disclosure use a mass storage device (such as a magnetic disk or optical disk and its corresponding disk drive) as permanent storage device 602.

[0342] Other embodiments use removable storage devices (such as floppy disks, flash drives and their corresponding disk drives) as permanent storage devices 602. Like permanent storage devices 602, system memory 604 is a read-write memory device. However, unlike storage devices 602, system memory 604 is a volatile read-write memory, such as random access memory. System memory 604 stores some instructions and data that the processor needs at run time. In some embodiments, the processes disclosed in the subject matter are stored in system memory 604, permanent storage devices 602, and / or ROM 610. From these various memory units, one or more processing units 612 retrieve instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0343] The bus 608 is also connected to input and output device interfaces 614 and 606. The input device interface 614 enables a user to communicate information and select commands to the electronic system. Input devices used with the input device interface 614 include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 606 enables, for example, the display of images generated by the electronic system 600. Output devices used with the output device interface 606 include, for example, a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some embodiments include devices such as a touch screen that function as both an input and an output device.

[0344] In addition, if Figure 6 As shown, bus 608 also couples electronic system 600 to a network (not shown) via network interface 616. Network interface 616 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or a radio circuit for connecting to a wireless access point. Network interface 616 may also include hardware (e.g., Ethernet hardware) for connecting a computer to a network (such as the Internet) that is part of a computer network (such as a local area network ("LAN"), a wide area network ("WAN"), a wireless LAN, or an intranet) or a plurality of networks. Any or all components of electronic system 600 may be used in conjunction with the subject disclosure.

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

[0346] Some embodiments include electronic components such as microprocessors, storage, and memory that store computer program instructions in machine-readable or computer-readable media (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, compact disk-read only (CD-ROM), compact disk-recordable (CD-R), compact disk-rewritable (CD-RW), read-only digital versatile disks (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable A disk, an ultra-density optical disk, any other optical or magnetic medium, and a floppy disk. A computer readable medium may store a computer program executable by at least one processing unit and includes multiple sets of instructions for performing various operations. Examples of computer programs or computer code include machine code (such as produced by a compiler), and files including higher-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

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

[0348] As used in the specification and any claims of this application, the terms "computer", "server", "processor" and "memory" refer to electronic or other technical devices. These terms do not include people or groups of people. For the purpose of this specification, the terms display or displaying means displaying on an electronic device. As used in the specification and any claims of this application, the terms "computer-readable medium" and "computer-readable media" are entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other transient signals.

[0349] To provide interaction with a user, embodiments of the subject matter described in this specification may 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 pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and the input from the user may be received in any form, including voice, speech, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0350] The subject matter described in this specification can be implemented in a computing system that includes a back-end component, such as a data server, or includes a middleware component, such as an application server, or includes a front-end component, such as a client computer with a graphical user interface or a web browser, through which a user can interact with the 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 digital data communication (e.g., a communication network) in any form or medium. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internets (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0351] A computing system may include a client and a server. The client and the server are usually remote from each other and may interact via a communication network. The relationship between the client and the server is due to the computer programs running on their respective computers and having a client-server relationship with each other. In some embodiments, the server transmits data (e.g., an HTML page) to a client device (e.g., to display data to a user interacting with the client device and to receive user input from a user interacting with the client device). Data generated at the client device (e.g., the result of the user interaction) may be received from the client device at the server.

[0352] Those skilled in the art will appreciate that various illustrative blocks, modules, elements, assemblies, methods and algorithms described herein can be implemented as electronic hardware, computer software or a combination of the two. In order to illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, assemblies, methods and algorithms are generally described above with regard to their functions. Whether this function is implemented as hardware or software depends on specific applications and the design constraints imposed on the overall system. For each specific application, the described function can be implemented in different ways. Various components and blocks can be arranged differently (for example, arranged in different orders, or partitioned in different ways), and all can not deviate from the scope of subject technology.

[0353] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The accompanying method claims present elements of the various steps in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0354] The subject technology as a description of the terms:

[0355] For convenience, various examples of aspects of the present disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided as examples and do not limit the subject technology. The identification of the figures and reference numbers is provided below only as an example and for illustrative purposes, and the clauses are not limited by these identifications.

[0356] Item 1. A system comprising: a syringe pump comprising a receptacle for receiving a syringe; one or more sensors configured to generate sensor data related to a syringe within the receptacle of the syringe pump; and one or more processors configured to execute instructions and perform operations, including: receiving an indication that a new syringe is loaded into the syringe pump based on the sensor data; determining, after receiving the indication, based on electronically stored information associated with the syringe pump, that the syringe pump is currently associated with a first fluid delivery order for a predetermined amount of a first fluid, and determining that at least a first portion of the first fluid has been previously delivered by the syringe pump in accordance with the first fluid delivery order before the new syringe is loaded into the syringe pump; determining that a second portion of the first fluid remains to be delivered to complete the predetermined amount of the first fluid for the first fluid delivery order; initiating delivery of the second fluid from the new syringe by the syringe pump in accordance with the second fluid delivery order; and automatically, without user intervention, electronically indicating the first fluid delivery order as completed, disassociating the first fluid delivery order from the syringe pump, and associating the syringe pump with the second fluid delivery order when the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered.

[0357] Clause 2. According to the system of clause 1, the operation also includes: receiving an indication that a first syringe loaded in the syringe pump is emptied before a new syringe is loaded into the syringe pump; generating an empty condition for the first fluid delivery order based on receiving the indication that the first syringe is emptied; generating a restart condition for the first fluid delivery order simultaneously with initiating the delivery of the second fluid according to the second fluid delivery order; and generating a start condition for the second fluid delivery order simultaneously with associating the syringe pump with the second fluid delivery order to continue delivering the second fluid from the new syringe.

[0358] Item 3. A system according to Item 2, wherein the delivery of the first fluid and the second fluid is measured in volume units, the operation further comprising: for a first fluid delivery order, continuously measuring the total volume of the first fluid based on the delivery of a portion of the first fluid from the first syringe before an empty condition is generated, and by delivering the second fluid from a new syringe until the amount of the second fluid delivered from the new syringe meets the second portion of the first fluid remaining to be delivered; confirming that the measured total volume of the first fluid has been delivered according to the first fluid delivery order; and providing the total volume for display on a display device.

[0359] Clause 4. A system according to clause 2 or 3, wherein the first fluid is a drug and the second fluid is a non-medicinal flush infusion, the operation further comprising: causing the syringe pump to deliver a portion of the first fluid from the first syringe until an indication is received that the first syringe is emptied; pausing the first fluid delivery order before initiating delivery of the second fluid, wherein, when the first syringe is emptied and delivery of the second fluid is initiated, a second portion of the first fluid remaining to be delivered is residing in an infusion line connected to the syringe pump but has not been delivered to the patient; and in response to initiating delivery of the second fluid, causing the syringe pump to deliver a portion of the first fluid from the infusion line by using the second fluid to push the portion of the first fluid through the infusion line.

[0360] Clause 5. A system according to clause 4, wherein the operation further includes: receiving an automated programming command from a remote computing system to configure the syringe pump to deliver a non-medicinal flush infusion in accordance with a second fluid delivery order; and in response to receiving the automated programming command, without user intervention: disabling a syringe empty alarm that is currently set to be provided when a first syringe loaded in the syringe pump is emptied; and automatically programming the syringe pump to initiate delivery of a second fluid from a new syringe by the syringe pump in accordance with the second fluid delivery order.

[0361] Item 6. A system according to Item 5, wherein the automated programming command causes the syringe pump to: automatically program the syringe pump to initiate delivery of a first fluid from a first syringe according to a first fluid delivery order; prompt the user to unload the first syringe and load a new syringe when the first syringe is emptied; and automatically stop delivering the second fluid when the amount of the second fluid delivered from the new syringe meets the second portion of the remaining first fluid to be delivered.

[0362] Clause 7. A system according to any one of clauses 2 to 6, wherein the operation further includes: causing the syringe pump to deliver the second fluid by driving the motor of the syringe pump in response to initiating delivery of the second fluid from the syringe; and causing the syringe pump to continue to deliver the second fluid from a new syringe by driving the motor of the syringe pump, wherein indicating the first fluid delivery order as completed, disassociating the syringe pump from the first fluid delivery order, associating the syringe pump with the second fluid delivery order, and continuing the delivery of the second fluid are performed without stopping the motor.

[0363] Clause 8. The system of clause 7, wherein indicating the first fluid delivery order as complete comprises associating a type of the second fluid and a flush complete event with the first fluid delivery order.

[0364] Clause 9. A system according to clause 7 or clause 8, wherein the operation further comprises: receiving an indication that a new syringe is emptied based on the generated sensor data; and providing an indication that the second fluid delivery order is complete when the indication that the new syringe is emptied is received.

[0365] Clause 10. A system according to any one of clauses 1 to 9, wherein the operation further includes, when the amount of the second fluid delivered from the new syringe satisfies the second portion of the remaining first fluid to be delivered, automatically, without user intervention: prompting the user to confirm to continue delivering the second fluid from the new syringe; and continuing to deliver the second fluid from the new syringe in response to receiving the confirmation.

[0366] Item 11. A machine-implemented method comprising: receiving an indication from one or more sensors associated with a syringe pump that a new syringe has been loaded into the syringe pump; upon receiving the indication, determining, based on electronically stored information associated with the syringe pump, that the syringe pump is currently associated with a first fluid delivery order for a predetermined amount of a first fluid, and determining that at least a first portion of the first fluid has been previously delivered by the syringe pump in accordance with the first fluid delivery order before the new syringe was loaded into the syringe pump; determining a second portion of the first fluid remaining to be delivered to complete the predetermined amount of the first fluid for the first fluid delivery order; initiating, by the syringe pump, delivery of the second fluid from the new syringe in accordance with the second fluid delivery order; and when the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, automatically, without user intervention: electronically indicating the first fluid delivery order as completed, disassociating the first fluid delivery order from the syringe pump, and associating the syringe pump with the second fluid delivery order.

[0367] Clause 12. The method according to clause 11, further comprising: receiving an indication that a first syringe loaded in a syringe pump is emptied before a new syringe is loaded into the syringe pump; generating an empty condition for a first fluid delivery order based on receiving the indication that the first syringe is emptied; generating a restart condition for the first fluid delivery order simultaneously with initiating delivery of the second fluid according to the second fluid delivery order; and generating a start condition for the second fluid delivery order simultaneously with associating the syringe pump with the second fluid delivery order to continue delivering the second fluid from the new syringe.

[0368] Clause 13. A method according to clause 12, wherein the delivery of the first fluid and the second fluid is measured in volume units, the method further comprising: for a first fluid delivery order, continuously measuring the total volume of the first fluid based on the delivery of the first fluid from the first syringe before an empty condition is generated, and by delivering the second fluid from a new syringe until the amount of the second fluid delivered from the new syringe meets the second portion of the remaining first fluid to be delivered; confirming that the measured total volume of the first fluid has been delivered according to the first fluid delivery order; and providing the total volume for display on a display device.

[0369] Clause 14. A method according to clause 12 or 13, wherein the first fluid is a drug and the second fluid is a non-medicinal flush infusion, the method further comprising: causing the syringe pump to deliver a portion of the first fluid from the first syringe until an indication is received that the first syringe is emptied; pausing the first fluid delivery order before initiating delivery of the second fluid, wherein, when the first syringe is emptied and delivery of the second fluid is initiated, a second portion of the first fluid remaining to be delivered resides in an infusion line connected to the syringe pump but is not delivered to the patient; and in response to initiating delivery of the second fluid, causing the syringe pump to deliver a portion of the first fluid from the infusion line by using the second fluid to push the portion of the first fluid through the infusion line.

[0370] Clause 15. The method according to clause 14, further comprising: receiving an automated programming command from a remote computing system to configure the syringe pump to deliver a non-medicinal flush infusion in accordance with a second fluid delivery order; and in response to receiving the automated programming command, without user intervention: disabling a syringe empty alarm that is currently set to be provided when a first syringe loaded in the syringe pump is emptied; and automatically programming the syringe pump to initiate delivery of a second fluid from a new syringe by the syringe pump in accordance with the second fluid delivery order.

[0371] Item 16. A method according to Item 15, wherein the automated programming command causes the syringe pump to: automatically program the syringe pump to initiate delivery of a first fluid from a first syringe according to a first fluid delivery order; prompt the user to unload the first syringe and load a new syringe when the first syringe is emptied; and automatically stop delivering the second fluid when the amount of the second fluid delivered from the new syringe meets the second portion of the remaining first fluid to be delivered.

[0372] Clause 17. A method according to any one of clauses 12 to 16, the method further comprising: causing the syringe pump to deliver the second fluid by driving the motor of the syringe pump in response to initiating delivery of the second fluid from a new syringe; and causing the syringe pump to continue delivering the second fluid from the new syringe by driving the motor of the syringe pump, wherein indicating the first fluid delivery order as completed, disassociating the syringe pump from the first fluid delivery order, associating the syringe pump with the second fluid delivery order, and continuing the delivery of the second fluid are performed without stopping the motor.

[0373] Clause 18. The method of Clause 17, wherein indicating the first fluid delivery order as complete comprises associating a type of the second fluid and a flush complete event with the first fluid delivery order.

[0374] Clause 19. The method of clause 17 or clause 18, further comprising: receiving an indication that the new syringe is emptied based on the generated sensor data; and providing an indication that the second fluid delivery order is complete upon receiving the indication that the new syringe is emptied.

[0375] Clause 20. A method according to any one of clauses 11 to 19, the method further comprising, when the amount of the second fluid delivered from the new syringe satisfies the second portion of the remaining first fluid to be delivered, automatically, without user intervention: prompting the user to confirm to continue delivering the second fluid from the new syringe; and continuing to deliver the second fluid from the new syringe in response to receiving the confirmation.

[0376] Clause 21. A non-transitory machine-readable storage medium comprising instructions which, when executed by a machine, facilitate the machine to perform the method of any one of clauses 11 to 20.

[0377] Further considerations:

[0378] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The accompanying method claims present elements of the various steps in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0379] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. The preceding 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 apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but to be given the full scope consistent with the language claims, wherein unless specifically so stated, referring to an element in the singular is not intended to mean "one and only one", but "one or more". Unless otherwise specifically stated, the term "some" refers to one or more. Male pronouns (e.g., his) include female and neutral genders (e.g., her and its), and vice versa. Titles and subtitles, if any, are used only for convenience and do not limit the invention described herein.

[0380] The predicates "configured to", "operable to", and "programmed to" do not imply any particular tangible or intangible modification of the subject, but are intended to be used interchangeably. For example, a processor being configured to monitor and control an operation or component may also mean that the processor is programmed to monitor and control the operation or that the processor is operable to monitor and control the operation. Similarly, a processor being configured to execute code may be interpreted as the processor being programmed to execute code or being operable to execute code.

[0381] The term automatically, as used herein, may include being performed by a computer or machine without user intervention; for example, by being responsive to instructions of a predicate action by a computer or machine or other initiating mechanism. The word "exemplary" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0382] Phrases such as "aspects" do not mean that the aspect is essential to the subject technology, or that the aspect applies to all configurations of the subject technology. The disclosure related to the aspect can apply to all configurations, or one or more configurations. An aspect can provide one or more examples. Phrases such as aspects can refer to one or more aspects, and vice versa. Phrases such as "embodiments" do not mean that such embodiments are essential to the subject technology, or that such embodiments are applicable to all configurations of the subject technology. The disclosure related to the embodiment can apply to all embodiments, or one or more embodiments. An embodiment can provide one or more examples. Phrases such as "embodiments" can refer to one or more embodiments, and vice versa. Phrases such as "configurations" do not mean that such configurations are essential to the subject technology, or that such configurations are applicable to all configurations of the subject technology. The disclosure related to the configuration can apply to all configurations, or one or more configurations. A configuration can provide one or more examples. Phrases such as "configurations" can refer to one or more configurations, and vice versa.

[0383] 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 providing information to a user in response to any received input signals. The control elements may include a dial, a button, an icon, a selectable area, or other perceptible marks presented via a UI, and when interacting with the UI (e.g., clicking, touching, selecting, etc.), the UI initiates data exchange with the device presenting the UI. The UI may be implemented in whole or in part using technologies such as hypertext markup language (HTML), FlashTM, JavaTM, .NETTM, Web services, or rich site summaries (RSS). In some embodiments, the UI may be included in an independent client (e.g., a fat client, a fat client), which is configured to communicate (e.g., send or receive data) according to one or more aspects described. The communication may be to or from a medical device or a server communicating with the medical device.

[0384] As used herein, the term "determine" or "determine" includes a variety of actions. For example, "determine" may include estimating, calculating, processing, deriving, generating, obtaining, searching (e.g., searching in a table, a database, or another data structure), ascertaining, etc. via a hardware element without user intervention. In addition, "determine" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. via a hardware element without user intervention. "Determine" may include parsing, selecting, choosing, establishing, etc. via a hardware element without user intervention.

[0385] As used herein, the term "providing" or "supplying" includes a variety of actions. For example, "supplying" may include storing a value in a location of a storage device for subsequent retrieval, sending a value directly to a recipient via at least one wired or wireless communication medium, sending or storing a reference to a value, etc. "Supplying" may also include encoding, decoding, encryption, decryption, validation, verification, etc. via hardware elements.

[0386] As used herein, the term "message" includes a variety of formats for communicating (e.g., sending or receiving) information. A message may include a machine-readable aggregation such as an XML document, a fixed field message, a comma-delimited message, JSON, a custom protocol, or the like. In some embodiments, a message may include a signal for sending one or more representations of information. When stated in the singular, it is understood that a message may be composed, sent, stored, received, etc., in multiple parts.

[0387] As used herein, the terms "selectively" or "selective" include a variety of actions. For example, a "selective" process may include determining an option from a plurality of options. A "selective" process may include: one or more of a dynamically determined input, a preconfigured input, or a user-initiated input for making a determination. In some embodiments, an n-input switch may be included to provide a selective function, where n is the number of inputs used to make a selection.

[0388] As used herein, the term "equivalent to" or "corresponds to" includes a structural, functional, quantitative and / or qualitative correlation or relationship between two or more objects, data sets, information, etc., preferably, wherein the correspondence or relationship can be used to transform one or more of the two or more objects, data sets, information, etc. to appear the same or equal. The correspondence can be evaluated using one or more of a threshold, a value range, fuzzy logic, pattern matching, a machine learning evaluation model, or a combination thereof.

[0389] In any embodiment, the generated or detected data can be forwarded to a "remote" device or location, where "remote" means a location or device other than the location or device where the program is executed. For example, the remote location can be another location in the same city (e.g., office, laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. As such, when a project is indicated as being "remote" from another project, this means that the two projects 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 involves sending data representing information as electrical signals through appropriate communication channels (e.g., dedicated or public networks). "Forwarding" a project refers to any way of bringing a project from one location to the next, whether by physically transmitting the project or otherwise (where possible), and at least in the case of data, including a medium that physically transmits the data or enables the data to communicate. Examples of communication media include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or information including email transmission and recorded on a website, etc.

Claims

1. A system comprising: a syringe pump comprising a receptacle for receiving a syringe; one or more sensors configured to generate sensor data related to the syringe within a receptacle of the syringe pump; as well as One or more processors configured to execute instructions and perform operations including: receiving an indication that a new syringe is loaded into the syringe pump based on the sensor data; determining, upon receiving the indication, based on electronically stored information associated with the syringe pump, that the syringe pump is currently associated with a first fluid delivery order for a predetermined amount of a first fluid, and determining that at least a first portion of the first fluid was previously delivered by the syringe pump pursuant to the first fluid delivery order before the new syringe was loaded into the syringe pump; determining a second portion of the first fluid remaining to be delivered to complete the predetermined amount of the first fluid for the first fluid delivery order; Initiating, by the syringe pump, delivery of a second fluid from the new syringe according to the second fluid delivery order; When the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, automatically without user intervention: electronically indicating the first fluid delivery order as completed, disassociating the first fluid delivery order from the syringe pump, and The syringe pump is associated with the second fluid delivery order.

2. The system of claim 1, wherein the operations further comprise: receiving an indication that a first syringe loaded into the syringe pump is emptied before the new syringe is loaded into the syringe pump; generating an empty condition for the first fluid delivery order based on receiving an indication that the first syringe is empty; generating a restart condition for the first fluid delivery order simultaneously with initiating delivery of the second fluid according to the second fluid delivery order; as well as A start condition for the second fluid delivery order is generated concurrently with associating the syringe pump with the second fluid delivery order to continue delivering the second fluid from the new syringe.

3. The system according to claim 2, wherein: The delivery of the first fluid and the second fluid is measured in volume units, and the operations further include: for the first fluid delivery order, continuously measuring a total volume of the first fluid based on delivery of a portion of the first fluid from the first syringe before the empty condition is generated and through delivery of the second fluid from the new syringe until the amount of the second fluid delivered from the new syringe satisfies a second portion of the first fluid remaining to be delivered; confirming that the measured total volume of the first fluid is delivered according to the first fluid delivery order; and The total volume is provided for display on a display device.

4. The system according to claim 2 or 3, wherein: The first fluid is a drug and the second fluid is a non-drug flush infusate, the operation further comprising: causing the syringe pump to deliver a portion of the first fluid from the first syringe until an indication is received that the first syringe is empty; pausing the first fluid delivery order prior to initiating delivery of the second fluid, wherein when the first syringe is emptied and delivery of the second fluid is initiated, a second portion of the first fluid remaining to be delivered resides in an infusion line connected to the syringe pump but has not been delivered to a patient; and In response to initiating delivery of the second fluid, the syringe pump is caused to deliver the portion of the first fluid from the infusion line by using the second fluid to push the portion of the first fluid through the infusion line.

5. The system of claim 4, wherein the operations further comprise: receiving automated programming commands from a remote computing system to configure the syringe pump to deliver the non-medicinal flush infusate in accordance with the second fluid delivery order; as well as In response to receiving the automated programming command, without user intervention: disabling a syringe empty alarm currently set to be provided when a first syringe loaded in the syringe pump is emptied; as well as The syringe pump is automatically programmed to initiate delivery of a second fluid from the new syringe by the syringe pump according to the second fluid delivery order.

6. The system according to claim 5, wherein: The automated programming commands cause the syringe pump to: automatically programming the syringe pump to initiate delivery of the first fluid from the first syringe by the syringe pump in accordance with the first fluid delivery order; prompting a user to unload the first syringe and load the new syringe when the first syringe is empty; as well as When the amount of the second fluid delivered from the new syringe meets the second portion of the first fluid remaining to be delivered, the delivery of the second fluid is automatically stopped.

7. The system according to any one of claims 2 to 6, wherein the operations further comprise: causing the syringe pump to deliver the second fluid by driving a motor of the syringe pump in response to initiating delivery of the second fluid from the syringe; as well as The syringe pump is caused to continue delivering the second fluid from the new syringe by driving a motor of the syringe pump, wherein indicating the first fluid delivery order as completed, disassociating the syringe pump from the first fluid delivery order, associating the syringe pump with the second fluid delivery order, and continuing delivery of the second fluid are performed without stopping the motor.

8. The system according to claim 7, wherein: Indicating the first fluid delivery order as completed includes: A type of the second fluid and a flush complete event are associated with the first fluid delivery order.

9. The system of claim 7, wherein the operations further comprise: receiving an indication that the new syringe is emptied based on the generated sensor data; as well as An indication that the second fluid delivery order is complete is provided upon receipt of an indication that the new syringe is emptied.

10. The system of any one of claims 1 to 9, wherein the operation further comprises, when the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, automatically without user intervention: prompting the user for confirmation to continue delivering the second fluid from the new syringe; and Delivery of the second fluid from the new syringe is continued in response to receiving the confirmation.

11. A method executed by a machine, comprising: receiving an indication from one or more sensors associated with a syringe pump that a new syringe is loaded into the syringe pump; determining, upon receiving the indication, based on electronically stored information associated with the syringe pump, that the syringe pump is currently associated with a first fluid delivery order for a predetermined amount of a first fluid, and determining that at least a first portion of the first fluid was previously delivered by the syringe pump pursuant to the first fluid delivery order before the new syringe was loaded into the syringe pump; determining a second portion of the first fluid remaining to be delivered to complete the predetermined amount of the first fluid for the first fluid delivery order; Initiating, by the syringe pump, delivery of a second fluid from the new syringe according to the second fluid delivery order; When the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, automatically without user intervention: electronically indicating the first fluid delivery order as completed, disassociating the first fluid delivery order from the syringe pump, and The syringe pump is associated with the second fluid delivery order.

12. The method according to claim 11, further comprising: receiving an indication that a first syringe loaded into the syringe pump is emptied before the new syringe is loaded into the syringe pump; generating an empty condition for the first fluid delivery order based on receiving an indication that the first syringe is empty; generating a restart condition for the first fluid delivery order simultaneously with initiating delivery of the second fluid according to the second fluid delivery order; as well as A start condition for the second fluid delivery order is generated concurrently with associating the syringe pump with the second fluid delivery order to continue delivering the second fluid from the new syringe.

13. The method according to claim 12, wherein: The delivery of the first fluid and the second fluid is measured in volume units, and the method further comprises: for the first fluid delivery order, continuously measuring a total volume of the first fluid based on delivery of the first fluid from the first syringe before the empty condition is generated and through delivery of the second fluid from the new syringe until the amount of the second fluid delivered from the new syringe satisfies a second portion of the first fluid remaining to be delivered; confirming that the measured total volume of the first fluid is delivered according to the first fluid delivery order; and The total volume is provided for display on a display device.

14. The method according to claim 12 or 13, wherein: The first fluid is a drug and the second fluid is a non-drug flush infusate, the method further comprising: causing the syringe pump to deliver a portion of the first fluid from the first syringe until an indication is received that the first syringe is empty; pausing the first fluid delivery order prior to initiating delivery of the second fluid, wherein when the first syringe is emptied and delivery of the second fluid is initiated, a second portion of the first fluid remaining to be delivered resides in an infusion line connected to the syringe pump but is not delivered to a patient; and In response to initiating delivery of the second fluid, the syringe pump is caused to deliver the portion of the first fluid from the infusion line by using the second fluid to push the portion of the first fluid through the infusion line.

15. The method according to claim 14, further comprising: receiving automated programming commands from a remote computing system to configure the syringe pump to deliver the non-medicinal flush infusate in accordance with the second fluid delivery order; as well as In response to receiving the automated programming command, without user intervention: disabling a syringe empty alarm currently set to be provided when a first syringe loaded in the syringe pump is emptied; as well as The syringe pump is automatically programmed to initiate delivery of a second fluid from the new syringe by the syringe pump according to the second fluid delivery order.

16. The method according to claim 15, wherein: The automated programming commands cause the syringe pump to: automatically programming the syringe pump to initiate, by the syringe pump, delivery of a first fluid from the first syringe in accordance with the first fluid delivery order; prompting a user to unload the first syringe and load the new syringe when the first syringe is empty; and When the amount of the second fluid delivered from the new syringe meets the second portion of the first fluid remaining to be delivered, the delivery of the second fluid is automatically stopped.

17. The method according to any one of claims 12 to 16, further comprising: causing the syringe pump to deliver the second fluid by driving a motor of the syringe pump in response to initiating delivery of the second fluid from the new syringe; as well as The syringe pump is caused to continue delivering the second fluid from the new syringe by driving a motor of the syringe pump, wherein indicating the first fluid delivery order as completed, disassociating the syringe pump from the first fluid delivery order, associating the syringe pump with the second fluid delivery order, and continuing delivery of the second fluid are performed without stopping the motor.

18. The method according to claim 17, wherein: Indicating the first fluid delivery order as completed includes: A type of the second fluid and a flush complete event are associated with the first fluid delivery order.

19. The method according to claim 17, further comprising: receiving an indication that the new syringe is emptied; as well as An indication that the second fluid delivery order is complete is provided upon receipt of an indication that the new syringe is emptied.

20. The method of any one of claims 11 to 19, further comprising, when the amount of the second fluid delivered from the new syringe satisfies the second portion of the first fluid remaining to be delivered, automatically without user intervention: prompting the user for confirmation to continue delivering the second fluid from the new syringe; and Delivery of the second fluid from the new syringe is continued in response to receiving the confirmation.

21. A non-transitory machine-readable storage medium comprising instructions which, when executed by a machine, facilitate the machine to perform the method of any one of claims 11 to 20.

Images