When Is a Software Change Really a Change that Requires FDA Review?: When to Submit a 510(k) for a Software Change to an Existing Device

On the same day the Food and Drug Administration issued its revised draft guidance document on when to submit a new 510(k) premarket notification for an existing medical device, it released a similar document specific to software changes and 510(ks). While the former document has garnered more attention, the latter, “Deciding When to Submit a 510(k) for a Software Change for an Existing Device,” is worthy of review. FDA will accept comments for the guidance.

This Bulletin will summarize some of the key elements in the draft, which represent the agency’s current thinking. FDA offers a number of software modification examples in an Appendix. We will not describe the many examples offered at the back of the draft due to the number offered and the technical elements, but it is worthy of reading. We conclude with some of our own observations.

Regulatory Background

• According to 21 C.F.R. § 807.81(a)(3), a new 510(k) premarket notification is required when there are significant changes or modifications to an existing device. This may include: a change or modification in the device that could significantly affect the safety or effectiveness of the device, (e.g., a significant change or modification in design, material, chemical composition, energy source, or manufacturing process), or a major change or modification in the device’s intended use
• In January 1997, the agency issued a draft guidance, which stands today, to explain its interpretation of the regulation
• This recently-issued draft, when finalized, will supersede the 1997 version

Scope

• The draft guidance, which is the subject of this Bulletin, is specific to software modifications or changes to an existing device
• The draft does not apply to software that FDA has stated elsewhere it “does not intend to enforce compliance with applicable regulatory controls” (e.g., certain types of mobile medical applications)
• FDA notes that software modifications can include, but are not limited to:

  • 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
• Software modifications such as a bug fix, hot patch, software change or tweak, are considered design changes under the Quality System Regulations (21 C.F.R. Part 820)
• A manufacturer must evaluate the combination of both software and non-software changes to evaluate the effect of a change to a device
• FDA defines “software” here as:
  the set of electronic instructions used to control the actions or output of a medical device, to provide input to or output from a medical device, or to provide the actions of a medical device … includes software that is embedded within or permanently a component of a medical device, software that is an accessory to another medical device, or software that is intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device

“Guiding Principles”

FDA offers a number of “Guiding Principles” for a company to consider when evaluating whether a software change to an existing device might require a 510(k).

• If a manufacturer modifies a device with the intent to significantly improve the safety or effectiveness of the device (in response to a known risk or adverse event), a new 510(k) is likely required

  • changes that are not intended to significantly affect the safety or effectiveness of a device should, nevertheless, be evaluated to determine whether the change could significantly affect device safety or effectiveness, regardless of intent
• A manufacturer should consider whether there are any unintended consequences or effects of the device change

  • e.g., an intended operating system upgrade may lead to unintended or effects in device drivers and software code embedded in the device
• A company should consider hazards and hazardous situations, risk estimation, risk acceptability, risk control, risk/benefit analysis, and overall risk evaluation during the design and development of a medical device
• A manufacturer should evaluate simultaneous changes individually and in the aggregate
• FDA recommends that, for each a time a change is made, a manufacturer should conduct a risk-based assessment that compares the changed device to the most recently-cleared device and the cumulative effect of the change
• When a manufacturer changes a device, it should review if any action is needed to comply with an applicable Quality System Regulation, such as documenting the device changes
• A 510(k) submission that is offered for a device with multiple modifications should describe all changes that trigger the requirements for a new 510(k)

  • also describe other modifications since the last cleared 510(k), even if those individual changes did not require a new 510(k)
  • if a manufacturer makes multiple changes to a device, but only one change requires a new 510(k), the changes that did not require a new 510(k) may be immediately implemented, if those changes can be implemented independently of changes that do not require a new 510(k)

Guidance Usage

• FDA recommends that companies use a flowchart it provides (download pdf below), its Guiding Principles, and additional factors it recommends to consider for evaluating when a software change to an existing device may require a new 510(k).
• FDA recommends that companies ask: “Is the change made solely to strengthen cybersecurity and does not have any other impact on the software or device?”

  • a change made solely to strengthen cybersecurity may not require a new 510(k)
  • however, manufacturers should review that these changes do not affect the performance of the device by conducting analysis, verification and/or validation
