FDA Regulation of Software for Medical Device Manufacturers

David A Vogel, PH.D.
June 2005
WHILE THE DIZZYING ARRAY of FDA regulations and changes may seem overwhelming, there is a checklist that can help you stay sane and in compliance.
Medical device manufacturers are regulated in two different but related ways by the FDA. First as with drugs, device manufacturers must convince the FDA through a pre-market notification process that their devices are both safe and effective. However, the FDA also requires medical device manufacturers to comply with its Quality System Regulations (QSRs). This set of regulations controls the methodologies and processes used by a manufacturer to design, develop, manufacture, and maintain their devices. This second set of controls is intended to assure the quality and consistency of the development and manufacturing processes by requiring a formal, systematic quality system to further assure the safety of the device.
Software gets special attention from the FDA. Software is now embedded in a large percentage of electro-medical devices, and the amount of device functionality controlled by software is continually growing. Software controls many medical device manufacturers’ design, development, manufacturing, and quality processes, regardless of whether software is a part of the manufactured device or not. Software failures can often be invisible and difficult to detect, and they can thus have disastrous consequences on the operation or quality of medical devices. For this reason, the FDA specifically requires validation of both device software and quality-system software.
There is a notion in the industry that compliance with FDA regulations is difficult because the “rules are constantly changing.” To some extent this is true, especially as they relate to software. Understanding why the rules appear to change can help medical device manufacturers cope with and even predict future changes.
Just What Are the “Rules”?
It is important to have an understanding that there are different types of “rules” that originate from different sources and that require different levels of compliance from device manufacturers. It’s useful to think of the hierarchy of rules as a tree. The root structure of the tree is federal law, in this case the Food, Drug, and Cosmetics Act of 1938, which was amended in 1976 and most recently revised in 1997. As you can see, this is not a rapid rate of change. The roots of our “rules-tree” do not move much in response to short-term influences. One unfortunate, related fact is that legislative change usually only takes place after a well publicized, large-scale tragedy.
The trunk of our rules-tree is the FDA’s Code of Federal Regulations (21 CFR 800-1299). Compliance with these regulations is mandatory, as is compliance with the legislation mentioned above.
The FDA’s guidelines for complying with its regulations are published as guidance documents, represented as the main branches off the trunk of the rules-tree. Compliance with the guidance documents is voluntary, although any deviation from the guidances should be explained and defended by the device manufacturer. Guidance documents are updated approximately every five years, and new guidances are issued as the need arises (more on this later). The roots and trunk of our rules-tree are very stable and resist movement as the winds of technology change rush by. The guidance branches, however, do tend to sway a bit as technology changes.
The twigs and leaves of the rules-tree are the industry standards and industry technical information reports (TIRs). These are usually written by industry consensus and organized by industry associations, often with FDA participation. Compliance is voluntary. These rules fluctuate as often as a group volunteers to write or rewrite them. Often they are written around a process or technique that is in vogue at the time. The TIRs are usually written as survey reports on a number of applicable methodologies in use that are applicable to a regulated activity. They are not at all proscriptive and as such are weaker documents than standards. In other words, TIRs neither recommend nor outlaw activities; they only present alternative ways to approach a problem. The twigs and leaves of the rules-tree branch sprout and change relatively rapidly as the winds of technology change and personal opinion and industry preference whistle through them.
Good Reasons for the Rules to Change
Now that we have an understanding of the relative rates of change of the various types of rules, let’s examine what stimulates the changes.
The original Food, Drug, and Cosmetics Act of 1938 became legislation after nearly 100 people died from ingesting an elixir containing a substance similar to antifreeze. The FDA’s power to require pre-market notification (PMN) wasn’t granted until the Medical Device Amendments of 1976, prompted by the injuries of thousands of women by the Dalkon shield intrauterine device. The massive X-ray overdose of cancer patients in the Therac-25 incident of the 1980s was caused by a software error and led to the Safe Medical Device Act of 1990 and the subsequent publication of the FDA’s QSRs in 1996, which gave software special attention. In all these cases, it was catastrophe that stimulated changes in legislation and regulation.
Change also breeds change. The QSRs mention the validation of software as a regulatory requirement. This new requirement led to the publication of the FDA Guidance on the General Principles of Software Validation (GPSV). Although it was a technology change (introduction of software into medical devices) that led to the software validation requirements in the regulation, it was the regulatory change itself that created the need for compliance guidelines.
Technology change stimulates change in the regulatory environment. Much of the regulation and guidance available from the FDA today related to software development and software validation implicitly assumes a lifecycle model roughly equivalent to a waterfall model or modified waterfall model. A waterfall lifecycle is one that sequentially goes through well-defined phases such as Concept, Specification, Design, Implementation, Test, and Maintenance. Today’s “agile methods” such as “extreme programming” do not fit well into the existing guidelines on software validation. If and when agile methods gain in popularity in the medical device industry, we can expect the guidelines to evolve to clarify the regulatory intent for this group of developers. As a second example, consider programmable parts such as field programmable gate arrays (FPGAs). The GPSV is targeted for software in general-purpose PCs and embedded microprocessors; it is seldom applied to software in other programmable parts such as FPGAs. As more functionality migrates to these types of devices, there is increased likelihood of catastrophic failure and subsequent updated regulatory guidance.
Evolution of regulatory thought is also responsible for some regulatory change. As device companies attempt to comply with the regulations and guidelines, it becomes evident that some guidelines work better than others. As TIR workgroups meet to discuss different ways to comply with FDA regulations, they question all aspects of the regulations and guidelines, and recommend change. As the industry strives to achieve compliance, tools evolve to help automate regulatory tasks and make possible other actions not originally anticipated by the regulators. All of these reasons and many others lead to evolution in the thought behind the regulations and ultimately to the evolution of the regulations and guidelines themselves.
Sometimes the Rules Don’t Change But Seem To…
There is another phenomenon that gives the impression that the FDA’s rules are always changing. This has to do with the logistics of enforcement of the rules.
Even when legislation, regulations, and guidelines are not changing, there will always be a spectrum of interpretation and opinion within the FDA. Consequently, the FDA response to submissions might vary from examiner to examiner. The results of manufacturer inspections will also vary among FDA inspectors. Interpretation and opinion accounts for some of the differences, but so do level of training, years of experience, and aptitude for the job. This level of variation exists even when there are no changes in the written rules.
Now consider what happens when the FDA’s regulations or guidelines do change. The entire examiner and inspector workforces need to be retrained on the new regulations, guidelines, or policies. This process itself can take months or years. During the training period there will be an obvious imbalance in application of the rules in addition to the variations already mentioned above.
To further complicate matters, as individual documents evolve within regulatory structure, the changes are likely to contradict or otherwise conflict with other, older documents in the regulatory tree. This can lead to confusion within the medical device industry as well as within the regulatory agency itself. This is an unfortunate byproduct of an agency tasked with trying to regulate an industry that changes rapidly with evolving medical science and device technology.
How Can Medical Device Manufacturers Deal with the Regulatory Realities?
It might at first seem like a hopeless cause to keep a medical device company in compliance given the challenges noted above. It can indeed feel hopeless if one gets lost in the apparent problems with the process and misses the big picture. Keep in mind that the FDA’s primary concern is to assure the public that medical devices are safe and effective. That’s the “Big Picture.”
There are a number of things you can do to stay as close to compliance with the regulations as possible:
Know what rules apply to your company, and to your specific area of responsibility. The sections of the Federal Regulations of most applicability to medical device manufacturers are 21 CFR 820 (the Quality System Regulations), and 21 CFR 11 (a.k.a. Part 11 – Electronic Records and Electronic Signatures).

