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, Draft Guidance for Industry 
 
 
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 2022 
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 
     
 
  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 ....................................................................... 5 
3.6.2.1 ESG Transaction Partners ................................................................................................ 5 
3.6.2.2 ESG Testing ........................................................................................................................ 6 
3.6.3   FDA ESG Header Information .............................................................................................. 6 
3.6.3.1 AS2 Headers and Routing IDs .......................................................................................... 6 
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 ................................................................ 9 
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 .............................................................. 10 
4.1.7   Data Element N.2.r.3: Message Receiver Identifier ............................................................ 10 
4.2   FDA ICSR Content ...................................................................................................................... 11 
4.2.1   Data Element Conformance ................................................................................................. 11 
4.2.2   Terminology .......................................................................................................................... 11 
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 ......................................................... 13 
4.2.3.4 Data Element FDA C.5.5a: IND Number Where AE Occurred .................................. 13 
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.r.6: IND Number of Cross-Reported IND ............................. 14 
4.2.4.   Section D: Patient Characteristics ...................................................................................... 14 
4.2.4.1 FDA Regional Data Elements ......................................................................................... 14 
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 ....................................................................................... 15 
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
 ....................................................................................................................................................... 16 
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 ....................... 18 
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 ......................................................................................................................... 20 
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.................................................................................................................. 21 
5.3   Date/Time Data Elements ............................................................................................................ 21 
5.4   Use of Metric Units ...................................................................................................................... 22 
5.5   Version of Medical Dictionary of Regulatory Activities (MedDRA) ....................................... 22 
5.6   Standard Terminologies and Codelists ...................................................................................... 22 
5.7   Use of nullFlavors ........................................................................................................................ 22 
5.8   ICSR Attachment(s)..................................................................................................................... 22 
5.9   ICSR Attachment File-Size Limitations .................................................................................... 23 
  Contains Nonbinding Recommendations   
 
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 (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 FDAs technical approach for submitting ICSRs, for incorporating its 
regionally controlled terminology5, 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. 
  1  Contains Nonbinding Recommendations   
 
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 
  Center for Drug Evaluation and Research (CDER)-regulated therapeutic 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) studies6 
 
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 
FDAs regional data elements, in extensible markup language (XML)8 file format and submitted 
through FDAs 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 FDAs Guidance for 
Industry: Providing Submissions in Electronic FormatPostmarketing 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); draft guidance for industry Providing Regulatory Submissions in Electronic Format: IND Safety Reports 
(Oct. 2019) (when final this guidance will represent FDAs current thinking on this topic). 
10 See the draft guidance for industry Electronic Submission of Expedited Safety Reports From IND-Exempt BA/BE 
Studies (Aug. 2022) (when final this guidance will represent FDAs current thinking on this topic). 
  2  Contains Nonbinding Recommendations   
 
 
The contents of this document do not have the force and effect of law and are not meant to bind 
the public in any way, unless specifically incorporated into a contract.  This document is 
intended only to provide clarity to the public regarding existing requirements under the law.  
FDA guidance documents, including this guidance, 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 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), 
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. 
 
  FDAs 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 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) 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 Agencys progress and ability to receive E2B(R3) formatted 
submissions; these updates will be published on FDA web pages.  Stakeholders interested in 
  3  Contains Nonbinding Recommendations   
 
submitting ICSRs to FAERS in E2B(R3) format should contact the FAERS electronic 
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). 
 
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) migration planning and pilot testing will be made 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). 
 
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 displayName 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="Ethnic Group" 
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). 
 
  4  Contains Nonbinding Recommendations   
 
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 
 
FDAs 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). 
 
3.6.2   FDA ESG Transaction Partners and Testing 
 
3.6.2.1 ESG Transaction Partners 
 
 
11 Information about the NCI EVS is available on the NCI web page at: http://evs.nci.nih.gov/. 
  5  Contains Nonbinding Recommendations   
 
To submit files electronically to FDA, organizations should apply for a Transaction Partner 
account.  Account requests should include the organizations 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 Centers "GW_TEST CONNECTION account 
using the submission type "CONNECTION TEST, not to the Centers 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.  
 
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.  
 
 
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. 
 
  6  Contains Nonbinding Recommendations   
 
Table 1. AS2 Headers and Routing IDs 
     
AS2 
Postmarketing  Premarketing reports   Premarketing reports 
Headers/
reports  for CDER  for CBER 
Routing 
IDs     
       
AS2  Destination: CDER  Destination: CDER  Destination: CBER  
Headers       
XML files: AERS  XML files:  XML files: 
AERS_PREMKT_CDER  AERS_PREMKT_CBER 
 
       
Routing  XML files:  XML files:  XML files: 
IDs  FDA_AERS  FDA_AERS_PREMKT_ FDA_AERS_PREMKT_
  CDER  CBER 
WebTrader Accounts:   
CDER AERS 
 
AS2 Accounts: 
FDA_AERS 
 
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  Notifies the sender that the submission was successfully 
Notification (MDN)  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 FDAs guidance for 
industry Providing Regulatory Submissions in Electronic 
Format--Receipt Date (February 2014). 
  7  Contains Nonbinding Recommendations   
 
ACK2  FAERS Review  Notifies the sender that the FAERS system processed the 
Acceptance/Rejection  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: 
 
