HK1102114B - Apparatus for therapeutic delivery of medication - Google Patents

Description

Device for therapeutic delivery of drugs

The technical field

The present invention relates generally to an apparatus and method for programming medical devices, and more particularly, to an apparatus and method for programming medical treatments, or infusion therapies for medical pumps, such as infusion pumps.

Cross-referencing

This application expressly includes and makes part of the following U.S. patents and U.S. patent applications by reference: U.S. Pat. nos. 5,842,841; U.S. patent application identified as attorney docket number EIS-6090(1417GP 934); U.S. patent application identified as attorney docket number EIS-6091(1417GP 935); and U.S. patent application Ser. No. EIS-6092(1417GP936), identified as attorney docket number EIS-6092.

Background

Medications, both pharmaceutical and non-pharmaceutical, may be introduced into a patient through the use of an injection device or through the use of various other types of medical devices. However, the patient's response to the infused drug is not always immediate. To promote a faster patient response, the clinician may administer the drug into the patient at a relatively higher rate or dosage. One form of a larger rate or dose of medication is known as a bolus dose. The purpose of a bolus dose is to enhance or augment patient response.

In addition, the delivery of certain types of drugs to a patient is to maintain the presence of the drug in the patient for a period of time. These deliveries are referred to as maintenance deliveries or maintenance doses. It is sometimes necessary to rapidly bring the amount of drug in a patient to a level at which it can be maintained before a dose is maintained. To establish this maintenance level, the clinician may deliver the drug into the patient at a higher rate or dosage. This initial large drug rate or dose is referred to as a loading dose. The purpose of a loading dose is to establish a drug level in the patient after which a maintenance dose can be used to maintain that level. The bolus or loading dose may be delivered using a liquid of a drug, non-drug or test substance, and may be given by an intravenous route, an epidural route, a subcutaneous route, or an arterial route.

Modern injection devices provide manual input of data to the injection device so that the device can control the injection of a medicament into a patient. The data provided to the device describes the infusion therapy and includes various parameters such as the volume of the drug, the infusion rate, and the total time to perform the infusion. Some of these devices provide for the input of data reflecting multiple states, thereby enabling the device to automatically control multiple injections simultaneously or sequentially.

A limited number of injection devices are configured with a memory that can store parameter data for standard continuous injection protocols. Such a device enables the clinician to recall parameter data from a standard continuous injection in the memory of the device. This feature provides the clinician with two distinct advantages. First, the parameter data can be recalled quickly from memory without the need for re-entry of the parameter data. Thus, these injection devices configured with memory have the advantage of being programmed faster than injection devices not configured with memory. Second, because parameter data can be stored and retrieved, the need for re-entry of parameter data is unnecessary, thereby minimizing human error associated with data entry. An injection device configured with memory can invoke a safe injection condition, eliminating the need for human input of a potential error condition. Such devices are limited to the storage of standard infusion therapies.

These devices, however, do not provide the ability to store or recall treatment data for bolus dose or loading dose injections. Furthermore, because these devices do not store bolus dose or loading dose therapy data in the memory of the device, they do not provide error checking for clinician-entered bolus dose or loading dose therapies.

Accordingly, a need has arisen for a controller for an infusion device that provides storage for bolus dose and loading dose infusion therapy data in the memory of the infusion device. Such a device would provide recall of safe bolus dose or loading dose infusion therapy data and thus may provide faster and safer bolus dose or loading dose infusion control. In addition, a need has arisen for a controller for an infusion device that provides error checking of clinician-entered bolus dose or loading dose infusion therapy data. Such a device would provide a safer bolus dose or loading dose infusion by comparing clinician-entered data to recommended parameter limits stored in the memory of the device.

In addition, it is common to provide medications to patients based on certain patient and disease conditions. In these cases, the clinician needs to determine the appropriate infusion therapy based on the condition of the patient. Sometimes, the clinician may require a significant amount of time to determine the proper infusion therapy and may delay the necessary treatment for the patient. In addition, there is a risk that the clinician is not sure of the appropriate medication for a particular patient condition. For this additional reason, a need has been found for a medical device that provides pre-programmed infusion therapy based on patient and condition data.

The present invention is provided to solve these and other problems.

Disclosure of Invention

The present invention provides an apparatus, system and method for programming and operating a medical device. The system and method may be used to program and operate medical devices, including syringe pumps.

In accordance with one aspect of the present invention, a medical device is provided for delivering at least one of a bolus dose medication therapy and/or a loading dose medication therapy to a patient. The medical device comprises a drug delivery device having a memory, an input device and a processor. The memory is preloaded with medication therapies for at least one of a bolus dose medication therapy and/or a loading dose medication therapy. An input device of the medication delivery device receives program parameters for a first medication therapy. After receiving the program parameters, the processor compares the received program parameters to the preloaded medication therapies.

According to another aspect of the present invention, the program parameters for a bolus dose medication therapy may include at least any one of a medication type, a medication concentration, a total amount of medication, an individual bolus volume, a total bolus volume, a bolus rate, a timing between bolus deliveries, and a patient weight.

According to another aspect of the invention, the program parameters for a loading dose medication therapy may include at least any one of a medication type, a medication concentration, a loading dose volume, a loading dose rate, a loading dose time, a maintenance rate, a maintenance volume, a maintenance time, a diluent volume, and a patient weight.

According to another aspect of the invention, the processor may provide an alert after the processor compares the received program parameters to the preloaded medication therapies. In one embodiment, the medication delivery device may have an alarm module for activating an alarm when at least one of the program parameters for the first medication therapy exceeds a limit of the parameters of the preloaded medication therapies.

According to another aspect of the invention, the alarm may be a soft alarm or a hard alarm. When the alarm is a soft alarm, the controller allows delivery of medication to the patient based on the received program parameters. However, the operator has the option of modifying any program parameters after receiving the soft alert. Conversely, when the alarm is a hard alarm, at least one of the input program parameters typically must be modified before drug delivery is allowed.

According to another aspect of the invention, after the processor compares the received program parameters to the preloaded medication therapies, the processor may request approval before allowing delivery of the medication.

According to another aspect of the invention, after the processor compares the received program parameters to the preloaded medication therapies, the processor may develop at least a portion of the first medication therapy based on the received program parameters.

According to another aspect of the invention, the input device of the medication delivery device receives program parameters for a second medication therapy. The second medication therapy may be one of a bolus dose medication therapy, a loading dose medication therapy, or a standard injection therapy. Further, a processor is provided to compare the received program parameters for the second medication therapy to the preloaded medication therapies. After the processor processes the program parameters for the second medication therapy, the processor may issue an alert as described above, or it may develop at least a portion of the second medication therapy based on the received program parameters. Further, the processor may generate a delivery schedule for delivery of the first medication therapy and the second medication therapy.

In accordance with another aspect of the present invention, a programmable infusion pump having a memory, an input device and a processor provides for delivering at least one of a bolus dose medication therapy and a loading dose medication therapy to a patient. The memory of the syringe pump is preloaded with medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. The input device receives program parameters for a first medication therapy of one of the bolus dose medication therapy and the loading dose medication therapy, and the processor compares the received program parameters to the preloaded medication therapies.

According to another aspect of the invention, a programmable infusion pump has a plurality of independently programmable pumping channels. Each pumping channel is independently programmable for delivering one of a bolus dose medication therapy, a loading dose medication therapy and a standard infusion therapy. In one embodiment, a three-way pump is provided as follows: a first pumping channel of the infusion pump is programmable for delivering a first medication therapy of one of a bolus dose medication therapy, a loading dose medication therapy and a standard infusion therapy; a second pumping channel of the infusion pump is programmable for delivering a second medication therapy of one of the bolus dose medication therapy, the loading dose medication therapy and the standard infusion therapy; and a third pumping channel of the infusion pump is programmable for delivering a third medication therapy of one of the bolus dose medication therapy, the loading dose medication therapy, and the standard infusion therapy. According to this aspect of the invention, the processor may generate a delivery schedule for each pumping channel being used.

According to another aspect of the present invention, a system for providing a bolus infusion therapy is provided. The system includes a controller for the infusion pump. The controller has a memory, a processor, and an input device. The controller may be a digital assistant. The memory includes preloaded bolus infusion therapies for a plurality of medications; the input device receiving program parameters for a first bolus infusion state; and, the processor compares the received program parameters to the preloaded bolus infusion therapies in the memory of the controller.

According to another aspect of the invention, in one embodiment the controller is an internal component of the syringe pump, while in another embodiment the controller is a separate and distinct component from the syringe pump. Generally, in both embodiments, the controller develops a first bolus infusion therapy and delivers the first bolus infusion therapy to the infusion pump.

According to another aspect of the present invention, a system for providing a loading dose infusion therapy is provided. The system includes a controller for an infusion pump having a memory, a processor, and an input device. The controller may be a digital assistant. The memory includes preloaded loading dose infusion therapies for a plurality of medications; the input device receives program parameters for a first loading dose injection state; and, the processor compares the received program parameters to the preloaded loading dose infusion therapies in the memory of the controller.

According to another aspect of the invention, in a first embodiment, the controller is an internal component of the syringe pump, while in a second embodiment the controller is a component separate and distinct from the syringe pump. Generally, in both embodiments, the controller develops a first loading dose infusion therapy and delivers the first loading dose infusion therapy to the infusion pump.

According to another aspect of the present invention, a method of programming an infusion therapy in an infusion pump is provided. The method comprises the following steps: providing a controller having a memory, a processor, and an input device, wherein the memory is preloaded with medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy; providing an input device for receiving a first set of program parameters for a first medication therapy, the first medication therapy being one of a bolus dose medication therapy and a loading dose medication therapy; providing a processor for comparing, at the processor, the received program parameters with the preloaded medication therapies; and providing an alarm for activating an alarm when at least one of the program parameters for the first medication therapy is outside a parameter limit of the preloaded medication therapy ranges. Further, the method provides for receiving a deactivation of the alert.