• Never assume that the regulations don’t apply to your situation because your company is small, or has a small budget, or doesn’t have the expertise available.
• Always do something to respond to each of the regulatory requirements. You can always debate the adequacy of what you’ve done, but you can seldom defend doing nothing.
• Always document your response to each regulatory requirement. In the eyes of an inspector or auditor, if you didn’t document it, you didn’t do it.
• Always take the time to understand why the regulators might feel each requirement is important for device quality and respond to that requirement appropriately. It does little to improve or assure the quality of a device when you take shortcuts in the quality process just to satisfy regulatory requirements
• Never document that your company has followed a process required by regulation when you really have not. Inspectors are trained to find evidence of this kind of activity. Furthermore, this deceptive activity does nothing to add value or quality to your device.
• When in doubt about how to comply with regulations, do the right thing. The most defensible position always will be that which does the most to assure the safety and effectiveness of the device.

Regulations of Particular Interest to Manufacturing and Process Engineers
The software validation requirements that apply to software used in manufacturing and process control are regulated by 21 CFR 820.70 and 21 CFR 820.30. All software, from machine-tool embedded software, to materials-planning software, to simple spreadsheets, is subject to these regulations.
The FDA, in collaboration with the Association for the Advancement of Medical Instrumentation (AAMI), has met with industry representatives for the past two years to produce a TIR on the Validation of Regulated Quality System Software. This workgroup’s research has identified a number of categories of software. These categories include off-the-shelf software, configurable or customizable off-the-shelf software, programmable software (e.g. macro-driven software), and totally custom-developed software.
There is a regulatory requirement to validate all of these types of software for their intended use. Yet there are very different levels of knowledge and control that a device manufacturer has over these very different categories of software. Consequently the validation needs to be handled in different ways.
The TIR will explain the differences in detail, propose a number of different methodologies for determining what level of validation is required, suggest a number of validation activities, and offer examples of how various types of software can be validated.
By understanding and keeping up with FDA software regulation, medical device manufacturers can hit the “moving target” of the latest FDA rules and requirements. Doing so enables the production of the best possible products with the fewest possible compliance snafus.
David A. Vogel, Ph.D., is president of Intertech Engineering Associates, Inc., 249 Vanderbilt Ave., Norwood, MA 02062. He can be reached at 781-255-5420 or dav@inea.com.