Correction (August 2026): An earlier version of this article said the FDA completed a MAUDE-to-AEMS device migration in May 2026. That was wrong. No such migration has happened. The article below has been rewritten against the FDA's primary sources, and the correction is left visible rather than quietly edited out.
No. MAUDE is still the FDA's device adverse event database, still where your reports go, and still where your surveillance data comes from.
The confusion is understandable. AEMS is real, it launched in March 2026, and the FDA has said devices are in scope. But what launched was the replacement for FAERS, the drug side. Devices have not moved.
What AEMS Actually Is
AEMS is the FDA's program to consolidate adverse event reporting into one platform across drugs, devices, vaccines, tobacco, food, cosmetics and veterinary medicine. The FDA's own page describes it in the present progressive: the agency "is implementing" AEMS, and AEMS "will serve" as a centralized platform.
That page sits under the FDA's drug section, is tagged "Regulated Product(s): Drugs", and carries the subtitle "[Formerly FDA Adverse Event Reporting System (FAERS)]". Every concrete link on it points at FAERS resources: the FAERS quarterly data files, the FAERS public dashboard, FAERS electronic submissions.
Devices appear once, in the list of categories AEMS will eventually consolidate.
What This Means for Device Teams
Three things are true right now.
MAUDE is the source of record. New medical device reports submitted under 21 CFR Part 803 still land in MAUDE. The historical archive is still MAUDE's.
There is no AEMS device API. No device endpoint, no device bulk download, no device quarterly file. If a vendor tells you they pull device data from an "AEMS API", ask for the endpoint URL. There is not one to give.
openFDA still says MAUDE because it is MAUDE. The openFDA device/event API documentation names MAUDE as its source and shows weekly refreshes with no deprecation notice. That is not documentation lag. It is accurate.
Why This Got Reported Wrong
AEMS launched with real fanfare in March 2026, and the announcement named devices among the systems it would eventually consolidate. A launch plus a list of future scope reads a lot like a completed migration if you skim it.
Then device adverse event publishing paused twice in 2026, once from late May and again from late July. A data feed going quiet right after a consolidation announcement looks like a cutover. It was not. Publishing resumed both times through the same MAUDE channels, and the data is current again.
How to Verify This Yourself
Do not take our word for it. Three sources settle it in about five minutes:
- The AEMS page (fda.gov/drugs/surveillance-post-drug-approval-activities/fda-adverse-event-monitoring-system-aems). Read the tense. Check which product category it is filed under.
- The MDR Data Files page (fda.gov/medical-devices/medical-device-reporting-mdr-how-report-medical-device-problems/mdr-data-files). This is where device bulk files live. Check whether they are still MAUDE files.
- The openFDA device/event docs (open.fda.gov/apis/device/event/). Check the named source and the refresh cadence.
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 to Do Now
Not much, which is the point.
Keep your surveillance running against openFDA. It is the live, FDA-supported source for device adverse event data, and nothing about AEMS requires you to switch.
Do not rename MAUDE in your SOPs yet. If you already did, that is worth correcting. A procedure naming a system that holds no device data is a finding waiting to happen.
Do add the indirection now. Describe the obligation and the access method in the procedure, and name the current system in one controlled appendix. When devices do migrate, you edit one document instead of twelve.
Watch the three pages above. Monthly is enough. Log the check.
The Bottom Line
MAUDE is not going away yet. AEMS is coming, the FDA has committed to it publicly, and devices are in scope. But announced and done are different things, and right now the gap between them is where a lot of bad documentation is being written.
DeviceWatch reads device adverse events from the openFDA device/event API, because that is where the FDA serves this data. We watch the FDA's channels for the device cutover and will follow it when it happens.