FDA Adverse Event Monitoring System (AEMS): Dashboard Use and Pharmacovigilance Practice

The FDA Adverse Event Monitoring System (AEMS) is a modernised FDA platform for handling and analysing adverse-event information across regulated product areas. Its public dashboard gives users easier access to reported events, but the dashboard is not a causality tool, a measure of product safety, or a denominator-based epidemiological database.

For pharmacovigilance professionals, the practical value is earlier access to a broader and frequently refreshed set of reports, plus a clearer public view of potential safety questions. That value depends on disciplined querying, data-quality review and evidence integration. The 2026 transition also has a technical reporting dimension: FDA’s current implementation schedule requires E2B(R3) for certain post-marketing ICSRs submitted through ESG NextGen from 1 October 2026.

This article reflects FDA information available on 3 October 2026. It distinguishes the wider AEMS platform, its public dashboard, the underlying case reports, and FDA’s separately published quarterly list of potential signals.

What AEMS is—and what the public dashboard shows

FDA launched AEMS on 11 March 2026 as a unified adverse-event platform. FDA described the programme as a way to consolidate previously separate systems used across product areas that include drugs, biologics, vaccines, devices, food, cosmetics, tobacco and veterinary products. Its stated design includes standardised reporting, case-processing workflows, analytics and cross-product surveillance. FDA also described AEMS as a future central platform for consumer complaints, regulatory-misconduct reports and whistleblower submissions. These platform goals are broader than the data visible in any one public dashboard. [1, 2]

The drug-and-biologic public dashboard is the user-facing query tool associated with AEMS. FDA identifies it as the former FAERS Public Dashboard and says the underlying FAERS data were moved to AEMS at launch. The public FAQ describes report summaries extending from 1968 to the present, searches by product or reaction, filtering, charts and limited export of query results. FDA’s AEMS pages also retain legacy names and paths in places, so a source document or data file may still say “FAERS” even when it refers to the current AEMS environment. [3, 4]

AEMS therefore has several related but distinct meanings in day-to-day work:

The name change does not create a global pharmacovigilance database. AEMS is an FDA system. It does not contain every adverse event worldwide, every case held by a marketing authorisation holder, or all reports sent to other regulators. A report appearing in a dashboard is a report received by FDA under its applicable pathways; it is not a complete census of what happened to all exposed patients.

A staged transition from legacy systems

At the March 2026 launch, FDA said reports for drugs, biologics, vaccines, cosmetics and animal food could be displayed in one streamlined dashboard. It also described a staged move for other product centres, historical-data migration and additional analytics and APIs. FDA’s current AEMS overview describes the platform as spanning all regulated product categories. For readers, the important point is that product scope, available fields and public visibility should be checked on the relevant current FDA page rather than inferred from the AEMS name alone. [1, 2]

The new environment also changes how users find material. Search engines and older links may still surface a “FAERS Public Dashboard” page, FAERS quarterly data files or a legacy system description. Those labels are not necessarily evidence that the information is outside AEMS. Record the exact FDA page, dashboard or file used and the access date so another reviewer can reproduce the source trail.

Using the public dashboard for a defined question

A useful dashboard query starts with a safety question, not a product name entered without a plan. Define the suspected event, the product or product class, the period of interest, the population or outcome filters needed, and how the result will inform the next step. Examples include checking whether reports for a newly described event are present, reviewing the time pattern of reports, or looking for follow-up information that can help characterise a known signal.

FDA’s FAQ describes a workflow in which the user searches initially by product or by reaction term, then uses other filters in subsequent views. The dashboard can filter or display report patterns by time and other fields; its FAQ describes selecting up to five products or reaction terms at a time, with additional filters such as sex, country and outcomes. It also describes charts and tables that can be exported, with a more limited set of fields than the raw quarterly files. The exact interface may change as the system is updated, so use the live dashboard and current FAQ when conducting a production analysis. [4]

For a repeatable analysis, document:

• the research question and date the query was run;
• the exact generic, brand and product terms selected;
• the reaction terms and any hierarchy or coding choices;
• the reporting period, geography, age, sex and outcome filters;
• whether counts refer to cases, reports, reactions or outcomes;
• the export or screenshot retained, plus the live FDA page and dashboard access date;
• any changes made when a follow-up query was run.

