17 Aug Draft Guidance for Industry and Food and Drug Administration Staff – Deciding When to Submit a 510(k) for a Software Change to an Existing Device
Document issued on August 8, 2016
On August 8, 2016 the FDA released a draft guidance providing recommendations for manufacturers on when to submit a new premarket notification (510(k)) due to a software (including firmware) change to a 510(k)-cleared or pre-amendment device. The guidance also applies to legally-marketed existing devices that are the subject of a recall and a change in the device or its labeling is required to correct the issue.
The FDA discusses the types of software modifications and guiding principles on deciding whether a new 510(k) will be required. The FDA recommends that both the guiding principles and the decision-making flowchart (Figure 1) be used to determine how the regulations apply.
According to the guidance, software modifications can take numerous forms, including, but not limited to, the following:
- Adaptive – modification of software to keep it usable in a changed or changing environment
- Corrective – reactive modification of software to address discovered faults;
- Perfective – modification of software to improve performance or maintainability.
- In addition, software modifications may be identified by many other names, including – bug fix, hot patch, software change or tweak.
Regardless of name or form, these are considered design changes under the Quality System regulation, 21 CFR Part 820.
The following guiding principles are identified in the guidance as being paramount in determining whether a new 510(k) is required:
- Modifications made with intent to significantly affect safety or effectiveness of a device – a new 510(k) is likely required.
- “Could significantly affect” evaluation and the role of testing – the manufacturer should conduct a risk-based assessment to determine whether the change could significantly affect the device’s safety or effectiveness, either positively or negatively and thus to make an initial decision whether or not a new 510(k) is required. If the initial decision following the risk assessment is that a new 510(k) is not required, this decision should be confirmed by successful, routine verification and validation activities. If routine verification and validation activities produce any unexpected issues, any prior decision that a new 510(k) is not required should be reconsidered.
- Unintended consequences of changes – In evaluating whether a change requires a new 510(k), manufacturers should consider whether there are any unintended consequences or effects of the device change.
- Use of risk management – The risk profile is based on the combination of multiple risk concepts which are important for managing the risks of medical devices. Hazards and hazardous situations, risk estimation, risk acceptability, risk control, risk/benefit analysis and overall risk evaluation are all concepts that can be applied during the design and development of a medical device. Both safety and effectiveness should be considered in evaluating a device’s risk profile.
- Evaluating simultaneous changes – Because many simultaneous changes may be considered at once, each change should be assessed separately, as well as in aggregate.
- Appropriate comparative device and cumulative effect of changes –When the manufacturer compares the proposed modified device to the device in its most recently cleared 510(k), the manufacturer should evaluate the cumulative impact of all changes since their most recently cleared 510(k).
- Documentation requirement – Whenever manufacturers change their device, they must take certain actions to comply with the QS regulation, 21 CFR Part 820, unless the device in question is exempt. The QS regulation requires that device changes be documented.
- 510(k) submissions for modified devices – When a new 510(k) is submitted for a device with multiple modifications, that 510(k) should describe all changes that trigger the requirement for a new 510(k). That 510(k) 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.
- Substantial equivalence determinations – Manufacturers should understand that, even though they may follow this guidance and submit a new 510(k), a substantially equivalent determination is not assured.
The following is a list that the FDA provides of common software change types that should be considered when making new 510(k) determinations.
- “Infrastructure” changes are modifications made to the software support system. Examples: switching compilers, changing languages (C to C++, C++ to Java), or changing software drivers or libraries.
- “Architecture” changes are modifications to the overall structure of the software. Examples: porting to a new OS, software changes to support a new hardware platform, and new middleware.
- “Core algorithm” changes are modifications made to an algorithm that directly drive the device’s intended use. Examples: alarm algorithms on a monitor, a motor control algorithm for an infusion pump, and a detection module and measurement engine algorithm for an IVD.
- “Clarification of Requirements – No change to Functionality” are changes made to clarify software requirements after a product has received premarket clearance. This clarification may be revised phrasing of an existing requirement or creation of a new requirement altogether, without changing or adding functionality. Changes made to clarify the requirements as discussed here likely do not require a new 510(k).
- “Cosmetic Changes – No change to Functionality” are changes made to the appearance of the device that do not impact the clinical use of the device. Example: changing the company logo that is 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 that the intended change could impact the device’s safety and effectiveness or intended use, and a new 510(k) is likely not required.
- “Reengineering” and “refactoring” are two common software maintenance techniques. “Reengineering” is defined as the examination and alteration of software to reconstitute it in a new form, and includes the subsequent implementation of the new form. It is often undertaken to replace aging legacy software. “Refactoring” is a disciplined technique for restructuring a software program’s internal structure without changing its clinical performance specification. Changes involving significant software re-write likely require a new 510(k) because of the impact on the performance and on the risk controls.
Medical device software is used in a wide variety of applications and is subject to a wide variety of changes. The changes have the potential to create unexpected changes to how the device functions if not controlled properly. As such, software changes should involve a careful evaluation of their potential impact on device safety and effectiveness. The questions in the flowchart and the associated recommendations in the text provide a guide for manufacturers’ decision-making and associated documentation. Manufacturers’ should make thoughtful and careful analysis of changes as the impact of on safety and effectiveness may not always be clear.
Boston Biomedical Associates has extensive experience assisting companies in meeting 510(k) requirements and providing submission support. We can help your company to understand what the FDA expects when they receive a 510(k) and provide with expertise in drafting and submitting successful 510(k)s.