There is a large gap between understanding E2B(R3) and being able to submit in it. The standard is well documented; what is less well documented is the implementation — the mapping decisions, the regional profile differences, the two distinct kinds of validation that catch different failures, and the sequencing of test submissions before you are live.
This guide covers that work. It deliberately does not re-explain how E2B(R3) differs structurally from E2B(R2) — E2B(R2) vs E2B(R3) does that. Start there if you need the comparison; start here if you have to make it work.
Scope of this guide
This describes general implementation practice to help you plan a project and specify a system. It is not regulatory advice, and it is not a substitute for the current ICH implementation guide or the receiving authority's own technical specifications — always work from those, since regional requirements are updated independently of each other.
| Phase | Work | Output |
|---|---|---|
| 1. Scope and obligations | Establish which authorities you submit to, for which products, markets and case types, and in which format each expects | A submission obligation matrix — the input to everything else |
| 2. Gap analysis | Compare the data you currently capture against the target dataset for each destination, including conditionally mandatory fields | A list of fields to start capturing, and where they come from |
| 3. Field mapping | Map internal case fields to E2B(R3) data elements, per regional profile | A documented mapping specification, version-controlled |
| 4. Configuration | Configure the mapping, code lists, regional profiles and reporting rules in the system | A configured, change-controlled submission setup |
| 5. Validation build | Schema validation plus business-rule validation, run before transmission | Failures caught in-house rather than as authority rejections |
| 6. Gateway setup | AS2 configuration, certificates, endpoints, routing per destination | A tested transmission path with acknowledgement handling |
| 7. Test submissions | Submit into each authority's test environment and resolve findings | Evidence that end-to-end transmission and ACK processing work |
| 8. Qualification | Execute your qualification against the configured system and document it | A qualified, documented submission capability |
| 9. Go-live and monitoring | Controlled cutover, with ACK monitoring and rejection triage from day one | Live submission with a feedback loop |
Phase 1 is the one teams skip
Most E2B implementation pain traces back to an incomplete obligation matrix. If you do not know precisely which authority expects which format for which case type in which market, you cannot map, cannot configure rules, and cannot test properly. Build the matrix first, get your qualified PV personnel to approve it, and treat it as a change-controlled document.
Most fields map straightforwardly. The effort concentrates in a small number of areas that recur in every implementation.
Free text into structured elements
R3 structures data that legacy processes often held as narrative. Deciding what is captured structurally versus what remains narrative is a process decision, not just a mapping one.
Dates with partial precision
Real reports contain "last month" and "about two years ago". The standard supports varying precision; your data entry conventions and validation have to as well.
Nullification and masking semantics
How to express "this information is not available" versus "this information exists but cannot be disclosed" versus "this field does not apply" — three different meanings that are easy to conflate.
MedDRA version alignment
The dictionary version used to code the case must be represented consistently, and recoding on version change has to be planned rather than discovered.
Identifiers and worldwide unique case ID
Getting case identifier construction and persistence right matters across follow-ups, retransmissions and nullifications — and it is painful to change later.
Attachments and source documents
Whether, how and to whom source documents are transmitted differs by destination, and has data-protection implications worth settling early.
Keep the mapping specification as a controlled document rather than as configuration only. When an authority raises a rejection two years later, the question will be why a field was mapped the way it was — and "because that is how the system is set up" is not an answer.
E2B(R3) is an ICH standard, but receiving authorities publish their own regional implementation requirements on top of it. Treating "E2B(R3) compliant" as a single destination-agnostic capability is a common and expensive assumption.
- Conditionally mandatory fields differ — a field optional for one authority may be required by another
- Business rules differ — the same file can pass one authority's validation and fail another's
- Code lists and controlled vocabularies may have regional additions or restrictions
- Acknowledgement content and error coding differ, so rejection triage is destination-specific
- Transmission arrangements differ — gateway configuration, routing identifiers and test environments are not interchangeable
- Nullification and amendment handling can differ in expectation even where the mechanism is the same
Practically, this means the reporting rules engine has to resolve not just *whether* to report but *which profile* to generate, and your validation has to run the destination's rules rather than a generic set. See the reporting rules engine for how obligations resolve into destination, format and deadline.
This distinction is routinely blurred, and blurring it is why teams get surprised by rejections on files that "validated fine".
| Schema validation | Business-rule validation | |
|---|---|---|
| Question | Is the file structurally well-formed against the XML schema? | Does the content satisfy the destination's logical requirements? |
| Catches | Missing required elements, wrong data types, invalid structure, malformed values | Conditionally mandatory fields absent, contradictory values, impossible date sequences, code-list violations, regional rule breaches |
| Misses | Everything logical — a structurally perfect file can be logically nonsense | Nothing logical, but assumes the structure is already valid |
| When to run | Before transmission, always | Before transmission, per destination profile |
| If skipped | Immediate technical rejection at the gateway | Acceptance followed by a business-level rejection, or silent data quality problems |
Run both in-house, before transmission
The goal is that an authority never rejects a file for something you could have detected yourself. Every avoidable rejection consumes clock, creates rework, and shows up in your on-time submission metric. Build both validations into the pre-transmission gate, not into a post-mortem.
Sending the file is the easier half. Closing the loop is what makes the submission defensible, and it is where implementations are most often thin.
- Parse the acknowledgement and match it back to the specific case version that was transmitted — not just to the case
- Distinguish transport-level receipt from business-level acceptance; the first does not imply the second
- Classify rejections by error code and route them to an owner as a task, rather than logging them somewhere nobody reads
- Track the clock through the rejection — a rejected submission is not a submitted one, and the deadline has not paused
- Detect missing acknowledgements: a file that was never acknowledged is the most dangerous state, because nothing failed visibly
- Support retransmission and nullification as first-class flows with their own audit entries
The silent failure
The worst outcome is not a rejection — it is an unacknowledged submission nobody noticed. Build an ageing report on transmissions awaiting acknowledgement and treat it as an operational queue with a threshold, the same way you treat overdue submissions.
Authorities generally provide test environments, and using them properly is the difference between a controlled go-live and a live discovery process. Sequence the testing rather than treating it as one activity.
- Start with your own validation — a file that fails locally should never reach a test gateway
- Test transmission and acknowledgement mechanics with a small, well-understood case set per destination
- Then test breadth deliberately: serious and non-serious, initial and follow-up, fatal outcomes, partial dates, multiple suspect products, multiple events, nullification, and retransmission
- Include the awkward cases you know exist in your real data, not only clean synthetic ones
- Record every test, its outcome, and the resolution of each finding — this becomes qualification evidence
- Plan cutover per destination rather than switching everything at once, and keep the ability to fall back
E2B submission is a regulated capability, so the configured system needs to be qualified in your environment — and the mapping specification, validation rules, and test evidence are central inputs to that.
- Requirements traceability should link each obligation in your matrix to the configuration and the test that demonstrates it
- Test submission records are useful performance-qualification evidence — capture them properly at the time rather than reconstructing later
- Change control matters disproportionately here: authorities update regional requirements, and each update is a change to a qualified capability
- Define in advance who reviews and approves a mapping or rule change, and what re-testing it triggers
Validation is environment-specific
PVgenix is validation-ready and audit-ready: it ships with a complete IQ/OQ/PQ documentation package to support client-led validation. 'Validated' is a state achieved only after qualification is executed in a specific client environment.
A capable safety system removes most of the recurring work here, leaving you the decisions that are genuinely yours — the obligation matrix, the mapping approvals, and the regulatory interpretation behind the rules.
| Capability | Why it matters |
|---|---|
| E2B(R2) and E2B(R3) generation | Both are still in use across destinations and partners; you rarely get to run only one |
| Per-destination profile generation | The same case must produce the profile each authority expects, resolved by rule rather than by hand |
| Schema plus business-rule validation pre-transmission | Avoidable rejections never reach an authority |
| Built-in AS2 gateway | No separate gateway product to license, configure and add to your qualification scope |
| ACK parsing and reconciliation to the case version | Closes the loop and makes on-time submission metrics derivable rather than asserted |
| Retransmission and nullification flows | First-class handling rather than manual workarounds on a regulated record |
| CIOMS I and MedWatch 3500A outputs | Partner exchange and some destinations still need forms alongside E2B |
| Audit trail of every generation and transmission event | The evidence base when a submission is questioned years later |
PVgenix provides E2B(R2) and E2B(R3) generation with schema and business-rule checks before transmission, a built-in AS2 gateway, acknowledgement handling reconciled back to the case, and retransmission and nullification handling — with documented submission support for FDA (FAERS via the ESG gateway), EMA (EudraVigilance) and MHRA. Other destinations are assessed per client agreement. See regulatory submission and E2B(R3) software for the capability detail.
The short version
Build the obligation matrix first and control it. Treat E2B(R3) as one standard with several regional dialects rather than a single capability. Run schema *and* business-rule validation in-house before transmission. Build acknowledgement reconciliation properly, including detection of missing ACKs. And keep the mapping specification and test evidence as controlled documents, because they are your qualification inputs and your answer years later.
Related: E2B(R2) vs E2B(R3) for the structural comparison, CIOMS I vs E2B(R3) for when a form is required instead of a data file, and expedited reporting timelines for the clocks these submissions run against.
Frequently asked questions
Common questions
Establishing the submission obligation matrix (which authority, which format, which case types, which markets); gap analysis against the target dataset; field mapping per regional profile; system configuration; building schema and business-rule validation; gateway setup with acknowledgement handling; test submissions into each authority's test environment; qualification execution and documentation; then controlled go-live with acknowledgement monitoring. The obligation matrix is the phase most often skipped and the source of most downstream pain.
Schema validation checks whether the file is structurally well-formed against the XML schema — required elements present, correct data types, valid structure. Business-rule validation checks whether the content satisfies the destination's logical requirements — conditionally mandatory fields, contradictory values, impossible date sequences, code-list violations, and regional rules. A structurally perfect file can be logically invalid, so both must run before transmission. Skipping the second produces acceptance followed by a business-level rejection.
No. E2B(R3) is an ICH standard, but receiving authorities publish regional implementation requirements on top of it. Conditionally mandatory fields, business rules, code lists, acknowledgement content and error coding, and transmission arrangements all differ. The same file can pass one authority's validation and fail another's, so treat E2B(R3) as one standard with several regional dialects and generate the profile each destination expects.
Parse the acknowledgement and match it to the specific case version transmitted; distinguish transport-level receipt from business-level acceptance; classify rejections by error code and route them to an owner as a task; keep the regulatory clock running through a rejection, since a rejected submission is not a submitted one; detect transmissions that were never acknowledged at all; and support retransmission and nullification as first-class flows with their own audit entries. The unacknowledged submission is the most dangerous state because nothing failed visibly.
Sequence it. Validate locally first — a file failing your own validation should never reach a test gateway. Then test transmission and acknowledgement mechanics with a small well-understood case set per destination. Then test breadth deliberately: serious and non-serious, initial and follow-up, fatal outcomes, partial dates, multiple suspect products and events, nullification and retransmission — including awkward cases you know exist in your real data. Record every test and the resolution of each finding, since that becomes qualification evidence.
Frequently yes. Destinations and partners migrate on different timelines, and legacy data exchange and migration activities often rely on R2. Most operations need the ability to generate both for a period, which is why dual-format support and per-destination profile resolution matter more than picking a single target format. See our E2B(R2) versus E2B(R3) guide for the structural comparison.