Editor's note (August 2026): A previous revision of this guide claimed the device cutover had completed in May 2026. It has not. That claim has been removed and the guide restored to what it is: preparation for a migration the FDA has announced but not yet carried out for devices.
The FDA has undertaken one of the most significant overhauls of its adverse event infrastructure in decades. The Adverse Event Monitoring System (AEMS) is intended to replace 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. Drugs moved first. Devices have not.
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 so far:
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).
Devices: not yet. The FDA has named devices in scope but has published no device migration date, no device data in AEMS and no device API. MAUDE remains the system of record for medical device adverse events.
openFDA remains the API. Device adverse event data 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, and openFDA's documentation still names MAUDE as its source, because that is what it serves.
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. A move to a native AEMS submission format would be separate work from the data migration, and neither has a published device date. 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, nothing has changed yet. The device/event endpoint is live, refreshes weekly and serves device adverse event data. Watch for the returned data model to gain AEMS fields, and for the FDA to document any AEMS-native device 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 eventual move to AEMS means updating the ingestion configuration, not rebuilding the platform.
We pull device adverse event data from the openFDA device/event API, and we run an automated watch on the FDA's data channels — openFDA, the MAUDE bulk files and the AEMS pages — so a device cutover is caught the day it happens rather than the month after.
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 represents the FDA's commitment to modernizing its safety surveillance infrastructure. For manufacturers, the eventual 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 prepare proactively — auditing their data dependencies, building flexible data architectures, and tracking the transition — will fold the change in without disruption. Those that wait until the legacy systems are decommissioned will face a scramble.
The device migration has not happened yet, and the FDA has not said when it will. That is the window. The teams that map their dependencies now will absorb the change quietly; the ones that wait will find out from a broken pipeline.