Apparatus for therapeutic delivery of medication

ES 2 328 593 T3

DESCRIPTION

Apparatus for the therapeutic administration of drugs.

Field and background of the invention

In general, the present invention relates to an apparatus and a method for programming medical devices, and more specifically to an apparatus and a method for programming medical or infusion treatments for a medical pump, such as a infusion pump.

Medications and non-drug products can be administered to a patient by an infusion device or by various other types of medical devices. However, the patient's response to an administered drug is not always immediate. To promote a more rapid response in the patient, physicians may give the patient a relatively high proportion or dose of drugs. A relatively high dosage form of medication is known as a "bolus dose." The purpose of the bolus dose is to speed up or amplify the patient's response.

In addition, certain types of drug administrations are carried out to a patient in order to maintain the presence of a drug in the patient for a period of time. These administrations are known as "maintenance administrations" or "maintenance doses". Sometimes, before a maintenance dose, it is necessary to quickly deliver an amount of medication to the patient at a level that they can maintain. To establish this level of maintenance, physicians can administer drugs to a patient in a relatively high ratio or dose. This relatively high starting dose or ratio of medication is known as a "loading dose." The purpose of the loading dose is to establish the level of medication in a patient, after which a maintenance dose can be applied to maintain that level. The bolus or loading dose can be delivered with a drug fluid, non-drug product, or test substance, and can be administered intravenously, epidurally, subcutaneously, or arterially.

Modern infusion devices allow manual data entry into the infusion device, making it easier for the device to control the infusion of medication to the patient. The data provided to such devices describes the infusion treatment and includes parameters such as the drug volume, the infusion rate, and the total time the infusion takes place. Some of these devices allow data entry that reflects multiple regimens, allowing the device to automatically monitor multiple infusions simultaneously or sequentially.

A limited number of infusion devices are provided with a memory that can store parameter data for standard continuous infusion protocols. These devices allow the clinician to retrieve the parameter data of a standard continuous infusion from the memory of the device. This feature offers two clear benefits to the physician. First, parameter data can be quickly recalled from memory without having to re-enter it. Thus, these infusion devices provided with memory have the advantage that they can usually be programmed more quickly than infusion devices that are not provided with memory. Second, because parameter data can be stored and retrieved, it no longer always needs to be re-entered, and thus human error associated with data entry is minimized. Memory-equipped infusion devices allow you to recall safe infusion regimens, thus preventing an operator from entering potentially erroneous regimen data. These devices are limited to the storage of standard infusion therapies.

However, these devices do not allow you to store or retrieve data for treatments that provide a bolus or loading dose infusion. Furthermore, since these devices do not store bolus dose or loading dose therapy data in the memory of the device, they do not contemplate error control of such treatments entered by the physician.

WO 03/080157 describes an automatic control system for monitoring blood glucose levels and adapting insulin flow based on insulin demand. This demand is calculated based on blood glucose levels and clinical parameters manually entered into the system.

WO 99/10029 describes a medication infusion device. The device provides for the automatic and controlled reconstitution, dissolution and dispensing of one or more intravenous medications in a given patient. The device checks prescription medication against patient and pharmaceutical databases prior to administration.

WO 2004/012043 describes a method for storing, in a separate storage device, the protocol information for the administration of a drug by means of a peristaltic pump.

WO 96/36389 describes a medical infusion system for infusing medical fluids into a patient via a pump. The system comprises a memory that stores multiple infusion parameters, to control the operation of the pump, and a processor, which selects and retrieves the appropriate infusion parameters from those that are stored.

ES 2 328 593 T3

Accordingly, a need arises for a controller for an infusion device that provides data storage of bolus dose infusion treatments and loading in the memory of the infusion device. Such a device would allow retrieval of bolus dose and loading infusion treatment data and thus provide faster and safer bolus dose or loading dose infusion control. In addition, a need arises for a controller for an infusion device that provides data error control of physician-entered bolus and loading infusion treatments. This device would provide safer bolus or loading dose infusions compared to physician-entered data to recommend parameter limits stored in the device's memory.

Furthermore, it is normal to provide a medication to a patient in response to his or her particular physical and pathological conditions. In these circumstances, the physician is obliged to determine the appropriate infusion treatment based on the physical condition of the patient. Sometimes the time required by the physician to determine the appropriate infusion treatment can be considerable and may delay the necessary treatment for the patient. In addition, there is a risk that the doctor will not determine the appropriate drug treatment for the particular physical condition of the patient. For this other reason, it has been discovered that there is a need for a medical device that provides pre-programmed infusion treatments based on patient data and physical condition.

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

Summary of the invention

The present invention provides a controller for a programmable medical pump according to claim 1.

The application also describes a medical device for delivering to a patient at least one bolus dose drug treatment and / or a loading dose drug treatment. The medical device comprises a medication delivery device having a memory, an input device, and a processor. The memory is preloaded with drug treatments for at least one bolus dose drug treatment and / or a loading dose drug treatment. The input device of the medication delivery device receives the program parameters for a first drug treatment. Once the program parameters are received, the processor compares the received program parameters with the preloaded drug treatments.

Program parameters for a bolus dose drug treatment can comprise at least one of: medication type, medication concentration, medication amount, individual bolus volume, total bolus volume, bolus rate, timing between bolus supplies and patient weight.

Program parameters for a loading dose drug treatment can comprise at least one of: medication type, medication concentration, loading dose volume, loading dose rate, loading dose time, maintenance rate, maintenance volume, maintenance hour, diluent volume and patient weight.

Once the processor compares the received program parameters with the preloaded drug treatments, the processor can provide an alarm. The medication delivery device may have an alarm module to activate an alarm when at least one of the program parameters for the first drug treatment is outside a previously loaded drug treatment parameter limit.

The alarm can be a soft alarm or a loud alarm. When the alarm is soft, the controller allows the delivery of medications to the patient based on the received program parameters. The operator, however, has the option of modifying any of the program parameters after receiving a soft alarm. On the contrary, when the alarm is loud, at least one of the input parameters of the program normally has to be modified before allowing the delivery of the medication.

After the processor compares the received program parameters with the preloaded drug treatments, the processor may request authorization before allowing delivery of the drugs.

After the processor compares the received program parameters with the preloaded drug treatments, the processor can build at least a portion of a first drug treatment based on the received program parameters.

The input device of the medication delivery device may receive program parameters for a second drug treatment. The second drug therapy can be one of: a bolus dose drug therapy, a loading dose drug therapy, or a standard infusion therapy. Once again, the processor is arranged to compare the received program parameters for the second drug treatment with the preloaded treatments. After the processor processes the program parameters for the second drug treatment, the processor can issue an alarm, as described above, or it can build at least a part of a second drug treatment based on the program parameters. received. In addition, the processor can develop a delivery schedule to administer the first drug treatment and the second drug treatment.

ES 2 328 593 T3

The application also describes a programmable infusion pump having a memory, an input device and a processor, to deliver to a patient at least one of: a bolus dose drug treatment and a loading dose drug treatment. The infusion pump memory is preloaded with drug treatments for at least one of: a bolus dose drug treatment and a loading dose drug treatment. The input device receives program parameters for a first drug treatment for one of: a bolus dose drug treatment and a loading dose drug treatment, and the processor compares the received program parameters with the preloaded drug treatments.

Also described herein is a programmable infusion pump that has multiple pump channels, which can be programmed independently. Each pump channel can be independently programmed to deliver at least one of: a bolus dose drug therapy, a loading dose drug therapy, and a standard infusion therapy. A three channel pump is also described. The first pump channel of the infusion pump can be programmed to deliver the first drug treatment for one of: a bolus dose drug treatment, a loading dose medication regimen, and a standard infusion treatment; The second pump channel of the infusion pump can be programmed to deliver a second drug therapy for one of: the bolus dose drug therapy, the loading dose drug therapy, and the standard infusion regimen, and the third pump channel The infusion pump can be programmed to deliver a third drug treatment for one of: bolus dose drug therapy, loading dose drug therapy, and standard infusion therapy. The processor can develop a delivery schedule for each pump channel that is used.

The application also describes a system for providing bolus infusion treatment. The system comprises a controller for an infusion pump. The controller has a memory, a processor, and an input device. The controller can be a digital assistant. The memory contains preloaded bolus infusion treatments for multiple medications, the input device receives the program parameters for a first bolus infusion regimen, and the processor compares the received program parameters with the preloaded bolus infusion treatments in memory controller.

The controller may be an internal component of the infusion pump, and in another embodiment the controller is a separate and independent component of the infusion pump. Typically, in both embodiments, the controller makes a first bolus infusion treatment and transmits it to the infusion pump.

The application also describes a system for providing loading dose infusion treatment. The system comprises a controller for an infusion pump. The controller has a memory, a processor, and an input device. The controller can be a digital assistant. The memory contains the preloaded loading infusion treatments for multiple medications, the input device receives the program parameters for a first loading infusion regimen, and the processor compares the received program parameters with the preloaded loading infusion treatments in the controller memory.

The controller may be an internal component of the infusion pump, and in a second embodiment the controller is a separate and independent component of the infusion pump. Typically, in both embodiments, the controller builds a first loading dose infusion treatment and transmits it to the infusion pump.

