Patent Description:
Infusion pumps are useful medical devices for managing the delivery and dispensation of infusates such as therapeutic medications and drugs. Infusion pumps provide significant advantages over manual administration of infusates by accurately delivering the infusates over an extended period of time. Infusion pumps are particularly useful for treating diseases and disorders that require regular pharmacological intervention, including cancer, diabetes, and vascular, neurological, and metabolic disorders. Infusion pumps also enhance the ability of healthcare providers to deliver anesthesia and manage pain. Infusion pumps are used in various settings, including hospitals, nursing homes, and other short-term and long-term medical facilities, as well as in residential care settings. There are many types of infusion pumps, including ambulatory, large volume, patient-controlled analgesia (PCA), elastomeric, syringe, enteral, and insulin pumps. Infusion pumps can be used to administer medication through various delivery methods, including intravenously, intraperitoneally, intra-arterially, intradermally, subcutaneously, in close proximity to nerves, and into an intraoperative site, epidural space or subarachnoid space.

For example, syringe pumps and related components are disclosed in <CIT> titled "Infusion Pump with Bar Code Input to Computer," <CIT> titled "Syringe Pump Rapid Occlusion Detection System," and <CIT> titled "Updating Syringe Profiles for a Syringe Pump.

Typically, infusion pumps are individually programmed without context to any role or position within a larger medical procedure or patient treatment activity. For example, current drug libraries typically focus on programming one medicament or drug on one pump as directed by a medical practitioner. Concentration limits, volume limits, and other limits or boundaries, as well as other medicament or drug programming parameters are usually set individually for each such infusate and the pump is programmed within those boundaries.

For example, an anesthesiologist in an operating room often operates multiple infusion pumps at the same time. It is not uncommon for several infusion pumps to be employed to deliver various infusates to a single patient. Further, it is not uncommon for multiple surgeries to be performed on multiple patients on the same day. Thus, in a single day, an anesthesiologist in an operating room might operate several sets of infusion pumps with the same or similar medicaments or drugs set to similar or nearly the same respective doses for those multiple surgeries. In traditional infusion systems, the anesthesiologist must spend time programming each of the infusion pumps separately, and respectively program each of the infusion pumps for each surgery. It might take, for example, <NUM> minutes for the anesthesiologist to program all of the infusion pumps for a single surgery. Over the course of the day, the anesthesiologist could therefore spend several hours programming infusion pumps for the same medicaments or drugs at similar or nearly the same respective doses. This sort of repetitive, individual programming of pumps is laborious, time-consuming, and potentially error-prone.

Document <CIT> discloses the programming of such a multiple pumps infusion system, but in this example every pumps requires a dedicated programming.

Therefore there is a need for devices, systems, and methods for procedure-based programming for infusion pumps that can minimize the repetitive, laborious, time-consuming, and potentially error-prone interactions of traditional infusion pump programming tasks.

Subject matter hereof may be more completely understood in consideration of the following detailed description of various embodiments of the subject matter in connection with the accompanying drawings, in which:.

While embodiments are amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit subject matter hereof to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of subject matter hereof in accordance with the appended claims.

<FIG> show examples of infusion pumps <NUM> and <NUM>, respectively (also referred to more generally in this disclosure by numeral <NUM>), which can be used to implement embodiments of the systems and methods discussed herein. In general, infusion pump <NUM> is a syringe-type pump that can be used to deliver a wide range of infusates, drug therapies and treatments. Infusion pump <NUM> includes a pharmaceutical container or syringe <NUM>, which is supported on and secured to housing <NUM> by clamp <NUM>, respectively. In embodiments, syringe <NUM> can be separately supplied from pump <NUM>. In other embodiments, syringe <NUM> is an integrated component of pump <NUM>. Syringe <NUM> includes a plunger <NUM> that forces fluid outwardly from syringe <NUM> via infusion line <NUM> that is connected to a patient. A motor and lead screw arrangement internal to housing <NUM> of pump <NUM> cooperatively actuates a pusher or plunger driver mechanism <NUM>, to move plunger <NUM> of syringe <NUM>. In embodiments, a sensor (not shown; which is typically internal to plunger driver mechanism <NUM>) monitors force and/or plunger position in the syringe according to system specifications.

