Technical writing
FDA Medical Device Recalls: The CDRH Recall Database Explained
The FDA's Center for Devices and Radiological Health publishes a searchable record of every medical device recall, correction, and removal since 1999 — roughly 1,000 to 1,500 actions per year, nearly all initiated voluntarily by manufacturers before the FDA exercises its rarely-used mandatory recall authority. Behind these numbers are some of the most consequential product liability events in American healthcare history.
What the Database Contains
The FDA CDRH Recalls database at fda.gov/medical-devices/medical-device-safety/recalls-corrections-and-removals-devices covers all formal recall actions initiated by the agency's Center for Devices and Radiological Health, plus a subset of blood product device recalls handled by the Center for Biologics Evaluation and Research (CBER). The database distinguishes three types of actions: recalls (removing a product from the market or from use), corrections (fixing a defect in place without removal), and removals (physically retrieving a distributed product). Market withdrawals and safety alerts appear separately — market withdrawals apply to products with minor defects that do not violate FDA regulations, while safety alerts notify the healthcare community about a risk without necessarily triggering a recall.
Coverage begins formally in 1999 for electronic records, though some earlier entries appear in bulk exports reaching back into the 1980s. The database is updated weekly. Each record represents a single recall event — one firm, one product description, one recall number — and the same underlying safety issue may spawn multiple records if separate lot numbers or product variants are recalled independently.
The Three Recall Classes
The FDA assigns every recall to one of three classes based on the health hazard the recalled product presents:
Class I is the most severe. The FDA defines it as a situation in which there is a reasonable probability that use of, or exposure to, the product will cause serious adverse health consequences or death. Class I recalls drive the safety story: implantable defibrillators that deliver inappropriate shocks, cardiac pacemakers with battery depletion failures, ventilators that lose pressure without alarming, and surgical instruments that fracture during procedures. These are the recalls that trigger press releases, regulatory enforcement letters, and in the most serious cases congressional hearings.
Class II covers products that may cause temporary or medically reversible adverse health consequences, or where the probability of serious harm is remote. Class II is by far the most common category by count — the majority of annual recall actions fall here. Diagnostic imaging software that underestimates lesion size, infusion pumps with inaccurate flow rates at certain settings, and glucose monitors that read outside acceptable tolerance bands are typical Class II events.
Class III applies when the recalled product is not likely to cause adverse health consequences. Labeling errors that omit a required lot number, cosmetic defects in device packaging, and clerical errors in instructions-for-use documents fall into Class III. These recalls are administratively important but carry minimal direct patient risk.
Full Database Field Schema
The OpenFDA device recall API and the bulk CSV export expose a consistent set of fields. The key fields are:
- recall_number — the FDA-assigned identifier, formatted as Z-XXXXXX-YYYY (where YYYY is the fiscal year). The Z-code prefix encodes the product classification category. There are seven major Z-code families mapping to broad device categories (e.g., Z-6xxx for in-vitro diagnostic devices, Z-8xxx for radiological devices, Z-9xxx for general hospital and personal use devices).
- recalling_firm / firm_name — the legal name of the company initiating the recall. This is typically the manufacturer but can be a distributor or repackager if they are the responsible party under 21 CFR Part 7.
- product_description — a free-text description of the recalled product, including model numbers, lot numbers, catalog numbers, and serial number ranges where applicable.
- classification — Class I, II, or III as described above.
- recall_initiation_date — the date the recalling firm notified its immediate consignees of the recall. This is the date the recall “starts” in the regulatory sense, not the date the FDA posted it publicly.
- recall_termination_date — the date the FDA determined the recall was complete. Open recalls have no termination date. Time-to-termination varies enormously: simple software corrections may close in weeks; implanted device recalls requiring patient notification and follow-up can remain open for years.
- center_classification_date — when CDRH formally classified the recall, usually weeks after initiation. This lag reflects the FDA's review process.
- product_code — a three-character FDA product code that maps to a specific device type within the classification system. Product codes link recalls to the 510(k) and PMA databases, enabling cross-database analysis.
- voluntary_mandated — whether the recall is “Voluntary: Firm Initiated” or “FDA Mandated.” The vast majority are firm-initiated.
- distribution_pattern — a free-text field describing where the product was distributed. Nationwide distributions are marked accordingly; others list specific states, countries, or named healthcare facilities.
- reason_for_recall — a narrative description of the defect or hazard. This is the most analytically rich free-text field and is frequently used for natural language classification of failure modes.
- action — what the firm has done or is doing: customer notifications, field corrections, product replacements, device inspections, or surgical explantation instructions.
- quantity_in_commerce — the number of units distributed. This field is often approximate or missing for complex multi-lot recalls.
- k_numbers / pma_numbers — cross-references to the 510(k) clearance number or Premarket Approval number for the recalled device. These linkages are not always populated, but when present they enable tracing a recall back to the predicate device lineage or the clinical evidence submitted at approval.
- event_date_initiated and report_date — internal FDA tracking fields that record when the agency became aware of the issue.
Scale and Annual Volume
The FDA processes between roughly 1,000 and 1,500 individual device recall actions per year. This figure has been relatively stable over the past decade, though enforcement attention and reporting requirements have shifted. The apparent stability masks significant variation by device category: in years following major guidance documents on software as a medical device or cybersecurity, the number of software-related recalls spikes. Similarly, a single large-scale recall event — like the Philips Respironics CPAP recall in 2021 — can generate hundreds of subordinate recall numbers as individual product families are processed separately.
Nearly all recalls are voluntary. The FDA's mandatory recall authority for devices, codified in the FDA Safety and Innovation Act of 2012 (FDASIA), has been exercised only a handful of times since enactment. The compliance incentives explain why: a firm that self-initiates a recall under 21 CFR Part 806 before the FDA demands action typically receives more cooperative treatment in subsequent inspections and enforcement actions. Firms that delay face warning letters, import alerts, and injunctions. The voluntary system thus functions through structured coercion rather than pure good faith.
How Device Recalls Differ from Drug Recalls
Drug recalls proceed on a fundamentally different timeline and logic than device recalls. A contaminated lot of a sterile injectable can be recalled and physically retrieved within hours to days because the product is fungible — one batch of saline is substitutable for another. Medical devices, by contrast, are often unique, implanted, or deeply integrated into clinical workflows.
An implanted hip prosthesis or cardiac device cannot be retrieved on a phone call. The recall action instead takes the form of patient notification letters, physician advisories, and instructions for watchful waiting — monitoring the patient for signs of failure rather than surgical explantation, because the risk of another surgery may exceed the risk of leaving the defective device in place. The DePuy ASR metal-on-metal hip recall exemplifies this: years elapsed between the recall initiation, patient notification, revision surgery decisions, and final termination of the recall, with the legal and clinical consequences extending a decade afterward.
Software-based device recalls present yet another model. A firmware update pushed over a hospital network can correct a recall-triggering defect in thousands of infusion pumps within a week. The FDA has developed specific guidance for software-as-a-medical-device (SaMD) corrections that distinguishes “software changes that require a new 510(k)” from those that can be deployed as a field correction without new regulatory submissions.
Landmark Recalls
Several device recalls stand as defining events in FDA regulatory history:
DePuy ASR Metal-on-Metal Hip System (2010): DePuy Orthopaedics, a Johnson & Johnson subsidiary, recalled approximately 93,000 ASR hip resurfacing and hip replacement systems after data showed a 12–13% revision rate at five years — roughly twice the industry benchmark. The metal-on-metal articulation shed cobalt and chromium ions into surrounding tissue, causing a condition called adverse local tissue reaction (ALTR) or pseudotumor formation. The recall triggered an estimated $4 billion in settlements, making it the largest medical device settlement in history at the time. Critically, the ASR XL acetabular system had received 510(k) clearance based on a predicate device, not a randomized clinical trial — the clearance pathway later became a focal point of congressional criticism of the 510(k) system.
Philips Respironics CPAP and BiPAP Systems (2021): Philips recalled more than 5.5 million sleep therapy and ventilator devices after identifying that the polyester-based polyurethane (PE-PUR) sound abatement foam used in the devices could degrade and off-gas potentially toxic and carcinogenic compounds, including volatile organic compounds and particulate matter that users could inhale or ingest. The recall is the largest device recall by unit count in FDA history. The replacement program was complicated by supply shortages, with millions of patients left using recalled devices or going without treatment for sleep apnea for months or years. Philips ultimately agreed to a $1.1 billion settlement with the U.S. Department of Justice covering recall remediation costs and regulatory violations.
Medtronic HeartWare HVAD Left Ventricular Assist Device (2021): Medtronic announced a permanent market withdrawal of the HeartWare HVAD system after post-market data revealed neurological adverse events (stroke, pump thrombosis, and right heart failure) at rates that exceeded comparator devices. The HVAD was used in patients with advanced heart failure as a bridge to heart transplant or as destination therapy. Because the device was implanted, patients already supported by the HVAD could not be recalled in any conventional sense — they remained on the device with enhanced monitoring until transplant, device explantation, or death. This recall illustrates the irreversibility problem that makes implanted device recalls categorically different from any other product safety action.
Stryker and Biomet Metal-on-Metal Hips (2012–2016): Following the DePuy ASR recall, Stryker recalled its Rejuvenate and ABG II modular hip stems (approximately 20,000 devices) in 2012 over corrosion at the metal taper junction — a different failure mode than the DePuy ball-and-cup design but producing similar cobalt and chromium ion release. Biomet, Wright Medical, and other manufacturers faced related class actions and FDA scrutiny of their metal-on-metal lineages. The cumulative effect was a near-total collapse of the metal-on-metal hip market, which had held roughly 35% of total hip replacement volume in the United States at its peak.
MAUDE, MDRs, and How the FDA Learns About Failures
Recalls do not emerge from thin air. The FDA learns about device failures through two primary mechanisms: mandatory device reports (MDRs) and voluntary MedWatch reports.
Under 21 CFR Part 803, manufacturers must submit an MDR to the FDA within 30 calendar days of becoming aware of information that “reasonably suggests” that a device they market has or may have caused or contributed to a serious injury or death, or has malfunctioned in a way that could cause or contribute to serious injury or death if the malfunction were to recur. User facilities — hospitals and nursing homes — must report deaths to both the FDA and the manufacturer within 10 working days, and serious injuries to the manufacturer within 10 working days. Distributors have separate but related obligations.
All MDR submissions flow into the MAUDE database (Manufacturer and User Facility Device Experience), which is itself accessible via the OpenFDA API at api.fda.gov/device/event.json. MAUDE is the upstream signal source that frequently triggers recall decisions: when MDRs for a specific device accumulate beyond statistical thresholds, the FDA's Office of Surveillance and Biometrics may issue a recall request or, more commonly, contact the firm informally to initiate a voluntary recall before the agency escalates to a mandatory action.
MedWatch, the FDA's voluntary reporting portal for healthcare providers and consumers, supplements MDRs. MedWatch reports are less structured and historically fewer in number than mandatory MDRs, but they provide a population-level signal that can surface problems affecting products used outside formal healthcare settings — over-the-counter devices, consumer wellness monitors, and home diagnostics.
Accessing the Data
The FDA provides three access methods for device recall data:
The CDRH Recalls database web interface at fda.gov allows simple keyword and date searches. It is adequate for looking up a specific recall number or reviewing recent Class I actions but is not suitable for bulk analysis.
The OpenFDA device recall API at api.fda.gov/device/recall.json supports full-text search, field-specific filtering, aggregation via the count endpoint, and pagination. The API returns JSON with a results array and a meta object containing total record counts. Without an API key, requests are limited to 240 per minute and 1,000 records per query. Registered keys raise those limits. The key query parameters are:
search— Lucene-style query string. Field-specific searches use the formatfield:value. Boolean operators AND, OR, and NOT are supported. Date range queries usefield:[YYYYMMDD+TO+YYYYMMDD].limit— number of records per page, maximum 1,000.skip— offset for pagination. OpenFDA enforces a maximum skip of 25,000, so retrieving more than 26,000 records for a single query requires partitioning by date range or product code.count— when provided instead of returning raw records, the API aggregates by the specified field and returns term-count pairs. Useful for histograms of recalls by classification, firm, or product code.
Bulk downloads are available as CSV and JSON files from the OpenFDA data download page. Bulk files are the correct approach for analysis requiring the full corpus, since they sidestep the API's pagination limits. Files are updated roughly weekly.
Querying the API: Class I Cardiovascular Device Recalls
The following Python script queries the OpenFDA recall API for Class I recalls across several cardiovascular device product codes, extracts the firm name, product description, initiation date, and reason for recall, and outputs a sorted table. String formatting uses concatenation to avoid template literal conflicts in the OpenFDA parameter construction.
import requests
import pandas as pd
# ---------------------------------------------------------------
# OpenFDA Device Recall API
# Endpoint: https://api.fda.gov/device/recall.json
# No API key required for <= 240 requests/min.
# Register at https://open.fda.gov/apis/authentication/ for higher limits.
# ---------------------------------------------------------------
BASE = "https://api.fda.gov/device/recall.json"
# Cardiovascular device product codes (a non-exhaustive sample):
# DXX - defibrillator, external
# DQK - pacemaker, implantable
# DSQ - ventricular assist device
# FRN - hip prosthesis (ortho, often cardiovascular comorbidity recalls)
# KZE - stent, coronary
# We will search Class I recalls across a broader cardiovascular set
# by filtering on product_code and classification.
CARDIO_PRODUCT_CODES = ["DXX", "DQK", "DSQ", "KZE", "MRX", "NIQ"]
records = []
for code in CARDIO_PRODUCT_CODES:
skip = 0
page_size = 100
while True:
params = {
"search": "product_code:" + code + "+AND+classification:Class+I",
"limit": page_size,
"skip": skip,
}
try:
resp = requests.get(BASE, params=params, timeout=30)
if resp.status_code == 404:
break
resp.raise_for_status()
except requests.HTTPError:
break
data = resp.json()
batch = data.get("results", [])
if not batch:
break
for r in batch:
records.append({
"recall_number": r.get("recall_number", ""),
"firm_name": r.get("recalling_firm", ""),
"product_description": r.get("product_description", "")[:80],
"initiation_date": r.get("recall_initiation_date", ""),
"reason": r.get("reason_for_recall", "")[:100],
"product_code": r.get("product_code", code),
})
# OpenFDA caps skip at 25000; stop if page is not full
if len(batch) < page_size:
break
skip += page_size
df = pd.DataFrame(records)
if df.empty:
print("No records returned.")
else:
df["initiation_date"] = pd.to_datetime(df["initiation_date"], errors="coerce")
df = df.sort_values("initiation_date", ascending=False)
print("Class I Cardiovascular Device Recalls")
print("=" * 80)
print(
df[["initiation_date", "firm_name", "product_description", "reason"]]
.to_string(index=False)
)
print()
print("Total records retrieved: " + str(len(df)))
print("Unique firms: " + str(df["firm_name"].nunique()))
The script pages through results using the skip parameter, handles the 404 response that OpenFDA returns when skip exceeds the total result set, and concatenates records across product codes before sorting by initiation date descending. Analysts running this against a full CDRH export should partition by year range to stay within OpenFDA's skip limit.
Research Applications
The recall database becomes most analytically powerful when joined to other FDA databases. The most productive linkages are:
Join to the 510(k) database by product code and K-number. When a recalled device has a clearance number in its recall record, analysts can traverse the predicate chain to identify whether the original clearance rested on clinical data or purely on substantial equivalence to an earlier device. The DePuy ASR case is the canonical example: the 510(k) clearance rested on a predicate that had itself never been tested in a randomized trial, yet the device entered wide commercial use. Researchers have used this linkage to estimate recall risk by predicate generation — devices that are three or more steps removed from the original predicate show measurably higher recall rates in several published analyses.
Track firm-level quality system failures. A firm that accumulates multiple recall actions within a two-year window often also has concurrent warning letters, FDA Form 483 inspection observations, or consent decrees in the FDA enforcement database. Correlating recall frequency with inspection outcomes produces a firm-level quality signal that investors, supply chain managers, and hospital value analysis committees have begun to use as part of vendor due diligence.
Compare recall rates by device category. Using the product code field as a grouping key and normalizing by the number of active device registrations (from the FDA Device Registration and Listing database), analysts can compute recall rates per 1,000 registered products by category. Cardiovascular implants and insulin pumps consistently show the highest Class I recall density; ophthalmic devices and dental equipment show much lower rates, partly reflecting differences in failure consequence severity.
MAUDE signal-to-recall lag analysis. By joining MAUDE event dates to recall initiation dates for the same device, researchers have measured the lag between first reported adverse event and recall action. Published analyses suggest a median lag of several months to years for implanted devices, and a much shorter lag for software-based devices. This lag is a regulatory process metric that the FDA has been under congressional pressure to reduce.
The Mandatory Recall Authority Debate
Section 616 of FDASIA 2012 gave the FDA explicit authority to order mandatory device recalls when a device presents a risk of serious adverse health consequences or death and the firm refuses to initiate a voluntary recall. Prior to FDASIA, the FDA had to rely on injunctions and seizure actions — slower and more resource-intensive legal tools.
In practice, the mandatory recall authority has been used extremely rarely since enactment. Critics argue the FDA has been reluctant to test the authority in court, since mandatory recall orders could be challenged as arbitrary and capricious under the Administrative Procedure Act if the underlying factual record is thin. Defenders of the current approach note that the informal recall request process works in the overwhelming majority of cases: firms self-initiate rapidly once the FDA signals a formal recall request is coming, because the reputational and legal exposure of being known as a firm that required a mandatory order vastly exceeds the cost of a voluntary recall.
The practical implication for data analysts is that the “voluntary” label on most recall records does not mean the manufacturer chose freely to act. It means the firm acted under the structured pressure of the regulatory system before the FDA escalated to its formal mandatory mechanism. This distinction matters for interpretations of recall counts as a quality metric: a firm with many voluntary recalls may simply be one that responds quickly to FDA pressure, while a firm with few recalls may have unresolved issues that have not yet surfaced in MDR volumes.
Cross-References to Related Databases
Device recall analysis rarely stands alone. The key related databases are:
FDA 510(k) clearances at api.fda.gov/device/510k.json — linking recalls to clearance decisions reveals the predicate lineage and the evidentiary standard under which the device entered the market.
FDA FAERS at api.fda.gov/drug/event.json — while FAERS covers drugs rather than devices, combination products (drug-device combinations like drug-eluting stents and prefilled syringes) may generate both FAERS adverse event reports and MAUDE device event reports simultaneously, requiring cross-database reconciliation.
CPSC product recalls at cpsc.gov/recalls — the Consumer Product Safety Commission handles recalls for consumer products that are not legally classified as medical devices. The line can be thin: a blood pressure cuff marketed for home use without diagnostic claims falls under CPSC; one marketed with diagnostic claims falls under FDA. Some products straddle the boundary and have appeared in both databases.
FDA Warning Letters database at fda.gov/inspections-compliance-enforcement-and-criminal-investigations/compliance-actions-and-activities/warning-letters — warning letters often precede or accompany major recall actions and provide the FDA's factual findings on quality system failures in more detail than recall records alone contain.
Related writing
FDA 510(k): The Medical Device Clearance Database Behind 5,000 Annual Market Approvals— how the substantial-equivalence pathway clears devices without clinical trials, the predicate daisy-chain problem, and queries against the 510(k) API.
FDA FAERS: The Adverse Drug Event Database Behind Post-Market Drug Safety— how the seven-file FAERS schema works, MedDRA terminology, and disproportionality analysis for signal detection.
FDA Warning Letters: The Enforcement Signal Hidden in Plain Sight— how warning letters are issued, what they reveal about quality system failures, and how to build a firm-level enforcement signal from the bulk data.