I’ve advocated before that you should prove that your device is safe to yourself before proving it to the FDA. I’m a big proponent of designing a development process that works for your team. Plus, the FDA does not actually require that you follow any particular published standard in order to get approved or cleared to sell a medical device. You won’t find any mention of particular standards in the Code of Federal Regulations that govern the FDA.
Why, then, are standards valuable?
It may seem like a silly question, but it’s worth explicitly stating the reasons for following the standards, so we can be able to recognize when it’s appropriate to not exactly follow the standards.
If you are developing software for a medical device, following a standard such as IEC 62304 gives you a repeatable starting point and framework for a development process that everyone in the industry is familiar with.
This is a good thing because it reduces:
- the work required to create your process
- the work required to evaluate your process
- the risk that you miss something
- the risk that your regulatory submission will be rejected
Let’s examine each of these a bit more.
Less work to create a process
A standard reduces the amount of work required to create a development process. Medical devices are complex. The people that create them, since they are human beings, are complex.
Specifying a detailed process that a team of people must follow to design, develop, and manufacture a complex product is REALLY FREAKING HARD.
IEC 62304 is a detailed standard, over 80 pages, that does a lot of the heavy lifting for you. You still have a lot of work to do, don’t get me wrong, but using an accepted standard as a starting point will save you years of effort.
Less work to evaluate a process
A standard reduces the amount of work required to evaluate a development process.
This is an important point to remember about your FDA submissions:
The FDA does not evaluate your product.
They don’t review code.
They don’t review schematics.
They don’t review mechanical drawings.
They don’t sit in on your system testing or usability testing.
They don’t actually test your product at all.
The FDA evaluates your process.
They want to see evidence that you devoted significant thought and effort to specifying what your device will do, and proving that it actually does that safely and effectively.
If you state that “We followed X industry-accepted standard”, then you’ve made the FDA reviewer’s job much easier. If you develop your own bespoke development process and do not tie it back to a known standard, then that person will have to dig much deeper to evaluate whether you’ve been thorough and rigorous.
Hint: it’s always a good idea to make your FDA reviewer’s job easier.
Less risk that you miss something
If you design a development process from a clean sheet of paper, you will almost certainly miss something, unless you spend years doing nothing but writing and reviewing and rewriting and experimenting and reviewing and rewriting and soliciting industry feedback and reviewing again. Just your process documentation.
Guess what? This is what standards committees do!
Any well-known standard was produced by a standards committee consisting of many smart people that have thought deeply about the domain, and they’ve spent years doing all the reviewing that you don’t have the time or money to do.
They will have included things you would almost certainly miss if you developed your own process from scratch.
Less risk that your submission is rejected
As mentioned above, basing your process on a known standard means less work for your FDA reviewer. They are also well-aware of the risk posed by a development process designed from scratch.
In practice, this means that if you don’t follow accepted standards, your submission will probably be rejected.
I’ve never been involved in a FDA submission where the company did NOT follow industry-accepted standards such as 13485, 14971, 60601, and 62304 (and many others). I wouldn’t want to be involved in such a project. I can’t imagine that such an effort would be successful.
Hey, you’re selling what’s already been sold
So, the end result of all this discussion is: comply with a standard? That’s… umm… obvious.
No. That’s not what I’m saying.
I’m saying you should start with a standard.
In almost all cases, I advocate meeting the requirements of the standard. There can be exceptions (more on this later).
In many cases, I advocate going beyond the standards. Remember how I said that you need to prove that your device is safe to yourself first? Sometimes the standards don’t go far enough for me.
I won’t list all the important standards for medical device development here, but for software-specific standards and regulatory information, check out this article.