Infusion pump <NUM> shown in <FIG> is an example of an ambulatory-type infusion pump that can be used to deliver a wide range of infusates, drug therapies, and treatments. Such ambulatory pumps can be comfortably worn by or otherwise removably coupled to a user for in-home ambulatory care by way of belts, straps, clips or other simple fastening means, and can also be alternatively provided in ambulatory pole-mounted arrangements within hospitals and other medical care facilities. Infusion pump <NUM> generally includes a peristaltic type infusion pump mechanism that controls the flow of medication from a reservoir (not shown in <FIG>) of fluid coupled to pump <NUM> through a conduit from the reservoir which can matingly pass along bottom surface <NUM> of pump <NUM>. The reservoir can comprise a cassette that is attached to the bottom of pump <NUM> at surface <NUM>, or an IV bag or other fluid source that is similarly connected to pump <NUM> via an adapter plate (not shown) at surface <NUM>. Specifically, pump <NUM> uses valves and an expulsor located on bottom surface <NUM> to selectively squeeze a tube of fluid (not shown) connected to the reservoir to effect the movement of the fluid supplied by the reservoir through the tube and to a patient in peristaltic pumping fashion. Infusion pumps <NUM> and <NUM> are two examples of infusion pumps that can be suitable for use with embodiments discussed herein, though other pumps and devices can be used in other embodiments of infusion systems utilizing subject matter hereof.

<FIG> is a schematic diagram of an infusion pump system <NUM>. System <NUM> includes infusion pump <NUM> having pump control system <NUM> with processor <NUM> and memory <NUM> programmable with selected protocols, profiles, segments of profiles, and other settings for controlling operation of pumping mechanism <NUM> such as, for example, the aforementioned syringe and ambulatory or peristaltic type mechanisms. In an embodiment, memory <NUM> can comprise a drug library or portions thereof configured for programming according to the functional sets described herein.

In an embodiment, processor <NUM> can be any programmable device that accepts digital data as input, is configured to process the input according to instructions or algorithms, and provides results as outputs. In an embodiment, processor <NUM> can be a central processing unit (CPU) configured to carry out the instructions of a computer program. In another embodiment, processor <NUM> can be an application specific integrated circuit (ASIC). In another embodiment, processor <NUM> can be a field-programmable gate array (FPGA). Processor <NUM> is therefore configured to perform arithmetical, logical, and input/output operations.

Memory <NUM> can comprise volatile or non-volatile memory as required by the coupled processor <NUM> to not only provide space to execute the instructions or algorithms, but to provide the space to store the instructions themselves. In embodiments, volatile memory can include random access memory (RAM), dynamic random access memory (DRAM), or static random access memory (SRAM), for example. In embodiments, non-volatile memory can include read-only memory, flash memory, ferroelectric RAM, hard disk, floppy disk, magnetic tape, or optical disc storage, for example. The foregoing lists in no way limit the type of memory that can be used, as these embodiments are given only by way of example and are not intended to limit the scope of subject matter hereof.

Infusion pump <NUM> can also include control module <NUM> (e.g., a user interface) for relaying commands to pump control system <NUM>. Control module <NUM> includes at least one user interface <NUM> utilizing operator input technology including input mechanism(s) <NUM>, which work with display <NUM>. In some cases display <NUM> will be considered part of user interface(s) <NUM>. User interface <NUM> generally allows a user to enter various parameters, including but not limited to names, drug information, limits, delivery shapes, information relating to hospital facilities, as well as various user-specific parameters (e.g., patient age and/or weight). Infusion pump <NUM> can include a USB port, Ethernet, Wi-Fi or other appropriate input/output (I/O) interface port <NUM> for connecting infusion pump <NUM> to network or computer <NUM> having software designed to interface with infusion pump <NUM>. In an embodiment, network or computer <NUM> can transmit a drug library or portions thereof for programming according to the functional sets described herein. For example, network or computer <NUM> can comprise an embedded server system for controlling, in real-time, infusion pump <NUM>. In embodiments, control module <NUM> can be automatically configured according to data from network or computer <NUM> (or the embedded server) for programming according to functional sets.

Power to infusion pump <NUM> is accomplished via an AC or DC power cord or any suitable battery source. Embodiments can also include a wireless power source. User inputs <NUM> to the system can be provided by programming from a user, such as a patient, pharmacist, scientist, drug program designer, medical engineer, nurse, physician, or other medical practitioner or healthcare provider. User inputs <NUM> may utilize direct interfacing (i.e., a keyboard or other touch-based inputs) or user inputs <NUM> may utilize indirect or "touchless" interfacing (i.e., gestures; voice commands; facial movements or expressions; finger, hand, head, body and arm movements; or other inputs that do not require physical contact). User inputs <NUM> are generally interfaced, communicated, sensed, and/or received by operator input mechanisms <NUM> of user interface <NUM>. Operator input mechanisms <NUM> may include, for example, keyboards, touch screens, cameras, or sensors of electric field, capacitance, or sound.

