Last time, I asked the question: “Does the FDA discourage modern software development best practices?”

I’ll tell you now that my post follows the “Betteridge’s Law of Headlines”, and the answer is no.

The FDA doesn’t want you using paper QMS systems.

The FDA doesn’t want you developing software like it’s 1995.

The FDA doesn’t want you to focus on checking boxes, while losing sight of the real goal.

Jon Speer at Greenlight Guru wrote a great article about his view of the same trends that I noted:

In 2019, FDA will be releasing a new, draft guidance “Computer Software Assurance for Manufacturing, Operations, and Quality System Software” that embraces modern thinking on the topic.

I am looking forward to this guidance because, in my experiences, I’ve made and observed decisions regarding automation and technology that were often hampered by fear and pain of validation.

It’s now 2020, and we still don’t have the new guidance yet, but it’s scheduled for this year (COVD-19 notwithstanding). I’m very hopeful that as part of the FDA’s Case for Quality, they will help medical device companies focus less on checking boxes, and more on truly improving the quality of the devices they design, build, and sell.

An antiquated view of FDA’s software validation requirements should not keep companies from adopting tools and processes that will increase software quality and decrease development time.

There are many options for software tools and frameworks that will help with:

• Requirements and Software Life Cycle management
• Project management and Issue tracking
• Continuous Integration
• Unit testing
• Hardware-in-the-Loop testing
• Static Analysis
• Runtime Analysis
• Virtualization

I’ll review some of these tools in the future, but for now, if you are responsible for developing software for a medical device, and you are holding back, out of fear, on introducing a tool that you know is better…

…snap out of it!

Happy developing!