According to another aspect of the present invention, an apparatus for programming a medication therapy for at least one of a bolus dose medication therapy and a loading dose medication therapy is provided. The apparatus includes a controller having a memory, an interface, and a processor. The memory is preloaded with medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. An interface is provided for receiving a selection of a first medication therapy type, the first medication therapy including at least one of a bolus dose medication therapy and a loading dose medication therapy, and a processor provides an input screen specific to program parameters for the selected medication therapy type.

According to another aspect of the present invention, a method of programming a medication therapy in a controller for an infusion pump is provided. The method comprises the following steps: providing a controller having a memory, a processor, and an interface device, wherein the memory is adapted to be preloaded with medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy; providing for receipt of a first medication therapy type, the first medication therapy type comprising at least one of a bolus dose medication therapy and a loading dose medication therapy; and providing for display an input screen that allows for receiving program parameters associated with the received medication therapy.

According to another aspect of the present invention, a method for preloading medication therapies in a syringe pump is provided. The method comprises the following steps: providing a controller having a memory, a processor, and an input device, wherein the memory is capable of retrievably storing one or more preloaded medication therapies for at least one of a bolus dose medication therapy and a loading dose medication state; providing a set of program parameters for receiving a medication therapy comprising at least one of a bolus dose medication therapy and a loading dose medication state; and providing for storing the program parameters in a retrievable manner in the memory.

According to another aspect of the present invention, a controller for a programmable infusion pump is provided. The controller has a memory, an input device, and a processor. The memory is preloaded with at least one of a plurality of patient profiles and condition profiles. The memory may further be preloaded with a plurality of associated medication therapies for a plurality of profiles. The input device receives profile data including at least one of a patient profile and a condition profile for a particular patient, and the processor processes the received profile data and provides as output a medication therapy based on the processed profile data. Typically, the processor selects a medication therapy from the preloaded medication therapies corresponding to the preloaded profiles.

According to another aspect of the invention, the memory is also preloaded with a plurality of medication profiles and for medication therapies associated with the plurality of medication profiles. Typically, the preloaded medication profiles include data for at least one of a medication, a non-medication, and a diluent. In addition, the medication typically includes at least one of dose, rate, concentration, and type of medication.

According to a further aspect of the invention, the preloaded patient profiles comprise data representing the patient's pain state, age group and gestational age. In addition, the preloaded condition profiles include data for at least one of a medical condition and a medical disease state.

According to another aspect of the invention, the medication therapy provided by the processor includes a medication type and a delivery parameter. The delivery parameters typically include at least one of dose, rate, and concentration.

According to another aspect of the present invention, a controller for a programmable infusion pump is provided. The controller has a drug delivery therapy of at least one of a bolus dose drug therapy and a loading dose drug therapy. The controller also has a memory, an input device, and a processor. The memory is preloaded with at least one of a plurality of patient profiles and condition profiles, and the memory is further preloaded with at least one of a bolus dose medication therapy and a loading dose medication therapy for each profile. The input device receives profile data including at least one of patient data and condition data for a particular patient. The processor processes the received profile data and provides as output at least one of the preloaded bolus dose medication therapies and the preloaded loading dose medication therapies based on the processed profile data.

According to another aspect of the invention, the controller selects a medication therapy from the preloaded bolus medication therapies and loading dose medication therapies corresponding to the preloaded profiles.

According to another aspect of the present invention, a method is provided for programming an infusion therapy in a controller that includes a memory, a processor, and an input device. The method comprises the following steps: preloading a memory with at least one of a plurality of patient profiles and condition profiles, and associated medication therapies for the plurality of profiles; receiving profile data comprising at least one of a patient profile and a condition profile for a particular patient; and processing the received profile data and providing one of the preloaded medication therapies as an output based on the processed profile data.

According to yet another aspect of the present invention, a method for programming infusion therapy in an infusion pump is provided. The method comprises the following steps: receiving a set of patient profile parameters describing at least one of a medication type, a patient condition, and a disease state; providing a controller having a memory, a processor, and an input device, wherein the memory is capable of retrievably storing one or more medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy, wherein at least one medication therapy matches at least one set of patient profile parameters; comparing, on the processor, the patient profile parameters to medication therapies stored in the memory; and transmitting the medication therapy in accordance with the patient profile parameters.

According to another aspect of the present invention, a method of programming a medication therapy in a controller for an infusion pump is provided. The method comprises the following steps: providing a controller having a memory, a processor, and an interface device, wherein the memory is adapted to be preloaded with a medication therapy for at least one of a bolus dose medication therapy and a loading dose medication therapy; providing for receiving a first medication therapy type comprising at least one of a bolus dose medication therapy and a loading dose medication therapy; providing for receiving a first medication type; and providing for display a suggested first medication therapy for the selected medication therapy type and the medication type.

According to another aspect of the invention, the method further comprises at least one of the following steps: providing for receiving program parameters related to the received medication therapy type; providing for receiving a change to at least one program parameter suggesting a first medication therapy; providing for comparing the received program parameters to the preloaded medication therapies; and providing for activating an alarm when the at least one program parameter for the first medication therapy exceeds the parameter limit for the preloaded medication therapies.

In accordance with yet another aspect of the present invention, a method is provided for programming a patient profile into memory and matching the patient profile to a recommended bolus/loading dose therapy. The method comprises the following steps: providing a controller having a memory, a processor, and an input device, wherein the memory is capable of retrievably storing one or more sets of patient profile parameters, the profile parameters describing at least one of a medication type, a patient condition, and a disease state, and wherein the memory is capable of storing one or more medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy; providing for receiving a set of patient profile parameters describing at least one of a medication type, a patient condition, and a disease state; providing for matching the received set of patient profile parameters to at least one of a bolus medication therapy and a loading dose medication therapy; providing for storing the received set of patient profile parameters in a retrievable manner in a memory; and providing for storing data in a retrievable manner in the memory, wherein the data reflects a correspondence of at least one of the at least one set of patient profile parameters and the bolus dose medication therapy and the loading dose medication therapy.

According to another aspect of the present invention, a medication delivery controller for an infusion pump is provided for delivering at least one of a bolus dose and a loading dose. The medication delivery controller includes a processor for cooperative interaction with a memory and an interface device. The memory is preloaded with medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. The interface device receives program parameters for a first medication therapy that is at least one of the bolus dose medication therapy, the loading dose medication therapy, and a standard infusion therapy. The processor compares the received program parameters to the preloaded medication therapies. The drug delivery controller is a controller for an infusion pump. The infusion pump has a plurality of pumping channels, and wherein each pumping channel is independently programmable for delivering at least one of a bolus dose medication therapy, a loading dose medication therapy, and a standard infusion therapy. Program parameters are required for correct execution of a first medication therapy of a medicine. The program parameters for a bolus dose medication therapy for a medication include at least one of a medication type, a medication concentration, a medication amount, a single bolus volume, a total bolus volume, a bolus rate, a timing between bolus deliveries, and a patient weight. The program parameters for the loading dose medication therapy include at least one of a medication type, a medication concentration, a loading dose volume, a loading dose rate, a loading dose time, a maintenance rate, a maintenance volume, a maintenance time, a diluent volume, and a patient weight. The controller includes an alarm module for setting an alarm when at least one program parameter for the first medication therapy exceeds a parameter limit of the preloaded medication therapies. The alarm is a soft alarm that allows delivery of medication to the patient based on received program parameters for the first medication therapy. At least one of the controller and the interface device includes an interface module for receiving a cancellation of the soft alarm. At least one of the controller and the interface device includes an interface module for receiving a change to at least one program parameter. When the alarm is a hard alarm, it requires a change in at least one program parameter for the first medication therapy. At least one of the controller and the interface device includes an interface module for receiving a change to at least one program parameter. The processor and memory are configured to develop at least a portion of the first medication therapy based on the received program parameters. The processor and memory are configured to generate a delivery schedule for the first medication therapy. An interface device is also provided for receiving program parameters for a second medication therapy of the medication, the second medication therapy being one of a bolus dose medication therapy, a loading dose medication therapy, and a standard infusion therapy, and wherein a processor is provided for comparing the received program parameters for the second medication therapy to the preloaded medication therapies. The processor and memory are configured to generate a delivery schedule for the first medication therapy and the second medication therapy. The controller also includes an alarm module for setting an alarm when at least one program parameter for the second medication therapy exceeds a parameter limit of the preloaded medication therapies. When the alarm is a soft alarm, it allows delivery of medication to the patient based on the received program parameters for the second medication therapy. At least one of the controller and the interface device includes an interface module for receiving a cancellation of the alarm. At least one of the controller and the interface device includes an interface module for receiving a change to at least one program parameter with the interface device. When the alarm is a hard alarm, it may be necessary to change at least one program parameter for the second medication therapy. At least one of the controller and the interface device includes an interface module for receiving a change to at least one program parameter. The first pumping channel of the infusion pump is programmable for delivering a first medication therapy of one of a bolus dose medication therapy, a loading dose medication therapy and a standard infusion therapy.

According to another aspect of the present invention, a second pumping channel providing the infusion pump is programmable for delivering a second medication therapy for one of the bolus dose medication therapy, the loading dose medication therapy and the standard infusion therapy. The third pumping channel of the infusion pump is programmable for delivering a third medication therapy for one of the bolus dose medication therapy, the loading dose medication therapy and the standard infusion therapy. A processor is also provided for generating a delivery schedule for the first medication therapy. A processor is also provided for generating a delivery schedule for at least one of the first, second and third medication therapies. The interface device includes a receiver for receiving information from the information identifier on the line set. The information identifier contains information including at least one of patient name, age, gender, weight, allergies, condition, medication name, medication type, medication concentration, medication amount, individual bolus volume, total bolus volume, bolus rate, dose, timing between bolus deliveries, maximum number of boluses per unit time, loading dose volume, loading dose rate, loading dose time, maintenance rate, maintenance volume, maintenance time, maintenance dose, diluent volume, patient profile data, and condition profile data.

