What FDA Recall Data Reveals About Design Process Failures — How to Prevent IEC 62304 and ISO 14971 from Becoming Mere Formalities

Background: 10-Year Trends in Software-Caused Recalls

An analysis of the U.S. FDA recall database (approximately 56,000 records) covering software-caused recalls from 2016 to 2025 reveals the following.

- Software-caused recalls account for an estimated 10–12% of all medical device recalls (240–350 cases per year)
- The absolute number has increased by approximately 35% over the past decade
- 2024 saw the highest level of Class I recalls (severe-risk classification under FD&C Act §518(e)) in 15 years

Sources: IEEE Spectrum December 2025 issue, FDA CDRH public data, AAMI industry reports

Root Cause Classification: FDA's 6-Category Analysis

FDA classifies the root causes of software-caused recalls as follows.

> Note: The chart above shows category labels in Japanese. An English version of the chart is in preparation.

Critical Interpretation: 55% of "Design Defects" Are Not Coding Issues

For the largest category—Software Design at 55%—AAMI research and FDA internal data share a common insight.

The primary cause of these design defects lies in inadequacies in upstream processes required by IEC 62304.

Specifically, the quality of the following activities is the root of the problem.

- §5.1 Software development planning (particularly the rationale for software safety class assignment)
- §5.2 Software requirements analysis (alignment with Intended Use, derivation of hazard-related software requirements)
- §5.3 Software architectural design (segregation requirements for Safety Class B or C)

IEC 62304 mandates these deliverables, but merely "filling in templates" leaves design-level defects that downstream testing cannot detect. Cases where the linkage with ISO 14971—hazard analysis → software safety class assignment → requirement reflection—does not function effectively are particularly common among Japanese manufacturers.

Cybersecurity: The Fastest-Growing Category

The track record of the FDA CDRH cybersecurity team and recent regulatory developments are as follows.

- 68 cyber-related recalls handled since the team's establishment in 2013
- 2023: Vulnerabilities discovered in medical products increased 59% year-over-year, with 64% originating in software components

Regulatory turning points:

- December 2022: Consolidated Appropriations Act 2023 enacted (adding FD&C Act Section 524B)
- March 2023: Section 524B took effect. Cybersecurity plans and SBOM submission became legal requirements for premarket submissions
- June 2025: FDA issued the updated final guidance

In Japan as well, MHLW cybersecurity notifications (Yakusei-Kishin-hatsu) and PMDA's premarket submission documentation guidance reference IEC 81001-5-1, requiring alignment with software safety requirements under Article 12 of the Essential Principles.

Change Management: The Overlooked 25% of Recall Causes

Change management failures (~15%) and defects introduced during design changes (~10%) together account for approximately one-quarter of all software-caused recalls.

The following activities required by IEC 62304 §6 (Software Maintenance Process) and §8 (Software Configuration Management) directly contribute to recall prevention.

- Impact analysis of change requests (§6.2.1): Identifying software units affected by a change
- Regression testing strategy (linkage with §5.7): Documenting the rationale for the re-verification scope after a change
- Configuration item management (§8.1): Mapping released versions to SBOM

As the frequency of cybersecurity patches increases, integrating patch deployment into the formal change management process flow has become essential.

Practical Response Strategies

① Substantive execution of upstream processes (ISO 14971 ↔ IEC 62304 linkage)

The most cost-effective investment for recall prevention is the quality of hazard analysis and software requirements. The quality of two specific items in submission documents has become a focal point in both PMDA and FDA reviews:

- "Rationale for software safety class assignment"
- "List of hazard-related software requirements (mapped to ISO 14971 §8)"

② Operationalizing PSIRT capability

For the post-market monitoring system required by IEC 81001-5-1 §8.8 (Monitoring of known vulnerabilities), an effective configuration consists of three elements.

- Virtual team model (cross-functional roles in development, quality, and regulatory affairs, rather than a dedicated department)
- Management-approved vulnerability response charter (explicit CVSS score thresholds and response timelines)
- SBOM-based vulnerability matching via NVD/JVN linkage (automation recommended)

③ Leveraging FDA recall trends as leading indicators

The FDA recall databases (MAUDE, Recall Database) are publicly available. Japan's regulatory tightening tends to follow the U.S. by 2–3 years; recall cause categories currently increasing at FDA can serve as leading indicators for confirmation items in future PMDA submission reviews. MSC Regulatory Watch continuously monitors these trends.

The data in this article are based on FDA public information, IEEE Spectrum (December 2025 issue), and AAMI industry reports. Regulatory decisions for individual cases should be based on primary sources and consultation with the relevant regulatory authorities.