Recently we came across a wonderful work of Dr.

Aami Tir45 Software AAMI TIR45

Jochen Jger (Roche) and his colleagues about Guidance on the use of AGILE practices in the development of medical device software AAMI TIR45:2012.

This publicly available Technical Information Report (TIR) by the Association of Advancement of Medical Instrumentation (AAMI) lays out the agile manifesto, several practices (e.g.

Definition of Done), its application and tailoring in relation to reference models like IEC 62304, ISO 13485, ISO 14971 and FDA CFR, Title 21, Part 820.30.

With this recommendation, I would like to spread the word about scaled agility and agile practices in the development of medical device software.

The TIR describes that agile principles and development have become an accepted method for developing complex systems and software products.

Also, that there have been questions and discussions from both manufacturers and regulators as to whether (or which) agile practices are appropriate to develop medical device software.

As enough medical device manufacturers have implemented agile practices in their software development to answer such questions; the answers have been documented in this TIR.

It documents guidance of which practices have been found appropriate and useful; serving developers of medical device software.

We were happily surprised to find people from the industry (authors of the TIR) sharing our understanding, that agile and regulated perspectives share the same goals of quality and the satisfaction of customers.

As the TIR points out, agile and regulated perspectives have differences in emphasis on development productivity and predictability, but this does not make them incompatible.

This recommends TIR also discusses the values of the agile manifesto, e.g.

Aami Tir45 How To Fulfill Such

Individuals and interactions over process and tools and concludes with recommendations on how to fulfill such values in regulated environments.

Another good example which we liked very much is the chapter about Customer collaboration over contract negotiation.

As described, it is key in agile to recognize that collaboration with an engaged customer in the development process is more likely to deliver software that meets the customers needs then based on contracts.

Consistent with an incrementalevolutionary lifecycle, the emphasis on customer collaboration means also that softwares definition will evolve over time.

The paper describes that it is normal and good practice, that some high-level definition will exist to varying degrees before the development begins, but most of the detailed definition and even some high-level definition will emerge as the development work proceeds.

As recognized in the TIR, this might be uncomfortable for manufacturers and regulators who are more familiar with big upfront definitions models in which definition work is more complete before software development begins.

The TIR concludes, that it is important for the development teams to explain how the definition will emerge and how that definition emerges in a controlled way.

Such considerations are also reflected in Applied SAFe and we recommend to work with Skeleton Requirements and different processes of contracting with suppliers, depending on the working model of the supplier, e.g.

This section talks about alignment, customization, and adoption of lifecycles, it provides recommendations on how to align agile and regulatory perspectives in a supportive manner; something that we also have implemented in Applied SAFe.

PEDCO strongly recommends this paper if you are interested in an unbiased view on agile and to truly establish scaled agility in a medical device development environment.

You can read a preview of the TIR45 FDA recognition statement: Purchase TIR45 (PEDCO has no connection or interest on selling this paper) This TIR provides perspectives on the application of AGILE during medical device software development.

It relates them to the following existing standards, regulations, and guidance: ISO 13485:2003, Quality management systems Requirements for regulatory purposes IEC 62304, Medical device software Software lifecycle processes ISO 14971:2007, Medical devices Application of risk management to medical devices FDA Code of Federal Regulations (CFR), Title 21, Part 820.30, Quality System Regulation: Design Controls FDA Guidance for the content of premarket submissions for software contained in medical devices FDA General principles of software validation; Final guidance for industry and FDA staff Why read this TIR (excerpt from AAMI TIR45:2012) AGILE was developed in response to quality and efficiency concerns posed by existing methods of software development.

It can bring benefits that are valuable to the medical device software world, including the following: Continuous focus on safety, risk management, and delivering customer value through BACKLOG prioritization, planning practices, and customer feedback Continuous assessment of quality through continuous integration and testing Continuous improvement of the software development process through RETROSPECTIVE s and team accountability Continuous focus on getting to DONE and satisfying quality management stakeholders through the regular completion of activities and deliverables AGILE can bring value to medical device software.

There are concerns about AGILE s compatibility with the regulated world of medical device software development.

For example, the AGILE Manifesto has value statements that seem contrary to the values of a quality management system; and because AGILE initially grew from the information-technology space where human safety and risk management were not of primary importance, there is concern that AGILE lacks the proper controls for producing safety-critical software.

Aami Tir45 Pdf