November 2022 Newsletter – Adapting to the Rapid Pace of Software Innovation
Agile Medical Software Development
Software is key to many innovative new solutions in healthcare but often medical device companies struggle with adopting modern methods for software development. Traditional approaches to medical device development are hardware focused and this is often reflected in our quality systems and our organizational habits. How can we leverage agile methods for development of medical software while staying compliant?
- First, make sure your design control procedures support agile development
- Second, make sure your software team understands design controls
- Third, leverage software tools to efficiently manage product data and generate compliance documents (“Documentation Automation”). With rapidly changing software there’s no time for manually editing every document! Don’t Rely on Documents to Manage Your Documentation
Many medical device companies hesitate to adopt modern software tools because they think it will be too time-consuming to validate them. However, the time spent upfront on validating software tools is easily recouped by time savings for years afterward. And there’s good news on this front: FDA recently issued new draft guidance on what they consider the appropriate level of validation for different software tools (AKA Computer System Validation AKA Non-Product Software Validation).
The new FDA draft guidance clarifies and simplifies requirements for many types of software and provides a more flexible, risk-based approach to validation. These are some key points of the guidance:
- Separates “High Process Risk” software from other software, where high process risk means software defects can directly affect medical device quality (i.e., software used in manufacturing or related processes); other software, such as CAPA management software, is considered lower risk for validation
- Describes various methods and testing activities for software validation, including unscripted testing for low risk software
- Includes multiple examples of software validation (high and low risk)
When finalized, the new guidance will serve as a supplement to the 2002 guidance “General Principles of Software Validation” (except it will supersede Section 6 of the 2002 guidance).
Software Documentation in FDA Submissions
FDA is changing its guidance on what’s required in software premarket submissions. When final, the new guidance will replace FDA’s Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices issued on May 11, 2005. The new draft guidance is quite different from the 2005 guidance. Here are some key changes in it:
- The documentation will no longer be determined by software Level of Concern (Minor / Moderate / Major); instead, it will be determined as needing Basic or Enhanced level of documentation (based on the software’s risk). The Enhanced level is required if any of the following apply:
- Class III or combination device
- Device tests blood donations or determines donor-recipient blood compatibility.
- Device software functions could present a probable risk of death or serious injury (pre-mitigations)
- The Device Hazard Analysis is replaced by the device’s Risk Management File documents.
- The new guidance allows for the declaration of conformity to the IEC 62304 medical software standard.
- The new guidance has more explanations of what is required in each type of software document, such as the software architectural design.
Notable Changes in the new FDA Draft Guidance – good summary from the Jama Software blog (JUL 2022)
FDA Issues a Draft Guidance for Content of Premarket Software Submissions – more detailed discussion by Lisa Baumhardt on the FDA Law Blog (NOV 2021)
Common Deficiencies with Software Documentation in FDA Submissions – lots of practical guidance on what not to do in this presentation by Kevin Go and Hrishikesh Gadagkar of RQM+
Design Controls Gone Bad – Part 2
Nobody sets out to write design control procedures that undermine product development but unfortunately that’s the situation I’ve observed at many medical device companies. In this blog post I continue the list of ways that your quality system can undermine your product teams (part 2 of 2).
November 29-30, 2022 in San Jose, California
March 29, 2023 at San Jose State University, San Jose, California