E2B R3

Skip key takeaways

Updated October 20, 2026

• Treat R3 as a new message format E2B(R3) replaces the R2 DTD with XML schemas, renumbers the elements, assesses seriousness per event and embeds attachments, so generating R3 from the safety database is safer than converting R2 output, which ICH warns can transform or lose information.
• One message carries one ICSR A batch wraps one or more messages, each message carries exactly one case and nullFlavor codes state why a mandatory element is empty. The generator applies null rules per element and numbers each batch uniquely at the sender.
• Validate against the receiver's rule set FDA and EMA publish their own business rules on top of the ICH guide and set their own terminology requirements, drawing on NCI EVS terms at FDA and EDQM Standard Terms for dose forms and routes in the EU, so validation runs the rule set of the receiver a message is addressed to.
• A delivery receipt is not acceptance We recommend correlation, a timer and an alert for every submission. In FDA's regional guide the first acknowledgment gives an official receipt date without implying acceptance, and ESG NextGen generates no acknowledgment for invalid file extensions or badly encoded files.
• Keep generation, validation and transport separate The safety database owns the case, a generation layer builds the message, a validation layer mirrors the receivers' rules and a transport adapter owns the gateway account, so a credential rotation touches only the transport adapter and a new regional guide revision stays within generation and validation.

Copy takeaways

In short: E2B R3, formally ICH E2B(R3), is the specification for sending individual case safety reports (ICSRs) from one safety database to another as XML messages built on the ISO/HL7 27953-2 ICSR standard and HL7 version 3 messaging. For an engineering team it breaks into three jobs: generating a valid message for each receiver, validating it against ICH and regional business rules and moving it through a regulator's gateway while reconciling the acknowledgments that come back. FDA and EMA each add their own business rules, terminology requirements and test procedures to the shared ICH guide.

This page covers the message and its path to a receiver, written for engineers who build or integrate ICSR pipelines as part of pharma software development around an existing safety database. Case processing and medical review stay with the safety team.

What Is E2B R3?

The R3 revision replaced E2B(R2). Its implementation guide, titled E2B(R3) Electronic Transmission of Individual Case Safety Reports (ICSRs) Implementation Guide, Data Elements and Message Specification, defines the data elements of a case and the message that carries them. The guide argues from scale. A worldwide exchange has many potential participants, so it needs one standard format that supports direct database-to-database transmission, whether between regulators, between companies and regulators or between pharmaceutical companies.

ICH keeps its own E2B(R3) page, and FDA hosts a copy of the implementation guide as FDA guidance, the version cited throughout this page.

Under the guideline sits an ISO standard. ICH's proposal to ISO became ISO project 27953, endorsed as a Joint Initiative project in February 2008 and published as an International Standard in November 2011. The ICH guide names it ISO/HL7 27953-2:2011, Health informatics, Individual case safety reports (ICSRs) in pharmacovigilance, Part 2: Human pharmaceutical reporting requirements for ICSR. The message layer comes from HL7 version 3, which is why the wrappers carry HL7 V3 interaction names and the reason a required value is missing is expressed with an HL7 nullFlavor code.

Difference Between E2B R2 and R3

R3 is a new message format rather than an extended R2 file. The ICH implementation guide calls the SGML-based DTD approach behind the earlier format no longer the optimal solution and states the consequence: "As a result, the current messaging standard herein now relies upon XML schemas."

FDA's Federal Register notice on postmarketing ICSRs summarizes the practical differences, and the ICH compatibility appendix adds the numbering change.

• Schema technology moves from DTD version 2.1, on which, the appendix says, pharmacovigilance databases were largely operating, to XML schemas.
• Data elements are new, changed or expanded, so an R2 export cannot simply be relabeled as R3.
• Seriousness is assessed per event instead of per case.
• Attachments are embedded in the ICSR rather than provided separately.
• Numbering changes throughout. R2 numbers the patient name or initials B.1.1 where R3 calls the item D.1, and R3 groups the message into N for the batch and message wrappers and C to H for the case.

