FDA 510(k): The Medical Device Clearance Database Behind 5,000 Annual Market Approvals

Each year the FDA clears roughly 5,000 medical devices through the 510(k) premarket notification pathway—without requiring clinical trials in the vast majority of cases. The legal basis is substantial equivalence: a manufacturer argues that its new device is as safe and effective as a device already legally marketed before 1976 or previously cleared through the same process. The FDA publishes every clearance decision in a public database stretching back to the program's origin, and the full dataset is accessible through the OpenFDA API. Understanding what the database contains— and what the clearance process does and does not prove—is essential for anyone analyzing medical device safety, competitive intelligence, or regulatory journalism.

This article covers the three-tier device classification system that determines which regulatory pathway a device must follow, the mechanics of the 510(k) substantial equivalence review, the data fields in the FDA's 510(k) database and how to access them in bulk, the predicate daisy-chain problem that allows clearance lineages to trace back to demonstrably unsafe original devices, the De Novo classification pathway for novel low-to-moderate risk devices, the most significant clearance controversies including metal-on-metal hip implants and vaginal mesh, a Python walkthrough using the OpenFDA device API, and how journalists and researchers use 510(k) data to investigate rapid clearance patterns and post-market performance.

The three-class device system

The Medical Device Amendments of 1976 established a risk-stratified classification framework that assigns every medical device to one of three classes. The class determines the regulatory controls required for market entry and post-market oversight.

Class I devices present low risk to patients. They are subject to general controls—the baseline requirements of the Federal Food, Drug, and Cosmetic Act, including registration, listing, labeling, and good manufacturing practice under 21 CFR Part 820. The overwhelming majority of Class I devices are exempt from premarket notification: bandages, examination gloves, tongue depressors, and most manual surgical instruments fall here. A small subset of Class I devices for which general controls alone are insufficient requires a 510(k) submission, but this is the exception rather than the rule. Roughly 47 percent of device types are classified as Class I.

Class II devices present moderate risk and require special controls in addition to general controls. Special controls may include mandatory performance standards, post-market surveillance requirements, patient registries, special labeling requirements, or guidance documents specifying acceptable test methods. Class II devices must obtain 510(k) clearance—the substantial equivalence review—before they can be marketed. This class covers the broadest range of commercially significant devices: infusion pumps, powered wheelchairs, diagnostic imaging software, contact lenses, blood glucose monitors, and most orthopedic implants. Approximately 43 percent of device types are Class II.

Class III devices present the highest risk and include devices that support or sustain human life, are implanted in the body, or present potential unreasonable risk of illness or injury. Class III devices require Premarket Approval—PMA—the most stringent regulatory pathway. A PMA application requires valid scientific evidence, typically including clinical trials, that provides reasonable assurance that the device is safe and effective. Examples include implantable pacemakers, deep brain stimulators, total artificial hearts, and cochlear implants. PMA approval is functionally analogous to new drug approval; the FDA's standard is not substantial equivalence but demonstrated safety and effectiveness backed by clinical data. About 10 percent of device types are Class III.

The classification of a specific device type is defined by regulation in 21 CFR Parts 862 through 892, organized by medical specialty panel. A device that does not fit any existing classified type is automatically treated as Class III until reclassified— this is the statutory default for novel devices and the situation that the De Novo pathway was created to address.

The 510(k) clearance process

A 510(k) submission is a notification to the FDA, not an application for approval. The distinction matters: 510(k) clearance means the FDA has determined that a device is substantially equivalent to a predicate device, not that the FDA has independently determined the device to be safe and effective. The legal standard in Section 510(k) of the FD&C Act is substantial equivalence, a narrower and less demanding standard than the safety-and-effectiveness standard applied to drugs and Class III devices.

To demonstrate substantial equivalence, the submitter must identify a predicate device—a device legally marketed in the United States. The predicate may be a device marketed before the 1976 Amendments (a “preamendments device”), a device previously cleared through 510(k), or a device reclassified down from Class III. The submitter then shows that the new device has the same intended use as the predicate and either has the same technological characteristics, or has different technological characteristics that do not raise new questions of safety and effectiveness and the device is at least as safe and effective as the predicate.