The application also describes a method for programming an infusion therapy on an infusion pump. The method comprises the steps of providing a controller with a memory, a processor and an input device, wherein the memory is preloaded with medication therapies for at least one of a bolus dose drug treatment and a loading dose medication regimen; providing receipt of a first set of program parameters for a first drug treatment that is one of a bolus dose drug treatment and the loading dose medication regimen; provide the comparison of the program parameters received with the drug treatments preloaded in the processor and, provide the activation of an alarm when at least one of the program parameters for the first drug treatment is out of limit of the parameters of the therapeutic ranges preloaded medications. Furthermore, the method determines the override of the alarm.

The application also describes an apparatus for scheduling a drug treatment for at least one of a bolus dose drug treatment and a loading dose drug treatment. The apparatus comprises a controller having a memory, an interface, and a processor. Memory is preloaded with drug therapies of at least one bolus dose drug treatment and one loading dose drug treatment. The interface receives a selection of a first drug treatment type that includes at least one of a bolus dose drug treatment and a loading dose drug treatment, and the processor provides the specific input screens in order to program the parameters for the type. of chosen drug treatment.

The application also describes a method of programming a drug treatment in a controller for an infusion pump. The method comprises the steps of providing a controller device with a memory, a processor and an interface, where the memory is adapted for preloading with drug treatments for at least one of a bolus dose drug treatment and a dose drug treatment. load; provide the reception of a first type of drug treatment comprising at least

ES 2 328 593 T3 one of a bolus dose drug treatment and a loading dose drug treatment; and, providing the display on an input screen that allows the reception of the program parameters pertinent to the received drug treatment.

The present application also describes a method of preloading a drug treatment in an infusion pump. The method comprises the steps of providing a controller with a memory, a processor and an input device, where the memory is capable of retrievably storing one or more preloaded drug treatments for at least one of a bolus dose drug treatment. and a loading dose medication regimen; providing receipt of a set of program parameters for a drug treatment that is described as at least a bolus dose drug treatment and a loading dose medication regimen; and, providing recoverable storage of program parameters in memory.

According to one aspect of the present invention, there is provided a controller for a programmable infusion pump. The controller has a memory, an input device, and a processor. The memory is preloaded with at least one of multiple patient profiles and fitness profiles. The memory is also preloaded with a plurality of associated drug treatments for the multiple profiles. The input device receives the profile data comprising at least one of the patient's profile data and one of the fitness profile data for a given patient, and the processor processes the received profile data and outputs a drug treatment based on the processed profile data. Typically, the processor selects the drug therapy from the preloaded drug therapies corresponding to the preloaded profiles.

According to another aspect of the present invention, the memory is also preloaded with a plurality of medication profiles and with a drug treatment associated with the plurality of medication profiles. In general, preloaded medication profiles comprise data for at least one of a drug, a non-drug product, and a diluent. Furthermore, drug treatment generally comprises at least one of a dose, a rate, a concentration and a type of medication.

According to another aspect of the present invention, the preloaded patient profiles comprise data for at least one of a pain state in the patient, chronological age, age group and gestational age. In addition, the preloaded fitness profiles comprise data for at least one of medical condition and medical condition.

According to another aspect of the present invention, the drug treatment provided by the processor comprises the type of medication and the administration parameters. Administration parameters generally comprise at least one of a dose, a rate, and a concentration.

According to another aspect of the present invention, there is provided a controller for a programmable infusion pump. The controller has a medication delivery therapy for at least one of a bolus dose drug treatment and a loading dose drug treatment. 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 fitness profiles, and, for each profile, the memory is also preloaded with at least one of a bolus dose drug treatment and a loading dose drug treatment. . The input device receives the profile data comprising at least one of the patient data and the physical condition data for a given patient. The processor processes the received profile data and outputs at least one of the preloaded bolus dose drug treatments and preloaded loading dose drug treatments based on the processed profile data.

In one embodiment, the controller selects the drug treatment from the preloaded bolus drug treatments and the loading dose drug treatments corresponding to the preloaded profiles.

Also described herein is a method of programming an infusion treatment in a controller having a memory, a processor and an input device. The method comprises the steps of: providing memory preload with at least one of the multiple patient and fitness profiles, and with an associated drug treatment for each of the multiple profiles; provide the receipt of the profile data comprising at least one of the patient profile data and the fitness profile data for a given patient, and provide the processing of the received profile data and output one of the treatments preloaded medications based on processed profile data.

The application also describes a method of programming an infusion treatment on an infusion pump. The method comprises the steps of: providing receipt of a set of patient profile parameters that describe at least one type of medication, a physical condition of the patient, and a disease; providing a controller with a memory, a processor and an input device, where the memory is capable of retrievably storing one or more drug treatments for at least one of a bolus dose drug treatment and a loading dose drug treatment, where at least one of the drug treatments matches at least one set of patient profile parameters; provide comparison of parameters

ES 2 328 593 T3 with the drug treatments stored in the memory of the processor, and provide the transmission of a drug treatment that matches the patient's profile parameters.

Also described here is a method of programming a drug treatment on a controller for an infusion pump. The method comprises the steps of: providing a controller with a memory, a processor and an interface device, where the memory is adapted to be preloaded with drug treatments for at least one of a bolus dose drug treatment and a dose drug treatment load; providing receipt of a first type of drug treatment comprising at least one of a bolus dose drug treatment and a loading dose drug treatment; provide the reception of a first type of medication; and providing the display of a proposed first type of medication for the selected drug treatment type and the selected medication type.

The method may further comprise at least one of the steps of: providing receipt of program parameters relevant to the type of drug treatment received; providing the received changes in at least one program parameter of the first proposed drug treatment; provide comparison of program parameters received with preloaded drug treatments; and providing the activation of an alarm when at least one of the program parameters for the first drug treatment is outside the limit of the parameters for the preloaded drug treatment.

Also described herein is a method of programming a patient profile into memory and matching the patient profile with a recommended bolus / loading dose treatment. The method comprises the steps of: providing a controller with a memory, a processor and an input device, where the memory is capable of retrievably storing one or more sets of patient profile parameters that describe at least one type of medication, a physical condition of the patient and a disease, and where the memory is capable of storing one or more drug treatments for at least one of a bolus dose drug treatment and a loading dose medication regimen; providing receipt of a set of patient profile parameters that describe at least one of the type of medication, the patient's physical condition, and the disease; providing matching of the received set of patient profile parameters to at least one of a bolus dose drug treatment and a loading dose medication regimen; providing retrievable storage of the received patient profile parameter set in memory; and, providing retrievable storage of memory data, where the data reflects the correspondence between at least one set of patient profile parameters and at least one bolus dose drug treatment and a loading dose drug treatment.

The present application further describes a medication delivery controller for an infusion pump for the administration of at least one of a bolus dose and a loading dose. The medication delivery controller comprises a processor to interact cooperatively with a memory and an interface device. Memory is preloaded with drug treatments for at least one of a bolus dose drug treatment and a loading dose drug treatment. The interface device receives program parameters for a first drug treatment which is one of said bolus dose or loading dose drug treatments and a standard infusion treatment. The processor compares the received program parameters with the preloaded drug treatments. The medication delivery controller is a controller for an infusion pump. The infusion pump has multiple pump channels, each pump channel being independently programmable to deliver at least one of a bolus dose drug treatment, a loading dose drug treatment, and a standard infusion treatment. The program parameters are necessary for the correct administration of the first drug treatment of a drug. Program parameters for a bolus dose drug treatment include at least one of the medication type, medication concentration, medication amount, individual bolus volume, total bolus volume, rate of bolus, timing between bolus supplies and patient weight. Program parameters for a loading dose drug treatment comprise at least one of the type of medication, the concentration of the medication, the volume of the loading dose, the speed of the loading dose, the time of the loading dose. , maintenance rate, maintenance volume, maintenance time, diluent volume, and patient weight. The controller comprises an alarm module for setting an alarm when at least one of the program parameters for the first drug treatment is outside the limit of the preloaded drug treatment parameters. The alarm is a soft alarm that allows the delivery of medication to the patient based on the program parameters received for the first medication treatment. At least one of the controller and interface device comprises an interface module for receiving a soft alarm cancellation. At least one of the controller and the interface device comprises an interface module for receiving a change of at least one of the program parameters. The alarm is a strong alarm that requires a change of at least one of the program parameters for the first drug treatment. At least one of the controller and the interface device comprises an interface module for receiving a change of at least one of the program parameters. The processor and memory are structured to perform at least a part of the first drug treatment based on the received program parameters. The processor and memory are structured to develop a delivery schedule for the first drug treatment. The interface device is further provided for receiving program parameters for a second drug treatment for a drug, which is one of a bolus dose drug treatment, a loading dose drug treatment and a standard infusion treatment, and where the processor is provided to compare the received program parameters for the second drug treatment with the preloaded drug treatments. Processor

ES 2 328 593 T3 and the specification are structured to develop a delivery schedule for delivering the first and second drug treatments. The controller further comprises an alarm module for setting an alarm when at least one of the program parameters for the second drug treatment is outside the parameter limit of the preloaded drug treatment. The alarm is a soft alarm that allows the delivery of medication to the patient based on the program parameters for the second drug treatment. At least one of the controller and the interface device comprises an interface module for receiving an alarm cancellation. At least one of the controller and the interface device comprises an interface module for receiving a change of at least one of the program parameters with the interface device. The alarm is a strong alarm that requires a change of at least one of the program parameters for the second drug treatment. At least one of the controller and the interface device comprises an interface module for receiving a change of at least one of the program parameters. A first pump channel of the infusion pump can be programmed to deliver the first drug treatment for one of a bolus dose drug treatment, a loading dose drug treatment, and a standard infusion treatment.

