Device adverse event data moved into the FDA's Adverse Event Monitoring System (AEMS) in May 2026, and MAUDE was retired as a standalone system. The direction was certain for months. Now it is done. If your post-market surveillance program still names MAUDE as its source, this is the checklist that brings your documentation into line without a scramble.
Everything here can be done in a week. The good news for anyone who prepared early: the openFDA device/event API you pull from did not change, so this is reconciliation work, not a rebuild.
If you want the full picture of what moved and what did not, read our companion article on whether MAUDE is going away. Short version: AEMS launched March 11, 2026 with drug data from FAERS, the device migration completed in May, and the openFDA device/event API still serves this data weekly as the delivery layer in front of AEMS.
Step 1: Fix SOP Wording So the Next Change Is Painless
The most common documentation mistake is hardcoding a system name into every procedure step. If your PMS SOP said "search MAUDE" in twelve places, the AEMS cutover meant twelve edits, a document revision, retraining records and possibly revalidation. The fix stops that from happening again.
Use one level of indirection. Describe the obligation and the data type in the procedure, and point to the specific system through a single controlled reference. For example:
"Adverse event data for monitored devices is obtained from the FDA's public device adverse event data source, currently AEMS accessed via the openFDA device/event API. The current source system, access method and refresh cadence are maintained in [controlled appendix or work instruction]."
Update that one appendix now to name AEMS. When the FDA renames or re-endpoints something again, you touch one document. The procedure itself, the training records and the validation rationale stay intact.
Apply the same pattern to your PMS plan, your surveillance work instructions and any data source references in report templates. The test: if the FDA renamed its database tomorrow, how many documents would you touch? The right answer is one.
Step 2: Keep Monitoring the Three FDA Pages
The migration is complete, but the follow-on work is not. AEMS-native submission specifications, new structured fields and API refinements will land over the coming months, and they will show up on FDA pages before anywhere else. Three pages cover it:
- The AEMS page (fda.gov/safety/fda-adverse-event-monitoring-system-aems) — the FDA's official description of the system. Watch for device-specific documentation and API announcements.
- 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 status in AEMS. Watch for changes to submission format guidance.
- The openFDA updates page (open.fda.gov/about/updates/) — shows the refresh date and record count for the device/event dataset. Watch for data-model changes, deprecation notices or cadence shifts.
A monthly check is enough. The important part is logging it: a one-line entry in your quality system each month — date, pages checked, change or no change — turns ad hoc awareness into documented surveillance of your own data source. Auditors notice the difference.
The FDA also offers email subscriptions for CDRH announcements, which can shorten the gap between an announcement and your next scheduled check. Treat the subscription as a supplement, not a replacement — the logged monthly review is what you can show an auditor.
Step 3: Document the Source Change for Auditors
At some point in the next year, an auditor or notified body reviewer will ask how your surveillance program handled the MAUDE-to-AEMS move. The answer is simple, but it lands much better as a dated memo than as an improvised explanation.
Write a short rationale memo, one page, that records:
- The facts as verified. The FDA completed the device data migration to AEMS in May 2026. Device adverse event data, including the full historical MAUDE archive, is served through the openFDA device/event endpoint, refreshed weekly. There is no separate public AEMS API for device data.
- The sources. The three FDA pages above, with the dates you checked them. Archive copies — a PDF print of each page is fine.
- What you changed and when. The SOP appendix update, the date you switched your documented source name to AEMS, and the bridging analysis described below.
- Your transition owner. Who watches, who decides, who executes.
This memo converts a source-system change from an apparent gap into a documented, deliberate action. That is the difference between a finding and a compliment.
Step 4: Protect PSUR Data Continuity
The hardest technical problem in a source-system change is period-over-period comparability. Your PSURs and trend reports compare this period's adverse event counts against historical baselines. When the underlying source changes mid-stream, those comparisons can shift for reasons that have nothing to do with device safety.
Improved deduplication is a stated goal for AEMS. That is good news for data quality and bad news for naive trend lines: if duplicate reports are consolidated, raw counts may drop at the cutover even though nothing changed in the field. A reviewer who does not know about the source change could read that as a safety improvement. A reviewer who does could face questions about why the baseline moved.
Four practices protect you:
- Archive raw extracts for every reporting period. Keep the actual API responses used to build each PSUR, not just the finished report. When the numbers shift, you can prove what each source said.
- Record the source system and extraction date in each report. One line in the methodology section: data source, endpoint, date retrieved, record count. MDCG 2022-21 expects your PSUR methodology to be transparent; this makes the source change explainable instead of mysterious.
- Run a bridging analysis. Compare the final pre-cutover extract against the first post-cutover extract for the same date range. Document the differences in counts and classification.
- Annotate the change in the first post-cutover PSUR. A short paragraph noting the source-system change and its observed effect on counts will pre-empt most reviewer questions.
Step 5: Keep a One-Page Transition Record
Pull the above into a single page in your quality system:
- Current source: AEMS via the openFDA device/event API, weekly refresh
- Monitoring: three FDA pages, monthly, logged
- Change made: documented source name updated to AEMS on [date], SOP appendix revised
- Bridging analysis: pre- versus post-cutover counts, result recorded
- Owner: named individual
That is the whole record. It is deliberately boring, which is what you want from infrastructure changes in a regulated environment.
Where Tooling Fits
If your surveillance runs through a platform rather than manual searches, the reconciliation burden shifts to your vendor — and so do the questions. Ask them three things: what source they query, how they handled the cutover, and what you had to change when it happened.
For DeviceWatch the answers are: the openFDA device/event API; we followed the migration server-side; and nothing. We archive raw API responses, our ingestion layer abstracts the data source from the analysis pipeline, and the switch happened underneath. Your products, review queue, audit trail and reports carried through unchanged.
However you run your program, the principle is the same. The AEMS migration is done, and the FDA will keep refining it. Teams that spend a week now on wording, documentation and a bridging analysis will spend a day on whatever comes next. Teams that ignore it will explain a moved baseline to an auditor with no memo in hand.