Three types of 510(k) submissions exist. A Traditional 510(k) is the standard pathway, requiring a full summary of the intended use, the predicate comparison, test data, and labeling. A Special 510(k) is a streamlined pathway for modifications to a manufacturer's own legally marketed device—it relies on design controls under the Quality System Regulation rather than a full predicate comparison and the FDA targets a 30-day review. An Abbreviated 510(k) relies on FDA guidance documents, special controls, or recognized consensus standards to streamline the demonstration of substantial equivalence for device types where the FDA has already specified the acceptable performance benchmarks.

After submission the FDA has 90 days to make a decision, though the clock can be stopped while additional information is requested. The decision is binary: the FDA issues a letter finding the device Substantially Equivalent (SE) and cleared for marketing, or finding it Not Substantially Equivalent (NSE) and not cleared. Applicants may also withdraw their submission (W) during review. The SE letter is the “clearance”—it authorizes commercial distribution. The cleared device is then added to the public 510(k) database with its K-number, a unique identifier in the format K followed by a two-digit year and five-digit sequence number.

What the 510(k) database contains

The FDA's 510(k) database at accessdata.fda.gov/scripts/cdrh/cfdocs/cfpmn/pmn.cfm provides a searchable interface to every 510(k) submission on record. Each entry includes a standardized set of fields that together define the regulatory history of the cleared device.

The K-number is the primary identifier, formatted as K followed by the two-digit year and a five-digit sequence number (for example, K231234 for the 1,234th submission received in 2023). The K-number is how cleared devices are referenced in scientific literature, legal filings, and subsequent 510(k) submissions that cite the device as a predicate.

The device name is the commercial or generic name of the device as submitted by the applicant. It is not standardized—the same physical device category can appear under dozens of naming conventions across different applicants. The applicant name is the legal entity submitting the notification, which may be the manufacturer, a US agent for a foreign manufacturer, or a third-party submitter.

The date received and decision date record when the submission arrived at the FDA and when the SE/NSE letter was issued. The interval is the effective review time. The FDA product codeis a three-letter code that identifies the device type within the FDA's classification system—this is the field that enables comparisons across manufacturers within the same device category. The device class records Class I, II, or III as determined for the product code. The specialty or advisory committee field identifies which of the FDA's device panels (Cardiovascular, Orthopedic, Radiology, General Hospital, and so on) has jurisdiction.

The decision field is SE (cleared), NSE (not cleared), or W (withdrawn). The 510(k) type distinguishes Traditional, Special, and Abbreviated submissions. The database also records whether a 510(k) Summary or 510(k) Statement is available—these are documents the applicant must provide, either a summary of the submission's safety and effectiveness information (Summary) or a statement that this information will be provided directly to any person on request (Statement). Summaries are the more useful for research since they disclose the predicate comparison and supporting data.

Accessing the data: web interface and OpenFDA API

The web-based 510(k) database at accessdata.fda.gov supports searches by K-number, applicant name, device name, product code, date range, and decision type. For individual lookups and targeted research it is serviceable, but it has no bulk export function and returns results in paginated HTML that requires scraping for any large-scale analysis.

The OpenFDA device/510k endpoint at api.fda.gov/device/510k.json provides the same data through a RESTful API with full-text search, field filtering, and a count aggregation endpoint. The API exposes all cleared and not-cleared decisions with the same fields available in the web interface. Unauthenticated requests are rate-limited to 240 per minute; API keys are free and raise the limit substantially. The count endpoint supports aggregation by any field, making it straightforward to compute clearance volume by product code, decision year, decision type, or applicant without downloading raw records. The search endpoint supports Boolean queries and field-level filters using Lucene-style syntax.

The FDA also maintains a downloadable device database file—the “Device Classification” and “510(k) Cleared Devices” flat files—at fda.gov/medical-devices/device-approvals-denials-and-clearances. These are pipe-delimited text files covering the full historical record and are the most practical starting point for bulk analysis that needs to join clearance records to product code classification data.

The predicate daisy-chain problem

The 510(k) pathway's reliance on predicate devices creates a structural vulnerability that critics have called the predicate daisy chain. A device cleared via 510(k) can itself serve as a predicate for subsequent devices. Those devices can serve as predicates for still later devices. Because predicates can chain backward indefinitely, a device cleared in 2024 may be, several links back in its clearance lineage, equivalent to a device marketed before 1976—before modern safety testing standards existed—or to a device that was subsequently recalled or found to be unsafe.

