INFUSION PUMP CONFIGURATION SCHEME USING EEPROMS

Abstract: A programmable infusion pump (10) can be configured to operate in one of several operational modes (i.e. BASAL, PCA, BASAL and PCA, etc.). The pump (10) is provided with an erasable, preferably non-volatile memory (34) for holding information designating one of the modes. The end user can set up the pump (10) easily and expeditiously for the designated mode, since the other, non-designated modes are made invisible.

Description: INFUSION PUMP CONFIGURATION SCHEME USING EEPROMS BACKGROUND OF THE INVENTION a. Field of Invention This invention pertains to a microprocessor- controlled infusion pump which is field programmable to a desired configuration, said configuration being stored in a non-volatile memory. The user can configure or customize the infusion pump to conform to his standard usage protocol. Microprocessor-controlled infusion pumps have become widely accepted and used in hospitals for the delivery of a variety of medications. These types of devices are particularly useful for post¬ operative pain management wherein a pain relieving medication is administered to the patient at a small infusion rate. These types of devices are especially useful for Patient Controlled Analgesia (PCA) procedures wherein within certain time constraints, a patient may request and receive an additional pain relieving dose. b. Description of the Prior Art To adequately describe the scheme some background is necessary. As the technology involved in designing drug infusion pumps has become more advanced, such pumps have become more complex. The earliest electronic drug infusion devices simply delivered fluid at a fixed rate. Later devices allowed a selection of rates using a mechanical means, such as a clutch and a transmission. Eventually the pumps advanced to the point where rates could be selected using thumb-wheel switches or rotary knobs and dials. Electronic circuitry inside the pumps interpreted these switches and dials and automatically ran the motor at the proper rate. With the advent of microprocessor technology, the pumps developed to the point where their activities over time could be varied. The Bard PCA made by the assignee of the present invention is an example of such a device. A user can select a constant infusion rate, as well as parameters to define a patient requestable dose. Based on the information programmed into the pump by the doctor, the pump can automatically administer pain medication at the patient's push-button request. The patient is only permitted to receive a dose after a certain amount of time has passed since the last dose. With the sophisticated microprocessor technology available today however, the number of choices in programming an infusion pump has increased. With this increase in choices comes an increased risk of programming errors. The increase in choices also contributes to the user's dissatisfaction with the complexity of the device. Programming a pump for operation in many cases has become complex, confusing and time consuming. It is possible to divide up the user population such that there are groups of users each of whom use their pumps in a particular way. It would be desirable for these groups to purchase infusion pumps that are customized to their particular protocols. For example, in a hospital where all infusion pump programming is done in milliliters, it is not desirable to ask the user for concentration units. However, the pump must be usable in hospitals where all programming is done in milligrams also. Another problem is that many pumps have become multi-purpose, that is, capable of performing a variety of drug therapies. For example, a pump might be capable of continuous infusion, Patient Controlled Analgesia ("PCA") infusion, and intermittent therapy infusion. This flexibility unfortunately complicates the programming of the device. With this added complexity comes the risk that a pump might accidentally be programmed in the wrong mode with potentially disastrous results. Despite these risks, there is a great incentive to develop these flexible pumps. There is a cost advantage to having one pump that can be used for a variety of different therapies. The hospital may purchase fewer pumps since their inventory of pumps becomes more flexible. They only have to train their service personnel to maintain only one type of device, and the cost of the associated disposables goes down since they would be buying them in larger quantities. Designing custom pumps for the wide variety of usage protocols is not feasible or cost efficient. Yet designing pumps that can be used with a variety of protocols yields complex user interfaces and the risk of programming error. The solution most manufacturers take to this problem is to attempt to design products that are as user-friendly as possible, using custom LCD displays and software. All of the programming options are presented to the user who must know how to disable each undesired function each time the pump is used. For example, one device allows the option of entering a prescription in milligrams or milliliters. When programming the pump, a concentration, which is necessary for milligram programming, is always requested. To select milliliter programming the user must enter a zero for the concentration. Another approach that is used is to present the user with lists of programming options, or menus. At each juncture in the programming where a choice must be made, the user must select a choice from a list. The problem with these approaches is that each option that is added to the pump adds to the complexity of the user interface. This increased complexity results in user dissatisfaction and greater risk of programming error. These approaches also add to the amount of time required to program the device before each use and increase the training required for the device to be used. Another solution is to use some sort of device or switch to customize the operation of the pump for its typical usage. A good example of this is Bard's patented Smart Label system for its InfusO.R. tm pump wherein different magnetically coded labels on the front of the pump allow users to customize their pump for a specific drug. The same pump also has a slide switch that allows users to select the brand of syringe they will be using with the pump. Yet another solution would be to use some sort of cartridge or cassette that can be inserted into the pump to provide the information required to customize the pump. This sort of system achieves the goal of a flexible customizable pump, nevertheless, such a system may add significantly to the cost of the product. Each of these two solutions also adds costly accessories (the labels, cartridges or cassettes) to the pump which could be misplaced. Misplacing one of these accessories could result in needless down-time for a potentially very expensive piece of equipment. As a result of the problems inherent in the existing solutions to these problems, manufacturers are restricted in terms of what new capabilities they can add to their pumps. Thus, programmable infusion pumps are advantageous because a single pump can be programmed by a health practitioner, a pharmacist, or nurse, in accordance with standard protocol set up by hospitals, to perform a large number of functions. Thus a single pump can be set up to perform the functions, and replace a variety of pumps dedicated for specific functions. This advantageously reduces expenses to hospitals related to both the cost of acquiring medical equipment and inventory control. Unfortunately, the very flexibility of computer controlled infusion pumps also proves to be a disadvantage because . f the complex and time consuming programming steps required to set them up. This problem is particularly disadvantageous if a pump has to be programmed by staff which normally is not used to the procedure, or has received inadequate training. The following description of a known programmable infusion pump illustrates the problems succinctly. One of the programmable infusion pumps presently available is the Bard Ambulatory PCA Infusion Pump made by the assignee of the present invention. This pump consists of a generally rectangular housing having a front panel with an LCD display screen, and a key pad for entering various commands. Inside the housing there is a chamber for a plastic bag from which a medicine is to be dispensed. A pump motor controlled by a microprocessor delivers the contents of the bag through a tube. The operational parameters are entered through the keypad in response to prompts from the LCD panel, during an initializing program as set forth in the flow chart 100 of Figure 1. The first step, step 102, of this program requires is a request for a security code. A person may not alter the pump parameters without this code. A security code is entered at the factory and may be changed by using a special sequence of commands. This code is stored in a special static RAM of the pump powered by its own battery. In step 102 the security code is requested and compared to the code in the static RAM. If the code is correct, the program moves onto step 10 . In step 104 the volume of the bag is entered for example in mi's. In step 106 the pump is primed. In step 108, the concentration of the medicine in the bag is entered. As part of step 108 a special subroutine is run to allow the operator to select the concentration in either mis, or mgs. Thereafter, all parameters are selected and displayed in the selected units. In step 110 the PCA dose, the amount of medicine to be administered upon a patient request, is set. In step 112 the minimum delay between PCA doses is set (normally in minutes) . In step 114 the basal rate is set. In step 116 the total hourly limit is set. The hourly limit consists of the total basal rate plus the PCA doses that can be delivered in a given hour. In step 118 the initial loading dose or bolus dose is set. During each of the steps 102-118 various internal calculations and checks are performed to insure that the prescription being set up is consistent and that it conforms to the capabilities of the pump. It is clear from the above description that depending on the selections made during the setup program, the pump is capable of performing in several different modes including (a) PCA only wherein a drug is administered only in response to a request from a patient, (b) basal only, wherein the patient receives the drug continuously at a preselected rate and may not request an additional dosage and (c) PCA and basal wherein the patient receives the drug continuously at a preselected rate, however if he so desires, he may request additional PCA doses. However in order to set up the pump in any of these modes, a person must proceed through the whole setup program and select the correct responses even when some of the responses are superfluous or redundant. For example, if the PCA only mode is desired, the person is still requested to enter a basal rate. Thus persons designated to set up a pump must receive extensive training, and if they forget the set up procedure they may be confused by it. A further problem arises from the fact that while usually hospitals have a standard designation for the units or concentration of the drugs to be administered, the pump must be set for the right units or concentration every time the setup procedure is used. Thus the set up process requires extra steps that are repetitive. Finally, the setup program does not permit a person to set any maximum default values for the various parameters. OBJECTIVES AND SUMMARY OF THE INVENTION In view of the above disadvantages of the prior art pumps, it is an objective of the present invention to provide a programmable pump which may be easily configured from one mode to another in the field. A further objective is to provide a pump which may be easily set up for a particular configuration and using fewer key strokes than in the prior art. Yet a further objective is to provide a pump with separate non-volatile memory means for storing configuration information whereby the pump need not be reconfigured every time it loses power. Other objectives and advantages of the invention shall become apparent from the following description. This invention consists of a an infusion pump assembly and a technique by which capabilities can be added to an infusion pump without making programming the pump for each use more complicated, and without adding any sort of cartridge. Infusion pumps designed using this invention are exceedingly flexible, capable of performing a wide riety of different drug infusion therapies. Ye'. _hey are as easy and safe to use as if they were designed for a specific protocol and regimen. This pump assembly includes an electrically alterable non-volatile memory device connected to a central processing unit (CPU) . The CPU can read the contents of this memory and these contents may be changed under control of the pump assembly software. If there is no software request for the change of this memory, the contents are maintained indefinitely. This non-volatile memory is preferably of the variety known as EEPROM or Electrically Erasable and Programmable Read Only Memory. This EEPROM is typically contained in an integrated circuit package located on a printed circuit board inside the pump assembly housing. However, it may also be contained inside of a microprocessor or microcontroller used in the pump assembly. EEPROM is preferred for the non-volatile memory component since it does not require any sort of battery backup to maintain its contents. The term non-volatile memory, in this instance, is intended to indicate that the memory's contents are maintained independent of the status of the system's primary power source. In the case of a battery operated infusion pump, the non-volatile memory's contends are maintained whether or not a primary battery is inserted or removed. Alternate configurations could include secondary-battery backup of a Static RAM (Random Access Memory) . The techniques required for implementing this invention are incorporated into the software that controls the pump, and would have several parts: i) Configuration Access Protectiony ii) The Pump Configuration Selection Routines iii) The Default Configuration iv) The Configuration Reading Routines v) The Configuration Interpretation Routines vi) The Configuration Writing Routines vii) Configuration Safety Routines i. Configuration Access Protection Since the configuration capability of the device allows it to be customized for particular usage protocols, a user who uses the pump assembly in only one particular configuration does not necessarily need to be made aware of how the configuration of the pump assembly is changed. For example, a hospital's biomedical engineering department may be made responsible for setting and verifying proper pump configuration and the nurses in a particular hospital unit may always use the pumps with one particular configuration. A hospital's protocol may even require that the configuration only be carried out by authorized personnel. To ensure the security of the configuration, routines are provided that restrict access to the configuration changing routines. Preferably, this routine requires a special sequence of key presses that must be used to access the configuration changing routine. The sequence of key presses is such that it does not occur during normal operation of the pump assembly. For example, the sequence may include holding down several keys simultaneously and/or pressing several keys in a particular order, optionally with a time limit. ii) The Pump Configuration selection Routines Software routines are necessary to change the configuration of the pump. This involves prompting the user for his choice of configuration options and saving that information so it can be written into the non-volatile memory component. iii) The Default Configuration When shipped from the factory the pump assemblies are configured in some general manner. This default configuration would typically be the most commonly used configuration or perhaps a configuration that gives maximum capability. iv) The Configuration Reading Routines When the pump is first turned on, the CPU reads in the selected configuration. The software routines that perform this task access the non¬ volatile memory component, and then read its contents. These contents contain coded information corresponding to a desired configuration of the pump. This information would be decoded by the Configuration Interpretation Routines. v) The configuration Interpretation Routines These routines are integral to the normal operation of the pump. They interpret the coded information which has been read from the non¬ volatile memory component and implement them. This implementation involves modifying the user interface of the device according to the * information specified via the Configuration Selection Routines. vi) Configuration Writing Routines After the Configuration Selection Routines have been used to select a configuration, the CPU accesses the non-volatile memory component and writes coded information to it that specifies the configuration. This information remains there until the next time the Configuration Selection Routines are activated. The coded information is read back using the Configuration Reading Routines. vii) Configuration Safety Routines These routines verify proper operation of the configuration circuit and the software routines that use it. When configuration information is written to the non-volatile memory component, error checking information would be written also. When the configuration information is read back this error checking information would be used to ensure that no failures have occurred in the circuit or the software routines. The configuration information may also be subject to a "reasonableness" check. This would simply involve making sure that the configuration selected is possible. A typical implementation of the error checking information scheme involves writing the coded configuration information to the non-volatile memory component along with the two's complement of the information. A checksum could also be written for further verification. A typical implementation of the reasonableness check scheme involves ensuring that configuration selections fall within selectable bounds. For example, if a device was configured so that a maximum dose volume is selected, that maximum dose volume setting is verified to ensure that if falls within the range of possible maximum dose volumes. BRIEF DESCRIPTION OF THE DRAWINGS Figur. 1 shows a flow chart for a prior art programmable infusion pump; Figure 2 shows a block diagram of a pump assembly constructed in accordance with this invention; Figure 3 shows a flow chart for a program for the pump assembly of Figure 2 for selecting its mode of operation; and Figure 4 shows a flow chart for a program for setting up the pump assembly of Figure 2 after a specific mode has been configured. DETAILED DESCRIPTION OF THE INVENTION Referring now to Figure 2, an infusion pump assembly 10 constructed in accordance with this invention includes a pump 12 connected to a bag, syringe, or other drug container means 14 by a tube 16. The pump 12 is used to dispense a drug from bag 14 to a patient through a tube 18. Tube 18 may be an IV tube used to feed the drug to a patient intravenously, it may be connected to an epidural catheter, and so on. The pump 12 is operated by a microprocessor 20 through a pump control interface 22. Also associated with microprocessor 20 is a display 24, a keypad 26, a RAM 28, an audio transducer 30, a ROM 32, and an EEPROM 34. Power to all these components is provided by a power supply 36. Preferably, to increase the versatility of the pump the power supply 36 provides this power selectively from a standard AC line, one or more rechargeable batteries, or one or more disposable batteries. Details of this power supply may be found in U.S. application S.N. 778,557 filed October 18, 1991, entitled INFUSION PUMPS WITH BATTERY BACK-UP and commonly assigned with the present application. All these components may be disposed in a common housing 40. The basic programming of the microprocessor 20 is located in the standard ROM 32. If no changes are made in the configuration of the microprocessor 20, the program follows the steps initializing program or state outlined in Figure l. ROM 32 also contains initial parameters for the operation of the pump set in the factory. These parameters are provided as default values in case a clinician fails to set these parameters correctly, or as a means of providing guide values if the EEPROM 34 fails and needs to be replaced or reprogrammed. However, before this pump is released for usage, it may be first reconfigured in a mode selection state to a mode compatible with the hospital protocol, and/or for a designated usage. For example, a hospital may decide to use a particular pump in a basal only mode. In order to configure the pumps to this mode, first the microprocessor is entered into a pump configuration subroutine 16 Finally, in step 160 the bolus limit is set for the initial dosage required to bring the level of the prescribed drug in the patient to a desired value. In step 162, the parameters and limits selected in steps 152-160 are stored. Preferably, in order to ensure that the pump assembly remains configured in the selected mode, these parameters and limits are stored in EEPROM 34 as discussed above. As mentioned above, if the pump assembly 10 is not reconfigured, it operates in accordance with the program flow chart of Figure 1. However, once the pump assembly 10 has been reconfigured, its original program is modified so that it operates in the selected mode. Of course, the pump must still be set up for operation during a set up stage. However, as illustrated below, since the mode and limits of the pump have been already selected, the set up of the pump system of Figure 2 is easier to learn and less confusing than the set up of Figure 1. For example, if in step 152 the clinician has selected the BASAL mode, then the pump system 10 is set up as shown in Figure 4 using the following steps. As soon as the pump system is energized, the contents of the EEPROM 34 are loaded into the RAM 28. During each of the following steps the maximum limits or parameters preset during the mode selection stage cannot be exceeded. In step 202 a security code is requested. This step is still required to prevent tampering. The security code may be stored now in the EEPROM 34. In step 204 the volume of drug in bag 14 is specified. In step 206 the pump is primed to remove air bubbles from the system. In step 208 the concentration of the drug 15 consisting of a mode-selection sequence state. This may be accomplished for example by pressing several keys on key pad 26 in a preselected order. Preferably, the keys and order are selected to avoid a sequence which would occur under normal operation of the pump. Once the proper sequence of keys is entered, the icr processor 20 shows prompts on display 24 necessary for reconfiguring the pump assembly. At each prompt, the factory preset value of the pertinent parameter is shown on display 24. More specifically, as shown in Figure 3, after the proper mode selection sequence of keys have been activated (step 150) , the desired mode of operation is requested in step 152. For example, during this step, the clinician indicates whether the pump is to operate in a PCA ONLY, BASAL ONLY or PCA and BASAL mode. In the next step 154 the clinician is requested to enter the concentration or units of measurement to be used. Once this selection is made the microprocessor will display all devices of units (i.e. ml, mg, meg, etc) . Next, in step 156 the clinician is requested to enter the limits for the basal administration. That is, the clinician is asked to set the maximum limit for the continuous administration rate of the drug. If the PCA ONLY mode is selected in step 152 then step 156 is skipped. Next, in step 158 the clinician is asked for the limits of the PCA administration, i.e. the PCA dosage and the PCA delay (the minimum time period between allowable PCA dosages) . If the BASAL ONLY mode is selected in step 152 then step 158 is skipped. in the bag is requested in the preset units. In step 214 the basal rate is set. Finally in step 218 the bolus is set. Thus steps 110, 112 and 116 (Figure 1) have been skipped. Similar savings are accomplished for the PCA ONLY mode. In summary, the initializing pre ram has been broken up into two stages: a presetting stage during which the pump is configured to a particular mode, and operational limits are selected, and a setup stage during which the actual operational parameters are selected. The pump assembly is set up so that persons having higher levels of security and technical expertise can select the pump mode while persons requiring less skills can set up the pump assembly. E. NOVEL FEATURES The novel features of this invention include: i) The use of a non-volatile memory device with associated software routines for the purpose of customizing the user interface of a complex drug infusion device. Included in this would be the use of a default configuration and user selectable alternate configurations. Pumps using this invention would be unique in that once they are programmed according to a particular user group's standard protocols, they would act as if they were a device designed specifically for that application or protocol. This would greatly enhance the user- friendliness of the device, and would minimize the risk of programming errors. ii) Another novel feature of this invention is that it will allow the design of drug infusion pumps that are multi-purpose. For example, in the past a hospital would have to purchase separate devices for chemotherapy administration, Patient Controlled Analgesia (PCA) administration, or intermittent antibiotic administration. With the introduction of this configuration capability, a single pump will be capable of being configured in a chemotherapy mode, a PCA mode or an intermittent mode. This would have been less desirable in the past due to the great complexity of the user interface that would have been required. iii) Another novel feature is that this invention can be used to enhance patient safety by allowing each hospital to program limits on each prescription item. These prescription limits could be tailored to the way each hospital uses its pumps. Programmable prescription limits would also enhance the flexibility of the device since the limits could be changed to adapt to new drug dosing regimens as they are developed. iv) Another novel feature of this invention is that patient safety will be enhanced because the the pump can be configured to operate only in a specific mode. For example, continuous infusion could be disabled by configuration to prevent accidental programming of an unwanted continuous infusion. F. IMPROVEMENTS OVER STANDARD PRACTICES This invention is a vast improvement over the standard practice of using a complex user interface to program infusion pumps. The simplifications of user-interface attained by the use of this invention will enhance the desirability of infusion pumps by providing devices that are much easier to use than those available today. The pumps designed using this technique will also be safer since the customized user interfaces will reduce the risk of programming errors. This approach is also of much lower cost than such other approaches as mechanical switches, "smart" labels, or insertable cartridges or cassettes. This approach also uses much less space inside the device than these other approaches. This is important since the devices involved are usually small and portable. Finally, this approach will typically consume less power than these approaches since the configuration circuit would only be activated briefly at power up and a similar amount of time if and when it is updated. This is important since these devices are typically battery operated. Obviously, numerous modifications may be made to this invention without departing from its scope as defined in the appended claims.

