FDA Regional Implementation Guide for E2B(R3) Electronic Transmission of Individual Case Safety Reports for Drug and Biological Products

Administrative guidance, not enacted legislation. This captured publisher edition preserves the listed document and attachments; later developments are not independently consolidated.

FDA Regional Implementation
Guide
for E2B(R3) Electronic Transmission of
Individual Case Safety Reports for Drug and
Biological Products
Guidance for Industry
Technical Specifications Document
This document is incorporated by reference into the following guidances for industry:
• 	E2B(R3) Electronic Transmission of Individual Case Safety Reports (ICSRs)
Implementation Guide –Data Elements and Message Specification
• 	Providing Submissions in Electronic Format – Postmarketing Safety Reports
• 	Postmarketing Safety Reporting for Combination Products
• 	Providing Regulatory Submissions in Electronic Format: IND Safety Reports
• 	Electronic Submission of IND Safety Reports Technical Conformance Guide
• 	Electronic Submission of Expedited Safety Reports From IND-Exempt BA/BE
Studies
For questions regarding this technical specifications document, contact
CDER at FAERSESUB@fda.hhs.gov.
U.S. Department of Health and Human Services
Food and Drug Administration
Center for Drug Evaluation and Research (CDER)
Center for Biologics Evaluation and Research (CBER)
August 2024
ICH

Revision History
Date 	Version 	Summary of Revisions
2016-06-22 	1.0 	Initial Version
2022-04-28 	2.0 	Addition of regional data elements for
premarketing, postmarketing and
combination product reporting
2022-08-15 	2.1 	Incorporated by reference into newly
published draft guidance for industry
Electronic Submission of Expedited Safety
Reports From IND-Exempt BA/BE Studies
2024-04-01 	3.0 	Editorial corrections and technical updates
2024-08-05 	3.1 	Technical updates to the attachment file
types in Section 5.9 ICSR Attachment File-
Size Limitations

Contains Nonbinding Recommendations
TABLE OF CONTENTS
1.0 	INTRODUCTION............................................................................................................. 1
2.0 	BACKGROUND ............................................................................................................... 3
3.0 	FDA REGIONAL IMPLEMENTATION OF E2B(R3) ................................................ 4
3.1 	Regional Data Elements ................................................................................................................ 4
3.2 	Use of the Display Name Data Element ....................................................................................... 4
3.3 	Technical Approach for Preparing Electronic Submissions ...................................................... 4
3.4 	Technical Approach for Incorporating Regionally Controlled Terminology .......................... 5
3.5 	Technical Approach for Adding FDA Regional Data Elements ................................................ 5
3.6 	Electronic ICSR Submissions Using the FDA ESG .................................................................... 5
3.6.1 	FDA ESG Connection Options .............................................................................................. 5
3.6.2 	FDA ESG Transaction Partners and Testing ....................................................................... 6
3.6.2.1 ESG Transaction Partners ................................................................................................ 6
3.6.2.2 ESG Testing ........................................................................................................................ 6
3.6.3 	FDA ESG Header Information.............................................................................................. 6
3.6.3.1 AS2 Headers and Routing IDs .......................................................................................... 7
3.6.4 	ICSR Acknowledgments ......................................................................................................... 7
3.6.5 	Submission Tracking .............................................................................................................. 8
3.6.6 	ESG Failure ............................................................................................................................ 8
3.6.7 	ICSR Submission Failure ...................................................................................................... 8
4.0 	FAERS FDA REGIONAL TECHNICAL SPECIFICATIONS ................................... 9
4.1 	Creating FDA ICSR Files .............................................................................................................. 9
4.1.1 	ICSR Batch and Message Wrapper Information .................................................................. 9
4.1.2 	Data Element N.1.1: Types of Messages in Batch .............................................................. 10
4.1.3 	Data Element N.1.2: Batch Number .................................................................................... 10
4.1.4 	Data Element N.1.3: Batch Sender Identifier ..................................................................... 10
4.1.5 	Data Element N.1.4: Batch Receiver Identifier................................................................... 10
4.1.6 	Data Element N.2.r.2: Message Sender Identifier .............................................................. 11
4.1.7 	Data Element N.2.r.3: Message Receiver Identifier............................................................ 11
4.2 	FDA ICSR Content ...................................................................................................................... 11
4.2.1 	Data Element Conformance................................................................................................. 11
4.2.2 	Terminology .......................................................................................................................... 12
4.2.3 	Section C.1: Identification of a Case Safety Report ............................................................ 12
4.2.3.1 Data Element C.1.7: Does this Case Fulfill the Local Criteria for an Expedited
Report? ......................................................................................................................................... 12
4.2.3.2 Linking Initial and Follow-Up ICSRs ............................................................................ 13
4.2.3.3 Correcting an Incorrect Safety Report Identifier ......................................................... 14
4.2.3.4 Data Element FDA.C.5.5a: IND Number Where AE Occurred .................................. 14
4.2.3.5 Data Element FDA.C.5.5b: Pre-ANDA Number where serious AE Occurred .......... 14
4.2.3.6 Data Element FDA.C.5.6.r: IND Number of Cross-Reported IND ............................. 14
4.2.4. 	Section D: Patient Characteristics ...................................................................................... 15
4.2.4.1 FDA Regional Data Elements ......................................................................................... 15
4.2.4.2 Data Element D.1: Patient (Name or Initials) ............................................................... 15

Contains Nonbinding Recommendations
4.2.5 	Section G.k: Drug(s) Information ....................................................................................... 16
4.2.5.1 FDA Regionally Controlled Terminology for Section G.k: Drug(s) Information ...... 16
4.2.5.2 Data Element G.K.2.1.1b: Medicinal Product Identifier (MPID) ............................... 16
4.2.5.3 Data Element G.k.2.2: Medicinal Product Name as Reported by the Primary Source
....................................................................................................................................................... 17
4.2.5.4 Data Element G.k.2.3.r.2b: Substance/Specified Substance TermID ......................... 17
4.2.5.5 Data Element G.k.3.1: Authorisation/Application Number......................................... 17
4.2.5.6 Data Element G.k.4.r.9.2b: Pharmaceutical Dose Form TermID ............................... 18
4.2.5.7 Data Element G.k.4.r.10.2b: Route of Administration TermID .................................. 18
4.2.5.8 Data Element G.k.4.r.11.2b: Parent Route of Administration TermID ..................... 18
4.2.5.9 Data Element FDA.G.k.10a.r: FDA Additional Information on Drug ....................... 19
4.2.6 	Section E.i: Reaction/Event as Reported by the Primary Source ....................................... 19
4.2.7 	Combination Product Information ...................................................................................... 19
4.3 	Submission Rules ......................................................................................................................... 21
4.4 	Forward Compatibility ................................................................................................................ 21
5.0 	GENERAL DATA COMPLETION INSTRUCTION ................................................ 21
5.1 	Required and Optional Data Elements ...................................................................................... 21
5.2 	Description in English.................................................................................................................. 22
5.3 	Date/Time Data Elements............................................................................................................ 22
5.4 	Use of Metric Units ...................................................................................................................... 22
5.5 	Version of Medical Dictionary of Regulatory Activities (MedDRA) ....................................... 22
5.6 	Standard Terminologies and Codelists ...................................................................................... 23
5.7 	Use of nullFlavors ........................................................................................................................ 23
5.8 	ICSR Attachment(s)..................................................................................................................... 23
5.9 	ICSR Attachment File-Size Limitations .................................................................................... 24

