Ep6 - Develop Med Device Software "in the spirit of IEC 62304"

MedTech Speed to Data

Decrease Time-to-Market by Developing Medical Device Software “In the Spirit” of IEC-62304

Getting any new medical device to market is a race against time, and it’s so tempting to jump in and start coding from the get-go. But hold your horses – you’ll save time in the long run, and potentially improve the valuation for your company, by following the spirit of IEC-62304 throughout each stage of development.

This standard impacts the entire software development lifecycle: from initial requirements and coding to release and maintenance. Understanding when and how IEC-62304 applies can potentially save you months of backtracking in the race to get your device to market.

Check out this video as Computer Engineer Jamie Kendall and Andy Rogers lay it all out and explain how “working in the spirit” of the standard can keep you on track, on time, and in compliance, particularly when developing non-regulated devices.

Need to know:

• How to define the right architecture
• The trade-offs of building documentation as you go vs. retrofitting
• How existing code libraries and re-using compliant modules built to the IEC-62304 standard can keep you from “re-inventing the wheel”
• What tools can make the process smoother?
• How 62304 compliance can affect company valuation.

The nitty-gritty:

IEC-62304 lays out a unified process for evaluating safety in medical devices sold in the US and EU. The software safety classification, Class A, B, or C determines the safety-related processes you’ll need to use.

With non-regulated medical devices, you’re working within a highly-structured environment, without the formalized legislative pressure. Choosing to focus on specific areas of IEC-62304, even without the requirement, balances the key factors of time and risk management. And when you understand precisely how the regulations apply, you can stay in compliance without going for all-out unit testing at each stage of development.

It’s important to identify interfaces from the very beginning. Think through what goes where: for instance, what should be firmware and what should be PC-based software. You can use pre-engineered software or existing code/ libraries for things that are not unique to the system (stepper motors, pump etc.) so you’re not reinventing the wheel at each stage.

For example, using a single micro-controller on your platform gives you a good reusable framework for low/mid-level modules, especially when these are designed to IEC-62304. In addition, you can use a methodology like AGILE project management, tools like ReSharper, or static analysis techniques to help you maintain quality and compliance.

Keeping within “the spirit” of 62304 at each stage of development allows you to focus on key parts of the system and make needed changes in days versus weeks. By adding value to your device in this way, you’re building value for your entire company.

Helpful links

https://www.iso.org/standard/38421.html