An external infusion pump is a medical device used to deliver fluids into a patient’s body in a controlled manner. There are many different types of infusion pumps, which are used for a variety of purposes and in a variety of environments.

Infusion pumps may be capable of delivering fluids in large or small amounts, and may be used to deliver nutrients or medications – such as insulin or other hormones, antibiotics, chemotherapy drugs, and pain relievers.

Some infusion pumps are designed mainly for stationary use at a patient’s bedside. Others, called ambulatory infusion pumps, are designed to be portable or wearable.

A number of commonly used infusion pumps are designed for specialized purposes. These include:

• Enteral pump - A pump used to deliver liquid nutrients and medications to a patient’s digestive tract.
• Patient-controlled analgesia (PCA) pump - A pump used to deliver pain medication, which is equipped with a feature that allows patients to self-administer a controlled amount of medication, as needed.
• Insulin pump - A pump typically used to deliver insulin to patients with diabetes. Insulin pumps are frequently used in the home.

Infusion pumps may be powered electrically or mechanically. Different pumps operate in different ways. For example:

• In a syringe pump, fluid is held in the reservoir of a syringe, and a moveable piston controls fluid delivery.
• In an elastomeric pump, fluid is held in a stretchable balloon reservoir, and pressure from the elastic walls of the balloon drives fluid delivery.
• In a peristaltic pump, a set of rollers pinches down on a length of flexible tubing, pushing fluid forward.
• In a multi-channel pump, fluids can be delivered from multiple reservoirs at multiple rates.
• A "smart pump" is equipped with safety features, such as user-alerts that activate when there is a risk of an adverse drug interaction, or when the user sets the pump's parameters outside of specified safety limits.

Software problems:

• A software error message is displayed, stating that the pump is inoperable. This occurs in the absence of an identifiable problem.
• The infusion pump interprets a single keystroke as multiple keystrokes (a problem called a “key bounce”). For example, the user programs an infusion rate of 10 mL/hour, but the device registers an infusion rate of 100 mL/hour.

Alarm errors:

• The infusion pump fails to generate an audible alarm for a critical problem, such as an occlusion (e.g., clamped tubing) or the presence of air in the infusion tubing.
• The infusion pump generates an occlusion alarm in the absence of an occlusion.

Inadequate user interface design ("human factors" issues ):

• The design of the infusion pump screen confuses the user, or the infusion pump does not respond as it should (i.e., with a warning or alarm) when inappropriate data is entered.
• The infusion pump screen doesn’t make clear which units of measurement the user is expected to enter. For example, the user may enter weight in pounds when the infusion pump requires it in kilograms.
• Pump labels or components become damaged under routine use. For example, cleaning the pump, as the user-maintainer believes is acceptable practice, may damage the pump, making it unreliable for clinical use. Users with long fingernails may damage the print on the pump keys, making them unreadable.
• User instructions or cues for mechanical set-up are not specific or clear enough. For example, an instruction to attach a tubing set in all required tube holder-clips before closing the pump’s access door may be unclear, resulting in clamped tubing and under-infusion.
• Inadequately designed alarm functions and settings cause users to miss problems or respond late. For example, an alarm indicating low battery charge may not be displayed in time for a user to prevent pump shut-off during a critical infusion while a patient is in transport. False (“nuisance”) alarms may decrease users’ sensitivity to all alarms.
• The infusion pump screen design is clunky or confusing to users, causing a delay in therapy. For example, the “Start Infusion” key may be located next to the “Power” key, and a user may turn off the infusion pump instead of initiating infusion. In some cases, programmed settings are lost when a user turns the pump off, and the infusion settings have to be re-entered after the pump restarts.
• Warnings are displayed so often that users come to ignore them (similar to “nuisance alarms”), are not detailed enough to prevent misuse, or represent values in ways that are unfamiliar to the user.
• Warning messages are unclear. In the example below, it is unclear if the user is confirming the warning message or the infusion settings.

• User manuals are confusing, inadequate, outdated, or unavailable. This is particularly of concern for home-based users.
• When communicating the critical aspects of the pump’s operational, default, or “piggyback” status, the system does not use user-friendly language or does not give enough information to guide users through appropriate actions.

Broken components:

Graphic: Cracks between operating buttons allow water inside.