As depicted in <FIG>, infusion pump <NUM> is operably coupled to reservoir <NUM> via pumping mechanism <NUM>. In embodiments, reservoir <NUM> can comprise any suitable infusate supply, such as an IV bag, syringe, continuous supply, or other infusate storage. In an embodiment, reservoir <NUM> is coupled to pumping mechanism <NUM> by cannula suitable for transferring infusate stored in reservoir <NUM> to pumping mechanism <NUM>.

Referring to <FIG>, a block diagram of a portion of a generic drug library <NUM> including functional sets is depicted, according to an embodiment. Drug library <NUM> generally comprises Functional Set A <NUM> and Functional Set B <NUM>. For example, Functional Set A <NUM> can comprise a department-level procedure for emergencies, in an emergency room department. In another example Functional Set B <NUM> can comprise a particular procedure for a particular department, such as cardiac surgery.

Functional Set A <NUM> comprises a set of medications <NUM> to be infused. For example, set of medications <NUM> can be defined by Drug <NUM>, Drug <NUM>, and Drug <NUM>, as depicted in <FIG>. Each of the individual medications in set of medications <NUM> can be utilized to individually address a need of Functional Set A <NUM>. In an embodiment, in combination, the individual medications within set of medications <NUM> are configured to complement each other to positively affect the patient being infused. In other embodiments, a medical practitioner can select among set of medications <NUM> for infusion. For example, only Drug <NUM> and Drug <NUM> might be utilized for a particular patient. Drug library <NUM> allows for easy selection of subgroups of set of medications <NUM>. Likewise, Functional Set B <NUM> comprises a set of medications <NUM> to be infused. For example, set of medications <NUM> can be defined by Drug <NUM>, Drug <NUM>, Drug <NUM>, and Drug <NUM>, as depicted in <FIG>.

Set of medications <NUM>, and particularly, Drug <NUM>, Drug <NUM>, and Drug <NUM> can be respectively configured for programming on a particular set of pumps <NUM>. For example, set of pumps <NUM> can generally include Infusion Pump <NUM>, Infusion Pump <NUM>, and Infusion Pump <NUM>. In an embodiment, Drug <NUM> can be configured for programming on Infusion Pump <NUM>, Drug <NUM> can be configured for programming on Infusion Pump <NUM>, and Drug <NUM> can be configured for programming on Infusion Pump <NUM>. In other embodiments (not shown), set of infusions <NUM> can be defined such that pumps can be programmed ad-hoc. Likewise, set of infusions <NUM>, and particularly, Drug <NUM>, Drug <NUM>, Drug <NUM>, and Drug <NUM> can be respectively configured for programming on a particular set of pumps <NUM>. For example, set of pumps <NUM> can generally include Infusion Pump <NUM>, Infusion Pump <NUM>, Infusion Pump <NUM>, and Infusion Pump <NUM>.

Therefore, by selecting Functional Set A <NUM>, a medical practitioner can program the infusions defined by set of medications <NUM> on set of pumps <NUM>. Likewise, by selecting Functional Set B <NUM>, a medical practitioner can program the infusions defined by set of medications <NUM> on set of pumps <NUM>.

Referring to <FIG>, a block diagram of a procedure-based programming configuration <NUM> for a cardiac surgery procedure <NUM> is depicted, according to an embodiment. Configuration <NUM> generally comprises a quick setup procedure, such as cardiac surgery procedure <NUM>.

Cardiac surgery procedure <NUM> comprises a set of infusates <NUM>-<NUM>. For example, cardiac surgery procedure <NUM> can comprise a programming configuration for an infusion pump for sodium bicarbonate <NUM>, a programming configuration for an infusion pump for saline <NUM>, a programming configuration for an infusion pump for fenoldopam <NUM>, a programming configuration for an infusion pump for insoline <NUM>, a programming configuration for an infusion pump for remifentanil <NUM>, and a programming configuration for an infusion pump for saline <NUM>.