The legal consequence is counterintuitive. If device A is cleared via substantial equivalence to predicate B, and predicate B was later recalled for safety failures, device A retains its clearance unless the FDA affirmatively takes action to withdraw it. The predicate's subsequent safety record does not automatically invalidate the clearances that relied on it. This means that a recall of a widely used predicate device does not cascade forward through its clearance children without explicit FDA intervention—and the FDA has limited tools to identify all devices in a predicate chain automatically.

Research published in JAMA Internal Medicine and subsequent academic work has traced clearance chains for specific device categories and found predicate lineages spanning 40 years and dozens of links, sometimes terminating in preamendments devices for which there is no modern safety or performance data at all. The FDA's own reports on 510(k) reform have acknowledged that the predicate chain system can allow device technology to drift substantially from the original predicate while remaining nominally “substantially equivalent.” The 510(k) Summary documents disclose the direct predicate but not the full chain, so reconstructing a complete lineage requires programmatic traversal of the database across multiple generations.

The De Novo pathway for novel devices

The De Novo classification pathway, established by the Food and Drug Administration Modernization Act of 1997 and significantly strengthened by the FDA Safety and Innovation Act of 2012, provides an alternative route to market for novel devices that present low to moderate risk but have no clear predicate in the existing 510(k) database. Without De Novo, such devices would automatically be classified as Class III and subject to PMA requirements—a burden disproportionate for genuinely low-risk technology.

A manufacturer requesting De Novo classification submits a request that includes the device's intended use, a risk-benefit analysis, proposed special controls, and performance data sufficient to demonstrate safety and effectiveness for the proposed classification. If the FDA grants the request, it issues a De Novo order creating a new device type classification. That classification can then serve as a predicate for future 510(k) submissions—the De Novo device becomes the “anchor” for a new predicate lineage.

De Novo has become the intended pathway for software as a medical device (SaMD)— clinical decision support software, AI-based diagnostic tools, and mobile medical applications that present moderate risk but have no hardware predicate. The FDA has granted De Novo orders for software that analyzes retinal images for diabetic retinopathy, electrocardiogram waveforms for arrhythmia detection, and radiology images for time-sensitive conditions. Each grant establishes a new classification that becomes the predicate anchor for subsequent AI diagnostic tools seeking 510(k) clearance. The accumulating De Novo classifications for SaMD have in practice created a new predicate ecosystem for AI-based diagnostics that is only a few years old, with correspondingly limited post-market performance data to evaluate.

Notable clearance controversies

Two cases became emblematic of the structural limitations of 510(k) clearance and drove significant legislative and regulatory attention to the program.

Metal-on-metal hip implants. Total hip replacement systems incorporating metal-on-metal articulation—where both the ball and socket surfaces are metal alloys—were cleared through the 510(k) pathway in the 2000s based on substantial equivalence to earlier orthopedic implants. Clinical trials were not required; the clearance rested on bench testing and the predicate comparison. After implantation in hundreds of thousands of patients worldwide, metal-on-metal hips proved to generate metallic debris from the articulating surfaces, causing a condition called adverse local tissue reaction (ALTR) or metallosis. ALTR could progress to tissue necrosis, bone loss, implant failure, and elevated blood metal ion levels with potential systemic effects. Major manufacturers including DePuy (Johnson & Johnson) and Stryker issued recalls affecting specific metal-on-metal designs. DePuy's ASR Hip Resurfacing System recall in 2010 became the largest single medical device recall in FDA history at the time. The Government Accountability Office and the Institute of Medicine both published reports criticizing the 510(k) pathway's inability to detect risks that emerge only from long-term clinical use in large patient populations.

Surgical mesh for pelvic organ prolapse and stress urinary incontinence. Transvaginal surgical mesh products were cleared via 510(k) beginning in the 1990s, with the submissions relying on predicates going back to abdominal hernia mesh products that had never been clinically evaluated for transvaginal use. The 510(k) substantial equivalence standard did not require the manufacturers to demonstrate that the intended use—permanent implantation through the vaginal wall in proximity to complex pelvic anatomy—was safe in clinical practice. Post-market data accumulated over subsequent years showing rates of mesh erosion, chronic pain, dyspareunia, and the need for revision surgery that were substantially higher than the manufacturers had disclosed. Tens of thousands of patients filed lawsuits; multibillion-dollar settlements followed. In 2019 the FDA ordered manufacturers to stop selling transvaginal mesh for pelvic organ prolapse repair, effectively reclassifying the indication's risk level. The FDA subsequently required manufacturers seeking to market similar products to submit PMA applications—a retroactive reclassification acknowledging that the 510(k) pathway had been insufficient for the risk profile.

