Medical device engineers are great at designing innovative, life-saving gizmos. Sometimes, however, it’s hard to anticipate everything that might go wrong with a device, even something as innocuous as a tubing connector.
Years ago, tubing for gases and IV fluids shared the same plastic connector, which was designed for quick, secure installation. The connectors worked exactly as intended. But, when patients or their loved ones disconnected the lines, they would occasionally reconnect them incorrectly. Thus, an air line for an automatic blood-pressure monitor would inadvertently get connected to an IV line—with disastrous results. Today, that connector can only be used with IV lines, and different connectors have been designed for gas lines.
“Many medical devices are not as intuitive as the engineer who designed them would like to believe,” says Robert Packard, president of Medical Device Academy, a training and consulting firm in Chester, VT.
Design problems—like the potential for usage error with the tubing connector—only seem obvious after adverse events. Before then, they’re not so evident. To ensure that medical device companies cover all the bases when designing and manufacturing new products, the Food and Drug Administration requires them to follow a design controls standard (21 CFR 820.30).
The standard requires manufacturers to:
- Establish intended use and design inputs.
- Create a design plan.
- Conduct periodic design reviews.
- Confirm that the design outputs conform to the design inputs through verification testing (“did we design the device right?”) and validation testing (“did we design the right device?”).
- Document the process in a design history file (DHF).
Although the standard has been around for more than a decade, many design teams still struggle to understand its requirements.
“A lot of companies don’t start out with a set of product requirements and do a top-down design the way the FDA expects,” points out Roy Hovland, principal engineer and co-founder of Toltec International Inc., a consulting firm in Lakewood, CO. “They may not perform an adequate risk analysis. Or, they may not do their validation correctly.”
Many engineers are confused by the standard’s terminology, says Packard. For example, they don’t understand what design inputs are. This is not a matter of semantics, since inputs govern subsequent validation and verification testing. If the input is wrong, the wrong tests might be done, or tests might be skipped.
“Many engineers think a design input is, ‘The device will be powered by two AA batteries,’ and the design output is a CAD drawing of the batteries,” Packard explains. “In fact, the batteries are a solutionto a design input. The actual design input is, ‘The device requires X amount of voltage and current.’ Knowing that input will lead to tests to ensure the batteries are hitting those numbers.”
Another requirement that manufacturers come up short on is actually one of the easiest to comply with—maintaining the DHF.
“The design history file should contain everything about the device, from concept through production—how you came up with the design, how you realized it, and how it’s made,” explains Hovland. “At the bottom level, it will have all the CAD files and source code. At the top level, it will have the product requirements and validation and verification results.
“Everything has to be in there. You don’t have to put informal documents in—notes, e-mails, things like that—but you can’t leave things out because you think they’re proprietary. For example, if the device will be in contact with a patient, you must list all the materials in the device and show they’re biocompatible. If one of those materials is new or proprietary, it doesn’t matter. It must be in the file.”
The DHF should also include design changes, complaints, adverse events, and, most importantly, what the manufacturer did to address any issues with the device.
