FDA MAUDE Database: The Complete Guide to Searching and Using Medical Device Adverse Event Reports

What Is the MAUDE Database?

MAUDE stands for Manufacturer and User Facility Device Experience. It is the FDA's publicly accessible database of medical device adverse event reports — formally known as Medical Device Reports (MDRs) — submitted under the mandatory reporting requirements of 21 CFR Part 803.

Every time a medical device is involved in a death, serious injury, or malfunction that could lead to death or serious injury, the responsible party is required by federal law to report that event to the FDA. Those reports end up in MAUDE. The database also includes voluntary reports submitted by healthcare professionals, patients, and consumers through the MedWatch program.

MAUDE is maintained by the Center for Devices and Radiological Health (CDRH) and is one of the most important tools available for post-market surveillance of medical devices in the United States. As of 2025, the database contains over 16 million reports dating back to 1991 and receives approximately 2 million new reports per year.

The database is free to access, requires no registration, and is available to anyone — regulators, manufacturers, researchers, clinicians, attorneys, investors, and the general public.

Direct link to MAUDE: accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm

Why MAUDE Matters

MAUDE is not just a regulatory compliance database. It is a strategic resource that serves multiple purposes across the medical device industry:

• Post-market surveillance. Manufacturers use MAUDE to monitor adverse events associated with their own devices and to identify emerging safety signals before they become field actions or recalls. A sudden spike in malfunction reports for a specific lot number, for example, can trigger a targeted investigation weeks before the problem escalates to a recall.

• Competitive intelligence. MAUDE reveals the real-world performance problems of competing devices — information that is unavailable from any other public source. You can identify recurring failure modes, track how competitors respond to problems, and assess the safety profile of devices you compete against.

• Predicate device research. When preparing a 510(k) submission, reviewing MAUDE reports for your predicate device helps you understand its known failure modes, which informs your risk analysis, design inputs, and testing strategy. FDA reviewers have access to the same data — if your predicate has known safety issues in MAUDE, your submission should address them proactively.

• Clinical evaluation and PMCF. For manufacturers selling into the EU under MDR, MAUDE is a recognized source of external post-market data for Clinical Evaluation Reports (CERs) and Post-Market Clinical Follow-up (PMCF) plans. EU Notified Bodies expect manufacturers to demonstrate that they have searched publicly available adverse event databases as part of their ongoing clinical evaluation.

• Regulatory decision-making. The FDA itself uses MAUDE data to identify safety signals, issue safety communications, mandate post-market studies under Section 522, and support recall decisions. When you see an FDA Safety Communication about a device type, it was likely triggered, at least in part, by patterns detected in MAUDE data.

• Academic research. Hundreds of peer-reviewed publications are based on MAUDE data, analyzing trends in device failures, patient outcomes, and reporting patterns across device categories. Journals like the Journal of Patient Safety, BMJ Quality & Safety, and AAMI's Biomedical Instrumentation & Technology regularly publish MAUDE-based analyses.

• Design input for new devices. Before designing a new device, reviewing MAUDE reports for the target device category reveals the failure modes, use errors, and design weaknesses that exist in currently marketed products. This is some of the most valuable design input available — it tells you what goes wrong in the real world, not just in the lab.

• Litigation and due diligence. Attorneys use MAUDE data in product liability cases. Investors and acquirers use it during due diligence to assess the safety track record of a device or a company's portfolio. A device company preparing for acquisition should know what its MAUDE profile looks like before a potential buyer discovers it.

Legal Basis: 21 CFR Part 803 — Medical Device Reporting

MAUDE exists because of a federal regulation: 21 CFR Part 803, commonly called the Medical Device Reporting (MDR) regulation. Understanding who must report, what must be reported, and when reports are due is essential to interpreting MAUDE data correctly.

Who Must Report

Three categories of reporters are legally obligated to submit MDRs to the FDA:

Reporter Type	Legal Obligation	Reports To
Manufacturers	Must report deaths, serious injuries, and malfunctions that could cause or contribute to death/serious injury	FDA
Importers	Must report deaths and serious injuries	FDA and the manufacturer
Device User Facilities (hospitals, nursing homes, ambulatory surgical centers, outpatient treatment facilities)	Must report deaths and serious injuries	Deaths: FDA and the manufacturer. Serious injuries: manufacturer (or FDA if manufacturer is unknown)

In addition, voluntary reporters — healthcare professionals, patients, consumers, and caregivers — can submit reports through the MedWatch program (FDA Form 3500). These voluntary reports also appear in MAUDE and are identified by their report source.

Important distinction: Physicians in private practice are not "device user facilities" under 21 CFR 803 and are not legally required to file MDRs. Their reports are voluntary. This is a significant gap in the reporting system and one reason MAUDE data underrepresents events that occur in outpatient and office-based settings.

What Must Be Reported

The three reportable event types under 21 CFR Part 803 are:

1. Death — The device may have caused or contributed to a patient death.
2. Serious injury — The device may have caused or contributed to a serious injury. "Serious injury" means an injury or illness that is life-threatening, results in permanent impairment of a body function or permanent damage to body structure, or necessitates medical or surgical intervention to prevent such outcomes.
3. Malfunction — The device malfunctioned in a way that, if the malfunction were to recur, would be likely to cause or contribute to a death or serious injury. This is a manufacturer-only reporting obligation — user facilities and importers do not report malfunctions to the FDA.

Reporting Timelines

Report Type	Deadline	Who Files
30-day report	Within 30 calendar days of becoming aware of the event	Manufacturers, importers
5-day report	Within 5 work days when an event requires remedial action to prevent unreasonable risk, or when FDA has specifically requested 5-day reporting for that device	Manufacturers
10-day report	Within 10 work days of becoming aware of the event	Device user facilities
Supplemental report	Within 30 calendar days of obtaining new information on a previously reported event	Manufacturers
Annual report	By January 1 of each year, summarizing all reports filed	Device user facilities

Practical note: Despite these deadlines, research shows that nearly 30% of MAUDE reports are filed late. One study found that the average reporting period for death events was 80 days and for malfunctions was 89 days — well beyond the 30-day requirement. Late reporting is a known limitation of the system and a recurring finding in FDA inspections.

The Decision to Report: Becoming Aware

One of the most debated aspects of MDR reporting is the concept of "becoming aware." Under 21 CFR 803, the reporting clock starts when the manufacturer "becomes aware" that a device may have caused or contributed to a death, serious injury, or reportable malfunction.

"Becoming aware" includes not only direct complaints from customers but also:

• Information from any employee, including service technicians, sales representatives, and distributors
• Information from published literature, including scientific papers and FDA safety alerts
• Trend analysis results from complaint data
• Information from user facility reports or other MDRs

This broad definition means that manufacturers cannot avoid reporting obligations by limiting who receives complaint information. The entire organization's awareness is imputed to the manufacturer.

Common compliance pitfall: Some manufacturers narrowly define "becoming aware" in their complaint handling SOPs to delay or avoid reporting. This is a frequent FDA inspection finding and has resulted in warning letters, consent decrees, and criminal prosecution in egregious cases. When in doubt, report. The regulatory consequences of under-reporting far outweigh those of over-reporting.

How Reports Are Submitted

Mandatory reporters submit MDRs electronically using FDA Form 3500A (the mandatory reporting form) through the FDA's electronic submission gateway (eSubmitter or the Health Level Seven — HL7 — Individual Case Safety Report format). Voluntary reporters use FDA Form 3500 (the voluntary reporting form), which can be submitted online through the MedWatch website, by mail, or by fax.

Each submitted report is assigned an MDR Report Key — a unique identifier used to link the report across the multiple data files that make up the MAUDE database.

Exemptions and Alternatives

Not every malfunction requires a separate MDR. The FDA offers two mechanisms to reduce the burden of individual malfunction reports:

• Summary Reporting (21 CFR 803.19): Manufacturers may request permission to submit quarterly summary reports instead of individual MDRs for well-known, frequently reported malfunctions. This requires prior FDA approval and is limited to specific malfunction types where individual reporting adds no new safety information.

• Exemptions (21 CFR 803.19): The FDA can grant exemptions from MDR reporting for specific device types or event types. These exemptions are published on the FDA website. Before concluding that a malfunction is not reportable, check whether an exemption applies to your device's product code.

• Real-World Data (RWD) Exemptions: Some manufacturers receive exemptions that allow them to submit adverse event information collected from real-world data sources such as registries, electronic health records, or medical claims data. These reports are identified in MAUDE with report numbers prefixed "RWDYYXXXXX," where "YY" refers to the year the exemption was granted and "XXXXX" is the unique RWD exemption identifier.

The Alternative Summary Reporting (ASR) Program: Important Historical Context

From 1997 to June 2019, the FDA operated the Alternative Summary Reporting (ASR) program, which allowed manufacturers of certain devices to report well-known, frequently occurring malfunctions in summary form rather than as individual MDRs. The FDA granted 108 ASR exemptions over the program's lifetime.

A critical detail for anyone analyzing historical MAUDE data: ASR reports were not included in the MAUDE database because the FDA required an incompatible submission format for ASR reports. This means that for devices enrolled in the ASR program, the MAUDE database significantly underrepresents the true volume of malfunction reports during the 1997-2019 period. Millions of malfunction reports were submitted under ASR but were invisible in MAUDE searches.

In 2017, the FDA modified the ASR program to require manufacturers to also submit a "companion" MDR so that summary information would be visible in MAUDE. In June 2019, the FDA formally ended the ASR program and revoked all exemptions. All historical ASR data (from 1999 to April 2019) is now available in legacy data files on the FDA's MDR Data Files webpage, but these reports are still separate from the standard MAUDE search interface.

The successor program — the Voluntary Malfunction Summary Reporting (VMSR) program — allows manufacturers to report certain device malfunctions in summary form on a quarterly basis for eligible device types. Unlike ASR, VMSR reports are publicly available in the MAUDE database.

Why this matters for your analysis: If you are analyzing MAUDE data for a device category that was enrolled in the ASR program between 1997 and 2019, your malfunction report counts for that period will be artificially low. You may see a sudden spike in malfunction reports around 2019 that reflects the end of ASR, not an actual increase in device malfunctions. Always check whether a device had an ASR exemption before drawing conclusions from historical malfunction trends.

MAUDE Data Structure and Fields

Understanding MAUDE's internal structure is essential for anyone doing serious analysis. The database is not a single flat table — it consists of four primary data files and two supplemental files containing a total of 135 fields.

Primary Data Files

File	Description	Key Fields
Master Event (mdrfoiThru)	One record per report. Contains the event-level information.	MDR Report Key, Event Key, Event Type, Date of Event, Report Date, Report Source, Date FDA Received, Single Use Flag
Device (foidev)	Device details for each report. A report can involve multiple devices.	MDR Report Key, Brand Name, Generic Name, Manufacturer Name, Model Number, Catalog Number, Product Code (3-letter procode), Device Availability, UDI-DI
Patient (foitext — patient section)	Patient outcome information. A report can involve multiple patients.	MDR Report Key, Patient Sequence Number, Date of Birth, Age, Sex, Patient Outcome (life-threatening, hospitalization, disability, etc.)
Text (foitext)	Free-text narrative descriptions of the event.	MDR Report Key, Text Type Key, Text (the narrative), Patient Sequence Number

Supplemental Data Files

File	Description
Device Problem (deviceproblem)	Links each report to one or more standardized device problem codes from the FDA's Patient Problem Code list.
Problem Code Descriptions (patientproblemcode)	Maps each numeric device problem code to a short text description (e.g., "Break," "Leak," "Software Anomaly," "Migration of Device").

Key Fields Explained

Event Type — Classifies the reported outcome: Death, Injury, Malfunction, Other, or No Answer Provided. This is the most basic filter for triaging reports.

Report Source — Identifies who submitted the report: Manufacturer, User Facility, Importer, Distributor, or Voluntary Reporter. This matters because manufacturers submit the most detailed reports with the most structured data.

Product Code — A three-letter FDA classification code (e.g., "DXL" for powered wheelchair, "QBJ" for catheter-tip oximeter). This is the single most useful field for systematic searches because it maps precisely to a device classification, unlike brand names, which vary in format and spelling.

Brand Name and Generic Name — The commercial name and FDA generic name of the device. These fields are free-text and inconsistently formatted — the same device may appear as "ACME Stent System," "Acme stent system," "ACME STENT," etc.

Device Problem Codes — Standardized codes describing what went wrong with the device. Approximately 1,700 codes exist, covering categories like mechanical failures, electrical problems, software errors, material degradation, and packaging issues.

Patient Problem Codes — Standardized codes describing the clinical outcome for the patient (e.g., infection, hemorrhage, device migration, no clinical signs/symptoms).

Event Narrative (Text) — The free-text description of what happened. This is often the most informative part of the report, but its quality varies enormously — some narratives run several pages with clinical detail, while others are a single sentence like "Device malfunctioned."

UDI-DI (Unique Device Identifier — Device Identifier) — In newer reports, this field links the adverse event to a specific device identifier in the GUDID (Global Unique Device Identification Database). When populated, this field provides precise device identification down to the model, version, and packaging level. The FDA added UDI-DI and UDI-Public fields to MAUDE in recent updates to improve device traceability.

Manufacturer Narrative — For manufacturer-submitted reports, this field contains the manufacturer's investigation findings and assessment of whether the device caused or contributed to the event. This is separate from the Event Description and often provides the most technically detailed information in the report.

Report Source also includes a sub-classification for voluntary reporters. Understanding who submitted the report helps you assess the likely reliability and completeness of the information. Manufacturer reports tend to be the most structured and complete because manufacturers have internal investigation processes and regulatory compliance teams.

FOIA Redaction Markers in MAUDE Reports

When reading MAUDE reports, you will encounter text replaced by "(b)(4)" or "(b)(6)" markers. These refer to exemptions under the Freedom of Information Act (FOIA):

• (b)(4) — Replaces trade secret or confidential business information. You may see this in lieu of product composition details, proprietary manufacturing processes, or confidential design specifications.
• (b)(6) — Replaces personal or medical files information. This marker commonly appears where patient age, date of birth, or other individually identifiable health information was originally present.

These redactions are applied by the FDA before reports are published in MAUDE to protect both commercial confidentiality and patient privacy. Understanding these markers prevents confusion when reading narratives that contain apparent gaps.

Critical Data Structure Issue: Patient Outcome Concatenation

For analysts working with raw MAUDE data files, be aware of a significant structural issue in the Patient file. When a single report involves multiple patients, the OUTCOME field does not remain patient-specific — instead, it represents a sequential concatenation of findings across all patient records sharing the same MDR Report Key.

This means that naively counting patient outcomes from the raw data can significantly inflate totals. For example, a report involving two patients — one hospitalized and one with no clinical consequences — may produce a concatenated outcome string that, if parsed incorrectly, appears to represent two separate hospitalizations. Research has shown that this concatenation issue can produce meaningfully distorted results in aggregate analyses. Always use the PATIENT_SEQUENCE_NUMBER field in conjunction with MDR_REPORT_KEY to correctly attribute outcomes to individual patients.

Event Keys vs. Report Keys: Counting Events, Not Just Reports

Another critical distinction for analysis: approximately 8% of records in the Master Event file share an EVENT KEY. This means the same underlying adverse event generated multiple reports — for example, both the manufacturer and the user facility filed reports about the same incident.

Failure to incorporate the EVENT_KEY field results in counting reports rather than unique events. For any quantitative MAUDE analysis, decide upfront whether your unit of analysis is the report or the event, and use the appropriate key field. For most regulatory and clinical analyses, unique events (deduplicated by EVENT KEY) are the more meaningful metric.

Data Availability by Field

Not all fields are populated in every report. Understanding data availability rates helps set realistic expectations for analysis:

• Device data (brand name, manufacturer, product code) — Available for approximately 90% of reports
• Patient outcome information — Present in approximately 75% of reports
• Patient treatment information — Present in only approximately 26% of reports
• Device Problem Codes — Available for approximately one-third of reports, and of those, roughly 25% use non-informative codes such as "No Information" or "Not Applicable"
• Text narrative dates — Missing for approximately 75% of records

How to Access and Search MAUDE

There are three primary ways to access MAUDE data, each suited to different use cases.

Option 1: The MAUDE Web Search Interface

URL: accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm

This is the most common access point and requires no technical skills. The web interface offers two search modes:

Simple Search — A single search field where you enter a product name, product code, manufacturer name, or any keyword. Results are returned as a list of matching reports. This is fine for a quick check but gives you limited control over what you find.

Advanced Search — A multi-field form that allows you to filter by:

• Product problem
• Product class
• Event type (Death, Injury, Malfunction, Other)
• Manufacturer name
• Model number
• Report number
• Brand name
• Product code (3-letter)
• Date received (date range)

The advanced search is what you should use for any substantive research. It allows you to combine multiple criteria — for example, all death reports for a specific product code from a specific manufacturer within a specific date range.

Each search result displays a summary row with the report number, event date, event type, brand name, and manufacturer. Click on any row to see the full report, including the event narrative, device details, patient information, and manufacturer narrative.

Limitations of the web interface:

• 500-record cap per search. Both simple and advanced searches return a maximum of 500 results. If your query matches more than 500 reports, the interface returns only the first 500 with no warning or indication that results were truncated. This is the single most dangerous limitation for anyone conducting systematic research — an inattentive user may believe they have retrieved all matching reports when they have only a fraction. Workaround: Narrow your date range into smaller intervals (e.g., 2-3 week windows) and run multiple searches to stay below the 500-record cap. Alternatively, use the openFDA API (which allows up to 1,000 results per query with a skip parameter for pagination) or download the bulk data files.
• Only returns reports from the last 10 years. Older reports must be accessed through bulk download or openFDA.
• Updated monthly, not in real-time. The search page displays the date of the most recent update.
• Export functionality is limited. You can export search results to a spreadsheet, but only a subset of data fields are included in the export — critical fields like the full event narrative are often truncated or excluded.
• No saved searches or alerts. You must re-run your search each time.
• Large result sets can be slow to navigate. The interface paginates results and does not provide efficient ways to browse thousands of records.
• UDI search capability. A device's UDI (Unique Device Identifier) can be entered into the simple search field to search for reports associated with that specific device identifier.

Option 2: openFDA API

URL: open.fda.gov/apis/device/event/

The openFDA device adverse event API provides programmatic access to MAUDE data. It is free to use and does not require an API key for basic queries (though an API key increases your rate limit).

Advantages over the web interface:

• Access to data from 1991 to present — not limited to 10 years
• Updated weekly, not monthly
• Returns structured JSON data with all fields, including full narratives
• Supports complex queries with Boolean operators, date ranges, exact matches, and field-specific searches
• Supports count queries (e.g., "how many death reports for product code QBJ per year?")
• No export limitations — you get the complete data

Example API query — all death reports for product code "DXL" in 2025:

https://api.fda.gov/device/event.json?search=device.device_report_product_code:"DXL"+AND+event_type:"Death"+AND+date_received:[20250101+TO+20251231]&limit=100

Example count query — number of reports by event type for product code "DXL":

https://api.fda.gov/device/event.json?search=device.device_report_product_code:"DXL"&count=event_type.exact

Tip: If you are not a developer, you can still use the openFDA API by constructing URLs in your browser. The openFDA interactive query tool lets you build queries visually without writing code.

Pagination with the skip parameter: The openFDA API returns a maximum of 1,000 records per query (using limit=1000). To retrieve more than 1,000 matching records, use the skip parameter to paginate through results. For example, adding &skip=1000 to your query retrieves records 1001-2000. This is a significant advantage over the web interface's hard 500-record cap. Note that openFDA caps the skip parameter at 25,000, so for result sets larger than 26,000 records, you will need to partition your query by date range or other fields.

Example with pagination:

https://api.fda.gov/device/event.json?search=device.device_report_product_code:"DXL"&limit=1000&skip=1000

Option 3: Bulk Data Download

URL: open.fda.gov/data/downloads/

The FDA provides quarterly bulk download files for the entire MAUDE dataset in JSON format via the openFDA downloads page. The raw MAUDE ASCII text files are also available from the FDA's CDRH website.

When to use bulk download:

• You need to analyze tens of thousands of reports across multiple product codes
• You are building a dashboard, monitoring tool, or research dataset
• You need to link MAUDE data to other FDA databases (510(k), PMA, recalls)
• You are conducting statistical analysis that requires the complete dataset

File sizes: The complete MAUDE dataset is several gigabytes. Plan accordingly for storage and processing.

Tip for non-programmers: If you need bulk data but do not have programming resources, consider using a tool like Google BigQuery, which has a public dataset program that includes FDA data. Alternatively, several academic institutions and commercial vendors maintain pre-processed MAUDE datasets that can be analyzed using standard spreadsheet or business intelligence tools.

Step-by-Step: How to Search MAUDE Effectively

The difference between a useful MAUDE search and a frustrating one comes down to technique. Here is a practical workflow.

Step 1: Identify Your Product Code

Do not start with a brand name search. Start with the three-letter FDA product code for your device type. This is the most reliable search field because it maps to a standardized classification, unlike brand names, which are inconsistently entered.

How to find your product code:

1. Go to the FDA Product Classification Database
2. Search by device name or regulation number
3. Note the three-letter product code (e.g., "DXL" for powered wheelchair, "QBJ" for catheter-tip oximeter, "GAT" for surgical stapler)

Alternatively, look up the product code from a 510(k) or PMA clearance for a known device in your category using the 510(k) database or PMA database.

If you are unsure which product code applies to your device, check the Devices@FDA database which allows searching by device name across both 510(k) and PMA databases and displays the associated product code.

Step 2: Run a Broad Search First

Go to the MAUDE Advanced Search page and enter:

• Product Code: Your three-letter code
• Date range: The last 2–3 years (or whatever period is relevant)
• Leave all other fields blank

Review the total number of results. This gives you a baseline for the volume of reporting activity for that device type.

Record this number. It becomes your reference point. If your product code generates 1,200 reports over 2 years, you know that roughly 600 events per year are being reported for this device category. This context is essential for interpreting any individual report or trend you find later.

Step 3: Filter by Event Type

Narrow your search by selecting a specific event type:

• Death — Start here if you are assessing the most serious safety concerns
• Injury — For understanding the range of patient harms
• Malfunction — For understanding device failure modes (often the highest-volume category)

Step 4: Refine with Additional Fields

Add filters progressively:

• Brand Name — To focus on a specific product (use wildcards, e.g., "ACME*")
• Manufacturer Name — To focus on a specific company
• Model Number — To isolate a specific device variant
• Product Problem — To filter by a specific failure mode

Step 5: Read the Narratives

The event narrative is where the real information lives. Click into individual reports and read the "Event Description" and "Manufacturer Narrative" text fields. Look for:

• Root cause information
• Whether the manufacturer confirmed or denied a device contribution
• Patient outcome details
• Whether a similar event has been reported before
• Any corrective actions taken

Step 6: Export and Analyze

Export your filtered results to a spreadsheet for systematic analysis. Track patterns across reports: recurring failure modes, specific model numbers or lot numbers with elevated reporting, time-based trends, geographic clustering.

Create a simple tracking spreadsheet with columns for:

• Report number
• Event date
• Event type
• Brand name / model number
• Device problem code
• Patient outcome
• Summary of narrative (your own one-sentence summary)
• Relevance to your device (high/medium/low)
• Action required (yes/no)

This structured approach transforms a pile of unstructured reports into actionable intelligence.

Search Tips and Techniques

Search tip: Use wildcards. MAUDE supports wildcard searches using the asterisk (*). Searching for hear* returns results containing "hearing," "heart," "hearing aid," etc. Searching for *stent* returns results containing "stent," "stenting," "biliary stent," etc. Use wildcards to account for naming variations.

Search tip: Use exact phrases and Boolean operators. In the simple search, you can enter an exact phrase in quotes (e.g., "electromechanical pump") or combine multiple terms with "and" (e.g., bruise and throat and intubation). This is particularly useful for narrowing results to specific clinical scenarios described in event narratives.

Search tip: Watch for the 500-record cap. Both simple and advanced searches silently cap results at 500 records. If your search returns exactly 500 results, you almost certainly have more records than were returned. Break your search into smaller date intervals (2-3 week windows) and aggregate the results, or switch to the openFDA API which supports pagination via the skip parameter.

Search tip: Try multiple name variations. The same device may be entered as "CardioStent Plus," "Cardiostent Plus System," "CARDIOSTENT," or "CS Plus." Run your search using the product code first, then use brand name searches as a secondary validation. If you are researching a specific brand, try at least three variations.

Search tip: Cross-reference with the TPLC database. The Total Product Life Cycle (TPLC) database integrates MAUDE adverse event data with 510(k) clearances, PMA approvals, and recall data by product code. It provides a high-level summary of adverse event counts that can help you quickly assess the reporting volume for a device category before diving into individual MAUDE reports.

Search tip: Use product codes, not generic names. The "Generic Name" field in MAUDE is free-text and varies in how it describes the same device type. The three-letter product code is standardized. Always anchor your search strategy to the product code. However, be aware that product codes are not validated upon entry — reporters may miscategorize a device under the wrong product code. For example, a pacemaker lead problem may be recorded under the pacemaker product code rather than the lead product code. For critical analyses, search both the primary product code and related codes in the same device family. The FDA publishes a complete, weekly-updated list of over 6,000 product codes in the downloadable Product Code Classification files.

Search tip: Check for supplemental reports. When you find a report of interest, check whether supplemental (follow-up) reports exist under the same MDR Report Key. Supplemental reports often contain the results of the manufacturer's investigation and may provide root cause information not available in the initial report.

Search tip: Date field matters. MAUDE offers filtering by "Date Report Received" — the date the FDA received the report — not the date the event occurred. These can differ by weeks or months. If you are investigating a specific incident with a known event date, you may need to search a broader date range to find the corresponding report.

How to Interpret MAUDE Reports

Reading MAUDE reports requires a critical eye. The data has significant limitations, and misinterpreting reports can lead to flawed conclusions. Regulators, researchers, and attorneys all struggle with interpretation — mastering this skill gives you a significant advantage.

What MAUDE Reports Tell You

• That an adverse event was reported. A report in MAUDE means that someone — a manufacturer, user facility, importer, or voluntary reporter — submitted a report describing a device-related event.
• The reporter's account of what happened. The narrative describes the event as understood by the reporter at the time of submission.
• The device involved. Brand name, model number, manufacturer, and product code identify the specific device.
• The outcome for the patient. Event type (death, injury, malfunction) and patient outcome codes provide a standardized classification.
• The reporter's assessment of device contribution. Manufacturer reports typically include a statement on whether the manufacturer believes the device caused or contributed to the event.
• Temporal patterns. When multiple reports cluster in time, they may indicate a manufacturing lot issue, a design change that introduced a new failure mode, or a change in clinical practice.

What MAUDE Reports Do NOT Tell You

• That the device actually caused the event. A MAUDE report is an allegation, not a confirmed finding. Reports are not investigated or verified by the FDA before being published. The presence of a report does not mean the device was defective or that it caused the reported outcome.
• The true incidence rate. MAUDE contains no denominator — there is no data on how many devices are in use or how many procedures have been performed. You cannot calculate an adverse event rate from MAUDE data alone.
• Whether the report is accurate. Reports may contain errors, incomplete information, or misidentified devices. Voluntary reports can be submitted by anyone, including individuals with no direct knowledge of the event.
• Causation. Even for confirmed device malfunctions, the causal relationship between the malfunction and the patient outcome is often unclear from the report alone.
• What the manufacturer did about it. Initial reports rarely include the outcome of the manufacturer's investigation. Supplemental reports may provide this information, but they are not always filed.

Reading Between the Lines: Practical Interpretation Strategies

Look for the manufacturer narrative. In manufacturer-submitted reports, the manufacturer narrative section often provides the most useful information — including investigation findings, root cause assessment, and whether the manufacturer was able to reproduce the failure. Some manufacturers include detailed failure analysis results, while others provide formulaic statements like "The manufacturer is unable to determine whether the device caused or contributed to the reported event." The absence of a substantive investigation in the narrative is itself informative.

Distinguish between user error and device failure. Many MAUDE reports describe events where the root cause is user error rather than device malfunction. A report describing a surgical complication may reflect a technique issue, patient anatomy, or user training gap rather than a device defect. Read the narrative carefully to assess whether the device actually malfunctioned or whether the outcome was related to use conditions.

Assess report source credibility. Manufacturer reports undergo at least some internal review before submission. Voluntary reports from patients or consumers may lack clinical context and may reflect misunderstanding of what constitutes a device problem. User facility reports from trained clinical staff tend to fall somewhere in between.

Look for clusters, not individual reports. A single MAUDE report rarely tells a definitive story. The value of MAUDE is in patterns — clusters of similar reports over time, across facilities, or from multiple independent reporters. A single report of a catheter fracture is a data point. Twenty reports of catheter fracture across five manufacturers over two years is a signal.

Critical caveat: Comparing raw report counts between two device brands or manufacturers is almost always misleading. Differences in market share, reporting culture, product lifecycle stage, and the level of proactive monitoring all affect reporting volume independently of actual device performance. A device with more MAUDE reports is not necessarily less safe than one with fewer reports.

Limitations and Caveats of MAUDE Data

Every regulatory professional, researcher, and clinician who uses MAUDE must understand its limitations. The FDA itself prominently disclaims the data on the MAUDE search page.

Underreporting

The most significant limitation. Not all adverse events are reported to the FDA. Studies estimate that the actual number of device-related adverse events is several times higher than what appears in MAUDE. Contributing factors include:

• No reporting obligation for most clinicians. Physicians in private practice, surgeons, and other healthcare providers are not required to report (unless they work in a "device user facility" as defined in 21 CFR 803).
• Patient unawareness. Most patients do not know they can report device problems to the FDA.
• Reporting fatigue. Even among mandatory reporters, the administrative burden of MDR reporting leads to underreporting, particularly for malfunctions.
• Manufacturer interpretation. Manufacturers make a judgment call about whether a complaint meets the MDR reporting threshold. This judgment is subjective, and some manufacturers are more conservative (under-report) while others are more aggressive (over-report).

No Denominator Data

MAUDE contains only numerators — the number of reports. Without knowing how many devices are in use (the denominator), you cannot calculate rates. A device type with 500 reports and 1 million units in use has a fundamentally different risk profile than a device type with 500 reports and 10,000 units in use.

Data Quality and Consistency

• Free-text fields are inconsistent. The same device model may appear with different brand names, model numbers, and manufacturer names across reports.
• Narratives vary in quality. Some reports contain detailed clinical descriptions with root cause analysis. Others contain a single sentence that conveys almost no useful information.
• Duplicate reports. The same event may generate multiple reports — from the manufacturer, the user facility, and a voluntary reporter. MAUDE does not automatically de-duplicate these reports. Research indicates that approximately 8% of records in the Master Event file share an EVENT_KEY, meaning multiple reports describe the same underlying incident. If you are counting events rather than reports, you must deduplicate using the EVENT_KEY field.
• Delayed reporting. Reports can appear in MAUDE months or even years after the event occurred.

No Independent Verification

Reports are published as submitted. The FDA does not verify the accuracy of the information, investigate the event before publication, or adjudicate whether the device actually caused the reported outcome. Some reports reflect user error, comorbidities, or other non-device-related factors.

The FDA has stated explicitly on the MAUDE search page: "Although MDRs are a valuable source of information, this passive surveillance system has limitations, including the potential submission of incomplete, inaccurate, untimely, unverified, or biased data."

Data Lag

The MAUDE web interface is updated monthly, and the openFDA API is updated weekly. In both cases, there is a lag between when the FDA receives a report and when it appears in the publicly searchable database. Urgent safety signals are not visible in MAUDE in real-time.

This lag means MAUDE is not suitable for real-time safety monitoring. By the time a report appears in MAUDE, weeks or months may have passed since the event occurred.

Limited International Scope

MAUDE contains only reports submitted to the FDA under US reporting requirements. It does not include adverse event reports submitted to other regulatory authorities (EU vigilance system, Health Canada, TGA, etc.). For a global picture of device safety, you need to consult multiple databases.

For international manufacturers, this means that MAUDE captures only a fraction of the adverse events associated with their devices worldwide. Events occurring outside the US — even with the identical device — are not reflected in MAUDE unless the manufacturer also reports them to the FDA (which is required only if the device is marketed in the US and the event would be reportable under 21 CFR 803).

Reporting Bias

The volume of reports for a given device is influenced by factors unrelated to actual device safety:

• Market share. Devices with larger installed bases generate more reports, regardless of their safety profile.
• Lifecycle stage. Newly launched devices often have lower report volumes simply because fewer are in use, not because they are safer.
• Media attention. Safety issues that receive media coverage trigger a wave of voluntary reporting (the "stimulated reporting" effect), which can create the appearance of a sudden increase in adverse events.
• Regulatory scrutiny. Devices under FDA investigation or recall may generate elevated voluntary reporting because awareness is heightened.
• Manufacturer reporting practices. Some manufacturers have more conservative MDR reporting thresholds than others, leading to higher report volumes for equivalent devices.

Misclassification of Events

Event type classifications (Death, Injury, Malfunction, Other) in MAUDE are assigned by the reporter, not independently verified. Misclassification occurs — events may be coded as "Malfunction" when a patient was actually injured, or as "Other" when the reporter was uncertain about the appropriate category. Research has shown that misclassification rates vary by device type and reporter type. When conducting safety analyses, do not rely solely on the event type field — always read the narrative text to confirm the actual severity of the reported event.

MAUDE Limitations for AI-Enabled Medical Devices

As the number of AI-enabled medical devices grows — the FDA's AI-Enabled Medical Devices List included over 1,000 devices as of 2025 — MAUDE's limitations become particularly acute for this device category. MAUDE's reporting structure was designed for traditional hardware and software devices and cannot adequately capture failure modes unique to AI/ML systems:

• Concept drift — When an AI model's performance degrades over time because the relationship between inputs and outputs changes. This type of failure is gradual and may not manifest as a discrete adverse event.
• Covariate shift — When the input data distribution in clinical use differs from the training data, causing the model to produce unreliable outputs. This is a systemic failure mode that does not fit neatly into a single adverse event report.
• Algorithmic bias — When an AI system performs differently across patient subpopulations in ways that were not anticipated during development. These disparities may only become apparent through population-level analysis, not individual event reports.

MAUDE's free-text narratives and standardized device problem codes do not have categories for these AI-specific failure modes. If you are monitoring an AI-enabled device through MAUDE, supplement your MAUDE analysis with additional monitoring methods designed for AI/ML performance, including output monitoring dashboards and population-level performance metrics.

Quantitative and Qualitative Analysis Frameworks for MAUDE Data

Effective MAUDE analysis requires both quantitative and qualitative approaches. Using only one approach leaves significant blind spots.

Quantitative Analysis

Quantitative analysis identifies patterns, trends, and frequencies across large numbers of reports. Key metrics to track include:

• Event frequency over time. Plot the number of reports per month or quarter to detect spikes or sustained increases. Sudden increases may indicate manufacturing lot issues, design changes, or stimulated reporting from media coverage. Gradual increases may reflect growing market penetration or a degrading component.
• Event type distribution. Track the ratio of Death, Injury, and Malfunction reports over time. A shift from predominantly Malfunction reports to an increasing proportion of Injury reports is a signal that warrants investigation.
• Top device problem codes. Identify which problem codes appear most frequently for your device category. This reveals the most common failure modes.
• Geographic trends. If reports are concentrated in specific regions, this may indicate facility-specific use practices, environmental factors (temperature, humidity), or distribution chain issues.
• Demographic patterns. When patient demographic data is available, assess whether certain patient populations experience higher rates of adverse events. This information is particularly relevant for devices used across a wide age range or in diverse clinical settings.
• Manufacturer comparison. For a given product code, compare report volumes and event type distributions across manufacturers. While raw counts are not directly comparable due to market share differences, large discrepancies in event type proportions (e.g., one manufacturer has a disproportionately high ratio of death reports) can be meaningful.

Qualitative Analysis

Qualitative analysis complements the numbers with clinical context from individual report narratives:

• Recurring failure modes. Read event narratives to identify common device components, subsystems, or processes that are prone to failure. Structured fields like device problem codes capture only part of this information — narratives often contain more specific failure descriptions.
• User error vs. device failure. Assess whether reported events reflect genuine device malfunctions or use-related issues (training gaps, confusing labeling, non-intuitive user interfaces). High rates of use error reports may indicate usability design problems rather than device reliability issues.
• Environmental and patient factors. Evaluate how patient comorbidities, clinical settings, or off-label usage conditions influence reported outcomes.
• Design control input. Use qualitative findings to inform design modifications, packaging improvements, labeling enhancements, or IFU (Instructions for Use) revisions.

Best practice: Combine both approaches. Use quantitative analysis to identify which failure modes, time periods, or device variants to investigate further, then use qualitative narrative review to understand the clinical context and root causes behind the numbers.

MAUDE vs. openFDA API: When to Use Which

Both access MAUDE data, but they serve different purposes.

Feature	MAUDE Web Interface	openFDA API
Best for	Quick lookups, browsing individual reports, one-off searches	Systematic analysis, trend monitoring, integration with other tools
Data range	Last 10 years	1991 to present
Update frequency	Monthly	Weekly
Export capability	Limited (partial field export to spreadsheet)	Full data in JSON format
Query complexity	Simple and advanced search forms	Complex Boolean queries, field-specific filters, date ranges, count aggregations
Technical skill required	None — browser-based point-and-click	Basic API knowledge (URL construction, JSON parsing) or use of the interactive explorer
Rate limits	None (but slow for large result sets)	240 requests/minute without API key; 120,000/day with key
Narrative text	Viewable in full for individual reports	Returned in full in API response

Use the web interface when: You need to look up a specific device or report, you want to browse event narratives, or you are doing a quick ad hoc check.

Use the openFDA API when: You need data from more than 10 years ago, you are tracking trends over time, you need structured data for analysis, you want to automate monitoring, or you need count-level aggregations.

Common openFDA query patterns for device professionals:

Task	API Query Approach
Count reports by year for a product code	search=device.device_report_product_code:"XXX"&count=date_received
Find all death reports for a manufacturer	search=device.manufacturer_d_name:"CompanyName"+AND+event_type:"Death"
Compare report volumes across manufacturers	search=device.device_report_product_code:"XXX"&count=device.manufacturer_d_name.exact
Identify top device problems for a device	search=device.device_report_product_code:"XXX"&count=device_problems.exact
Search by UDI	search=device.udi_di:"UDISTRING"

The openFDA API documentation at open.fda.gov/apis/device/event/ provides complete field reference, query syntax, and interactive examples.

MAUDE vs. the FDA TPLC Database

The Total Product Life Cycle (TPLC) database provides an integrated view of premarket and postmarket data by product code. It combines data from the 510(k) database, PMA database, MAUDE, and the recall database into a single report per product code.

When to use TPLC instead of MAUDE:

• You want a high-level overview of all regulatory activity (clearances, approvals, adverse events, recalls) for a device category
• You are starting your research and want to understand the overall landscape before drilling into individual MAUDE reports
• You need to quickly compare post-market activity across different product codes

When to use MAUDE directly:

• You need individual report-level detail
• You want to read event narratives
• You need to filter by brand name, model number, or manufacturer
• You need data that is more current (TPLC is updated less frequently than MAUDE)

TPLC URL: accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tplc.cfm

The FDA AEMS Transition: What Is Changing

On March 11, 2026, the FDA launched the Adverse Event Monitoring System (AEMS) — a new unified platform designed to consolidate the agency's fragmented adverse event databases into a single, publicly accessible system.

What AEMS Replaces

AEMS is replacing seven separate legacy databases that the FDA previously used to track adverse events across all regulated products:

Legacy System	Product Area	Status
FDA Adverse Event Reporting System (FAERS)	Drugs, biologics, cosmetics, color additives	Replaced (March 2026)
Vaccine Adverse Event Reporting System (VAERS)	Vaccines	Data displayed in AEMS (March 2026)
Adverse Event Reporting System (AERS)	Animal drugs, animal foods	Replaced (March 2026)
MAUDE	Medical devices	Scheduled for May 2026
Human Foods Complaint System (HFCS)	Human foods, dietary supplements	Scheduled for May 2026
Center for Tobacco Products AE Reporting System (CTPAE)	Tobacco, e-nicotine products	Scheduled for May 2026

What This Means for Device Professionals

MAUDE is scheduled to be absorbed into AEMS by the end of May 2026. Here is what to expect:

• Reporting obligations are unchanged. The underlying regulation — 21 CFR Part 803 — remains in effect. Manufacturers, importers, and user facilities must continue to submit MDRs on the same timelines and using the same forms. Nothing about your complaint handling, MDR assessment, or reporting procedures needs to change in terms of substance.

• The interface will change. AEMS features a new public dashboard with improved search capabilities and real-time publication of reports (rather than monthly batch updates). The "look and feel" of how you search for and retrieve adverse event data will be different from the current MAUDE web interface.

• Cross-product visibility. For the first time, adverse events for devices, drugs, biologics, vaccines, and food will be searchable in a single system. This is particularly relevant for combination products (drug-device, biologic-device) where adverse events may have been split across FAERS and MAUDE under the legacy systems.

• New APIs. The FDA has announced enhanced APIs and data analytics tools as part of AEMS. The specifics of how these will relate to or replace the openFDA device event API are not yet fully detailed. Companies that have built automated monitoring tools on top of the openFDA API should plan for potential endpoint changes.

• Cost savings. The FDA expects to save $120 million over five years by eliminating the seven legacy systems. The annual budget for the seven databases combined was approximately $37 million.

• Real-time reporting. Unlike MAUDE, which publishes reports in monthly batches, AEMS will publish reports in real-time, subject to requirements for protecting individually identifiable patient information. This is a significant improvement — it means safety signals will become publicly visible much faster than under the current system.

• Reduced FOIA burden. Because AEMS will publish reports in real-time rather than quarterly, the FDA expects a significant reduction in FOIA requests for unreleased adverse event reports. This is good news for manufacturers who have previously had to wait for FOIA responses to access reports related to their devices.

Action item for device companies: The transition is imminent. If you have internal processes, SOPs, or automated systems that reference the MAUDE web interface URL or the openFDA device event API, plan for those endpoints to change. Monitor the FDA AEMS page for migration timelines and updated documentation.

Will Historical MAUDE Data Be Preserved?

The FDA has stated that AEMS will contain historical adverse event data. However, the exact scope of historical MAUDE data migration — and whether the full archive back to 1991 will be immediately available in AEMS — has not been confirmed as of this writing. It is prudent to download and archive any historical MAUDE data you depend on for ongoing regulatory or research purposes before the transition.

What Device Companies Should Do Now

The transition timeline is tight. Here are concrete steps to prepare:

1. Inventory your MAUDE dependencies. Identify every process, SOP, work instruction, and automated system that references MAUDE URLs, the openFDA device event API endpoint, or MAUDE data formats.

2. Archive critical data. Download and store any historical MAUDE data that supports ongoing regulatory submissions, CERs, PMCF reports, or litigation matters. Do not assume this data will be immediately available in the same format after migration.

3. Update SOPs. Revise your post-market surveillance procedures to reference AEMS as the successor system. Include both the current (MAUDE) and future (AEMS) database references during the transition period.

4. Monitor FDA communications. Subscribe to the FDA AEMS page for updates on the migration timeline, new API documentation, and any changes to data formats or access methods.

5. Test AEMS early. As soon as device data is available in AEMS (expected May 2026), verify that your searches produce equivalent results to what you were getting from MAUDE. Flag any discrepancies early.

6. Brief your team. Ensure that everyone involved in complaint handling, MDR reporting, and PMS monitoring understands that the system is changing but the underlying regulatory obligations are not.

Common Mistakes When Using MAUDE

Even experienced regulatory professionals make errors when using MAUDE data. Here are the most common pitfalls and how to avoid them.

Mistake 1: Treating Report Counts as Incidence Rates

Report counts from MAUDE are not incidence rates. Without denominator data (total devices in use, total procedures performed), you cannot calculate a rate. Saying "Device A had 200 reports and Device B had 50 reports, therefore Device A is four times more dangerous" is statistically invalid. Device A may simply have four times the market share.

Mistake 2: Searching Only by Brand Name

Brand names in MAUDE are free-text fields with no standardization. The same device may appear under multiple name variations, abbreviations, and misspellings. Searching by brand name alone will miss reports. Always search by product code first, then validate with brand name searches.

Mistake 3: Ignoring Malfunction Reports

Many analysts focus exclusively on death and injury reports. But malfunction reports — the most voluminous category — reveal device failure modes that have not yet resulted in patient harm. These are leading indicators. A pattern of malfunction reports often precedes more serious events and is exactly the kind of signal a proactive PMS system should detect.

Mistake 4: Failing to Read Narratives

Relying solely on structured fields (event type, device problem code, patient outcome) without reading the event narratives misses critical context. Two reports both coded as "Injury" with device problem "Break" may describe fundamentally different events — one may be a cosmetic housing crack with no clinical consequence, while the other may be a catastrophic structural failure during a surgical procedure.

Mistake 5: Not Documenting Your Search Methodology

If you are using MAUDE data in any regulatory context — a 510(k), a CER, a risk analysis, or a PMS report — and you do not document your search date, search parameters, date range, number of results, and inclusion/exclusion criteria, the analysis is not reproducible and will not withstand regulatory scrutiny.

Mistake 6: Assuming Completeness

MAUDE does not contain all adverse events. Underreporting is endemic. The absence of reports for a device type does not mean the device is free of safety concerns — it may mean that events are not being reported, that the device has limited market penetration, or that its user population is unlikely to file voluntary reports.

Using MAUDE for Competitive Intelligence

MAUDE is one of the few public sources of real-world performance data for competitor devices. Here is how to use it strategically.

Identify Competitor Failure Modes

Search MAUDE for your competitor's product code, brand name, or manufacturer name. Review the event narratives to identify:

• Recurring failure modes (e.g., specific components that break, software errors, battery failures)
• Design-related issues versus manufacturing-related issues
• User error patterns that may indicate usability problems
• Whether failures are concentrated in specific model numbers or manufacturing lots
• How the competitor's manufacturer narrative characterizes their investigation findings

This information directly informs your own design risk analysis. If your competitor's device has a pattern of catheter tip fractures, your design team should specifically address that failure mode. This is not about finding vulnerabilities to exploit in marketing — it is about learning from the real-world experience of devices in your category to build a safer product.

Benchmark Reporting Volume

Compare the number of MAUDE reports for comparable devices in the same product code category. While raw report counts are not directly comparable (due to differences in market share and reporting practices), large discrepancies can suggest meaningful differences in device performance.

Use the openFDA count API to quickly compare:

https://api.fda.gov/device/event.json?search=device.device_report_product_code:"QBJ"+AND+date_received:[20240101+TO+20241231]&count=device.manufacturer_d_name.exact

This returns the number of reports per manufacturer for product code QBJ in 2024.

Track Competitor Recalls Alongside MAUDE

Cross-reference MAUDE reports with the FDA Medical Device Recall Database and FDA Safety Communications. A spike in MAUDE reports often precedes a recall or field safety corrective action.

Identify Market Gaps

Patterns in MAUDE data can reveal unmet clinical needs. If a device category has persistent reports of a specific failure mode that no manufacturer has solved, that is a product development opportunity.

Monitor a Competitor's Product Launch

When a competitor launches a new device, set up a monitoring protocol to track MAUDE reports for that device from day one. Early-stage MAUDE data for a new product can reveal manufacturing quality issues, design problems, or use errors that surface during initial market adoption — information that takes months or years to appear in published literature.

Assess a Device Category Before Entering a Market

If you are evaluating whether to develop a device in a particular category, MAUDE data gives you an unfiltered view of the real-world problems that exist. High volumes of reports for a device category may indicate a design space with significant engineering challenges — or an opportunity to build a better product.

Using MAUDE for Post-Market Surveillance and PMCF

FDA Post-Market Surveillance

For US-marketed devices, MAUDE is the primary source of post-market adverse event data. Every device manufacturer should have a systematic process for monitoring MAUDE — this is not optional, it is a regulatory expectation.

What to monitor:

• Reports for your own devices (by brand name, model number, and product code)
• Reports for equivalent devices in your product code category
• Trend analysis: Is the volume of reports for your device increasing, decreasing, or stable?
• Signal detection: Are new failure modes appearing that were not identified during premarket testing?

How to monitor systematically:

1. Set a recurring schedule (monthly at minimum, aligned with MAUDE update dates)
2. Run standardized searches using your product code and brand name
3. Review all new reports since your last search
4. Log findings in your post-market surveillance system
5. Assess whether any reports trigger MDR trend reporting obligations (21 CFR 803.53)
6. Feed findings into your risk management file and CAPA system

EU MDR Post-Market Clinical Follow-up (PMCF)

The EU Medical Device Regulation (2017/745) requires manufacturers to include a PMCF plan as part of their post-market surveillance system. MAUDE is an accepted source of external PMS data for this purpose, even for devices marketed only in the EU.

How MAUDE supports PMCF:

• Provides real-world adverse event data for equivalent devices marketed in the US
• Helps identify safety concerns that may not be apparent from European vigilance databases (which have their own data completeness challenges)
• Supplements clinical literature review with post-market safety data
• Supports the ongoing update of the Clinical Evaluation Report (CER) with current adverse event information

When using MAUDE data in a PMCF context, document your search methodology, date range, search terms, and the rationale for how you selected equivalent devices. Notified Body auditors will want to see a systematic, reproducible approach.

Practical PMCF search protocol for MAUDE:

1. Identify the equivalent device(s) marketed in the US using the FDA Product Classification Database
2. Determine the appropriate product code(s)
3. Search MAUDE for the product code(s) over a defined period (typically 5+ years)
4. Filter by event type and review all death and serious injury reports
5. Categorize reports by failure mode and patient outcome
6. Assess whether any identified risks are reflected in your risk management file
7. Document the search date, parameters, total results, and key findings in your PMCF report
8. Include a limitations statement acknowledging the known limitations of MAUDE data

Using MAUDE for 510(k) Predicate Research

When preparing a 510(k) submission, MAUDE data for your predicate device provides valuable context that strengthens your submission.

Risk Analysis Input

MAUDE reports for the predicate reveal its known failure modes and associated patient outcomes. This information should feed directly into your risk analysis (per ISO 14971). If the predicate has MAUDE reports for catheter fracture, your risk analysis should address catheter fracture — and your design should demonstrate how you have mitigated that risk.

This is not a hypothetical recommendation. FDA reviewers reviewing your 510(k) have access to the same MAUDE data for your predicate. If they see that the predicate has a known failure mode and your risk analysis does not address it, they will ask. Proactively incorporating MAUDE findings into your risk analysis demonstrates regulatory maturity and prevents avoidable review delays.

Identifying Predicate Weaknesses

If the predicate device has a significant number of MAUDE reports for a specific failure mode, and your device design eliminates or reduces that failure mode, this is a differentiator you can highlight in your substantial equivalence comparison. It does not make your device "better" for regulatory purposes (SE is about equivalence, not superiority), but it demonstrates awareness of the predicate's post-market performance.

Literature Supplement

Several peer-reviewed studies have used MAUDE data to analyze device categories. Citing these studies in your 510(k) clinical summary or risk analysis demonstrates thorough due diligence.

Key journals that publish MAUDE-based research include the Journal of Patient Safety, BMJ Quality & Safety, AAMI's Biomedical Instrumentation & Technology, and device-specific clinical journals. A PubMed search for "MAUDE database" plus your device type will often identify published analyses that have already done the heavy lifting of categorizing and analyzing reports for your device category.

What FDA Reviewers Look For

FDA reviewers have access to MAUDE data for your predicate. If your predicate has known safety issues in MAUDE, and your submission does not address those issues in your risk analysis or testing strategy, reviewers may issue an Additional Information (AI) request asking you to explain how your device mitigates those risks. Proactively addressing predicate MAUDE findings saves review cycles.

Practical Example: Using MAUDE for Predicate Research

Suppose you are developing a powered surgical stapler and your predicate is a competitor's cleared device (K-number K123456). Here is how you would use MAUDE:

1. Look up the product code for powered surgical staplers in the FDA Product Classification Database (e.g., "GAT")
2. Search MAUDE for product code "GAT" over the last 5 years
3. Filter for the predicate manufacturer and brand name
4. Review all death and injury reports — identify the top 3-5 failure modes (e.g., misfire, incomplete staple formation, tissue damage, electrical failure)
5. For each failure mode, assess whether your device design addresses it
6. Document this analysis in your risk management file (ISO 14971) with specific references to MAUDE report numbers
7. In your 510(k) submission, reference this analysis in your risk analysis summary and describe how your testing protocols address the identified failure modes

Practical Workflow: Monitoring MAUDE for Your Device Type

Here is a practical workflow that a regulatory affairs team can implement immediately.

Monthly MAUDE Monitoring Procedure

Frequency: Monthly, within one week of the MAUDE database update.

Scope: Your own devices + equivalent/predicate devices + your product code category.

Step 1 — Run standardized searches:

• Search by product code (primary search)
• Search by your brand name(s) (secondary search to catch miscoded reports)
• Search by competitor brand names (competitive monitoring)

Step 2 — Review new reports:

• Filter to reports received since your last review date
• Triage by event type: review all Death reports first, then Injury, then Malfunction

Step 3 — Assess each report:

• Does this report involve your device? If yes, cross-reference with your internal complaint file.
• Is this a new failure mode not previously identified in your risk management file?
• Does this report suggest a trend (increasing frequency of a known failure mode)?
• Does this report involve a competitor device with relevance to your design?

Step 4 — Document findings:

• Log the search date, search parameters, number of results, and key findings
• Record any reports that warrant further investigation
• Update your PMS records

Step 5 — Take action:

• New safety signals: escalate to risk management and CAPA process
• Trend identification: assess whether 21 CFR 803.53 trend reporting is triggered
• Competitive findings: share with product development and marketing as appropriate
• PMCF updates: incorporate findings into next CER/PSUR cycle

Automating MAUDE Monitoring

For companies monitoring multiple product codes or needing more frequent updates than the monthly MAUDE refresh, the openFDA API enables automation:

• Script-based monitoring: Write a script (Python, R, or any language with HTTP capabilities) that queries the openFDA API weekly, filters for new reports since the last query, and generates a summary report. A basic Python script using the requests library can query the openFDA API and produce a CSV summary in under 50 lines of code.

• Third-party tools: Several commercial tools (e.g., Celegence CAPTIS, Innolitics MAUDE Alerts) provide automated MAUDE monitoring with email alerts and dashboards. These tools are worth evaluating if your regulatory team monitors a large portfolio of product codes or if you need to demonstrate to auditors that you have a robust, continuous monitoring system.

• Custom dashboards: Use openFDA data to build internal dashboards in tools like Tableau, Power BI, or Google Data Studio for visual trend analysis. Common visualizations include reports-over-time by event type, top device problem codes, and manufacturer comparison views.

• RSS and email alerts: While MAUDE itself does not offer native alerting, the openFDA system and several third-party tools can be configured to send automated email summaries when new reports matching your criteria are published.

• Third-party MAUDE search platforms: Several commercial platforms provide enhanced search, visualization, and monitoring capabilities on top of MAUDE data. These include Device Events (cloud-based alternative with consolidated metrics and trend visualizations), Redica Systems (data visualization, benchmarking, and inspection readiness tools), Flinn.ai (AI-enabled safety database monitoring covering MAUDE and 14+ international databases), Nested Knowledge (systematic review platform with MAUDE search integration), and AI-powered search tools like Medical Sys Consult's AI Assistant (which generates automated PDF summary reports from MAUDE data). These tools address many of MAUDE's usability limitations — poor search functionality, the 500-record cap, lack of visualization, and the inability to cross-reference with other databases — and are worth evaluating if your team monitors a large device portfolio or needs audit-ready reporting.

Documenting Your Monitoring Process

Whatever approach you use, document it in your PMS procedures. Your documentation should include:

• The scope of monitoring (which product codes, brand names, competitors)
• The frequency of monitoring
• The search parameters used
• Who is responsible for performing the review
• How findings are escalated (criteria for triggering a CAPA or MDR trend report)
• Where results are recorded (PMS file, quality system database)

Auditors — both FDA inspectors and Notified Body auditors — will ask to see evidence of systematic post-market surveillance. Having a documented, repeatable MAUDE monitoring process is a fundamental element of compliance.

Understanding MAUDE Report Volume and Trends

To put MAUDE data in context, it helps to understand the scale and trends in reporting over time.

Reporting Volume Over Time

MAUDE reporting volume has increased dramatically since the database was established. In the early 1990s, the database received hundreds of thousands of reports per year. By the 2010s, annual volumes exceeded one million. The increase reflects a combination of factors: more devices on the market, increased regulatory enforcement of reporting requirements, growing awareness among voluntary reporters, and expanded definitions of reportable events.

Distribution by Event Type

Across the entire MAUDE database, malfunctions account for the vast majority of reports — roughly 70-80% in most years. Injury reports make up approximately 15-25%, and death reports represent 1-3% of total reports. These proportions vary significantly by device category. High-risk implantable devices tend to have a higher proportion of death and injury reports relative to malfunctions, while Class II devices with large installed bases generate predominantly malfunction reports.

Top Device Categories by Report Volume

Certain device categories generate disproportionately high volumes of MAUDE reports. These include:

• In vitro diagnostic devices — High volume due to the sheer number of tests performed
• Infusion pumps — Complex electromechanical systems with high utilization rates
• Surgical staplers — High-profile safety concerns have driven increased reporting
• Implantable cardiac devices (pacemakers, defibrillators) — Long implant life and life-sustaining function generate sustained reporting
• Hip and knee implants — Large patient populations with long follow-up periods
• Glucose monitors — Massive installed base with daily use patterns

Understanding the baseline reporting volume for your device category is essential for interpreting your own device's MAUDE profile. If your product code typically generates 500 reports per year and your device has 10, that contextualizes your data very differently than if the typical volume is 20.

Bulk Data Download and Analysis

For large-scale research or integration into internal systems, bulk data access is the most practical approach.

openFDA JSON Downloads

The openFDA website provides quarterly bulk download files in JSON format at open.fda.gov/data/downloads/. These files contain the complete MAUDE dataset and can be loaded into databases (PostgreSQL, MongoDB) or data analysis tools (Python/pandas, R).

Raw ASCII Files

The FDA also provides raw MAUDE data files in ASCII (pipe-delimited text) format from the CDRH website. These are the source files that feed into the MAUDE search interface and the openFDA API. They are available at fda.gov/medical-devices/mandatory-reporting-requirements-manufacturers-importers-and-device-user-facilities/manufacturer-and-user-facility-device-experience-database-maude.

Technical notes for importing raw ASCII files:

• Header rows are present only in the Master Event and Device files — the Patient, Text, and supplemental files do not include headers, so you must apply column names manually based on the MAUDE data dictionary.
• Rare non-printing line-feed characters within text fields can cause data import tools to prematurely truncate records. In SAS, use the TERMSTR=CRLF option; in R, use the quote parameter in read.csv() to handle embedded quotes correctly.
• Double quotation marks are used inconsistently in the raw files — they may indicate word emphasis, measurements, or missing values. Standard CSV parsers may mishandle these unless configured to tolerate irregular quoting.
• The Text file contains 2 or more times as many records as the Master Event file because a single report can generate multiple text entries (event description, manufacturer narrative, additional manufacturer narrative, etc.).

Data Linkage

MAUDE data becomes significantly more powerful when linked with other FDA datasets:

Dataset	Link Field	What You Gain
510(k) database	Product code	Connect adverse events to specific cleared devices
PMA database	Product code, PMA number	Connect adverse events to approved devices
Recall database	Product code, manufacturer	Correlate adverse event spikes with recalls
GUDID / UDI database	UDI-DI (available in newer MAUDE records)	Precise device identification down to model/version
Product Classification	Product code	Map adverse events to device classification and regulation number

Technical note: The MDR_REPORT_KEY field is the primary key for linking across MAUDE's internal files (Master Event, Device, Patient, Text). The DEVICE_REPORT_PRODUCT_CODE field (3-letter product code) is the key for linking MAUDE to external FDA databases.

Alternative FDA Safety Databases

MAUDE is not the only FDA resource for device safety data. Depending on your needs, other databases may be more appropriate — or should be used in combination with MAUDE.

Database	What It Contains	Best For
MAUDE	Adverse event reports (MDRs)	Individual event analysis, failure mode research, trend monitoring
TPLC	Integrated premarket + postmarket data by product code	High-level overview of entire device category lifecycle
MedWatch	Safety alerts, recalls, and the voluntary reporting form	Staying current on FDA safety actions
Medical Device Recall Database	Recall information since 2002	Tracking corrective actions and root causes
MedSun	Reports from a network of ~350 clinical facilities	Focused, higher-quality adverse event reports for specific device categories
AEMS (new, 2026)	Consolidated adverse events for all FDA-regulated products	Cross-product safety analysis, real-time reporting
openFDA	API access to MAUDE + other FDA datasets	Programmatic analysis, automation, bulk data access
GUDID / AccessGUDID	Device identification data (UDI)	Identifying specific devices by UDI, linking to MAUDE
522 Post-Market Surveillance Studies	Studies mandated under Section 522	Understanding long-term safety data requirements for specific devices

MedSun: A Higher-Quality Alternative for Some Device Categories

The Medical Product Safety Network (MedSun) deserves special mention. Unlike MAUDE, which captures passively reported events, MedSun is an active surveillance network of approximately 350 healthcare facilities that collaborate with the FDA to identify, understand, and resolve medical device safety issues.

MedSun reports tend to be higher quality than typical MAUDE reports because they are submitted by trained clinical contacts at participating facilities who provide detailed clinical context. If your device category is covered by MedSun, reviewing MedSun reports in addition to MAUDE provides a more complete picture of real-world device performance.

MedSun reports are searchable through the MedSun database.

When to Use Multiple Databases Together

No single FDA database gives you the complete picture. For comprehensive device intelligence, combine multiple sources:

Pre-submission research workflow:

1. Product Classification Database — Identify product code and classification
2. 510(k) / PMA / De Novo databases — Identify cleared/approved devices in the category
3. TPLC — Get a high-level overview of premarket and postmarket activity
4. MAUDE — Drill into specific adverse event reports
5. Recall database — Check for field actions and root causes
6. GUDID — Look up specific device identifiers for precise device matching

Post-market monitoring workflow:

1. MAUDE (monthly) — Monitor adverse events for your device and competitors
2. Recall database (monthly) — Monitor recalls in your product code category
3. MedWatch (ongoing) — Check for FDA Safety Communications
4. MedSun (quarterly) — Review active surveillance reports if available for your device type

Frequently Asked Questions

What does MAUDE stand for?

MAUDE stands for Manufacturer and User Facility Device Experience. It is the FDA's database of medical device adverse event reports (Medical Device Reports, or MDRs) submitted under 21 CFR Part 803.

Is MAUDE data free to access?

Yes. The MAUDE web search interface, the openFDA API, and bulk data downloads are all free and publicly accessible. No registration or API key is required for basic access (though an openFDA API key increases rate limits).

How far back does MAUDE data go?

The MAUDE web search interface covers the last 10 years of data. The openFDA API and bulk download files contain data from 1991 to present, though earlier records (before approximately 2000) tend to have less structured data and fewer populated fields.

How often is MAUDE updated?

The MAUDE web search interface is updated monthly. The openFDA API is updated weekly. In both cases, there is a processing lag between when the FDA receives a report and when it appears in the public database. Note that with the transition to AEMS (expected May 2026), the FDA has announced that reports will be published in real-time.

Can I use MAUDE data in a regulatory submission?

Yes. MAUDE data is commonly cited in risk analyses (ISO 14971), Clinical Evaluation Reports (EU MDR), 510(k) clinical summaries, and post-market surveillance reports. When referencing MAUDE data in a submission, document your search methodology, date range, search parameters, and the specific reports you relied on. Acknowledge the limitations of the data (no denominator, unverified reports, potential underreporting).

Does a MAUDE report mean the device is defective?

No. A MAUDE report means that someone reported an adverse event involving a device. The report is not verified or investigated by the FDA before publication. The presence of a report does not confirm that the device caused the event, was defective, or malfunctioned. Many reports describe events where user error, patient comorbidities, or other non-device factors were the primary cause.

Are manufacturers notified when a report is filed against their device?

Manufacturers are required to submit their own reports and are therefore aware of those. For reports filed by user facilities or voluntary reporters, the FDA may forward the report to the manufacturer if the manufacturer is identified, and the manufacturer may be required to investigate and submit a supplemental report.

Can I report a device problem to MAUDE myself?

Yes. Any person — healthcare professional, patient, caregiver, or consumer — can submit a voluntary report through the MedWatch program using FDA Form 3500. The report will appear in MAUDE as a voluntary report.

How do I find the product code for my device?

Use the FDA Product Classification Database. Search by device name, regulation number, or browse by panel (medical specialty). The product code is the three-letter code (e.g., "DXL," "QBJ," "MNH") assigned to each generic device type.

What is the difference between MAUDE and MedWatch?

MedWatch is the FDA's safety information and adverse event reporting program — it is the submission portal where voluntary reporters file reports and where the FDA publishes safety alerts. MAUDE is the database that stores medical device adverse event reports. Reports submitted through MedWatch (and through mandatory reporting channels) end up in MAUDE. Think of MedWatch as the front door and MAUDE as the filing cabinet.

Why does my MAUDE search show exactly 500 results?

The MAUDE web interface caps both simple and advanced search results at 500 records per query. If your search returns exactly 500 results, it is almost certain that additional matching records exist beyond that cap. To retrieve complete results, narrow your date range into smaller intervals (e.g., 2-3 week windows), run multiple searches, and combine the results. Alternatively, use the openFDA API, which returns up to 1,000 records per query and supports a skip parameter for pagination through larger result sets, or download the bulk data files for comprehensive analysis.

What is the Alternative Summary Reporting (ASR) program and how does it affect MAUDE data?

The ASR program (1997-2019) allowed manufacturers of certain devices to report well-known malfunctions in summary form rather than as individual MDRs. These ASR reports were not included in the MAUDE database because they used an incompatible submission format. This means MAUDE significantly underrepresents malfunction reports for devices enrolled in ASR during that period. The FDA ended the ASR program in June 2019 and replaced it with the Voluntary Malfunction Summary Reporting (VMSR) program, which does publish reports in MAUDE. Historical ASR data is available in separate legacy data files on the FDA website.

What do "(b)(4)" and "(b)(6)" mean in MAUDE report text?

These are FOIA redaction markers. (b)(4) replaces text containing trade secret or confidential business information (e.g., product composition, proprietary manufacturing details). (b)(6) replaces personal or medical files information (e.g., patient age, date of birth, or other individually identifiable health information). These redactions protect both commercial confidentiality and patient privacy.

Are there third-party tools that make MAUDE easier to search?

Yes. Several commercial platforms provide enhanced search, visualization, and monitoring capabilities on top of MAUDE data. Examples include Device Events, Redica Systems, Flinn.ai, and Nested Knowledge. These tools address common MAUDE usability limitations such as the 500-record search cap, lack of trend visualization, absence of alerting, and difficulty cross-referencing with other FDA databases. They are worth evaluating for teams that monitor large device portfolios or need audit-ready reporting.

Will MAUDE be shut down when AEMS launches?

The FDA plans to migrate MAUDE data into the new AEMS platform by the end of May 2026. MAUDE's functionality — searching and accessing medical device adverse event reports — will be available through AEMS, but the legacy MAUDE web interface will likely be retired. The underlying reporting obligations under 21 CFR Part 803 remain unchanged regardless of which database platform is used.

How do I cite MAUDE data in a publication or report?

Include the database name, search date, search parameters, number of results retrieved, and the URL. Example: "A search of the FDA MAUDE database (accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm) was conducted on [date] using product code [XXX] and date range [start–end]. [N] reports were identified and reviewed."

What are the penalties for failing to submit an MDR?

Failure to submit required MDRs is a violation of federal law. Consequences include:

• FDA warning letters citing failure to report under 21 CFR Part 803
• 483 observations during FDA inspections
• Consent decrees requiring corrective action and ongoing FDA oversight
• Civil money penalties (fines)
• Criminal prosecution in cases of willful failure to report, particularly when the failure contributes to patient harm

The FDA has pursued criminal charges against individuals and companies for systematic under-reporting. This is not a theoretical risk — it has happened and continues to happen.

Can MAUDE data be used in product liability lawsuits?

Yes, and it frequently is. Plaintiff attorneys routinely search MAUDE for adverse event reports related to a device involved in a lawsuit. MAUDE data can be used to demonstrate that a manufacturer was aware of a failure mode (because they submitted MDRs about it), to show a pattern of similar events, or to challenge the manufacturer's claim that an adverse event was an isolated incident. However, courts also recognize the limitations of MAUDE data — reports are unverified allegations, and the database cannot demonstrate causation or incidence rates.

How is MAUDE different from FAERS?

FAERS (FDA Adverse Event Reporting System) is the equivalent database for drugs, biologics, cosmetics, and color additives. MAUDE covers only medical devices. The two databases have different data structures, different reporting requirements, and historically had separate search interfaces. With the launch of AEMS in 2026, both datasets are being consolidated into a single platform.

Key Takeaways

• MAUDE is the FDA's database of medical device adverse event reports, containing over 16 million reports dating back to 1991. It is the primary US source of post-market device safety data.

• Three categories of reporters are legally required to submit reports under 21 CFR Part 803: manufacturers, importers, and device user facilities. Voluntary reports from clinicians, patients, and consumers are also included.

• The three-letter FDA product code is the most reliable search field. Brand names and manufacturer names are inconsistently entered. Always start your search with the product code.

• MAUDE has significant limitations. Underreporting, no denominator data, unverified reports, inconsistent data quality, and monthly update lag all affect the reliability and interpretability of the data.

• A MAUDE report is not proof that a device caused harm. Reports are allegations, not confirmed findings. They are not verified by the FDA before publication.

• Use the openFDA API for serious analysis. The web interface is limited to 10 years of data and monthly updates. The API provides weekly updates, data back to 1991, and full structured data in JSON format.

• MAUDE is being absorbed into the new FDA AEMS platform by the end of May 2026. Reporting obligations under 21 CFR Part 803 are not changing, but the interface, URLs, and APIs will change. Plan your transition now.

• Every device manufacturer should have a systematic MAUDE monitoring process as part of their post-market surveillance system. Monthly monitoring, at minimum, aligned with database update dates.

• MAUDE is a strategic tool, not just a compliance database. Use it for competitive intelligence, predicate device research, risk analysis input, PMCF data sourcing, and product development insight.

• Document your methodology. Whether you are using MAUDE data for a regulatory submission, a CER, a risk analysis, or a research publication, document your search parameters, date range, and analytical approach. Reproducibility matters.

Bottom Line

The MAUDE database is one of the most underutilized tools in the medical device industry. Many companies treat it as a compliance obligation — they submit their own MDRs and never look at it again. The companies that gain a real advantage are the ones that use MAUDE proactively: to monitor their own devices, to understand their competitors, to inform their design decisions, and to build a defensible post-market surveillance system.

The data is imperfect. The limitations are real. But no other publicly available resource gives you this level of visibility into the real-world performance of medical devices. Learn to search it effectively, interpret it critically, and integrate it into your regulatory and product development workflows. With AEMS on the horizon, the underlying data will only become more accessible and more timely.

Start with your product code. Set up a monthly monitoring process. Read the narratives. Document your findings. That is the foundation.