Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

FDA software compliance 2016


Published on

The FDA recommends implementing a coding standard during medical device software development. In practice, this means running a static analysis tool to detect any problematic constructs that could lead to problems down the road.

But if you think you can simply download an analyzer and go, you might consider that the FDA requires documented details associated with code quality activities.

What standard are you going to check against? What rules in the analyzer cover the standard? Which rules are you suppressing? The implementation of static analysis is enough to cause headaches, gastrointestinal discomfort, and other side-effects.

This webinar prescribes some static analysis implementation best practices to relieve your FDA compliance symptoms, including:

The benefits of static analysis and what to look for in an analyzer
How to automate static analysis execution
How to integrate static analysis within your software development processes.
How to reduce noise and stop wasting time manually triaging results

Published in: Healthcare
  • The #1 Woodworking Resource With Over 16,000 Plans, Download 50 FREE Plans... ★★★
    Are you sure you want to  Yes  No
    Your message goes here
  • Want to preview some of our plans? You can get 50 Woodworking Plans and a 440-Page "The Art of Woodworking" Book... Absolutely FREE 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

FDA software compliance 2016

  1. 1. Parasoft Corporation © 2016 1 2016-08-27 Rx for FDA Software Compliance August 2016
  2. 2. Parasoft Corporation © 2016 22 Open and hide your control panel Join audio: • Choose “Mic & Speakers” to use VoIP • Choose “Telephone” and dial using the information provided Submit questions and comments via the Questions panel Note: Today’s presentation is being recorded and will be provided within 48 hours. Your Participation GoToWebinar Housekeeping
  3. 3. Parasoft Corporation © 2016 33 Your Presenters Arthur Hicken is Chief Evangelist at Parasoft where he has been involved in automating various software development and testing practices for over 20 years. He has worked on projects including cybersecurity, database development, the software development lifecycle, web publishing and monitoring, and integration with legacy systems. Follow him on Twitter @codecurmudgeon Kelly Weyrauch has more than 30 years of software and systems development experience, and 20 years of focus on software processes and quality systems for medical devices. As an independent consultant, he works with software and systems creators to apply Agile concepts and Quality Management System requirements to the unique context of their development environment. Follow him on LinkedIn @kellyweyrauch
  4. 4. Parasoft Corporation © 2016 44 Agenda What the FDA expects IEC 62304 Benefits of static analysis How to integrate static analysis How to reduce noise and stop wasting time
  5. 5. Parasoft Corporation © 2016 5 2016-08-27 Introduction to Medical Device Software Regulations Where do Static Analysis Tools fit in? Kelly Weyrauch – Agile Quality Systems LLC
  6. 6. Parasoft Corporation © 2016 6  Software as a Medical Device  Software-only  Part of a medical device system  Software used to develop/manufacture/manage a device  Development environments & tools  Automated test systems  Manufacturing systems  …  Quality Management System tools  CAPA & Issue Tracking systems  Complaint handling systems  Document Control  … Scope of Software Regulations (c) Agile Quality Systems 2016
  7. 7. Parasoft Corporation © 2016 7  21 CFR 820  Quality System Regulation  820.30 Design Controls  21 CFR 11  Electronic Records; Electronic Signatures  ISO 13485  Medical devices— Quality management systems  Section 7 – Product Realization  IEC 62304  Medical device software— Software life cycle processes  ISO 14971  Medical devices — Application of risk management to medical devices Software Development Regulations and Standards (c) Agile Quality Systems 2016
  8. 8. Parasoft Corporation © 2016 8  GPSV  General Principles of Software Validation (FDA)  AAMI TIR45:2012  Guidance on the Use of AGILE Practices in the Development of Medical Device Software  AAMI TIR36:2007  Validation of software for regulated processes  Many other, more specialized standards & guidance documents Software Development Guidance (c) Agile Quality Systems 2016
  9. 9. Parasoft Corporation © 2016 9  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.  FDA is also responsible for advancing the public health by helping to speed innovations that make medicines more effective, safer, and more affordable and by helping the public get the accurate, science-based information they need to use medicines and foods to maintain and improve their health. …  ... (  Same things Industry wants!  Industry & Regulatory should align on the same goals  Requires effort to show they are aligned FDA Mission Statement (c) Agile Quality Systems 2016
  10. 10. Parasoft Corporation © 2016 10  Satisfying regulatory expectations should be a natural result of doing good work  Should not be viewed as  Adversarial  Conflicting  Bureaucratic  Legalistic  Impractical  Offensive to your engineering sensibilities  … Industry & Regulatory Alignment (c) Agile Quality Systems 2016
  11. 11. Parasoft Corporation © 2016 12  21 CFR 820 mentions software only 3 times  820.30(g) Design Controls: Design Validation  “Design validation shall include software validation and risk analysis, where appropriate.” (No definition of what “Software Validation” means.)  820.70(i) Production & Process Controls: Automated Processes  “When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol.”  820.181(a) Device Master Record  “Device specifications including … software specifications”  Software “requirements” (expectations) come from Guidance Documents  General Principles of Software Validation (GPSV)  Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices  Others FDA Software Regulations (c) Agile Quality Systems 2016
  12. 12. Parasoft Corporation © 2016 13  Regulators often not experienced with software  For software as a medical device, may bring bias of hardware-development experience, especially with assumptions of a linear lifecycle  For software tools, may bring bias of manufacturing systems  So you should be the software expert  Showing how your process satisfies regulations FDA Software Regulations (c) Agile Quality Systems 2016
  13. 13. Parasoft Corporation © 2016 14  Explain what you do  In Processes and Plans  Demonstrate that you do it  By producing adequate records  “Demonstrate” may seem like non-value- added burden  Especially to those doing the work  Necessary, so find ways to optimize the value/cost, to avoid the perception of “burden” Be In Control, Show That You Are In Control (c) Agile Quality Systems 2016
  14. 14. Parasoft Corporation © 2016 16  …Is ALWAYS a lousy reason  Too simple  Offloads responsibility for owning our process  Often a cover for another argument, usually one that is not well thought out and probably dysfunctional  We own our process (and the FDA does say that)  But regulators are stakeholders to be satisfied  Satisfy ourselves that your process is good, and the regulators will be satisfied “Cuz the FDA Said So…” (c) Agile Quality Systems 2016
  15. 15. Parasoft Corporation © 2016 17  Build a good product  Safe & Effective  Have a good process for building that product  Do good work  With evidence of that good work  Tell a good story that will convince anyone  Why you think your product is good  Why you think your process is good  That you know what you are doing Keys To Success (c) Agile Quality Systems 2016
  16. 16. Parasoft Corporation © 2016 18  Specifically created for medical device software  Though many elements are foundational to any robust software development process IEC 62304 (c) Agile Quality Systems 2016
  17. 17. Parasoft Corporation © 2016 19  A framework – processes, activities and tasks  Identifies requirements for  What needs to be done  What needs to be documented  Software only  Assumes software is part of a broader system that defines higher-level activities for design inputs and design (product) validation IEC 62304 – What it is (c) Agile Quality Systems 2016
  18. 18. Parasoft Corporation © 2016 20  Does not prescribe how to meet the requirements  Not a “how to” with defined methods or practices  Does not require a specific software life cycle  Does not specify documents  Says what to document, not where it must go.  These decisions are left to you IEC 62304 – What it isn’t (c) Agile Quality Systems 2016
  19. 19. Parasoft Corporation © 2016 2121 IEC 62304 Medical Device Software – Software Life Cycle Processes (c) Agile Quality Systems 2016 SYSTEM development ACTIVITIES (including RISK MANAGEMENT) Customer needs Customer needs satisfied 7 Software RISK MANAGEMENT 8 Software configuration management 9 Software problem resolution Activities outside the scope of this standard 5.2 Software requirements analysis 5.1 Software development planning 5.8 Software release 5.7 Software SYSTEM testing 5.3 Software ARCHITECTURAL design 5.4 Software detailed design 5.6 Software integration and integration testing 5.5 Software UNIT implementation
  20. 20. Parasoft Corporation © 2016 22  Mentioned briefly in FDA General Principles of Software Validation, 2002  In 2000’s, driven largely by concerns over the high failure rate in infusion pump systems & software, FDA recognizes value in using Static Analysis techniques to reduce software errors  Often an “expectation” in submissions and quality system inspections Static Analysis (c) Agile Quality Systems 2016
  21. 21. Parasoft Corporation © 2016 2323 Software Unit Implementation (c) Agile Quality Systems 2016 SYSTEM development ACTIVITIES (including RISK MANAGEMENT) Customer needs Customer needs satisfied 7 Software RISK MANAGEMENT 8 Software configuration management 9 Software problem resolution Activities outside the scope of this standard 5.2 Software requirements analysis 5.1 Software development planning 5.8 Software release 5.7 Software SYSTEM testing 5.3 Software ARCHITECTURAL design 5.4 Software detailed design 5.6 Software integration and integration testing 5.5 Software UNIT implementation
  22. 22. Parasoft Corporation © 2016 24  Implement software units – write the code  Establish acceptance criteria for software units  Coding Standards are a “should have” (defined in the Plan)  Establish strategies, methods and procedures for verifying each software unit  Reviews  Static Analysis  Unit Tests  Address this in the Verification Strategy section of the Plan  Perform and document results of software unit verification  According to the strategies and methods  Does not require all software units to be tested Software Unit Implementation (c) Agile Quality Systems 2016
  23. 23. Parasoft Corporation © 2016 2525 Software Integration and Integration Testing (c) Agile Quality Systems 2016 SYSTEM development ACTIVITIES (including RISK MANAGEMENT) Customer needs Customer needs satisfied 7 Software RISK MANAGEMENT 8 Software configuration management 9 Software problem resolution Activities outside the scope of this standard 5.2 Software requirements analysis 5.1 Software development planning 5.8 Software release 5.7 Software SYSTEM testing 5.3 Software ARCHITECTURAL design 5.4 Software detailed design 5.6 Software integration and integration testing 5.5 Software UNIT implementation
  24. 24. Parasoft Corporation © 2016 26  Integrate the software units (build the software system)  Verify that software units have been integrated (build was successful)  Review of build procedures, make-files, configurations, etc.  Compiler checks, static analysis, etc.  Test integrated software system performs as expected in accordance with plan  Functionality, behavior, performance, etc  Regression tests  Document test results  Can be done as part of software system testing (see later slide)  Capture problems (software problem resolution process) Software Integration and Integration Testing (c) Agile Quality Systems 2016
  25. 25. Parasoft Corporation © 2016 27  Define in your Software Development Procedure/Processes:  Strategy for using Static Analysis as a part of your overall verification strategy  Requirements for how and when to use it  As part of code (unit-level) verification  As part of integration verification Recommendation for use of Static Analysis (c) Agile Quality Systems 2016
  26. 26. Parasoft Corporation © 2016 28  Kelly Weyrauch   763-688-0980   Connect with me on LinkedIn Contact Information (c) Agile Quality Systems 2016
  27. 27. Parasoft Corporation © 2016 2929 Recalls due to Software Failure ProductsandTobacco/CDRH/CDRHReports/UCM308208.pdf
  28. 28. Parasoft Corporation © 2016 3030 FDA on Static Analysis 3.1.2 “Software testing is one of many verification activities intended to confirm that software development output meets its input requirements. Other verification activities include various static and dynamic analyses, code and document inspections, walkthroughs, and other techniques.” 5.2.4 “Source code should be evaluated to verify its compliance with specified coding guidelines.” General Principles of Software Validation; Final Guidance for Industry and FDA Staff
  29. 29. Parasoft Corporation © 2016 3131 What Choice  Prevent Defect Insertion Quality System Design Control Risk Management  Remove Defects by Detection Code Review Design Review Testing: unit, integration, system, alpha, beta Customer Dissatisfaction Recall  Roll the dice John Murray, US FDA, March 2008
  30. 30. Parasoft Corporation © 2016 3232 Fix or Prevent
  31. 31. Parasoft Corporation © 2016 3333 Static analysis is more than detection  Relationship of automated analysis  Preventative static analysis  Flow analysis  Runtime error detection  Uninitialized memory example  Runtime will find it IF the test suite is thorough  Flow analysis may find it depending on complexity  Pattern to prevent: Initialize variables upon declaration  Many standards like MISRA are focused on prevention rather than detection
  32. 32. Parasoft Corporation © 2016 3434 Static analysis – what it can do  Identify defective code - runtime bugs  Flag defect-prone code (possible bugs and “gotchas”)  Suggest defensive programming practices  Monitor application-specific guidelines (e.g. portability)  Enable policy enforcement (security)  Flag unmaintainable / poorly readable / “dialect” code
  33. 33. Parasoft Corporation © 2016 3535 Sample Static Analysis Policy  Which rules run on all code  Which rules run on certain conditions  International, performance, etc  What level of compliance is required  When are suppressions acceptable  Where does SA fit the process
  34. 34. Parasoft Corporation © 2016 3636 Static Analysis Feedback Loop Identify Error Isolate Root Cause Fix New Rule to Prevent Monitor  Code review  Regression  QA  Field bugs
  35. 35. Parasoft Corporation © 2016 3737 How to choose rules  Based on why you’re using static analysis  Study expected issues  Analyze bug-tracking system  Don’t just turn on rules because it’s a good idea  Pick few enough to use sustainably
  36. 36. Parasoft Corporation © 2016 3838 Why MISRA for Medical?  Coding Standards  Well-defined  Updated  Flexible  Deviation Strategy  Auditable  What else would you start with?
  37. 37. Parasoft Corporation © 2016 3939 FDA/MISRA Alignment FDA Guideline MISRA Capability “Least burdensome approach” Lightweight and flexible Company defines standards Proven standards pre-packaged Work must be traceable Provides traceability methodology Process must be auditable Defines auditable reports
  38. 38. Parasoft Corporation © 2016 4040 Sample Rules for FDA Static Analysis  Avoid accessing arrays out of bounds  Avoid use before initialization  Avoid null pointer dereferencing  Avoid overflows due to [various causes]  Avoid division by zero  Ensure deallocation functions guarantee resource freeing  Do not use resources that have been freed  Do not free resources using invalid pointers  Do not abandon unreleased locks  Do not use blocking functions while holding a lock  Ensure resources are freed  Do not abandon unreleased locks  Properly terminate character strings  Never return a reference to a local object
  39. 39. Parasoft Corporation © 2016 4141 Automated static analysis in IDE
  40. 40. Parasoft Corporation © 2016 4242 Intelligent, Actionable Findings
  41. 41. Parasoft Corporation © 2016 4343 Visibility for Compliance  Real-time feedback on compliance and certification with industry, regulatory or standards initiatives upon delivery.
  42. 42. Parasoft Corporation © 2016 4444 Managing and measuring Static Analysis Test management Traceability Multi-discipline results
  43. 43. Parasoft Corporation © 2016 4545 Dashboards Vs Process Intelligence 1970s Electrocardiogram • Isolated data points • No priority • No warnings – just data • No analysis 21st Century Monitor • Multi-variate analysis • Customizable • Critical alerts • Valuable data
  44. 44. Parasoft Corporation © 2016 4646 Harnessing “Big” Data  Aggregate data  Correlate data  Mine data  Create  Reports  Dashboards  Tasks  Alerts  Continuous testing/delivery/release
  45. 45. Parasoft Corporation © 2016 4747 Execution / CI Build Parasoft DTP RawObservations Parasoft Development Testing Platform Static Analysis Engine Testing and Coverage PHPMD API FindBugs API CheckStyle API Other 3rd Party … API Desktop IDE Web UI External SystemRequirements and Defects Source Control Workflow (Task) Intelligence (Dashboards/ Reports) Practice/ Domain Data (REST API) Prioritized Findings Web UI Process Intelligence Engine Policy Management
  46. 46. Parasoft Corporation © 2016 4848 Parasoft Development Testing Platform Optimal Routes Historic Data Road Construction Traffic Conditions Map/Road Data Speed Limits
  47. 47. Parasoft Corporation © 2016 4949 Parasoft DTP Process Intelligence Engine PIE – Derivative (Predictive) Analysis External Systems Application Hotspots Prioritized Actionable Information External Processes 3rd Party System CI/CD/CR Infrastru cture System Monitoring Product FeedbackCustomer Support Code Review Metrics People Code Defect Static Analysis Tests User Stories Coverage Parasoft DTP
  48. 48. Parasoft Corporation © 2016 5050 What can PIE do? What do I test first? Where is the business logic and how testable is it? Test Stability Index; Look at your unstable tests. Identify valuable Tests Find Application Hotspots: Technical Risk vs Business Risk, Technical Debt, Density KPIs, Clusters I made changes, which tests need to be re-run? What is the risk of new code? Did I test the new code changes? Don’t make the problem worse & review existing issues when your working with code
  49. 49. Parasoft Corporation © 2016 5151 Root Cause - Cluster Over 3000 Anti-Patterns Application Under Development Event
  50. 50. Parasoft Corporation © 2016 52 2016-08-27 Real world examples
  51. 51. Parasoft Corporation © 2016 5353 Customer Challenge: Reducing the Burden of Compliance  In order to develop solutions for the pharmaceutical market, a company must not only follow very strict requirements, but also prove that they actually satisfied these rigorous expectations. To achieve this, they must provide evidence that the system is designed, constructed, and tested according to best practices implemented throughout the various phases of the lifecycle.
  52. 52. Parasoft Corporation © 2016 5454 The Solution: Static Analysis with Robust, Easy, Flexible rule set
  53. 53. Parasoft Corporation © 2016 5555 The Benefit: Faster, Easier, Better Documented Compliance  Time saved doing tedious tasks  Better consistency  Easy traceability and auditability  Precisely fit to their needs ”With Parasoft’s solution, previously arduous, boring and difficult-to-document tasks were transformed into tasks that we could perform systematically— in an automated and rapid manner.“
  54. 54. Parasoft Corporation © 2016 5656 Customer Challenge: Streamline Certification for Medical Device Software under IEC 62304 “Our products are used intraoperative. If any failure occurs during an operation, the operation might have to be aborted. Moreover, since we monitor nerves and their signals, incorrect interpretations and decisions made by our software could lead to wrong decisions by the user...and could cause injuries for the patient.” The US FDA accepts IEC 62304 compliance as evidence that medical device software has been designed to an acceptable standard.
  55. 55. Parasoft Corporation © 2016 5757 The Solution: Automating Risk Management Processes with Parasoft  Multiple languages: C, C++, .NET  Integration with existing systems: IDE, bug- tracking, source control
  56. 56. Parasoft Corporation © 2016 5858 The Benefit: Increased Efficiency through Automation “The current level of verification for each requirement task (including task pass/fail status and coverage) is bi-directionally traceable to all associated tests. Full traceability is crucial for IEC compliance. Using the Parasoft solution significantly increases our efficiency because many manual steps could be automated.“
  57. 57. Parasoft Corporation © 2016 5959 Parasoft Support for FDA Static analysis Policy definition management Requirement definition and tracking Unit test Peer review Runtime error detection Coverage
  58. 58. Parasoft Corporation © 2016 6060 Summary Financial and health risks are increasing FDA requires a rigorous mature process Static analysis both provides tight controls and prevents real problems from occuring Proper configuration and deployment reduce common static analysis problems
  59. 59. Parasoft Corporation © 2016 6161 FDA Resources  FDA - “General Principles of Software Validation” ceDocuments/ucm085281.htm …guidance outlines general validation principles that the Food and Drug Administration (FDA) considers to be applicable to the validation of medical device software…  FDA – 21 CFR 820  .cfm?CFRPart=820&showFR=1 …Quality System Regulations  ANSI/AAMI 62304 “Medical device software-Software life cycle processes” …A recommended practice provides guidelines for the use, care, and/or processing of a medical device or system.
  60. 60. Parasoft Corporation © 2016 6262  Blog:  Web:  Facebook:  Twitter: @Parasoft @CodeCurmudgeon  LinkedIn:  Google+ Community: Static Analysis for Fun and Profit IoT API's session - API World - San Jose, CA Sep 13th Managing Auto Supply Chain Risk – Automotive Software Kongress - Germany Sep 21-22 StarWest Conference - Anaheim CA - Oct 5-6