Contains Nonbinding Recommendations
1
FDA Regional Implementation Guide
for E2B(R3) Electronic Transmission of
Individual Case Safety Reports for Drug and Biological Products
Guidance for Industry
Technical Specifications Document1
This guidance represents the current thinking of the Food and Drug Administration (FDA or Agency) on
this topic. It does not establish any rights for any person and is not binding on FDA or the public. You
can use an alternative approach if it satisfies the requirements of the applicable statutes and regulations.
To discuss an alternative approach, contact the FDA office responsible for this guidance as listed on the
title page.
1.0 	INTRODUCTION
The purpose of this technical specifications document is to assist submitters transmitting
electronic individual case safety reports (ICSRs) and ICSR attachments to the FDA Adverse
Event Reporting System (FAERS) database. An ICSR is a description of an adverse experience
related to an individual patient or subject.2 FDA adopted the International Council for
Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH)
Implementation Guide (IG) for Electronic Transmission of Individual Case Safety Reports
(ICSRs): E2B(R3) Data Elements and Message Specification (ICH ICSR IG)3 in February 2014,
and published the guidance for industry E2B(R3) Electronic Transmission of Individual Case
Safety Reports: Implementation Guide — Data Elements and Message Specification (E2B(R3)
Electronic Transmission of ICSRs IG) and an appendix to the guidance entitled Appendix I (B) to
the ICH E2B(R3) ICSRs Implementation Guide — Backwards and Forwards Compatibility.4
This document describes FDA’s technical approach for submitting ICSRs, for incorporating its
regionally controlled terminology,5 and for adding FAERS regional data elements that are not
1 This technical specifications document has been prepared by the Office of Surveillance and Epidemiology in the
Center for Drug Evaluation and Research in cooperation with the Center for Biologics Evaluation and Research at
the Food and Drug Administration. For questions regarding this technical specifications document, contact CDER
at FAERSESUB@fda.hhs.gov. You may submit comments on this guidance at any time. Submit comments to
Docket No. FDA-2016-D-1280 (available at https://www.regulations.gov/search?filter=fda-2016-D-1280).
2 21 CFR 310.305(b), 314.80(a), and 600.80(a); see also 21 CFR 329.100(b).
3 See https://ich.org/page/e2br3-individual-case-safety-report-icsr-specification-and-related-files.
4 See https://www.fda.gov/regulatory-information/search-fda-guidance-documents. The Guidance for Industry
E2B(R3) Electronic Transmission of Individual Case Safety Reports: Implementation Guide — Data Elements and
Message Specification” and appendix to the guidance entitled “Appendix I (B) to the ICH E2B(R3) ICSRs
Implementation Guide — Backwards and Forwards Compatibility” were updated to incorporate technical updates
made to the ICH ICSR IG in Nov. 2016 and to the ICH Appendix I (B) to the Implementation Guide for Electronic
Transmission of Individual Case Safety Reports - Backwards and Forwards Compatibility Recommendations in
Mar. 2022.
5 Controlled terminology is a finite set of values that represent only the allowed values for a data item.

Contains Nonbinding Recommendations
2
addressed in the E2B(R3) Electronic Transmission of ICSRs IG for the following FDA-regulated
products:
• 	Drug products marketed for human use with approved new drug applications (NDAs) or
abbreviated new drug applications (ANDAs)
• 	Prescription drug products marketed for human use without approved applications,
including prescription drug products that are compounded by facilities registered as
outsourcing facilities under section 503B of the Federal Food, Drug, and Cosmetic Act
(21 U.S.C. 353b)
• 	Nonprescription drug products marketed for human use without approved NDAs or
ANDAs
• 	Biological products with approved biologics license applications (BLAs)
• 	Combination products with approved NDAs, ANDAs, or BLAs
• 	Drug and biological products studied under investigational new drug applications (INDs)
or IND-exempt bioavailability/bioequivalence (BA/BE) studies supporting ANDAs6
This document does not apply to the following:
• 	Postmarketing safety reports for vaccines7
• 	Whole blood or blood components
• 	Combination products with a drug or biological product constituent part marketed under a
device application
• 	Human cellular and tissue-based products regulated solely under section 361 of the
Public Health Service Act (42 U.S.C. 264)
ICSRs (and any ICSR attachments) should be prepared in accordance with the ICH E2B(R3) and
FDA’s regional data elements, in extensible markup language (XML)8 file format and submitted
to the FAERS database through FDA’s Electronic Submissions Gateway (ESG) (see
https://www.fda.gov/industry/electronic-submissions-gateway). Postmarketing ICSRs should
not be submitted to the electronic Common Technical Document (eCTD). ICSRs from IND
studies9 and premarket IND-exempt BA/BE studies10 should be submitted as per the published
guidance. Agency information about electronic submissions will be periodically updated to
reflect the evolving nature of the technology and the experiences of those using this technology.
6 These types of reports will be referred to as premarketing reports in this document.
7 Electronic submission of postmarketing safety reports for vaccines is addressed in the FDA’s Guidance for
Industry: Providing Submissions in Electronic Format—Postmarketing Safety Reports for Vaccines (Aug. 2015).
We update guidances periodically. For the most recent version of a guidance, check the FDA guidance web page at
https://www.fda.gov/regulatory-information/search-fda-guidance-documents.
8 XML is a markup language that defines a set of rules for encoding documents in a format that is both human- and
machine-readable.
9 See the guidance for industry Electronic Submission of IND Safety Reports Technical Conformance Guide (Apr.
2022); guidance for industry Providing Regulatory Submissions in Electronic Format: IND Safety Reports (Apr.
2024).
10 See the guidance for industry Electronic Submission of Expedited Safety Reports From IND-Exempt BA/BE
Studies (Apr. 2024).

Contains Nonbinding Recommendations
3
In general, FDA’s guidance documents do not establish legally enforceable responsibilities.
Instead, guidances describe the Agency’s current thinking on a topic and should be viewed only
as recommendations, unless specific regulatory or statutory requirements are cited. The use of
the word should in Agency guidances means that something is suggested or recommended, but
not required.
2.0 	BACKGROUND
The ICH E2B Expert Working Group released the revised ICH ICSR IG to standardize the
definitions of the data elements used in the electronic transmission of different types of ICSRs,
regardless of source and destination. The revised guideline describes the harmonized core set of
ICH E2B(R3) data elements, ICH business rules, and other technical specifications for creating
ICH-compliant XML files for ICSR data exchange which were adopted by FDA.
Regional data elements are considered non-harmonized; however, the ICH XML file structure
allows regions to use regionally controlled terminology and to add region-specific elements as
outlined in this document.
In addition to the regional specifications described in this document and the FDA E2B(R3) Core
and Regional Data Elements and Business Rules document, available on FAERS Electronic
Submissions – E2B(R3) Standards web page (see https://www.fda.gov/drugs/questions-and-
answers-fdas-adverse-event-reporting-system-faers/fda-adverse-event-reporting-system-faers-
electronic-submissions-e2br3-standards), FDA supports use of all the ICH E2B(R3) data
elements and recommends that stakeholders refer to other relevant technical documents to help
create compliant ICSR files, such as the following:
• 	The E2B(R3) Electronic Transmission of ICSRs IG provides technical and business
specifications for the harmonized, core set of ICH data elements.
• 	FDA’s guidance for industry Appendix I (B) to the ICH E2B(R3) ICSRs Implementation
Guide - Backwards and Forwards Compatibility supplements the E2B(R3) Electronic
Transmission of ICSRs IG, and assists reporters and recipients in implementing systems
with a special focus on the recommendations for conversion between the previous
standard (ICH E2B(R2)) and this standard (ICH E2B(R3)).
• 	The FAERS Electronic Submissions – E2B(R3) Standards web page (see
https://www.fda.gov/drugs/questions-and-answers-fdas-adverse-event-reporting-system-
faers/fda-adverse-event-reporting-system-faers-electronic-submissions-e2br3-standards)
provides web links to the technical documents and examples for accommodating FDA
regional data elements, forward compatibility, and ICH file validation rules to support
automated XML file validation and a sample FDA instance file.
FDA technical specifications relevant to ICH E2B(R3) adoption and implementation will be
updated periodically to reflect the Agency’s progress and ability to receive E2B(R3) formatted
submissions; these updates will be published on FDA web pages. Stakeholders interested in
submitting ICSRs to FAERS in E2B(R3) format should contact the FAERS electronic

Contains Nonbinding Recommendations
4
submissions coordinator (via email at FAERSESUB@fda.hhs.gov) for more information about
specific program adoption, testing, and implementation timelines or refer to the FAERS
Electronic Submissions web page (see https://www.fda.gov/drugs/questions-and-answers-fdas-
adverse-event-reporting-system-faers/fda-adverse-event-reporting-system-faers-electronic-
submissions-e2br3-standards).
3.0 	FDA REGIONAL IMPLEMENTATION OF E2B(R3)
FDA recognizes the need to support both the current and previous versions of ICH E2B
standards and will continue to provide support for ICH E2B(R2) for postmarketing reports.
Information about FAERS E2B(R3) validation is available on the FAERS Electronic
Submissions – E2B(R3) Standards web page (see https://www.fda.gov/drugs/questions-and-
answers-fdas-adverse-event-reporting-system-faers/fda-adverse-event-reporting-system-faers-
electronic-submissions-e2br3-standards).
3.1 	Regional Data Elements
The use of the term regional extension in this document refers to FDA data elements and
terminologies supported in the ICSR file in addition to the ICH E2B (R3) data elements. FDA
regional extensions for ICSRs are specific to premarketing and postmarketing safety
surveillance. These FDA regional extensions help support Agency efforts to improve overall
ICSR data quality and support other Department of Health and Human Services (HHS) public
health initiatives.
3.2 	Use of the Display Name Data Element
FDA has implemented and recommends the use of the XML data element name as the
displayName listed in the FDA E2B(R3) Core and Regional Data Elements and Business Rules
document to facilitate human and computer system identification and understanding of coded
regional data elements in the ICSR file. The example below demonstrates how display name is
used:
EXAMPLE:
<subjectOf2 typeCode="SBJ">
<observation classCode="OBS" moodCode="EVN">
<code code="C16564" displayName="Patient Ethnicity Code"
codeSystem="2.16.840.1.113883.3.26.1.1"/>
3.3 	Technical Approach for Preparing Electronic Submissions
FDA regional specifications comply with ICH E2B(R3) conformance criteria. Use of the term
conformance in this document refers to data element definitions, formats, and use (e.g., required
or optional) as specified by the ISO/HL7 27953-2:2011 standard and in accordance with the
content specifications described in the E2B(R3) Electronic Transmission of ICSRs IG. Regional
specifications for submitting ICSRs are defined in section 3.6 (Electronic ICSR Submissions
Using the FDA ESG).

Contains Nonbinding Recommendations
5
3.4 	Technical Approach for Incorporating Regionally Controlled Terminology
Where applicable, ICH elements accept regionally controlled terminology without compromising
ICH E2B(R3) conformance criteria. Regional implementation includes incorporating regionally
controlled terminology drawn from the National Cancer Institute (NCI) Enterprise Vocabulary
Services (EVS) code set (namespace) 2.16.840.1.113883.3.26.1.1.11
FDA’s regionally controlled terminology is described in section 4.2.2. (Terminology) of this
document; specifications are provided in section 4.2.5.1 (FDA Regionally Controlled
Terminology for Section G.k (Drug(s) Information)) of this document.
3.5 	Technical Approach for Adding FDA Regional Data Elements
FDA incorporates the collection of regional data to help improve overall ICSR data quality and
support other FDA safety initiatives. The data are accommodated in the ICSR file using the
XML schema attributes supported. FDA uses the XML observation attribute to provide details
and the characteristic attribute to provide descriptions about the subject. Specifications for
regional observation data are provided in section 4.2.4.1 (FDA Regional Data Elements) of this
document and FDA E2B(R3) Core and Regional Data Elements and Business Rules document.
3.6 	Electronic ICSR Submissions Using the FDA ESG
3.6.1 	FDA ESG Connection Options
Connections to the FDA ESG are supported through a direct gateway-to-gateway or web-based
communications interface that uses Hyper Text Transfer Protocol Secure (HTTPS) for
transmission according to Applicability Statement 2 (AS2) standards. Information about FDA
ESG connection options can be found in the FDA ESG User Guide (see
https://www.fda.gov/industry/about-esg/user-guide).
The current exchange of ICSRs with FDA is a one-way inbound file transaction between the
ICSR sender organization and the FDA ESG. The FDA ESG supports the receipt of electronic
regulatory submission of files up to 100 gigabytes (GB) in size.
Senders should follow FDA guidance for file compression in the ESG User Guide Appendix B:
Creating .tar Files and Compressing Files for Submission (see
https://www.fda.gov/industry/about-esg/esg-appendix-b-creating-tar-files-and-compressing-files-
submission).
11 Information about the NCI EVS is available on the NCI web page at: http://evs.nci.nih.gov/.

Contains Nonbinding Recommendations
6
3.6.2 	FDA ESG Transaction Partners and Testing
3.6.2.1 ESG Transaction Partners
To submit files electronically to FDA, organizations should apply for a Transaction Partner
account. Account requests should include the organization’s digital certificate information and
be submitted to the ESG Help Desk via email at ESGHelpDesk@fda.hhs.gov. For more
information about digital certificate specifications, refer to the ESG User Guide Appendix C:
Digital Certificates (see https://www.fda.gov/industry/about-esg/esg-appendix-c-digital-
certificates). Upon approval by the FDA ESG Administrator, organizations can initiate
communication testing with ESG.
3.6.2.2 ESG Testing
Senders should complete two levels of testing: (1) to establish a successful Transaction Partner
account and (2) to confirm the senders’ ability to generate ICSR files per the technical
specifications and accepted by FAERS. To test connectivity, senders should submit all ICSR
connectivity test submissions to the appropriate Center’s "GW_TEST CONNECTION” account
using the submission type "CONNECTION TEST,” not to the Center’s production account.
• 	For more information about ESG connectivity testing, email
ESGHelpDesk@fda.hhs.gov.
• 	For more information about FAERS testing, email FAERSESUB@fda.hhs.gov.
3.6.3 	FDA ESG Header Information
For an adverse event associated with a marketed drug evaluated under an IND that meets IND
and postmarketing safety reporting requirements, the sponsor should submit two separate ICSRs
to FAERS. A separate submission pathway for submitting IND safety reports to FAERS has
been established to keep premarketing and postmarketing reports separate in the FAERS
database. Similarly, for adverse events that occur with a marketed vaccine evaluated under an
IND that meet IND and postmarketing safety reporting requirements, the sponsor should submit
two separate ICSRs: one to the Vaccine Adverse Event Reporting System (VAERS) for the BLA
and one to FAERS for the IND.12
When exchanging ICSRs with the FDA ESG, senders must use one of the FAERS gateway
headers described in Table 1 to ensure that the submissions are routed to the targeted receiving
system.
12 Technical specifications to electronically submit postmarketing safety reports for vaccines are available at
https://www.fda.gov/industry/about-esg/cber-vaccine-icsr-implementation.

Contains Nonbinding Recommendations
7
3.6.3.1 AS2 Headers and Routing IDs
For safety report submissions, the sponsors should include the unique AS2 headers or routing
IDs for ICSRs in one of the two ways listed in Table 1 to differentiate premarketing from
postmarketing safety reports.
Table 1. AS2 Headers and Routing IDs
AS2
Headers/
Routing
IDs
Postmarketing
reports
Premarketing reports
for CDER
Premarketing reports
for CBER
AS2
Headers
Destination: CDER
XML files: AERS
Destination: CDER
XML files:
AERS_PREMKT_CDER
Destination: CBER
XML files:
AERS_PREMKT_CBER
Routing
IDs
XML files:
FDA_AERS
WebTrader Accounts:
CDER AERS
AS2 Accounts:
FDA_AERS
XML files:
FDA_AERS_PREMKT_
CDER
XML files:
FDA_AERS_PREMKT_
CBER
3.6.4 	ICSR Acknowledgments
FAERS implemented two acknowledgements (ACKs) described in Table 2.
Table 2. FDA Acknowledgments
ACK# 	Description 	Use
ACK1 	FDA Message Delivery
Notification (MDN)
Notifies the sender that the submission was successfully
received in the ESG and is being processed. It also
provides the official FDA receipt date but does not imply
FDA acceptance of the submission. For more information
about FDA receipt dates, refer to FDA’s guidance for
industry Providing Regulatory Submissions in Electronic
Format--Receipt Date (Feb. 2014).

Contains Nonbinding Recommendations
8
ACK# 	Description 	Use
ACK2 	FAERS Review
Acceptance/Rejection
Notifies the sender that the FAERS system processed the
submission and either accepted or rejected all or part of
the submission. The notification provides codes indicating
validation errors.
Review Acceptance/Rejection means:
1. Acceptance: The ICSR file meets FAERS ICSR
file validation specifications without requiring
correction and resubmission.
2. Rejection: Failure to meet FAERS ICSR file
validation may result in the need to correct and
resubmit ICSR files.
Note: FAERS ICSR file validation is consistent with the
ICSR file validation provided in the document FDA
E2B(R3) Core and Regional Data Elements and Business
Rules.
3.6.5 	Submission Tracking
For more information about FDA submissions tracking, refer to Chapter 4.7, “Tracking
Submissions,” on the ESG User Guide web page (see https://www.fda.gov/industry/about-
esg/user-guide).
3.6.6 	ESG Failure
If an ACK1 is not received within 24 hours, confirm system status through the ESG Planned
Maintenance and Status History web page (see https://www.fda.gov/industry/about-esg/planned-
maintenance-and-status-history). This web page provides ESG status information, such as
operational status, downtime history, submission statistics, and links to other ESG-related topics.
If the ESG System Status web page is non-operational, go to the ESG home page (see
https://www.fda.gov/industry/electronic-submissions-gateway) for information on whom to
contact.
3.6.7 	ICSR Submission Failure
1. 	If an ACK2 acknowledgement is not received within 24 hours of
receiving the ACK1 ESG message delivery notice of
acknowledgement, resubmit the original ICSR submission
without changing the batch identifier.
2. 	If an FDA ACK2 response is received for an unsuccessful (failed)
ICSR submission, please refer to the following instructions:

Contains Nonbinding Recommendations
9
a. 	For a single ICSR submission, resubmit the corrected ICSR with
a new unique batch identifier. Refer to Section 4.1.3 (Batch
Number N.1.2) of this document for more information about
ICSR batch identifiers.
b. 	For ICSR submissions containing multiple ICSR files (batch
submissions), and one or more ICSRs in the submission failed to
process, do the following:
• 	Separate the failed ICSRs from the successfully submitted
ICSRs
• 	Correct the failed ICSRs
• 	Resubmit them as a new submission with a unique batch
identifier
For example, if there were 50 ICSRs in an original batch
submission and 15 of them failed to process, then correct
and resubmit the failed 15 ICSRs ONLY. The failed
ICSRs should be submitted with a new unique batch
identifier. The resubmission should not contain any of the
successfully processed ICSRs.
4.0 	FAERS FDA REGIONAL TECHNICAL SPECIFICATIONS
4.1 	Creating FDA ICSR Files
Refer to the FDA E2B(R3) Core and Regional Data Elements and Business Rules document for
all core ICH and regional extension to create ICSR files. Additionally, the XML schema
examples and more information about the following procedures for populating ICSR data
elements are available on the FAERS Electronic Submissions web page (see
https://www.fda.gov/drugs/questions-and-answers-fdas-adverse-event-reporting-system-
faers/fda-adverse-event-reporting-system-faers-electronic-submissions).
4.1.1 	ICSR Batch and Message Wrapper Information
Individual and batch ICSR files are supported using the HL7 batch message wrapper and the
message interaction identifier MCCI_IN200100UV01. Below is a snippet of the batch message
wrapper to be used:
<MCCI_IN200100UV01 xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ITSVersion="XML_1.0"
xsi:schemaLocation="urn:hl7-org:v3
https://www.accessdata.fda.gov/icsr/schema/cvm/schemas/vich/multicacheschemas/MCCI_IN20
0100UV01.xsd">

Contains Nonbinding Recommendations
10
ICSR sender and receiver information is captured in the batch wrapper using specific data
elements to distinguish ICSR sender and receiver information. Because this information is
provided in the batch wrapper, the Generic Message Transmission Wrapper is not used. For
more information about HL7 Batch and Generic Message Transmission wrappers, refer to the
Transmission Infrastructure topic in the ISO/HL7 27953-2:2011 standard.
4.1.2 	Data Element N.1.1: Types of Messages in Batch
E2B(R3) uses one ICSR message type, which is characterized by the HL7 message interaction
IDPORR_IN049016UV. FDA does not support additional HL7 interaction identifiers or
message types for Follow Up or Withdrawn ICSRs described in the ISO/HL7 27952-2 standard.
FDA accepts only the value of “1” (ichicsr) for data element N.1.1, Types of Messages in Batch.
4.1.3 	Data Element N.1.2: Batch Number
Each electronic submission of ICSRs must have a stakeholder-unique batch identifier (filename
or number). Organizations may choose their own format to maintain uniqueness. For more
information about the use of the ICSR batch number in ICSR acknowledgements, refer to
Section 4.0 of the E2B(R3) Electronic Transmission of ICSRs IG (The ICSR Acknowledgment
Transaction).
4.1.4 	Data Element N.1.3: Batch Sender Identifier
Senders should use the Data Universal Numbering System (DUNS) number for data element
N.1.3 using the Dun and Bradstreet (D&B) Object Identifier 1.3.6.1.4.1.519.1. The DUNS
number for Business Entity Identifiers is used to validate business entities in various FDA
information systems. For more information about how to obtain a DUNS number, refer to the
FDA Business Entity Identifiers web page (see https://www.fda.gov/industry/structured-product-
labeling-resources/business-entity-identifiers).
4.1.5 	Data Element N.1.4: Batch Receiver Identifier
FAERS uses two different batch receiver identifiers for test and production submissions. These
identifiers are:
• 	For Test Postmarketing ICSR Submissions: ZZFDATST
• 	For Test Premarketing ICSR Submissions: ZZFDATST_PREMKT
• 	For Production Postmarketing ICSR Submissions: ZZFDA
• 	For Production Premarketing ICSR Submissions: ZZFDA_PREMKT
Refer to section 3.6 (Electronic ICSR Submissions Using the FDA ESG) of this document for
more information about FDA ESG connection options and testing specifications.

Contains Nonbinding Recommendations
11
4.1.6 	Data Element N.2.r.2: Message Sender Identifier
Senders should receive FDA approval of their Message Sender Identifier before beginning
FAERS Submissions. The Message Sender Identifier can be the DUNS Number (9 Digit
Identifier using the DUNS OID 1.3.6.1.4.1.519.1) or other Identifier with FDA approval.
4.1.7 	Data Element N.2.r.3: Message Receiver Identifier
These identifiers must correspond to the FDA ESG connection (e.g., WebTrader or AS2 B2B)
used to send the ICSR submission to FAERS.
• 	CDER/CBER Postmarketing ICSR: CDER
• 	CDER IND ICSR: CDER_IND
• 	CDER IND-exempt BA/BE ICSR: CDER_IND_EXEMPT_BA_BE
• 	CBER IND ICSR: CBER_IND
For all postmarketing ICSRs, Message Receiver Identifier (data element N.2.r.3) = CDER, the
Batch Receiver Identifier (data element N.1.4) must be “ZZFDA”.
For all premarketing ICSRs, Message Receiver Identifier (data element N.2.r.3) = CDER_IND or
CBER_IND or CDER_IND_EXEMPT_BA_BE, the Batch Receiver Identifier (data element
N.1.4) must be "ZZFDA_PREMKT".
4.2 	FDA ICSR Content
4.2.1 	Data Element Conformance
FDA has described data element conformance categories (e.g., required or optional) in the
E2B(R3) Electronic Transmission of ICSRs IG. FDA data element conformance may vary from
the ICH ICSR IG due to regional regulatory specifications, and these variations are noted in the
FDA E2B(R3) Core Data Elements and Business Rules document.
The conformance for data elements can be “Required”, “Conditional-Required” or “Optional”.
Absence of required data elements will result in a negative acknowledgment and be rejected.
HL7 nullFlavor codes are used to explain the reason for the lack of data on required elements
and must be used for specific required data elements as defined if the data values are blank.
The business rules defined for a data element are listed under the tab “Rejection and Warning
Rules” in the FDA E2B(R3) Core Data Elements and Business Rules document. Some business
rules can result in a negative acknowledgement and not be accepted by FAERS whereas others
can result in a positive acknowledgement with warning message and will be accepted by
FAERS. A list of business rules that will generate a rejection or a warning is included in the
document FDA E2B(R3) Core and Regional Data Elements and Business Rules.

Contains Nonbinding Recommendations
12
4.2.2 	Terminology
FDA supports the recommendations of the ICH E2B(R3) concerning use of the terminology
found in the Medical Dictionary for Regulatory Activities (MedDRA)13 for coding of clinical
and laboratory terms. When possible, use the Lowest Level Term (LLT) and record the LLT as
the MedDRA numeric code rather than the LLT name (e.g., the LLT name is Rash; the MedDRA
numeric code for LLT Rash is 10378444). Stakeholders should refer to the E2B(R3) Electronic
Transmission of ICSRs IG for data elements that specify the use of MedDRA coding.
FDA supports the use of constrained Unified Codes for Units of Measurement (UCUM) (see
http://www.fda.gov/ForIndustry/DataStandards/StructuredProductLabeling/ucm168397.htm) for
coding units of measure (e.g., medication dosing units), ICH E2B(R3) ICSR code lists, and
European Directorate for the Quality of Medicines (EDQM) (see
https://www.edqm.eu/sites/default/files/standard_terms_introduction_and_guidance_for_use.pdf)
for dosage form and route of administration.14, 15 FDA regional terminology supports the
controlled terminology of NCI’s Enterprise Vocabulary Services (EVS), the Device Product
Code (“ProCode”) (see
https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/classification.cfm) for the device
constituent part of the combination product (e.g., the syringe component of a drug supplied in a
pre-filled syringe), Device Problem Code (see https://www.fda.gov/media/146825/download),
and internal Substance Registration System (SRS) (see https://www.fda.gov/industry/fda-data-
standards-advisory-board/fdas-global-substance-registration-system).16 ICH elements that use
FDA-controlled terminologies are noted and defined in the relevant sections of this document.
4.2.3 	Section C.1: Identification of a Case Safety Report
4.2.3.1 Data Element C.1.7: Does this Case Fulfill the Local Criteria
for an Expedited Report?
The E2B(R3) Electronic Transmission of ICSRs IG describes conformance criteria for data
element C.1.7, Does this Case Fulfill the Local Criteria for an Expedited Report?, to specify
whether the case fulfills regional specifications for expedited reporting. FDA does not support
use of the HL7 nullFlavor code NI (No Information) for this data element in initial submissions.
Initial submissions with HL7 nullFlavor code NI will be rejected. Subsequent submissions for
ICSRs already received by FDA will default to the initially submitted value.
The E2B(R3) Electronic Transmission of ICSRs IG describes values allowed for data element
C.1.7: “true, “false”, or the HL7 nullFlavor code NI. FAERS ICSRs that meet the FDA reporting
criteria for 7-day reports, 15-day reports or 5-day reports are considered expedited reports, and a
13 Companies can license MedDRA from the international maintenance and support services organization (MSSO).
14 The complete UCUM value set can be downloaded from the Regenstrief Institute web page at:
http://unitsofmeasure.org/trac/.
15 Refer to Use of EDQM terminologies for Dose Forms and Routes of Administration for Individual
Case Safety Reports in E2B(R3) message in the E2B(R3) Electronic Transmission of ICSRs.
16 SRS files are available for download at: https://gsrs.ncats.nih.gov/#/release. The regional Substance/Specified
Substance TermID Version Date/Number (G.k.2.3.r.2a) is the date and time of the modified file downloaded from
the FDA web page. Questions concerning these identifiers should be addressed to fda-srs@fda.hhs.gov.

Contains Nonbinding Recommendations
13
value of “true” should be applied for data element C.1.7. FDA has also applied a regional rule
necessitating a coded response for data element FDA.C.1.7.1, Local Criteria Report Type which
specifies the type of expedited or non-expedited report.
For postmarketing ICSRs, data element C.1.7.1, Local Criteria Report Type, is dependent on the
selections made on data element FDA.C.1.12, Combination Product Report Indicator, and data
element C.1.7, Does this Case Fulfill the Local Criteria for an Expedited Report? If data
element FDA.C.1.12, Combination Product Report Indicator, is “Yes” and the case is an
Expedited Report, then data element FDA.C.1.7.1, Local Criteria Report Type, value options are
“5-Day” (4) or “15-Day” (1). If the data element C.1.12, Combination Product Report Indicator,
is ‘Yes’ and the case is not an Expedited Report, then data element C.1.7.1, Local Criteria
Report Type, value options are “Non-Expedited Adverse Event (AE)” (2) or “30-Day” (5). If a
postmarketing ICSR is not a combination product report and it is expedited, then the data
element C.1.7.1, Local Criteria Report Type, is “15-Day” (1); if it is not expedited, then the
Local Criteria Report Type is “Non-Expedited Adverse Event” (2).
For a premarketing ICSR (IND and/or IND-exempt BA/BE safety report), if data element C.1.7
is “true” then the Local Criteria Report Type value options are “7-Day” or “15-Day”.
4.2.3.2 Linking Initial and Follow-Up ICSRs
If the initial ICSR was submitted on paper but its follow-up ICSR will be submitted
electronically, include the data element C.1.1, Sender’s (case) Safety Report Unique Identifier,
from the initial report in both data elements C.1.1 and C.1.8.1, Worldwide Unique Case
Identification, in the follow-up electronic submission.
Note that the Sender’s (case) Safety Report Unique Identifier is also referred to as the
Manufacturer Control Number17 (MCN) listed in Box G.9. (Manufacturer Report Number) of
Form FDA 3500A.
Always use the same identifier for data element C.1.1 that was assigned to the initial ICSR when
submitting follow-up reports for the lifecycle of a case. If the internal Safety Report Unique
Identifier is provided, note the internally reassigned safety report ID in the ICSR narrative
Section H.1 of the follow-up report (e.g., This ICSR has been reassigned the Company ID
number COA12345). Do not use the internally reassigned safety report ID for any follow-up
reports.
Refer to the FAERS Electronic Submissions web page (see
https://www.fda.gov/drugs/questions-and-answers-fdas-adverse-event-reporting-system-
faers/fda-adverse-event-reporting-system-faers-electronic-submissions) for XML schema
examples of correctly populating the ICH C.1.1 data element.
17 The MCN should be a concatenation of three segments separated by a hyphen: “country code-company or
regulator name-report number.” The country code is the two-letter ISO 3166 part 1code (ISO 3166-1 alpha-2)
corresponding to the country of the primary source of the report (C.2.r.3).

Contains Nonbinding Recommendations
14
4.2.3.3 Correcting an Incorrect Safety Report Identifier
In the event that an incorrect safety report ID has been used in a follow-up report, contact the
FAERS Electronic Submissions Coordinator at FAERSESUB@fda.hhs.gov.
4.2.3.4 Data Element FDA.C.5.5a: IND Number Where AE Occurred
This is a required data element for IND safety reports. This element describes the “primary”
IND which is the IND number under which the clinical trial where the event occurred is
conducted. Use the “parent” IND number18 in this field for reports submitted from an Aggregate
Analysis as per § 312.32(c)(1)(i)(C)) (21 CFR 312.32(c)(1)(i)(C)) or for several events submitted
as per § 312.32(c)(1)(i)(B), from trials conducted under more than one IND.
4.2.3.5 Data Element FDA.C.5.5b: Pre-ANDA Number where serious
AE Occurred
The E2B format is an acceptable form of notification to the FDA for a serious adverse event(s)
required under 21 CFR 320.31(d)(3). This is a technical requirement to voluntarily submit the
IND-exempt BA/BE study safety reports in the electronic E2B format. This data element
describes the pre-assigned ANDA (referred to as the acronym “Pre-ANDA”) number19 obtained
by a company that plans to electronically submit serious adverse event reports from a
premarketing IND-exempt BA/BE study. For instructions on requesting a Pre-ANDA number,
navigate to https://www.fda.gov/drugs/electronic-regulatory-submission-and-review/requesting-
pre-assigned-application-number.
4.2.3.6 Data Element FDA.C.5.6.r: IND Number of Cross-Reported
IND
This is a required data element for IND safety reports. This element describes cross-reported
INDs, which are relevant INDs to which the sponsor should also submit the IND safety report.20
This element is repeatable and the relevant IND numbers should be individually listed in separate
data fields. If there are no cross-reported INDs, then an HL7 nullFlavor code NA (Not
Applicable) code should be populated in this field.
18 The “parent” IND is the IND under which clinical trials were first initiated in the United States. If the drug is
being evaluated in multiple INDs, the parent IND is generally the IND with the lowest number.
19 Although these are pre-assigned ANDA numbers and the term “Pre-ANDA” is being used with these numbers,
each submission may or may not be associated with the Office of Generic Drug’s Pre-ANDA Program for complex
drug products. See https://www.fda.gov/drugs/generic-drugs/pre-anda-program.
20 As discussed in FDA’s guidance for industry and investigators Safety Reporting Requirements for INDs and
BA/BE Studies (Dec. 2012), IND safety reports should be submitted to all the sponsor’s INDs under which the drug
is being administered.

Contains Nonbinding Recommendations
15
4.2.4. 	Section D: Patient Characteristics
4.2.4.1 FDA Regional Data Elements
If patient race and ethnic group observations are available, use the codes listed in the document
FDA E2B(R3) Core and Regional Data Elements and Business Rules. If patient race or ethnic
group information is unknown or not available, use HL7 nullFlavor code NI for these elements.
Validation information and example XML coding is available on the FAERS Electronic
Submissions web page (see https://www.fda.gov/drugs/questions-and-answers-fdas-adverse-
event-reporting-system-faers/fda-adverse-event-reporting-system-faers-electronic-submissions).
a. Data element FDA.D.11.r.1 – Patient Race Code: senders may submit multiple
observation codes for patient race (see FDA E2B(R3) Core and Regional Data
Elements and Business Rules document)
b. Data element FDA.D.12 – Patient Ethnicity Code: senders may submit only
one observation code for patient ethnic group (see FDA E2B(R3) Core and
Regional Data Elements and Business Rules document)
4.2.4.2 Data Element D.1: Patient (Name or Initials)
At least one of the available data elements in the E2B(R3) Electronic Transmission of ICSRs IG
section D (Patient Characteristics) needs to be populated to help fulfill reporting criteria for an
identifiable patient. If the patient is not the primary source reporter and other available data
elements (e.g., age, date of birth, or sex) are unknown, then the HL7 nullFlavor codes NI or
ASKU (Asked But Unknown) can be used. When the patient information is not provided due to
regional privacy restrictions (e.g., foreign reports), FDA supports the use of the HL7 nullFlavor
code MSK (Masked).
For reports from outsourcing facilities or for medication error reports, use HL7 nullFlavor code
NA where no patient is involved.21
For postmarketing combination product ICSR, if a single report is reported for a malfunction
without an adverse event, the data element value for Patient (name or initials) should be
nullFlavor NA.
For postmarketing combination product ICSR, if there are multiple malfunction reports with no
adverse event, then the data element value for Patient (name or initials) should be
“SUMMARY”.
For premarketing aggregate report, the element value must be “AGGREGATE.” If data element
C.1.10.r, Identification Number of the Report Which Is Linked to This Report, is populated, then
data element D.1, Patient (name or initials), should have the value “AGGREGATE.”
21 See FDA’s guidance for industry Adverse Event Reporting for Outsourcing Facilities Under Section 503B of the
Federal Food, Drug, and Cosmetic Act (Oct. 2015).

Contains Nonbinding Recommendations
16
4.2.5 	Section G.k: Drug(s) Information
ICH supports harmonization of medicinal product information and provides input to the
ISO/Technical Committee (TC) Health Informatics workgroups, and the Pharmacy and Medicine
Business, and the ICH ICSR IG through its Multidisciplinary Expert Working Group 5 (M5).22
Identification of Medicinal Product (IDMP) standards are designed to facilitate the exchange and
practical use of medicinal product data by regulators, pharmaceutical industry workers, and
healthcare providers. ICH E2B(R3) references the use of a constrained set of M5-controlled
terminologies in section G.K as optional data elements.
ISO IDMP is a suite of five standards to uniquely and unambiguously identify and describe
medicinal product, pharmaceutical product, and substance. FDA intends to update this document
to address the ISO IDMP standards, when available, for ICSR reporting and support the use of
regionally controlled terminology for data elements in this section. The suite of related ISO
IDMP standards is summarized below, and information about these standards is available on the
ISO/TC 215 web page (see https://www.iso.org/committee/54960/x/catalogue/).
4.2.5.1 FDA Regionally Controlled Terminology for Section G.k: Drug(s)
Information
FDA currently uses regional controlled terminologies to support ISO IDMP Standards. The
FDA regionally controlled terminologies are defined in Section G.k, Drug(s) Information, to
support use of FDA regional product identifiers and FDA specialized product categories:
• 	Medicinal Product Identifier (MPID) (ISO 11615:2012)
• 	Medicinal Product Name as Reported by the Primary Source
• 	Substance/Specified Substance TermID (ISO 11238:2012)
• 	Authorization/Application Number
• 	Pharmaceutical Dosage Form TermID (ISO 11239:2012)
• 	FDA Additional Information on Drug
• 	FDA Specialized Product Category
4.2.5.2 Data Element G.K.2.1.1b: Medicinal Product Identifier (MPID)
The FDA National Drug Code (NDC), when known, should be used as the regional MPID.23 If
the NDC or MPID is unknown, please refer to the E2B(R3) Electronic Transmission of ICSRs
IG. Information about obtaining a list of the NDCs can be found on the NDC Structured Product
Labeling Data Elements ("NDSE") web page (see https://www.fda.gov/industry/structured-
product-labeling-resources/nsde).
22 The maintenance and use of ICH M5-controlled terminology was integrated into the E2B Implementation
Working Group work plan per decisions undertaken by the ICH Steering Committee during a Jun. 2013 meeting in
Brussels.
23 The full three segments of the NDC are technically referred to as Packaged Medicinal Product Identifier (PCID)
per ISO 11615. Reporters can use either only the first two segments of the NDC or the full NDC as regional MPID
in ICSR reporting to FDA.

Contains Nonbinding Recommendations
17
4.2.5.3 Data Element G.k.2.2: Medicinal Product Name as Reported by the
Primary Source
FDA validates Medicinal Product Names for products marketed in the United States against the
available Structured Product Labeling (SPL)24 XML file or the label that was submitted with the
ICSR as an attachment. When the product has an SPL file, use the same naming convention in
the ICSR as the name appears in the SPL file. When submitting a product label as an attachment
to an ICSR, use the name as it appears on the submitted product label.
If the Medicinal Product Name is not available but the active substance name is known, provide
the active substance as it appears in the FDA SRS Unique Ingredient Identifiers (UNII) (see
https://precision.fda.gov/uniisearch) list using the free text data element G.k.2.3.r.1,
Substance/Specified Substance Name, and populate data element G.k.2.2, Medicinal Product
Name as Reported by the Primary Source, with the known active substance name.
If data element G.k.2.2, Medicinal Product Name as Reported by the Primary Source, is a
foreign product trade name, provide the active substance name as it appears in the FDA SRS
UNII list using the free text data element G.k.2.3.r.1, Substance/Specified Substance Name.
Additionally, provide the foreign product trade name in data element G.k.2.2.
4.2.5.4 Data Element G.k.2.3.r.2b: Substance/Specified Substance TermID
The FDA SRS UNII list should be used to populate data element G.k.2.3.r.2b:
Substance/Specified Substance TermID and data element G.k.2.3.r.1: Substance/Specified
Substance Name using the UNII Code and the substance name, respectively.
FDA recommends that applicants proactively validate substance information with primary source
reporters before preparing the ICSR submission. FDA UNII codes are updated monthly and may
be obtained from the FDA SRS UNII list.
4.2.5.5 Data Element G.k.3.1: Authorisation/Application Number
FDA requires the use of a prefix to determine the application type associated with products. For
example, for human drug products, include the acronym “NDA” or “ANDA” immediately
followed by the application number with no spaces (e.g., NDA123456, ANDA012345). Table 3
describes format specifications for FDA application numbers and exceptions such as marketed
unapproved prescription drug products (use 000000), marketed unapproved nonprescription drug
products (use 999999), and compounded products (use COMP99).
24 SPL is a document markup standard approved by HL7 and adopted by FDA as a mechanism for exchanging
product and facility information. The list of FDA SPL dosage forms is available at:
https://www.fda.gov/industry/structured-product-labeling-resources/dosage-forms.

Contains Nonbinding Recommendations
18
Table 3. FDA Product and Format Specifications
Product Type 	FDA Application Type* 	Recommended Format
Human drug product 	NDA/ANDA 	NDA123456 or
ANDA012345
Biological product 	BLA 	BLA123456
Prescription drug products marketed
without an approved application
Rx No Application 	000000
Non-prescription drug product marketed
without an approved application
Non-Rx No Application 	999999
Compounded product marketed 	Compounded Product 	COMP99
* For IND and IND-exempt BA/BE safety reports that are reporting on marketed drug products and biological products
being evaluated under an IND or IND-exempt BA/BE, do not place the IND or pre-ANDA number in this field,
respectively. Use data element FDA.C.5.5a: IND Number Where AE Occurred and FDA.C.5.5b: Pre-ANDA Number
Where AE Occurred for IND and IND-exempt BA/BE, respectively.
Procedures and examples for capturing FDA application numbers in the XML file are
provided on the FAERS Electronic Submissions web page (see
https://www.fda.gov/drugs/questions-and-answers-fdas-adverse-event-reporting-system-
faers/fda-adverse-event-reporting-system-faers-electronic-submissions).
4.2.5.6 Data Element G.k.4.r.9.2b: Pharmaceutical Dose Form TermID
FDA accepts either the EDQM code list for Pharmaceutical Dose Form TermID or the FDA SPL
Dosage Form list.25 If EDQM codes or FDA SPL codes are not available, populate data element
G.k.4.r.9.1, Pharmaceutical Dose Form, with free text.
4.2.5.7 Data Element G.k.4.r.10.2b: Route of Administration TermID
FDA accepts either the EDQM code list for Route of Administration TermID or the FDA SPL
Route of Administration list.26 If EDQM codes or FDA SPL codes are not available, populate
data element G.k.4.r.10.1, Route of Administration, with free text.
4.2.5.8 Data Element G.k.4.r.11.2b: Parent Route of Administration TermID
FDA accepts either the EDQM code list for Route of Administration TermID or the FDA SPL
25 Refer to ICH and EDQM guides for specific user instructions on EDQM at
https://www.edqm.eu/sites/default/files/standard_terms_introduction_and_guidance_for_use.pdf. The list of FDA
SPL dosage forms is available at: https://www.fda.gov/industry/structured-product-labeling-resources/dosage-forms.
26 Refer to ICH and EDQM guides for specific user instructions on EDQM at
https://www.edqm.eu/sites/default/files/standard_terms_introduction_and_guidance_for_use.pdf. The list of FDA
SPL routes of administration is available at: https://www.fda.gov/industry/structured-product-labeling-
resources/route-administration.

Contains Nonbinding Recommendations
19
Route of Administration list.27 If EDQM codes or FDA SPL codes are not available, populate
data element G.k.4.r.11.1, Parent Route of Administration, with free text.
4.2.5.9 Data Element FDA.G.k.10a.r: FDA Additional Information on Drug
FDA regionally controlled terminology for data element FDA.G.k.10a.r, FDA Additional
Information on Drug, is used to provide characteristics associated with product information.
These codes comprise the product types used in an IND-exempt BA/BE study and compounding
products listed in the document FDA E2B(R3) Core and Regional Data Elements and Business
Rules. Procedures and other examples for capturing FDA Specialized Product Categories are
provided on the FAERS Electronic Submissions web page (see
https://www.fda.gov/drugs/questions-and-answers-fdas-adverse-event-reporting-system-
faers/fda-adverse-event-reporting-system-faers-electronic-submissions). Recommendations on
selecting the data element FDA.G.k.10a.r code for IND-exempt BA/BE study safety reports is
provided in the guidance for industry Electronic Submission of Expedited Safety Reports from
IND-Exempt BA/BE Studies.
4.2.6 	Section E.i: Reaction/Event as Reported by the Primary Source
Applicants should follow the E2B(R3) Electronic Transmission of ICSRs IG and relevant
sections within this document concerning the use of MedDRA coding. For combination
products, enter MedDRA reaction/event terms instead of Patient Problem Codes.28 For a
malfunction-only combination product report, enter a MedDRA code associated with a relevant
product quality issue or the MedDRA LLT code “No adverse event” for data element E.i.2.1b,
Reaction / Event (MedDRA code).
4.2.7 	Combination Product Information
FDA has provided regional extensions to accommodate reports for Combination Products as
required by 21 CFR Part 4, Subpart B, which was added by the “Postmarketing Safety Reporting
for Combination Products” rule.29 ICSR submissions using the regional extensions for a
combination product with a drug constituent part that received marketing authorization under an
NDA or ANDA or with a therapeutic biological product constituent part that received marketing
authorization under a BLA, the information in Table 4 should be provided, as applicable.
27 Refer to ICH and EDQM guides for specific user instructions on EDQM at
https://www.edqm.eu/sites/default/files/standard_terms_introduction_and_guidance_for_use.pdf.
The list of FDA SPL dosage forms is available at: https://www.fda.gov/industry/structured-product-labeling-
resources/route-administration.
28 FDA maintains a list of patient problem codes at https://www.fda.gov/medical-devices/mdr-adverse-event-
codes/coding-resources.
29 Postmarketing Safety Reporting for Combination Products; Final Rule, 81 FR 92603 (December 20, 2016).

Contains Nonbinding Recommendations
20
Table 4: Regional Extensions to Report Combination Products
Data Element 	Field Name 	Data Element Detail
FDA.G.k.10.1 	FDA Specialized
Product Category
FDA extensions are used for ICH data element
G.k.10.r, Additional Information on Drug (coded), to
support the identification of specialized FDA product
categories of combination products. This FDA
regional data element is used to support coding of
specialized FDA product categories in the drug
information section using NCI concept identifier
C94031. Data element FDA.C.1.12, Combination
Product Report Indicator, is used to indicate that an
ICSR includes a combination product;
FDA.G.k.10.1, FDA Specialized Product Category,
is used to indicate which product(s) are combination
products and the type of combination product.
FDA.G.k.12.r.1 	Malfunction 	Malfunction is captured as a Boolean value (true or
false) and should be provided for all combination
products in an ICSR when the Combination Product
Report Flag is “true.”
FDA.G.K.12.r.3.r 	Device Problem
Code
FDA maintains a list of medical device problem
codes. If there is no medical device problem
associated with the ICSR, use the medical device
problem code for “No Known Device Problem”. At
least one medical device problem code must be
provided when malfunction=true.
FDA.G.k.12.r.4 	Device Brand
Name
Provide the name or ProCode for the medical device
constituent part of the combination product. At least
one of the following data elements should be
provided for each combination product:
FDA.G.j.12.r.4, FDA.G.k.12.r.5 or FDA.G.k.12.r.6
FDA.G.k.12.r.5 	Common
Device Name
Provide the name or ProCode for the medical device
constituent part of the combination product. At least
one of the following data elements should be
provided for each combination product:
FDA.G.j.12.r.4, FDA.G.k.12.r.5 or FDA.G.k.12.r.6
FDA.G.k.12.r.6 	Device
Product Code
Provide the name or ProCode for the medical device
constituent part of the combination product. At least
one of the following data elements should be
provided for each combination product:
FDA.G.j.12.r.4, FDA.G.k.12.r.5 or FDA.G.k.12.r.6
FDA.G.k.12.r.7.1a 	Device
Manufacturer
Name
Provide the name and location of the manufacturer of
the medical device constituent part of the product.
FDA.G.k.12.r.7.1b 	Device
Manufacturer
Address
Provide the name and location of the manufacturer of
the medical device constituent part of the product.

Contains Nonbinding Recommendations
21
Data Element 	Field Name 	Data Element Detail
FDA.G.k.12.r.7.1c 	Device
Manufacturer
City
Provide the name and location of the manufacturer of
the medical device constituent part of the product.
FDA.G.k.12.r.7.1d 	Device
Manufacturer
State
Provide the name and location of the manufacturer of
the medical device constituent part of the product.
FDA.G.k.12.r.7.1e 	Device
Manufacturer
Country
Provide the name and location of the manufacturer of
the medical device constituent part of the product.
FDA.G.k.12.r.8 	Device Usage 	Indicate the usage of the device as the initial use,
reuse, or unknown.
FDA.G.k.12.r.9 	Device Lot
Number
Provide the lot number of the device.
FDA.G.k.12.r.10 	Operator of
the Device
Indicate the operator of the device.
FDA.G.k.12.r.11.r 	Remedial Action
Initiated
Indicate the applicable action(s). This data element is
required for 5-day reports (i.e., Local Criteria for
Report is “5-day”). See the FDA regulations
concerning remedial action (21 CFR Parts 7, 803 and
806) for additional information.
4.3 	Submission Rules
The submission rules define conditions that will result in a negative acknowledgement and not be
accepted by FAERS, if not met. The document FDA E2B(R3) Core and Regional Data Elements
and Business Rules defines the conformance and the business rules for each data element. The
tab “Rejection and Warning Rules” lists the rejection rules that will result in a negative
acknowledgement, and the warning rules that will list a warning but result in positive
acknowledgement.
4.4 	Forward Compatibility
The forward compatibility defines the rules to migrate existing FDA regional E2B(R2) data
elements to the FDA regional E2B R3 data elements. The document FDA E2B(R3) Forward
Compatible Rules lists the data elements and the rules to be applied when moving from E2B(R2)
to E2B(R3) format. Additionally, the guidance for industry Appendix I (B) to the ICH E2B(R3)
ICSRs Implementation Guide — Backwards and Forwards Compatibility (Apr. 2022) should be
referenced for data elements whose ”Source” is ICH.
5.0 	GENERAL DATA COMPLETION INSTRUCTION
5.1 	Required and Optional Data Elements
A required data element is one that needs to be present (i.e., not to be omitted) either in the ICSR
message or an instance of a repeating data element section within the ICSR message.

Contains Nonbinding Recommendations
22
A required data element may or may not allow a nullFlavor, depending on the data validation
rules associated with the data element.
An optional data element generally does not have to be included in the message if it does not
have a value. But in some cases, a referential data validation rule may necessitate an optional
data element be indicated with a nullFlavor under certain circumstances.
The FDA E2B(R3) Core and Regional Data Elements and Business Rules document lists all data
elements, including ICH and FDA regional data elements, and validation rules used to process
incoming ICSRs. The Business Rules document provides detailed information on the
conformance, format, and where applicable, allowed values, nullFavors, and controlled
terminologies for each data element.
Regional extensions not described in the FDA E2B(R3) Core and Regional Data Elements and
Business Rules document are not allowed.
5.2 	Description in English
All ICSR data elements should be completed in English with the exceptions of the following
elements:
• 	“Reaction/Event as Reported by the Primary Source in Native Language” (E.i.1.1a);
• 	“Case Summary and Reporter’s Comments in Native Language” (H.5.r)
5.3 	Date/Time Data Elements
Actual local dates and times should be used and offset (i.e., +/-ZZzz) is attached where
appropriate. A single format (CCYYMMDDhhmmss.UUUU[+/-ZZzz]) is used to represent
dates and times. The minimum level of precision for the date data elements is specified in the
Business Rules; however, as much information as is available (e.g., known) should be provided.
Future dates are not acceptable in an ICSR message.
5.4 	Use of Metric Units
Metric units should be used for measurement values.
5.5 	Version of Medical Dictionary of Regulatory Activities (MedDRA)
A single version of MedDRA should be used for all MedDRA coding data elements within the
same ICSR (i.e., ICSR message). Therefore, the same MedDRA version should be reflected in
all the populated data elements concerning MedDRA version information. However, within a
safety message (i.e., a batch of ICSRs), different ICSRs can refer to different MedDRA versions.

Contains Nonbinding Recommendations
23
5.6 	Standard Terminologies and Codelists
If a data element is defined with a specific codelist (in the “Values” column of the Business
Rules), the associated codelist needs to always be used. Also, when the codelist code is captured
as the value of a data element, its text name should be provided in display name to make the
XML code human readable.
5.7 	Use of nullFlavors
HL7 nullFlavor codes are used to explain the reason for the lack of data on required elements.
The definitions of nullFlavor codes are from the E2B(R3) Electronic Transmission of ICSRs IG
and can be used as appropriate.
5.8 	ICSR Attachment(s)
In accordance with E2B(R3) Electronic Transmission of ICSRs IG, ICSR attachments should be
sent inline as embedded files using base 64 encoding (refer to E2B(R3) Electronic Transmission
of ICSRs IG Section 3.5 (Document Attachments) for further information). To facilitate ICSR
attachment file processing, the data element “Attachment file name” must be included using the
<reference value> data element in the XML file, which must be placed after the <text
mediaType> tag.
EXAMPLE:
<reference typeCode="REFR">
<document classCode="DOC" moodCode="EVN">
<code code="1" codeSystem="2.16.840.1.113883.3.989.2.1.1.27"
displayName="documentsHeldBySender"/>
<title>Narrative Summary Report</title>
<text mediaType="text/plain" representation="B64">
<reference value="Narrative Summary Report.pdf"/>
VGhlIHBhdGllbnQgd2FzIGEgMzUgeWxlIHdpdGggbm8gc==
</text>
</document>
</reference>
Special Note: the “attachment file name” must follow the naming convention for a valid “url”.
Letters, digits, and special characters "a"--"z", digits, as well as the characters plus ("+"), period
("."), and hyphen ("-") are allowed.
If the file type in the reference value tag does not match the file extension in the file name, the
file will be rejected. For example, a file with <reference value="SAMPLE FILE.txt"/> must
have a text file media type reported.
For more information about restrictions, see http://www.ietf.org/rfc/rfc1738.txt.

Contains Nonbinding Recommendations
24
5.9 	ICSR Attachment File-Size Limitations
The FDA ESG supports the receipt of electronic regulatory submissions of up to 100 GB in size;
however, the recommended ICSR submission size is less than 100 megabytes (MB). ICSR
attachments should not be individually compressed.
The following attachment file types with corresponding media types are supported:
Attachment Type 	Media Type
Portable document format (.pdf) 	"application/pdf"
Image file formats (.jpeg, .jpg) 	"image/jpeg"
Bitmap image format (.bmp) 	"image/bmp"
Portable Network Graphics (.png) 	"image/png"
Graphics Interchange Format (.gif) 	"image/gif"
Tagged image file format (.tiff) 	"image/tiff"
Tagged image file format (.tif) 	"image/tif"
Text format (.txt) 	"text/plain"
Spreadsheet file format (.xls) 	"application/vnd.ms-excel"
Spreadsheet file format (.xlsx) 	“application/vnd.openxmlformats-
officedocument.spreadsheetml.sheet"
Word processing document format (.doc) 	“application/msword”
Word processing document format (.docx) 	"application/vnd.openxmlformats-
officedocument.wordprocessingml.document"
Word processing document format (.wpd) 	"application/vnd.wordperfect"