• The infusion pump may have been dropped or damaged during use, which may result in an over-infusion or an under-infusion if the pump continues to be used without being repaired.
• The plastic casing of an insulin pump, although promoted as waterproof, is prone to cracking, allowing water to enter the case and to cause the pump to malfunction. See Graphic on right.
• Slight misalignment of tubing places stress on the pump door, resulting in eventual cracking of pump case. See the photos below.

Figure 1. Proper positioning of tubing set

Figure 2. Close-up photo showing tubing set out of alignment. The bump in the door will catch on the lower flange of the tubing set instead of fitting between the lower and upper flanges as intended.

Figure 3. Photo of a cracked door hinge resulting from stress caused by misaligned tubing.

Photo: Sealed lead-acid battery damage caused by overcharging.

Battery failures:

• A design issue causes over-heating of the battery and leads to premature battery failure. See photo on right.
• A patient returns from ambulating and forgets to plug in the infusion pump. The infusion pump alarms with a low battery message, but the speaker volume is set too low, and the alarm goes unnoticed. The infusion pump powers off after the battery is depleted.
• The battery is not replaced during the recommended end of life routine maintenance.

Fire, sparks, charring, or shocks:

• The user plugs in or unplugs the device from an electrical outlet and receives a shock, and/or sparks are seen.
• A burning smell or flames are noted on the infusion pump. See the photo below.

Photo: The photomicrograph on the right shows charring and melting of failed connectors after a fire that occurred when pump modules were attached to a running unit.

Software Safety

Many infusion pumps are controlled by software that governs key aspects of the user interface, controls the pumping mechanism to maintain the prescribed infusion rate, and performs key safety functions. The purpose of software is to make the device safer and easier to use. Users often do not realize the extent to which software determines many of the key functional and performance characteristics of the system until something goes wrong.

Unfortunately, in some cases, the software does “go wrong” and compromises patient safety. Because software is inevitably complex, abstract, and intangible, design errors can be difficult to detect. However the means to develop trusted software are well-known and readily available. Users and patients should expect infusion pump software to be free from errors. The occurrence of a software error should be a highly unusual event.

Historically, software safety has been focused on the software development process and system-level testing. Not coincidentally, the FDA has focused its regulatory oversight on these two elements as well. Having skilled engineers and a rigorous software development process, as required by FDA’s Quality System Regulation, is important to help minimize errors. However, assessing the software development process provides only indirect insight into the "goodness" of the resulting software. System-level testing that would comprehensively test software is currently beyond the state of the art for all but the simplest of systems. Moreover, it is very difficult to actually test the software under real-world conditions until it has been married with the hardware in a finished prototype, and that typically doesn't happen until late in the product development cycle. Thus, in recent years, the focus of the software engineering community has shifted from the traditional "design-test-fix" approach to a model-based approach.

Model-Based Design of Infusion Pumps

The FDA has recognized that if product developers had tools that enable them to examine and evaluate software earlier in the development cycle, then there would be a greater likelihood that the resulting software would be more robust. Just as architects now have 3D modeling tools that allow them to take their clients on virtual tours of a new building before ground has been broken, the software engineering community has been developing tools for modeling software and its interactions with the system it controls. The safety properties of the model can be systematically examined, and once the model has been verified, the software derived from it can be proven to conform to the model. The result is software designs that are far more robust than those developed using traditional methods.

Over a period of years, the Laboratory of Software Engineering at FDA (within the Center for Devices and Radiological Health) has been working with academic collaborators under the NSF/FDA Scholar-in-Residence program to develop and refine model-based engineering methods and associated verification techniques. Characteristically, these methods have been applied first in the aerospace and automotive industries, where the cost of failure is enormous in both social and economic terms and the incentive to make the necessary investment is correspondingly high. Years of research have finally been commercialized, yielding static analysis tools that are now readily available and being increasingly employed by medical device manufacturers.

Generic Infusion Pump Project

One of our ongoing research projects related to model-based software development is the Generic Infusion Pump Project. The goal of this project is to develop a set of infusion pump safety models and reference specifications that can be used / adapted by manufacturers to verify safety properties of their own infusion pumps. Our collaborators include researchers at the University of Pennsylvania in Philadelphia and the Fraunhofer Center for Experimental Software Engineering in College Park, MD.

The Generic Infusion Pump project team has a website that provides a sample hazard analysis and reference safety specifications for a generic patient-controlled analgesic infusion pump. This kind of device, often known as a "pain pump," is used to infuse medication to relieve chronic pain. Interested parties, including researchers and medical device software developers, are invited to participate with FDA in this research by refining and extending the models and specifications that have been developed. For details, please see the project website.