ICH's agreed recommendations for converting ICSRs and acknowledgments between R2 and R3 are in Appendix I (B), published as a reference for system providers. The appendix states the limits: "Repeated conversion could result in transformation or loss of information." It tells receivers to evaluate converted content carefully and recommends a case narrative with no size limit, so the narrative placeholder can hold fields that cannot be converted directly.

Our recommendation for a mixed estate is to convert once at the boundary, keep the original message and avoid round-tripping a case between versions, since ICH warns that repeated conversion can transform or lose information. For a safety database whose exports still produce R2, the move is a mapping and legacy modernization project: we give every field an R3 target or a documented place in the case narrative, a nullFlavor policy and tests against the new business rules.

E2B R3 Format: Batch, Message and Case Sections

An E2B(R3) file nests three levels, and the ICH guide fixes the cardinality at each one. A batch can hold one or more ICSRs, while the message level is strict: "One ICH ICSR message contains one and only one ICSR."

The batch wrapper, N.1, identifies the transmission. N.1.1 states the type of messages in the batch as a coded value, listed in the ICH guide as 1=ichicsr, and its business rule says the value allowed is case sensitive, with lowercase characters only. N.1.2 is the batch number, which the sender assigns uniquely to each outbound batch file, and N.1.4 names the batch receiver. Each message has its own header, N.2.r, with a message identifier (N.2.r.1) and a message receiver identifier (N.2.r.3).

In HL7 V3 terms, the batch is the interaction MCCI_IN200100UV01 and each ICSR message is PORR_IN049016UV, while acknowledgments use MCCI_IN200101UV01 for the batch and MCCI_IN000002UV01 for each message. ICH's schema carries initial, follow-up and nullification reports as individual messages in one batch, where HL7 provides separate schemas for each report.

The case runs from section C to section H.

• C identifies the case safety report (C.1), including included documents (C.1.6.1.r.2) and local criteria for expedited reporting (C.1.7), then the primary sources (C.2.r), the sender (C.3), literature references (C.4.r) and study identification (C.5).
• D holds the patient characteristics that R2 kept in section B.1.
• E.i records reactions and events with their MedDRA codes (E.i.2.1b) and seriousness criteria at event level (E.i.3.2).
• F.r carries results of tests and procedures.
• G.k describes the drugs, down to relatedness assessment (G.k.9.i.2.r).
• H is the narrative section.

Missing values and attachments

Mandatory elements do not always have data, and R3 lets the sender state why instead of leaving them blank. HL7 nullFlavor codes, as FDA's regional implementation guide (August 2024) describes them, explain why data is missing on a required element, and the ICH guide uses them to keep a message valid when a mandatory element carries no content. The ICH nullFlavor table uses NI, MSK, UNK, NA, ASKU, NASK, NINF and PINF. A generator needs a per-element allow list rather than one global default, because each data element lists the codes it accepts: the reporter's title allows MSK, ASKU, NASK and UNK.

Attachments travel inside the message. The ICH guide allows them in-line in the ICSR, does not permit a reference to a document URL and leaves the allowed values to each region. FDA's regional guide asks for base64-encoded inline files that are not individually compressed and recommends keeping an ICSR submission under 100 MB.

E2B R3 Business Rules

A file that passes schema validation can still fail at the receiver. The ICH guide treats its harmonized messaging rules as the validation conditions receivers apply to inbound ICSR messages, and its business rules add detail for individual data elements, such as the N.1.1 case-sensitivity rule.

FDA and EMA each add their own rule set. FDA links the FDA E2B(R3) Core and Regional Data Elements and Business Rules spreadsheet from its E2B(R3) standards page, and the regional guide states that FAERS file validation is consistent with that document. In the EU, section I.C.4 of the EU ICSR Implementation Guide tabulates the business rules for all submissions to EudraVigilance, including every rule that generates an error message.