In an embodiment, a drug library can be utilized that defines a set of medications for the procedure <NUM> and the infusates <NUM>-<NUM>, such as drug library <NUM>. Optionally, and as described with respect to drug library <NUM>, the drug library can define a set of pumps for administering the set of infusates. As a result, a drug library, such as drug library <NUM>, can comprise a "Workflow Management" programming configuration or "Procedure Management" programming configuration option. Drug library <NUM> therefore supports more than one pump being programmed concurrently. In another embodiment, a "Workflow Management" programming configuration or "Procedure Management" programming configuration option can be selected on a pump, such as infusion pump <NUM> in <FIG>.

Referring to <FIG>, an annotated block diagram of a system <NUM> for programming a set of infusion pumps for functional set programming is depicted, according to an embodiment. In particular, system <NUM> is configured for the programming of the cardiac surgery procedure of <FIG> System <NUM> generally comprises a server <NUM>, a drug library <NUM>, and a set of infusion pumps <NUM>-<NUM>.

In embodiments, set of infusion pumps <NUM>-<NUM> can be operably coupled to a networked rack. The rack can be configured to physically and removably couple the set of infusion pumps <NUM>-<NUM>. In an embodiment, the rack further comprises a router configured to enable digital communications between the set of infusion pumps <NUM>-<NUM>. For example, a router and set of infusion pumps <NUM>-<NUM> can comprise a local area network such the set of infusion pumps <NUM>-<NUM> are physically coupled to the rack and electrically coupled to the local area network through the router.

In an embodiment, server <NUM> comprises a processor and a memory. In an embodiment, the processor can be any programmable device that accepts digital data as input, is configured to process the input according to instructions or algorithms, and provides results as outputs. In an embodiment, the processor can be a central processing unit (CPU) configured to carry out the instructions of a computer program. In another embodiment, the processor can be an application specific integrated circuit (ASIC). In another embodiment, the processor can be a field-programmable gate array (FPGA). The processor is therefore configured to perform basic arithmetical, logical, and input/output operations.

The memory can comprise volatile or non-volatile memory as required by the coupled processor to not only provide space to execute the instructions or algorithms, but to provide the space to store the instructions themselves. In embodiments, volatile memory can include random access memory (RAM), dynamic random access memory (DRAM), or static random access memory (SRAM), for example. In embodiments, non-volatile memory can include read-only memory, flash memory, ferroelectric RAM, hard disk, floppy disk, magnetic tape, or optical disc storage, for example. In an embodiment, the memory can comprise a database. In an embodiment, the memory comprises memory for operation of the processor and a separate database for storing records related to the system. The foregoing lists in no way limit the type of memory that can be used, as these embodiments are given only by way of example and are not intended to limit the scope of the subject matter hereof.

A plurality of engines can be implemented by or according to the processor and memory of server <NUM>. For example, any number of engines can be configured to coordinate the programming of the set of pumps <NUM>-<NUM>, as directed by drug library <NUM>. As such, server <NUM> is communicatively coupled to at least one of infusion pumps <NUM>-<NUM>. In an embodiment, referring to infusion pump system <NUM> in <FIG>, server <NUM> comprises a network or computer similar to network or computer <NUM> having software designed to interface with infusion pumps <NUM>-<NUM>. In an embodiment, server <NUM> can comprise a real-time embedded server, such as embodiments of the embedded server described in the aforementioned <CIT>. It is therefore to be appreciated and understood that, although depicted in <FIG> separately from pumps <NUM>-<NUM>, server <NUM> could physically reside in the rack or even in one of pumps <NUM>-<NUM>.

Server <NUM> can be configured to transmit a set of programming instructions that comprise part of a functional set larger than programming for a single pump. For example, a set of programming instructions can comprise a unique programming configuration for each coupled pump. In an embodiment, the set of programming instructions comprises a batch programming command that contains the programming instructions for all coupled pumps <NUM>-<NUM>. In such embodiments, each pump is only programmed according to the particular instructions intended for that particular pump but receives the batch or aggregated programming instructions for all pumps. In embodiments, pump identifiers or other unique data sets can be utilized to parse the batch programming command. In another embodiment, server <NUM> individually transmits the programming instructions for all coupled pumps <NUM>-<NUM> to each of the coupled pumps <NUM>-<NUM>. In still another embodiment, one of pumps <NUM>-<NUM> further directs the programming command after receipt from server <NUM>.

