How to Search the FDA MAUDE Database (and What It Won't Tell You)

To search the FDA MAUDE database, open the FDA MAUDE web search at accessdata.fda.gov, enter a device brand name, manufacturer, or three-letter product code, set a date_received range, and open each result to read its narrative. For bulk or category-wide queries, use the openFDA API at /device/event.json instead.

The quick version, in five steps:

1. Open the FDA MAUDE search at accessdata.fda.gov.
2. Search by brand name, manufacturer, or product code. The three-letter product code is the most reliable way to pull a whole device category.
3. Filter by event type (death, injury, malfunction) and a date_received range.
4. Open individual reports and read the mdr_text narrative, where the clinical detail lives.
5. For more than a few hundred records, or anything you want to script, switch to the openFDA API.

That is the mechanics. The rest of this guide is about the part nobody warns you about: what those results do, and do not, mean.

Most people who open the MAUDE database close it again within five minutes. The interface is dated, the query fields are cryptic, the results are inconsistent, and the narratives are written by people who were not trying to be read. It is still the single largest public record of medical device adverse events in the world, and it is still where you should look first if you want to know what has gone wrong with a specific device.

#What MAUDE Actually Is

MAUDE stands for Manufacturer and User Facility Device Experience. It is the public search interface over reports submitted under the FDA's Medical Device Reporting regulation. Manufacturers, importers, device user facilities, and occasionally patients or clinicians file reports when a device is associated with death, serious injury, or certain malfunctions. Those reports flow into MAUDE, usually with a lag of several weeks to a few months.

MAUDE is not a recall database. Recalls are a separate system, tracked by the Center for Devices and Radiological Health under its own search. It is not a clearance database. 510(k) and PMA records live elsewhere. It is not a complete record of every bad outcome involving a medical device. It is the public surface of the reports that were submitted, which is a different thing from everything that happened. For a deeper discussion of that distinction, see our earlier post on what post-market surveillance in the U.S. actually is.

If you want to know what events a manufacturer disclosed, MAUDE is the right place. If you want to know the rate at which events occur, MAUDE alone will not get you there.

#The Three Front Doors

There are three reasonable ways to search MAUDE. They are good for different things.

The first is the FDA's own MAUDE web search, hosted under accessdata.fda.gov. It is the canonical interface and the one FDA staff use. It supports brand name, manufacturer, product code, event date range, event type, and a handful of other filters. It returns one report per row and links through to the full narrative. It is slow, and it paginates in a way that makes large queries painful, but it is authoritative.

The second is openFDA, which exposes MAUDE through a JSON API at /device/event.json. This is the interface to use when you want to script anything, pull more than a few hundred records, or apply filters the web UI does not expose cleanly. openFDA also has a browser-based query builder if you want to see the underlying structure without writing code.

The third is a curated lookup layer on top of MAUDE, which is what we build at Claripulse. It only matters once you have hit the limits of the first two.

#The Fields That Actually Matter

MAUDE has dozens of fields. Most of them are never populated or never useful. The ones that carry the weight of almost every real query are these:

• device.brand_name: the marketed name of the device. Start here for specific-product searches.
• device.generic_name: the FDA-side descriptive name. Often more consistent than brand name across reports.
• device.manufacturer_d_name: the manufacturer as listed on the device record. Spellings vary.
• product_code: the three-letter FDA classification code. This is the most reliable way to search a device category.
• event_type: one of Death, Injury, Malfunction, Other, or No answer provided.
• date_received: when FDA logged the report. Use this for date-range filters. date_of_event is often missing.
• mdr_text.text: the free-text narrative. This is where the actual clinical story lives.

A concrete openFDA query for Medtronic pacemaker reports filed in the last full year looks like this:

https://api.fda.gov/device/event.json?search=
  device.manufacturer_d_name:"MEDTRONIC"+AND+
  product_code:DXY+AND+
  date_received:[20250101+TO+20251231]
&limit=100

Product code DXY is "Pacemaker, Permanent, Implantable." Filtering by product code rather than brand name avoids most of the spelling-variation problem, at the cost of returning every manufacturer in that class. You usually want to combine both.

#Reading a MAUDE Result Without Fooling Yourself

Open one report. The first thing to look at is event_type. A Malfunction classification is not the same as an Injury, and neither is the same as a Death. A single adverse outcome can generate multiple reports from different filers, which means raw counts of any one type overstate incidence.

Next, read the narrative. MAUDE narratives are written by regulatory staff, customer service, and clinicians under time pressure. They tend to compress clinical events into a few sentences of jargon and abbreviation. The useful questions to ask of each narrative are: What was the device doing at the time of the event? Was the event identified by the patient, the clinician, or through routine interrogation? Was there a device malfunction, a procedural issue, or an unrelated clinical event that got reported out of caution? Was the device returned for analysis, and if so, what did the manufacturer find?

These questions are not answered cleanly in the structured fields. That is the point of the narrative, and it is also why MAUDE resists aggregation.

#Where MAUDE Starts Failing You

Everything above assumes you are looking up a specific device and reading reports one at a time. That is what MAUDE is designed for. It is also where its limits are least visible.

The limits show up the moment you try to answer a quantitative question.

Reporting is voluntary for most parties and mandatory for manufacturers, but in practice it is uneven. Published estimates of underreporting in MAUDE range widely by device class and event type. Some event categories are reported at a fraction of their true rate. You cannot correct for this from inside MAUDE.

There is no denominator. If a device generates forty event reports in a quarter, that number is meaningless without knowing how many times the device was used. A fortyfold increase in volume produces a fortyfold increase in raw counts, and that is not a safety signal. We wrote a longer piece on this in why signal detection in post-market surveillance is broken.

Brand and manufacturer strings are not normalized. The same device can appear as "MICRA", "Micra TPS", "MICRA AV", "Micra Transcatheter Pacing System", and several variants with trailing whitespace, depending on who filed the report. A naive brand-name search will miss a meaningful fraction of the relevant reports.

Product codes are coarse. A single product code can cover multiple generations of a technology, from multiple manufacturers, with different intended uses. "Lead, Pacemaker" covers transvenous leads, epicardial leads, and leadless variants depending on how the filer interpreted the category.

Reports duplicate. A single event can produce an initial report, one or more supplements, and a final report, all with distinct report keys. Without deduplication, a month with three supplementary filings on one incident looks like three new events.

Physical devices cross product-code boundaries. This matters more than it sounds. A single implantable cardioverter-defibrillator lead can be reported under several product codes in the same year, from the same manufacturer, describing the same device. If you search by one code, you are seeing part of the picture.

Narratives resist aggregation. The actual clinical signal lives in free text, and free text does not sort, filter, or trend without additional processing.

#When Raw MAUDE Is the Right Tool

A clinician looking up a specific device a specific patient has should use raw MAUDE. So should a journalist chasing one malfunction story, or a manufacturer's safety team pulling recent narratives on their own product.

These are one-device, one-question workflows, and MAUDE was built for them.

#When You Have Outgrown It

You have outgrown raw MAUDE the first time you try to do any of the following:

• Compare event volume across every device in a category, not one at a time.
• Track a device over time whose brand name changes across report years.
• See the same physical device aggregated across the product codes it shows up under.
• Rank devices in a category by report volume and filter by manufacturer.
• Get weekly-updated counts without running the same query by hand.

At that point you need a MAUDE-derived catalog, not a MAUDE search.

#What Our Lookup Tool Handles

We built Claripulse's free MAUDE lookup for exactly this gap. It sits on top of the same underlying MAUDE data, but with the cleanup already done.

Brand names and manufacturer strings are normalized against FDA's device registry and against external identifiers, so one device is one device no matter how four different filers spelled its name. Reports are deduplicated across supplements. Where the same physical device appears under multiple product codes, we group it so the aggregate counts reflect the actual device, not the filing convention.

The catalog covers 32 cardiology product codes grouped into 8 categories: rhythm management, ablation, mapping, structural heart, coronary intervention, mechanical circulatory support, heart failure and neuromodulation. You can browse a category, search by brand or manufacturer, or sort by report volume. It updates weekly from the latest MAUDE release.

It is free, and it is intended to be the front door people reach for when they would otherwise start on accessdata.fda.gov and give up.

#A Worked Comparison

Say you want to find every leadless pacemaker on the U.S. market and see which ones have rising report volume over the last two years.

In raw MAUDE: there is no "leadless pacemaker" filter. You search by product code NVY, then again by DXY for any misclassified reports, then separately by brand name for the two devices currently marketed, then again for any prior brand names those devices went by. You manually deduplicate. You export CSVs. You build your own time series in Excel. You still do not have a usable denominator.

In our lookup: you open the rhythm management category, filter to leadless devices, and sort by report trend. The same underlying data, one click instead of an afternoon.

We are not claiming to give you a denominator either. Nobody does, publicly, with high fidelity. We remove the friction between you and the part of the question MAUDE can answer.

#What MAUDE Is For

MAUDE is a compliance artifact that got pressed into service as a research tool. It does the compliance job well and the research job partially. Knowing which half you are using it for is most of what separates a useful MAUDE search from a misleading one.

Use MAUDE when you want to read what was reported. Use a purpose-built layer when you want to compare, aggregate, or track. If you are doing the second, start with our lookup and only drop down into raw MAUDE when you need the original narrative.

Claripulse analyzes publicly available FDA MAUDE data. We do not provide medical advice. MAUDE data is de-identified, and we do not attempt re-identification.