E2B(R3) Data Elements: ICSR Guide

An E2B(R3) Individual Case Safety Report (ICSR) isn’t a free-text safety narrative — it’s a structured, schema-validated XML message, and every field in that message carries one of three designations: mandatory, conditional, or optional. Getting that designation wrong is the single most common reason a technically well-formed ICSR still fails business-rule validation at a receiving authority. This page is a practical, section-by-section reference to what those data elements actually are and how their required-ness is determined — not the registration, routing, or reporting-timeline mechanics of any one destination, which the EudraVigilance reporting guide already covers for the EU specifically. Use this page when you’re actually building or reviewing a case, not when you’re deciding where to send it.

What E2B(R3) is, briefly

E2B(R3) is the current ICH standard defining the data elements and message structure for electronic transmission of ICSRs — the harmonised format that lets a case built once be submitted, with only regional business-rule adjustments, to any ICH-region authority (the FDA, EMA/EudraVigilance, PMDA, and the other regulators that have adopted it). It replaced the older E2B(R2) format, moving from a flat, EDI-style message to an XML message built on the HL7 Individual Case Safety Report standard (aligned with ISO/HL7 27953). The ICSR processing workflow guide covers what happens to a case before and after it becomes an E2B(R3) message — intake, triage, medical review, follow-up. This page picks up specifically at message construction: what has to be in it, what doesn’t, and why.

The message structure: A-sections and B-sections

E2B(R3) organises a case into two broad groups of data elements, conventionally labelled A and B in the ICH implementation guide:

A.1 – Identification of the case safety report: the safety report’s own unique identifier, its worldwide unique case identifier, report type (spontaneous, study, literature, other), and version/nullification status.
A.2 – Primary source(s) of information: who reported the case — qualification (physician, pharmacist, consumer, other health professional), country, and contact details to whatever degree privacy rules allow.
A.3 – Information on sender and receiver: the transmitting organisation and the destination authority or partner, needed for routing and acknowledgment matching.
A.4 – Literature reference(s): citation detail when the case originates from a published article.
A.5 – Study identification: study name/number/type when the case originates from a clinical trial or other organised data collection, distinct from spontaneous reporting.
B.1 – Patient characteristics: age, sex, weight/height, relevant medical/family history, and (for parent-child or parent-fetus cases) parent information.
B.2 – Reaction(s)/event(s): the MedDRA-coded adverse reaction or event, seriousness criteria, onset/outcome, and the reporter’s and sender’s causality assessments — see MedDRA coding for trial safety data for how that coding step actually works.
B.3 – Results of tests and procedures: relevant investigations performed on the patient, structured rather than narrative where the schema allows it.
B.4 – Drug(s) information: suspect, concomitant, and interacting drugs, each with its own dosage, route, indication, and action-taken-with-drug elements — the most data-element-dense section of the message.
B.5 – Narrative case summary and further information: the free-text case narrative, sender’s diagnosis, and reporter/sender comments that tie the structured fields together into a readable case.

Every field inside those sections is then assigned a required-ness designation by the ICH E2B(R3) implementation guide itself.

Mandatory, conditional, and optional — what the three designations actually mean

The ICH guide doesn’t leave required-ness to interpretation; each data element carries one of three categories:

Mandatory: the message is invalid without it. The safety report unique identifier, the worldwide unique case identifier, at least one reaction/event term, and at least one drug are examples — these map directly onto the four minimum criteria for a reportable case (identifiable reporter, identifiable patient, suspect drug, adverse reaction) that gate whether a case is valid at all, before it even reaches the format question.
Conditional: required only when a specific triggering condition is met elsewhere in the message — for example, a dose unit is conditional on a dose value actually being present; a parent’s age is conditional on the case being a parent-child report. Getting a conditional element wrong (present when it shouldn’t be, or missing when its trigger fires) is a common source of schema-validation rejections that look, on the surface, like a mandatory-field problem.
Optional: genuinely not required by the ICH core standard, but often worth populating anyway — richer optional data (batch/lot number, additional test results, more granular dosage structuring) improves signal-detection quality downstream even where no rule forces it.

Two things trip up teams building cases against this: first, an ICH-core-optional element can be promoted to regionally required (below); second, “mandatory” describes the data element’s presence in the schema, not necessarily a specific value — which is what null flavours exist to resolve.

Null flavours: how a mandatory field survives an unknown value