A second pump channel of said infusion pump may be programmed to deliver a second drug treatment for one of said bolus dose, loading dose and standard infusion drug treatments. A third pump channel of the infusion pump can be programmed to deliver a third drug therapy for one of a bolus dose drug therapy, a loading dose drug therapy, and a standard infusion therapy. The processor is also planning to develop a supply schedule for the first drug treatment. The processor is further planned to develop a supply schedule for at least one of the first, second, and third drug treatments. The interface device has a receiver to receive information from an information identifier in a group of lines. The information identifier contains information that includes at least one of a patient's name, age, sex, weight, allergies, physical condition, name of medication, type of medication, concentration of medication, amount of medication, Individual bolus volume, total bolus volume, bolus rate, dose, timing between bolus deliveries, maximum number of boluses, maximum number of boluses per unit of time, loading dose volume, loading dose rate, loading dose time, maintenance rate, maintenance volume, maintenance time, maintenance dose, diluent volume, patient profile data, and fitness profile data.

A system for a bolus infusion treatment is also described here. The system comprises a controller for an infusion pump. The controller has a memory, a processor, and an input device. The memory contains preloaded bolus infusion treatments for a plurality of medications. The input device receives the program parameters for a first bolus infusion treatment and the processor compares the received program parameters with the bolus infusion treatments preloaded in the controller's memory. The controller is an internal component of the infusion pump. The controller can also be a separate and individual component of the infusion pump. The controller develops the first bolus infusion treatment and transmits it to the infusion pump. The infusion pump comprises the controller.

The present application also describes a loading dose infusion treatment system. The system comprises a controller for an infusion pump. The controller has a memory, a processor, and an input device. The memory contains preloaded loading dose infusion treatments for a plurality of medications. The input device receives the program parameters for a first loading dose infusion treatment and the processor compares the received program parameters with the loading dose infusion treatments preloaded in the controller memory.

Also described here is a drug treatment scheduling system for at least one of a bolus dose drug treatment and a loading dose drug treatment. The system comprises a controller, a memory, and an interface device. The memory is adapted to be preloaded with drug treatments for at least one of a bolus dose drug treatment and a loading dose drug treatment. The interface device is structured to receive a selection of a first type of drug treatment including at least one of a bolus dose drug treatment and a loading dose drug treatment. The interface device is structured to receive one type of medication and the processor is structured to deliver a proposed first drug treatment for the selected type of drug treatment. The interface device is structured to provide specific screens to receive the first drug treatment program parameters for the selected drug treatment type. After the initial receipt of the program parameters, the interface device is structured to receive changes to the program parameters for the first drug treatment. The controller is an integral part of a medication delivery device, the medication delivery device further comprising the memory and the interface device.

The present application also describes a method for programming a drug treatment to be used by an infusion pump controller. The method comprises the steps of providing a memory adapted to be preloaded with drug treatments for at least one of a bolus dose drug treatment and a loading dose drug treatment; receiving a first type of drug treatment that includes at least one of a bolus dose drug treatment and a loading dose drug treatment; receive a first type of medication; and propose a first drug treatment for a type of

ES 2 328 593 T3 determined drug treatment and a type of medication. The memory is preloaded with drug treatments for at least one of a bolus dose drug treatment and a loading dose medication regimen. The method further comprises the steps of receiving a first set of program parameters for the first type of drug treatment, which is one of a bolus dose drug treatment and a loading dose drug treatment; the comparison of the program parameters received with the preloaded drug treatments; and triggering an alarm when at least one of the program parameters for the first drug treatment is outside a parameter limit of the ranges of the preloaded drug treatment. The method further comprises the step of providing a controller for the infusion pump to deliver the first drug treatment from the preloaded drug treatments. The method further comprises the step of providing an input device for receiving an identifier of information from a group of infusion lines for use in scheduling the infusion treatment.

Also described herein is a group of lines to be interconnected with an infusion control system to deliver at least one of a bolus dose and a loading dose. The infusion control system comprises a processor and a memory to interact in cooperation with said processor. The specification comprises drug treatments for at least one of a bolus dose drug treatment and a loading dose drug treatment. The group of lines comprises a length of tube and a microelectromechanical system (MEMS) element connected to said tube. The infusion control system also comprises an input device for receiving the program parameters for a first drug treatment, which is one of the aforementioned bolus dose, loading dose and standard infusion drug treatments, comparing said processor the program parameters received with said drug treatments in memory. The processor and memory are housed with a controller to control the operation of said MEMS element. The controller has a screen to display information. The infusion control system further comprises a central computer and a MEMS interface device, and where said processor and said memory are located inside said central computer, and where said central computer is located remotely from said MEMS element and said MEMS interface device. The MEMS interface device comprises means for controlling and polling the MEMS element. The line group is disposable and the MEMS interface device is reusable. The infusion control system also comprises an input device with a screen to show information on the operation of said MEMS element and has a reader for receiving an identifier. The identifier may also include an identification of the MEMS element, such as a MEMS pump, for the transmission of this information by the system and for monitoring the operation and interaction of the MEMS element in relation to the system.

According to another aspect of the present invention, the application also describes a medical infusion system for the infusion of at least one of a bolus dose and a loading dose. The system consists of a disposable tube, a disposable electromechanical pump element connected to said tube, a pump interface device operatively connected to the pump element, a processor, and a memory to interact cooperatively with the processor. The specification comprises drug treatments for at least one of a bolus dose drug treatment and a loading dose drug treatment. The system further includes a disposable reservoir attached to the disposable tube. The disposable reservoir comprises a valve structured to be remotely controlled.

According to another aspect of the present invention, a method of delivering a medicament is also described herein. The method comprises the steps of providing a tube with a MEMS pump attached thereto, the MEMS pump structured to be operatively connected to a pump interface device, a processor, and a memory to interact cooperatively with said processor. The specification comprises drug treatments for at least one of a bolus dose drug treatment and a loading dose drug treatment. The pump is activated by said pump interface device, to deliver said drug in accordance with at least one of said bolus dose and loading dose drug treatments.

Other apparatus, systems, methods, features, and advantages of the present invention will become apparent to anyone skilled in the art upon examining the following figures and the detailed description.

Brief description of the figures

The invention can be better understood with reference to the following figures. The components in the figures are not necessarily to scale, however emphasis is placed on clearly showing the principles of the present invention. In the figures, the same reference numbers designate corresponding parts throughout the figures.

Figure 1: flow chart representing an embodiment of the programming system of the medical device of the present invention.

Figure 2: flow chart representing another embodiment of the programming system of the medical device of the present invention.

Figure 3: Front elevation view of a medical device and a controller used in the system of the present invention.

ES 2 328 593 T3

Figure 4: representation of a treatment selection interface screen of the system of the present invention.

Figure 5: representation of a data entry screen of the system of the present invention.

Figure 6: representation of an embodiment of an alarm screen of the system of the present invention.

Figure 7: representation of another embodiment of an alarm screen of the system of the present invention.

Figure 8: representation of an authorization screen of the system of the present invention.

Figure 9: representation of a channel selection screen of the present invention.

Figure 10: representation of a programming screen of the system of the present invention.

Figure 11: representation of an embodiment of a profile data entry screen of the present invention.

Figure 12: representation of a proposed treatment screen of the system of the present invention.

Figure 13: representation of a pre-programming screen of the system of the present invention.

Figure 14: representation of another embodiment of a pre-programming screen of the system of the present invention.

Figure 15: flow chart representing the pre-programming of a system controller of the present invention.

Figure 16: diagram of another embodiment of the present invention using a disposable pump.

Figure 17: diagram of yet another embodiment of the present invention using a disposable pump.

Detailed description of the invention

With reference to the figures, and in particular to Figures 1 and 2, two flow charts are shown that identify systems and methods for programming a medical device in order to deliver a drug treatment to a patient. The person skilled in the art will fully understand that the present system is designed to program any type of medical device to deliver a medication to a patient. For illustrative purposes only, the detailed description focuses on an infusion pump as a medical device for delivering a drug and / or a non-drug product to the patient. In addition, infusion pumps are understood to incorporate a variety of types of medical pumps, including volumetric infusion pumps, peristaltic pumps, cassette pumps, and syringe pumps, but are not limited to, and can be used in administration applications. such as intravenous, intramuscular, IA, epidural administration, irrigation of fluid spaces and other types of administration and uses.

Figure 3 illustrates one embodiment of the medical device 10 of the present invention. In general, the system of the present invention incorporates a medication delivery device 10, a controller 12 with a memory 14, a processor 16, and an interface device 19. The interface device 19 may comprise an input device 18 or a display device 17 or both. Furthermore, the components of the interface device 19 (ie, the input device 18 and the display device 17) can be separate components or integral components. As an example, the interface device 19 may be a touch screen that provides the function of a display device and an input device.

In one embodiment, the controller 12 is an internal component of the infusion pump 10. In an alternative embodiment, the controller 12a is a separate and individual component of the infusion pump 10. As an example, the controller 12a may be a controller 12a of a stand-alone personal digital assistant (PDA), also shown in Figure 3, which is used to produce a drug treatment and then to transmit signals to operate the medical device 10.