The rule sets behave like dependencies. Implement each rule as a named, versioned check tied to the document revision it comes from, select the ICH, FDA or EU set by the message receiver and treat a new rules document as a release with its own regression run. A rule that fires at the receiver but not in your own pipeline is a defect in the pipeline.

Acknowledgments: What Comes Back After a Submission

In the ICH model, the receiver acknowledges every ICSR transmission from a known trading partner, and a partner it does not know or has not authorized gets no acknowledgment. One acknowledgment responds to a whole batch and still reports on each message. Batch-level results are carried in elements such as the transmission acknowledgment code (ACK.A.4), while elements beginning with ACK.B carry the result for each ICSR message, as section 4 of the ICH guide describes.

The EU ICSR Implementation Guide spells out the batch-level values EudraVigilance returns. AA means the batch was processed with no further action needed. With AE, errors were found and some ICSRs need action. AR signals a parsing error that left no data extracted, so the whole transmission must be re-sent. Per report, the ICH compatibility appendix gives CA (commit accept) and CR (commit reject) for ACK.B.r.6. These values are documented for the ICH and EU flows, so an FDA integration should check FDA's own documentation before relying on them.

FDA describes acknowledgments in two documents from two generations of its gateway. The regional implementation guide (August 2024), written around the earlier ESG, describes two FAERS acknowledgments and says of the first: "It also provides the official FDA receipt date but does not imply FDA acceptance of the submission."

The ESG NextGen page on submission acknowledgments defines ACK1 as information on whether the submission was uploaded into ESG NextGen, ACK2 as information on whether it reached the FDA center and ACK3 and ACK4, where applicable, as the center's response. AS2 submissions receive acknowledgments over AS2, and portal or API submissions by email and in the portal's submission history. The page lists which acknowledgments each submission type receives and, in the notes to its submission-type table, including the AERS rows, states: "ACKs are not generated for invalid file extensions nor for files which are not encoded properly." We recommend covering that case in submission monitoring.

Our recommendation is to treat a gateway receipt as proof of delivery rather than acceptance, record the official receipt date the first acknowledgment carries and mark a case as accepted only on the receiver's own response. We also recommend correlating every acknowledgment to the batch number and message identifiers it answers and giving every submission a timer, because a file the gateway cannot read may produce no acknowledgment at all. These are design choices; no FDA or EMA document cited here sets them. The table below is Pharos Production's engineering model of the states one submission passes through, not a state machine any regulator prescribes.

State	Entered when	What to record	Next action
Generated	A batch is built for one receiver profile	Batch number (N.1.2), message identifiers (N.2.r.1) and the receiver profile	Run the validation layers
Validated	The batch passes every validation layer	The rule set revisions it was checked against	Hand the file to the transport adapter
Sent	The adapter hands the file to ESG NextGen or the EudraVigilance Gateway	Channel and send time	Start the acknowledgment timer
Delivered	A gateway or delivery acknowledgment arrives	Any official receipt date it carries	Wait for the receiver's response, since delivery is not acceptance
Accepted or rejected	The receiver's own response arrives: in the EU, a batch code AA, AE or AR and a per-message CA or CR, as the ICH and EU documents describe; at FDA, the center's response where applicable	The batch result and the result for each message	None for accepted messages; investigate each rejection
No response	The timer expires without the expected acknowledgment	Expiry time	Raise an alert, because ESG NextGen generates no acknowledgment for invalid file extensions or badly encoded files

Gateway or Safety Database: Which Component Does What

The regulators' documents separate the two jobs. FDA's testing guide has the XML generated from the safety database and checked with FDA's validator, while opening a portal, AS2 or API account with ESG NextGen is a separate first step, and EMA puts the transmission software on the sender or its service provider. The split below is Pharos Production's engineering framing of those documents, not a structure any regulator prescribes.

