MAUDE data is due to move into the FDA’s Adverse Event Monitoring System, and the agency has not said when the device side will switch. The useful work now is knowing what in your own program depends on MAUDE.
Where the migration stands
The FDA launched AEMS on 11 March 2026 with drug adverse event data from FAERS. It has said MAUDE data will become available there. As I write, openFDA’s device adverse event API still names MAUDE as its source and refreshes weekly, and eMDR submissions are accepted as before.
Reporting obligations have not changed. 21 CFR Part 803 sets the same deadlines and the same definitions of a reportable event. AEMS changes the system, and the rules stay as they are.
I keep the current state in what FDA AEMS means for MAUDE searches. DeviceWatch once described the device migration as complete. It was not.
A checklist for surveillance teams
1. Map what depends on MAUDE. List every place that reads MAUDE data or submits MDRs:
the surveillance system or platform
scripts and queries against the openFDA API
MDR submission workflows, whether eSubmitter, a third-party platform or a custom integration
dashboards that show MAUDE-derived metrics
PSURs and other reports that cite MAUDE
Each is a place a source change could break.
2. Watch the FDA’s own channels. The MDR Data Files page, the AEMS page and the openFDA documentation are where a change will be documented. We got this wrong once by not checking the FDA’s own page.
3. Keep the raw data. Store source records beside the processed ones. If field names or coding change, you can reprocess instead of losing history.
4. Keep field mappings configurable. A pipeline with hard-coded field names needs a rebuild when the source changes. One with a mapping layer needs a configuration change.
5. Plan for two sources and update the PMS plan. During a transition, the same data may be available from both systems with differences in completeness or deduplication. Decide which you will treat as the source of record and test your queries against the new one before switching. When the source changes, the post-market surveillance plan should say so, because auditors compare the documented process with the real one.
What might change later
The FDA has described AEMS as a single platform for drug, biologic and device reports, with better deduplication as a goal. A move to a new submission format, possibly built on HL7 FHIR, is expected at some point. The agency has published no device specification and no date, so none of it is worth building for yet.
How DeviceWatch is handling it
DeviceWatch reads device adverse event data from the openFDA API and keeps source handling separate from analysis, which gives us one place to adapt when the FDA documents a device channel. It also monitors openFDA, the MAUDE bulk files, the MDR Data Files page and the AEMS page, and flags changes for review.