"Do we use CIOMS or E2B?" is one of the most common questions in a safety software evaluation, and it contains a category error. The two are not competing options. CIOMS I is a form — a fixed layout on a page, designed to be read by a person. E2B(R3) is a data standard — a structured electronic message, designed to be parsed by a system. Asking which to use is a bit like asking whether to use a printed invoice or a database record: it depends entirely on who or what is receiving it.
In practice most operations need both, and MedWatch 3500A as well. This guide sets out what each is for, how they relate, and where the practical traps are.
Scope of this guide
This describes general industry practice. It is not regulatory advice, and it does not tell you which format any specific authority or partner requires of you — that comes from applicable legislation, the receiving party's own requirements, and your agreements, confirmed by your qualified PV personnel.
| CIOMS I | MedWatch 3500A | E2B(R3) | |
|---|---|---|---|
| What it is | An internationally recognised paper/PDF form for reporting a single case | A US FDA form for reporting a single case | An electronic data standard for transmitting ICSRs |
| Designed to be read by | A person | A person | A system |
| Typical use | Partner and licensee exchange; some authorities and territories; attachments and documentation | US reporting contexts and documentation | Gateway submission to authorities that accept electronic ICSRs |
| Transport | Email, portal upload, or attached document | Email, portal upload, or attached document | Electronic gateway, commonly AS2 |
| Data richness | Constrained by the form layout | Constrained by the form layout | Substantially richer and more granular |
| Acknowledgement | None inherent — receipt is whatever your process arranges | None inherent | Built into the exchange, with structured error reporting |
| Machine validation | Not applicable | Not applicable | Schema and business-rule validation |
The distinction that resolves most confusion
A form is a *presentation* of case data. A data standard is a *transmission* of case data. Both are generated from the same underlying case record — so the real question is never "which one is our format", it is "which outputs must our system be able to produce, for whom".
The pattern below is typical rather than universal — confirm your own obligations per destination.
Authority gateway submission
Where an authority accepts electronic ICSRs, this is normally the required route — with acknowledgement handling and reconciliation back to the case version transmitted.
Partner and licensee exchange
Very common in safety data exchange agreements, particularly where a partner's system cannot receive E2B, or where a human-readable artefact is what the agreement specifies.
Territories without electronic submission
Some destinations still expect a form rather than a gateway transmission. This is one reason a form capability rarely becomes redundant.
US reporting contexts
The FDA's own form, used in specific reporting and documentation contexts alongside electronic submission.
Documentation and audit packs
A readable case summary is what you hand an auditor, attach to an inquiry, or include in a report appendix. XML is not a useful artefact for a person.
Because all three are generated from the same case record, they overlap heavily in content. The differences that matter are in granularity and in what cannot be expressed.
| Content area | On a form (CIOMS I / 3500A) | In E2B(R3) |
|---|---|---|
| Patient details | Free-text and small fixed fields | Structured, with defined precision and null-flavour handling |
| Suspect and concomitant products | Limited number of entries by layout | Repeating structured blocks with dose, route, dates and causality per product |
| Events | Limited entries; often summarised | Repeating structured blocks with per-event outcome, seriousness and coding |
| Narrative | Central to the form | Present, but alongside far more structured data |
| Coding | Often shown as text | Coded terms with explicit dictionary version |
| Causality | Usually one overall assessment | Per product and per event, with source of assessment distinguished |
| Case identifiers and versioning | Present but minimal | Structured, supporting follow-up, retransmission and nullification |
Do not treat a form as your system of record
The common failure is generating a CIOMS I form, sending it, and treating the form as the record of what was reported. Forms lose granularity by design. Your record of what was reported should be the case version in the safety database, with the generated form attached to it — otherwise reconciliation and later reconstruction become guesswork. See ICSR follow-up and case versioning.
- Assuming E2B replaces forms entirely. Partner agreements, some territories, and every audit conversation keep forms relevant.
- Generating forms manually. Hand-filled forms drift from the case record immediately and create two versions of the truth.
- Losing the acknowledgement discipline on form-based routes. E2B has acknowledgement built in; a form sent by email does not, so your process has to supply proof of receipt and timing.
- Forgetting that a form-based route still has a deadline. The clock does not care that the transport is manual.
- Not versioning generated forms. A follow-up produces a new form; the old one should remain attached to the version it represented.
- Overlooking data protection. Forms are often emailed, and a narrative plus patient details in an email attachment deserves the same scrutiny as any other transfer of personal data.
- Assuming a partner can receive E2B because they are large. Capability varies; confirm it in the safety data exchange agreement rather than discovering it at go-live.
Since all three artefacts derive from the same case, generating them should be a configuration and rules question rather than a manual task.
- Generate E2B(R2) and E2B(R3) per destination profile, plus CIOMS I and MedWatch 3500A outputs, from the same approved case version
- Let the reporting rules engine decide which output goes to which destination, in which format, by when — rather than relying on someone remembering
- Attach every generated artefact to the case version it was produced from, under version control
- Record the transmission event and, for gateway routes, reconcile the acknowledgement back to that case version
- Keep secure, role-based access to generated documents, since they contain patient narrative and identifiers
PVgenix generates E2B(R2) and E2B(R3) alongside CIOMS I and MedWatch 3500A form outputs from the approved case version, with the reporting rules engine resolving destination, format and deadline, generated documents attached to the case under version control, and role-based access to them. See regulatory submission.
The short version
CIOMS I and MedWatch 3500A are human-readable forms; E2B(R3) is a machine-readable data standard. They are not alternatives, and most operations need all three — E2B for gateway submission, forms for partner exchange, some territories, and every conversation involving a person. Generate all of them from the same case version, never treat a form as your record, and remember that a manual transport route still has a regulatory deadline.
Related: E2B(R2) vs E2B(R3) for the two data standard versions, E2B(R3) implementation for making it work, and expedited reporting timelines for the deadlines that apply regardless of format.
Frequently asked questions
Common questions
They are different kinds of artefact rather than competing standards. CIOMS I is a human-readable form — a fixed layout designed to be read by a person and typically sent by email, portal upload or as an attachment. E2B(R3) is a machine-readable data standard — a structured electronic message designed to be parsed by a system, transmitted over a gateway, with acknowledgement and validation built into the exchange. Both are generated from the same underlying case record.
Usually yes. Safety data exchange agreements with partners and licensees frequently specify CIOMS I, particularly where the partner's system cannot receive E2B; some territories still expect a form rather than a gateway transmission; and a readable case artefact is what you attach to an inquiry, hand to an auditor, or include in a report appendix. XML is not a useful artefact for a person, so form generation rarely becomes redundant.
MedWatch 3500A is the US FDA's own reporting form, used in specific US reporting and documentation contexts. Functionally it is the same kind of artefact as CIOMS I — a human-readable form generated from the case record — with a different layout and field set. Most operations need the ability to produce both, alongside E2B for electronic submission.
No. E2B(R3) is substantially more granular: repeating structured blocks for multiple suspect and concomitant products with per-product dose, route, dates and causality; per-event outcome, seriousness and coding with an explicit dictionary version; structured null-flavour and date-precision handling; and structured case identifiers supporting follow-up, retransmission and nullification. A form constrains content by layout, which is why a form should never be treated as your system of record.
Yes. The applicable expedited timeline attaches to the reporting obligation, not to the transport mechanism. A CIOMS I form sent by email is subject to the same clock as an E2B transmission over a gateway. Because forms carry no inherent acknowledgement, your process also has to supply evidence of receipt and timing, which a gateway route provides automatically.
By the system, from the approved case version. Manually filled forms drift from the case record immediately and create two versions of the truth, which breaks reconciliation and later reconstruction. Generated forms should be attached to the case version they were produced from, under version control and role-based access, since they contain patient narrative and identifiers.