As Agile is gaining traction in regulated product development, market pressure forces more and more medtech companies to adopt. To calm worries about compliance in an Agile environment, AAMI TIR45 provides guidance on the use of Agile practices in the development of medical device software.
Agile in medical device development
Due to the stringent requirements of regulations, developers were historically wary of using Agile in the delivery of medical device software. As Agile practices grew into maturity over recent years, it became obvious that their use doesn’t inherently contradict the stipulations of medical standards.
FDA’s endorsement of Agile practices further reinforced this statement. At last, Agile started gaining popularity in the delivery of medical technology. Manufacturers and regulators today agree that Agile is appropriate for developing medical device software.
But developers often still wrestle with understanding how exactly they can marry Agile’s decentralized and flexible nature with requirements on meticulous risk management, mature development processes, and thorough documentation. The adoption of Agile in practice is still an area riddled with questions and misunderstandings. AAMI TIR45 attempts to answer those questions and clarify the basics of adopting this framework in medical device development.
AAMI TIR45 is a document released by the Association for the Advancement of Medical Instrumentation in 2012. It is important to note that this Technical Information Report is not a standard or even a recommended practice. Yet its authors have considered the requirements of a host of medical standards (ISO 13485, IEC 62304, ISO 14971, FDA 21 CFR 820, etc) to provide developers with instructions on using Agile while achieving compliance.
Titled Guidance on the use of AGILE practices in the development of medical device software, TIR 45 specifies certain prerequisites to meeting regulatory requirements in an Agile development environment:
- The use of Agile processes has to conform to the requirements specified in the organization’s Quality Management System.
- Detailed lifecycle modeling should be undertaken to help maintain discipline in the operation of mature development processes.
- Robust strategies on change management have to be devised to ensure high product quality and an adequate risk level in a fast-moving Agile context.
- Ensure adequate documentation to meet quality standards (both internal and those of regulators).
The above quality topics were also addressed in Intland Software’s Roundtable Discussion on Agile in Medical Technology on 26 Sep 2018. Our experts emphasized the need for meticulous modeling and a strong QMS, among other valuable best practices. Access the on-demand webinar for free below!
Agile implementation in medical device development
To provide practical guidance, this Technical Information Report chalks up a hierarchical architecture of development processes. Specifically, TIR45 specifies four layers of development according to the Agile framework:
User story: Partial or full function that is delivered in anywhere from one to to a few days.
Increment (in the case of Scrum, a sprint): A set of functionality that might not be a complete software system, but is more complex than a simple user-story function. Delivered 1-4 weeks.
Release: A version of the product that is considered complete for internal testing. Delivered generally in one to several months.
Project: Finished product ready for market release.
Activities pertaining to each of these layers are mapped to IEC 62304 requirements to make sure that regulatory requirements are aligned with Agile practices. In addition, the document also provides ample information on the basic values of Agile as well as regulatory principles in defining a quality management system. Having understood the underlying principles, users of the Agile methodology can gain more confidence in adapting Agile strategies to their specific environments without jeopardizing compliance.
Further guidance on design inputs and design outputs in TIR45 helps developers distinguish between these often confusing categories (as in an Agile environment, the two do not exist in isolation). User stories, along with their defined acceptance criteria, are design inputs. The document also emphasizes the importance of non-functional requirements in user stories. TIR45 lists all the other artifacts as design outputs, specifically: architecture and design elements, code, as well as test cases and their results.
Benefits of adopting Agile in medtech development
Overall, TIR45 recommends that the organization produces a stable architecture early on in the process. The document also emphasizes the importance of design reviews at the end of each increment (and at releases), and frequent retrospectives to drive continuous learning. These both contribute to the enhanced product quality that is considered one of the fundamental benefits of using Agile.
Continuous testing helps make accurate estimations on product quality on the go, even as customer feedback is incorporated continuously due to the rapid reaction enabled by the Agile way of working. Enhancing and prioritizing the backlog throughout development makes for closer alignment with customer or market requirements, even when they're changing as development progresses. And finally, a clear and well-described Definition of Done that requires adequate documentation both enhances quality management and increases the rigour necessary for successfully tackling compliance audits.
In order to ensure adequate documentation and control over all lifecycle processes in an Agile environment, medtech development teams rely on smart tools. Intland Software's codeBeamer ALM is an integrated Application Lifecycle Management platform for medical device developers that offers full Agile support, enhanced collaboration in an accelerated environment, and automated documentation to help you assert compliance with medical regulations. Give it a try or contact us for more info!