James A. Dunning, CEO, QPC Services10.12.16
The U.S. Food and Drug Administration (FDA) has issued a draft guidance document, “Deciding When to Submit a 510(k) for a Software Change to an Existing Device.” This new guidance document applies to software changes only, and addresses the question of whether medical device firms must submit a new 510(k) or only internal documentation of the change.
Content of the Guidance Document is:
The introduction in this guidance document is brief and to the point.
According to the background section, there are two key issues with 21 CFR 807.81(a) (3): One is the phrase, “could significantly affect the safety or effectiveness of the device” while the other is use of the adjectives “major” and “significant,” both of which can lead the FDA and device manufacturers to radically different interpretations of the regulation. I not only agree with this statement, I contend there is an even greater risk of misinterpretations when software is involved, so I am very pleased to see this draft guidance document. The background section also includes a portion on “The 510(k) Process and the Quality System Regulation,” which provides an overview of change control according to 21 CFR Part 820 Quality System Regulation.
The scope of the draft guidance focuses on software modifications, and it clearly states that non-software modifications are not within the scope of the new regulations and should be evaluated using the existing K97-1 Memo, “Deciding When to Submit a 510(k) for a Change to an Existing Device.” That document, however, also is undergoing an update [Editor’s note: Details of the K97-1 Memo draft guidance can be found in the September/October Regulatory column of MPO’s sister publication, Orthopedic Design & Technology]. The scope of the software modification draft guidance document clearly communicates the following:
Additionally, the scope section states the finalized draft guidance will not supersede device-specific guidance, but may cover areas not addressed in any device-specific regulation.
Also, the scope section notes the draft guidance does not apply to software for which the FDA is choosing not to regulate, such as that for mobile medical applications.
This Guiding Principles section of the draft guidance provides a number of guiding principles that should be followed. Some of these rules are derived from existing FDA 510(k) policy, and others are necessary for exercising guidance logic. Some of the most significant guiding principles include:
The section explaining how to use the guidance contains a step-by-step question flowchart and associated descriptions:
This section superbly shows the reader how to use the flowchart and decision logic. This is the most impactful and best-written section of the draft guidance document, in my opinion.
The next portion is self-explanatory, providing users with additional factors to consider when deciding whether to submit a new 510(k) application for a software change to an existing device:
The FDA does an excellent job of communicating its current thinking on software change impacts to an existing 510(k) in the final section of the draft guidance document (“Software Modification Examples”). This portion provides detailed examples of various software modifications ranging from a proactive software security patch to adding new modes and features. The examples include a description of the proposed change, the associated flowchart question, and the answer to the question (based on the description of the proposed change), the answer’s rationale, and the outcome (a new 510(k) or documentation). These examples, in my opinion, are not merely an add-on or afterthought to this draft guidance document; rather, they are a key element. This section is not one to be quickly glossed over.
Overall, this draft guidance document is a great addition to the FDA’s cache of guidance documents.
James A. “Jim” Dunning’s consulting career began in 2001. He has provided quality and regulatory consulting services for various companies ranging from Fortune 500 medical device firms to startups. Dunning’s passion, however, lies with startups and small companies, especially those in regulatory distress. He has amassed significant experience in preparing 510(k) applications, developing complete Quality Management Systems, providing Quality System Training, and advising on quality, business, and leadership issues. Dunning is a senior member of the American Society for Quality (ASQ) and a member of the Regulatory Affairs Professional Society (RAPS). He can be reached at jdunning@qpcservices.com.
Content of the Guidance Document is:
- Introduction
- Background
- Scope
- Guiding Principles
- How to Use This Guidance
-
Additional Factors to Consider When Determining When to Submit a New 510(k) for a Software Change to an Existing Device
Appendix A. Software Modification Examples
The introduction in this guidance document is brief and to the point.
According to the background section, there are two key issues with 21 CFR 807.81(a) (3): One is the phrase, “could significantly affect the safety or effectiveness of the device” while the other is use of the adjectives “major” and “significant,” both of which can lead the FDA and device manufacturers to radically different interpretations of the regulation. I not only agree with this statement, I contend there is an even greater risk of misinterpretations when software is involved, so I am very pleased to see this draft guidance document. The background section also includes a portion on “The 510(k) Process and the Quality System Regulation,” which provides an overview of change control according to 21 CFR Part 820 Quality System Regulation.
The scope of the draft guidance focuses on software modifications, and it clearly states that non-software modifications are not within the scope of the new regulations and should be evaluated using the existing K97-1 Memo, “Deciding When to Submit a 510(k) for a Change to an Existing Device.” That document, however, also is undergoing an update [Editor’s note: Details of the K97-1 Memo draft guidance can be found in the September/October Regulatory column of MPO’s sister publication, Orthopedic Design & Technology]. The scope of the software modification draft guidance document clearly communicates the following:
- Combination products, such as drug/device or biologic/device combinations, are not specifically addressed but the general principles and concepts described in the draft guidance may help manufacturers better determine whether a 510(k) is necessary for changes to software-containing device constituent parts of combination products.
-
Software modifications can take numerous forms, including but not limited to:
- Adaptive—Modification of software to keep it usable in a changed or a changing environment
- Corrective—Reactive modification of software to address discovered faults
- Perfective—Modification of software to improve performance or maintainability
Additionally, the scope section states the finalized draft guidance will not supersede device-specific guidance, but may cover areas not addressed in any device-specific regulation.
Also, the scope section notes the draft guidance does not apply to software for which the FDA is choosing not to regulate, such as that for mobile medical applications.
This Guiding Principles section of the draft guidance provides a number of guiding principles that should be followed. Some of these rules are derived from existing FDA 510(k) policy, and others are necessary for exercising guidance logic. Some of the most significant guiding principles include:
- Use of risk management. The draft guidance recognizes and aligns with ISO 14971 Medical devices—Application of risk management to medical devices. According to paragraph (a)(3)(i) of 21 CFR 807.81, which outlines the requirements for a premarket notification submission, a new 510(k) proposal is needed when a change “could significantly affect safety or effectiveness.” Both safety and effectiveness should be considered in evaluating a device’s risk profile.
- Evaluating simultaneous changes. Since many simultaneous changes may be considered at once, each change should be assessed separately as well as in aggregate.
- 510(k) submission for modified devices. When a new 510(k) is submitted for a device with multiple modifications, that application should describe all changes that trigger the need for a new 510(k). The new submission “should also describe other modifications since the last-cleared 510(k) (i.e., those that did not require a new 510(k) that would have been documented as part of the original 510(k) for that device. This helps ensure the FDA has a more complete understanding of the device under review.”
The section explaining how to use the guidance contains a step-by-step question flowchart and associated descriptions:
- Is the change made solely to strengthen cybersecurity and does not have any other impact on the software or device?
- Is the change made solely to return the system into specification of the most recently cleared device?
- Does the change introduce a new cause or modify an existing cause of a hazardous situation that could result in significant harm and that is not effectively mitigated in the most recently cleared device?
- Does the change introduce a new hazardous situation or modify an existing one? This flowchart uses yes-or-no questions to either advance the respondent to an additional question, or lead him to determine whether he must submit a new 510(k) or “document.”
- Does the change create or necessitate a new risk control measure for a hazardous situation that could result in significant harm?
- Could the change significantly affect clinical functionality or performance specifications that are directly associated with the intended use of the device?
This section superbly shows the reader how to use the flowchart and decision logic. This is the most impactful and best-written section of the draft guidance document, in my opinion.
The next portion is self-explanatory, providing users with additional factors to consider when deciding whether to submit a new 510(k) application for a software change to an existing device:
- Clarification of Requirements—No Change to Functionality: This item discusses changes made to clarify software requirements after a product has received FDA 510(k) clearance. Such a clarification may either revise the phrasing of an existing requirement or create a new requirement, without changing or adding functionality. Nevertheless, changes made to clarify existing requirements likely do not need a new 510(k).
- Cosmetic Changes—No Change to Functionality: This clause addresses changes made to a product’s appearance that do not impact its clinical use. For example, changing a company logo displayed on the background of every screen could involve modifying multiple software modules; while the number of modules impacted may be large, it is unlikely the intended change would impact the device’s safety and effectiveness or intended use. Thus, a new 510(k) is likely not required.
- Reengineering and Refactoring—This paragraph focuses on two common software maintenance techniques. Reengineering is defined as the examination and alteration of software to reconstitute it in a new form, and it includes the subsequent implementation of the new form. It is often undertaken to replace aging legacy software. Refactoring, meanwhile, is a disciplined technique for restructuring a software program’s internal structure without changing its clinical performance specification. Refactoring seeks to improve a program structure and its maintainability. In general, reengineering often results in broader and more complex changes, while refactoring is often narrower in scope and less complex. The complexity of the change should be considered when determining whether the change requires a new 510(k). Minor modifications to enhance the maintainability of the device within its specification context are unlikely to require a new 510(k). But significant software rewrites will likely require a new 510(k) because of the impact on the product’s performance and on risk controls.
The FDA does an excellent job of communicating its current thinking on software change impacts to an existing 510(k) in the final section of the draft guidance document (“Software Modification Examples”). This portion provides detailed examples of various software modifications ranging from a proactive software security patch to adding new modes and features. The examples include a description of the proposed change, the associated flowchart question, and the answer to the question (based on the description of the proposed change), the answer’s rationale, and the outcome (a new 510(k) or documentation). These examples, in my opinion, are not merely an add-on or afterthought to this draft guidance document; rather, they are a key element. This section is not one to be quickly glossed over.
Overall, this draft guidance document is a great addition to the FDA’s cache of guidance documents.
James A. “Jim” Dunning’s consulting career began in 2001. He has provided quality and regulatory consulting services for various companies ranging from Fortune 500 medical device firms to startups. Dunning’s passion, however, lies with startups and small companies, especially those in regulatory distress. He has amassed significant experience in preparing 510(k) applications, developing complete Quality Management Systems, providing Quality System Training, and advising on quality, business, and leadership issues. Dunning is a senior member of the American Society for Quality (ASQ) and a member of the Regulatory Affairs Professional Society (RAPS). He can be reached at jdunning@qpcservices.com.