A query record matters because the dashboard data change over time. FDA says the public dashboard is updated daily, or near real time. The FAQ also explains that a case can have successive versions as follow-up information arrives and that the latest version is the most current. Counts can increase or decrease as reports are added, updated, reconciled or removed. A number copied into a slide without its query date and filters is not a stable estimate. [4]

What the data can—and cannot—support

AEMS reports support case finding and signal generation. They do not by themselves show that a product caused the reported event. FDA warns that reports may be incomplete, duplicated, unverified, stimulated by publicity or influenced by the underlying disease and concomitant medicines. Reporting is incomplete: not every event is reported, and reporting rates vary with factors such as time on market and public attention. FDA explicitly states that dashboard data cannot estimate event incidence and should not be used by themselves as an indicator of a drug’s safety profile or to compare one product’s safety with another’s. [3, 4]

Different counts can describe different things. A single case may include several reactions or several outcomes; reaction-level or outcome-level subtotals therefore may equal or exceed the count of distinct cases. A consumer report and a manufacturer report may describe the same case. Follow-up submissions can create new versions of a case. FDA’s FAQ notes these features and warns that the counts shown can change as the database evolves. A safety reviewer should avoid adding reaction or outcome rows and presenting the sum as the number of patients. [4]

Dashboard output and quarterly data extracts may not match exactly. FDA continues to provide quarterly data files alongside dashboard access and notes that the public dashboard may not be identical to the files. The files are raw, linked data extracts; FDA says they require familiarity with relational databases or suitable analytic tools. A dashboard export is more convenient but includes a limited set of fields. The extract selected, database cut, filters and deduplication approach should be preserved when results are used in an assessment. [4, 5]

A death or hospitalisation term is an outcome reported in a case, not an attribution of that outcome to the suspect product. Similarly, a high report count may reflect exposure, duration on market, indication, reporting obligations, media attention, duplicated submissions or data handling—not a higher underlying risk. For these reasons, AEMS counts are unsuitable as incidence numerators without an appropriate denominator and study design. They also do not establish causality through temporal association alone.

AEMS data and FDA’s potential-signal postings

FDA’s quarterly page is distinct from the interactive dashboard. It lists new safety information or potential signals of serious risk that are based wholly or partly on AEMS data, along with the status of FDA’s evaluation or action. FDA says a product’s appearance there means that a potential safety signal is being evaluated; it does not mean FDA has concluded that the product causes the risk or that a regulatory action is warranted. FDA may later determine that no action is needed, require labelling or REMS changes, seek additional data, or take other action. [6]

This distinction helps keep signal terminology precise. A dashboard query is an analyst’s exploration of submitted reports. A potential signal on FDA’s quarterly list is an FDA-published item under a specific statutory process. Neither should be described as a confirmed causal association unless later evidence and FDA’s conclusion support that statement. See Signal Detection, Signal Validation and Data Sources for Signal Management for the broader signal-management process.

Integrating AEMS into pharmacovigilance work

AEMS is most useful when its output is a starting point in a broader evidence review. A practical sequence is:

1. Frame the question. Define the suspected adverse event, relevant product or class, population, period and decision the analysis should support. Separate a hypothesis about a possible product–event association from a question about volume of reports.
2. Run and preserve a reproducible query. Record product and reaction terms, filters, date accessed, dashboard or file version, output type and the exact count field. Save the export or screenshot and retain the raw file only under the organisation’s data-governance controls.
3. Check data quality. Assess duplicates, follow-up versions, product-name mapping, missing exposure and event chronology, reporter type, case completeness and the possibility that reaction or outcome rows exceed unique cases.
4. Review medically informative cases. Where report access permits, assess chronology, seriousness, dechallenge or rechallenge, alternative causes, concomitant medicines, diagnostic evidence, treatment, outcome and follow-up. The dashboard summary alone may not expose enough detail to make a case-level causality judgement.
5. Test the hypothesis against other evidence. Review clinical-trial data, literature, product information, epidemiology, exposure estimates, other regulators’ findings and biological or clinical context. Use AEMS counts to locate patterns or cases; use a suitable epidemiological design and denominator if the question is about rates.
6. Document the conclusion and next step. State whether the output generated an alert, supported validation, informed further assessment or did not change the current view. Explain data limitations and define what additional information would change the conclusion.

