IEC 62304 & Agility for medical device software

  • Auteur/autrice de la publication :
  • Publication publiée :
  • Catégorie de la publication :Dispositifs médicaux / Marquage CE
  • Commentaires de la publication :0 commentaire
  • Dernière modification de la publication :
iec-62304-agile-software-development

IEC 62304 & Agiltity approach

The IEC 62304 standard defines a structured framework for the software development lifecycle, outlining several key stages.
Although some organizations still use the V cylce(linear and sequential approach), the agile approach (iterative and incremental) is more suited for medical device software development..

Definitions of Key Terms

Before diving into the main topic, let’s define some key terms. These definitions will help ensure a better understanding of agility

  • Backlog: A prioritized list of features, defects, and tasks to be completed, used for planning and tracking work. It includes user stories describing specific needs.
  • User story: A description of a feature written from the end user’s perspective, following the format: « As a <role>, I want <goal> so that <benefit>. »
  • Continuous integration: The process of frequently integrating code changes, accompanied by automated tests to ensure stability.
  • Increment: The gradual addition of new features or improvements to the software, with each increment providing immediate value.
  • Release: An operational version of software or a set of features delivered for deployment, testing, or use by clients or end users.

IEC 62304 and V Cylce

To begin, let’s examine the V-cycle, which is still widely used in the industry. This linear and sequential model follows strict steps but has some limitations when faced with more flexible development environments.

  • Rigidity in handling changes: Requirements often evolve during development, but the V-Model struggles to accommodate such adjustments.
  • Lack of user interaction: User testing occurs late in the cycle, potentially revealing issues at a costly stage.
  • Long development cycles: Full cycles can be too lengthy to adapt to an evolving regulatory environment.

Now, let’s move on to an increasingly adopted alternative: the Agile approach.

IEC 62304 and Agile approach

Agility is a more flexible way of working, allowing us to change plans if needed and deliver working pieces of software quickly. It’s like building the software step by step, improving it at each stage.

  • Incremental Delivery: We deliver small pieces of software whenever they are ready.
  • Collaboration: The whole team works together, exchanging ideas and feedback regularly.
  • Flexibility: If something goes wrong, we can easily change the plans.
  • Continuous Improvement: We constantly improve our way of working to be more efficient.

How does it work in practice?

To simplify (as that’s the goal), development is organized around four main layers:
Project, Release, Increment, Story.
Each of these layers must meet specific requirements defined by the standard.

The work is divided into different stages, or « layers, » which help manage each part of the project

Risk Management

The Agile approach does not specifically propose practices for risk planning or assessment, but it integrates seamlessly with risk management activities. Risk analysis activities can be incorporated into the backlog. When analyses identify risk control measures (such as mitigation actions or necessary modifications), these are added to the backlog as tasks to be addressed, distributed across the levels of stories, increments, and releases.

The priority of these items is determined based on their criticality, ensuring that critical risks are addressed before the end of the project.

The Agile approach does not specifically propose practices for risk planning or assessment, but it integrates very well with risk management activities. Risk analysis activities can be managed through the backlog. When risk analysis is performed and risk control measures are identified (such as mitigation actions ), they are added as backlog items at the story, increment, and release levels.

The priority of these items is adjusted based on their importance, ensuring they are addressed before the project is completed.

In the case the development of the software is outsourced, a quality agreement should be in place.

Would you like to discuss your project or learn how to ensure compliance with the IEC 62304 standard? Book a meeting here.

Laisser un commentaire