Drug library <NUM> comprises a database of functional sets including a set of medications to be infused for each level such as, for example, the aforementioned department-level procedure for emergencies. In an embodiment, drug library <NUM> is substantially similar to the portion of drug library <NUM> depicted in <FIG>. For example, drug library <NUM> can comprise cardiac surgery procedure <NUM> and set of medications <NUM>-<NUM> as depicted and described with respect to <FIG>. Referring again to <FIG>, as depicted, drug library <NUM> is operably coupled to server <NUM>. In an embodiment, drug library <NUM> can be embodied on server <NUM>. In another embodiment, drug library <NUM> can be embodied on a separate database accessible by server <NUM>.

Each of set of pumps <NUM>-<NUM> can be substantially similar to infusion pump <NUM> as depicted and described with respect to <FIG>. In an embodiment, set of pumps <NUM>-<NUM> are communicatively coupled to each other. For example, pump <NUM> can be operably and communicatively coupled to each of pumps <NUM>-<NUM> such that pump <NUM> can command programming to each of pumps <NUM>-<NUM>. In another example embodiment, each of pumps <NUM>-<NUM> is communicatively coupled to server <NUM>. In embodiments, pumps <NUM>-<NUM> can be communicatively coupled such that data, commands, messages, or any other information specific to one of pumps <NUM>-<NUM> can be passed to any of the other pumps <NUM>-<NUM>. For example, pumps <NUM>-<NUM> can be operably coupled to a networked rack.

In operation, as depicted by the annotations in <FIG>, server <NUM> communicates with drug library <NUM> to define the functional set programming for pumps <NUM>-<NUM>. Server <NUM> communicates with pump <NUM> after a functional set programming is selected on pump <NUM>. In another embodiment, functional set programming is initiated by server <NUM>. In another embodiment, a clinician interfaces with one of associated pumps and selects the desired work flow for the upcoming procedure. This pump then sends programming information to the other of the associated plurality of pumps <NUM>-<NUM>. The programming information can include infusion information such as drug, dose, concentration, and weight, as needed per the infusion type. In an embodiment, after the initial programming, the pumps do not automatically control each other.

As depicted in <FIG>, "Cardiac Surgery Quick Setup" is selected on pump <NUM>. Pump <NUM> interfaces with server <NUM>, and pump <NUM> is correspondingly programmed for a particular infusion defined by the functional set infusions for Cardiac Surgery. For example, referring again to <FIG>, and cardiac surgery procedure <NUM>, pump <NUM> can be programmed for an infusion of sodium bicarbonate <NUM>. Subsequently or concurrently with the programming of pump <NUM>, pumps <NUM>-<NUM> receive programming information from pump <NUM>. In an embodiment, pump <NUM> can transmit a programming command to pumps <NUM>-<NUM>. For example, in an embodiment, and referring again to <FIG>, pump <NUM> is programmed for an infusion of saline <NUM>. Pump <NUM> is programmed for an infusion of fenoldopam <NUM>. Pump <NUM> is programmed for an infusion of insoline <NUM>. Pump <NUM> is programmed for an infusion of remifentanil <NUM>. Pump <NUM> is programmed for an infusion of saline <NUM>. In another embodiment (not depicted), server <NUM> transmits a programming instruction separately to each of pumps <NUM>-<NUM> in either a batched command or individual commands unique to each pump. Irrespective of a particular programming architecture, pumps <NUM>-<NUM> to be used in the procedure are thus associated with each other. Pumps <NUM>-<NUM> could be associated by being plugged into the same rack or they could be associated manually through serial number, MAC (media access control) address, same subnet, barcode, or any other suitable association method.

Referring to <FIG>, a block diagram of a system <NUM> for programming a set of infusion pumps according to a functional set is depicted, according to an embodiment. System <NUM> generally comprises inputs of hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM> into programming engine <NUM> for programming of a plurality of infusion pumps <NUM>-<NUM>.

Hospital data <NUM> generally comprises hospital-level data or information related to infusions. For example, hospital data <NUM> can comprise hospital procedures, standards, configurations, and other hospital-centric information.

Patient data <NUM> generally comprises patient-specific data or information. For example, patient data <NUM> can comprise patient height, patient weight, patient gender, patient ID, allergy information, and any other suitable patient-specific information. Sensor data <NUM> generally comprises readings, levels, or other statuses provided by any sensors configured for sensing information about the patient. For example, sensor data <NUM> can comprise temperature data, pulse rate, breathing rate, blood oxygen levels, and blood pressure, and any other suitable sensor data.