According to another aspect of the present invention, a system for bolus infusion therapy is provided. The system includes a controller for the infusion pump. The controller has a memory, a processor, and an input device. The memory includes preloaded bolus infusion therapies for a plurality of medications. The input device receives program parameters for a first bolus infusion therapy and the processor compares the received program parameters to the preloaded bolus infusion therapies in the memory of the controller. The controller is an internal component of the syringe pump. The controller may be a component separate and distinct from the syringe pump. The controller develops a first bolus infusion therapy and transmits the first bolus infusion therapy to the infusion pump. The syringe pump includes a controller.

According to another aspect of the present invention, a system for loading dose infusion therapy is provided. The system includes a controller for the infusion pump. The controller has a memory, a processor, and an input device. The memory includes preloaded loading dose infusion therapies for a plurality of medications. The input device receives program parameters for a first loading dose infusion therapy and the processor compares the received program parameters to the preloaded loading dose infusion therapies in the memory of the controller.

According to another aspect of the present invention, a system is provided for programming at least one of a bolus dose medication therapy and a loading dose medication therapy. The system includes a controller, a memory, and an interface device. The memory is adapted to be preloaded with at least one medication therapy for a bolus dose medication therapy and a loading dose medication therapy. The interface device is configured to receive a selection of a first medication therapy type including at least one of a bolus dose medication therapy and a loading dose medication therapy. The interface device is configured to receive a medication type and the processor is configured to provide a suggested first medication therapy for a selected medication therapy type and medication type. The interface device is configured to provide a screen dedicated to receiving program parameters for a first medication therapy of a selected medication therapy type. After initially receiving the program parameters, the interface device is configured to receive a change in the program parameters for the first medication therapy. The controller is an integral part of the drug delivery device and wherein the drug delivery device further comprises a memory and an interface device.

According to another embodiment of the present invention, a method is provided for programming a medication therapy utilizing a controller for an infusion pump. The method comprises the following steps: providing a memory adapted to be loaded with a medication therapy for at least one of a bolus dose medication therapy and a loading dose medication therapy; receiving a first medication therapy type comprising at least one of a bolus dose medication therapy and a loading dose medication therapy; receiving a first medication type; and suggest a first medication therapy for the selected medication therapy type and medication type. The memory is preloaded with medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. The method further comprises the following steps: receiving a first set of program parameters for a first medication therapy, the first medication therapy being one of a bolus dose medication therapy and a loading dose medication therapy; comparing the received preloaded medication therapies for the program parameters; and activating an alarm when at least one of the program parameters for the first medication therapy exceeds the parameter limits of the preloaded medication therapy ranges. The method also includes the step of providing a controller for the infusion pump for delivering the first medication therapy from the preloaded medication therapies. The method also includes the steps of: an input device is provided for receiving an information identifier from an infusion line set for use in programming an infusion therapy.

According to another aspect of the present invention, a tubing set for interfacing with an infusion control system for delivering at least one of a bolus dose and a loading dose is provided. The injection control system includes a processor and a memory for cooperative interaction with the processor. The memory includes medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. The line set comprises a length of tubing and a micro-electromechanical system (MEMS) element connected to the tubing. The line set of claim 53 wherein the infusion control system further comprises an input device for receiving program parameters for a first medication therapy, the first medication therapy being one of the bolus dose medication therapy, the loading dose medication therapy and a standard infusion therapy, the processor being operable to compare the received program parameters to the medication therapy in the memory. The processor and memory include a controller for controlling operation of the MEMS element. The controller has a display for displaying information. The injection control system further comprises a central computer and a MEMS interface device, wherein the processor and the memory are located within the central computer, and wherein the central computer is located remotely from the MEMS element and the MEMS interface device. The MEMS interface device includes means for controlling and interrogating the MEMS element. The line set is disposable and wherein the MEMS interface device is reusable. The injection control system further includes an input device having a display for displaying information regarding the operation of the MEMS element and having a reader for receiving the identifier. The identifier may also include an identification of the MEMS element, such as a MEMS pump, for sending such information forward along the system, and for tracking the operation and interaction of the MEMS element with respect to the system.

According to another aspect of the present invention, a medical infusion system is provided for infusing at least one of a bolus dose and a loading dose. The system includes a disposable tube, a disposable electromechanical pump element connected to the tube, a pump interface device operably connectable to the pump element, a processor, and a memory for cooperative interaction with the processor. The memory includes medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. The system also includes a disposable reservoir connected to the disposable tube. The disposable reservoir includes a valve configured to be remotely controlled.

According to another aspect of the present invention, a method for delivering a drug is provided. The method comprises the following steps: a tube is provided having a MEMS pump coupled thereto, the MEMS pump being configured to be operatively coupled to a pump interface device, a processor, and a memory for cooperative interaction with the processor. The memory includes medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. The pump is actuatable using the pump interface device to deliver the medication in accordance with at least one of the bolus dose medication therapy and the loading dose medication therapy.

According to another aspect of the present invention, a controller for a programmable medical pump is provided, comprising a memory having at least one preloaded patient profile and at least one preloaded condition profile, the memory further having an associated preloaded medication therapy for each of the plurality of profiles; an input device for receiving profile data including at least one of patient profile data and condition profile data corresponding to a particular patient; and a processor for providing at least one of the preloaded medication therapies in accordance with the received profile data, wherein the processor compares the received profile data to the preloaded profiles in memory to determine whether the medication therapy is to be provided.

According to another aspect of the present invention, there is provided a medical system for therapeutic delivery of a drug, comprising: a disposable tube; a disposable electromechanical pump element connected to the tube; a pump interface device operatively connected to the pump element; a processor; and a memory cooperatively interacting with the processor, the memory including a plurality of preloaded patient profiles and preloaded condition profiles, and a related medication therapy for the at least one of the plurality of profiles, wherein the processor is configured to select the related medication therapy based on received profile data for a particular patient and compare the received profile data to the preloaded profiles in memory to determine whether the related medication therapy is to be delivered.

Other devices, systems, methods, features and advantages of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional devices, systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims.

Drawings

The invention may be better understood by reference to the following drawings. The components in the figures are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. In the drawings, like reference numerals designate like parts throughout the several views.

FIG. 1 is a flow chart illustrating one embodiment of a medical device programming system of the present invention.

FIG. 2 is a flow chart illustrating another embodiment of a medical device programming system of the present invention.

Fig. 3 is a front view of a medical device and controller for use in the system of the present invention.

Fig. 4 is a view of a treatment selection interface screen of the system of the present invention.

FIG. 5 is a view of a data entry screen of the system of the present invention.

FIG. 6 is a view of one embodiment of an alarm screen of the system of the present invention.

Fig. 7 is a view of another embodiment of an alarm screen of the system of the present invention.

Fig. 8 is a view of an approval screen of the system of the present invention.

Fig. 9 is a view of a channel selection screen of the present invention.

Fig. 10 is a view of a schedule screen of the system of the present invention.

FIG. 11 is a view of one embodiment of a profile data entry screen of the system of the present invention.

FIG. 12 is a view of a proposed treatment screen of the system of the present invention.

Fig. 13 is a view of a pre-programmed screen of the system of the present invention.

Fig. 14 is a view of another embodiment of a pre-programmed screen of the system of the present invention.

FIG. 15 is a flow chart describing the pre-programming of the controller of the system of the present invention.

Fig. 16 is a schematic view of another embodiment of the present invention utilizing a disposable pump.

Fig. 17 is a schematic view of yet another embodiment of the present invention utilizing a disposable pump.

Detailed Description

Referring to the drawings, and in particular to fig. 1 and 2, there are shown two flow charts of what is considered to be the same system and method for programming a medical device to deliver a medication therapy to a patient. One of ordinary skill in the art will fully appreciate that the present system is designed to operate for programming of any type of medical device to deliver medication to a patient. For illustrative purposes only, this detailed description focuses on a syringe pump as a medical device for delivering drugs and/or non-drugs to a patient. Further, it should be understood that the syringe pump includes many types of medical pumps, including but not limited to volumetric syringe pumps, peristaltic pumps, cassette pumps, and syringe pumps, and may be applied to delivery mode applications such as intravenous delivery, intramuscular delivery, IA delivery, epidural delivery, perfusion of a fluid space, and other types of delivery and uses.

FIG. 3 depicts one embodiment of the medical device 10 of the present invention. In general, the system of the present invention comprises a drug delivery device 10, a controller 12 having a memory 14, a processor 16 and an interface device 19. The interface device 19 may include one or both of the input device 18 and the display device 17. Furthermore, the components of the interface device 19 (i.e. the input device 18 and the display device 17) may be separate components, or they may be an integral component. As an example, the interface device 19 may be a touch screen providing the functions of a display device and an input device.

In one embodiment, controller 12 is an internal component of syringe pump 10. In an alternative embodiment, controller 12a is a separate component from syringe pump 10 and from syringe pump 10. By way of example, the controller 12a may be a stand-alone Personal Digital Assistant (PDA) controller 12a, also shown in FIG. 3, which may be used to develop a medication therapy and subsequently transmit signals to operate the medical device 10.

Generally, when the controller 12a is a separate and distinct component from the medical device 10, such as a PDA, the controller 12a performs all of the following functions: processing of program parameters, comparison of program parameters to preprogrammed medication therapies, development of medication therapies and progress of medication therapies, and providing medication therapies in response to entered patient and condition data. As an example, to operate the medical device 10 with a separate controller 12a, the controller 12a may generate an output signal that is sent to a motor of the medical device 10. The level of the input signal, which may be a varying power signal, will determine the speed of operation of the motor to deliver the medication to the patient.