Typically, when controller 12a is a different and separate component from medical device 10, such as with a PDA, controller 12a performs all processing of the program parameters, the comparison of the program parameters with the scheduled drug treatments, the preparation of drug treatments and planning of drug treatments, and offers drug treatments in response to the input of the patient and their physical condition. As an example, to drive the medical device 10 with a separate controller 12a, the controller 12a can generate an output signal that is sent to the motor of the medical device 10. The level of the output signal, which can be a variable power signal , will determine the speed at which the motor will operate to deliver the medication to the patient.

One type of infusion pump that can be used in the present invention is that described in US Patent 5,842,841, issued in favor of Danby et al., And assigned to the holder of the present invention. As shown in Figure 3, the infusion pump 10 has a housing 20, an inlet device, and a plurality of delivery channels.

ES 2 328 593 T3 pump 22a, 22b, 22c. In the present invention, each of the pump channels can be separately programmed to deliver a variety of drug treatments to a given patient. In operation, an operator, such as a nurse or other physician, will begin the infusion of a medication by inserting tube 25 from a standard IV line 24 into a tube loading port 26, or tube channel 26, located in the front of any of the housing channels. Conduit line 24 may include one or more of the following components: IV conduit 25, slide clamp 28, connector, and container 84. The group of conduits 24 may be made up of more or fewer components. Furthermore, the operator would at the same time insert a sliding clamp 28, associated with the group of conduits 24, into a hole 29 for the sliding clamp located upstream, that is, above the fluid source, of the loading port of the tube 26 . The operator would then actuate a tube loading sequence in which a series of pawls and a movable upper jaw would serve to grab tube 25 from conduit group 24 and drag it into tube channel 26. As the loading cycle progresses , the jaws and pawls close around tube 25 capturing it within tube channel 26. Then, as the valves close to close tube 25, slide clamp 28 would move to a position where it will no longer close tube 25. Pump 10, upon receiving appropriate signals from an associated controller going To determine the pumping speed, air volume, temperature and pressure allowed, it is actuated by drawing fluid from the fluid source and expelling it according to the drug treatment. As explained in more detail here below, each of the process parameters and / or patient profiles necessary to develop a drug treatment, and possibly the entire drug treatment, can be provided to the controller via an information identifier 27 connected to the duct group 24. Information identifier 27 can be found on, but not limited to, any component of conduit group 24, including conduit 25, container 84, and slide 28.

As already explained above, the system 30 of the present invention is used to program a medical treatment in a medical device 10. The system 30 of the present invention can be implemented in software (for example, firmware), hardware or a combination of both of them. In the currently contemplated best embodiment, system 30 has a medical device drive system that is implemented in software, such as an executable program. The medical device drive system can be found on or have parts found on any computer, a server, the medical device 10, or a digital assistant controller 12a.

Typically, in terms of hardware architecture, as shown in Figure 3, controller 12 is a computer that includes a processor 16, memory 14, and one or more input and / or output devices (I / O ) 18 (or peripherals) coupled in communication through a local interface. The local interface can be, for example, but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface can have more elements, which are omitted for simplicity, such as more controllers, buffers (caches), drivers, repeaters, and receivers, to allow communication. In addition, the local interface may include address, control, and / or data connections to allow proper communication between the other computer components.

Processor 16 is a hardware device for executing software, specifically software stored in memory 14. Processor 16 can be any custom or commercial processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computer, a semiconductor-based microprocessor (in the form of a microchip or set of microchips), a microprocessor or, in general, any device for executing software instructions. Examples of commercial microprocessors are: PA-RISC series microprocessor from Hewlett-Packard company, Pentium series microprocessor from Intel Corporation, PowerPC microprocessor from IBM, Sparc microprocessor from Sun Microsystems, Inc, or Motorola 68xxx series microprocessor Corporation.

