Yes, and it already happened. In May 2026 the FDA completed the move of device adverse event data into the Adverse Event Monitoring System (AEMS) and retired MAUDE as a standalone system. New medical device reports now land in AEMS, and the full historical MAUDE archive moved with them.
For most surveillance teams the day-to-day access did not change, which is the part worth understanding. The openFDA device/event API you already query is still live, still refreshes weekly and still returns device adverse event records. What changed sits underneath it: the system of record, not the pipe you pull from.
What AEMS Is
AEMS is the FDA's consolidated platform for adverse event data across drugs, biologics and devices. It launched on March 11, 2026 with drug data migrated from FAERS and a public dashboard built on Qlik Sense (fda.gov/safety/fda-adverse-event-monitoring-system-aems). The device migration followed in May, folding MAUDE into the same system.
The ambition is real and overdue: one modern platform replacing a patchwork of databases that dated to the 1990s. Better deduplication, richer structured fields and eventually faster processing are the stated goals. The device side is now part of that system rather than a separate legacy database.
What Actually Changed
Three things moved. A few important ones did not.
MAUDE became the archive inside AEMS. The decades of historical device reports did not disappear. They are queryable through AEMS, and through the openFDA endpoint that serves this data.
New reports flow into AEMS. Manufacturer and user-facility reports submitted under 21 CFR Part 803 now land in the new system rather than the standalone MAUDE database.
The legacy MAUDE database was retired as a system of record. Consolidation is the whole point of AEMS, so running MAUDE as a separate platform alongside it would defeat the purpose.
What did not change matters just as much. Your reporting obligations under 21 CFR Part 803 are untouched: the same deadlines, the same definitions of a reportable event, the same content requirements. Only the system that receives and stores the reports changed.
Why openFDA Still Says "MAUDE"
Here is the nuance that trips people up. The openFDA device/event API documentation still names its source as MAUDE and still shows weekly refreshes with no deprecation notice (open.fda.gov/apis/device/event/). That is not a contradiction. openFDA is the delivery layer, AEMS is the system of record behind it. The endpoint serves the same device adverse event data — new reports and the historical archive — that now lives in AEMS. Documentation labels lag system changes, and the FDA has not yet relabeled every downstream surface.
The practical implication: there is no separate public AEMS API for device data to point your tooling at. openFDA remains the API. If a vendor tells you they pull device data from a distinct "AEMS API," ask for the endpoint URL. There is not one to give.
How to Verify This Yourself
Don't take anyone's word for it, including ours. The primary sources tell the story:
- The AEMS page (fda.gov/safety/fda-adverse-event-monitoring-system-aems) describes the system and its scope.
- The MDR Data Files page (fda.gov/medical-devices/medical-device-reporting-mdr-how-report-medical-device-problems/mdr-data-files) tracks the device data's move into AEMS.
- The openFDA updates page (open.fda.gov/about/updates/) shows the device event dataset's refresh date and record count, so you can confirm data is still flowing.
Archive what you find. A dated PDF of each page in your quality records turns a five-minute check into evidence an auditor can use a year from now.
What Device Companies Should Do Now
The migration is done, so the work is reconciliation, not preparation.
Keep your surveillance running against openFDA. It is the live, FDA-supported source for device adverse event data. Nothing about the AEMS cutover requires you to switch endpoints.
Update your SOP wording once, carefully. Your post-market surveillance plan should name the data source you actually use. The durable phrasing points at the obligation and the access method, then references the current system through a single controlled appendix: "device adverse event data obtained from the FDA's public device adverse event source, currently AEMS accessed via the openFDA device/event API." When a label changes again, you edit one appendix.
Run a bridging check on your trend baselines. If AEMS deduplication consolidates records that MAUDE double-counted, raw report counts can step down for reasons that have nothing to do with device safety. Compare a period across the cutover and document any difference before it surfaces as a phantom signal in a PSUR.
Archive your raw API responses. A source-system migration turns slow data drift into a step change. Keeping the raw responses, with retrieval timestamps, protects the reproducibility of every surveillance decision you made.
The Bottom Line
MAUDE is going away in the only sense that matters: it is no longer a separate system. Its data lives on in AEMS, and you still reach that data through the openFDA API you already use. The move completed in May 2026.
If leadership asks, the one-sentence summary is: the FDA consolidated device adverse event data into AEMS, your access through openFDA is unchanged, and the work now is updating documentation to match.
DeviceWatch monitors device adverse events through the openFDA device/event API, because that is where the FDA serves this data. We handled the AEMS transition server-side. Our customers kept the same products, the same review queue and the same reports, with new plumbing underneath. That is what the migration should look like for you too — an infrastructure event, not a compliance crisis.