Correction (August 2026): An earlier version of this article was written as a post-cutover checklist and said device data moved to AEMS in May 2026. That was wrong. The migration has not happened. The checklist below is the same work, reframed as preparation, and the correction is left visible rather than quietly edited out.
The FDA has said it will consolidate device adverse event reporting into the Adverse Event Monitoring System (AEMS). It has not done so yet. MAUDE is still the source of record and there is no device API.
That gap is an opportunity. Everything here can be done in a week, and doing it before the cutover is the difference between a day of work later and a month of it.
If you want the full picture of what has and has not moved, read our companion article on whether MAUDE is going away. Short version: AEMS launched March 11, 2026 as the successor to FAERS on the drug side, devices have not migrated, and the openFDA device/event API still serves MAUDE data weekly.
Step 1: Fix SOP Wording So the Cutover Is Painless
The most common documentation mistake is hardcoding a system name into every procedure step. If your PMS SOP says "search MAUDE" in twelve places, a cutover means twelve edits, a document revision, retraining records and possibly revalidation.
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 MAUDE accessed via the openFDA device/event API. The current source system, access method and refresh cadence are maintained in [controlled appendix or work instruction]."
Name MAUDE in that appendix today, because that is what is true today. When the FDA moves devices to AEMS, 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: Monitor the Three FDA Pages
The device cutover will show up on FDA pages before it shows up anywhere else. Three pages cover it:
- The AEMS page (fda.gov/drugs/surveillance-post-drug-approval-activities/fda-adverse-event-monitoring-system-aems) — the FDA's official description of the system. Watch for device-specific documentation, a device dashboard, or an API announcement.
- The MDR Data Files page (fda.gov/medical-devices/medical-device-reporting-mdr-how-report-medical-device-problems/mdr-data-files) — where device bulk files live. Watch for the files to move, change format, or gain an AEMS label.
- 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.
Step 3: Write the Rationale Memo Now
At some point an auditor or notified body reviewer will ask how your surveillance program is handling the AEMS transition. The answer 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 has announced AEMS and named devices in scope. Device data has not migrated. Device adverse event data, including the full historical 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.
- Your transition plan. The SOP appendix that will change, who watches, who decides, who executes.
Date it, and update it when the facts change. That converts a pending source-system change from an apparent gap into a documented, deliberate position.
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.
Note that device publishing already paused twice in 2026, so some baselines have a gap in them regardless of AEMS. 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 a source change explainable instead of mysterious.
- Plan the bridging analysis. When the cutover comes, compare the final pre-cutover extract against the first post-cutover extract for the same date range, and document the differences in counts and classification.
- Annotate any publishing gaps. The 2026 pauses are already in your baselines. A short note in the methodology section pre-empts most reviewer questions.
Step 5: Keep a One-Page Transition Record
Pull the above into a single page in your quality system:
- Current source: MAUDE via the openFDA device/event API, weekly refresh
- Monitoring: three FDA pages, monthly, logged
- Pending change: FDA AEMS device migration, announced, not scheduled
- Bridging analysis: planned, to run at cutover
- 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 will handle the cutover, and what you will have to change when it happens.
For DeviceWatch the answers are: the openFDA device/event API; we monitor the FDA's data channels and will follow the migration server-side; and nothing. We archive raw API responses, and our ingestion layer abstracts the data source from the analysis pipeline.
However you run your program, the principle is the same. Teams that spend a week now on wording, documentation and monitoring will spend a day on the cutover. Teams that ignore it will explain a moved baseline to an auditor with no memo in hand.