Technical writing
FDA Device Classification Database: The Federal System Behind Every Medical Device Type
The FDA Product Classification database is the master index of American medical devices — not a list of individual products, but a taxonomy of roughly 7,058 device types, each pinned to a three-letter product code, a risk class, a regulation number in the Code of Federal Regulations, a medical specialty review panel, and the premarket pathway a manufacturer must clear to sell it. It is the schema beneath every 510(k) clearance, every premarket approval, every device registration, and every adverse-event report in the FDA's device ecosystem.
When a company wants to bring a new blood glucose meter, a hip implant, an infusion pump, or an artificial-intelligence radiology tool to market, the first question is never “is it approved?” but “what is it?” The answer is a product code. That three-letter code identifies the device type, and the device type determines the risk class, the controls the device must meet, and the road to market. The Product Classification database is where those determinations live. It is published through the openFDA program at the device/classification.json endpoint and mirrors the FDA's public Product Classification lookup tool. Master the product code and you hold the join key that stitches the entire device landscape together: clearances, approvals, registrations, recalls, and the device safety reports in the MAUDE database all reference it.
What it is and the risk-based classification system
The Medical Device Amendments of 1976 gave the FDA authority over medical devices and created the framework that still governs them: a risk-based classification system that sorts every device type into one of three classes according to the level of regulatory control needed to provide a reasonable assurance of safety and effectiveness. The classification is not a judgment about an individual product's quality; it is a judgment about the device type. Every device of a given type inherits the class, the controls, and the pathway that the FDA has assigned to that type.
The Product Classification database is the operational record of those assignments. Each row is a single device type. The device_name field carries the generic name — not a brand name, but a description such as “catheter, intravascular, therapeutic, long-term greater than 30 days” or “system, image processing, radiological.” The device_class field holds the risk class, stored as 1, 2, or 3 (a handful of legacy entries are unclassified or marked not classified). Alongside sit the regulation number, the medical specialty, the premarket submission type, and a set of boolean flags that capture whether the device type is exempt from Good Manufacturing Practice requirements, whether it is an implant, whether it is life-sustaining or life-supporting, and whether it is eligible for third-party review.
Class I is the lowest-risk tier. These device types are subject to general controls only — the baseline statutory requirements that apply to all devices: establishment registration and device listing, adherence to the Quality System Regulation, proper labeling, prohibitions on adulteration and misbranding, and adverse-event reporting. General controls are considered sufficient on their own to assure the safety and effectiveness of these devices. Elastic bandages, manual surgical instruments, examination gloves, bedpans, and tongue depressors are canonical Class I examples. The great majority of Class I device types are exempt from premarket review entirely, and many are also exempt from large portions of the Quality System Regulation, which is exactly what the GMP-exempt flag records.
Class II is the moderate-risk tier and the largest by volume. For these device types, general controls alone are deemed insufficient to assure safety and effectiveness, so the FDA layers on special controls — device-specific requirements that may include performance standards, mandatory testing, specific labeling, postmarket surveillance, patient registries, or FDA-issued guidance documents tailored to the device type. Most Class II devices reach the market through the premarket notification process known as a 510(k), in which the manufacturer demonstrates that the new device is substantially equivalent to a legally marketed device of the same type. Powered wheelchairs, infusion pumps, many catheters, blood glucose meters, surgical drapes, diagnostic ultrasound equipment, and a large share of in vitro diagnostic tests are Class II.
Class III is the highest-risk tier: device types that support or sustain human life, are of substantial importance in preventing impairment of health, or present a potential unreasonable risk of illness or injury. For these, neither general nor special controls are considered adequate to assure safety and effectiveness, so the FDA requires premarket approval (PMA) — the most stringent pathway, demanding scientific evidence, typically from clinical trials, that the specific device is safe and effective for its intended use. Implantable pacemakers and defibrillators, heart valves, coronary stents, many implantable neurostimulators, and certain high-risk diagnostic tests are Class III. A PMA approval is product-specific, not a clearance of a device type, which is why Class III device types map to a different downstream dataset than Class I and II.
The three-letter product code as the join key
The product code is the single most useful field in the entire FDA device data ecosystem, and understanding why is the key to using any of it. The code is a three-letter identifier —DQA for a glucose test system, DXY for a powered wheelchair, LWS for a permanent pacemaker electrode, QAS for a radiological computer-assisted detection device, and so on. Each code corresponds to one row in the classification database, and therefore to exactly one risk class, one regulation number, one review panel, and one default pathway. The code is the device type rendered as a primary key.
Because the same product code is carried on records throughout the FDA's device systems, it functions as a foreign key that joins them. A 510(k) clearance record in the device/510k.json endpoint carries the product code of the device cleared. A premarket approval record in device/pma.json carries it. An establishment registration and device listing in device/registrationlisting.json carries it. A device recall in device/enforcement.json and a recall record in device/recall.json carry it. And a device adverse-event report in the MAUDE database, exposed at device/event.json, carries it as well. The product code is the thread that runs through all of them.
This is what makes the classification database so much more than a reference table. On its own it tells you what every device type is. Joined on product code to the other endpoints, it lets you ask questions that span the regulatory lifecycle: how many devices of a given type have been cleared, how many have been recalled, how many adverse events have been reported, and how those volumes compare across risk classes and specialties. The classification record supplies the class and the specialty; the other datasets supply the activity. The join turns a static taxonomy into a map of where the risk and the volume actually sit.
The regulation number and 21 CFR Parts 862 through 892
Every classified device type is created by a regulation, and the regulation_number field cites it. The number takes the form of a part and section in Title 21 of the Code of Federal Regulations — for example 870.1130 or 862.1345. The codified regulation does real work: it names the device, states its intended use, assigns the class, and, for Class II devices, identifies the special controls. Reading the regulation is how a manufacturer or analyst confirms exactly what the FDA means by a device type and what is required to market it.
The device regulations are organized by medical specialty into parts numbered 862 through 892. The part number is itself informative because it maps directly to a medical field. Part 862 covers clinical chemistry and clinical toxicology devices; 864 hematology and pathology; 866 immunology and microbiology; 868 anesthesiology; 870 cardiovascular devices; 872 dental; 874 ear, nose, and throat; 876 gastroenterology and urology; 878 general and plastic surgery; 880 general hospital and personal use; 882 neurological devices; 884 obstetrical and gynecological; 886 ophthalmic; 888 orthopedic; 890 physical medicine; and 892 radiology. A product code whose regulation begins with 870 is a cardiovascular device; one beginning with 888 is orthopedic. The part number and the medical specialty field encode the same fact from two directions.
The pathways: 510(k), De Novo, PMA, and exempt
The classification of a device type implies a default route to market, and the database records the intended pathway in its submission-type field. There are four principal routes, and they line up closely with the risk classes.
The 510(k) premarket notification is the workhorse pathway and the route for most Class II devices. Rather than proving safety and effectiveness from first principles, the manufacturer demonstrates that the new device is substantially equivalent to a legally marketed predicate device — one with the same intended use and the same technological characteristics, or different characteristics that do not raise new questions of safety and effectiveness. A successful 510(k) results in a clearance, not an approval, and the device may then be marketed. The predicate-based logic is efficient but creates a lineage: many devices on the market trace their clearance back through a chain of predicates, which is one reason the 510(k) program is perennially debated.
The De Novo pathway exists for genuinely novel device types that are low or moderate risk but have no suitable predicate, so a 510(k) is impossible and a full PMA would be disproportionate. A De Novo request asks the FDA to classify the new device type into Class I or Class II based on the risk it actually presents. A granted De Novo does two things at once: it authorizes the specific device, and it creates a brand-new product code and classification regulation that future devices of the same type can then use as a 510(k) predicate. Many of the newest entries in the classification database — including a large share of software and AI-enabled device types — originate as De Novo grants.
Premarket approval (PMA) is the pathway for Class III devices. It requires the manufacturer to submit valid scientific evidence, generally including clinical data, establishing that the specific device is safe and effective for its intended use. A PMA is an approval of a particular product, complete with its own approval order and conditions, rather than a clearance of a device type. Related to the PMA is the Humanitarian Device Exemption, a route for devices treating conditions affecting small patient populations, where demonstrating probable benefit is permitted in place of the full effectiveness showing a PMA demands.
Finally, many Class I and a smaller number of Class II device types are exempt from premarket review altogether. An exempt device type still must comply with general controls — registration, listing, labeling, and, unless separately exempted, the Quality System Regulation — but the manufacturer need not submit a 510(k) before marketing, subject to limitations that prevent an exemption from being stretched to cover a materially different or higher-risk device. The exemptions are what keep the FDA from having to review every bandage and tongue depressor, and they are recorded in the classification database both through the submission type and through the GMP-exempt flag.
Medical specialty panels
Every device type is assigned to a medical specialty, captured in the medical_specialty_description field and abbreviated in a companion specialty code. The specialty corresponds to the FDA advisory committee, or device panel, that has expertise in that clinical area — Cardiovascular, Orthopedic, Radiology, Clinical Chemistry, Neurology, General and Plastic Surgery, Gastroenterology and Urology, Ophthalmic, Dental, Hematology, Immunology, Anesthesiology, Obstetrics and Gynecology, Ear Nose and Throat, Physical Medicine, General Hospital, Microbiology, Pathology, and Toxicology among them. These panels are the same divisions reflected in the 21 CFR part structure, so the specialty and the regulation part are two encodings of the same organizing principle.
The specialty field is what lets an analyst slice the device universe by clinical domain. It answers questions such as how many distinct device types exist in cardiology versus radiology, which specialties are dominated by Class II 510(k) devices versus Class III PMA devices, and where new device types are being created fastest. When advisory committees convene to weigh a novel device or a safety concern, it is the panel named by this field that does the convening. The specialty is, in effect, the FDA's organizational chart projected onto the device taxonomy.
How AI/ML-enabled devices and Software as a Medical Device are classified
Software has become one of the most consequential and fastest-moving corners of the classification database. The FDA regulates software that meets the definition of a medical device — Software as a Medical Device, or SaMD — under the same risk-based framework as physical devices, and an algorithm that aids diagnosis or treatment is classified by the same logic of product code, risk class, regulation number, and pathway. A piece of clinical software is not a special category sitting outside the system; it is a device type with a product code like any other.
The risk class of a software device follows the consequences of its output and the seriousness of the clinical situation. Software that informs clinical management in a non-critical setting tends toward Class II; software that drives or directly affects decisions in a serious or critical condition can rise toward higher controls. Computer-assisted detection and diagnosis tools in radiology, software that triages images for review priority, algorithms that detect arrhythmias from physiological signals, and clinical decision-support functions that cross the line into device territory all carry their own product codes. Many of the most novel AI-enabled device types entered the database through the De Novo pathway, which then established product codes and special controls that subsequent AI-enabled devices of the same type can cite as 510(k) predicates — the same predicate mechanics that govern hardware, now applied to algorithms.
Adaptive and machine-learning models pose a structural challenge the classification framework was not originally built for: a model that continues to learn can change after it is authorized, and the device the FDA cleared may not be the device a hospital is running a year later. The FDA has responded with the concept of a predetermined change control plan, which lets a manufacturer specify in advance the modifications a model may undergo — and the methods used to validate them — so that certain anticipated changes need not trigger a new marketing submission. The classification record still anchors the device type and its risk class; the change control plan governs how the authorized device is allowed to evolve within that classification. For anyone analyzing the device landscape, the practical consequence is that the count of AI-enabled device types and product codes is growing quickly, and the regulatory framework around them is still settling.
What you can do with it
The classification database is most powerful as the backbone of analyses that join it to the rest of the device ecosystem. At the simplest level, it lets you map the device landscape by class and specialty: count the distinct device types in each risk tier, see how those types distribute across clinical panels, and identify which specialties are dominated by low-risk exempt devices versus high-risk PMA devices. That map alone is useful for anyone trying to understand the structure of a therapeutic area or size a market by regulatory category.
A second use is pathway analysis: because the database records the intended submission type and the exemption flags for every device type, you can determine which product codes require a PMA, which go through a 510(k), which are exempt, and which originated as De Novo classifications. This is the starting point for any regulatory strategy — knowing the route a device type demands before committing to a development program — and for studying how the mix of pathways differs across specialties and how it has shifted as new device types appear.
The richest use is risk and activity profiling through joins on the product code. Join the classification record to the 510(k) endpoint and you can rank device types and specialties by clearance volume, surfacing the busiest and most competitive device categories. Join it to MAUDE and you can attach adverse-event counts to each device type, then sort to find the device types with the highest reported harm — and cross those against class and clearance volume to see whether the most-reported device types are the high-risk Class III implants you would expect or high-volume Class II devices whose sheer prevalence drives the totals. Join it to the recall endpoints and you can ask which device types and specialties generate the most recalls. In each case the classification record supplies the context — what the device type is, how risky the FDA considers it, which panel owns it — and the other dataset supplies the signal.
A worked Python example
The openFDA device endpoints share a compact query language over a simple REST interface. The search parameter accepts field-scoped expressions joined with +AND+ and +OR+, exact-match phrases via the .exact suffix, and range queries in bracket syntax. The count parameter returns server-side term frequencies for a field without transferring individual records, which is the efficient way to tally, for example, 510(k) clearances by product code. For record-level retrieval, limit and skip page through results, with skip capped at 25,000. The classification list is small enough to download in full; the 510(k) corpus is large, so we tally it server-side rather than pulling every record. No API key is required for light use; registering for a free key raises the limits substantially.
The script below pulls the full classification list, sizes it by class, builds a product-code crosswalk to class, specialty, regulation number, and submission type, then uses a single count query to get 510(k) volume per product code. It joins the two, ranks medical specialties by 510(k) volume, surfaces the Class II product codes with the most clearance activity, and profiles how the device universe splits across premarket pathways.
import requests
import pandas as pd
from collections import defaultdict
# ---------------------------------------------------------------
# openFDA Device Classification + 510(k) APIs
# Classification endpoint: https://api.fda.gov/device/classification.json
# 510(k) endpoint: https://api.fda.gov/device/510k.json
#
# No API key required for <= 240 requests/min and 1,000/day.
# Register at https://open.fda.gov/apis/authentication/ for
# 120,000 requests/day and a higher per-minute ceiling.
#
# This script:
# 1. Pulls the full device classification list (one row per
# product code) and sizes it by device class.
# 2. Builds a crosswalk from product code -> class, specialty,
# regulation number, and premarket submission type.
# 3. Uses a count query to get 510(k) clearance volume per
# product code without downloading individual clearances.
# 4. Joins the two, then ranks specialties and surfaces the
# Class II product codes with the most 510(k) activity.
# ---------------------------------------------------------------
CLASS_URL = "https://api.fda.gov/device/classification.json"
K510_URL = "https://api.fda.gov/device/510k.json"
def fetch_all(url: str, search: str | None = None, page_size: int = 1000) -> list[dict]:
"""Page through an openFDA endpoint with limit/skip.
openFDA caps skip at 25,000, so any single search must resolve to
fewer than that many records. The classification list is well under
the cap, so one search retrieves it in full.
"""
records: list[dict] = []
skip = 0
while True:
params = {"limit": page_size, "skip": skip}
if search:
params["search"] = search
resp = requests.get(url, params=params, timeout=60)
if resp.status_code == 404: # openFDA returns 404 on empty result sets
break
resp.raise_for_status()
batch = resp.json().get("results", [])
if not batch:
break
records.extend(batch)
print(f" Fetched {len(records):,} records so far...")
if len(batch) < page_size or skip + page_size >= 25000:
break
skip += page_size
return records
def count_field(url: str, field: str, search: str | None = None) -> dict:
"""Server-side term frequencies via the openFDA count parameter.
Returns aggregate counts without transferring individual records --
the efficient way to tally 510(k) volume by product code.
"""
params = {"count": field}
if search:
params["search"] = search
resp = requests.get(url, params=params, timeout=60)
if resp.status_code == 404:
return {}
resp.raise_for_status()
results = resp.json().get("results", [])
return {row["term"]: row["count"] for row in results}
# ---------------------------------------------------------------
# Step 1: Pull the full classification list and size it by class.
# Each record is one device type keyed by product_code.
# ---------------------------------------------------------------
print("Fetching the FDA device classification list...")
rows = fetch_all(CLASS_URL)
clf = pd.DataFrame(rows)
print(f"Retrieved {len(clf):,} device classification records.")
# device_class is "1", "2", or "3"; map to the familiar Roman numerals.
ROMAN = {"1": "Class I", "2": "Class II", "3": "Class III", "U": "Unclassified", "N": "Not classified"}
clf["class_label"] = clf["device_class"].map(ROMAN).fillna("Other")
print("\nDevice Types by Class")
print("-" * 32)
for label in ["Class I", "Class II", "Class III", "Unclassified", "Not classified", "Other"]:
n = int((clf["class_label"] == label).sum())
if n:
print(f"{label:<16} {n:>6,}")
print(f"{'TOTAL':<16} {len(clf):>6,}")
# ---------------------------------------------------------------
# Step 2: A product-code -> attributes crosswalk.
# medical_specialty_description names the review panel;
# regulation_number is the 21 CFR citation.
# ---------------------------------------------------------------
keep = [
"product_code", "device_name", "class_label", "regulation_number",
"medical_specialty_description", "submission_type_id",
"gmp_exempt_flag", "implant_flag", "life_sustain_support_flag",
"third_party_flag",
]
crosswalk = clf[[c for c in keep if c in clf.columns]].copy()
crosswalk = crosswalk.set_index("product_code")
print(f"\nCrosswalk covers {crosswalk.index.nunique():,} unique product codes.")
# ---------------------------------------------------------------
# Step 3: 510(k) clearance volume per product code.
# A single count query returns counts for every code at once.
# ---------------------------------------------------------------
print("\nCounting 510(k) clearances per product code...")
k510_counts = count_field(K510_URL, "product_code.exact")
print(f"Product codes with at least one 510(k): {len(k510_counts):,}")
total_510k = sum(k510_counts.values())
print(f"Total 510(k) clearances counted: {total_510k:,}")
# ---------------------------------------------------------------
# Step 4: Join 510(k) volume onto the classification crosswalk.
# ---------------------------------------------------------------
crosswalk["k510_count"] = (
pd.Series(k510_counts, name="k510_count")
.reindex(crosswalk.index)
.fillna(0)
.astype(int)
)
# Aggregate 510(k) volume by medical specialty panel.
by_specialty = (
crosswalk.groupby("medical_specialty_description")["k510_count"]
.sum()
.sort_values(ascending=False)
.head(15)
)
print("\nTop 15 Specialties by 510(k) Clearance Volume")
print("-" * 56)
print(f"{'Specialty panel':<40} {'510(k)s':>12}")
print("-" * 56)
for spec, n in by_specialty.items():
label = (spec or "Unspecified")[:39]
print(f"{label:<40} {n:>12,}")
# ---------------------------------------------------------------
# Step 5: The Class II device types with the most 510(k) activity.
# Class II is where 510(k) substantial equivalence lives, so
# these are the busiest competitive device categories.
# ---------------------------------------------------------------
class2 = crosswalk[crosswalk["class_label"] == "Class II"]
top_codes = class2.sort_values("k510_count", ascending=False).head(15)
print("\nTop 15 Class II Product Codes by 510(k) Volume")
print("-" * 78)
print(f"{'Code':<6} {'510(k)s':>8} {'21 CFR':<10} {'Device name':<44}")
print("-" * 78)
for code, r in top_codes.iterrows():
reg = str(r.get("regulation_number", "") or "")
name = str(r.get("device_name", "") or "")[:43]
print(f"{code:<6} {int(r['k510_count']):>8,} {reg:<10} {name:<44}")
# ---------------------------------------------------------------
# Step 6 (illustrative): which codes require PMA vs 510(k)?
# submission_type_id encodes the premarket route. Counting it
# shows how the device universe splits across pathways.
# ---------------------------------------------------------------
# submission_type_id values (per the openFDA data dictionary):
# 1 = 510(k) 2 = PMA
# 3 = (reserved) 4 = HDE (humanitarian)
# 8 = exempt / other (codes vary; treat as a hint, not gospel)
SUBMISSION = defaultdict(lambda: "Other/unknown")
SUBMISSION.update({"1": "510(k)", "2": "PMA", "4": "HDE", "8": "Exempt/other"})
if "submission_type_id" in crosswalk.columns:
route = crosswalk["submission_type_id"].astype(str).map(SUBMISSION)
print("\nDevice Types by Premarket Submission Type")
print("-" * 40)
for label, n in route.value_counts().items():
print(f"{label:<18} {n:>6,}")
The pattern generalizes directly. Swap the device/510k.json count for a count against device/event.json on device.device_report_product_code.exact to attach MAUDE adverse-event volume to each product code, then sort within Class III to find the high-risk device types driving the most safety reports. Point the count at device/enforcement.json to rank device types by recall count. Or filter the classification crosswalk to a single specialty — say cardiovascular, by selecting regulation numbers that begin with 870 — and profile the pathways and clearance volumes within one clinical domain. The classification record is the spine; each additional endpoint adds a dimension of activity hung off the same product code.
Caveats and limits
Three limits shape any honest use of this dataset. First, classification is not static. The FDA can and does reclassify device types — moving a device type from Class III to Class II as evidence accumulates and special controls mature, or in rarer cases up-classifying a type that has proven more hazardous than its original assignment assumed. New device types are created continuously, especially through De Novo grants, and obsolete ones persist in the record. The class attached to a product code is the current classification, and a longitudinal analysis that assumes a device type has always sat in its present class can misread history. The advent of software and AI device types has accelerated this churn at the leading edge of the database.
Second, the product code itself drifts. New codes are minted as device types are recognized; codes are occasionally split when a category is subdivided or consolidated when types merge; and a single physical product can legitimately carry more than one product code when it spans multiple intended uses. Codes are also sometimes assigned inconsistently across submissions by different manufacturers and reviewers. Because every join in the device ecosystem runs on the product code, this drift propagates: a clean join on a current code can silently miss records filed under a predecessor code or an adjacent code for what is functionally the same device type. Serious analyses reconcile related codes rather than trusting a single code to capture an entire device category.
Third, software and AI devices are genuine edge cases for a framework designed around physical products. The boundary between a regulated SaMD and unregulated clinical or wellness software is nuanced and has shifted with statute and guidance, so the set of software device types in the database reflects regulatory line-drawing as much as technological reality. Risk classification of an algorithm depends on its intended use and clinical context in ways that are harder to read off a product code than for a catheter or an implant, and the machinery for governing models that change after authorization — predetermined change control plans foremost among them — is still maturing. Treated with those caveats in mind, the Product Classification database remains the authoritative, openly accessible map of what the FDA regulates as a medical device, how risky it considers each device type, and the pathway each must travel to reach patients.
Related writing
FDA food enforcement reports is the FDA's parallel recall dataset for food and cosmetics, built on the same agency's classification logic but graded by health hazard rather than by device risk class.
NHTSA vehicle complaints is the consumer-safety and defect-investigation pipeline for motor vehicles, where complaint patterns trigger recalls much as device adverse events feed back into FDA oversight.
CMS physician and provider data is the federal record of the clinicians who use these devices, a complementary lens on the same healthcare system from the provider side.