Procedure data <NUM> generally comprises a functional set selection of a set of medications to be infused. In an embodiment, procedure data <NUM> can comprise a functional set selection as defined by <FIG> and, for example, Functional Set A <NUM> or Functional Set B <NUM>. For example, procedure data <NUM> can comprise "Cardiac Surgery Quick Setup" as depicted in <FIG>.

In embodiments, hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM> can be received by communications engine <NUM> from a respective sending apparatus. For example, a Hospital Information System (HIS) can transmit hospital data <NUM> and/or patient data <NUM> to communications engine <NUM>. Each of the respective sensors configured to sense characteristics about or related to the patient can transmit the respective sensor data <NUM> to communications engine <NUM>. Procedure data <NUM> can be selected or input as described with respect to <FIG> and subsequently transmitted to communications engine <NUM>. In embodiments, additional or fewer data inputs can be utilized by system <NUM>.

Programming engine <NUM> generally comprises a functional set drug library <NUM>, a processor <NUM>, and a communications engine <NUM>. In an embodiment, programming engine <NUM> is embodied on a discrete server, such as server <NUM> as depicted in <FIG>. However, in other embodiments, programming engine <NUM> is embodied on an individual medical device, such as one of the plurality of coupled infusion pumps <NUM>-<NUM>. In other embodiments, portions of the engines described herein can be spread across multiple devices, such as a discrete server or an infusion pump.

The engines described herein can be constructed, programmed, configured, or otherwise adapted, to autonomously carry out a function or set of functions. The term engine as used throughout this document is defined as a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or field-programmable gate array (FPGA), for example, or as a combination of hardware and software, such as by a microprocessor system and a set of program instructions that cause the engine to implement the particular functionality, which (while being executed) transform the microprocessor system into a special-purpose device. An engine can also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of an engine can be executed on the processor(s) of one or more computing platforms that are made up of hardware (e.g., one or more processors, data storage devices such as memory or drive storage, input/output facilities such as network interface devices, video devices, keyboards, mouse or touchscreen devices, etc.) that execute an operating system, system programs, and application programs, while also implementing the engine using multitasking, multithreading, distributed (e.g., cluster, peer-peer, cloud, etc.) processing where appropriate, or other such techniques. Accordingly, each engine can be realized in a variety of physically embodied configurations, and should generally not be limited to any particular implementation exemplified herein, unless such limitations are expressly called out. In addition, an engine can itself be composed of more than one sub-engines, each of which can be regarded as an engine in its own right. Moreover, in the embodiments described herein, each of the various engines corresponds to a defined autonomous functionality; however, it should be understood that in other contemplated embodiments, each functionality can be distributed to more than one engine. Likewise, in other contemplated embodiments, multiple defined functionalities may be implemented by a single engine that performs those multiple functions, possibly in parallel or series with, and/or complementary to other functions, or distributed differently among a set of engines than specifically illustrated in the examples herein.

Drug library <NUM> comprises a database of functional sets including a set of medications to be infused for each level. In an embodiment, drug library <NUM> is substantially similar to the portion of drug library <NUM> depicted in <FIG>. In embodiments, drug library <NUM> can comprise a set of medications defining the respective medication amounts and infusion rates that are varied depending on a number of factors, including inputs related to hospital data <NUM>, patient data <NUM>, and sensor data <NUM>. For example, the amounts and infusion rates of the set of medications for a selected functional set for a <NUM> lb male patient can be significantly different than for a <NUM> lb female patient. Drug library <NUM> is configured to store these differing sets of medications. As such, multiple sets of medications can be defined for each functional set.

Processor <NUM> comprises processing logic and suitable hardware for implementing the processing logic to evaluate received hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM> and determine an appropriate set of infusions from drug library <NUM>. Processor <NUM> is further configured to command programming of a set of infusions to infusion pumps <NUM>-<NUM>. In embodiments, processor <NUM> can be operably coupled to memory (not shown in <FIG>).

In embodiments, processor <NUM> is further configured to suggest or automatically adjust the previously-determined set of infusions or infusion parameters. For example, additional hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and/or procedure data <NUM> can be received and evaluated to modify or adjust infusion parameters. In an embodiment, such additional hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and/or procedure data <NUM> can be received and evaluated after the initial set of infusions or infusion parameters have been commanded and are operational. In embodiments, evaluation of hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and/or procedure data <NUM> can be on regular intervals or continuous.

Communications engine <NUM> comprises communication logic and suitable hardware for receiving hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM>. Further, communications engine <NUM> comprises communication logic and suitable hardware for transmitting programming commands to infusion pumps <NUM>-<NUM>.