• The safety database owns the case: intake, coding, assessment, follow-up versions and the decision that a case is reportable to a given receiver.
• An ICSR generation layer maps each case version to E2B(R3) for one receiver profile at a time and assigns batch numbers and message identifiers.
• A validation layer blocks any message that fails.
• A transport adapter holds gateway credentials and protocols, AS2 or API for ESG NextGen and the EudraVigilance Gateway for EMA, and tracks account activity, since ESG NextGen deactivates accounts that are inactive for 60 days.
• An acknowledgment processor correlates every response to the batch and messages it answers and writes the regulatory status back to the case.

Keeping generation and transport apart matters whenever something changes: a new FDA regional guide revision touches generation and validation, while a credential rotation touches only the adapter. An auditor can follow any case from the database to the acknowledgment that closed it, because every layer writes to one submission log keyed by case, case version, batch number and message identifier. Gateway adapters and acknowledgment processing are integration work, covered by our software integration services as part of the same pipeline.

FDA and EMA Requirements Compared

Both regions implement the same ICH guide, and each adds its own differences on top of it. The matrix summarizes the FDA and EMA documents cited on this page.

Aspect	FDA	EMA (EudraVigilance)
Receiving database	AEMS, formerly FAERS	EudraVigilance database management system (EDBMS)
Gateway	ESG NextGen, with portal (USP), AS2 and API accounts	EudraVigilance Gateway, following the ICH M2 gateway recommendation (ESTRI)
Route without a gateway	Safety Reporting Portal, for filers without E2B(R3) capability and closed to gateway partners	EVWEB, the web application where registered users create, send and view ICSRs
E2B(R2) messages	Accepted through ESG NextGen for postmarketing ICSRs from companies not yet transitioned only through the cut-off in the status snapshot below, after which FDA intends to stop accepting them for the named product classes	Not accepted
Business rules	FDA E2B(R3) Core and Regional Data Elements and Business Rules spreadsheet	Business rules tables in the EU ICSR Implementation Guide
Regional terminology	Regionally controlled terms from the NCI EVS code set; EDQM or FDA SPL codes accepted for dose form and route of administration TermIDs	EDQM Standard Terms for dose forms and routes of administration, compliant with ISO 11239
Acknowledgments	ACK1 to ACK4 message types, with the applicable ones listed per center and submission type	ICH acknowledgment message with AA, AE or AR at batch level
Testing before production	Pre-production environment, separate test receiver identifiers, a web validator and two levels of testing	Development and validation testing, then quality assurance testing in XCOMP with positive acknowledgments for test cases 1a to 10

FDA regional elements and receiver identifiers

FDA's regional implementation guide calls its additions regional extensions: FDA data elements and terminologies carried on top of the ICH elements, covering premarketing, postmarketing and combination product reporting. Regionally controlled terminology comes from the National Cancer Institute (NCI) Enterprise Vocabulary Services code set 2.16.840.1.113883.3.26.1.1. FDA's postmarketing electronic safety reporting guidance (the eSRR Guidance) incorporates these specifications by reference, and the Federal Register notice describes them as periodically updated, so pin the revision each release was built against.

Routing runs through two header elements. For all postmarketing ICSRs, the regional guide gives the message receiver identifier (N.2.r.3) as CDER and requires the batch receiver identifier (N.1.4) ZZFDA. Premarketing ICSRs use ZZFDA_PREMKT with a message receiver of CDER_IND, CBER_IND or CDER_IND_EXEMPT_BA_BE, and test submissions use ZZFDATST for postmarketing and ZZFDATST_PREMKT for premarketing. These FAERS-era values appear alongside the FAERS name for the database FDA now calls AEMS. They belong in environment configuration, so a test run cannot pick up a production identifier.

The FDA postmarket requirement

Postmarketing ICSRs for human drug products, biological products and drug- or biologic-led combination products submitted through ESG NextGen must reach the AEMS database in E2B(R3) from the switch date in the status snapshot below. FDA defines the requirement by product and channel. The source is a Federal Register notice (document type Notice, not a final rule), which limits its own reach: "This notice regarding the use of ICH E2B(R3) data standards applies only to submission of ICSRs and ICSR attachments through the ESG NextGen."