Both cases share a structural pattern: 510(k) clearance based on predicate comparison and bench performance testing, without clinical evidence of long-term safety in the actual patient population and indication; post-market harm emerging over years and affecting large numbers of patients before regulatory action; and eventual reclassification or recall after the evidence base that would have been required for PMA approval had accumulated through injury surveillance rather than pre-approval clinical trials.

Python: analyzing 510(k) clearances via the OpenFDA API

The following script uses the OpenFDA device/510k endpoint to aggregate clearance volume by year, retrieve raw records for a specific product code, compute the decision distribution, and estimate predicate chain depth within the retrieved dataset. The example uses product code FRN (hip prosthesis) as its target.

import requests
import pandas as pd
from collections import defaultdict

# ---------------------------------------------------------------
# OpenFDA 510(k) API
# Endpoint: https://api.fda.gov/device/510k.json
# No API key required for <= 240 requests/min; register for higher limits.
# ---------------------------------------------------------------

BASE = "https://api.fda.gov/device/510k.json"

def fetch_510k(params, limit=100):
    """Fetch a page of 510(k) records from OpenFDA."""
    params = dict(params)
    params["limit"] = limit
    resp = requests.get(BASE, params=params, timeout=30)
    resp.raise_for_status()
    return resp.json()

# ---------------------------------------------------------------
# 1. Count clearances by decision year using the count endpoint.
#    The count endpoint aggregates without returning raw records.
# ---------------------------------------------------------------

count_resp = requests.get(
    BASE,
    params={
        "search": "decision:SE",          # Substantially Equivalent decisions only
        "count": "decision_date",         # aggregate by decision_date field
        "limit": 1000,
    },
    timeout=30,
)
count_resp.raise_for_status()
count_data = count_resp.json()

# decision_date is a full date string; extract year manually
year_counts = defaultdict(int)
for entry in count_data.get("results", []):
    date_str = entry.get("term", "")
    year = date_str[:4] if len(date_str) >= 4 else "unknown"
    year_counts[year] += entry.get("count", 0)

year_df = pd.DataFrame(
    sorted(year_counts.items()),
    columns=["year", "se_clearances"]
)
print("SE clearances by year:")
print(year_df.to_string(index=False))

# ---------------------------------------------------------------
# 2. Fetch raw 510(k) records for a specific product code.
#    Product codes map to FDA device families (e.g., "FRN" = hip prosthesis).
#    K-number, applicant, device name, predicate, and decision are all present.
# ---------------------------------------------------------------

PRODUCT_CODE = "FRN"   # hip prosthesis — a historically controversial product code

records = []
skip = 0
page_size = 100

while True:
    try:
        data = fetch_510k(
            {
                "search": "product_code:" + PRODUCT_CODE,
                "skip": skip,
            },
            limit=page_size,
        )
    except requests.HTTPError as e:
        # OpenFDA returns 404 when skip exceeds total results
        if e.response is not None and e.response.status_code == 404:
            break
        raise

    batch = data.get("results", [])
    if not batch:
        break

    for r in batch:
        records.append({
            "k_number":       r.get("k_number", ""),
            "applicant":      r.get("applicant", ""),
            "device_name":    r.get("device_name", ""),
            "decision":       r.get("decision", ""),
            "decision_date":  r.get("decision_date", ""),
            "date_received":  r.get("date_received", ""),
            "predicate_knumber": r.get("predicate_510k", {}).get("predicate_number", "")
                                  if isinstance(r.get("predicate_510k"), dict)
                                  else "",
            "clearance_type": r.get("type", ""),
            "product_code":   r.get("product_code", ""),
            "specialty":      r.get("advisory_committee_description", ""),
        })

    skip += page_size
    total = data.get("meta", {}).get("results", {}).get("total", 0)
    if skip >= total:
        break

df = pd.DataFrame(records)
print("\nRecords for product code " + PRODUCT_CODE + ":", len(df))
print(df[["k_number", "applicant", "decision", "decision_date"]].head(10).to_string(index=False))