• Firms should consider: “Is the change made solely to return the system into specification of the most recently cleared device?”

  • a new 510(k) is not likely required if a change to the software only restores the device to the specifications of the most recently cleared device
  • however, manufacturers should conduct an analysis that involves determining the overall effect of the change to the device in terms of risk assessment and performance
  • in general, manufacturers will not need to submit a new 510(k) for changes to a specification document for the purpose of clarifying an existing software requirement or to capture a missing software requirement, if this does not require any changes to software code or product performance specifications
  • but, manufacturers should still review the effect of the changes on other software documentation when applying appropriate design controls
• A company making a software change should ask: “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?”

  • a “hazardous situation” exists when there is a potential source of harm: such as potential exposure to physical injury or damage
  • “cause” refers to the cause of a hazardous situation, as identified and defined by the manufacturer in the risk management file for the device
  • “significant harm” refers to situations when the risk level is serious or more severe, e.g., the risk could result in injury or impairment requiring professional medical intervention, permanent impairment, or death
  • assess whether a new cause of a hazardous situation is created, or an existing cause altered, as a result of the software change
  • if the following criteria are all met, a new 510(k) is likely required:

    • the change leads the manufacturer to document a new cause or the modification of an existing cause in the risk management file
    • this criterion is met if the change creates a new cause or modifies an existing cause (such as increasing the likelihood) of an existing hazardous situation
    • the level of harm associated with the new or modified cause is considered serious or more severe, e.g., the cause of the hazardous situation could result in injury or impairment requiring professional medical intervention, permanent impairment or death
    • the hazardous situation associated with the new or modified cause is not already effectively mitigated in the most recently cleared device
    • The agency recommends a company consider: “Does the change introduce a new hazardous situation or modify an existing hazardous situation that could result in significant harm and that is not effectively mitigated in the most recently cleared device?”
  • evaluate whether a new hazardous situation (defined above) is created, or an existing hazardous situation altered, as a result of the software change
  • if the following criteria are all met, a new 510(k) is likely required:

    • the change leads the manufacturer to document a new hazardous situation or the modification of an existing hazardous situation in the risk management file
    • this criterion is met if the change creates a new hazardous situation or modifies an existing hazardous situation (such as increasing the likelihood of such)
    • the level of harm associated with the new or modified hazardous situation is considered serious or more severe, e.g., the hazardous situation could result in injury or impairment requiring professional medical intervention, permanent impairment or death
    • the hazardous situation is not effectively mitigated in the most recently cleared device
  • A company should evaluate: “Does the change create or necessitate a new risk control measure or a modification of an existing risk control measure for a hazardous situation that could result in significant harm?”
  • introducing new risk control measures or implementing changes to risk control measures could significantly affect the safety or effectiveness of the product
  • a new 510(k) is likely if the changes to risk controls are necessary to effectively prevent significant harm
  • a new 510(k) is likely not required as a result of a manufacturer implementing additional risk control measures, if this is not in response to a new, modified, or previously known hazardous situation
• Finally, a device firm should consider: “Could the change significantly affect clinical functionality or performance specifications that are directly associated with the intended use of the device?”

  • changes in performance specifications can range from routine specification changes necessary to improve device performance to significant product redesigns
  • a new 510(k) is likely required if the software change could significantly affect clinical functionality or performance specifications that are directly associated with the intended use of the device

    • for in vitro diagnostic devices (IVDs), this includes a change that could have clinically significant effect in terms of clinical decision-making
    • a new 510(k) is not likely required for IVD functionality changes that are not related to the IVD’s intended use, and the performance of the modified device could not significantly change from previously cleared performance claims

Additional Factors to Consider

