Your browser is no longer supported. Please upgrade your browser to improve your experience.

How long could a Class III medical device with Class C software take to get FDA approval?

For Class III with Class C software it could take up to 30 months for regulatory approval from the FDA.

And when it comes to the EU and the newly enshrined MDR and IVDR?

No one has yet seen how the increased oversight and complexity in the approval process will impact time to approval in the EU.

Your medical device software can hold you back from getting to market

The last thing you want is for your software to let you down in your time-to-market by either:

  • Failing an IEC 62304 audit when an auditor assesses your software and documentation. (IEC 62304 is the software safety classification used worldwide.)
  • Doing documentation in a way that it’s a burden on all involved, further slowing down development.
  • Making it a slow process to bring in new software engineers and testers to work on the project.

How do you ensure your software development is not a huge time drain?

Here are four things your software team can do to ensure your product’s software doesn’t hold back your product.

1. Get your Software Development Plan right from the get-go!

Your Software Development Plan is likely where an auditor will look first. At least when auditing for IEC 62304 compliance. It’s the home of some essential information about your software, like:

  • Explaining what kind of development method you’re using, such as an Agile or Lean-Agile.
  • Naming the project management and technical processes your team uses for software development.
  • What the inputs and outputs are for each step of the software development process.

The Software Development Plan offers a critical opportunity if done well:

You can use the plan to empower the team to enable continuous improvement of the software.

(Botching the plan means it doesn’t matter how well you’ve covered IEC 62304; the software will fail an audit.)

Support continuous improvement the Lean-Agile way

When we say continuous improvement, we mean the Agile/Lean-Agile idea of it. Sharing learning from the start and using it during development, testing and post-release.

By doing this in a way that follows the core of AAMI TIR45, your team can do Lean-Agile in a way that fits with IEC 62304. Helping software meet compliance.

(TIR45 offers advice on how to develop software that’s compliant while using Agile practices.)

An illustration of TIR45 for medical device software.

It means teams can straightaway take the knowledge gained in development and use it. Doing this avoids delays and problems later, where they might lose context and insight when trying to fix an issue.

2. Use living documentation and reduce the documentation burden

The IEC 62304 software classification is demanding when it comes to documentation. The Software Development Plan forms only a tiny part of what’s needed.

In one part of it, it asks if you’ve documented:

  • Source code
  • Unit tests
  • Code reviews

But software engineers aren’t fans of creating vast volumes of documentation. Why? They’re usually tied to creating documentation in ways that don’t fit with their workflow.

Living documentation for medical device software combines artefacts already made during development in a way that’s:

  • Version controlled
  • Understood by the software team
  • Understood by external auditors

Like so:

The elements of living documentation in medical device software.Here there’s an easy, automated play between engineering tasks and bringing together what an auditor needs.

Make the most of development artefacts

Suppose your team uses many practices that fit with Lean-Agile and Agile. In that case, it’s easy to bring everything together.

Practices like:

All the above, make clear artefacts that show the software journey. They also give great traceability. And you can automate bringing this evidence together and include version control.

Freeing up dev and tester time means they can focus on tasks that lift project velocity and quality.

3. Put in place automated testing

Automated testing frees up software testers to do activities that add more value to projects:

Exploratory testing and usability testing.

And for medical device software teams that use test automation, you’ll see shorter release cycle times.

It’s true that 100% automated test coverage isn’t likely. But not having testers involved in 90-95% of testing is a big gain for project velocity. (Even 30-40% coverage is possible in legacy systems.)

Automated testing functions particularly well in an Agile or Lean-Agile environment. Methods like Behaviour-Driven Development can help in test automation. How? In BDD, it’s easy to align software requirements and test cases.

What test automation involves for medical device software.The mix here helps again to improve traceability. It also matches many of the demands made by IEC 62304 on documenting testing. Good, automated testing also ensures that teams handle inconclusive and failing tests.

How does test automation look in a Lean-Agile environment following guidelines from TIR45?

You’re looking at moving from a testing environment that looks like this:

A graphic of how testing in a typical project looks like.To an automated testing flow that looks like this:

A graphic of how testing in a typical project looks like.

We know we’d prefer to ensure testers are spending time on activities that add real value to a project.

4. Invest in the roots of your code

How do you cut the time it takes for engineers and testers to get on with what they need to do for project success? Invest in the roots of your code.

When we say roots, we mean ideas like “conceptual integrity”. We also mean what IEC 62304 calls “software architectural design activity”.

Conceptual integrity means:

  • The habitability of software—software structure and documentation.
  • The maintainability of software—clearly written software that’s easy to maintain.
  • The scalability of software—well-structured software that’s easy to add features to.

Benefit: Habitability and maintainability speed up in-house or outsourced engineers starting development. (No matter what point in development they come in.)

Plus, it makes future development after product release far easier (scalability).

Code with high conceptual integrity is easier and faster to fix when solving bugs uncovered during testing or after launch.

Software architectural design activity means:

  • How all your software elements connect and interact (or don’t interact).
  • It can include third-party software and its interaction with in-house coded software.

Benefits: Well-documented software architectural design makes testing easier and helps conceptual integrity. It also shrinks the time it takes to bring in new software engineers to a project. It does this by making it easier to grasp how everything fits together.

Find out if your medical device software is IEC 62304 ready

We hope you’ve picked up a few ideas on how your team can make sure they keep project velocity and follow IEC 62304.

Are you wondering how well your device software holds up against IEC 62304? You can download your copy of The essential IEC 62304 checklist today.

The essential IEC 62304 checklist will help you:

  • Understand critical parts of the standard from a business perspective.
  • See the early signs of whether your medical device software is audit-ready or not.
  • Discover key opportunities working to IEC 62304 presents for your business.

Download your checklist and answer:



Did you know that we have a monthly newsletter?

If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!

Find out more