FDA E2B(R3) Electronic Transmission of Individual Case Safety Reports User Guide

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 by 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).

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.

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.

Electronic ICSR Submissions Using the FDA ESG

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).

2. FDA ESG Transaction Partners and Testing

3. 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.

4. 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](mailto:ESGHelpDesk@fda.hhs.gov).
  * For more information about FAERS testing, email [FAERSESUB@fda.hhs.gov](mailto:FAERSESUB@fda.hhs.gov).

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.

4. 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_AERSPREMKT CDER| XML files: FDA_AERSPREMKT CBER
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).
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.

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).

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.

7. ICSR Submission Failure

8. 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.

9. 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 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.

FAERS FDA REGIONAL TECHNICAL SPECIFICATIONS

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).

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_IN200100UV01.xsd”>

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.

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.

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).

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).

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.

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.

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”.

FDA ICSR Content

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 acknowledgment 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.

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.

3. Section C.1: Identification of a Case Safety Report

4. 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 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”.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. Section D: Patient Characteristics

11. 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)
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.
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.”

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/).

6. 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
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).

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.  **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.

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 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).

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.

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.

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.

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.

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).

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

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.
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.

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.

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.

GENERAL DATA COMPLETION INSTRUCTION

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.

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)

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.

Use of Metric Units
Metric units should be used for measurement values.

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.

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.

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.

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