The FDA says MAUDE data will move into the Adverse Event Monitoring System (AEMS) during 2026. It has not happened yet, no date is set, and there is no public AEMS API. That combination — certain direction, uncertain timing — is exactly when preparation is cheapest.
This checklist is for regulatory affairs and quality teams who want their PMS program to ride through the cutover without a documentation scramble. Everything here can be done in a week, and none of it needs to be redone when the FDA finally announces a date.
If you want the full evidence trail on what AEMS is and is not today, read our companion article on whether MAUDE is going away. Short version: AEMS launched March 11, 2026 with drug data from FAERS and a public dashboard; device data still lives in MAUDE, served weekly through the openFDA device/event API.
Step 1: Write SOP Wording That Survives the Transition
The most common documentation mistake is hardcoding a system name into every procedure step. If your PMS SOP says "search MAUDE" in twelve places, the AEMS cutover means twelve edits, a document revision, retraining records and possibly revalidation.
The fix is 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 the MAUDE database accessed via the openFDA device/event API. The current source system, access method and refresh cadence are maintained in [controlled appendix or work instruction]."
When the FDA cuts over, you update one appendix under document control. 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 That Will Move First
When the device migration is announced, it will show up on FDA pages before it shows up 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 data announcements.
- The MDR Data Files page (fda.gov/medical-devices/medical-device-reporting-mdr-how-report-medical-device-problems/mdr-data-files) — currently states, future tense, that MAUDE data "will become available" in AEMS in 2026. Watch for that sentence to change.
- The openFDA updates page (open.fda.gov/about/updates/) — shows the refresh date and record count for the device/event dataset. Watch for deprecation notices or cadence changes.
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 Decision for Auditors
At some point in the next year, an auditor or notified body reviewer will ask why your surveillance program still references MAUDE when the FDA is moving to AEMS. 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 serves device adverse event data from MAUDE via the openFDA device/event endpoint, refreshed weekly, with no deprecation notice. AEMS currently covers drug data only and exposes no public API.
- 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 triggers. The specific observable events that will start your cutover work: an FDA announcement of device data in AEMS, a deprecation notice on the openFDA endpoint, or a published decommission date for MAUDE.
- Your transition owner. Who watches, who decides, who executes.
This memo converts "we haven't migrated" from an apparent gap into a documented, monitored, deliberate position. 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. If the underlying source changes mid-stream, those comparisons can shift for reasons that have nothing to do with device safety.
The FDA has stated that improved deduplication is a 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 or export files used to build each PSUR, not just the finished report. When the source changes, you can prove what the old 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 future source change explainable instead of mysterious.
- Plan a bridging analysis. When the cutover happens, run one period against both sources if the FDA provides any overlap window, or compare the final MAUDE extract against the first AEMS 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 Plan
Pull the above into a single page in your quality system:
- Current source: MAUDE via openFDA device/event API, weekly refresh
- Monitoring: three FDA pages, monthly, logged
- Triggers: FDA device-data announcement, deprecation notice or decommission date
- Actions on trigger: update controlled data-source appendix, run bridging analysis, annotate next PSUR, verify tooling has switched
- Owner: named individual
That is the whole plan. 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 preparation burden shifts to your vendor — and so do the questions. Ask them three things: what source they query today, how they will detect the cutover, and what their customers must change when it happens.
For DeviceWatch the answers are: the openFDA device/event API; we monitor the FDA's update cadence and documentation continuously; and nothing. We archive raw API responses, our ingestion layer abstracts the data source from the analysis pipeline, and the migration happens server-side. Your products, review queue, audit trail and reports carry through unchanged.
However you run your program, the principle is the same. The AEMS transition is real, it is coming, and the FDA has told us roughly when. Teams that spend a week now on wording, monitoring and archival will spend a day on the actual cutover. Teams that wait will spend a quarter.