Memory 14 may include any volatile memory element or a combination thereof (for example access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (for example, ROM, disk hard drive, tape, CDROM, etc.). In addition, memory 14 may incorporate electronic, magnetic, optical, and / or other storage media. Memory 14 may have a distributed architecture in which various components are remote, but accessible to processor 16.

The software in memory 14 may include one or more different programs, each of which comprises an ordered listing of executable instructions for applying logic 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 commercial operating systems is as follows: (a) Windows operating system available from Microsoft Corporation; (b) Netware operating system available from Novell, Inc; (c) Macintosh operating system available from Apple Computer, Inc .; (d) UNIX operating system that can be purchased from many vendors, for example Hewlett-Packard Company, Sun Microsystems Inc., and AT&AT Corporation; (e) LINUX operating system, in the public domain that can be purchased on the Internet; (f) Vxworks real-time operating system from WindRiver Systems, Inc; or (g) an application-based operating system, such as that implemented in laptop computers or personal digital assistants (PDAs) (eg, PalmOS available from Palm Computing, Inc., and Windows CE available from Microsoft Corporation). The operating system basically controls the execution of any other computer program and provides planning, input-output control, file and data management, memory management, and communication control and related services.

ES 2 328 593 T3

The medical device drive system can be a source program, an executable program (object code), a script or any other entity that comprises a set of instructions to be performed. When it is a source program, the program does not have to be translated by a compiler, assembler, interpreter or equivalent, which may or may not be included in memory 14, to function properly in connection with the O / S. Additionally, the medical device drive system can be written as (a) an object-oriented programming language, which has data classes and methods, or (b) a process programming language, which has routines, subroutines, and / or functions, for example, but not limited to C, C ++, Pascal, Basic, Forran, Cobol, Perl, Java, and Ada. In one embodiment, the drive system of the medical device is written in C ++. In another embodiment, Power Builder is employed. I / O devices 18 may include input devices, for example, but not limited to, a keyboard, mouse, scanner, microphone, touch screens, interfaces to various medical devices, barcode readers, pointers, readers. laser, RF device readers, etc. In addition, the I / O devices 18 may also include output devices, for example a printer, a barcode printer, monitors, etc., but are not limited thereto. Finally, the I / O devices 18 can also include devices that communicate both inputs and outputs, for example a modulator / demodulator (MODEM; to access another device, system or network), radio frequency (RF) or another transceiver, a telephone interface , a bridge, a router, etc., but not limited to them.

When the medical device actuation system is implemented in software, it should be understood that the medical device actuation system may be stored on any computer-readable medium for use with or in correspondence with any computer system or method. In the context of this document, a computer-readable medium is an electronic, optical magnetic, or other physical device or medium that may contain or store a computer program for use with or in correspondence with any computer system or method. The medical device drive system may be included in any computer-readable medium for use with or in correspondence with an instruction execution system, apparatus, or device, such as a computer-based system, a system containing a processor or other system that can obtain instructions from an instruction execution system, apparatus or device and execute them. In the context of this document, a "computer-readable medium" can be any medium that can store, communicate, propagate, or transport the program for use with or in connection with the instruction-executing system, apparatus, or device. The computer-readable medium may be, for example, but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or a propagation medium. More specific examples (non-exhaustive list) of computer-readable medium include: electrical connection (electronic) with one or more cables, laptop floppy disk (magnetic), random access memory (RAM) (electronic), read-only memory ( ROM) (electronic), programmable read-only memory (EPROM, EEPROM, or flash memory) (electronic), fiber optic (optical), and a portable read-only memory compact disc (CD ROM). It should be noted that the computer-readable medium can even be paper or any other suitable medium on which the program is printed, as the program can be captured electronically, for example by optically scanning the paper or other medium, then compiled, interpreted or processed. appropriately if necessary, and then stored in the memory of a computer.

In another embodiment, when the medical device actuation system is implemented in hardware, the medical device actuation system can be implemented with any of the following technologies or a combination thereof, well known in the state of the art: one or more discrete logic circuits that have logic gates to implement logic functions based on data signals, an application-specific integrated circuit (ASIC) that has combinational logic gates, one or more programmable gate arrays (PGA), an array of field programmable (FPGA), etc.

Returning back to FIG. 1, the flow chart shown represents 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 in step 31 of Figure 1. The start command 31 typically includes the connection of the controller 12 of each infusion pump 10 or of a separate controller 12a. Once the start command is launched, the infusion selection screen 32 appears. A representation of an infusion selection screen 32 is illustrated in Figure 4. As shown, the infusion selection screen 32 is adapted to allow the operator to select an infusion treatment. In one embodiment, the infusion treatments available to select from are a fluid bolus infusion treatment 34, typically used to schedule the delivery of bolus medication of a non-drug product, a bolus infusion treatment of a drug 36, and a treatment loading dose infusion 38. A bolus is typically defined as a relatively large volume of fluid or a dose of a drug or test substance given through an intravenous, epidural, subcutaneous, or arterial line, often rapidly, to accelerate or intensify a response. A loading dose is typically defined as a volume of fluid or dose of test drug or substance provided through an intravenous, epidural, subcutaneous, or arterial line, prior to a maintenance infusion of that same test fluid, drug, or substance. The purpose of a bolus or loading dose is to obtain a rapid serum concentration. This, however, can increase the risk of adverse effects. Therefore, means have been sought to reduce the possibility of increased risks. As already explained, this publication aims to provide, among other things, means to reduce the risk of error when providing a patient with a medication, be it a drug or a non-drug product.

In one aspect of the invention, memory 14 is preloaded with drug treatments. The type of drug treatment that is preloaded in memory 14 includes at least one of the drug treatments of

ES 2 328 593 T3 bolus doses, for both drug boluses and non-drug boluses, loading dose drug treatments and standard infusion treatments. Preloaded drug therapies can identify acceptable ratios and / or limits for each of the process or program parameters required to develop a particular therapy. This allows the hospital to set a standard loading or bolus dose for each medication, both drug and non-drug, defined in the memory library 14. This also allows the hospital to set a standard bolus dose treatment or loading dose. for various patient fitness profiles. As one skilled in the art will understand, an acceptable ratio and / or limit for a given program parameter can be adjusted based on the other program parameters. For example, if you increase the infusion time, you can increase the allowable rate / limit for the infusion dose, while if you decrease the infusion time, you can decrease the allowable rate / limit for the infusion dose. Also, you can change the allowable ratio for a given medication depending on the concentration of the medication. Many other examples are also possible.

After the operator selects the appropriate infusion treatment on the infusion selection screen 32, the system allows the operator to enter program parameters in step 40 (see FIG. 1) to deliver the medication. The program parameters vary depending on the type of infusion, the type of parameters established by the hospital or another team of caregivers, the medication, etc. In general, program parameters are the set of information and / or instructions necessary to program a medical device in accordance with an order or prescription. The various program parameters for a bolus dose drug treatment include as a minimum Medication Type, Medication Concentration, Medication Amount, Individual Bolus Volume, Total Bolus Volume, Bolus Rate, Timing between bolus supplies, the maximum number of boluses, the maximum number of boluses per unit of time, and the patient's weight. Likewise, the various program parameters for a loading dose drug treatment include at least the type of medication, the concentration of the medication, the amount of medication, the volume of the loading dose, the speed of the loading dose, time. of the loading dose, maintenance rate, maintenance volume, maintenance time, diluent volume and patient weight. Anyone skilled in the art will appreciate that other program parameters are possible for these and other infusion treatments.

In one embodiment of the present invention, after the operator has selected the type of drug treatment in step 32, the system will provide an input screen that only allows receiving program parameters concerning the type of drug treatment received. For example, if a bolus dose drug treatment is selected in step 32, the system only provides input of program parameters relating to a bolus dose drug treatment. Also, if a loading dose drug treatment is selected in step 32, the system only provides input of program parameters related to a loading dose drug treatment. A representation of a program parameter entry screen 42 for a loading dose treatment is illustrated in FIG. 5. As shown by way of example, the loading dose parameter input screen 42 requests data on loading rate 48, loading volume 50, concentration 52, maintenance rate 54, maintenance volume 56 and concentration 58.

The program parameter input screenshot 42 illustrated in FIG. 5 is an example of an interface device 19 that functions as an input device 18 and a display device 17. Program parameters can be programmed using the arrow keys. selection 44 and up / down arrows 46, and the display is provided through a video screen.

Furthermore, in one embodiment of the present invention, once the operator has selected the type of drug treatment in step 32, and the type of medication has been provided to the controller 12, the system 30 can provide the proposed drug treatment for the patient. type of therapy and type of medication selected. Thus, instead of displaying the program parameters concerning the specific type of drug treatment selected, or in conjunction with the same display, the system 30 can provide an identification of the program parameters and their values, for the parameters suitable for this type of drug treatment. As an example, if a specific narcotic drug is selected and in step 32 the operator makes a selection to deliver said narcotic via bolus treatment, the system 30 will identify the proposed drug treatment for that medication and for the type of therapy. The operator can later modify any of the parameters in step 60.

Referring back to Figure 1, in step 60, once the operator has entered or modified the program parameters in the input device 18, the processor 16 receives the parameters and compares the received program parameters with the drug treatments. preloaded. In a preferred embodiment, this may include using an algorithm in processor 16 to determine appropriate ranges for each parameter, possibly based on a pre-programmed grading matrix.

In step 62, once the processor 16 compares the received program parameters with the drug treatments preloaded in memory 14, the processor 16 determines whether the received program parameters exceed the acceptable ranges programmed in advance for each of the parameters. process or specific drug treatment program. If the received program parameters match the preloaded drug treatments, the processor 16 at that time can process, at least in part, the drug treatment based on the received process parameters.

ES 2 328 593 T3

However, if any of the program parameters for the given drug treatment exceeds the limits set in the preloaded drug treatments, the system provides a signal or warning in step 64 to advise the physician that the dose is outside the range recommended by the hospital protocol. The alarm can be provided by an alarm module 66 which is a component of the controller 12, as illustrated in the embodiment shown in figure 3. The alarm can be visual or audible, and different types of alarms can have different alerts. visible or audible. Furthermore, as shown in step 68 of the flow chart of FIG. 1, the alarm can be a loud alarm or a soft alarm. When it is not allowed to exceed the parameter limits, a loud alarm is provided to warn the operator that a program parameter is invalid and that he has to modify at least one of the program parameters. A representation of a loud alarm is shown in Figure 7. Once the operator receives a loud alarm, they have the option of modifying one or more program parameters in step 69. If the operator does not modify at least one of the program parameters to eliminate the loud alarm, the treatment request is denied in step 70. If the operator does modify at least one of the program parameters, the system returns to step 60 of Figure 1 to determine if the revised parameters are within acceptable limits already programmed.

Unlike a loud alarm, a soft alarm allows the parameter limits to be exceeded without modifying the parameter that is out of limit. The soft alert, however, provides a warning to the operator that at least one of the program parameters exceeds the limit set for the preloaded drug treatment. A screenshot for one embodiment of a soft alarm is depicted in Figure 6. Upon receipt of a soft alarm, an override is requested in step 72 of Figure 1. The operator can provide the override response at an interface module of the input device 18. As already explained, the interface module it can include a touch screen, keyboard, mouse, and so on. If the request is denied, an override is not provided for a soft alarm and the treatment request is denied in step 70. In addition, the scheduling sequence is to be determined in step 80. However, if the request is accepted, the system continues to step 74 to determine if authorization is required.

As shown in Figure 1, another means by which an operator can get to step 74 occurs when it is determined, in steps 60 and 62, that the received program parameters entered in step 40 are within the limits or proportions programmed in advance.

In step 74, the processor determines whether authorization is needed to continue. There are several processes that may need authorization. First, if a soft alarm has been canceled, authorization is required. Second, if a dual-confirmed medication is provided, such as a narcotic or blood, an authorization is required. It is understood that there are other processes that require authorization.

Consequently, if it is determined that authorization is required because a soft alarm has been canceled, even though double acknowledgments are not required, the system proceeds from step 75 to step 77. In step 77 an alarm / warning is provided that alerts the operator that needs authorization to continue. In step 79, authorization to continue is provided or not due to a parameter override. If no authorization to override the program parameter is provided in step 79, the system proceeds to step 70 and the request for program processing is denied. If authorization to override the program parameter is provided in step 79, the system continues to step 81. In step 81, the pharmacy and physician are advised that the administration parameters established for the treatment are out of bounds. of the hospital protocol io.

If it is determined in steps 74 and 75 that authorization is required because a soft alarm has been overridden or that a double acknowledgment is required, the system continues to step 76. In step 76, the system provides an alarm / warning of that two signatures / authorizations are required. Then, in step 78, the system determines whether the two authorization signatures have been provided. If the two authorization signatures have not been provided, the system continues to step 70 and the request for program treatment is denied. If, in step 78, both authorization signatures are provided, which may be a secure authorization such as entry of an authorization code, the system continues to step 81. If the administration parameters were overridden in step 72, then in step 81 the pharmacy and physician are advised that the administration parameters established for the treatment are outside the limits of the hospital protocol. If the delivery parameters have not been overridden in step 72, then neither the physician nor the pharmacy need to be contacted.

Once the corresponding authorization or authorizations have been provided in steps 78 and 79, or if authorization is not required in step 74, the system continues to step 82 of Figure 1. In step 82, the system prompts the operator to select the proper pump channel and that identifies the proper container and conduit line 24, if you have not already done so. The recognition of the group of pipes of the pumping channel can be done manually by the operator by entering information related to the container 84, the medication that is in the container 84 and the channel 22 in which the tube 25 is located, or the recognition can occur automatically. It is also understood that the recognition of the container 84 and conduit line 24 may occur much earlier in the programming sequence.

For reference, Figure 9 shows a channel selection screen of the controller 12. In the routine shown in Figure 9, the operator identifies the appropriate channel for the scheduled infusion treatment. If the recognition and / or programming of vessel, conduit or channel parameters is not to be performed manually, a means is provided to automatically provide in-use recognition / programming.

ES 2 328 593 T3 of the information identifier 27 of a component of the conduit line 24. The information identifier 27 may contain information about the patient, such as: the patient's name, age, sex, weight, allergies, physical condition, etc .; the drug connected as part of the conduit line 24 (i.e., in the container 84), such as the drug / non-drug type, name, concentration, etc., and the drug treatment that will be carried out in the conduit line, including all or any of the process parameters required for medication treatment. Such process parameters may include at least the type of medication, concentration of medication, amount of medication, individual bolus volume, total bolus volume, bolus rate, dose, timing between supplies of bolus, maximum number of boluses, maximum number of boluses per unit time, volume of loading dose, rate of loading dose, time of loading dose, maintenance rate, maintenance volume, maintenance time, maintenance dose, diluent volume, and patient weight. Finally, the information identifier 27 may include information about the profile data, which includes data from the patient profile, such as the patient's pain status, chronological age, age group, and gestational age, although it is not limited to themselves, and patient profile data such as medical condition or medical condition, including but not limited to kidney disease, congenital heart disease, and liver failure. In addition to including specific drug treatment information, the information identifier 27 may also include a generic drug treatment. For example, information identifier 27 may include process parameters and data that can be applied to various medications, a category of medications, or a category of patient and / or fitness profiles.

The manufacturer of the conduit line 24, the hospital pharmacy or any other entity may assemble the information identifier 27 to the conduit line 24. When the manufacturer assembles the information identifier 27 to the conduit line 24, typically the line Line does not yet include medication container 84. As such, conduit line 24 with information identifier 27 can be pre-made and provided with information that can be applied to a category or group of medications. This conduit line 24, with the information identifier 27, can then be attached to a container 84 containing the medications that fall within this category. On the other hand, conduit line 24 can be highly personalized and contain many of the patient-specific and / or treatment-specific process parameters outlined above. Such personalization is usually carried out by the pharmacy, where a specific prescription and treatment instructions are added to the identification identifier 27.

The data from the information identifier 27 is transferred to the controller 12 as if it were an input on a keyboard of the input device 18. In one embodiment, the slide clamp 28 has one or more read indices per machine, a code of bars and / or a radio frequency transmitter, including RFID, that communicates with controller 12 to transmit the information to controller 12. In a similar embodiment, the controller 12 may have as input device 18 a barcode reader, a radio frequency receiver, a fiber optic receiver, a laser reading receiver and / or an infrared receiver etc., for receive the information from the information identifier 27.

When the input device 18 of the controller 12 is going to receive any information via an information identifier line 27, it is understood that it may be beneficial if this information is transferred to the controller at an early stage of the programming process and, preferably, in the step 40, as seen in figures 1 and 2.

After channel 22 is selected in step 82 and container 84, including medication and conduit line 24, is identified, processor 16 of system 30 prompts the operator to develop a scheme for drug treatment in step 86. One of The elements of the required scheme serve to identify the treatment as a primary treatment or as a complementary treatment as shown in Figure 10. With a three-channel multichannel infusion pump, potential drug therapies include at least a primary drug therapy, a first add-on drug therapy, and a subsequent add-on drug therapy. In such a configuration, the primary drug treatment is given first (i.e. a first drug treatment), the first add-on drug treatment is given second (i.e. a second drug treatment), and the subsequent add-on drug treatment is given. third (that is, a third drug treatment). All therapies can consist of any standard drug therapy, bolus dose drug therapy, and / or loading dose drug therapy.

Another element of the scheme required the time and date of the supply of the treatment. Controller 12 can be programmed prior to delivery of medications and / or attachment of container 84 and conduit line 24 to medical device 10.

As an example of a multi-container 84 and multi-channel program, controller 12 can be programmed to provide a loading dose drug treatment from a primary container associated with the first pump channel 22a, and be followed by a loading dose drug treatment in a maintenance drug treatment (i.e. a supplemental medication regimen), either from a second container associated with the second pump channel of 22b, or from the same container of the first pump channel 22a. Furthermore, the supplemental drug treatment following the first two medications described above may be a bolus dose drug treatment from a third container connected to the third pump channel 22c. There are many other examples.

ES 2 328 593 T3

With the use of complementary drug treatments, the system allows the creation of a first drug therapy (that is, a primary drug treatment), a second drug therapy (that is, a complementary treatment), a third drug therapy (that is, a subsequent complementary treatment), etc. The complementary treatments are programmed following the same steps and with the same system 30, including all the alarms and cancellations mentioned above.

As an additional feature, the system can incorporate a repeat function that allows the operator the possibility of repeating any part of the program parameters, or an entire treatment, without having to re-enter the parameters.

Referring now to FIG. 2, another system 30a for programming a medical device 10 of the present invention is shown. The first step of the system programming process 30a is to start the start command on the controller (either a controller 12 connected to a medical device 10 or a standalone controller 12a), as shown in step 31 of figure 2. Once the start command is launched, the operator can select to continue to the infusion selection screen 32. As I have already explained, the infusion selection screen 32, shown in figure 4, allows the operator the possibility selecting an infusion treatment. If the operator selects an infusion treatment, the drug treatment that is delivered as a result of the system 30a, which is described in full detail below, will act in accordance with the infusion delivery parameters for this specific infusion treatment. Specifically, as an example, if the operator selects a bolus dose drug treatment in step 32, the processor 16 will process the received profile data and output one of the bolus drug treatments loaded in advance in the database of processed profile. On the other hand, the operator can skip step 32 and continue directly to steps 90 and 91 shown in Figure 11, where the operator can input the profile data into input device 18, comprising at least one of the patient profile 92, physical condition profile 94 and medication profile 96.

The profile data for patient profiles 92 may comprise at least one of the patient's pain status, chronological age, age group, and gestational age. The profile data for the fitness profiles 94 may comprise at least one of the medical condition or medical pathology, eg, kidney disease, congenital heart disease, and liver failure. Finally, the profile data for Medication Profile 96 can include any medication data (i.e. the drug, non-drug product, or diluent), including the name or type of medication to be delivered to the patient. . Each of the patient profiles 92, the fitness profile 94, and the medication profile 96 resides in memory 14. More specifically, in addition to the drug treatments that are preloaded into memory 14, as described above, memory 14 is also preloaded with patient profiles 92, fitness profiles 94, and medication profiles 96 that correspond to a specific drug treatment.

After the operator enters the profile data, which may include manipulating the drop-down selection menus of Figure 11 (i.e., input device 18), in steps 98 and 100, the profile data receives The input device 18 will be reviewed by the processor 16 and compared with the data from the preloaded profiles 92, 94, 96 to determine the appropriate drug treatment. In one embodiment, the processor 16 has an algorithm that compares the received profile data with the preloaded profiles to provide drug treatment. Finally, in step 102, processor 16 will output a drug treatment. The processor 16 normally selects the drug treatment from the preloaded drug treatments corresponding to the preloaded profiles 90-92 that further correspond to the received profile data. The drug treatment provided by the processor 16 typically comprises the type of medication and the parameters of administration. Administration parameters comprise at least one of dose, rate, and concentration. An example of exit drug therapy is depicted in Figure 12. In this example, drug therapy includes rate, volume, concentration, time, and medication name.

On the other hand, if the output is presented as a bolus drug treatment, the delivery parameters may comprise at least one of the medication type, medication concentration, medication amount, individual bolus volume, volume bolus rate, bolus rate, and timing between supplies. And, if the output is presented as a loading dose drug treatment, the administration parameters can comprise at least one of the type of medication, the medication concentration, the volume of the loading dose, the speed of the loading dose, the time of the loading dose, the maintenance volume, the maintenance time and the diluent volume.

While system 30a can provide drug treatment based on input of a single profile data, when the operator enters more than one profile data into input device 18, in steps 90, 92 shown in Figure 11, such as input data for patient profile and fitness profile, processor 16 will perform a cross-analysis to obtain or construct a proposed drug treatment based on pre-programmed drug treatments.

After the system 30a has provided a drug treatment recommended in step 102, the operator has the ability to accept or reject the drug treatment recommended in step 104. If the operator accepts drug treatment recommended in step 104, the system 30a go to step 74, identified

ES 2 328 593 T3 above, and the system continues as already mentioned. On the contrary, if the operator rejects the drug treatment recommended in step 104, then the operator has the opportunity to adjust any of the parameters of the drug treatment recommended in step 106. If the operator chooses not to adjust any of the parameters in step 106, and the operator also decides not to accept the recommended drug treatment, the system 30a continues to the end and rejects the treatment request. On the other hand, if the operator chooses to adjust any of the program parameters in step 106, the system 30a continues to step 62. As explained above, in step 62 the processor 16 will provide an analysis to determine if the program parameters are within the range of parameters programmed in advance. After step 62, system 30a continues as explained above with respect to system 30.

Referring now to the flow chart of figure 15, this represents a system 110 with which the controller 12 is programmed in advance, which is usually done before the programming of the drug treatment that is indicated in the previous systems 30 and 30a. As shown in Figure 15, the first step in programming controller 12 is to select, in step 112, whether the programming will be for a drug profile or for a drug treatment. A representation of the screen for programming a drug profile is presented in figure 13. As can be seen, the programmer enters various program parameters, at least some of them comprising the name of the drug 126, the infusion volume for the treatment 128, diluent volume for treatment 130, concentration 132, dose 134 and rate 136. Other program parameters are possible, as is apparent to one of ordinary skill in the art.

The other mode of programming is for a drug treatment. There are at least two types of drug therapy groups: patient profiles, shown in step 122 of figure 15, and fitness profiles, shown in step 120 of figure 15. In addition, the The programmer can enter medication parameters in step 124. Figure 14 depicts a sample screen for pre-programming a patient profile for a particular pre-programmed drug treatment. On this screen, the programmer will enter at least one of the patient's physical condition 138 and the specific medical condition 140. For the specific profile parameters noted in the programming step above, the programmer will enter the program parameters for the drug treatment. As shown in Figure 14, among the various program parameters are at least drug 142, treatment volume 144, concentration 146, and rate 150.

When the programmer finishes programming a drug treatment or treatment profile, the programmer will be asked to confirm the program or to reprogram in step 116. If the programmer confirms the program, the 110 system continues to store the program in memory at step 118. On the other hand, if the programmer decides to reprogram, the system 110 returns to the start programming command at step 111.

It will be understood that the memory 14 of the present invention can retrievably store one or more drug treatments for at least one bolus dose drug treatment and one loading dose drug treatment. At least one of the stored drug treatments matches at least one set of patient profile parameters. The processor 16 provides the comparison of the patient's profile parameters with the drug treatments stored in the memory 14 of the processor 16. The processor 16 further provides the transmission of a drug treatment that matches the patient's profile parameters.

Figures 16 and 17 show other embodiments of a system of the present invention, designated by reference numerals 200 and 300. Similar to the embodiments described above in at least Figure 3, systems 200, 300 may use a line of disposable tubes 214, 314. The tube line 214, 314 may have attached a disposable element 212, 312, such as a disposable pump 212, 312. The tubing line and / or the disposable pump can have an identifier 218, 318. In other words, the systems 200, 300 use a disposable element 212, 312 and an identifier 218, 318. The disposable pump can be a micropump or a MEMS pump (microelectromechanical system) or other type of disposable pump. As indicated in Figures 16 and 17, systems 200, 300 generally include a medical pump 212, 312, preferably a MEMS pump, a delivery line 214, 314, and a container 216, 316.

MEMS refers to a microelectromechanical system (MEMS) component. MEMS is a technology used to create tiny or tiny devices that can measure less than a millimeter, although they can also be larger. MEMS devices are typically made from thin sheets of glass or silicon, but the technology has advanced far beyond the origins of the semiconductor industry. Each MEMS device is a micro-system on a chip that can incorporate moving mechanical parts as well as optical, fluidic, electrical, chemical and biomedical elements. The resulting MEMS devices or elements are sensitive to many types of inputs, including pressure, vibration, chemistry, light, and acceleration. MEMS components can consist of several different elements, including various types of pumps, a flow valve, a flow sensor, lines, a pressure sensor, or combinations thereof. These MEMS devices are smaller than conventional machines used for sensing, communication, and actuation. As a result, it is possible to use them in places where mechanical devices could not be used traditionally. MEMS devices also operate at higher speeds and consume less power than conventional devices. Furthermore, MEMS technology has advanced to the stage where MEMS devices can be manufactured at a viable cost to be considered disposable or single use devices. The devices

ES 2 328 593 T3

MEMS are normally etched onto silicon. It is further understood that MEMS can also describe other types of microelectromechanical system devices, such as those that are micromolded into plastic. Thus, MEMS devices may include silicon-etched, plastic-molded, or other small-scale fabricated devices. It should be understood that the MEMS element or pump can have different shapes. For example, the MEMS element or pump can be a disposable element, such as a peristaltic pump, a volumetric pump, an ambulatory pump, a syringe pump, or another type of disposable pump. The MEMS element can also be a pump or micromolded element, or another type manufactured on a small scale. The MEMS element can also be a pump or piezoelectrically actuated plastic element. In some embodiments, a flow sensor may be embedded in a cavity in the path of the same disposable pump. It is also understood that the MEMS devices of the present applied for invention can be manufactured using application-specific integrated circuit (ASIC) technology, where electronics are etched onto the same chip as a MEMS fluid structure.

The disposable element could be considered the MEMS pump 212 or the conduit line 214, or the combination of both elements. In addition, other types of MEMS components can also be used in system 200. Container 216, 316 is similar to container 84 that is described above in at least Figure 3. In a preferred embodiment, container 216, 316 is a flexible bag adapted to contain a medication or medicament, such as a medical fluid. Administration conduit line 214, 314 is similar to tube line 25 described above. The conduit line 214, 314 includes a tube having one end connected to or in communication with the container 216, 316 and the other end having a catheter or other device for communicating with the patient.

As also indicated in Figures 16 and 17, MEMS pump 212, 312 is operatively associated with conduit line 214, 314. MEMS pump 212, 312 can be connected to conduit line 214, 314 in different ways. configurations. For example, MEMS pump 212, 312 may have an inlet port 220, 320 and an outlet port 222, 322, with MEMS pump 212, 312 being connected to an intermediate portion of conduit line 214, 314. Consequently, a part of the conduit line 214, 314 is connected to the inlet port 220, 320 and another part of the conduit line 214, 314 is connected to the outlet port 222, 322, the MEMS pump 212 being connected, 312 operatively to conduit line 214, 314. Once properly connected, MEMS pump 212, 312 can pump fluid from canister 216, 316, through conduit line 214, 314, to the patient.

The system 200, 300 may also use an identifier 218, 318. In a preferred embodiment, the identifier 218, 318 is associated or connected to the MEMS pump 214, 314. It is understood, however, that the identifier 218, 318 can also associate with other elements, connect in other places, such as disposable conduit line 214, 314, as shown in Figures 16 and 17.

Referring to FIG. 16, the system 200 may further utilize a controller 230. The controller 230 may be operatively associated with the MEMS pump 212 or another type of MEMS or disposable pump. Controller 230 can communicate with MEMS pump 212 through a wireless connection. Alternatively, a hard connection can be used in which MEMS pump 212 can be connected to controller 230. It is further understood that the controller 230 may be an integral part of the MEMS pump 212. It is also understood that the controller 230 may be a standalone laptop or a standalone network controller, which controls the pump 212 through a communication link of network, as explained below. As already mentioned, the controller 230 has a recognition system 232. The recognition system 232 is capable of recognizing 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 that identifies the type of conduit line 214 connected to MEMS pump 212.

In the embodiment shown in Figure 16, similar to other embodiments already described, the controller 230 has a memory 260 and a microprocessor, a microcontroller, or a processor 280. The nursing facility or hospital can preload the memory. 260 with a plurality of patient profiles and patient fitness profiles. Memory 260 may also have a drug treatment preloaded for each of the multiple profiles. An input screen (not shown) of the controller can be used to receive profile data, for example patient profile data and / or fitness profile data, for a specific patient being targeted. to provide an infusion. Processor 280 compares the profile data received through the input screen with the profiles loaded in advance, in order to determine if there is a match between the two. For example, the algorithm used to determine whether there is a match could include determining whether there is exact match, whether the profile is within a group, whether the profile is within a range, and / or whether the profile is above or below a predetermined value. If there is a match, processor 280 then provides at least one of the preloaded drug treatments from memory 260 for use in operating pump 212 using the corresponding preloaded treatment. The operating parameters associated with the corresponding treatment are used for the application and control of the infusion. The treatment and the corresponding parameters can also be selected in the manner described in previous embodiments.

As in previous embodiments, the controller 230 has a processor 280. As mentioned above, the controller 230 can communicate with the MEMS pump 212 and control the operation of the MEMS pump 212 via wireless communication or via wired communication. Controller 230 can also 17

ES 2 328 593 T3 to receive operational status information from MEMS pump 212. As in previous embodiments, controller 212 also communicates with and controls the operation of a plurality of "channels" (not shown). For example, a controller 230 may communicate with and control the operation of a plurality of MEMS pumps 212 simultaneously, or in succession, depending on the treatment that is provided to the patient.

The embodiment shown in FIG. 16 may further 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 can communicate bi-directionally with the central computer 290. The central computer 290 and the user interface device 240 can comprise various functions and structures.

The user interface device or input device 240 can also be used to receive the profile data, as it can be done through the controller input screen (provided one is provided). For example, patient profile data and / or fitness profile data for a specific patient to be infused can be entered through a screen of user interface device 240. This profile data for a certain patient can be entered in the same way as in the previous embodiments. This profile data for a particular patient can then be transmitted to the central computer 290 and also transmitted to the controller 230 to be used when providing the infusion, as already explained. As part of this process, processor 280 compares profile data received through user interface device 240 with profiles preloaded into memory 260 to determine if there is a match.

As mentioned, the recognition system 232 of the controller 230 can recognize the identifier 218 of the conduit line 214 and / or the MEMS pump 212. The user interface device 240 can also have a recognition system or reader 232 , such as a barcode reader, to perform identical and / or related functions to the recognition system 232 of the controller 230. Controller 230 may also have a controller identifier 248 specific to that particular controller 230, such that reader 232 of user interface device 240 can be used to read controller identifier 248 and the MEMS or line identifier. of conduits 218, and create an association between these devices and / or an operator (not shown, although it is usually the person who has accessed the user interface device 240), as shown and described in detail in the applications that are incorporated herein by reference.

Information regarding status, alarms, alerts, messages and / or other information related to the operation of the MEMS 212 pump and / or the administration of medications to a patient can be transmitted through the pump, received and / or generated by the controller 230 to remote central computer 290 via a communication network, such as a wireless communication network, as described in the aforementioned applications. This status and other information can be received by the interface device 240 and viewed and / or activated through the interface device 240 at a location near or far from the controller 230, through a communications network, such as a wireless communications network, as explained in detail in the applications incorporated herein by reference. Similarly, the central computer 290 can be divided into a first central computer and a second central computer, depending on the separation of functionality, data separation or other type of separation, as explained in the applications that have been incorporated. .

A new embodiment of the present invention is shown in Figure 17. Specifically, instead of using a controller with a memory and a processor, the system 300 comprises a MEMS communication interface device 340, a memory 360, and a processor 380 located in a remote device from the MEMS interface device 340. In the embodiment shown, memory 360 and processor 380 are located on a central computer 390 separate from the MEMS interface device 340 but in communication with it over a communication network such as a wireless communication network. The MEMS interface device 340 can be operatively associated with the MEMS pump 312 or with another type of disposable or MEMS pump. MEMS interface device 340 can communicate with MEMS pump 312 through a wireless connection. On the other hand, a hard connection can be used in which MEMS pump 312 can be connected to MEMS interface device 340. It is further understood that MEMS interface device 340 can be an integral part of MEMS pump 312. It is also understood that the MEMS interface device 340, which operates in conjunction with the memory 360 and the processor 380, can perform the same functions as the pump controller of the previous embodiments.

In the embodiment of Figure 17, the MEMS interface device 340 has a recognition system 348. The recognition system 348 can recognize the data contained in the identifier 318. The recognition system 348 can cooperate with the identifier 318 to make system 300 will operate. For example, identifier 318 may contain information identifying the type of conduit line 314 connected to MEMS pump 312.

In the embodiment shown in Figure 17, similar to other embodiments described above, the system 300 has memory 360 and a microprocessor, microcontroller, or processor 380. The nursing facility or hospital can preload memory 360 with a plurality of patient profiles and patient physical condition profiles. Memory 360 may also have a drug treatment preloaded for each of the multiple profiles. An input screen (not shown) connected to central computer 390 or MEMS interface device 340 can be used for receiving profile data, for example data on the patient's profile and / or data on the physical condition profile. , for a specific patient to be infused. The processor 380 compares the profile data received through the input screen with the profiles loaded from

ES 2 328 593 T3 in advance in order to determine if there is a correspondence between the two. For example, the algorithm used to determine whether there is a match could include determining whether there is exact match, whether the profile is within a group, whether the profile is within a range, and / or whether the profile is above or below a predetermined value. If there is a match, processor 380 then provides at least one of the preloaded drug treatments from memory 360 for use in operating pump 312 using the corresponding preloaded treatment. The operating parameters associated with the corresponding treatment are used for the application and control of the infusion. The treatment and the corresponding parameters can also be selected in the manner described in previous embodiments.

As already mentioned, MEMS interface device 340 can communicate with MEMS pump 312 and control the operation of MEMS pump 312, along with memory 360 and processor 380, via wireless or wired communication. Interface device 340 may also receive status information during MEMS pump 312 operation. As in previous embodiments, interface device 340 also communicates with and controls the operation of a plurality of "channels" (not shown). For example, an interface device 340 may communicate with and control the operation of a plurality of MEMS pumps 312 simultaneously, or in succession, depending on the treatment that is provided to the patient.

As mentioned, the embodiment shown in Figure 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). User interface device 330 can communicate bi-directionally with central computer 390. In addition to the structure and functions discussed herein, the MEMS interface device 340, memory 360, and processor 380 may together comprise the structure and functions of the controller in the various embodiments described above.

