Thought Leadership - News and Blog - ProPharma

Modernizing Case Management for Global Compliance

Written by Angie Robertson | June 8, 2026

One of the biggest challenges in pharmacovigilance is knowing (and staying informed of) regional and country requirements for adverse event reporting. There are so many different requirements, methods for submission, and formats for reports that it often takes a whole team of people to collect, catalog, and monitor these requirements. Wouldn't it be great if every country's regulatory authority required the same form, with the exact same data fields, to be submitted within the same timeframe? One 'universal' adverse event report? Maybe the E2B (R3) is the beginning of that dream coming true!

E2B(R3) Defined

What is 'the E2B (R3)' you ask? E2B(R3) is a pharmacovigilance standard data file designed for the electronic exchange of individual case safety reports (ICSR) and Suspected Unexpected Serious Adverse Reaction (SUSAR) for drug products, that are produced by validated safety databases (or other software tools) and used to import standardized data elements into other databases. HL7 ICSR models and ISO identification standards contribute to the design of the E2B (R3).

Start with the End Result

Starting with regional and country safety reporting requirements, the safety database is configured to produce validated files based on Health Authority requirements for file formatting, inclusion of specific ICSR criteria (i.e., seriousness, relatedness, listedness), and transmission methods within a specified number of days from awareness.

Doing this before any safety reports are entered in the database is the foundation for ensuring reporting compliance. Subsequently, updating these initial configurations when regulatory requirements change is critical for maintaining reporting compliance.

Currently FDA, EMA, MHRA, Japan's MHLW, Health Canada, Australia's TGA, and other regulatory authorities have adopted E2B(R3) method of submitting ICSRs and SUSARs; each with a slightly different profile requirement. Many other regulatory authorities are in the process of adopting this standard. Most regulatory authorities also require submission of test files to be approved prior to the first ICSR or SUSAR submission.

The Data Flow

Regardless of the names or the number of steps in your process to create and manage ICSRs, each data field must be entered accurately or the E2B (R3) will not meet the receiving regulatory authority's data requirements and result in non-compliance.

Robust training of all team members entering data from Intake to Case Finalization is key for successful E2B (R3) generation.

Standard E2B fields include (but are not limited to):

  • Adverse event terms coded with standard MedDRA dictionary
  • Suspect products coded to the registered product identifier
  • Medical history coded with standard MedDRA dictionary
  • Concomitant medications coded with standard WHODrug dictionary
  • Patient demographics
  • Comprehensive narratives
  • Supporting laboratory or diagnostic test results (frequent cause of file generation failures)
  • Blank fields(Most E2B (R3) profiles do not allow blank data fields and null values must be selected.)

Starting with intake and receipt of the adverse event information and continuing in each step thereafter, the data fields must be entered to meet the final output requirements.

Conclusion

Not only are E2B (R3) files now required by many regulatory authorities, but they can also be used to exchange safety data with business partners and even for data migration/transition projects.

With validated E2B (R3) profile configurations based on country specific regulatory authority requirements and robust database user training, E2B (R3) files get us closer to a 'universal' way to exchange ICSRs and improved reporting compliance in efforts to protect patient safety.