Each of infusion pumps <NUM>-<NUM> can be substantially similar to infusion pump <NUM> as depicted and described with respect to <FIG>. In embodiments, additional or fewer infusion pumps can be programmed.

In operation, system <NUM> is configured for the programming of infusion pumps <NUM>-<NUM> according to a functional set. Hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM> are input into programming engine <NUM>. In an embodiment, hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM> are received by communications engine <NUM>. In an embodiment, the data received by communications engine <NUM> is stored. For example, memory operably coupled to processor <NUM> can store the received data.

Processor <NUM> evaluates received hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM> in view of drug library <NUM>. For example, as selected by procedure data <NUM>, a set of medications to be infused is chosen. Processor <NUM> can then utilize drug library <NUM> in view of received hospital data <NUM>, patient data <NUM>, and sensor data <NUM> to select a particular set of medications specific for the unique combination defined by the received data.

Subsequently, processor <NUM> transmits a programming signal to any of infusion pump <NUM>, infusion pump <NUM>, infusion pump <NUM>, or additional infusion pumps (not shown in <FIG>). As a result, the pumps receiving the programming signal, such as infusion pump <NUM>, infusion pump <NUM>, infusion pump <NUM>, or additional infusion pumps, are programmed for the respective infusion defined by drug library <NUM> for the selected procedure data <NUM> and the unique combination defined by the received hospital data <NUM>, patient data <NUM>, and sensor data <NUM>.

According to embodiments, grouping principles such as functional sets can be applied such that a hierarchy is adhered to so that higher levels are placed near the "top" with more specific concepts underneath. The higher the level, the less detail is presented to the user. The lower the level, the more detail is presented to the user. In embodiments, a drug library can be grouped according to various functional set hierarchies.

For example, referring to <FIG>, a block diagram of an example functional set according to a hierarchy <NUM> in a hospital network is depicted, according to an embodiment. Hierarchy <NUM> generally comprises a hospital network level <NUM>, a hospital level <NUM>, a department level <NUM>, a procedure level <NUM>, and an infusion level <NUM>.

As depicted, hospital network <NUM> generally comprises one or more hospitals <NUM>. A particular hospital <NUM> generally comprises one or departments <NUM>. A particular department <NUM> generally comprises one or more procedures <NUM>. Each procedure <NUM> generally comprises one or more infusions <NUM>. In embodiments, any of the aforementioned levels can be omitted such that programming of infusions does not adhere to the hierarchical flow depicted in <FIG>. For example, depending on the procedures and guidelines for the particular hospital network <NUM> and/or hospital <NUM>, additional or fewer functional sets can be utilized.

In embodiments, referring again to <FIG>, programming hierarchies can be implemented at any of the aforementioned levels. As a result, programming hierarchies can be carried down through the lower functional sets. For example, at hospital network <NUM>, generalized infusions <NUM> common to all hospitals <NUM> in hospital network <NUM> can be defined. In turn, all of the generalized infusions <NUM> common to all hospitals <NUM> in hospital network <NUM> are carried through the lower levels and thus available to all departments <NUM> and procedures <NUM>. In this way, particular hospital networks <NUM> can define sets of infusions <NUM> unique to that hospital network <NUM>.

Likewise, at hospital <NUM>, generalized infusions <NUM> common to all departments <NUM> in a particular hospital <NUM> can be defined. In turn, all of the generalized infusions <NUM> common to all departments <NUM> in hospital <NUM> are carried through the lower levels and thus available to all procedures <NUM>. In this way, particular hospitals <NUM> can define sets of infusions <NUM> unique to that hospital <NUM>.

Similarly, each department <NUM> can define sets of infusions <NUM> unique to that particular department <NUM>. For example, infusions <NUM> that are specific to the "surgery" department <NUM> can be implemented such that the higher level infusion definitions are available for use, as well as the surgery-specific infusions defined at the department <NUM> level.

In another example, referring to <FIG>, a block diagram of an example hierarchy <NUM> in a hospital network is depicted, according to an embodiment. Hierarchy <NUM> generally comprises a hospital network level <NUM>, a hospital level <NUM>, a department level <NUM>, a procedure level <NUM>, and an infusion level <NUM>. In the example depicted, infusions <NUM> can be defined at any level within hierarchy <NUM>. In embodiments, infusions <NUM> are defined such that no generalized infusions are carried through the lower functional sets.