# ---------------------------------------------------------------
# 3. Analyze decision distribution for this product code.
# ---------------------------------------------------------------

decision_counts = df["decision"].value_counts()
print("\nDecision breakdown:")
print(decision_counts.to_string())

# SE  = Substantially Equivalent (cleared)
# NSE = Not Substantially Equivalent (not cleared)
# W   = Withdrawn by applicant

se_rate = (df["decision"] == "SE").sum() / len(df) * 100 if len(df) > 0 else 0
print("\nClearance rate (SE): " + str(round(se_rate, 1)) + "%")

# ---------------------------------------------------------------
# 4. Simple predicate chain depth estimator.
#    Build a dict of K-number -> predicate K-number, then walk chains.
# ---------------------------------------------------------------

predicate_map = {}
for _, row in df.iterrows():
    if row["k_number"] and row["predicate_knumber"]:
        predicate_map[row["k_number"]] = row["predicate_knumber"]

def chain_depth(knumber, pmap, visited=None):
    if visited is None:
        visited = set()
    if knumber in visited or knumber not in pmap:
        return 0
    visited.add(knumber)
    return 1 + chain_depth(pmap[knumber], pmap, visited)

df["chain_depth"] = df["k_number"].apply(lambda k: chain_depth(k, predicate_map))
print("\nPredicate chain depth distribution:")
print(df["chain_depth"].value_counts().sort_index().to_string())

How journalists and researchers use 510(k) data

The 510(k) database has become a standard tool for device-industry investigative journalism and regulatory research. Several analytical approaches have yielded published findings.

Predicate chain analysis traverses the disclosed predicate K-numbers recursively to map the full lineage of a cleared device. Investigators have used this technique to show that some currently marketed devices trace their equivalence claims back to devices that were subsequently recalled, reclassified, or that were themselves cleared based on preamendments devices with no modern safety data. The technique requires programmatically parsing 510(k) Summary documents—which are PDFs submitted at clearance time—since the structured database fields record only the direct predicate.

Rapid clearance pattern analysis examines whether certain product codes or manufacturers show unusually short review timelines, suggesting that submissions may be inadequately scrutinized. The date_received and decision_date fields in the OpenFDA API make this straightforward to compute at scale. Academic research has found that review times declined substantially in the 2010s and that devices cleared more quickly are not demonstrably safer or more effective than those subject to longer review— but they do show higher rates of subsequent recall.

Post-market performance cross-referencinglinks 510(k) K-numbers to MAUDE (the FDA's Manufacturer and User Facility Device Experience database of medical device adverse events) using the product code and applicant name as join keys. Cleared devices that appear frequently in MAUDE adverse event reports can be identified by combining the two databases. Similarly, 510(k) clearances can be cross-referenced to the FDA's device recall database to compute the recall rate by product code, clearance type, or review time— a methodology that has supported published analyses of 510(k) reform proposals.

The FDA has acknowledged the analytical uses of the 510(k) database in its own reform proposals. The Center for Devices and Radiological Health has considered mandatory disclosure of predicate chains beyond the direct predicate, structured machine-readable 510(k) summaries to replace PDFs, and automated flagging of submissions that rely on predicates with recall histories. Some of these proposals are in various stages of guidance development as of 2026. In the interim, the combination of the structured OpenFDA API data and the PDF 510(k) Summaries available through accessdata.fda.gov remains the most complete public record of how medical devices reach the American market.

Related writing

FDA Warning Letters: The Public Enforcement Record for 100,000+ Regulatory Actions — The FDA publishes every warning letter it sends on fda.gov — pharmaceutical cGMP violations, food HACCP failures, device 510(k) deficiencies, dietary supplement claims, and clinical investigator fraud. Here is the data structure, bulk access methods, and how to analyze 100,000+ enforcement actions by category and year.

FDA FAERS: The Adverse Drug Event Database Behind Post-Market Drug Safety — The FDA Adverse Event Reporting System holds more than 30 million reports of adverse drug reactions. Here is the seven-file relational schema, MedDRA coding, proportional reporting ratio signal detection, and how to download and deduplicate the bulk data.

CPSC Consumer Product Recalls: The Federal Safety Database Behind 400 Annual Recalls — The Consumer Product Safety Commission publishes every recall it announces through a structured public database. Here is what the fields mean, how recall risk assessments work, and how to use the CPSC API to track product safety patterns.