The user interface device or input device 330 can also be used to receive the profile data, as it can be done through the input screen that is connected to the central computer 390 or MEMS interface device 340 (if it is available). For example, patient profile data and / or fitness profile data for a specific patient to be infused can be entered through a screen of user interface device 330. This profile data for a certain patient can be entered in the same way as in the previous embodiments. This profile data for a particular patient can then be transmitted to the central computer 390 and also to the MEMS interface device 340 for use when delivering the infusion, as already explained. As part of this process, processor 380 compares profile data received through user interface device 330 with profiles preloaded into memory 360 to determine if there is a match.

As already mentioned, the recognition system 348 of the MEMS interface device 340 can recognize the identifier 318 of the conduit line 314 and / or the MEMS pump 312. The user interface device or input device 330 can also have a recognition system 332 or reader, such as a barcode reader, to perform identical and / or related functions to the recognition system 348 of the MEMS interface device 340. The MEMS interface device 340 may also have a MEMS interface identifier 348 specific to that particular MEMS interface device 340, such that the reader 332 of the user interface device 330 can be used to read the MEMS interface identifier 348. and the identifier of the conduit set or MEMS 318, and create an association between these devices and / or an operator (not shown, although it is usually the person who has accessed the user interface device 340), as shown and described in detail in the applications incorporated herein by reference. The system can be structured to use one and / or two two-dimensional barcodes, when barcodes are used.

