Creating a proof of concept device is cheap. Creating a device to be submitted through the regulatory path is not, even when it’s the exact same device.

The regulatory path is expensive.

Hardware-in-the-Loop Testing Setup at Dojo Five (Source)

There are two ways you can develop a device. The first method, which most industries use is to come up with some features and characteristics, write down some details, design the circuits, and start writing code. Maybe start with a development board and add the necessary extra components. Have some boards built up. Check them out. Now sell them. There are probably a few extra steps in there to create some documents and file them away.

The second way you can develop a device is for the regulatory path, like the medical device industry. It starts out with the same concept: an idea for a device. From there, things start to change.

The regulatory authorities’ focus is repeatable quality with the lowest possible likelihood of failure and risk. The means to this end is to create a detailed process for every step along the way. In other words, it’s all about process control. Create detailed processes, implement those processes, provide a means to show they are being followed, and review and update those processes as necessary.

The regulatory process requires a quality system: a set of documents that detail how the company’s activities must be performed, and the mechanisms to insure that company complies with those methods, e.g. audits, reports, paper trails, etc. The level and scope of details in those documents work as a how-to manual for the company, and they’re extensive. Details include how product concepts are documented and developed into products, how the development process occurs, how testing is performed, how products are distributed, how products are returned, how anomalies/failures and feedback are tracked, how components are qualified, what the roles of various departments and employees are, how people are trained on the various processes, etc. The scope is a bit daunting. The quality system even details how all of those same documents are maintained, stored, updated, approved, and retired, including the ones describing the quality system itself.

So, not only is all of that documentation in place, along with the set of methods that must be followed, but it requires regularly scheduled and surprise audits to prove that the system documentation covers all necessary aspects, and that it is being followed correctly. Failing the audits can cause a company to lose the ability to sell products or worse.

It’s a lot of documentation, but we’ve only just covered the basics, and nothing has even been developed yet. Buried in there are the product development processes. This provides details on how a product is developed: this covers how the products will be developed, what documentation will be created and maintained. Those documents might call out additional documentation identifying what methods and tools will be used. For medical devices, the hardware must conform to the IEC-60601 standards for safety. Software development must conform to the IEC-62304 software lifecycle standard. These are fairly extensive standards.

The standards don’t just apply to the medical device company. Any development work that is performed for a device by an outside provider must follow the documented processes. Training developers, and documenting that training, will be part of the quality system. It’s also possible for the outside developer to have their own quality system, in which case, if it meets the standards of the medical device company, the work can be done under that system instead. But that means there’s a similarly complex, active, up-to-date, audited quality system in place at the outside company.

So, imagine the effort involved in developing the quality system. Add to that the effort necessary for maintaining all of those documents and verifying that all of the methods are being followed. Make sure all of the employees are trained in the system, including further training for any applicable changes or additions to the system. It’s not a cheap prospect.

To get approval on a medical device, all of that needs to be in place. Documented proof will be necessary to submit to the regulatory authorities for the device to be considered for approval.

So, what’s the alternative? A proof of concept device can be built as just a “device,” not as a “medical device.” It’s the same hardware/software design, but it’s not a medical device. It doesn’t have to be developed and built under those rules. Instead, to use the device in clinical trials, the makers of the device will need to provide documentation including: what it is, how it has been tested, what risks it poses and what mitigation is in place to reduce those risks. Anyone wishing to use it will have to seek specific approval for that specific device and each specific use. There are standard rules and procedures for this, as it’s fairly common. It can be developed and modified much more quickly and with less expense. But when all is said and done, it’s not a medical device.

If you’re creating a device to be sold as a medical device, there’s a fairly lengthy process to complete. Most of that effort will not be focused on designing, building, and testing that device. Most of the effort will go into the regulatory process, and there’s a significant financial cost that goes along with it.

And if you have questions about an embedded project you’re working on, Dojo Five can help you with all aspects of your devops for embedded journey! We are always happy to hear about cool projects or interesting problems to solve, so don’t hesitate to reach out and chat with us on LinkedIn or through email!