FDA's AEMS electronic submissions page and the notice set the limits of the requirement. Safety Reporting Portal filers need no action, because the notice applies only to submissions through ESG NextGen. The portal serves applicants, specified nonapplicants and responsible persons without E2B(R3) capability, and a gateway partner cannot use it instead. Once a company has started submitting in E2B(R3), FDA expects all of its ICSRs in that standard. Some filers may need an earlier transition to meet their reporting requirements.

Status snapshot (checked 2026-09-30): the notice, published April 6, 2026 at 91 FR 17284, states: "For postmarketing ICSRs for human drug products, biological products, and drug- or biologic-led combination products submitted via ESG NextGen, beginning October 1, 2026, the ICSRs must be submitted to the AEMS database using ICH E2B(R3) data standards." For postmarketing ICSRs sent through ESG NextGen, FDA's AEMS page keeps E2B(R2) open through September 30, 2026 for companies that have not yet moved to R3 and presents the new date as a six-month extension of the previously recommended implementation period. The notice says FDA intends to stop accepting R2 postmarketing ICSRs sent through ESG NextGen for those products after September 30, 2026. The AEMS page gives April 1, 2026 as the date from which FDA requires E2B(R3) IND safety reports from commercial IND sponsors that submit to AEMS through ESG NextGen by database-to-database transmission. In the EU, EMA's Management Board confirmed that reporting to EudraVigilance in the ISO ICSR standard based on E2B(R3), with ISO terminology for dose forms and routes, became mandatory as of June 30, 2022.

IND safety reports

Premarketing reports follow their own requirement. FDA requires premarketing IND safety reports in E2B(R3), and its AEMS page scopes that to commercial IND sponsors sending ICSRs to AEMS through ESG NextGen by database-to-database transmission. The final guidance on IND safety reports sets the format under section 745A(a) of the FD&C Act for the reports that 21 CFR 312.32(c)(1)(i) requires for serious and unexpected suspected adverse reactions, with binding effect 24 months after its publication in the Federal Register. Electronic submission for IND-exempt BA/BE studies stays voluntary. Because FDA uses different receiver identifiers for premarketing and postmarketing ICSRs, we configure a sponsor with products in both phases with two FDA profiles in one generator.

EudraVigilance

The EU offers no R2 fallback. EMA's electronic reporting page says: "The EudraVigilance system does not accept ICSR messages in the ICH E2B (R2) format." EMA also asks senders to use the ISO terminology for pharmaceutical forms and routes of administration.

That terminology comes from EDQM. The ICH user guide on EDQM terminologies covers EDQM dose form and route of administration terms in E2B(R3) messages. The EU ICSR Implementation Guide adds that these terms comply with ISO 11239, that EudraVigilance synchronizes the EDQM code lists every night and that organizations should aim to update their own systems with EDQM changes regularly. Coding and validation need a planned MedDRA version change, because the EU guide says a new release should become the reporting version for EudraVigilance on the first Monday of the second month after it is released.

Transport runs through the EudraVigilance Gateway, which follows the ICH M2 recommendation for the electronic transfer of regulatory information (ESTRI). EMA makes companies and sponsors responsible for software that exchanges encrypted, digitally signed safety and acknowledgment messages, or for using a service provider, while EVWEB lets registered users create, send and view ICSRs without a gateway. New organizations register separately for the XCOMP testing environment and for production.

Safety Data Exchange With License Partners

The EU's GVP Module VI sets expectations for exchange between license partners without prescribing a format. Where a marketing authorization holder has contractual arrangements with a person or organization, the module expects explicit procedures and detailed agreements, a transfer mechanism that gives confidence that all notifications are received and a confirmation or reconciliation process.