Information regarding status, alarms, alerts, messages and / or other information regarding the operation of the MEMS 312 pump and / or the distribution of medication to a patient through the pump, received and / or generated by the interface device MEMS 340 can be transmitted to central computer 390, remotely, over a communication network, such as a wireless communication network, as described in the aforementioned applications. This status and other information can be received by the user interface device 330 and viewed and / or activated through the user interface device 330 at a location near or far from the MEMS interface device 340, through a communication network, such as a wireless communication network, as explained in detail in the applications incorporated herein by reference. Similarly, the central computer 390 can be divided into a first central computer and a second central computer, depending on the separation of functionality, data separation or other type of separation, as explained in the incorporated applications. As already noted, it should be understood that the disposable item, such as the MEMS pump 312, can be activated and controlled by the central computer 390.

The systems 200, 300 of Figures 16 and 17 further include a programming device for programming the memory 260, 360 of the systems in order to preload information on patient profiles and physical condition profiles and associated drug treatments, and, hence, parameters. In the system 200 of FIG. 16, this programming device can be part of the controller 230, part of the central computer 290 and / or part of the user interface device 240. Once programmed by the programming device, the MEMS pump 212 , 312 can be activated by controller 230 or MEMS interface device 340. Once activated, controller 230 or MEMS interface device 340 controls MEMS pump 212, 312, with pump 212, 312 operating to deliver medication to a patient. Pump 212, 312 has the ability to recognize a circumstance

