Balancing Agile With the Rigidity of Medical Device Software

Although taking an Agile approach to software development for medical devices seems counterintuitive, it brings great value by mitigating risks.

Medical devices have a long history of being subject to strict regulations and safety standards. Software, on the other hand, entered the medical device space more recently. In the early days, medical devices had to be taken off the market because ineffective processes led to bad software. As a sensible reaction, regulatory bodies, such as the FDA, addressed those problems with new or rewritten regulations, and even international standards were developed.

These regulations and standards require a high level of planning and documentation and either mandatory or strongly suggested processes, actions, and decisions. At first glance, the rigidity that enforces quality and safety can seem incompatible with Agile. However, experience has shown that not only is it possible, but it’s even beneficial to take an Agile approach to medical device software development.

Our article will elaborate on one of the key standards in the sector — IEC 62304, defining the life cycle of medical device software. After a brief outline of the requirements for compliance with this standard, we’ll explore how it can be effectively applied within the Scrum framework and examine how Agile values contribute to mitigating risks in the development of medical software.

IEC 62304 and Software Classification

In brief, IEC 62304 is:

• An internationally recognized quality standard that defines the life cycle requirements for medical device software
• Composed of a comprehensive list of requirements for the development process of software as a medical device (SaMD) and software in a medical device (SiMD)
• Recognized as a consensus standard by the FDA, as cited in its Content of Premarket Submissions for Device Software Functions
• Recognized by regulatory agencies around the world

Let’s first clear up a concept that might be confusing. As formulated by regulatory bodies, medical software is considered a medical device, and this applies to both SaMD (not a part of a hardware medical device) and SiMD (integrated into one).

Additionally, medical software is sorted into classes based on the type of potential risk it presents to patients:

• Class A: no health risk is implied
• Class B: no serious injury is possible
• Class C: death or serious injury is possible

Phases of the Software Development Process

Central to IEC 62304, consisting of nine parts, is part 5, which defines the software development process. Depending on the class the SaMD/SiMD belongs to, some phases of the development life cycle are considered optional, while others are mandatory for compliance.

5.1 Software Development Planning

Each organization creating medical software must have a development plan including а development process definition, task deliverables, software requirements and traceability between system requirements, tests, risk controls, SOUP configuration items, verification plans, and more.

SOUP, short for Software of Unknown Provenance, refers to any code — tools or source code — developed by a third party without clear development controls and formal documentation. This code is, by default, considered error-prone, and consequently, it is crucial to carry out a risk analysis of every SOUP used.

5.2 Software Requirements Analysis

The software development company must identify and document all software requirements, such as functional, performance, and safety requirements. They need to be complete, correct, and unambiguous and should be traceable to system requirements, uniquely identifiable, and written in a way that allows test establishment based on them. Finally, the requirements should be verified.

5.3 Software Architectural Design

This document includes the overall structure, interfaces, and modules and should be based on the software requirements. The architecture should support the intended purpose of the software and facilitate verification and validation activities.

5.4 Software Detailed Design

The level of detail required in the software detailed design document varies depending on the classification of the software. While both class B and C require this document, class C imposes additional requirements, demanding a detailed design for each software unit and interface design. Furthermore, verification of this detailed design is mandated for class C software.

5.5 Software Unit Implementation and Verification

Each software unit should be implemented. A verification plan should be made for class B and C software, and each software unit should meet acceptance criteria before merging into a more extensive software system. Each unit should be verified, and the results should be documented.

5.6 Software Integration and Integration Testing

Integration testing is required for classes B and C, verifying that the software units have been integrated and functioned correctly and as intended. It is possible to combine integration testing with software system testing in parts where they overlap (“working as intended”)

5.7 Software system testing

Before releasing any software, system testing that combines automated and manual testing must be carried out. The most important aspect is traceability between tests and software requirements, documenting the actual tests and results and preferably providing proof (e.g., a screenshot).

