Glanced through the latest FDA warning letters today. From the FDA Medical Device & Radiological Health Operations West/Division 3 I see the inspector pointing out “This design validation also fails to include software validation [emphasis mine] to assure software will perform as intended and will not prevent safe operation by the user.” Of course this is straight from the regs – 21CFR820.30(g). Absolutely one must consider the safe and effective operation of the software when making an argument for design validation. For those of us familiar with software development, we are always skeptical our software will perform as expected under all operating conditions.
So what does FDA expect with regard to software validation? A common misconception is that software validation is a very comprehensive test that is executed once the final version of software is created. While a comprehensive test is helpful, testing alone is insufficient to give confidence that software is performing according to all specs, meets the users’ expectations, and that defects will not lead to hazardous situations. FDA guidance recommends, and fully expects, an entire software development lifecycle approach to software quality. Safe and effective software, at a minimum, should include:
- designed-in risk control measures
- other operating self checks of hardware and software
Additionally, the software should be developed under appropriate and sufficient process controls throughout the entire lifecycle. IEC 62304 is an FDA recognized standard for software development process and IEC 80002-1 contains many excellent best practices for medical device software. These two standards are definitely a good start for ensuring the software development lifecycle process being used is state-of-the-art.
Beyond FDA expectations or requirements under ISO standards, each company should develop their own quality standards – remember published standards like IEC 62304 are meant to be the “bar” which in reality is a minimum. Our goal as software professionals is to create defect-free designs. Go beyond the bar. Focus on “real” quality – develop appropriate metrics so that it is clear where the process works well and where it is not working well. As one professional stated, “Own it. Take responsibility for software errors and make the changes necessary to prevent inserting others.”