How to meet those expectations is a design choice. We run a partner channel like a regulatory one, with a profile per partner, acknowledgments in both directions and case-list reconciliation at a fixed interval, so a lost file shows up as a count mismatch instead of a late case.

How to Validate Generated E2B R3 Messages

Regulators expect the sender to validate its output before the first production file. FDA's E2B(R3) standards page names the tool: "FDA has provided the FDA E2B(R3) Validator tool to facilitate the validation of the E2B(R3) XML files generated from your safety database."

FDA's guide to preparing for the electronic exchange of safety reports asks organizations to test in the FAERS pre-production environment before production reporting, with gateway partners developing against the ICH and FDA specifications and checking their test files with the validator. The regional guide describes two levels of testing, a working transaction partner account first and then ICSR files that FAERS accepts. The ESG NextGen getting started page points to per-submission-type details such as file size thresholds and whether test submissions are required.

In the EU, EMA requires organizations that report from their own system to complete development and validation testing before quality assurance testing, which they request once test cases 1a to 10 in XCOMP have each received a positive acknowledgment, as EMA's electronic reporting page sets out. Both regulators support initial testing of software and system solutions by IT vendors and third-party service providers, so a build team can prove a generator before the client's own testing starts.

Inside the build, validation runs from the cheapest check to the most specific, and a message that fails one layer never reaches the next.

1. XML schema (XSD) validation against the ICH ICSR XML Schema Set that FDA links from its E2B(R3) guidance page.
2. ICH conformance, such as the N.1.1 business rule that the value allowed is case sensitive, with lowercase characters only.
3. Regional business rules from FDA's spreadsheet or the EU guide's tables, chosen by the message receiver.
4. Terminology checks for the MedDRA version in force, EDQM terms in EU messages and, for FDA, the regionally controlled terms its regional guide allows in both regional and ICH elements, each loaded from versioned reference data instead of hard-coded lists.
5. Transport checks on extension, encoding and size.

For regression tests, FDA publishes FDA ICSR XML Instances and links the ICH reference and example instances from its guidance page. Running every release against them, plus anonymized cases from the client's own history, catches a mapping change before a receiver does, and our QA services team builds that kind of automated suite into the delivery pipeline.

E2B R3 Implementation Checklist

Tagged items rest on the FDA or EMA documents cited on this page, and untagged items are Pharos Production's engineering practice.

1. List every receiver the system must serve, whether FDA postmarketing, FDA IND, EudraVigilance or a license partner, with its format, test environment and identifiers kept per environment.
2. Confirm which FDA channel each reporting flow uses, since the ESG NextGen requirement does not reach Safety Reporting Portal filers (FDA).
3. Map each safety database field to an R3 element and its allowed nullFlavor codes, decide where R2 data without a direct R3 target goes under the ICH conversion recommendations and keep original messages.
4. Pin every rule source and terminology a release was built against: the ICH schema set, FDA's business rules spreadsheet, the regional guide, the EU guide and versioned MedDRA, EDQM and NCI EVS reference data, with each MedDRA switchover scheduled.
5. Embed attachments inline. For FDA, encode them as base64 without compressing them individually and check submission size against FDA's recommendation; for EudraVigilance, follow the EU guide's attachment encoding rules (FDA, EMA).
6. Track every submission through the acknowledgment state model above, with correlation, timers and alerts, so that a delivery receipt is never treated as acceptance.
7. Pass FDA pre-production testing and the EMA XCOMP test cases before the first production file (FDA, EMA).
8. Hand the client's QA team the requirements trace, test evidence and configuration records it needs to validate the system.
9. Recheck FDA's AEMS and ESG NextGen pages, EMA's electronic reporting page and both regional guides on a fixed schedule.

How Pharos Production Helps

Pharos Production builds and integrates the E2B(R3) pieces around a client's safety database: ICSR generation for each receiver profile, validation layers that mirror FDA and EMA rules, gateway adapters and the acknowledgment processing that writes each result back to the case. In our delivery model, the safety database remains the system of record and the client's QA team owns validation of the system. Our delivery is validation-ready, with requirements traceability, test evidence and change records produced in the SDLC and handed over for that validation. E2B(R3) integration is one part of our pharmaceutical software development services.