• FDA notes that it cannot anticipate every type of software change or offer a recommendation in each case; in addition to the Guiding Principles and Flowcharts, the agency offers additional factors that companies should consider when making changes (and when in doubt, consult the relevant FDA office and branch most likely familiar with the product and types of changes)
• The agency provides a non-exhaustive list of common software change types (many of which we provide below) and, depending on the changes, discusses whether or not a new 510(k) might be required:

  • “infrastructure,” i.e., modifications made to the software support system (e.g., switching compilers, changing language, or changing software drivers or libraries)
  • “architecture,” i.e., modifications to the overall structure of the software (e.g., porting to a new OS, software changes to support a new hardware platform, and new middleware)
  • “core algorithm,” i.e., modifications made to an algorithm that directly drive the device’s intended use (e.g., 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,” i.e., made to clarify software requirements after a product has received premarket clearance
  • “cosmetic changes – no change to functionality,” i.e., made to the appearance of the device that do not affect the clinical use of the device

AGG Observations

• The revised guidance offers the medical device industry insights as to FDA’s current thinking on when to submit a new 510(k) for software changes to an existing device. It’s not a one-size-fits-all document and, by the agency’s acknowledgement, it cannot anticipate and answer all questions and permutations. Rather, by explaining its rationale behind certain types of changes and whether or not it believes a new 510(k) may (or not) be required, FDA is attempting to provide industry with issues to consider.
• FDA’s regulation is the first place to start. That’s law. The guidance is an effort to further explain FDA’s interpretation of that regulation. FDA cannot take enforcement against a company that fails to follow its guidance; it can take enforcement if the company fails to follow the regulation. However, by better understanding the guidance, companies get a peek of what FDA expects.
• A company that makes a software change to an existing device should include members from its Medical, Quality, Regulatory, and Legal teams. Other groups, such as Manufacturing and Engineering, should be included as appropriate. Each member has unique experience, insight, and perspective, and all are important to evaluate whether a change might significantly affect safety, efficacy, or intended.
• A company may decide, based on the facts, that it is not required to submit a new 510(k). If such an assessment is made, it should document its rationale in a memo to internal file, including a review of FDA’s regulations, the guidance document, a Health Hazard Assessment, and then applicability to the specific case. Someone from the company or outside the company, who did not prepare the memo, should review the document, with an objective and critical eye, anticipating where FDA or a competitor might challenge the position. FDA can always disagree with the decision but, if the company has a rhyme or reason for its good-faith interpretation, based on a careful review of FDA’s rules and guidances, as well as a safety and risk evaluation, possible enforcement is minimized, although not necessarily eliminated. Any action taken by FDA might not be as severe as could be the case if no serious consideration was given to the change and its effect on safety, effectiveness, or intended use.
• We would add that, while not necessarily related to this guidance, we have seen cases where companies have submitted new 510(k)s for new uses, as an example, did not receive clearance, and proceeded with the sale of the new use anyway. While the mere submission of a new 510(k) is not an admission that a new application was needed, if a company chooses to submit, is rejected, and then markets the new use regardless, it should ask itself why — did the company think the new 510(k) was not necessary, did it re-review FDA’s guidance and come to a different conclusion, did the company not have the time to resubmit or collect the data FDA might have requested in the review, or was a senior management decision made to proceed at risk?
• Consider reviewing what other companies with similar products have done. That is, if all competitors are submitting new 510(k)s for changes similar to what your company is contemplating, this might suggest a new 510(k) should be provided. Of course, the fact that others made such a decision is not dispositive and does not mean that your company must submit a new 510(k). The guidance does not take this approach, and each case is different. However, if your company is alone in its belief, for example, that a new 510(k) is not required for a particular change and all other similar companies have concluded otherwise, your firm is on an island. This is merely a practical issue to consider.
  Finally, consider the what-ifs. What if, for example, the company does not submit a new 510(k) and something goes wrong with the software change to the device, such as an injury or failure to work? Again, there are many cases when a new 510(k) for a change might not be required, and FDA acknowledges many such cases in its guidance. However, a firm must consider the potential consequences, such as liability exposure, FDA inspection, competitor challenge, loss of good will in the marketplace.

To review the entire document and formatting for this alert (e.g., footnotes), please access the original below: