Health care equipment data: 25.7 million adverse-event reports and the registry behind them · Head-to-head
openFDA Device Adverse Events (MAUDE) API vs openFDA Device Registration & Listing API
Which health care equipment data: 25.7 million adverse-event reports and the registry behind them data fits your job: openFDA Device Adverse Events API, or openFDA Device Registration & Listing API. API, files, or your warehouse. Daily, weekly, or hourly.
openFDA Device Adverse Events (MAUDE) API
openFDA Device Registration & Listing API
Where the fields line up
No shared field names. These two answer different questions.
| Field | openFDA Device Adverse Events API | openFDA Device Registration & Listing API |
|---|---|---|
mdr_report_key | Unique identifier for the adverse event report - an 8-digit string whose final digit is a checksum. Every device, patient and narrative in the record hangs off this key. | not in this set |
event_type | Outcome associated with the event: Death, Injury, Malfunction, Other, or no answer provided. The single most-used split on the whole corpus. | not in this set |
date_of_event | Actual or best estimate of the date the adverse event first onset, as reported; YYYYMMDD format. Present on reports from 2006 onward. | not in this set |
date_received | Date FDA received the report. The gap between date_of_event and date_received is the reporting lag analysts measure. | not in this set |
report_source_code | Who filed the report: manufacturer, user facility, distributor, or a voluntary submission from a health professional, patient or consumer. | not in this set |
manufacturer_name | Name of the device manufacturer implicated in the report as submitted; group via the harmonized identifier rather than the raw string, since subsidiaries share names. | not in this set |
device.brand_name | Trade or proprietary name of the suspect device as used in labeling or catalog; reads NA on reprocessed single-use devices. | not in this set |
device.generic_name | Generic or common name of the suspect medical device, or a generally descriptive name when no trade name applies. | not in this set |
device.model_number | Exact model number from the device label or accompanying packaging - the field that separates one firmware generation from the next. | not in this set |
device.device_report_product_code | Three-letter FDA product classification code identifying the device category under 21 CFR Parts 862-892. The standard join key across the FDA device stack. | not in this set |
device.implant_flag | Whether the suspect device is an implant (Y/N) - the fastest cut between implantable and non-implantable safety questions. | not in this set |
patient.patient_age | Patient's age at the time of the event, exactly as reported; unvalidated and frequently missing on voluntary submissions. | not in this set |
Coverage, side by side
| openFDA Device Adverse Events API | openFDA Device Registration & Listing API | |
|---|---|---|
| Geographic | No documented address columns; geography enters through the implicated firm | `registration.city`, `registration.iso_country_code` |
What each contains
Pick by fit, not by loyalty.
| openFDA Device Adverse Events API | openFDA Device Registration & Listing API | |
|---|---|---|
| FDA product code | `device.device_report_product_code` | `products.product_code` |
| Regulated device identity | `openfda.device_name`, `openfda.device_class`, `openfda.regulation_number` | `products.openfda.device_name`, `products.openfda.device_class`, `products.openfda.medical_specialty_description` |
| Firm identity | `manufacturer_name` | `registration.name` plus `registration.owner_operator.firm_name` |
| Record identifier | `mdr_report_key` (8-digit string, checksum final digit) | `registration.registration_number` plus `registration.fei_number` |
| Dates | `date_of_event`, `date_received` | `products.created_date`, `registration.reg_expiry_date_year` |
| Patient detail | `patient.patient_age`, `patient.patient_sex`, `patient.patient_problems` | Not carried |
| Narrative text | `mdr_text.text` | Not carried |
| Establishment role | Not carried | `establishment_type`, `registration.initial_importer_flag`, `registration.us_agent.email_address` |
| Facility geography | No documented address columns; geography enters through the implicated firm | `registration.city`, `registration.iso_country_code` |
| Premarket references | `openfda.regulation_number` is the nearest analogue | `k_number`, `pma_number` |
What each does better
openFDA Device Adverse Events API
Scale with memory. 25,711,469 records, publicly releasable from roughly 1992 to the present, growing by several hundred thousand reports a year. Any question about how a device category behaves in the field over time has no alternative instrument - see MAUDE adverse event reporting.
Outcome typing. Every report lands in event_type - Death, Injury, Malfunction, Other - and report_source_code separates mandatory reports from manufacturers, importers and user facilities against voluntary reports from clinicians and patients. Malfunction-only signals, death-to-malfunction ratios, reporter-mix shifts: all computable straight from the dictionary.
Traceability hooks. The nested device array carries brand, generic and model names, catalog and lot numbers, an implant flag, and UDI public identifiers on devices marked since October 2022 - enough to follow a suspect lot rather than a suspect category.
Human texture. Patient age, sex and reported problems, plus the narrative text of the report itself - the part of a medical device report that no summary table reproduces. The registration record, being a facility-product pair, structurally cannot hold any of it.
openFDA Device Registration & Listing API
The who-and-where map. Establishments producing devices for US use must register, and most must list what they make - which turns this into a census of the manufacturing base: 333,804 facility-product pairs, US and foreign plants alike, each pinned with name, city, ISO country code and FEI number. For supply-chain mapping this is the denominator the events ledger lacks.
Roles, not just addresses. establishment_type distinguishes contract manufacturers, contract sterilizers, repackagers and relabelers; initial_importer_flag separates importers from makers; a nested US-agent block identifies representatives of foreign firms, and an owner-operator block ties each plant to its corporate parent. Competitive-footprint work starts here; see competitor tracking.
Premarket anchoring. Records cite their 510(k) or PMA numbers, so a listing connects to the pathway that cleared it, and products.created_date timestamps when a product entered the listing - a launch calendar hiding in a regulatory file. The FDA product code itself is unpacked in FDA product code.
Company-shaped queries. Because the grain is establishment-with-listings, one filter returns a firm's entire declared portfolio across categories - something the event ledger only approximates by counting incidents.
The verdict
Verdict: sample both, pick by fit - the unit of analysis decides.
Nothing else answers it.
It is the only one shaped for supplier discovery and footprint analysis.
If your question names a company, they compose: registration supplies the establishments and declared listings, the events ledger supplies the incident history on the same product codes. Neither replaces the other, and neither wins on craft margins wide enough to excuse guessing - let returned rows make the call.
Sample both, pick by fit. See openFDA Device Adverse Events API · See openFDA Device Registration & Listing API
Fair questions
Which dataset reaches further back?
The events record. Publicly releasable adverse event reports run to roughly 1992, giving three decades of field history per device category. Registration documentation runs from 2007 onward, which suits mapping today's manufacturing base rather than replaying its past.
Do the two datasets overlap?
On two concept families: the FDA product code (`device.device_report_product_code` against `products.product_code`) and the `openfda{}` block resolving codes into regulated device names, classes and regulation numbers. Firm names appear in both, differently framed. Everything else - patient detail, narratives and implant flags on one side; addresses, establishment roles and premarket references on the other - belongs exclusively to one dictionary.
Which one should a medtech analyst sample first?
Sample both, pick by fit. Working a safety signal, recall precursor or complaint backlog for a product code? Sizing a category, finding suppliers or mapping a competitor's manufacturing footprint? Name the codes, firms and date windows when you request the sample and it arrives pre-cut.
Can Datadory deliver both datasets together?
Yes. Either record arrives alone or merged onto one delivery calendar, normalized on product code and firm name so events roll up to establishments before it reaches you - delivered daily, weekly, or hourly, your call. Samples come with field definitions and coverage profiles attached.