ICH E2B(R3) explained: the ICSR format for pharmacovigilance reporting

What E2B(R3) is

The ICH guideline E2B(R3) covers the electronic transmission of ICSRs: the data elements that describe a suspected adverse reaction case, and the message specification for sending them. It is implemented through the ISO ICSR standard developed with HL7, and replaced the older E2B(R2) format.

The guideline is the common core. Each regulator publishes a regional implementation guide with its own business rules, extra fields, gateways and acknowledgement handling. The EU’s guide for EudraVigilance is the most widely used example. Before submitting anywhere, read the current guide for that destination.

E2B(R3) defines how a case is exchanged, not how it is processed. Timelines, seriousness rules and who must report what still come from each region’s pharmacovigilance legislation and guidance, so the PV system has to combine the exchange standard with regional rules.

How an E2B(R3) message is structured

An R3 message wraps one or more ICSRs in batch and message headers. Each ICSR is organised into lettered sections:

Two identifiers matter in every case: the sender’s safety report unique identifier, and the worldwide unique case identification number that stays the same across senders and follow-ups. Getting them right is the basis of duplicate detection and case versioning.

What changed from E2B(R2)

Null flavours deserve a note. In R3 an empty field is not the same as “unknown” or “asked but not known”, and business rules often check which null flavour is allowed. Safety systems need to capture that distinction at data entry, not invent it at export.

Coding and terminologies

Reactions, indications and medical history are coded with MedDRA, using the version the receiver accepts. Many companies also code drugs with a drug dictionary such as WHODrug for consistency, while the ICSR carries product names and identifiers. Units use UCUM, and the EU expects ISO-based terms for dose form and route.

• Keep the reported verbatim term alongside the coded term.
• Record which MedDRA version each case was coded with.
• Plan for MedDRA version upgrades and recoding rules.
• Remember that MedDRA and drug dictionaries need their own licences, held by the marketing authorisation holder or its provider.

Submission, validation and acknowledgements

Sending a case is a round trip. The receiver checks the message against the schema and its business rules, then returns an acknowledgement message saying whether each ICSR was accepted or rejected, with error details. Your system should:

• Validate the XML against the schema and regional business rules before sending.
• Send through the regulator’s gateway or approved tool and log the transmission.
• Receive and parse acknowledgements automatically and link them to the case version.
• Flag rejections immediately so the case can be corrected and resent within the deadline.
• Track reporting timelines from the day the company first became aware of the case.

Every one of these steps changes GxP records, so the case history and audit trail must show who did what and when; our deep dive on audit trail requirements applies here too.

Common reasons ICSRs are rejected

Most rejections come from a small set of problems that good software can catch before sending:

• Mandatory elements missing, or left blank where a null flavour was required.
• A null flavour used that the business rules do not allow for that field.
• Code values outside the allowed list, such as an invalid route, dose form or unit.
• MedDRA terms from a version the receiver no longer accepts, or terms that are not at the expected level.
• Follow-up reports whose identifiers do not match the original case, creating duplicates.
• Dates in the wrong format or precision, or dates that contradict each other.
• XML that does not validate against the schema, often after a manual edit.

Running the same business-rule checks inside the PV system, at data entry and before export, turns most of these into warnings a case processor can fix in minutes instead of a rejection found days later.

Moving from R2 to R3

Teams still working with R2-era systems or partners face a migration, not a format switch. The practical steps are:

1. Map your case data model to R3 elements, including the new repeatable fields and null flavours.
2. Decide how legacy cases will be converted, following the ICH mapping guidance, and how converted cases are verified.
3. Update case-entry screens so the data R3 needs is captured at source, not guessed at export.
4. Agree exchange formats with licensing partners and service providers, and update safety data exchange agreements if needed.
5. Test submissions in the regulator’s test environment before going live, and validate the changed system.

What a PV system needs to support E2B(R3)

• Case intake from email, forms, literature and partners, with duplicate checks on key identifiers.
• A data model that mirrors R3, including repeating elements and null flavours, so export is faithful.
• MedDRA coding with version control and verbatim terms kept.
• Follow-up versioning that keeps every version of the case and what changed.
• E2B(R3) import and export, schema and business-rule validation, gateway connection and acknowledgement handling.
• Workflow and deadlines for triage, medical review and submission, with alerts before due dates.
• Audit trail, access control and validation like any other GxP system.

Whether to buy a safety database or build one around your process is covered in pharmacovigilance software: build vs buy. Validation of the system follows the same life cycle as any other, described in our GxP validation guide.

How we approach E2B(R3) projects

We build pharmacovigilance software covering case intake, MedDRA coding, E2B(R3) submissions and signal management, with the validation deliverables written alongside the code and sign-off by your QA. Our PVgenix platform is described on our work page, and the service itself on our pharmacovigilance software page.

Frequently asked questions