One type of syringe pump that may be used in the present invention is the pump disclosed in U.S. Pat. No. 5,842,841, issued to Danby et al and commonly assigned to the assignee of the present invention. As shown in fig. 3, the syringe pump 10 has a housing 20, an input device, and a plurality of pumping channels 22a, 22b, and 22 c. In the present invention, each pumping channel will be independently programmable for delivering multiple medication therapies to a particular patient. In operation, an operator, such as a nurse or other clinician, initiates injection of the medication by inserting a standard IV line set 24 into a tube loading port 26 or tubing (tubeway)26 located at the front of any housing passageway. The line set 24 may include one or more of the following components: IV tubing 25, slide clamp 28, connector and container 84. Additional or fewer components may comprise the line set 24. In addition, the operator simultaneously inserts a slide clamp 28 associated with the tubing set 24 into a suitable slide clamp orifice 29 located upstream of the tubing loading orifice 26, i.e., closer to the source of the fluid. The operator may then initiate a tube loading procedure in which a series of catches and a movable upper clamp device act to catch the tube 25 of the line set 24 and guide the tube 25 into the conduit 26. As the loading cycle progresses, the clamp and catch grip the tube 25 to capture the tube 25 in the channel 26. Subsequently, when the valve approaches the plugging tube 25, the slider 28 will move to a position such that the slider clamp 28 will no longer plug the tube 25. Upon receiving appropriate signals from the associated controller, which determines the pumping rate, allowable air volume, temperature and pressure, the pump is activated, wherein liquid is drawn from the liquid source and expelled from the pump 10 according to the medication therapy. As described in further detail herein, each of the process parameters and/or patient profiles necessary to develop a medication therapy and potentially complete a medication therapy may be provided to the controller via the information identifier 27 coupled to the line set 24. The information identifier 27 may be included on any component of the line set 24, including but not limited to the tube 25, the container 84, and the slide clamp 28.

As explained above, the system 30 of the present invention is used to program medication therapies in the medical device 10. The system 30 of the present invention may be implemented in software (e.g., firmware), hardware, or a combination thereof. In the best mode presently contemplated, the system 30 has a medical device operating system implemented in software, such as an executable program. The medical device operating system may be located in or have portions located in any computer, server, controller of the medical device 10 or digital assistant 12 a.

Generally, in accordance with the hardware architecture shown in FIG. 3, the controller 12 is a computer that includes a processor 16, a memory 14, and one or more input and/or output (I/O) devices 18 (or peripherals) that are communicatively coupled via a local interface. The local interface may be, for example, but not limited to, one or more buses or other wired or wireless connectors, as is known in the art. The local interface may have additional elements, which are omitted for simplicity, such as additional controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. In addition, the local interface may include address, control, and/or data connectors to enable appropriate communication between other computer components.

The processor 16 is a hardware device for executing software, in particular software stored in the memory 14. The processor 16 can be any custom made or commercially available processor, a Central Processing Unit (CPU), an auxiliary processor among multiple processors associated with a computer, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions. Examples of suitable commercially available microprocessors are as follows: the PA-RISC family of microprocessors from Hewlett-Packard, the 80X 86 or Pentium family of microprocessors from Intel, the IBM PowerPC microprocessor, the Sparc microprocessor from Sun microsystems, Inc., or the 68xxx family of Motorola.

The memory 14 may include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.) and non-volatile memory elements (e.g., ROM, hard disk drive, tape, CDROM, etc.).

The software in memory 14 may include one or more separate programs, each of which includes an ordered listing of executable instructions for performing logical functions. In the example of FIG. 3, the software in memory 14 includes a suitable operating system (O/S). A non-exhaustive list of examples of suitable commercially available operating systems is as follows: (a) windows operating systems available from Microsoft corporation; (b) netware operating system available from Novell corporation; (c) macintosh operating systems available from Apple computer, Inc.; (d) the Unix operating system, which is commercially available from many vendors, such as Hewlett-packat, Sun microsystems, Inc., and AT & T; (e) a LINUX operating system, which is free software readily available on the internet; (f) an operating time Vxworks operating system from Windriver Systems, Inc.; or (g) a device-based operating system such as those implemented in a handheld computer or Personal Digital Assistant (PDA) (e.g., Palm OS, available from Palm computing, Inc., and Windows CE, available from Microsoft corporation). The operating system essentially controls the execution of any other computer program, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

The medical device operating system may be a source program, an executable program (object code), a script, or any other entity comprising a set of instructions to be executed. When a source program needs to be translated via a compiler, assembler, interpreter, or the like, the source program may or may not be included in memory 14 to operate properly in connection with the O/S. Further, the medical device operating system may be written in (a) an object-oriented programming language with classes of data and methods, or (b) a procedural programming language with routines, subroutines, and/or functions, such as, but not limited to, C, C + +, Pascal, Basic, Fortran, Cobol, Perl, Java, and Ada. In one embodiment, the medical device operating system is written in C + +. In other embodiments, the medical device operating system is created using a Power Builder. The I/O devices 18 may include input devices such as, but not limited to, a keyboard, a mouse, a scanner, a touch screen, interfaces for various medical devices, a bar code reader, a stylus pen, a laser reader, a radio frequency device reader, and the like. In addition, the I/O devices 18 may also include output devices such as, but not limited to, printers, bar code printers, displays, and the like. Finally, the I/O devices 18 may further include devices to communicate inputs and outputs, such as, but not limited to, modulators/demodulators (modems; for accessing additional devices, systems, or networks), Radio Frequency (RF) or other transceivers, telephone interfaces, bridges, routers, and the like.

