Editor's note (July 2026): This guide was written before the cutover. The FDA has since completed it. Device adverse event data migrated to AEMS in May 2026, and AEMS now holds new device reports plus the full MAUDE archive. Read the sections below as the record of what the transition involved, with the timeline and data-access notes updated to the completed state. DeviceWatch made the switch server-side, so its customers changed nothing.
The FDA undertook one of the most significant overhauls of its adverse event infrastructure in decades. The Adverse Event Monitoring System (AEMS) replaces the patchwork of legacy databases — including MAUDE, MedWatch, and FAERS — with a single, unified platform for all adverse event reporting across drugs, biologics, and devices.
For medical device companies that have built their post-market surveillance programs around the MAUDE database and the openFDA API, this migration has practical implications. Your data sources, report formats, and potentially your submission workflows will change. Here is what we know, what is changing, and how to prepare.
What Is AEMS?
AEMS — the Adverse Event Monitoring System — is the FDA's next-generation platform for receiving, processing, and analyzing adverse event reports across all FDA-regulated product categories. It is designed to replace multiple legacy systems that were developed independently over the past three decades and have been showing their age.
The current landscape of FDA adverse event systems includes:
- MAUDE (Manufacturer and User Facility Device Experience) for medical device reports
- FAERS (FDA Adverse Event Reporting System) for drugs and biologics
- MedWatch for voluntary safety reports
- CVM ADE for veterinary products
- Various internal systems for processing, deduplication, and analysis
Each of these systems has its own data model, submission format, and access interface. AEMS consolidates them into a single platform with a unified data model, modern architecture, and improved analytical capabilities.
Timeline: What Happened When
Here is the sequence the FDA followed:
March 11, 2026: AEMS launched. The initial release migrated drug adverse event data from FAERS and provided a public dashboard, built on Qlik Sense, for exploring it (fda.gov/safety/fda-adverse-event-monitoring-system-aems).
May 2026: device data migrated. The FDA completed the device side of the migration. New medical device reports now flow into AEMS, and the full historical MAUDE archive moved with them. MAUDE was retired as a standalone system.
openFDA remains the API. Device adverse event data still flows through the openFDA device/event endpoint on a weekly refresh (open.fda.gov/apis/device/event/). There is no separate public AEMS API for device data. openFDA is the delivery layer, AEMS is the system of record behind it, so surveillance pipelines that already pull from openFDA kept working through the cutover.
What Changes for Manufacturers
Submission Format Changes
The most visible eventual change is how adverse event reports are submitted. AEMS is expected to adopt the HL7 FHIR (Fast Healthcare Interoperability Resources) standard for data exchange, eventually replacing the legacy eMDR (electronic Medical Device Reporting) format that device manufacturers currently use. The FDA has not yet published device submission specifications for AEMS.
For companies that submit MDRs through the FDA's eSubmitter software or through third-party submission platforms, the submission tool will be updated to generate FHIR-compliant reports. For companies that have built custom submission integrations, there will be development work required to map existing data fields to the FHIR format.
The good news is that eMDR submissions continue to be accepted, and the FDA has not signaled a change to the submission format. The data migration completed in May 2026, but the move to a native AEMS submission format is separate follow-on work. New capabilities — such as enhanced reporting fields and real-time submission status tracking — would presumably arrive with that format, but the FDA has not published details.
Data Access and API Changes
For surveillance teams that pull from the openFDA API, the transition was close to invisible. The device/event endpoint stayed live through the cutover, still refreshes weekly and still serves device adverse event data. Watch for the returned data model to gain AEMS fields over time, and for the FDA to document any AEMS-native endpoints it adds. Neither breaks an existing openFDA pipeline today.
Key changes to watch for:
New data fields. AEMS is expected to introduce additional structured fields that were not present in MAUDE, including more granular device identification data built on the UDI system, improved patient demographic fields, and structured causal assessment fields. These new fields would enrich the data available for surveillance analysis.
Improved deduplication. One of AEMS's stated goals is better deduplication of reports. The MAUDE database is notorious for containing duplicate reports for the same event (when both a manufacturer and a user facility report it). AEMS's unified data model is designed to link related reports and reduce duplicate counting.
Changed field mappings. Some existing MAUDE fields may map differently in the AEMS data model. Product codes, event types, and manufacturer identifiers may use different coding systems or field names. Surveillance systems that parse these fields will need to be updated.
Real-time or near-real-time availability. An FDA press release from August 2025 described the agency's goal of moving toward real-time adverse event data, and reducing data lag is a stated aim of AEMS. Currently, reports can take 4-8 weeks to appear in the public database. AEMS is designed for faster processing, though the FDA has not committed to a specific latency target for public data availability.
Reporting Obligations Unchanged
It is important to emphasize that AEMS changes the infrastructure, not the regulatory requirements. The mandatory reporting obligations under 21 CFR Part 803 remain the same: manufacturers must still report deaths and serious injuries within 30 days (or 5 days for events requiring remedial action), user facilities must still report deaths within 10 working days, and the same definitions of reportable events apply.
The content requirements for MDR reports are also substantively unchanged. What changes is the format and the system through which reports are submitted and made available.
How to Prepare Your Surveillance Systems
For companies that rely on automated surveillance systems — or are planning to implement one — here are the practical preparation steps:
Audit Your Current Data Dependencies
Document every place in your organization that consumes MAUDE data or submits MDR reports. This includes:
- Your post-market surveillance system or platform
- Any custom scripts or queries that pull from the openFDA API
- MDR submission workflows (eSubmitter, third-party platforms, or custom integrations)
- Reporting dashboards that display MAUDE-derived metrics
- PSUR and other regulatory reports that cite MAUDE data
Each of these touchpoints may need updates when the AEMS migration occurs for medical devices.
Monitor FDA Communications
The FDA is providing advance notice of API changes, new data field definitions, and migration timelines through multiple channels. Subscribe to the FDA's Device Safety page for official communications, monitor the openFDA GitHub repository for technical updates, and attend relevant FDA webinars on the AEMS transition.
Design for Data Model Flexibility
If you are building or selecting a surveillance platform, prioritize systems that abstract the data source layer from the analysis layer. A well-architected system should be able to adapt to changes in the underlying data format without requiring a complete rebuild of the analytical and reporting components.
This means avoiding hard-coded field mappings in favor of configurable data transformations. It means storing raw source data alongside processed data so that reprocessing is possible when field mappings change. And it means having a team or vendor that can respond quickly to API changes.
Plan for the Parallel Period
During the transition, data may be available in both MAUDE and AEMS simultaneously, potentially with differences in completeness, formatting, or deduplication status. Your surveillance process should account for this:
- Decide whether you will query both sources during the parallel period or transition to AEMS immediately
- Plan for potential differences in data completeness between the two systems
- Test your surveillance queries against AEMS endpoints as soon as they become available for device data
Update Your PMS Plan Documentation
Your post-market surveillance plan should reference the specific data sources you use for surveillance. When AEMS replaces MAUDE as your primary data source, update the PMS plan accordingly. This documentation change may seem minor, but it matters for notified body audits and FDA inspections — your documented PMS process should match your actual process.
What This Means for Data Quality
Beyond the logistical changes, AEMS represents a potential improvement in the quality of adverse event data available for post-market surveillance:
Better structured data through the FHIR standard means more information captured in queryable fields rather than buried in narrative text. This makes automated analysis more effective.
Improved UDI integration means more precise device identification. Rather than relying on product codes and brand names (which can be inconsistent), UDI-based identification links adverse events to specific device versions and models.
Cross-product analysis becomes possible when drug, biologic, and device adverse events live in the same system. For combination products or devices used in conjunction with specific drug therapies, this unified view could reveal interaction effects that siloed databases would miss.
Reduced duplicates mean more accurate trending and signal detection. If AEMS delivers on its deduplication goals, surveillance teams will be able to trust report counts more than they can with MAUDE's current data.
DeviceWatch and AEMS
DeviceWatch's architecture was designed with data source migration in mind. Our ingestion layer abstracts the data source from the analysis pipeline, so following the FDA's move to AEMS meant updating the ingestion configuration, not rebuilding the platform.
We continue to pull device adverse event data from the openFDA device/event API, which serves AEMS data as its delivery layer, and we monitor FDA communications for the AEMS-native device endpoints and submission specifications still to come. Our customers received their weekly adverse event digests and AI-powered summaries without interruption through the transition.
As AEMS introduces new structured fields — particularly enhanced UDI data and structured causal assessments — they will feed directly into our analysis pipeline, improving the precision of our AI-generated summaries and severity classifications.
The Bigger Picture
AEMS is more than a database migration — it represents the FDA's commitment to modernizing its safety surveillance infrastructure. For manufacturers, the short-term work of adapting to new data formats and submission workflows is real, but the long-term benefits of better data quality, faster processing, and unified adverse event analysis are substantial.
The companies that prepared proactively — auditing their data dependencies, building flexible data architectures, and tracking the transition — folded the change in without disruption. Those that waited until the legacy systems were decommissioned faced a scramble.
The device migration is done. The follow-on work will land over the coming months: AEMS-native submission specifications, new structured fields, API refinements. The teams that mapped their dependencies early will absorb those changes the same way — quietly.