Medical device companies often treat regulatory change as document maintenance. A database is renamed, so someone edits an SOP. A new submission template appears, so the team downloads it. An FDA system changes, so IT updates a connection. Each step may be correct on its own, and the organization can still end up unprepared.

That gap is especially dangerous in 2026, because the changes are not isolated. Within four months, the FDA has reset the infrastructure under quality management, post-market surveillance, electronic reporting, and premarket submissions:

• The Quality Management System Regulation (QMSR) became effective February 2, 2026, replacing the former Quality System Regulation and aligning the FDA's framework more closely with ISO 13485:2016.
• FDA launched the Adverse Event Monitoring System (AEMS) on March 11, 2026, consolidating a patchwork of legacy adverse-event databases into a single platform.
• The FDA released eSTAR version 7.0 and PreSTAR version 3.0 on June 1, 2026, incorporating new human factors content and expanding the Q-Submission types PreSTAR supports.

The organizations that navigate this well will not be the ones that update the most SOPs. They will be the ones who understand where regulatory requirements intersect with data, software, workflows, vendors, and human decision-making.

AEMS is more than a new name for MAUDE

FDA built AEMS to unify adverse-event reporting across regulated product categories, with real-time publication, standardized workflows, and improved analytics. MAUDE - the device community's primary public database since the 1990s - is one of the legacy systems being absorbed, with device data migrating into AEMS during 2026.

The temptation is a global "MAUDE-to-AEMS" find-and-replace. Resist it. FDA's transition is staged, and legacy and new access methods may coexist during migration. For any organization that relies on MAUDE in post-market surveillance, clinical evaluation reports, risk management, complaint trending, or regulatory intelligence, that distinction is operational: removing MAUDE from procedures before validating AEMS coverage can create a data gap, and continuing to rely solely on MAUDE after cutover can eventually create a different one.

The correct response is a controlled migration - documented source validation, parallel testing, reconciliation, and an approved cutover decision.

Real-time publication changes the tempo of the evidence, not its quality

AEMS is designed to surface adverse-event information faster. That can strengthen signal detection, but it can also create pressure to react to incomplete or duplicative data. FDA itself cautions that the system may contain duplicate and incomplete reports, and that the presence of a report does not establish that a product caused an event.

Real-time access does not mean real-time truth. It means teams may see emerging information sooner - and that signal-management procedures still need defensible criteria for distinguishing a new signal from a known risk, a duplicate, a reporting artifact, or an event requiring investigation. Review the cadence and triage logic of your surveillance, not just its source.

The legal obligations remain; the technical failure modes are changing

AEMS does not alter the underlying requirements of 21 CFR Part 803. Manufacturers remain subject to the same 30-calendar-day reporting obligations and to 5-work-day reporting in the circumstances specified by the regulation. The reportability criteria, timelines, and forms are unchanged.

That does not mean electronic-reporting systems can be left untouched. As part of the AEMS consolidation, the FDA announced changes to the codes used in electronic MDR submissions on May 11, 2026. AS2 and API submitters are directed to confirm compliance with the August 2024 XML specification; the system is expected to stop accepting certain two-letter country codes in favor of three-letter codes and to make minor changes to acknowledgment error messages. The reporting criteria may be unchanged, but a technically invalid report is still an operational failure - and the time to find that out is in a test environment, not during a reportable event.

Verify before you file: confirm the current eMDR production-deployment date and the exact country/event code changes on FDA's eMDR System Enhancements page before your next submission cycle.

eSTAR 7.0 requires version control, not panic

The June 1 update introduced eSTAR 7.0 (IVD and non-IVD) and PreSTAR 3.0. PreSTAR now supports additional Q-Submission types, including Submission Issue Requests, Informational Meetings, Study Risk Determinations, PMA Day 100 Meetings, and Accessory Classification Requests. The previous eSTAR 6.2 and PreSTAR 2.2 are scheduled for retirement on August 3, 2026.

The right action depends on submission status. For new, unsubmitted work, begin with the current template wherever practical. For work already substantially developed in an earlier template, run a documented impact assessment rather than assume that migration - or non-migration - is automatically correct. FDA has indicated that earlier versions may be used until their retirement date and are not automatically rejected, though using one may prompt additional information requests. Once the FDA issues an acknowledgment letter, the submission is generally grandfathered to that eSTAR version, and responses to Additional Information or Technical Screening requests should continue in the original template.

"Always use the latest template" is not a sufficient procedure. Submission status, acknowledgment status, retirement dates, and the applicability of new content all have to be weighed.

Human factors content cannot be left until publishing