A hypothetical example shows the difference between a count and an assessment. A reviewer searches a drug and a reaction over a defined period and sees a recent rise in reports. The rise is an observation worth investigating, not proof that risk has increased. The reviewer checks for a safety communication that may have stimulated reporting, examines report versions and duplicates, compares the pattern with exposure and product-market history, then reviews case narratives and independent sources. If the evidence remains uncertain, the record should say so and specify continued monitoring or the data needed to resolve the question. This is an illustrative workflow, not an FDA case.

If FDA lists a potential signal on its quarterly page, that status should be captured as FDA’s published description and date. Do not upgrade “evaluating the need for regulatory action” into “FDA confirmed a risk.” Conversely, absence from that list does not show that FDA has not reviewed a product or that no safety concern exists; the page is a defined public reporting mechanism, not a complete register of every FDA safety activity. [6]

Electronic submissions: what changed in 2026

AEMS is also the destination for certain electronic safety-report submissions. The dashboard’s public-access changes should be distinguished from the technical standards and legal timelines that govern regulated submissions.

For post-marketing ICSRs for human drugs, biological products and drug- or biologic-led combination products submitted through the FDA Electronic Submissions Gateway Next Generation (ESG NextGen), FDA requires ICH E2B(R3) data standards from 1 October 2026. FDA accepted E2B(R2) through 30 September 2026 for companies that had not yet transitioned; once a company begins submitting in R3, FDA expects all its ICSR submissions to use that standard. FDA states that submitters using the Safety Reporting Portal (SRP) do not need to take action for this ESG NextGen change. This is a defined channel-and-product scope, not a statement that every safety submission to FDA must be made through ESG NextGen. [7, 8]

FDA has accepted post-marketing E2B(R3) submissions since January 2024. For specified commercial IND safety reports, electronic R3 submission to AEMS via database-to-database transmission or SRP has been required since 1 April 2026; FDA identifies non-commercial INDs as exempt from that requirement. Other IND safety information may follow separate eCTD pathways, so sponsors should follow the applicable FDA regulation and technical guidance rather than treating every study finding as an AEMS ICSR. [7, 9]

The FDA AEMS submission page also documents alignment with ICH E2D(R1). It accepts new E2B(R3) C.5.4 study-type values for reports from a patient support programme, market research programme, and an organised data collection system whose source data come from a digital platform. The new values help identify how safety information was obtained; they do not, on their own, decide whether an event is reportable or replace the assessment of solicited versus spontaneous status under applicable requirements. [7, 10]

For PV operations, this means checking data dictionaries, gateway configuration, acknowledgements, business rules, controlled terminology and partner/vendor specifications. Update procedures and validation only where the organisation’s submission pathway or source classification requires it. Preserve evidence that the chosen reporting channel, applicable standard, effective date and follow-up process were understood and tested.

Governance, common errors and inspection evidence

The dashboard is a public source, but decisions made from it remain part of the organisation’s safety governance. A defensible signal record should let a second reviewer reproduce the query, understand why a pattern was investigated, see what evidence was added, and reconstruct the decision and follow-up.

Common errors include:

• treating every row as a distinct patient or counting each reaction as a separate case;
• interpreting a report count as an incidence rate, comparative risk estimate or probability of harm;
• assuming the product caused an event because it appears as a suspect product;
• reading a death, hospitalisation or other serious outcome as proof of product causation;
• comparing products without controlling for exposure, time on market, indication, reporting behaviour and data quality;
• combining the interactive dashboard and quarterly raw files without recording their different data cuts;
• treating FDA’s “potential signal” listing as a confirmed association or final regulatory action;
• failing to preserve the original query, filters, access date, export and review rationale;
• applying the 2026 E2B(R3) requirement beyond its stated ESG NextGen scope, or overlooking it for affected submissions after 1 October 2026.