Because E2B(R3) is schema-validated XML, a mandatory element can’t simply be left blank when the actual value is genuinely unavailable — the reporter didn’t give a date of birth, or a drug’s dose truly wasn’t specified. E2B(R3), inheriting from its HL7 v3 base, resolves this with null flavour codes: a controlled value placed in the field instead of the real answer, stating why it’s absent rather than just leaving a gap. Common null flavours include codes for “unknown,” “asked but unknown” (the question was put to the source and they didn’t know), “not asked,” and “masked” (withheld deliberately, e.g. for privacy). This is a genuine structural improvement over E2B(R2), which had no equivalent standard mechanism and pushed reporters toward inconsistent placeholder text instead.

Regional layering: the same core, different required-ness by ICH region

The ICH E2B(R3) implementation guide defines the harmonised core — the M/C/O designations above are the same everywhere a message is built to spec. What differs by destination is the regional layer: FDA, EMA, PMDA, and other ICH-region authorities each publish their own regional implementation guide and validation rule set on top of the ICH core, and that regional layer can promote an ICH-optional (or conditional) element to regionally required for messages submitted to that authority specifically. A field that validates cleanly against the bare ICH schema can still be rejected by a specific regulator’s regional business rules if a regionally-required element is missing — the schema check and the regional business-rule check are two separate gates, and passing the first doesn’t guarantee passing the second. In practice, this means a case built once against the ICH core still needs a destination-specific validation pass before submission, not a single generic check reused across every regulator. The regional layer can only add requirements, never relax an ICH-mandatory element back to optional.

What changed structurally from E2B(R2)

Beyond the format shift from flat/EDI-style to HL7-based XML, E2B(R3) introduced handling that R2 lacked:

Nullification and amendment as distinct, linked message types — rather than resubmitting a corrected case as if it were new, R3 lets a sender formally nullify a previously submitted report or submit a follow-up/amendment that references the original case’s identifiers, so the receiving system can track a case’s full version history instead of treating each submission as unrelated.
An acknowledgment (ACK) message returned by the receiver, confirming whether the submission was received and whether it passed structural and business-rule validation — the mechanism that actually tells a sender a submission succeeded, distinct from simply not getting an error back at transmission time. Treat receipt of a positive ACK, not just a completed transmission, as the confirmation that a case is actually in the system.
More granular structured fields, particularly in drug dosage/route and test-result structuring, reducing how much case detail has to live only in the B.5 narrative.

Practical submission-prep checklist

Confirm the case clears the four minimum reportability criteria before worrying about element-level completeness — an invalid case doesn’t need a perfect message.
Walk the A- and B-sections in order and mark each element mandatory, conditional, or optional against the ICH core guide first, before layering on any single regulator’s regional rules.
For every conditional element, confirm both directions: it’s present when its trigger condition is met, and absent (or correctly omitted) when it isn’t.
Use a null flavour, not a blank field or placeholder text, anywhere a mandatory value is genuinely unknown.
Re-validate against the destination authority’s current regional implementation guide before submission — a case valid against the ICH core alone is not the same as a case valid for a specific regulator.
For a correction, use a proper amendment referencing the original case identifiers rather than a fresh submission; use nullification only when the case itself shouldn’t have been reported at all.
Treat a positive ACK, not the absence of a transmission error, as confirmation of successful submission.

Frequently asked questions

Is E2B(R3) the same format for every country?

The core data elements and their mandatory/conditional/optional designations are harmonised across ICH regions. What differs is the regional implementation guide each authority (FDA, EMA, PMDA, and others) layers on top, which can require additional elements the ICH core leaves optional — so a message has to be validated against the specific destination, not just the shared ICH schema.

What’s the difference between a conditional and an optional data element?

A conditional element becomes required only when a specific triggering condition elsewhere in the case is met (e.g. a dose unit once a dose value is given); an optional element is never required by the ICH core standard regardless of what else is in the case, though populating it can still improve downstream data quality.

Why can’t a mandatory field just be left blank when the value is unknown?

E2B(R3) is schema-validated XML, and a mandatory element with no value fails validation outright. A null flavour code (for “unknown,” “asked but unknown,” “not asked,” etc.) satisfies the schema while honestly recording why the real value is absent, instead of forcing a placeholder or a rejected message.

How is E2B(R3) different from E2B(R2)?

R3 moved from a flat, EDI-style message to an HL7-based XML message, added formal nullification and amendment message types linked to the original case’s identifiers, added an acknowledgment (ACK) message confirming receipt and validation status, and introduced more granular structured fields in areas like drug dosage and test results.

Does passing ICH schema validation mean a case is ready to submit?

Not on its own. Schema validation confirms the message is well-formed against the ICH core; a receiving authority’s regional business rules are a separate check that can still reject a schema-valid message if a regionally-required element is missing.

E2B(R3) Data Elements: A Practical ICSR Submission Reference

Ask about E2B(R3) Data Elements: A Practical ICSR Submission Reference