Referring to <FIG>, a flowchart of a method <NUM> for procedure-based programming of a plurality of infusion pumps in a functional set is depicted, according to an embodiment.

At <NUM>, a plurality of infusion pumps are implemented. For example, each of the plurality of infusion pumps can be substantially similar to any of the infusion pumps described herein, such as infusion pump <NUM> as depicted in <FIG>. In an embodiment, the plurality of infusion pumps can be activated, turned on, or otherwise prepared for operation. In embodiments, the plurality of infusion pumps are operably coupled to a patient. In another embodiment, the plurality of infusion pumps are staged for coupling to a patient.

At <NUM>, a drug library including one or more functional sets is implemented. For example, the drug library can be substantially similar to any of the drug libraries described herein, such as the template of the portion of generic drug library <NUM> as depicted in <FIG>. In an embodiment, implementing the drug library comprises receiving inputs that define the functional set and the corresponding set of medications to be infused. In embodiments, other inputs can define the number or type of infusion pumps needed or other criteria or fields related to the set of medications to be infused.

At <NUM>, input data is received. In an embodiment, input data comprises a functional set selection. For example, referring to <FIG>, procedure data <NUM> is input into programming engine <NUM> as the selected functional set. In other embodiments, input data further comprises hospital data, patient data, and/or sensor data. For example, referring again to <FIG>, inputs such as hospital data <NUM>, patient data <NUM>, and sensor data <NUM> are input into programming engine <NUM>. Input data can be received by manual input into the programming engine, such as on a pump or embedded server as aforementioned. In other embodiments, input data can be automatically transmitted to the programming engine.

Referring again to <FIG> at <NUM>, a set of medications is obtained from the drug library implemented at <NUM>. In an embodiment, the functional set selection corresponds to a set of medications in the drug library. In another embodiment, referring to <FIG>, processor <NUM> evaluates received hospital data <NUM>, patient data <NUM>, sensor data <NUM>, and procedure data <NUM> in view of drug library <NUM>. As selected by procedure data <NUM>, a set of medications to be infused is chosen. Processor <NUM> can then utilize drug library <NUM> in view of received hospital data <NUM>, patient data <NUM>, and sensor data <NUM> to select a particular set of medications specific for the unique combination defined by the received input data.

Referring again to <FIG> at <NUM>, the plurality of infusion pumps are programmed according to the set of medications obtained from the drug library at <NUM>. For example, again referring to <FIG>, processor <NUM> transmits a programming signal to any of the plurality of infusion pumps, such as infusion pump <NUM>, infusion pump <NUM>, and infusion pump <NUM>. In an embodiment, each of the infusion pumps receives a set of instructions that are part of the larger set of instructions. Each pump can then parse the received message for its particular protocol and delivery characteristics. In another embodiment, each pump is individually sent programming instructions or commands for its particular protocol and delivery characteristics such that parsing of a larger message is not needed. The pumps are then respectively programmed for operation according to the set of medications defined by the drug library.

Referring again to <FIG> at <NUM>, the plurality of infusion pumps respectively infuse the patient according to the set of medications programmed at <NUM>. In an embodiment, at <NUM>, a clinician loads the drug container onto each of the plurality of pumps per its respective programmed setup configuration. The clinician can then verify the information is correct on each of the plurality of pumps. In an embodiment, the clinician can then start each pump to initiate their respective infusion processes.

Claim 1:
A system for programming a plurality of infusion pumps, the system comprising:
a plurality of infusion pumps, each of the infusion pumps configured to administer medication to a patient;
at least one sending apparatus configured to transmit a data set including at least one item selected from a set comprising hospital data, patient data, sensor data, and procedure data;
an input source configured to receive a selected functional set, the selected functional set comprising a set of programming instructions for all of the plurality of infusion pumps, each particular programming instruction uniquely associated with one of the plurality of infusion pumps; and
a programming engine including:
a drug library including at least one functional set corresponding to the selected functional set defining at least one set of medications, the at least one set of medications defining medication amounts and infusion rates;
a communications engine configured to interface to the sending apparatus, the plurality of infusion pumps and the input source; and
a processor configured to interface to the drug library to automatically select a set of medications from the selected functional set based on the data set and to command the communications engine to program the plurality of infusion pumps according to the selected functional set and the selected at least one set of medications obtained from the drug library,
the programming involving each infusion pump receiving the selected functional set, with each infusion pump being programmed according to the associated particular programming instruction for that infusion pump such that each infusion pump receives a unique programming instruction.