Appropriate Use of Agile in Medical Device Software Development

Transcription

1 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 Next Steps Deploying Agile in your Organization 1

2 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 2

3 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 3

4 Overview - Status of the TIR Work began early st draft 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 Next Steps Deploying Agile in your Organization 4

5 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 Practice to do or perform often, customarily or habitually 5

6 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 6

7 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

8 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 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. 8

9 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 FDA values safety value add 9

10 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, 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. 10

11 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 11

12 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. 12

13 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 13

14 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 14

15 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 15

16 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) 16

17 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 17

18 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 Next Steps Deploying Agile in your Organization 18

19 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 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 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 things on the left 19

20 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 Next Steps Deploying Agile in your Organization 20

21 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 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 21

22 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 Use Agile s practices to manage both business and safety risk 22

23 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 Measure outcomes and continuously improve 23

24 Questions? Speaker Contact Information David Walker David Walker SPCS, LLC