Every electronic ICSR you submit travels in an ICH E2B file. Two versions are still encountered in practice: the legacy E2B(R2) and the current E2B(R3). Knowing the difference matters because it affects which fields you must capture, how your data is validated, and which authorities accept which version. This guide keeps it practical.
What is E2B?
E2B is the ICH (International Council for Harmonisation) standard that defines the data elements and electronic format for transmitting Individual Case Safety Reports between organisations and regulators. It is what lets a case created in one system be received and understood by another, anywhere in the world. If you are new to the case itself, start with our guide to ICSR case processing.
The big shift: ICH ICSR / HL7
The headline change from R2 to R3 is the underlying format. E2B(R2) uses an older DTD-based XML structure. E2B(R3) is built on the HL7 v3 messaging standard (the ICH ICSR message), which is more rigorous, more richly structured, and validated against XML schemas. In practice this means R3 files are larger and more complex, but far more precise about how each piece of information is represented.
Key differences at a glance
| Area | E2B(R2) | E2B(R3) |
|---|---|---|
| Underlying standard | Legacy DTD-based XML | HL7 v3 (ICH ICSR), schema-validated |
| Data elements | Around 180 fields | Substantially more (roughly 250+) |
| Missing data handling | Limited | Null flavours specify why data is absent (unknown, not applicable, masked) |
| Character support | More limited | Full Unicode / internationalisation |
| Granularity | Coarser fields | Finer structure for dose, timing, causality |
| Attachments | Not natively supported | Supports embedded documents / literature references |
| Status | Being phased out | Current required format in major regions |
Null flavours: a small change with big impact
One of the most useful additions in R3 is the concept of null flavours. Instead of simply leaving a field blank, R3 lets you state why it is empty — for example 'unknown', 'not applicable', 'asked but unknown', or 'masked'. This removes ambiguity for the receiving authority and improves data quality across the system. It is also a common source of validation errors when teams migrate from R2, so it deserves attention during testing.
Who accepts which version?
The major regions have moved to R3 for their primary safety reporting. The EMA's EudraVigilance has required E2B(R3) since 2017, and other authorities have followed. The FDA (FAERS) and MHRA also support R3-based submission. That said, R2 has not disappeared entirely from partner and legacy exchanges, so a capable platform should generate and validate both. PVgenix supports E2B(R2) and E2B(R3) XML generation and validation, with a built-in AS2 gateway and coverage for FDA, EMA, and MHRA submission.
What R3 means for your team in practice
- Capture more granular data at intake — R3 expects finer detail on dosing, timing, and causality
- Configure null flavours so missing information is explained, not just left blank
- Validate against the XML schema before submission to catch structural errors early
- Maintain mapping for partner exchanges that still use R2
- Keep an audit trail of what was generated and submitted, and reconcile acknowledgements
The bottom line
E2B(R3) is not just a new file format — it is a richer, stricter data model. Teams that capture clean, granular data at intake and validate early have far smoother submissions. A platform that handles both versions and automates validation removes most of the pain.
Frequently asked questions
E2B(R2) uses an older DTD-based XML structure, while E2B(R3) is built on the HL7 v3 ICH ICSR message. R3 has more data elements, supports null flavours to explain missing data, and is validated against XML schemas.
The major authorities have moved to E2B(R3) for primary safety reporting — for example EudraVigilance has required R3 since 2017. R2 is still seen in some partner and legacy exchanges, so supporting both is useful.
Null flavours let you state why a field is empty — such as unknown, not applicable, or masked — rather than just leaving it blank, which improves data quality and reduces ambiguity for the receiving authority.