When the medical device operating system is executed using software, it should be noted that the medical device operating system can be stored on any computer-readable medium for use by or in connection with any computer-related system or method. In the context of this document, a computer readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method. The medical device operating system may be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can store, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exclusive list) of computer-readable instructions include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (EPROM, EEPROM, or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

In another embodiment where the medical device operating system is implemented in hardware, the medical device operating system may be implemented using any or a combination of the following techniques, each of which is well known in the art: a discrete logic circuit having logic gates for performing logic functions on data signals; an Application Specific Integrated Circuit (ASIC) with appropriate combinational logic gates; programmable Gate Arrays (PGA), Field Programmable Gate Arrays (FPGA), etc.

Turning to fig. 1, a flow chart is shown depicting one embodiment of a system 30 for programming a medical device 10 of the present invention. The first step in the programming process is to initiate a start command, shown at step 31 in FIG. 1. The start command 31 typically includes turning on the controller 12 of the syringe pump 10 or a separate controller 12 a. After the start command is initiated, an injection selection screen 32 appears. One depiction of an injection selection screen 32 is shown in fig. 4. As shown, the injection selection screen 32 is adapted to allow the operator the ability to select an injection therapy. In one embodiment, the injection treatments available for selection are the programmed liquid bolus injection treatment 34, the drug bolus injection treatment 36, and the loading dose injection treatment 38 typically used for non-drug bolus drug delivery. A bolus is generally defined as a relatively large volume of liquid, or dose of drug or test substance, that is provided via an intravenous, epidural, subcutaneous, or arterial route to enhance or augment the response. A loading dose is generally defined as a volume of liquid or a dose of a drug or test substance given via an intravenous, epidural, subcutaneous or arterial route prior to maintenance of the same liquid, drug or test substance. One purpose of a bolus or loading dose is to achieve rapid serum concentrations. However this may increase the risk of adverse effects. Accordingly, means are sought to reduce the likelihood of increased risk. As explained previously, this disclosure seeks to provide means to reduce the risk of error when providing a medication, whether a medication or a non-medication, to a patient.

As one aspect of the invention, the memory 14 is preloaded with medication therapies. The types of medication therapies preloaded in the memory 14 include at least one of bolus dose medication therapies, loading dose medication therapies, and standard infusion therapies for both medication boluses and for non-medication boluses. The preloaded medication therapies may identify acceptable ranges and/or limits for each procedure or procedure parameter required to develop a particular medication therapy. This enables the medical treatment to establish a standard bolus dose or loading dose of each medication, including both drugs and non-drugs, which is defined in the library of memory 14. This also enables hospitals to establish standard loading dose or bolus dose treatments for a variety of patient condition profiles. As known to those skilled in the art, the acceptable range and/or limit for a particular process parameter may be adjusted based on other process parameters. For example, if the injection time increases, the allowable range/limit for injection may increase, whereas if the injection time decreases, the allowable range/limit for injection may decrease. In addition, the allowable rate of a particular drug may vary depending on the concentration of the drug. Many other examples are possible.

After the operator selects the appropriate infusion therapy at the infusion selection screen 32, the system provides the operator the ability to enter program parameters for drug delivery at step 40 (see fig. 1). The program parameters vary depending on the type of treatment, type of parameters, medication, etc. set for the hospital request or set by other care facilities. Typically, the program parameters program the medical device to operate according to the instructions or prescriptions for the necessary set of information and/or instructions. The plurality of program parameters for a bolus dose medication therapy includes at least a medication type, a medication concentration, a medication amount, an individual bolus volume, a total bolus volume, a bolus rate, a timing between bolus deliveries, a maximum number of boluses per unit time, and a patient weight. Also, the program parameters for loading dose medication therapy include at least the type of medication, the concentration of the medication. Drug amount, loading drug volume, loading dose rate, loading dose time, maintenance rate, maintenance volume, maintenance time, diluent volume, and patient weight. One skilled in the art will recognize that additional procedural parameters are possible for these and other infusion therapies.

In one embodiment of the present invention, after the operator makes the selection of the medication therapy type at step 32, the system will provide an input screen that only allows program parameters related to the received medication therapy type to be received. For example, if a bolus dose medication therapy is selected at step 32, the system will only provide input for those program parameters relevant to the bolus dose medication therapy. Likewise, if a loading dose medication therapy is selected at step 32, the system provides for the entry of only those program parameters associated with the loading dose medication therapy. One depiction of a program parameter entry screen 42 for a loading dose therapy is shown in fig. 5, where for exemplary purposes the loading dose parameter entry screen 42 requests data regarding loading rate 48, loading volume 50, concentration 52, maintenance rate 54, maintenance volume 56, and concentration 58.

The program parameter input screen 42 shown in fig. 5 is also an example of operating the interface device 19 as the input device 18 and the display device 17. Program parameters can be programmed using the selection keys 44 and up/down arrows 46 and provide a display via a video screen.

Further, in one embodiment of the present invention, after the operator makes a selection of a medication therapy type at step 32, and after the medication type is provided to the controller 12, the system 30 may provide a suggested medication therapy for the selected medication therapy type and medication type. Thus, instead of, or in conjunction with, displaying the program parameters associated with the particular medication therapy type selected, the system 30 may provide an identification of the program parameters and their values for the associated parameters for that medication therapy type. As an example, if a particular anesthetic drug is selected and the operator chooses to provide such anesthetic drug via a bolus therapy at step 32, the system 30 will identify a suggested medication therapy for that drug and the medication therapy type. The operator will then be able to receive or modify any parameters at step 60.

Referring back to fig. 1, after the operator enters or modifies the program parameters into the input device 18, the processor 16 receives the parameters and compares the received parameters to the preloaded medication therapies at step 60. In a preferred embodiment, this may include using an algorithm in the processor 16 to determine the appropriate range for each parameter, possibly based on a preprogrammed size-varying matrix.

At step 62, after the processor 16 compares the received program parameters to the preloaded medication therapies in the memory 14, the processor 16 determines whether the received program parameters are outside of the preprogrammed acceptable ranges for each of the process or program parameters of the particular medication therapy. If the received program parameters are appropriate for the preloaded medication therapies, the processor 16 may then develop at least a portion of the medication therapies based on the received program parameters.

However, if any of the program parameters for a particular medication therapy are outside the limit settings in the preloaded medication therapies, the system provides an alarm or notification at step 64 to alert the clinician that the dosage is outside the recommended range specified by the hospital. The alarm may be provided using an alarm module 66, which is a component of the controller 12 as described in the embodiment shown in FIG. 3. The alarms may be visual or audible alarms, and different alarm types may have different visual or audible alarms. When the parameter limits are not allowed to be exceeded, a hard alarm is provided to alert the operator that the program parameters are invalid and that they must modify at least one of the program parameters. One depiction of a hard alarm is provided in fig. 7. After receiving the hard alarm, the operator has the option of modifying one or more program parameters at step 69. If the operator does not modify at least one of the program parameters to preclude a hard alarm, the treatment request will be denied in step 70. If the operator modifies at least one of the program parameters, the system will return to step 60 of FIG. 1 to determine if the number of modified parameters is within the preprogrammed acceptable range.

In contrast to hard alarms, soft alarms allow parameter limits to be exceeded without modifying the out-of-limit parameters. The soft alarm, however, provides notification to the operator that at least one of the program parameters is outside the limits set in the preloaded medication therapies. A screen shot for one embodiment of a soft alarm is shown in fig. 6. After receiving the soft alert, a request to provide revocation is made at step 72 in fig. 1. The operator may provide a recall response in the interface module of the input device 18. As explained previously, the interface module may include a touch screen, keyboard, mouse, and the like. If the request is answered in the negative, then no override of the soft alert is provided and the treatment request will be denied in step 70. Further, the program sequence will terminate at step 80. If the request is answered in the affirmative, the system proceeds to step 74 to determine if authorization is required.

As shown in FIG. 1, another means by which the operator may reach step 74 occurs when the received program parameters entered at step 40 are determined at steps 60 and 62 to be within the preprogrammed limits or ranges.

At step 74, the processor determines whether authorization is required to proceed. There are a number of processes that require approval. First, if a soft alarm has been revoked, approval is required. Second, if a dual-labeled drug, such as an anesthetic or blood, is provided, approval is required. It should be understood that there are other procedures that require approval.

Thus, if it is determined that authorization is required because the soft alarm was deactivated, but that double marking is not required, the system proceeds to step 77 via step 75. An alert/notification is provided at step 77 alerting the operator that approval is required to proceed. At step 79, the authorization required to continue with the revocation of parameters is provided or not. If authorization is not provided to override the program parameters at step 79, the system then proceeds to step 70 and the programming therapy request is denied. If authorization is provided to override the program parameters at step 79, the system then proceeds to step 81. At step 81, the pharmacy and the treating physician are notified that the delivery parameters set for treatment are outside the hospital's prescribed ranges.

If it is determined at steps 74 and 75 that approval is required because the soft alarm is deactivated or a double flag is required, the system proceeds to step 76. At step 76, the system provides an alert/notification that double labeling/approval is required. The system then determines whether two authorization marks have been provided at step 78. If both approval marks are not provided, the system proceeds to step 70 and denies the programming therapy request. If two authorization signatures are provided at step 78, which may be security authorization, the system proceeds to step 81. If the delivery parameters are overridden at step 72, then the pharmacy and the treating physician are notified at step 81 that the delivery parameters set for the treatment are outside the hospital's prescribed ranges. If the delivery parameters are not overridden at step 72, then it is not necessary to notify the treating physician and pharmacy.

Once appropriate authorization is provided at steps 78 and 79, or if authorization is not required at step 74, the system proceeds to step 82 of FIG. 1. At step 82, the system requests the operator to select the appropriate pumping channel and determine the appropriate container and line set 24, if these have not been completed. The identification of the line set in the pumping channel may occur manually by the operator entering information about the reservoir 84, the medicament in the reservoir 84 and the channel 22 in which the tube 25 is located, or this identification may occur automatically. It should also be understood that the identification of the container 84 and line set 24 may occur earlier in the program sequence.

For reference, fig. 9 shows a channel selection screen of the controller 12. In the routine shown in fig. 9, the operator determines the appropriate channel for programming the infusion therapy. If the container, line set, channel identification and/or parameter programming is not performed manually, one means for providing automatic identification/programming utilizes an information identifier on the components of the line set 24. The information identifier 27 may contain information about: a patient, such as the patient's name, age, sex, weight, allergies, condition, etc.; drug connected as part of the line set 24 (i.e., in the reservoir 84), such as drug/non-drug type, name, concentration, etc.; and a medication therapy to be performed with the line set, including all or any necessary process parameters for the medication therapy. Such process parameters may include at least medication type, medication concentration, medication amount, individual bolus volume, total bolus volume, bolus rate, dose, timing between bolus deliveries, maximum number of boluses per unit time, loading dose volume, loading dose rate, loading dose time, maintenance rate, maintenance volume, maintenance time, maintenance dose, diluent volume, and patient weight. Finally, the information identifier 27 may include information about profile data, including but not limited to patient profile data such as patient pain status, age group, and gestational age, and condition profile data such as medical conditions or medical disease status, including but not limited to renal disease, congenital heart disease, and liver dysfunction. In addition to including specific medication therapy information, the information identifier 27 also includes general medication therapies. For example, the information identifier 27 may include process parameters and data applicable to a plurality of medications, medication categories, or patient categories and/or condition profiles.

The information identifier 27 may be connected to the line set 24 by the manufacturer of the line set 24, by a hospital pharmacy, or by some other entity. When the information identifier 27 is connected to the line set 24 by the manufacturer, the line set typically does not also include a medication container 84. Thus, the line set 27 with the information identifier 27 may be pre-formed and provided as having class or group information applicable to the medication. The line set 24 with the information identifier 27 may then be connected to a container 84 with such a medicament therein. Alternatively, the line set 24 may be highly customized and contain many of the above specific patient and/or specific treatment process parameters. Such customization is typically performed by a pharmacy, where the particular prescription and treatment instructions are linked to the information identifier 27.

Data from the information identifier 27 is transmitted to the controller 12 as if it were entered into the keyboard of the input device 18. In one embodiment, the slide clamp 28 has one or more of machine readable indicia, a bar code, and/or a radio frequency transmitter including an RFID that communicates with the controller 12 and transmits information to the controller 12. In a similar embodiment, the controller 12 may have an input device 18, such as a bar code reader, a radio frequency receiver, a fiber optic receiver, a laser readable receiver, and/or an infrared receiver, etc., to receive information from the information identifier 27.

When any information is received by the input device 18 of the controller 12 via the line set information identifier 27, it should be understood that it is advantageous when this information is transmitted to the controller early in the programming process, and preferably at step 40 as shown in FIGS. 1 and 2.

After selecting the channel at step 82, the container 84 including the medication and line set 24 is identified and the processor 16 of the system 30 queries the operator to generate a schedule for medication therapy at step 86. One aspect of the schedule query is to identify the treatment as an initial treatment, or as a segment control treatment, as depicted in fig. 10. With a three-channel multi-channel infusion pump, possible medication therapies include at least an initial medication therapy, a first piggyback medication therapy and a subsequent piggyback medication therapy. In such a configuration, an initial medication therapy (i.e., a first medication therapy) is delivered first, then a first piggyback medication therapy (i.e., a second medication therapy) is delivered, and a subsequent piggyback medication therapy is delivered third, all of which may be any of a standard medication therapy, a bolus dose medication therapy, and/or a loading dose medication therapy.

Another part of the schedule query is the time and date of the medication delivery. The controller 12 may be programmed prior to delivering the drug and/or connecting the reservoir 84 and the line set 24 to either or both of the medical device 10.

As an example of a multi-reservoir 84 and multi-channel program, the controller 12 may be programmed to provide a loading dose medication therapy from a primary reservoir associated with the first pumping channel 22a and a maintenance medication therapy (i.e., a piggyback medication therapy) from a secondary reservoir associated with the second pumping channel 22b or the same reservoir associated with the first pumping channel 22a following the loading dose medication therapy. In addition, the above-described stepwise controlled medication therapy following the first two drugs may be a bolus medication therapy from a third reservoir connected to the third pumping channel 22 c.

By using a segmented medication therapy, the system is able to form a first medication therapy (i.e., an initial medication therapy), a second medication therapy (i.e., a segmented therapy), a third medication therapy (i.e., a subsequent segmented therapy), and so on. The segment therapy is programmed according to the same steps with the same system 30, including all of the above identified alarms and overrides.

As an additional feature, the system may include a repeat feature that allows the operator the ability to repeat any portion of the procedure parameters or the entire treatment without having to reenter the parameters.

Referring now to fig. 2, fig. 2 illustrates another system 30a for programming the medical device 10 of the present invention. The first step in the programming process of the system 30a is to initiate a start command at the controller (either the controller 12 connected to the medical device 10 or the standard stand-alone controller 12a), shown at step 31 in fig. 2. After initiating the start command, the operator may choose to proceed to the injection selection screen 32. As noted above, an infusion selection screen 32 is depicted in FIG. 4, which provides the operator with the ability to select an infusion therapy. If the operator selects an infusion therapy, the medication therapy provided as a result of system 30a, as described in detail below, will operate according to infusion delivery parameters for that particular infusion therapy. Specifically, as an example, if the operator selects a bolus dose medication therapy at step 32, the processor 16 will process the received profile data and provide as output a preloaded bolus medication therapy based on the processed profile data. Alternatively, the operator may skip step 32 and proceed directly to steps 90 and 91, indicated in FIG. 11, wherein the operator may enter profile data into the input device 18, the profile data including at least one of a patient profile 92, a condition profile 94, and a medication profile 96.

The profile data for the patient profile 92 may include at least one of a patient pain condition, an age group, and a gestational age. The profile data for condition profile 94 may include at least one of a medical condition or medical disease state, such as kidney disease, congenital heart disease, and liver failure. Finally, the profile data for the medication profile 96 may include any data regarding the medication (i.e., medication, non-medication, or diluent), including the name or type of medication to be delivered to the patient. Each of the patient profile 92, condition profile 94, and medication profile 96 is resident in the memory 14. More specifically, in addition to the medication therapies preloaded in the memory 14 as previously described, the memory 14 is also preloaded with a patient profile 92, a condition profile 94, and a medication profile 96 corresponding to a particular medication therapy.

After the operator enters the profile data, which may include manipulating the drop-down selection menu in fig. 11 (i.e., the input device 18), the profile data received by the input device 18 may be examined by the processor 16 and compared to the data in the preloaded profiles 92, 94, 96 to determine the appropriate medication therapy at steps 98 and 100. In one embodiment, the processor 16 has an algorithm that compares the received profile data to the preloaded profiles to provide the medication therapy. Finally, at step 102, the processor 16 will provide as output a medication therapy. The processor 16 typically selects a medication therapy from the preloaded medication therapies that correspond to the preloaded profiles 90-92 and also to the received profile data. The medication therapy provided by the processor 16 typically includes a medication type and delivery parameters. The delivery parameter includes at least one of dose, velocity and concentration. An example of a delivery medication therapy is shown in fig. 12. In this example, the medication therapy includes speed, volume, concentration, time, and medication name.

Alternatively, if output is provided as a bolus medication therapy, the delivery parameters may include at least one of a medication type, a medication concentration, a medication amount, an individual bolus volume, a total bolus volume, a bolus rate, and a timing between bolus deliveries. And, if provided as an output of a loading dose medication therapy, the delivery parameters may include at least one of a medication type, a medication concentration, a loading dose volume, a loading dose rate, a loading dose time, a maintenance volume, a maintenance time, and a diluent volume.

While the system 30a may provide a suggested medication therapy based on one profile data input alone, if the operator enters more than one profile data in the input device 18 at steps 90, 92, as shown in fig. 11, for example, entering data regarding both a patient profile and a condition profile, the processor 16 will perform a cross-analysis based on the preprogrammed medication therapies to obtain or develop the suggested medication therapy.

After the system 30a provides the recommended medication therapy at step 102, the operator has the ability to accept or reject the recommended medication therapy at step 104. If the operator approves the recommended medication therapy at step 104, the system 30a proceeds to step 74, as described above, and the system proceeds as described above. Conversely, if the operator rejects the recommended medication therapy at step 104, the operator is provided the opportunity to adjust any parameters of the recommended medication therapy at step 106. If the operator chooses not to adjust any parameters at step 106, and the operator also chooses not to accept the recommended medication therapy, then the system 30a proceeds to end and denies the therapy request. Alternatively, if the operator chooses to adjust any of the program parameters at step 106, the system 30a proceeds to step 62. As previously described, processor 16 will provide an analysis at step 62 to determine whether the program parameters meet preprogrammed parameter ranges. Following step 62 the system 30a proceeds as described above with reference to system 30.

Reference is now made to the flow chart of fig. 15. This flowchart depicts system 110, which is typically completed prior to programming of a medication therapy, as in systems 30 and 30a above, and thus controller 12 is pre-programmed. As shown in fig. 15, the first step in programming the controller 12 is to select whether the programming is for a drug profile or a drug therapy at step 112. A screen view for programming a drug profile is provided in fig. 13. As shown, the programmer enters a number of program parameters, at least some of which include a drug name 126, an injection volume 128 for treatment, a diluent volume 130 for treatment, a concentration 132, a dose 134, and a speed 136. Other programming parameters are possible, as will be appreciated by those skilled in the art.

Other programming modes are for medication. There are at least two types of drug treatment groups: a patient profile shown at step 122 in figure 15, and a condition profile shown at step 120 in figure 15. Additionally, the programmer may enter medication parameters at step 124. Fig. 14 shows a sample screen for patient profile programming for a particular pre-programmed medication therapy. In this screen, the programmer will enter at least one of a particular patient condition 138 and a disease condition 140. The programmer would then enter program parameters for the medication therapy for the specific profile parameters identified in the programming step above. As shown in fig. 14, the plurality of program parameters are at least the drug 142, the volume for treatment 144, the concentration 146, and the velocity 150.

When the programmer completes programming of a medication or therapy profile, it will be queried at step 116 to confirm the program or to reprogram it. If the programmer confirms, the system 110 proceeds to store the program to memory at step 118. Alternatively, if the programmer chooses to reprogram, the system 110 returns to the start programming command at step 111.

It should also be understood that the memory 14 of the present invention is capable of retrievably storing one or more medication therapies for at least one of a bolus dose medication therapy and a loading dose medication therapy. At least one of the stored medication therapies matches at least one set of patient profile parameters. The processor 16 provides for comparing the patient profile parameters with the medication therapies stored in the memory 14 in the processor 16. The processor 16 also provides for delivering medication therapy that matches the patient profile parameters.

Fig. 16 and 17 illustrate another embodiment of the system of the present invention, designated by reference numerals 200 and 300. Similar to the embodiments described above in at least fig. 3, the systems 200, 300 may use disposable line sets 214, 314. As shown and described in U.S. patent application serial No. 10/040,887, the entire specification of which is incorporated herein by reference, the line set tubing 214, 314 may be connected to its disposable components 212, 312, such as disposable pumps 212, 312. The line set tubing and/or the disposable pump may have an identifier 218, 318. That is, the system 200, 300 uses the disposable component 212, 312 and the identifier 218, 318. The disposable pump may be a micro-pump or a MEMS (micro-electro-mechanical systems) pump, or other type of portable pump. As shown in fig. 16 and 17, the systems 200, 300 generally include a medical pump 212, 312, preferably a MEMS pump, a management line set 214, 314, and a container 216, 316.

MEMS refers to micro-electromechanical system (MEMS) components. MEMS is a technique for forming devices that may be smaller than millimeters in small or minute dimensions, although they may also be larger. MEMS devices are typically fabricated from glass wafers or silicon, but this technology has far exceeded the origins of their semiconductor industry. Each MEMS device is an integrated microsystem on a chip that can include moving mechanical components in addition to optical, fluidic, electronic, chemical, and biomedical components. The resulting MEMS device or component responds to many types of inputs, including pressure, vibration, chemicals, light, and acceleration. The MEMS component can be many different components including various types of pumps, flow switches, flow sensors, tubes, pressure sensors, or combinations of components. These MEMS devices are smaller than conventional machines for detection, communication and actuation. As a result, they can be used in places where mechanical devices traditionally could not be used. MEMS devices also operate at higher speeds and consume less power than conventional devices. Furthermore, MEMS technology has progressed to the step of: MEMS devices can be manufactured at a cost that facilitates handling the device as a disposable or single-use device. MEMS devices are typically etched in silicon. It should also be understood that MEMS may also describe other types of MEMS devices, such as devices that are micro-molded in plastic. Thus, MEMS devices may include devices etched in silicon, molded in plastic, or otherwise fabricated on a small scale. It should be understood that the MEMS component or pump may take many different forms. For example, the MEMS component or pump may include a disposable component, such as a disposable peristaltic pump, volumetric pump, ambulatory pump, syringe pump, or other type of disposable pump. The MEMS component may also be a micro-molded pump or component, which otherwise makes the component in a small size. The MEMS component may also be a piezo-electrically actuated plastic component or a pump. In some embodiments, the flow sensor may be embedded in a recess in the flow path of the disposable pump itself. It should also be understood that the MEMS devices to which the present invention applies may be fabricated using Application Specific Integrated Circuit (ASIC) technology, where the electronics are etched on the same chip as the MEMS flow structures.

The disposable component may be considered a MEMS pump 212 or a line set 214, or a combination of both components. In addition, other types of MEMS components may also be used in the system 200. Containers 216 and 316 are containers similar to container 84 described above at least in fig. 3. In a preferred embodiment, the container 216, 316 is a container suitable for containing a drug or medicament, such as a medical fluid. The administration line set 214, 314 is similar to the line set 25 described above. The line set 214, 314 comprises a tube having one end connected to or in communication with the container 216, 316 and the other end having a conduit or other device for communicating with the patient.

As further shown in fig. 16 and 17, the MEMS pump 212, 312 is operatively connected to the line 214, 314. The MEMS pump 212, 312 may be connected to the line set 214, 314 in a variety of configurations. For example, the MEMS pump 212, 312 may have an inlet port 220, 320 and an outlet port 222, 322, wherein the MEMS pump 212, 312 is connected at an intermediate portion of the line set 214, 314. Thus, a portion of the line set 214, 314 is connected to the inlet port 220, 320, and a portion of the line set 214, 314 is connected to the outlet port 222, 322, with the MEMS pump 212, 312 operatively connected to the line set 214, 314. Once properly connected, the MEMS pump 212, 312 may pump fluid from the container 216, 316 through the line set 214, 314 to the patient.

The system 200, 300 may also use the identifier 218, 318. In a preferred embodiment, the identifier 218, 318 is associated with the MEMS pump 214, 314 or connected to the MEMS pump 214, 314. However, it should be understood that the identifiers 218, 318 may be associated with other components and connected at other locations such as the disposable line sets 214, 314 shown in FIGS. 16 and 17. Various embodiments of identifiers 218, 318 are described in U.S. patent application attorney docket number EIS-6090(1417GP934), which is related to the present application and is included herein by reference, and may include information or identifying indicia as described herein. Additional examples of identifiers are described in U.S. patent application nos. 10/748,589, 10/748,593, 10/748,749, 10/748,750, 10/748,762, 10/749,099, 10/749,101, and 10/749,102.

Referring to fig. 16, the system 200 also uses a controller 230. The controller 230 is operatively associated with the MEMS pump 212 or other MEMS or disposable pump. The controller 230 may communicate with the MEMS pump 212 via a wireless connection. Alternatively, a hard connection may be used, wherein the MEMS pump 212 may be plugged into the controller 230. It should also be understood that the controller 230 may be integral with the MEMS pump 212 as a component thereof. It should also be understood that the controller 230 may be a separate handheld computer or a separate network controller that controls the pump 212 via a network communication link, as will be explained below. As mentioned, the controller 230 has a recognition system 232. The identification system 232 is capable of identifying the data contained in the identifier 218. The recognition system 232 may cooperate with the identifier 218 to operate the system 200. For example, the identifier 218 may contain information identifying the type of line set 214 connected to the MEMS pump 212.

In the embodiment shown in fig. 16, similar to the other embodiments described above, the controller 230 has a memory 260 and a microprocessor, microcontroller, or processor 280. The care-giving institution or hospital may preload the memory 260 with a plurality of patient profiles and condition profiles. The memory 260 may also have preloaded therein associated medication therapies for each of the plurality of profiles. An input screen (not shown) on the controller may be used to receive profile data, such as patient profile data and/or condition profile data for the particular patient for which an infusion is to be provided. The processor 280 compares the profile data received via the input screen to the preloaded profiles to determine if there is a correspondence between the two. For example, an algorithm for determining whether there is correspondence between the two may include: determine if there is an exact match, determine if the profile is within the group, determine if the profile is within the range, and/or determine if the profile is above or below a predetermined value. If a correspondence exists, then the processor 280 provides at least one preloaded medication therapy from the memory 260 for use in the operation of the pump 212 using the corresponding preloaded therapy. The operating parameters associated with the corresponding treatment are used to perform and control the injection. The corresponding treatments and parameters may also be selected in the manner described in the previous examples.

As in the previous embodiment, the controller 230 has a processor 280. As previously mentioned, the controller 230 may be in communication with the MEMS pump 212 and control the operation of the MEMS pump 212 via wireless communication or via wired communication. The controller 230 may also receive status information regarding the operation of the MEMS pump 212. As in the previous embodiment, the controller 212 also communicates with and controls the operation of a plurality of "channels" (not shown). For example, one controller 230 may communicate with and control the operation of multiple MEMS pumps simultaneously or sequentially depending on the therapy being delivered to the patient.

The embodiment shown in fig. 16 may also have a central computer 290, such as a server, and a portable user interface device or input device 240, such as a Personal Digital Assistant (PDA). The user interface device 240 may be in two-way communication with the central computer 290. The central computer 290 and the user interface device 240 include a variety of functions and structures corresponding to the various embodiments disclosed in U.S. patent application serial numbers 10/748,589, 10/748,593, 10/748,749, 10/748,750, 10/748,762, 10/749,099, 10/749,101, and 10/749,102. In addition to the structure and function explained herein, the controller 230 additionally includes the structure and function of the various embodiments disclosed in these previously filed patent applications.

The user interface means or input means 240 may also be used to receive profile data, which may be performed via an input screen (one should be provided) on the controller. For example, patient profile and/or condition profile data for a particular patient for which an infusion is to be provided may be entered via a screen on the user interface device 240. The profile data for a particular patient may be entered in the manner of the previous embodiment. This profile data for a particular patient may then be transmitted to the central computer 290 and further to the controller 230 for use in providing an injection, as explained previously. As part of this process, the processor 280 compares the profile data received through the user interface device 240 with the profiles preloaded in the memory 260 to determine if a correspondence exists.

As mentioned, the identification system 232 of the controller 230 may identify the identifier 218 of the line set 214 and/or the MEMS pump 212. The user interface device 240 may also have an identification system or reader 232, such as a bar code reader, for performing the same and/or related functions as the identification system 232 of the controller 230. The controller 230 may also have a controller identifier 248 specific to that particular controller 230 so that the reader 232 of the user interface device 240 can be used to read each controller identifier 248 and the MEMS or line set identifier 218 and form an association between and among these devices and/or operators (not, but typically, personnel logged into the user interface device 240), as described in detail in the applications incorporated herein by reference above.

The status, alarms, reminders, messages and/or other information relating to the operation of the MEMS pump 212 and/or the medication delivered to the patient by the pump, received and/or generated by the controller 230, may be transmitted to the central computer 290 at a remote location via a communications network, such as a wireless communications network, as described in the aforementioned applications. This status and other information may be received by the interface device 240 and examined and/or acted upon over a communication network, such as a wireless communication network, when passed through the interface device 240 at a location near or remote from the controller 230, as explained in detail in the applications incorporated herein by reference. Likewise, the central computer 290 may be split into a first central computer and a second central computer according to functional separation, data separation, or other separation, as explained in the incorporated applications.

Another embodiment of the present invention is shown in fig. 17. Specifically, rather than using a controller with a memory and a processor, the system 300 includes the MEMS communication interface device 340 and the memory 360 and processor 380 in a separate device from the MEMS interface device 340. In the illustrated embodiment, the memory 360 and processor 380 are located in a central computer 390 that is remote from, but in communication with, the MEMS interface device 340 via a communication network, such as a wireless communication network. The MEMS interface device 340 may be operatively associated with the MEMS pump 312 or other MEMS or disposable pump. The MEMS interface device 340 communicates with the MEMS pump 312 via a wireless connection. Alternatively, a hard connection may be used, wherein the MEMS pump 312 may be plugged into the MEMS interface device 340. It should also be understood that the MEMS interface device 340 may be integral with and a part of the MEMS pump 312. It should also be understood that the MEMS interface device 340 used in conjunction with the memory 360 and the processor 380 may perform the same functions as the pump controller from the previous embodiment.

In the embodiment of FIG. 17, the MEMS interface device 340 has an identification system 348. The recognition system 348 is capable of recognizing the data contained in the identifier 318. The recognition system 348 may cooperate with the identifier 318 to operate the system 300. For example, the identifier 318 may contain information identifying the type of line set 314 connected to the MEMS pump 312.

In the embodiment shown in fig. 17, similar to other embodiments described above, the system 300 has a memory 360, a microprocessor, microcontroller, or processor 380. The care facility or hospital preloads the memory 360 with a plurality of patient profiles and condition profiles. The memory 360 may also have preloaded therein associated medication therapies for each of the plurality of profiles. An input screen (not shown) connected to the central computer 390 or the MEMS interface device 340 can be used to receive profile data, such as patient profile data and/or condition profile data for the particular patient for which an infusion is to be provided. The processor 380 compares the profile data received via the input screen with the preloaded profiles to determine if there is a correspondence between the two. For example, the algorithm used to determine whether there is a correspondence may include: determining whether an exact match exists; determining whether the profile is in a group; determining whether the profile is within range; and/or determining whether the profile exceeds or is below a predetermined value. If a correspondence exists, then the processor 380 provides at least one of the preloaded medication therapies from the memory 360 for use in operating the pump 312 with the corresponding preloaded therapy. The operating parameters associated with the corresponding therapy are used to perform and control the injection. The corresponding treatments and parameters may also be selected in the manner described in the previous embodiments.

As described above, the MEMS interface device 340 may be in communication with the MEMS pump 312 and control the operation of the MEMS pump 312 via wireless or wired communication, in conjunction with the memory 360 and the processor 380. The interface device 340 may also receive status information regarding the operation of the MEMS pump 312. As in the previous embodiment, the interface device 340 also communicates with and controls the operation of a plurality of "channels" (not shown). For example, one interface device 340 may communicate with and control the operation of multiple MEMS pumps 312 simultaneously or sequentially depending on the therapy being delivered to the patient.

As mentioned above, the embodiment shown in FIG. 17 has a central computer 390, such as a server, and a portable user interface device or input device 330, such as a Personal Digital Assistant (PDA). The user interface device 330 may be in two-way communication with the central computer. The central computer 390 and the user interface device 330 may include a variety of functions and structures corresponding to the various embodiments disclosed in U.S. patent application serial numbers 10/748,589, 10/748,593, 10/748,749, 10/748,750, 10/748,762, 10/749,099, 10/749,101, and 10/749,102. In addition to the configurations and functions described herein, the MEMS interface device 340, the memory 360, and the processor 380 may together comprise the structure and functions of the various embodiments described above and of the controllers in these previously filed patent applications.

The user interface device or input device 330 may also be used to receive profile data, which may be performed through an input screen (if provided) connected to the central computer 390 or the MEMS interface device 340. For example, patient profile data and/or condition profile data for a particular patient for which an infusion is to be provided may be entered via a screen on the user interface device 330. Such profile data for a particular patient may be entered in the manner of the previous embodiment. Such profile data for a particular patient may be transmitted to the central computer 390 and further transmitted to the MEMS interface device 340 for use in providing an injection, as explained above. As part of this process, the processor 380 may compare the profile data received through the user interface device 330 to the preloaded profiles in the memory 360 to determine if a correspondence exists.

As described above, the identification system 348 of the MEMS interface device 340 can identify the identifier 318 of the line set 314 and/or the MEMS pump 312. The user interface device or input device 330 may also have an identification system or reader 332, such as a bar code reader, for performing the same and/or related functions of the identification system 348 of the MEMS interface device 340. The MEMS interface device 340 may also have a MEMS interface identifier 348 that is specific to the particular MEMS interface device 340, such that the user interface device reader 332 may be used to read each of the MEMS interface identifier 348, MEMS or line set identifier 318, and form associations between and among such devices and/or operators (not shown, but typically personnel recorded in the user interface device 330), as described in detail in the applications incorporated herein by reference above. The system may be configured to use one-way and/or two-way barcodes when using barcodes.

The status, alarms, reminders, and/or other messages regarding the operation of the MEMS 312 and/or delivery of medication to the patient via the pump received and/or generated by the MEMS interface device 340 may be transmitted to the central computer 390 at a remote location via a communication network, such as a wireless communication network, as described in the above-identified applications. This status and other information may be received using the user interface device 330 and examined and/or acted upon over a communication network, such as a wireless communication network, when passed through the user interface device 330, which may be closer or farther from the MEMS interface device 340, as explained in detail in the applications incorporated herein by reference. Likewise, the central computer 390 may be split into a first central computer and a second central computer according to functional separation, data separation, or other separation. As noted above, it should be understood that disposable elements such as the MEMS pump 312 can be actuated and controlled using the central computer 390.

The systems 200, 300 of fig. 16 and 17 also include programming means to program the memory 260, 360 of the system to preload information about the patient and condition profiles and related medication therapies and parameters. In the system 200 of FIG. 16, this programming device may be part of the controller 230, part of the central computer 290, and/or part of the user interface device 240. Once programmed using the programming device, the MEMS pumps 212, 312 may be actuated using the controller 230 or the MEMS interface device 340. Upon actuation of the valve, the valve is opened,the controller 230 or the MEMS interface device 340 controls the MEMS pumps 212, 312, wherein the pumps 212, 312 operate to deliver medication to a patient. The pumps 212, 312 have the ability to recognize a predetermined event, such as when fluid is generally sufficiently pumped from the containers 216, 316 to form a generally empty container. For example, once a predetermined pressure sensed by the MEMS pump 212, 312 is reached, the MEMS pump 212, 312 will be caused to shut down. Once the MEMS pump 212, 312 is turned off, this state triggers an alarm, reminder, or other message to the central computer 290, 390 for further notification to the user interface device 240. In one embodiment, memories 260, 360 and/or identifiers 218, 248, 318, 348 may comprise a plug-in or a non-plug-in electrically rewritable non-volatile memory manufactured by VIRAGE LOGIC and designated NOVEA athttp://www/viragelogic.com/productsShown and described.

Other features may be used with any of the embodiments described above. As discussed, a kit may be formed that includes the container 216, 316, the line set 214, 314, and the identifier 218, 318. The identifier 218, 318 may be associated with or connected to any of the containers 216, 316 and line sets 214, 314. In some embodiments, the container 216, 316 may include a pre-attached reconstitution device with a pre-attached drug container, such as a vial. The regeneration device may be actuated to regenerate the medicament using the fluid 217, 317 in the reservoir 216, 316. It should be understood that the identifier 218, 318 may also include information regarding vials that may be pre-connected to the reconstitution device. In another embodiment, a disposable pump, such as a micro-pump or MEMS pump, may also be connected to the line set 214, 314 and considered part of the kit. The identifiers 218, 318 associated with such kits may have any of the information described above for the overall proper operation of the system. In yet another embodiment, the container 216, 316 or a container associated with a kit may include a pre-mixed medicament 217, 317.

In another embodiment involving fig. 16 and 17, as noted above, the identifiers 218, 318 may be specifically programmed to include profile data for a particular patient in addition to, for example, a desired patient identification of the line set and/or identification of the medications 217, 317 in the reservoirs 216, 316. The reader 230 on the controller 230, the readers 240 and 330 on the user interface device, or a reader (not shown) on the MEMS interface device 340 may be used to automatically read the profile data and/or other information in the identifiers 218, 318 and use this information for programming and controlling the operation of the MEMS pumps 212, 312 according to the preloaded medication therapies for the corresponding preloaded patient profiles and condition profiles. Through at least one of the controller 230, the user interface 240, 330, and/or the central computer 290, 390, the user may be given the opportunity to accept, reject, or modify the medication therapy suggested by the system 200, 300 as a result of the profile data being read from the identifier 218, 318.

It should be understood that the pumps used in the systems described above and below herein may include safety software. The safety software can generate a basic error alarm in which the pump will assume an error safe condition, e.g. no free flow of drug through the pump. A variety of software/pump configurations may be used. For example, all software may be provided on the pump head, or all software may be provided off or remote from the pump head. Furthermore, all software may be located off the pump head, except that certain safety software is located on the pump head. In particular and preferably, the controller 230 may include safety software to generate a basic error alert when the remaining functions of the controller are not operating or are in a hazardous state. In this case, the controller 230 will assume a fail safe condition to prevent free flow of medication through the pump, which the controller 230 controls and provides a basic level of alarm/reminder. Alternatively or additionally, safety software may also be present at the central computer 290, 390 to achieve this function, for example when control of a pump, such as the MEMS pump 212, 312, occurs directly from the central computer 290, 390. Alternatively or additionally, safety software may also be present at the pump or MEMS element 8612 to achieve this function, for example when at least some of the minimum levels of control are provided at the pump or MEMS element 212, 312. These security software embodiments may be applied at least in a similar manner to the embodiments shown in fig. 87 and 88 below, for example, disposed on the interface device 240, 330, the central computer 290, 390 and/or the MEMS element 212, 312.

It should be emphasized that the above-described embodiments of the present invention, particularly, any "preferred embodiments" are possible examples of implementations, merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the spirit and principles of the invention. All such modifications are intended to be included within the scope and content of this invention and protected by the following claims.

A fan apparatus applied to a front suction/discharge type air conditioning device will be described.

Claims (13)

1. A controller for a programmable medical pump comprising a memory having at least one preloaded patient profile and at least one preloaded condition profile, said memory further having an associated preloaded medication therapy for each of said plurality of profiles; an input device for receiving profile data including at least one of patient profile data and condition profile data corresponding to a particular patient; and a processor for providing at least one of the preloaded medication therapies in accordance with the received profile data, wherein the processor compares the received profile data to the preloaded profiles in memory to determine whether the medication therapy is to be provided.

2. The controller of claim 1, wherein the processor is adapted to select the medication therapy from the preloaded medication therapies in the memory corresponding to the preloaded profiles.

3. The controller of claim 1 or 2, wherein the memory is further preloaded with a plurality of medication profiles and for each medication profile the memory is further preloaded with an associated medication therapy comprising at least one of a dose, a rate, a concentration, and a medication type.

4. The controller according to claim 1 or 2, wherein the preloaded patient profiles comprise data representing at least one of a patient pain state, age group and gestational age.

5. The controller of claim 1, wherein the preloaded condition profiles comprise data indicative of at least one of a medical condition and a medical disease state.

6. The controller of claim 3, wherein the preloaded medication profiles comprise data representing at least one of a medication, a non-medication, and a solvent.

7. The controller of claim 1, wherein the medication therapy provided by the processor includes a medication type and delivery parameters including at least one of dose, velocity, and concentration.

8. The controller of claim 1, wherein the input device is a digital assistant.

9. The controller of claim 1, wherein the input device comprises a receiver for receiving information from an information identifier on the line set.

10. The controller of claim 9, wherein the information identifier comprises information comprising at least one of: patient name, age, gender, weight, allergies, conditions, medication name, medication type, medication concentration, medication amount, individual bolus volume, total bolus volume, bolus rate, dose, timing between bolus deliveries, maximum number of boluses per unit time, loading dose volume, loading dose rate, loading dose time, maintenance rate, maintenance volume, maintenance time, maintenance dose, diluent volume, patient profile data, and condition profile data for at least one of a medical condition and a medical disease state.

11. A medical system for therapeutic delivery of a drug, comprising:

a disposable tube;

a disposable electromechanical pump element connected to the tube;

a pump interface device operatively connected to the pump element;

a processor; and the number of the first and second groups,

a memory cooperatively interacting with the processor, the memory including a plurality of preloaded patient profiles and preloaded condition profiles, and associated medication therapies for the at least one of the plurality of profiles,

wherein the processor is configured to select the relevant medication therapy based on the received profile data for the particular patient and compare the received profile data to the preloaded profiles in memory to determine whether the relevant medication therapy is to be delivered.

12. The system of claim 11, further comprising a disposable reservoir connected to the disposable tube.

13. The system of claim 12, wherein the disposable reservoir includes a valve configured for remote control.