Sources: Federal Register notice 91 FR 17284; FDA AEMS electronic submissions, E2B(R3) standards, ESG NextGen and acknowledgments pages, regional implementation guide, testing guide and IND safety reports guidance; ICH E2B(R3) implementation guide and Appendix I (B) in FDA's guidance copies; EMA EudraVigilance electronic reporting, system overview and registration pages, EU ICSR Implementation Guide, EDQM terminology user guide, Management Board announcement and GVP Module VI. Engineering guidance, not regulatory or legal advice.

FAQ

Last updated: October 20, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 7

• What is E2B R3 in pharmacovigilance?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  It is the ICH standard for exchanging individual case safety reports electronically. Each case travels as its own XML message under ISO/HL7 27953-2, and each message carries exactly one ICSR.

  The receiver checks each message against its business rules and, for a known trading partner, answers the whole batch with one acknowledgment that reports on every message. Regulators use the format to receive cases, and companies can use the same messages to exchange cases with license partners.

• What does E2B R3 stand for?

  Copy link Copies a direct link to this answer to your clipboard.

  The name points to an ICH guideline: E2B is the guideline on electronic transmission of individual case safety reports, and (R3) marks the revision that replaced E2B(R2). ICSR stands for individual case safety report.

• Is E2B R3 mandatory?

  Copy link Copies a direct link to this answer to your clipboard.

  For EudraVigilance and for FDA's ESG NextGen channel, yes. EudraVigilance does not accept E2B(R2) messages.

  FDA requires E2B(R3) for postmarketing ICSRs on human drug products, biological products and drug- or biologic-led combination products submitted through ESG NextGen, and for IND safety reports that commercial IND sponsors send to AEMS through ESG NextGen by database-to-database transmission. Filers who use FDA's Safety Reporting Portal need no action, because the requirement covers only submissions through ESG NextGen; the portal serves filers without E2B(R3) capability.

• Can a company keep producing E2B R2 and convert it at the gateway?

  Copy link Copies a direct link to this answer to your clipboard.

  ICH publishes conversion recommendations for that in Appendix I (B), but the appendix warns that repeated conversion can transform or lose information and tells receivers to evaluate converted content carefully. EudraVigilance does not accept R2, and FDA expects every ICSR in R3 once a company has started submitting R3.

  A converter is a bridge for a license partner that still sends R2, while generating R3 directly from the safety database avoids the conversion risk.

• Does FDA use EDQM terms the way EMA does?

  Copy link Copies a direct link to this answer to your clipboard.

  Not in the same way. EudraVigilance expects EDQM terms for dose forms and routes of administration. FDA's regional implementation guide accepts either EDQM codes or FDA SPL lists for the dose form and route of administration TermIDs and draws its other regionally controlled terminology from the NCI EVS code set, so terminology rules belong in each receiver's profile.

• Who validates an E2B R3 system, the vendor or the pharmaceutical company?

  Copy link Copies a direct link to this answer to your clipboard.

  No FDA or EMA document cited on this page assigns that responsibility. In the delivery model this page describes, the client's QA function owns validation of the system and the development partner delivers validation-ready evidence: requirements traceability, test evidence and change records.

  The regulators' own testing is narrower. FDA's validator and pre-production environment and EMA's XCOMP quality assurance testing check the messages the system produces, and both regulators support initial testing of software by IT vendors.

• What should happen when FDA sends no acknowledgment?

  Copy link Copies a direct link to this answer to your clipboard.

  We recommend treating the silence as a failure to investigate rather than a pending state. FDA's ESG NextGen page states that acknowledgments are not generated for files with invalid extensions or files that are not encoded properly, so a submission without an acknowledgment past its expected window should raise an alert, and the team should check the file before resending it.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.