Claims: I claim: 1. A programmable infusion pump assembly for administering a drug to a patient, said assembly comprising: a pump; microprocessor means for controlling said pump; first memory means coupled to said microprocessor means and including programming defining several configurations for said pump; selection means for selecting one of said configurations; and second memory means coupled to said microprocessor for holding said configuration; said microprocessor means being arranged and constructed to operate said pump in said configuration. 2. The assembly of claim 1 wherein said first memory means is a non-erasable memory. 3. The assembly of claim 1 wherein said second memory means is an erasable memory. 4. The assembly of claim 3 wherein said second memory means is non-volatile memory. 5. The assembly of claim 3 wherein said second memory means an EEPROM. 6. The assembly of claim 1 wherein each said configuration defines an operational mode. 7. The assembly of claim 1 wherein said selecting means includes parameter means for selecting a set of limiting operational parameters for said pump. 8. A programmable infusion pump assembly for administering a drug to a patient, said assembly comprising: a pump; microprocessor means for controlling said pump; first memory means coupled to said microprocessor means and including programming defining several operational modes for said pump; selection means for selecting one of said operational modes, said mode selection means being responsive to a request to designate an operational mode; and second memory means coupled to said microprocessor for holding said one operational mode; said microprocessor means being arranged and constructed to operate said pump in said one operational mode. 9. The assembly of claim 8 wherein said selecting means includes parameter means for selecting a set of limiting operational parameters for said pump. 10. The assembly of claim 9 wherein said selecting means includes unit selecting means for selecting the units defining a specific drug administration by said pump. 11. The assembly of claim 8 wherein said first and second memory means are non-volatile. 12. The assembly of claim 8 wherein said first memory means is non-erasable and said second memory means is erasable. 13. The assembly of claim 6 wherein said second memory means is an EEPROM. 14. An infusion pump assembly comprising: a pump for administering a drug; microprocessor for controlling said pump; a keypad for entering commands to said microprocessor means; display means for displaying prompts and information from said microprocessor; first memory means for storing a program defining several modes of operation for said pump, including a BASAL ONLY mode, a PCA ONLY mode, and a BASAL and PCA mode; and second memory means; wherein said microprocessor means includes sensing means for sensing a mode designating command from said keypad, mode selecting means for designating one of said modes of operation in response to said mode designating command, and storing means for storing information designating said one mode of operation into said second memory; said microprocessor means operating said pump in accordance with information stored in said second memory means. 15. The assembly of claim 14 wherein said second memory means is a non-volatile memory. 16. The assembly of claim 14 wherein said second memory means is an erasable memory. 17. The assembly of claim 14 wherein said second memory mear is an EEPROM. 18. The assembly of claim 14 wherein said sensing means includes parameter means for sensing a set of limiting operational parameters from said keypad for said pump. 19. A method of administering a drug to a patient comprising the steps of: providing a programmable infusion pump assembly including a pump, a microprocessor for controlling said pump, a first memory for operating said pump in several modes of operation, and a second memory; selecting one of said modes of operation; storing information defining said one mode of operation in said second memory; setting said microprocessor up for administering drug to a particular patient in accordance with said one mode of operation; coupling a drug container to said pump; and starting said pump. 20. The method of claim 19 further comprising the steps of selecting a unit of measurement for said drug and storing said unit into said second memory prior to the step of setting said microprocessor. 21. The method of claim 19 further comprising the steps of selecting limiting parameters for said one mode of operation and storing said limiting parameters in said second memory, wherein said microprocessor cannot be set during said setting step to operate said pumps beyond said limiting parameters. 22. The method of claim 19 wherein said modes of operation include a BASAL ONLY, PCA ONLY and BASAL and PCA mode.

Inventors: GILLESPIE JOHN JR, GILLESPIE, JOHN, JR.
Applicants: BAXTER INT, BAXTER INTERNATIONAL INC.
Application year: 1993
Main classification: G06F15
IPC codes: A61M5, F04B49