For years, FDA accepted postmarketing individual case safety reports in the older E2B(R2) format alongside the newer E2B(R3) standard. That period has ended. Since 1 October 2026, postmarketing ICSRs for human drug products, biological products and drug or biologic-led combination products submitted to FDA through the Electronic Submissions Gateway Next Generation must use the ICH E2B(R3) data standards. E2B(R2) was accepted only up to 30 September 2026.
This guide explains what the requirement covers, what is different about R3 in practice, the transition rule many companies overlooked, and how to check whether your safety reporting is genuinely ready. If you are searching for FDA E2B(R3) requirement for postmarketing ICSRs, E2B(R3) migration support, FDA AEMS ICSR submission, or pharmacovigilance safety database upgrade for E2B(R3), this is written for you.
What FDA Announced
FDA published a Federal Register notice on 6 April 2026 setting out the updated data standard requirement and implementation schedule. The key points are:
- From 1 October 2026, postmarketing ICSRs for human drugs, biologics and drug or biologic-led combination products must be submitted using the data standards in the ICH E2B(R3) Implementation Guidance, which incorporates FDA’s regional implementation guide
- The requirement applies to submissions to the FDA Adverse Event Monitoring System, or AEMS, through ESG NextGen
- The aim is to improve the quality of data in ICSR submissions and support more consistent global exchange of safety information
A small but useful detail: AEMS is the new name for the database that most people still call FAERS. If your SOPs, work instructions and training materials still refer only to FAERS, they are due an update so that a new team member understands the reference.
The Rule That Makes This a Company-Wide Move
The point that causes the most operational difficulty is not the format itself but the transition expectation. FDA’s position is that once a company begins submitting in E2B(R3), all of its ICSR submissions are expected to use that standard. That removes the option of running a slow report-by-report pilot in production. A company either cuts over or it does not, and the cutover affects every product, every reporter type and every attachment in the flow.
This is also why the October date has been treated as a hard stop by experienced safety teams. A company that waited until the last week to begin testing had very little room to correct rejected submissions before the old format stopped being accepted.
Premarketing Reports Are Already on R3
For context, E2B(R3) has been mandatory for IND safety reports submitted electronically to FDA since 1 April 2026. Companies that already moved their IND ICSRs have a working R3 pathway, a tested gateway connection and some practical lessons. Those that left postmarketing and premarketing on separate, unconnected projects have often discovered the two flows depend on shared coding, mapping and reference data.
FDA’s technical guidance also notes a practical point for cases that need to be reported both as a postmarketing report and as an IND report. In those situations, separate ICSRs are submitted, one referencing the application number and one referencing the IND. Teams that treat these as one record can run into rejections or duplicates.
What Is Different About R3 in Practice
E2B(R3) is not simply R2 with a new file extension. The standard is built on HL7 messaging and is more structured, which changes the work in several ways:
- More granular and structured data elements, including richer product, substance and dose information
- Controlled use of null flavours, with FDA’s regional guide rejecting initial submissions that use certain null flavour codes
- Stricter validation, so errors that R2 tolerated may now produce a rejection
- Better handling of attachments, which are sent with the ICSR rather than through a separate process
- Backward and forward compatibility rules that need to be understood when exchanging cases with partners still on R2
- Regional FDA data elements that must be populated correctly
Postmarketing ICSRs are not submitted through the eCTD. They go through the gateway to the safety database at FDA, which is a common source of confusion for regulatory teams used to thinking of every submission as an eCTD sequence.
Where Companies Get Caught Out
Experience from companies that migrated safety databases points to the same pitfalls:
- Safety database vendor upgrades that were installed but not validated end to end against FDA’s own validation rules
- Partner and licensing agreements that did not say who submits what, so a case was reported twice or not at all
- Legacy data with free text or coding that does not map cleanly into structured R3 fields
- Gateway credentials, test and production receiver identifiers and certificates that were not refreshed in time
- Procedures that describe R2 behaviour, such as how to handle follow-ups or nullified cases
- Small companies relying on an outsourced provider without checking whether the provider’s own environment had completed its migration
- Business continuity plans that did not cover what to do if a submission is rejected close to a reporting deadline
How to Check Whether You Are Truly Ready
A short readiness check can be run against the following questions:
- Has every product, reporter type and attachment type been tested end to end in the FDA test environment, not only in the vendor’s sandbox?
- Are rejection and acknowledgement messages monitored daily, with named owners and escalation rules?
- Are your PSMF, SOPs and training records updated to describe the R3 process?
- Do licensing and distribution agreements state who submits ICSRs to FDA for each product?
- Has the migration been documented as a validated change, with risk assessment, test evidence and sign-off?
- Can you demonstrate that reporting timelines were met throughout the cutover period?
For an inspector or auditor, the last question matters most. A migration that is technically successful but leaves a gap in submissions, or a backlog that was cleared late, still produces a compliance issue.
Practical Steps for the Weeks Ahead
- Confirm with your safety database provider the exact version in production and the validation evidence behind it
- Review the first weeks of R3 acknowledgements and rejections for patterns, and fix root causes rather than resubmitting case by case
- Reconcile the number of cases received, processed and submitted across the cutover to prove nothing was lost
- Update SOPs, work instructions, the PSMF and training materials, and record who has been trained
- Audit your partners and service providers to confirm they have also completed their migration
- Keep a record of every decision made during the transition, because it will be asked for in an inspection
Moving to E2B(R3) Without Disrupting Safety Reporting
A migration of this kind sits at the intersection of pharmacovigilance, validation and regulatory operations, which is the territory Quality and Vigilance Ltd works in, alongside its wider remit covering FDA, EMA and MHRA requirements. The cost of a poorly managed migration is not only technical. It shows up as late reports, rejected submissions and findings in the next inspection. The support that makes the biggest difference tends to include:
- Gap assessments of your safety database, gateway set up and procedures against the R3 requirement
- Validation planning and documentation that stands up to inspection
- Post-cutover reviews that reconcile case numbers and confirm that timelines were met
- Reviewing partner and vendor agreements so that submission responsibilities are clear
- Updating SOPs, the PSMF and training records to reflect the new process
Get in touch with Quality and Vigilance Ltd today to confirm your E2B(R3) reporting is compliant, validated and ready for inspection.