a.  For a single ICSR submission, resubmit the corrected ICSR with 
a new unique batch identifier.  Refer to Section 4.1.3 (Batch 
  8  Contains Nonbinding Recommendations   
 
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.  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  
 
  9  Contains Nonbinding Recommendations   
 
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. 
 
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.  
  10  Contains Nonbinding Recommendations   
 
 
  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 Message Receiver Identifier (data element N.2.r.3) = CDER, the Batch Receiver Identifier 
(data element N.1.4) must be ZZFDA.  
 
For all 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.  
NullFlavors 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 whose Source is ICH is under the ICH Business 
Rules and are applicable to both premarketing and postmarketing data elements unless specific 
rules are defined under Post-market Business Rules and/or Pre-market Business Rules.  For 
the regional data elements whose Source is FDA, the business rules are defined under the 
Post-market Business Rules and/or Pre-market Business Rules.  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. 
 
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 
 
13 Companies can license MedDRA from the international maintenance and support services organization (MSSO). 
  11  Contains Nonbinding Recommendations   
 
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) 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 NCIs 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), 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 NI (No Information) for this data element in initial submissions.  
Initial submissions with nullFlavor 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 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 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 
 
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. 
  12  Contains Nonbinding Recommendations   
 
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, Senders (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 Senders (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. 
 
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 
 
 
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). 
  13  Contains Nonbinding Recommendations   
 
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.r.6: 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 NA (Not Applicable) 
code should be populated in this field. 
 
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 the HL7 nullFlavor NI code (HL7 nullFlavor 
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). 
 
 
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 Drugs Pre-ANDA Program for complex 
drug products.  See https://www.fda.gov/drugs/generic-drugs/pre-anda-program. 
20 As discussed in FDAs 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 sponsors INDs under which the drug 
is being administered. 
  14  Contains Nonbinding Recommendations   
 
a. Data element FDA.D.11.r  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. 
 
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 
 
21 See FDAs guidance for industry Adverse Event Reporting for Outsourcing Facilities Under Section 503B of the 
Federal Food, Drug, and Cosmetic Act (Oct. 2015). 
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. 
  15  Contains Nonbinding Recommendations   
 
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). 
 
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 
 
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. 
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. 
  16  Contains Nonbinding Recommendations   
 
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 provided 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. 
 
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  
 
If the Substance/Specified Substance TermID (data element G.k.2.3.r.2b) is not available, the 
FDA SRS UNII list should be used to populate data element G.k.2.3.r.1, Substance/Specified 
Substance Name. 
 
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). 
 
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  Rx No Application  000000 
without an approved application 
Non-prescription drug product marketed  Non-Rx No Application  999999 
without an approved application 
  17  Contains Nonbinding Recommendations   
 
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 
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 
 
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. 
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. 
  18  Contains Nonbinding Recommendations   
 
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.6   Section E.i: Reaction/Event as Reported by the Primary Source 
 
Applicants should follow the E2B(R3) Electronic Transmission of ICSRs IG concerning the use 
of MedDRA coding.  For combination products, enter MedDRA reaction/event terms instead of 
Device/Patient Problem Codes.28  For a malfunction-only combination product reports, 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. 
 
Table 4: Regional Extensions to Report Combination Products 
Data Element  Field Name  Data Element Detail 
FDA.G.k.13.r  FDA Specialized  FDA extensions are used for ICH data element 
Product Category  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.13.r, 
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  FDA maintains a list of medical device problem 
Code  codes. If there is no medical device problem 
 
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). 
  19  Contains Nonbinding Recommendations   
 
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  Provide the name or ProCode for the medical device 
Name  constituent part of the combination product. At least 
FDA.G.k.12.r.5  Common  one of these three data elements should be provided 
Device Name  for each combination product. 
FDA.G.k.12.r.6  Device 
Product Code 
FDA.G.k.12.r.7.1a  Device  Provide the name and location of the manufacturer of 
Manufacturer  the medical device constituent part of the product. 
Name 
FDA.G.k.12.r.7.1b  Device 
Manufacturer 
Address 
FDA.G.k.12.r.7.1c  Device 
Manufacturer 
City 
FDA.G.k.12.r.7.1d  Device 
Manufacturer 
State 
FDA.G.k.12.r.7.1e  Device 
Manufacturer 
Country 
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  Provide the lot number of the device. 
Number 
FDA.G.k.12.r.10a  Operator of  Indicate the operator of the device. 
the Device 
FDA.G.k.12.r.11.r  Remedial Action  Indicate the applicable action(s). This data element is 
Initiated  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.  
 
  20  Contains Nonbinding Recommendations   
 
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 (April 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.  
 
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 Reporters 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 
  21  Contains Nonbinding Recommendations   
 
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. 
 
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 
 
NullFlavors are used to explain the reason for the lack of data on required elements.  The 
definitions of nullFlavors 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>  
  22  Contains Nonbinding Recommendations   
 
    </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. 
 
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 are supported: 
 
  Portable document format (.pdf) 
  Image file formats (.jpeg, .jpg) 
  Bitmap image format (.bmp) 
  Portable Network Graphics (.png) 
  Graphics Interchange Format (.gif) 
  Tagged image file format (.tif, .tiff) 
  Rich text format (.rtf) 
  Text format (.txt) 
  Spreadsheet file format (.xls, .xlsx) 
  Word processing document format (.doc, .docx, .wpd) 
 
  23