Software and FDA

Medical Device & Diagnostic Industry Magazine | MDDI Article Index

Originally published January 1996

Ken Niehoff

Liebel-Flarsheim, Cincinnati, OH

I began developing software for medical devices after years of developing software for the military, commercial, and industrial marketplaces. I knew coming in that FDA regulated the medical device industry. What surprised me was not that the industry was overregulated, but rather that FDA did not place more stringent requirements on software development activities. After all, medical device software can be as complex and safety-critical as some advanced military systems. In both cases, poorly designed or poorly written software could cause serious injury or death.

Industry journals have devoted innumerable articles to software safety, quality assurance, and development methodologies. Typically the information presented is very useful, clear, and concise. When I examined actual FDA documents, however, I found them vague and open to interpretation. Most of these documents, such as Application of the Medical Device GMPs to Computerized Devices and Manufacturing Processes, Reviewer Guidance for Computer-Controlled Medical Devices Undergoing 510(k) Review, and Technical Reference on Software Development Activities, were aimed at training FDA investigators. These documents signaled to the medical device industry that software development activities would most definitely be an area of interest during forthcoming FDA investigations. No signal could be clearer than the following quote from the FDA document Reviewer Guidance for Computer-Controlled Medical Devices Undergoing 510(k) Review: "The FDA is focusing attention on the software development process to assure that potential hazardous failures have been addressed, effective performance has been defined, and means of verifying both safe and effective performance have been planned, carried out, and properly reviewed."

It is apparent from the proliferation of software-related seminars and consultants that companies received these signals loud and clear. My experience, however, is that although software is certainly an area of interest during FDA audits, the level of scrutiny varies greatly. No wonder, then, that some companies seem more concerned with increasing the quantity of their documentation than improving the quality. The medical device industry is an intensely market-driven business, and medical device companies must constantly balance time-to-market pressures with FDA requirements. If companies perceive FDA requirements for software development as being vague and loosely enforced, it is no wonder that, when pressed, some companies choose to get the product to market as quickly as possible and view the software development requirements simply as a word- processing exercise to be performed after the fact.

Despite this, however, FDA is having a positive effect on the quality of medical device software because the guidelines force medical device companies to treat software development as an engineering discipline rather than a black art. This is the all-important first step in gaining control of the software development process. Many companies do follow the recommended software development practices, and most companies promote good practices; however, I believe a true commitment to formal software development practices is driven as much by competition as by FDA. The pain of one poorly developed software release makes a true believer out of any medical device company.

FDA has, for now, wisely decided to allow medical device manufacturers to prove through internal documentation that they are following the appropriate software development practices. Should FDA--as I first thought--have more control over software development in the medical device industry similar to the control the Department of Defense (DOD) has in the defense industry? The answer is no for three simple reasons. First, the medical device industry does not need the additional bureaucracy. Encouraging good practices is one thing; dictating detailed requirements is quite another. Many smaller companies would suffocate under the weight of the additional requirements with no apparent benefit. Second, FDA does not have sufficient staff to enforce additional regulations. Providing in-depth software validation is a gargantuan task for which FDA appears to have neither enough expertise nor funding. Third, the two agencies have different types of relationships with their respective industries. FDA is a regulator, whereas DOD is a customer. It would be impossible for FDA to require that all medical device software be written in a particular programming language as the miltary has done.You can bet that the Health Industry Manufacturers Association and the National Electrical Manufacturers Association, to name just two, would be knocking down the doors of Congress in outrage, and rightfully so.

Software development is a complex process, and it gets more complex all the time. As medical devices rely more and more on software to implement functions and safety features, FDA must place increased emphasis on the use of proper software development methods. Are the current FDA guidelines appropriate? I think so. Even though medical device manufacturers could comply with the letter of the law but not its intent, such companies will not survive for long. The complexity of the software required to run tomorrow's medical devices will demand proper software development techniques.