Version 7.0 incorporates the FDA's final guidance, Content of Human Factors Information in Medical Device Marketing Submissions, published on May 29, 2026, and effective as of August 1, 2026. The guidance establishes a risk-based framework for presenting human factors information in 510(k), De Novo, PMA, and HDE submissions. FDA recognizes a transition period and generally does not expect submissions received before August 1, 2026, to include all newly recommended information, though it will review the information when provided.

Do not read that transition window as permission to wait. Human factors documentation is produced by design and development activities that often begin months or years before a submission is assembled - the use-related risk analysis, identification of critical tasks, validation methodology, residual-risk discussion, labeling, and training records. Discovering those gaps during final eSTAR assembly is too late.

Core action items to put in place now

1. Open a formal regulatory change control. Assign a cross-functional owner and document the impact across regulatory, quality, clinical, safety, medical writing, software, IT, and vendors. The record should identify affected procedures, tools, submissions, products, deadlines, owners, and the evidence required to close each item. A thread of emails is not a change-control strategy.
2. Run MAUDE and AEMS in parallel before cutover. For a defined validation period, execute equivalent searches in both environments. Compare date coverage, record counts, product identifiers, event classifications, narrative availability, duplicate behavior, and export functionality. Document discrepancies and define when MAUDE remains an approved fallback.
3. Revalidate every automated surveillance dependency. Inventory scripts, APIs, scheduled downloads, dashboards, vendor feeds, literature-surveillance platforms, saved searches, product-code dictionaries, and deduplication logic. Test that each still returns complete, reproducible results, and preserve raw exports, query parameters, execution dates, and reconciliation results so the validation can be reconstructed during an inspection.
4. Update procedures with transition logic, not just new terminology. Post-market surveillance and CER procedures should name AEMS as the target-state source while acknowledging any validated continued use of MAUDE. Search records should capture source, access date, criteria, coverage period, known limitations, and any fallback method.
5. Complete eMDR testing before the production-deployment cutover. AS2 and API submitters should confirm compliance with the August 2024 XML specification, replace unsupported country codes, verify acknowledgment handling, and run representative submissions - including negative cases - in FDA's test environment, so the team knows how a rejected report appears and how to correct it within applicable timelines.
6. Establish submission-level eSTAR version control. Maintain an inventory showing template version, submission type, planned filing date, retirement date, acknowledgment status, and migration decision for every active submission. Use 7.0 / PreSTAR 3.0 for new work unless a documented rationale supports otherwise, and do not migrate an acknowledged submission into a newer template when FDA instructs continued use of the original.
7. Perform a human factors content gap assessment before August 1. Compare each affected submission against the new guidance and eSTAR structure. Confirm the human factors narrative is consistent with the risk-management file, design history, validation evidence, labeling, intended users, use environments, and critical tasks. The content should tell one coherent story across the submission, not sit as an isolated report bolted on at the end.
8. Retain evidence that the changes worked. Under QMSR, the organization must be able to demonstrate more than document approval. Retain validation protocols and reports, updated procedures, training records, test evidence, discrepancy assessments, risk decisions, and vendor confirmations. The inspection question is unlikely to be "Did you change the word MAUDE to AEMS?" It is far more likely to be "How did you determine that your surveillance and reporting processes continued to work?"

Regulatory intelligence must end in controlled action

Compliance in 2026 increasingly depends on versioned templates, structured data, machine-readable submissions, and interoperable systems that change quickly. Static checklists and periodic SOP reviews are no longer enough. Regulatory intelligence must connect each authoritative change to the procedures, systems, submissions, products, and people it affects - naming an accountable owner, setting a deadline, preserving the rationale, and verifying that the change was effective.

At Ailethea, our position is straightforward: an alert is not regulatory intelligence until it produces traceable action. FDA's infrastructure may be changing quickly, but the standard for industry remains familiar - know what changed, determine what it affects, control the implementation, and retain the evidence. The companies that do that well in 2026 will not merely stay compliant. They will make faster, more defensible regulatory decisions while their competitors are still editing acronyms.

Ailethea builds the infrastructure for that discipline. TRIAD-AI, the intelligence layer beneath every product and one that can be embedded directly into portfolio company systems, links each authoritative change to the procedures, submissions, and people it affects. Veros, our quality management system, stores the procedures, training records, and approvals that QMSR expects an organization to produce. Apex manages regulatory submissions and their version control across eSTAR, PreSTAR, and the expanding set of Q-Submission types. Ada automates GxP validation, reducing a process that typically takes more than four months to under four hours, so revalidation keeps pace with the FDA's release cadence rather than lagging behind. Nexus coordinates risk management across products and tenants in Life Sciences and Health Care. The point is not the tooling; it is that intelligence, action, and evidence stay connected from the first alert to the inspection.

This content is intended for general informational purposes and does not constitute legal or regulatory advice.