Software Recalls: When a Medical Device Update Is a Recall

FDA's Medical Device Recalls database lets you filter recalls by root cause. Six of the categories are about software: software design, software design change, software change control, software design (manufacturing process), software manufacturing or deployment, and software in the use environment.

For software, the fix often reaches users before anyone has decided what kind of action it is. A new release can be an ordinary enhancement, a reportable correction in the US, and a field safety corrective action (FSCA) in the EU. This article looks at software updates, cybersecurity patches and rollbacks, and at the records you need to know which versions are affected. Our article on medical device recalls under FDA and EU rules explains the legal framework itself.

Enhancement or correction?

The first decision is the same for every release: does it fix a problem in the marketed device, or does it only improve a device that was already acceptable?

Sources: FDA, Distinguishing Medical Device Recalls from Medical Device Enhancements (October 2014); 21 CFR Part 806; MDR; MDCG 2023-3 Rev.2.

According to FDA, the key factor that separates a recall from an enhancement is whether there is a violation of the FD&C Act or its regulations. In the EU, MDCG 2023-3 Rev.2 lists "changes of software/firmware in the device that are related to a safety issue (e.g. version update or rollback to an earlier version)" as an FSCA.

In our view, the release note is the wrong place to make this decision. Record it in the problem report, with the risk assessment, before the release is approved.

Cybersecurity patches

Security fixes are where software teams most often get this wrong, because most patches are routine.

FDA's Postmarket Management of Cybersecurity in Medical Devices guidance (December 2016) separates two cases:

Source: FDA, Postmarket Management of Cybersecurity in Medical Devices, December 2016.

For uncontrolled risk, FDA does not intend to enforce Part 806 reporting if all four conditions are met:

1. There are no known serious adverse events or deaths associated with the vulnerability.

2. Within 30 days of learning of it, the manufacturer informs customers, identifies interim compensating controls and develops a remediation plan.

3. Within 60 days, the manufacturer fixes the vulnerability, validates the change and distributes the fix.

4. The manufacturer actively participates in an Information Sharing Analysis Organization (ISAO).

For cyber devices, section 524B of the FD&C Act also requires processes for updates and patches. Our article on FDA cybersecurity guidance covers that side.

In the EU, there is no separate route for security patches. A vulnerability that could lead to a serious incident is assessed like any other safety issue, and a safety-related patch is an FSCA under MDCG 2023-3 Rev.2.

Knowing which versions are where

A software recall depends on one question: which users run which version? Without that answer, neither an FDA effectiveness check nor an EU field safety notice can be completed.

Under the MDR, the UDI rules for software in Annex VI, Part C, Section 6.5 help here:

• a new UDI-DI is needed for a change that affects the original performance, safety, intended use or interpretation of data;

• a minor software revision needs a new UDI-PI, not a new UDI-DI.

MDCG 2018-5 gives guidance on assigning UDIs to software. Our EUDAMED and UDI checklist covers registration.

In our view, the record that matters most is the installed base: customer, site, version and date of update. For cloud software you control the version, but you still need to know who used the faulty release and when. For installed software, you also need to know who has not yet updated.

The importers and distributors in the supply chain need the same information. MDIS gives economic operators shared access to the current device documentation and supports vigilance reporting.

Choosing the corrective action

Software gives manufacturers more options than a physical product, but each one has consequences:

In our view, whichever option you choose, the field safety notice or recall letter must name the affected versions exactly and tell users how to check which version they run.

Where IEC 62304 fits

IEC 62304 already contains most of the process a software recall needs. The software problem resolution process records and investigates each problem, and the maintenance process evaluates and implements changes after release.

The link that is often missing is the regulatory decision. In our view, the problem report template should include three questions: is this a correction or removal under Part 806, is this an FSCA under the MDR, and which versions and users are affected? The software as a medical device framework sets the context for these questions.

A hypothetical example

Hypothetical example: a company sells a cloud-based SaMD in the EU and the US. A cybersecurity researcher reports a vulnerability in the login service. In the same month, a customer reports that one release rounds a calculated value incorrectly.

1. Vulnerability: the risk assessment shows that compensating controls keep the risk of patient harm acceptable. In the US, the patch is a routine update and needs no Part 806 report. In the EU, it is not related to a serious incident risk, so it is not an FSCA. The rationale is recorded.

2. Calculation defect: the wrong value could influence a clinical decision. In the US, the fix is a correction to reduce a risk to health, so a Part 806 report is due within 10 working days. In the EU, it is an FSCA, reported to the competent authorities with a field safety notice.

3. Affected users: the company identifies them from its access logs, by release and date, and confirms that no one is still on the faulty version.

Conclusion

For software, the regulatory question is not whether to fix a defect but how to classify the fix. FDA separates enhancements from recalls by whether there is a violation, and routine security patches from reportable corrections by whether the risk is controlled. The EU treats any safety-related software change, including a rollback, as an FSCA.

In our view, put the regulatory decision into the problem resolution process, and keep a version-level record of the installed base. Then a software recall becomes a release with paperwork, not a crisis.

If you need help assessing a software correction or preparing a field safety notice, our vigilance support team can help, or contact MedQAIR.

Frequently asked questions

Is every software bug fix a recall?

No. In the US, a fix is a recall only if it corrects a violation; it needs a Part 806 report only if it reduces a risk to health. In the EU, it is an FSCA only if it is related to a safety issue.

Does a cybersecurity patch have to be reported to FDA?

Not usually. FDA treats routine patches for vulnerabilities with controlled risk as enhancements. Fixes for vulnerabilities with uncontrolled risk need a Part 806 report, unless the four conditions in the 2016 guidance are met.

Is a rollback to an earlier version an FSCA?

Yes, if it is done for a safety reason. MDCG 2023-3 Rev.2 lists a rollback to an earlier version as an example.

Does a software fix need a new UDI-DI?

Only if it changes the original performance, safety, intended use or interpretation of data. A minor software revision needs a new UDI-PI.

How do I prove a software recall reached every user?

With installed-base records by user, site and version, and with confirmation that each installation updated.