Operational controls should assign an owner for external-database surveillance, define how findings are triaged, require medical review for clinically important patterns, set escalation criteria for serious or rapidly evolving risks, and link the resulting record to the signal register or assessment. Quality review should verify the query, count definition, duplicate handling, source and date, case version, interpretation and decision. QPPV oversight should focus on whether the PV system identifies relevant findings, escalates them on time and documents actions—not on treating every dashboard fluctuation as a formal signal.

Keep the source of each statement clear in case records and reports. “AEMS dashboard displayed 34 reports under the selected filters on 3 October 2026” is a reproducible observation. “FDA confirmed 34 drug-caused cases” is not supported unless FDA has made that finding. The same distinction applies to published quarterly potential-signal entries and to any internal analysis based on public reports.

Practical checklist

Before using an AEMS result in a signal assessment, confirm:

• What question is the search intended to answer?
• Which FDA dashboard, data extract or quarterly potential-signal page was used?
• What query date, period, product names, reaction terms and filters were applied?
• Does the count represent distinct cases, reports, reactions or outcomes?
• Have duplicate submissions and follow-up versions been considered?
• Could the observed pattern reflect reporting stimulation, exposure, time on market or other data-quality issues?
• Have clinically informative cases and alternative explanations been reviewed?
• What external evidence, denominator or study design is needed before drawing a broader conclusion?
• Is FDA’s potential-signal status being reported using FDA’s wording and date?
• Are the applicable electronic submission channel and E2B standard clear for affected company reports?
• Can another reviewer reproduce the query and follow the evidence to the documented decision?

The checklist is recommended operational practice. It does not replace FDA’s reporting regulations, technical instructions or current guidance.

Key takeaways

• AEMS is FDA’s broader adverse-event platform; the public dashboard is one access point into selected data.
• The dashboard can help identify and characterise a possible signal, but a report does not establish causality, and counts cannot establish incidence or comparative safety.
• Daily updates, case versions, duplicate submissions and multiple reactions or outcomes mean counts are dynamic and must be interpreted with the exact query context.
• FDA’s quarterly potential-signal page is a separate, defined publication process; a listed product is under evaluation, not necessarily confirmed to have the risk.
• From 1 October 2026, E2B(R3) is required for the specified post-marketing ICSR submissions sent through ESG NextGen. The requirement has a stated scope and should not be generalised to every FDA safety-report pathway.
• Good practice preserves the query, source, filters, data cut, interpretation, evidence integration and decision trail.

References

1. US Food and Drug Administration. FDA Launches New Adverse Event Look-Up Tool. 11 March 2026. FDA news release.
2. US Food and Drug Administration. FDA Adverse Event Monitoring System (AEMS). Current AEMS overview.
3. US Food and Drug Administration. FDA Adverse Event Monitoring System (AEMS) Public Dashboard. Dashboard page and limitations.
4. US Food and Drug Administration. AEMS Public Dashboard Frequently Asked Questions. FDA FAQ.
5. US Food and Drug Administration. AEMS Latest Quarterly Data Files. Data-file page.
6. US Food and Drug Administration. New Safety Information or Potential Signals of Serious Risks Identified from AEMS. Quarterly potential-signal process and current postings.
7. US Food and Drug Administration. AEMS Electronic Submissions. Submission standards and timelines.
8. US Food and Drug Administration. Electronic Submission of Postmarketing Individual Case Safety Reports to AEMS Using ICH E2B(R3) Data Standards; Regional Data Elements and Implementation Schedule. 6 April 2026. Federal Register, 91 FR 17284.
9. US Food and Drug Administration. IND Application Reporting: IND Safety Reports. Electronic submission requirements.
10. US Food and Drug Administration. E2D(R1) Postapproval Safety Data: Definitions and Standards for Management and Reporting of Individual Case Safety Reports. Final guidance.

Regulatory Note

This article summarises FDA materials available on 3 October 2026. It is an educational pharmacovigilance resource, not a substitute for current FDA instructions, applicable regulations or technical conformance guidance. Dashboard features, data fields, submission standards and rollout status can change. Confirm the live FDA source and the reporting pathway that applies to the specific product, report type and submitter.