The Hidden Cost of Ignoring Medical Device Standards

Sarah Shen is a paediatrician. Every week in her ward, she sees children arrive with fevers that spiked overnight, unnoticed. In a young child, a temperature spike is a signal. Catch it early, and outcomes improve.

So Sarah had an idea. A small wireless patch, worn under a child’s arm, that pings a parent’s phone the moment a fever appears. Simple. Elegant. Clinically obvious.

What Sarah didn’t have was a background in regulated device development. Neither did the engineers she brought on board. Twelve weeks in, they had a working prototype and a standing ovation at a paediatrician conference. Six months after that, they had cloud sync, multi-child profiles, and talks underway with a hospital.

Then a hospital coordinator asked one simple question about their software classification, and the team realised they had no path to market. Not because the idea was wrong. Because the foundations were missing, and by that point, missing foundations don’t get fixed. They get rebuilt, at three to five times the cost, with the clock already running.

Join Aquib Fateh, IDE’s Head of Software, as he unpacks why most medical device software projects fail long before they reach a regulator, and what to do about it. You’ll meet Sarah, and see exactly where her team’s foundations gave way, and what she should have done differently from day one.

This webinar is built for founders, product leads and engineers building connected medical devices, whether you’re three months into your first prototype or already talking to hospitals. If you’ve written a single line of code without answering “what standards apply to us?”, this is for you.

Aquib unpacks the frameworks and legislation that govern how software for medical devices must be planned, designed, tested and maintained. This includes four standards that apply from day one. ISO 13485 is the quality management system and governs all medical device company’s processes. IEC 62304 governs how the software itself is built and maintained. ISO 14971 treats risk as an ongoing process, not a document. IEC 62443 covers cybersecurity, because a connected device is a vulnerable device. Although full compliance is not expected until regulatory submission, gaps in one standard create gaps in the others.

Skip these at the start, and you don’t skip the work. You defer it. According to the FDA, close to a third of submissions fail at the very first administrative screening, before anyone even evaluates the science. Most of the rest get sent back for more information. These aren’t bad ideas being rejected. They’re good ideas with bad processes.