In the previous blog post, we asked if it is possible to develop medical software using agile methods. We concluded that surely it is possible, but in addition to knowledge about agile software development, you also need in-depth regulatory know-how. When dealing with medical software products, the traditional way of working must inevitably be re-considered.
For Solita, the topic is important from two perspectives: both in terms of our Oravizio product development and customer projects. While Solita is undoubtedly efficient in many other software development domains, we also want to do the same in the medical context.
We have a certified ISO 13485:2016 quality management system in place, and we are helping our customers to build theirs. In addition, we are getting ready for the MDD-to-MDR transition at full speed while further developing our model for agile software development in the medical device context. In the last blog, we promised to provide more details about our vision below.
Solita way: Rapid Medical Software Development process
We aimed to create a software development model that ensures regulatory compliance and can be tailored depending on the environment of use. We have considered the different regulatory requirements relevant to the scope of products we are dealing with. Applicable standards for all Software as medical device (SaMD) products are company level quality management standard ISO 13485, software development lifecycle standard IEC 62304, process standards ISO 14971 and IEC 62366-1, and a product level standard IEC 82304. It is worth noticing that an applicable set of requirements and standards must be considered on a case-by-case basis. There are variations in the rigour of the process requirements based on the risk level of the product.
We want to follow basic agile principles and values: we want to build value first. We want to keep our customers in focus and collaborate transparently. We firmly believe, based on our experience, that iterative software development techniques drive high software quality.
However, some agile development models tend to focus more on management and team activities while giving less attention to technical practices. In regulated software development, certain technical practices are fundamental! As a result, we had to tailor our model to include technical capabilities that enable fast, efficient, and compliant development workflow. We aimed to automate repetitive tasks and invest in overall transparency within the process.
The outer circle is for regulatory work and clinical evaluation
In our model, the first thing is to understand the relationship between the inner and outer circles. While DevOps – the little cousin of RegOps – aims to release changes continuously to the production environment, it is simply not possible in the medical context. But that does not mean that medical software development cannot be done with agile methods. Not at all.
According to MDR, most software products are considered class IIa or higher. As a result, a notified body (organisation designated by an EU country to assess the conformity of products before being placed on the market) is involved in the product approval process. The initial CE certification is one thing, but the real challenge comes later in the maintenance phase. How often can you make a public release? Do you need the approval from a notified body for each release?
We do not have much real practical experience yet about how it all works in the MDR world. What we do know, however, is that when introducing substantial changes such as new clinical features or other updates, there is no way to avoid the involvement of the notified body. It is realistic to think that 3-4 such major feature releases per year are close to maximum – of course, this depends on many things. Making releases that only include error corrections is possible with a much lighter process.
The public releases include work that is hard to automate. In practice, the work tasks on the outer circle are performed by non-developer roles, such as regulatory experts, clinical experts, and product owners. Computers cannot estimate clinical patient risks, evaluate the usability of the UI, or validate the intended use of the device without a human touch, clinical know-how and experience.
Daily agile software development in the inner circle
Daily software development tasks are happening inside the inner “iteration cycle” with highly automated regulatory support. In addition to the usual roles found in the agile development team, the medical device software development team needs a few more, such as clinical and regulatory experts. These domain experts help the development team with tasks related to clinical efficiency and safety, such as requirement analysis and risk management.
The documentation that we are required to create should be as valuable as possible, and it is generated automatically as a by-product whenever that is possible. Key to this is a supportive project management tool and carefully crafted workflows – by following workflow developer is creating regulatory evidence without much effort. As software developers tend to be interested in the technical side of the development rather than regulatory aspects, we wanted to create an environment where the regulatory burden is carried out by the automated process.
Workflows also bring discipline and ensure that mandatory process steps are not bypassed. Without a doubt, a set of different checklists is our Quality Manager’s best friend. Still, the efficient use of the project management tool can reduce the number of checklists needed. It should be noted that the development team still owns their process – we are involved only to help them make sure that regulatory requirements are fulfilled. Furthermore, developers can choose their development tools quite freely, but the tools must be validated and accepted before use as required by our Quality Management System.
Conclusions and a sneak peek into cybersecurity
To summarise the original question – there are no actual barriers to agile adoption in the medical device context. However, keep in mind:
- Regulatory requirements can be fulfilled by extending agile practices and using appropriate tools, but you need to be aware of all the bit and pieces.
- Focus on high-level regulatory process documentation and use agile practices to generate plans for more detailed tasks.
- Regulatory processes require (a lot of) documentation – however, keep in mind that this documentation provides business value as we want to sell our product!
- The part of the project documentation that does not add value should be kept to a minimum.
So how to adapt the inner and outer circles into your company in practice? That is, of course, the tricky part, and it depends on a lot of your existing toolset, processes, and the products themselves. Solita can help you to build the process as agile as it can be in the medical device world.
Finally, a few words about one of the trending topics in the medical device business: cybersecurity. Have you already become familiar with how MDR explicitly emphasises the importance of managing not only safety-related but also security-related risks? We have, and we have adopted our risk management processes accordingly.
