Agile and Medical Device Software Kelly Weyrauch – Medtronic - AAMI Agile TIR Committee

Topics AAMI Technical Information Report Align Agile Values with regulated Values Add Agile to an existing, robust, effective Quality Management System Align Agile's Incremental/Evolutionary lifecycle with (mis)expectations of more Linear models What does the FDA think of Agile? Challenges unique to Medical Device Software Continuous Release Myths, misperception, miscommunication, and mistakes Others?

Using Agile for Medical Device Software You Can Agile TIR You Should Benefits not unique to Medical Device Software Productivity, Predictability, Team Intangibles Benefits for Medical Device Software Emphasis on User Needs and Intended Use Test-Driven Development Team discipline, responsibility for continuous improvement of the development process

Technical Information Report: Guidance on the Use of Agile Practices in the Development of Medical Device Software

The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. The FDA does not have singular or specific written manifesto that is simply focused on medical device software. The FDA regulates medical device software as an integral part of a well structured set of laws, regulations and guidances. Manifesto for Agile Software Development, www.agilemanifesto.org

Design Controls FDA Design Control Guidance For Medical Device Manufacturers

Aligning Agile with a Quality Management System Add Agile to an existing Quality Management System Agile by itself is insufficient Don’t disrupt the existing system Avoid raising undue concerns “Don’t tell us you are using Agile, we don’t need to know” Agile practices insufficient Need Risk Management, Configuration Management Change Control

IEC 62304: Medical device software – Software life cycle processes 7 Software Risk Management 8 Software Configuration Management 5.1 SW Development Planning 5.1 SW Requirements Analysis 5.1 SW Architectural Design 5.1 SW Detailed Design 5.1 SW Unit Implement. & Verification 5.1 SW System Testing 5.1 SW Release 9 Software Problem Resolution

Mapping 62304’s activities… 5.1 SW Development Planning 5.1 SW Development Planning 5.1 SW Development Planning 5.1 SW Development Planning 5.1 SW Development Planning 5.2 SW Requirements Analysis 5.2 SW Requirements Analysis 5.3 SW Architectural Design 5.3 SW Architectural Design 5.4 SW Detailed Design 5.4 SW Detailed Design 5.5 SW Unit Implement. & Verification 5.5 SW Unit Implement. & Verif 5.6 SW Integration and Integr. Testing 5.6 SW Integration and Integr. Testing 5.6 SW Integration and Integr. Testing 5.6 SW Integration and Integr. Testing 5.7 SW System Testing 5.7 SW System Testing 5.7 SW System Testing 5.8 SW Release 5.8 SW Release 5.3 SW Architectural Design 5.2 SW Requirements Analysis 5.7 SW System Testing …into Agile’s Incremental/Evolutionary life cycle For Each Project 5.1 SW Development Planning - Project 5.2 SW Requirements Analysis – High-Level, Backlog Management 5.3 SW Architectural Design – Infrastructure, Spikes For Each Release 5.1 SW Development Planning - Release 5.6 SW Integration and Integration Testing For Each Increment 5.1 SW Development Planning - Increment But 62304 provides a Software Development Process Model, addressing Lifecycle activities. Even it does not 5.6 SW Integration and Integration Testing For Each Story More Releases … 5.1 SW Development Planning - Story 5.7 SW System Testing & Regression Testing 5.2 SW Requirements Analysis – Story Details More stories … More Increments … 5.3 SW Architectural Design - Emergent 5.7 SW System Testing & Regression Testing 5.4 SW Detailed Design 5.5 SW Unit Implementation and Verification 5.8 SW Release 5.6 SW Integration and Integration Testing 5.7 SW System Testing

What does the FDA think of Agile? The FDA does not prohibit or encourage the use of any specific software development methodology Based on the intended use of the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software lifecycle. [GPSV: Page 1 General Principles of Software Validation: Final Guidance for Industry and FDA Staff] The FDA does not prohibit the use of Agile

What does the FDA think of Agile? They have indicated some expected characteristics of the selected software lifecycle The quality system requirements do not dictate the types of design process that a manufacturer must use. Manufacturers should use processes best suited to their needs. However, whatever the processes may be, it is important that the design controls are applied in an appropriate manner. [Design Control Guidance for Medical Device Manufacturers] FDA believes that Agile Methods can be tailored for use in a regulated environment

What does the FDA think of Agile? Demonstrate that you satisfy Design Controls, be in control Explain what you do Demonstrate that you do it Don’t use Agile as an excuse to not do something

Challenges Frequent Releases When software is part of a larger system Regulatory cycles Field updates

Challenges Myths, misperception, miscommunication, and mistakes “Doctor, it hurts when I go like this…”

Agile and Medical Device Software Kelly Weyrauch kelly.weyrauch@medtronic.com 763-688-0980 kdccf@comcast.net