Static Analysis

Software code is the name given by software engineers to the actual instructions — written in a programming language — that constitute a computer program. In modern infusion pumps, the software may contain more than 100,000 lines of code. Traditionally, three verification methods are used to determine whether the code is “correct”:

• manual code reviews, where one team of engineers systematically reviews the software developed by a different team.
• exhaustive testing of the system in which the software is used.
• simulating the execution of the software on a computer.

A fourth and relative new technique for verifying the “correctness” of the software is “static code analysis” — or “static analysis”. Static analysis is the name for a family of analytical techniques for finding bugs in software code and/or proving properties of the code related to its safety or correctness. Unlike traditional methods which run the software in a real or simulated environment to see how it performs, static analysis uses a computer to examine the source code looking for patterns that are indicative of potential design errors. Conceptually, this is exactly what human reviewers do when performing a code review, but static analysis examines the code exhaustively for certain kinds of insidious errors that are hard for human reviewers to detect.

For example, when a software program runs, it stores instructions and data values in the computer’s memory. Other parts of the software can then access this information and process it accordingly. When storing such information, the software must first request permission to access a specific amount of storage space from the operating system. Once the operating system specifies which part of memory to use, the software can place the information in the designated memory space.

Sometimes, due to a programming error, the software may inadvertently write beyond the allocated space it has been granted. In such a case, a portion of the instructions or data that were supposed to be stored is lost. Moreover, in some cases, the flawed software may overwrite data in an adjacent block of memory that was intended to be accessed by another part of the software. This problem, usually referred to as a “buffer overflow,” can result in device malfunction.

Buffer overflow is but one of many problems that can lurk in a body of software code. Static analysis is very effective in detecting a variety of different kinds of insidious software errors like buffer overflow. Since static analysis tools have to methodically trace all possible execution paths through the software, the analysis is very laborious. Until recently, these techniques were exclusively the province of the world's fastest supercomputers, but today's desktop machines have surpassed the performance of the supercomputers of a few years ago. As a result, static analysis tools have been made available commercially from a number of vendors, and as with model-based development techniques, are being increasingly embraced by medical device manufacturers.

It is unlikely that your infusion pump will malfunction. However, sometimes there can be problems with infusion pumps for a variety of reasons. The following are actions you can take to help avoid potential malfunctions, including strategies to plan ahead in the event of an infusion pump malfunction.

Reduce Risks

Plan Ahead

• Work with your home health nurse to develop a back-up plan in case of an infusion pump failure.
• Know if your plan includes calling 911.
• Know where your infusion pump back-up battery is located and how to access an emergency power supply, if applicable.
• Refer to Home Healthcare Medical Devices: Infusion Therapy - Getting the Most Out of Your Pumpfor more information.
• Learn about your infusion pump and medication. Ask your home health care provider:
  • About the infusion pump
    • What is the name of my infusion pump?
    • Is this infusion pump already set up?
    • Do I need to look at anything on the infusion pump to make sure it is correct? If so, what?
    • How do I start and stop the infusion pump?
    • Do I need training to use this infusion pump?
    • Will any electrical items in my home interfere with my pump?
  • About your medication
    • What is the name of my medication?
    • What does the medication do? How should it make me feel?
    • What are the side effects?
    • What is the dose of my medication?
    • How long should my medication take to complete?
    • Can there be medication left in my tubing or in my bag when the infusion pump stops?
  • What to do when there are problems
    • What should I look for if I'm getting too much medication too fast?
    • What should I look for if I'm getting too little medication?
    • Who should I call with questions or problems?
    • What should I do if the power goes out?

Check

• Make sure you can read the infusion pump's displays and hear the alarms, if applicable.
• Verify the settings when starting or changing the rate of a medication or fluid, if applicable. If they are not correct, or if you have questions, call your home health provider.

Report Problems

• Call your home healthcare provider to obtain further instructions if:
  • The infusion pump appears broken or damaged or has small chips or cracks.
  • An unfamiliar alarm sounds or is displayed.
  • An alarm is unable to be cleared that you have been trained to respond to.
• You are also encouraged to file a voluntary report with the FDA for any problems you may encounter with the infusion pump.

ADVERSE EVENT
An adverse event is any undesirable experience associated with the use of a medical product in a patient. The event is serious and should be reported when the patient outcome is:

• Death - Report if the patient's death is suspected as being a direct outcome of the adverse event.
• Life-Threatening - Report if the patient was at substantial risk of dying at the time of the adverse event or it is suspected that the use or continued use of the product would result in the patient's death.
• Hospitalization (initial or prolonged) - Report if admission to the hospital or prolongation of a hospital stay resulted because of the adverse event.
• Disability - Report if the adverse event resulted in a significant, persistent, or permanent change, impairment, damage or disruption in the patient's body function/structure, physical activities or quality of life.
• Congenital Anomaly - Report if there are suspicions that exposure to a medical product prior to conception or during pregnancy resulted in an adverse outcome in the child.
• Requires Intervention to Prevent Permanent Impairment or Damage - Report if you suspect that the use of a medical product may have resulted in a condition which required medical or surgical intervention to preclude permanent impairment or damage to a patient.

APPROVED
When FDA review is needed prior to marketing a high-risk medical device, FDA will "approve" the device after reviewing a premarket approval (PMA) application that has been submitted to FDA.

To acquire approval of a device through a PMA application, the PMA applicant must provide reasonable assurance of the device’s safety and effectiveness.

CLEARED
When FDA review is needed prior to marketing a moderate or low risk medical device, FDA will "clear" the device after reviewing a premarket notification, otherwise known as a 510(k) (named for a section in the Food, Drug, and Cosmetic Act), that has been filed with FDA. To acquire clearance to market a device using the 510(k) pathway, the submitter of the 510(k) must show that the medical device is "substantially equivalent" to a device that is already legally marketed for the same use.

ELASTOMERIC INFUSION PUMP
An infusion pump which utilizes the energy in an elastic membrane to provide the force for fluid delivery.

ENTERAL INFUSION PUMP
An infusion pump that delivers liquid nutrients and medicines into the patient’s digestive tract.

GUIDANCE
Describes FDA’s current thinking on a regulatory issue. Guidance is not legally binding on the public or FDA.

HUMAN FACTORS
Human factors (HF) is the study of how people use technology. It involves the interaction of human abilities, expectations, and limitations, with work environments and system design.

INDEPENDENT DOUBLE-CHECK
An independent double-check involves two clinicians separately checking (alone and apart from each other, then comparing results) the infusion settings in accordance with the physician’s order.

INSULIN INFUSION PUMP
An ambulatory electromechanical pump typically used to deliver insulin to patients with diabetes. The pump is used mainly by home care patients, but may also be used in a healthcare facility.

MAUDE DATABASE
Manufacturer and User Facility Device Experience Database. MAUDE data represent reports of adverse events involving medical devices. The data consists of all voluntary reports since June 1993, user facility reports since 1991, distributor reports since 1993, and manufacturer reports since August 1996.

OVER-INFUSION
A situation in which more fluid or medication than is intended is delivered to the patient.

PATIENT-CONTROLLED ANALGESIA (PCA) INFUSION PUMP
An infusion pump intended for the delivery of analgesics (pain relievers), which is equipped with a feature that allows for additional limited delivery of medication upon patient demand.

PMA
Premarket approval (PMA) is the FDA process of scientific and regulatory review to evaluate the safety and effectiveness of Class III medical devices. Class III devices are those that support or sustain human life, that are of substantial importance in preventing impairment of human health, or that present a potential, unreasonable risk of illness or injury.

RECALL
A recall is when a product is removed from the market or a correction is made to the product because it is either defective or potentially harmful.

Sometimes a company discovers a problem and recalls a product on its own. Other times a company recalls a product after FDA raises concerns.

SMART PUMP
An infusion pump equipped with IV medication error-prevention software that alerts operators when a pump setting is programmed outside of pre-configured limits.

SYRINGE INFUSION PUMP
An external infusion pump which utilizes a piston syringe as the fluid reservoir and to control fluid delivery.

TPLC
Total Product Life Cycle (TPLC) is an integrated device review, tracking, reporting and compliance scheme employed by FDA. The TPLC approach allows FDA to integrate all regulatory activities from device inception to obsolescence.

UNDER-INFUSION
A situation in which less fluid or medication than is intended is delivered to the patient.

USE ERROR
Safe and effective use of a medical device means that users do not make errors that lead to injury and they achieve the desired medical treatment. If safe and effective use is not achieved, use error has occurred. Why and how use error occurs is a human factors concern.