While at the MD&M show in Anaheim, CA this week, I ran into Stephen Olsen, a technical marketing engineer for Mentor Graphics’ embedded division. Stephen was on his way to attend a class of 510(k) clearances. I asked him to write a blog about the class, which he gladly did:

At the MD&M and DesignMED conferences this week, I listened to some FDA experts describe the process inside the FDA to bring a medical device to market. These were former and current inspectors who had detailed knowledge of the FDA including its process for 510(k) clearance. While an excellent overview of the process (I now have a much better picture of what it takes to push a medical device through to receive the coveted FDA clearance necessary to get a product to market) I was still left thinking. And then this one catch phrase emerged—it depends.

While a little phrase such as this might be true for many aspects of product design, there usually is more certainty surrounding government regulation. Or at least there should be. As a medical device manufacturer, I would want to know what testing is necessary for FDA clearance. The answer is “it depends” on how critical that software is. What are the failure modes? And how are the failure modes being minimized in the design?

All well and good, but system architects expect a clear definition of what must be done to achieve certification. They are used to producing clear specifications for their systems and consuming external specifications. I have always liked specifications that use absolutes in their language with words like “must” and “cannot.” Even a range of acceptability is specified if it is critical to the success of the product.

The department of defense with the DO178B is a much more rigorous certification process, and for the highest qualifications, the code must be tested for every entry and exit from every block of code that will go on the aircraft. We’re talking mission-critical software here, but not so with the FDA 510(k) process.

Unfortunately, the FDA has a more nebulous specification with a lot of “it depends” sprinkled in, which is not a reproducible quantifiable process. It’s not all bad. As the FDA collects data on a product group, that collected data or product family is made public, so that every vedor can see what to test for and what to avoid. If there’s a failure attributed to a certain manufacturer, then they can hold the manufacturer to tighter scrutiny. If you have a good product with good history and documentation, then keeping that history clean is paramount to future success with the FDA.

In theory, any operating system can be approved for use in a medical device. But you must keep track of all the software in your device. If you’re working on a Linux platform, you must know where every bit comes from and not just the kernel. Every piece of software that touches the device must be sourced and maintained as to which versions of the code are in your device. I would imagine that this is not a trivial issue with some open-source solutions.

You must identify risks in your system and then show how your implementation eliminates the risk. What if the software stops working? What will your system do? Is there an external software and hardware watchdog to correct for unforeseen software catastrophes?

While system architects want a more detailed specification, the FDA doesn’t give them one, which means you can’t test to the specification. Rest assured, the FDA inspector will delve into your product documentation, and how well you’ve prepared will tell him if your product is complete, or if you need more information. "It depends!''

Note: This blog has been corrected, replacing the word "approval" with "clearance" throughout.