Appropriate Use of Agile in Medical
Device Software Development
Presented May 18, 2011
Software Division & Biomedical Division Joint Session David Walker
Member, AAMI Agile TIR Working Group
Agenda
• Overview
• Regulatory Goals, Values and Principles • Agile Goals, Values and Principles
• Overview of TIR Structure and Content • Key Takeaways
Overview - Agile Overview and Misconceptions • Agile was born out of frustration with the traditional document focused,
waterfall method
• Agile started out being applied to niche markets but now has become a widely accepted software development method
• Agile brings value to medical device software: continuous focus on safety, risk management, quality…
• The Agile Manifesto may appear to be contrary to the values of a quality management system
• Technical Information Report (TIR) explains how to tailor Agile methods for use in a regulated environment
Overview – Agile TIR Task Group
• AAMI – Association for the Advancement of Medical Instrumentation
– Nonprofit organization founded in 1967 – ~6000 members worldwide
– AAMI administrates almost 300 medical device standards committees
– Dedicated to increasing the understanding and beneficial use of medical instrumentation through effective standards, educational programs, and publications
– AAMI Medical Device Software Committee is sponsor of the Agile TIR Task Group
Agile TIR Task Group Members 1 of 2
Name Title Entity
Richard Chapman Branch Chief GHDB FDA
Sherman Eagles Partner SoftwareCPR
Brian Fitzgerald Deputy Director OSEL FDA
Jochen Jäger Dept. Project Leader Sw. Dev. Roche Diagnostics Ltd Patricia Krantz CRDM Standards Advisor Medtronic, Inc Mary Beth McDonald Director, Software Quality Assurance St. Jude Medical John Murray Software Compliance Expert FDA
Brian Pate Partner SoftwareCPR
Bakul Patel Policy Advisor FDA
Lori Pope Director, Software Development St. Jude Medical
Agile TIR Task Group Members 2 of 2
Name Title Entity
Michael Robkin President Anakena Solutions Victor Rodrigues Head of Audiological Software Cochlear Ltd Mike Russell Agile Transformer Leader SoftwareCPR
John Schmidt Director of Firmware Development Boston Scientific Corporation Rick Schrenker Systems Engineering Manager Massachusetts General Hospital Greg Urquhart Group Leader – Applications Toshiba Med. Visualization Systems Marta Walker Quality Assurance /Reg. Affairs Mgr Nucletron AB
David Walker Independent Consultant David Walker SPCS, LLC Kelly Weyrauch Senior Principal Software Engineer Medtronic, Inc
Overview - Status of the TIR
• Work began early 2010
• 1stdraft for AAMI Medical Device Software Standards
Committee review June 2011
• TIR Publication expected by end of 2011
Agenda
• Overview
• Regulatory Goals, Values and Principles
John Murray – Software Compliance Expert, FDA
• Agile Goals, Values and Principles • Overview of TIR Structure and Content • Key Takeaways
Educational Material
• Illuminating/Illustrative • Not all inclusive
• Not formal policy/ guidance or regulation • Designed to focus your thinking process • You will need to go back to study and use
the source regulatory documents
Context References
• Goal the end toward which effort is directed
• Principle a comprehensive and fundamental law or assumption • Value relative worth, utility or importance
FDA Manifesto
• 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
What does FDA think about Agile?
• The Agile Manifesto is represented by a set of goals, perspectives etc
• Figuratively speaking the FDA’s manifesto is represented by a set of laws, regulations and guidances
• Understanding these FDA elements can allow the Agile Practitioner to create compliant medical device software using Agile Methodologies
Is Agile Acceptable?
• The FDA does not prohibit or encourage the use of any specific software development
methodology. They have indicated some
expected characteristics of the selected software lifecycle and development. [GPSV]
• FDA Does not prohibit the use of Agile
• FDA believes that Agile Methods can be tailored for use in a regulated environment
Principle - Regulatory Perspective
• The Federal Food, Drug, and Cosmetic Act (FD&C Act) is a federal law enacted by Congress. It and other federal laws
establish the legal framework within which FDA operates. The FD&C Act can be
found in the United States Code, which contains all general and permanent U.S. laws, beginning at 21 U.S.C. 301
Goal - Protecting
• The FDA is responsible for protecting the public health by assuring the safety,
efficacy, and security of human and veterinary drugs, biological products,
medical devices, our nation’s food supply, cosmetics, and products that emit radiation
http://www.fda.gov/AboutFDA/Transparency/Basics/ucm192695.htm
Goal - Advancing
The FDA is also responsible for advancing the public health by helping to speed innovations that make medicines and foods more effective, safer, and more affordable; and helping the public get the accurate, science-based information they need to use medicines and foods to improve their health supports, or at least, encourages productivity ... it is in the best interest of public health.
Value - Focused on Control
• Regulatory Controls increase from Class I to Class III
• General Controls, Special Controls and Pre market applications
• The regulatory system relies upon
management control, professional work and professional training
• Control of the design to ensure a predictable outcome
Value - The Concept
• FDA is not focused on individual interactions or decision making
• QS preamble state principles embodied have been accepted world wide
• The FDA rules are more focused on group practices, principle and controls
Federal Food, Drug, and Cosmetic Act
• The basic framework governing the regulation of medical devices is established in the Medical Device
Amendments to the Federal Food, Drug, and Cosmetic (FFD&C) Act. The Medical Device Amendments were enacted on May 28, 1976.
Practice - Legislation to Regulations
• FDA develops regulations based on the laws set forth in the FD&C Act or other laws under which FDA operates. FDA follows the procedures required by the Administrative Procedure Act, another federal law, to issue FDA regulations. This typically involves a process known as
"notice and comment rulemaking" that allows for public input on a proposed regulation before FDA issues a final regulation. FDA regulations are also federal laws, but they are not part of the FD&C Act.
Principle - Guidance Documents
• In an effort to describe the agency’s current thinking on the law or the regulations the FDA frequently publishes Guidance Documents. FDA follows the procedures required by its "Good Guidance Practice" regulation to issue FDA guidance. Guidance is not legally binding on the public or FDA. The guidance’s provide insight and knowledge about how certain regulations need to applied to medical devices and medical device software.
Regulatory Impact on Software
• Reading from the law, regulations and guidances you quickly discover the major regulatory principles that can have an impact on medical device software • Let us review some of those
Principle - Life Cycle Control
• 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 life cycle. [GPSV]
Value - Design Control is not Design
• Based on the intended use and 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. [GPSV]
• This guidance recommends an integration of software life cycle management and risk management activities.
Principle - Software Validation
• Software validation is a part of the design validation for a finished device
• FDA considers software validation to be
"confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled." • In practice, software validation activities may
occur both during, as well as at the end of the software development life cycle to ensure that all requirements have been fulfilled.
Principle
–
The Sum of the Parts
• A conclusion that software is validated is highly dependent upon comprehensive software testing, inspections, analyses, and other verification tasks performed at each stage of the software development life cycle
All medical device software
• Must be designed and developed in compliance with the Quality System Regulation 21 CFR 820 • There are 3 very specific elements of the Quality
System Regulations that can have a direct impact on the use of Agile Methodology
– 21 CFR 820 Subpart C Design controls – 21 CFR 820 Subpart J Corrective and
preventive action
– 21 CFR 820 Subpart M Records • These are just the primary issues
The Quality System Requirements
• Designed to be independent of the design methodology that is chosen or the product or software lifecycle that is applied
• Under the law the medical device software Agile Practitioner must still meet the regulatory
requirements
• Appendix XX of the Agile TIR contains a list of important regulatory requirements that every Medical Device Software Agile Practitioner must establish compliance with
Value - Establish & Ensure
• Procedures to control the design of the device in order to ensure that specified design requirements are met
Principle - Design Control
• Interrelated set of practices and
procedures that are incorporated into the design and development process, i.e., a system of checks and balances
• Systematic assessment of the design an integral part of development
• Increased likelihood that the design
transferred to production will translate into a device that is appropriate for its intended use
Design and development planning
• Describe or reference the design and development activities and define responsibility for implementation
• Identify and describe the interfaces with different groups or activities that provide, input to the design and development process
• Review, update, and approve as design and development evolves
Design review
• Documented reviews of the design results are planned and conducted at appropriate stages
• Design reviews include representatives of all functions concerned with the design stage being reviewed, as well as any specialists needed
• The results of a design reviews shall be documented in the design history file (the DHF)
Design transfer
• Procedures to ensure that the device design is correctly translated into production specifications
Design changes
• Procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation
Appendix
XX
• The previous slides contained a sample list of regulatory requirements
• The TIR Appendix will contain a more detailed list either in the form of infinite detail or detailed references or some combination of both
Agenda
• Overview
• Regulatory Goals, Values and Principles
• Agile Goals, Values and Principles
• Overview of TIR Structure and Content • Key Takeaways
Agile Goals
• Agile’s goals: Eliminate the risk inherent in traditional waterfall methods – Processes that did not respond well to changing business needs
– Low visibility into actual project progress
• Focus on Quality– the correctness of the product
• Improve on Productivity– efficiency and speed of development, while reducing development cost
• Improve Predictability– through estimation and planning
• Product Effectiveness– through defined roles and continual feedback
Align the goals of Quality, Productivity, Predictability, and Effectiveness to be supportive of one another
Agile Values - 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 interactionsover processes and tools Working softwareover comprehensive documentation Customer collaborationover contract negotiation Responding to changeover following a plan
That is, while there is value in the items on the right we value the items on the left more http://www.agilemanifesto.org
Find the proper balance between the left and the right not by diminishing the value of the things on the right but by enhancing the value of the
Agile Principles
• Agile principles we feel are important and apply to the context of Medical Device Software that will be addressed by this TIR.
– Apply incremental and evolutionary life cycle;with increments being as short a week and evolution happening as late as the last increment before a product is shipped
– Define what “done” means; define Doneness to include the requirements of the QMS that must be satisfied
– Deliver customer value; frequent customer interaction/validation provides feedback on usability and safety of the product.
– Manage business and safety risk; use Agile’s practices to manage both business risk and safety risk: team collaboration to focus on a robust and safe design, doneness criteria to ensure items related to schedule and safety risk management are completed
– Reflect at regular intervals; adapt the process to constantly improve quality and efficiency of work
Agenda
• Overview
• Regulatory Goals, Values and Principles • Agile Goals, Values and Principles
• Overview of TIR Structure and Content
• Key Takeaways
TIR Structure and Content
• Title: Guidance on the use of Agile Practices in the Development of Medical Device Software
• Introduces the 2 perspectives, Regulatory and Agile • 4 major sections in the structure:
– Aligning on Goals – Aligning on Values – Aligning on Principles – Aligning on Practices
TIR Structure and Content
• TIR aggregates practices from various agile methods that may be particularly confusing to determine how to apply to medical device software development. This is the heart of the TIR
• Practices consider FDA’s QSR, General Principles of Software Validation (GPSV) and IEC 62304
– Topics related to Planning, Documentation, Design Reviews, Product Definition/Requirements, Software Architecture, Detailed Design, Implementation and Unit Verification
– Techniques such as Pair Programming as the design review technique and Test Driven Development as a verification technique and user stories as a product definition technique
Agenda
• Overview
• Regulatory Goals, Values and Principles • Agile Goals, Values and Principles
• Overview of TIR Structure and Content
• Key Takeaways
• Next Steps – Deploying Agile in your Organization
Key Takeaways
• Agile brings value to medical device software
• Agile can be adapted to unique needs of medical device software • Agile should be applied within the context of a Quality Management
System
• Key Takeaways are points of notable interest throughout the TIR (DOs and DON’Ts)
– Produce documentation that has business value – Define the lifecycle model
– Define Doneness to include the requirements of the Quality Management System that must be satisfied
Agenda
• Overview
• Regulatory Goals, Values and Principles • Agile Goals, Values and Principles
• Overview of TIR Structure and Content • Key Takeaways
• Next Steps – Deploying Agile in your Organization
Next Steps - Deploying Agile in your Organization
• Create a strategy and a plan for introducing Agile practices into the existing Quality Management System
– Assess existing quality management system
– Select agile practices to be adopted and create a plan – Train the development team and management
– Apply the new process on one project, then deploy to others – Monitor deployment and provide support
Questions?
Speaker Contact Information
David Walker
David Walker SPCS, LLC
[email protected] www.davidwalkerspcs.com
