Many medical device manufacturers are in favor of agile software development. However, they confuse SCRUM with a process model and are not fully aware or the implications even when working compliant with regulatory requirements.
The agile software development emerged as a kind of counter-movement to the trend,
The agile manifesto tries to overcome this trend, to find back to the original values and to adjust the priorities accordingly:
Another section in this article discusses this set of values in the context of software development for medical devices.
It is possible to develop software agile and to comply with the requirements of IEC 62304.
That's what the standard even explicitly expresses. But it also gives specific requirements, which we highlight below.
The IEC 62304 is clear: You have to document and to verify all activities:
You can meet these requirements, by going through the following activities several times and iteratively:
In practice, you mostly encounter one of the two approaches in medical devices:
The first (and compliant) approach includes the verification activities in every sprint. I.e. any changed artifact (e.g. SRS, architecture, code) will be reviewed prior to the next activity.
However, if your processes in particular the verification and approval steps are not very slim and streamlined, you have not reduced the documentation efforts, but multiplied it.
With delta-reviews and continuous revising documents you can minimize this issue. But that's the art of process excellence. Agile methods require highly trained protagonists and efficient approvals.
The second option is that you only document the above activities, including the reviews, after the last iteration. This is the approach that is frequently observed in practice in agile developing companies. But these companies have combined disadvantages:
Thereby companies pervert the purpose of regulations.
The IEC 62304 is also pretty clear when it comes to software architecture: The standard prohibits ad-hoc design decisions. Of course, capable software architects can develop and revise a software architecture iteratively and document it in compliance with standards.
However: Developing a software architecture "upfront" is already difficult enough, and most companies fail defining a concise, weakly coupled, and maintainable architecture. Even more difficult it is to iteratively and incrementally develop and refactor a software architecture in an agile approach when new requirements may be added in any sprint.
Frequently documentation and code get out of sync, architectural depths increase and cause problems with software quality and maintainability in the long run.
"Grown historically" is the usual explanation of software architectures, when an auditor questions the quality of the documentation or/and of the software itself.
Define the first two levels of your architecture upfront. Keep the architecture and documentation concise and consistent at any sprint!
We have already mentioned two pitfalls in agile software development for medical products:
But there are more pitfalls that partially result from misconceptions.
The values of the agile manifesto sound as reasonable as they are attractive. Let us analyze this set of values:
Undeniably, trusting teamwork, good communication and highly qualified employees are the prerequisite for successful software development.
The requirements of the standards such as the IEC 62304 or ISO 13485 for well-defined processes and the targeted selection, validation and documentation of employed tools neither can be discussed nor do they have a negative impact on achieving the goals of an agile development.
Many developers prefer to hear the second principle. Of course, working programs are essential. The hope of being able to reduce the documentation effort by agile software development, is mostly not met. On the contrary: The attempt of many companies, to develop in an agile way and in accordance with IEC 62304, often ends in the worst case: a particularly high proportion of documentation which is not conducive to the quality of the product. More on that later.
The most insidious trap is set by the last two points of the manifesto. Why does it require constant coordination with the customer? Why are regular changes necessary?
I know the statements of the development departments very well such as "the customer has decided otherwise," or "the requirements have changed." But behind this there hides a downright tragic misunderstanding: User requirements never change in a given context of use. Rather, there is a deficit of identifying these usage requirements in a systematic, complete and correct way. And companies try to compensate for this deficit by creating a development process that can deal with these changes.
If the manufacturer were to only focus a fraction of the energy that they apply for conversion to agile processes, invest in a systematic requirement engineering and training of those responsible, they would produce new products faster, more reliably and more cost-effectively. For products that the customers actually really need.
Standards such as ISO 9241-210 (2010) will give you valuable information about how to collect user requirements systematically. By the way, you can achieve substantial compliance with the IEC 62366
Conclusion: Do not abuse the agility to compensate for the incompetence in the systematic collection of software requirements and stakeholder demands.
It is desirable to develop, in an approximately one month cycle potentially shippable software, for example to reduce the complexity of the software development. However, it often makes no sense to actually bring the new version of the medical device on the market in this cycle, because functional changes or improvements to the product, mean a new approval or conformance testing.
A new conformity assessment procedures and / or submission of the technical documentation with notified bodies or the FDA's many companies is too expensive. In addition, an FDA clearance can last 90 days. Therefore, most companies do not iterate over the complete development process.
Let us also summarise the potential (!) dangers and disadvantages of agile development :
We recommend you develop the (agile) software development as follows in order to develop your medical software quickly, professionally and IEC 62304 compliantly:
Agility for agility’s sake is nonsense. The values of the agile manifesto are not: Trusting cooperation, customer focus, mutual understanding, mental flexibility and effective communication. Live these values!
If you want to learn even more about how you can make your software development agile and compliant with the IEC 62304, then use our help:
Get in contact with us!