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

IEC 62304 is a software lifecycle standard that covers the safe design and maintenance of medical device software. It has several points about how your software team handles feedback for medical device software.

And sure, complying with these points is essential for getting through your product’s software audit.

But have you ever stopped to think about how you could use feedback points? Use them to create opportunities for your software, your team, your product, and your business in the long term?

You can use IEC 62304 to improve the quality of your software.

Feedback loops in a software setting

Feedback loops are a classic part of quality management strategies. Loops help you to work in a way that puts knowledge gained during development right back in.

Using an Agile or Lean-Agile development philosophy in a medical device setting means regular feedback. Feedback becomes part of a development journey that’s “evolutionary” and not linear like you find in Waterfall.

AAMI TIR45 guides teams through using Agile in medical device software development. Committing to an Agile/Lean-Agile vision of software development, it looks something like this:

Evolutionary lifecycle as depicted by TIR45.

As you can see, loops are happening at every possible stage. Feedback is constant and not left until near the end of a project or often saved for version two.

And working with Agile methodologies can deliver a six-times higher success rate than Waterfall (CHAOS report 2015 (PDF)).

IEC 62304 gives you opportunities to create good feedback loops

At least several points in IEC 62304 offer you the chance to build robust and valuable feedback loops. Including the software development plan.

Your software development plan can help you record an evolutionary approach to software creation.

And before you say, “But IEC 62304 doesn’t allow for process changes to happen as you go!”

It does, and it all depends on how you write your software development plan.

If you explain the approach you’re taking and how these elements interact, you’ve done your job. And showing how that plan can change in a controlled way during development is critical too.

Benefits of effective feedback loops

Lean-Agile and Agile ways of working need frequent feedback loops to function but there are real benefits to working this way. Regular feedback helps:

  • Cut waste
  • Decrease bugs and improve software quality
  • Enhance product usability

How?

Frequent reflection on projects helps identify waste. Waste can come from unnecessary feature development. But frequent reflection allows teams to assess the business value of features for better prioritisation. It also helps teams learn from each other and see if any processes are causing issues and offer a forum to fix them.

Catching bugs and defects early keeps costs down. It’s more expensive to fix bugs after development and after release. Test-first software development like Test-Driven Development can help decrease defects by 40% and 90%. That’s compared to testing everything at the end of development.

Relative cost to fix bugs, based on time of detection. The later bugs are detected, the more cost involved in fixing them.Focusing on usability early helps ensure that your team develops software that is less prone to human errors. Investing in usability makes devices more intuitive and easier to use. Creating a product that works with people rather than against them, helps push your product to the top of the market.

Unlike Waterfall, working in an Agile or Lean-Agile way supports continuous improvement from the get-go. It doesn’t matter what the “maturity” of your processes are.

Feedback practices that work well with Agile and Lean-Agile teams

The following suggestions are not exhaustive. Yet these have a lot to offer when working in a way that supports evolutionary lifecycles.

User Experience (UX) activities

UX examines every facet of an end user’s (or customer’s) interaction “with an organisation, and its products and services.”

A critical part of UX is focusing on usability. Usability testing gives you the chance to determine whether your product’s software choices are heading in the best direction. They also help you evolve a product and its features or find out what you need for the next generation post-release.

The great thing about UX research? Whether it’s:

  • Holding interviews
  • Empathy mapping
  • Building personas
  • Running observed usability testing

Or any other UX method?

You can do many of them at any point in a product lifecycle, but they’re game changers when you start them early. UX makes sure you’re basing decisions about design and features and prioritisation on evidence.

Plus, starting work early on UX means you have concrete info you can give your marketing and sales teams so that they can build a solid launch campaign.

Software testing

Software testing and its documentation are a big part of IEC 62304. Several practices can help your teams shorten feedback loops and build robust testing regimes.

Test-Driven Development (TDD) is a test-first approach to software development. It involves software engineers developing unit tests for the code they’re writing and then writing the code to pass that test. It ensures code functions in line with requirements. Plus, it creates a suite of tests to help with software bug tracking as the project progresses.

The feedback loop created by UX, TDD and BDD in software development.

Behaviour-Driven Development (BDD) helps you understand how a user’s journey through a system relates to software requirements. And it does that in a way that both software teams and non-technical stakeholders understand. BDD supports early discussions on requirements, improving quality and understanding for everyone involved.

Both TDD and BDD, when used with living documentation and test automation, have enormous advantages. Combining all four cuts time spent on testing and document creation. They also create a documentation trail between requirements and actual source code.

(Get your software testing right and you also cut the time spent on release cycles.)

Frequent retrospectives and reviews

Retrospectives and reviews are the cornerstones of Agile and Lean-Agile ways of working. Retrospectives especially so.

Retrospectives look at how a sprint has gone—and can take place at any point in the evolutionary lifecycle diagram we showed earlier. Retrospectives are process focused. Here wins and challenges can be flagged and either worked through or an action created to address it.

Retrospectives support continuous improvement from the start. Happening as part of the development and testing cycles and not at the end of the entire project.

Reviews look at feature delivery during a sprint and what features might be considered next sprint. They help with prioritisation and making sure sprints deliver business value.

Both offer opportunities to provide feedback, look at the feedback given up to this point and make project adjustments as needed.

Would you like to know more about how Bluefruit works to deliver high-quality embedded software? Watch our video:

Unsure if your medical device is IEC 62304 ready?

We hope you’ve picked up a few ideas on how you can gain the most from having frequent, high-quality feedback during software development and how these fit with IEC 62304.

If you’re wondering how well your device software holds up against IEC 62304, 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 critical 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