ES 2 328 593 T3 determined, such as when fluid is generally and substantially pumped from container 216, 316 to decide whether the container is empty. For example, a certain pressure sensed by MEMS pump 212, 312, once reached, can cause MEMS pump 212, 312 to turn off. After the MEMS pump 212, 312 is turned off, this state may trigger alarms, alerts, or other messages that would be sent to the central computer 290, 390 for further notification to the user interface device 240. In one embodiment, the memory 260, 360 and / or identifiers 218, 248, 318, 348 may include embedded or non-embedded electrically alterable non-volatile memory, made by VIRAGE LOGIC under the name of NOVEA and is shown and described at http://www.viragelogic.com / products.

Other features can be used with any of the embodiments described above. As already mentioned, a kit can be created that includes the container 216, 316, the conduit line 214, 314 and the identifier 218, 318. The identifier 218, 318 can be associated or connected to any of the containers 216, 318 and to the conduit line 214, 314. In some embodiments, container 216, 316 may contain a reconstitution device previously attached to a previously attached drug container, such as a vial. The reconstitution device can be activated to reconstitute the drug with the fluid 217, 317 from the container 216, 316. It is understood that the identifier 218, 318 may also include information about the vial that can be pre-attached to the reconstitution device. In another embodiment, a disposable pump, such as a micropump or MEMS pump, can also be connected to conduit line 214, 314 and considered as part of the kit. The identifier 218, 318 associated with this type of kit can have any of the information described above for the good general functioning of the system. In yet another embodiment, the container 216, 316 or the container associated with the kit may include a premixed drug 217, 317.

In another embodiment involving Figures 16 and / or 17, as already indicated, the identifier 218, 318 can be specifically programmed to include the profile data of a particular patient, in addition to other information such as patient identification. to which the conduit line and / or drug identification 217, 317 is intended, within the container 216, 316. The reader 232 of the controller 230, the reader of the user interface device 240, 330, or a reader (not shown) of the MEMS interface device 340 can be used to automatically read the profile data and / or other information from the identifier 218. , 318, and use this information to program and control the operation of the MEMS 212 pump, 312 according to the preloaded drug therapy for the preloaded patient profiles and fitness profiles. Through at least the controller 230, the user interface 240, 330 and / or the central computer 290, 390, the user can accept, reject or modify the drug treatment suggested by the system 200, 300 as a result of the profile data that They are read from the identifier 218,318.

It should be understood that the pump used in the systems described herein may incorporate safety software. Safety software can generate basic failure alarms, with the pump assuming a failsafe condition, such as non-free flow of drugs through the pump. Various software / pump configurations can be used. For example, all software can be located on the pump head or outside or away from the pump. Additionally, all software can be located outside the pump head except for specific safety software located on the pump head. In particular and preferably, the controller 230 may include security software to generate fault alarms when the other functions of the controller are inoperative or in a dangerous condition. In such a case, controller 230 assumes a failsafe condition preventing free flow of medication through the pump controlled by controller 230 and providing a basic level of alarms / alerts. On the other hand or in addition to the above, the security software may reside in the central computer 290, 390 to also provide this functionality, for example when the control of the pump, such as a MEMS pump 212, 312, is being carried out. carried out directly from the central computer 290, 390. On the other hand or in addition, the security software may reside in the MEMS pump or element 8612 to also provide this functionality, for example when imparting at least a minimum level of control to the pump or to the MEMS element 212, 312. These security software embodiments can be applied at least in the embodiments shown in Figures 87 and 88 below in a similar manner, located for example on interface device 240,330, host computer 290, 390, and / or element MEMS 212, 312.