5.8 Software release

The software can be released once all required stages and documentation have been completed. The goal here is to ensure that the verification is completed and all the activities described in the software development/maintenance plan are completed, to document and evaluate residual anomalies and how the released version was created, archive the released version, and describe how the new version will be delivered to customers.

How do Agile and Scrum fit in?

Now that we have outlined the key concepts and processes regarding the life cycle of medical device software as per IEC 62304 let’s come back to our main question: How does the Agile methodology align with the rigidity of the medical device sector?

Many seem to forget that there are two sides to Agile. The Agile Manifesto states: “That is, while there is value in the items on the right, we value the items on the left more.“

In other words, the “items on the right” (process and tools, comprehensive documentation, contract negotiation, following a plan) should be orchestrated in a way that they support the “items on the left” (individuals and interactions, working software, customer collaboration, responding to change), rather than just being there isolated.

With that in mind, although it might seem counterintuitive, embracing an Agile mindset while adhering to IEC 62304 standards proves both feasible and advantageous.

The objective of IEC 62304 is to mitigate risks associated with the development and utilization of medical software. Scrum, the most commonly used Agile framework, works especially towards minimizing risk as it emphasizes iterative and incremental development. Here are a few advantages Agile and Scrum bring to software development for medical devices.

No missed details

By focusing only on the work that needs to be done within a single sprint (typically a two-four-week increment), the development team is encouraged to look into each detail of the increment, thus identifying potential risks early in the development life cycle.

Clarity and frequent communication

Scrum fosters clarity in requirements by promoting frequent communication (Scrum ceremonies) and feedback loops, thereby facilitating compliance with most of the verification requirements of IEC 62304, provided that the work is well-documented and traceable (as commonly observed through user stories, test cases, and via branching strategies).

Finding and fixing anomalies and defects proactively

The principles of test-driven development (TDD), a programming style commonly seen in Agile, ensure early detection of anomalies and flaws, empowering the development team to preemptively address any issues with medical software long before it reaches the end-user.

Quick reaction to any issue or change request

Agile frameworks are designed to enable swift responses to any issue or change request. Continuous integration and continuous deployment (CI/CD) pipelines, common in Agile setups, ensure the seamless and secure integration and deployment of software changes. This is achieved by ensuring that all needed (automated) tests are in place and run, rollbacks are possible and quickly done, there are enough environments to test the code before sending it to end users, etc. In medical software, promptly and securely deploying required changes is paramount.

Ultimately, following Scrum or any other Agile framework while documenting all processes, requirements, and decisions leads to compliance with IEC 62304. While the notion of exhaustive documentation doesn’t seem Agile-like, we highlight again that documentation is still valued in an Agile setting, as long as it serves the purpose, i.e., a working (and safe!) software.

Putting It All Together

Planning software development is something that happens at the beginning of every project. This should produce a software development and software integration plan (5.1) that describes the stages of the Agile development model, including the roles, responsibilities, and tools used in the process.

Then, the product backlog is created by analyzing software requirements (5.2). During the refinement sessions and sprint planning, when the focus is on system requirements, an architecture design document (5.3) can be created, along with the detailed software design document (5.4), if needed, before the sprint starts.

Once the sprint starts, the user stories are implemented and verified (5.5), and at the end of the sprint, during code freeze, software integration and testing (5.6) take place, along with software system testing (5.7). Once all the steps are done, the software is released (5.8) to end users.

Conclusion

The benefits of building medical software to follow the standards outlined in IEC 62304 are undeniable. We’ve made the case that process and documentation have a place in Agile and Scrum as we demonstrated how the different phases of Part 5 of IEC 62304 fit into various stages of the software development life cycle in Scrum.

The rules and frameworks are already in place. Once the expert team is put together, you’ll be well on releasing expertly built and tested medical software products.

Original post here.

Authored by Tara Maksimović and David Tomov-Strock.