You are here
E2B reports: frequently asked questions
These FAQs have been updated following minor changes to the E2B R2 functionality. These FAQs have been updated to reflect the changes, and to clarify existing requirements.
E2B R2 is an international standard for transmitting medicine adverse event reports specified by the International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH).
XML, or Extensible Markup Language, is a markup language that defines rules for structuring documents in a format that can be read by both humans and machines. The structure of XML is based on a grouping of sections and elements that are annotated by start and end tags. Tags are user-friendly phrases used to indicate the data elements contained within the tags. For example, using the E2B R2 format a patient's date of birth of 19 March 1972 in XML would appear as: <patientbirthdate>19720319</patientbirthdate>.
The preparation of an E2B adverse event report file, requires mapping of your internal database to the E2B data set described in the ICH M2 EWG - Electronic Transmission of Individual Case Safety Reports Message Specification (ICH ISCR DTD) which is available for download on the EudraVigilance or the US Food and Drug Administration websites. After your database has been mapped, the data elements must be marked in conformance with the specified document type definition (DTD).
*Large file warning: Attempting to open large pdf files over the Internet within the browser window may cause problems. It is strongly recommended you download this document to your own computer and open from there.
- ICH M2 EWG: Electronic Transmission of Individual Case Safety Reports Message Specification (ICH ICSR DTD Version 2.1) (pdf,565kb)
The ICH ICSR DTD document defines the specific data elements to be included for electronic submission of adverse event data, the order of the elements, and their interrelationship.
Prior to submission of an E2B R2 file, a connection will need to be setup between your system and TGAs system. This will require the exchange of technical and contact details as well as applicable digital certificates. Once this connection has been established and tested, E2B R2 files can be electronically submitted system to system using the AS2 transmission protocol.
For further information, refer to the Electronic submission of individual case safety reports - Electronic data interchange for ICSR submission using the E2B R2 format.
Adverse event reports from the pharmaceutical industry that are submitted system to system are associated with a Sponsor record by TGA using the provided AS2 identifier and digital certificates of the sender organisation.
An organisation that has multiple Sponsor records with the TGA can choose to either have:
- separate connections established with TGA for each Sponsor record and adverse events associated with the applicable Sponsor records; or
- one connection established and all adverse events associated with the one Sponsor record.
No. The system has been designed for a single adverse event report per xml file.
There is no limit to the number of xml files that can be submitted from your system to TGA's system.
The system will accept xml files up to 2mb.
Yes. Clinical trial reports can be electronically submitted system to system. The message type for all adverse event reports (including those that occurred in clinical trials) must be ICH ICSR.
Yes. For cases previously provided in the E2B R2 format the follow-up report needs to include the same sender's case safety report unique identifier (A.1.0.1) and worldwide unique case identification number (A.1.10).
For cases previously provided via another method such as email or the online form, the previously issued TGA reference number should be provided in the 'Other case identifiers in previous transmissions' (A.1.11) section of the xml for the updated case. This will assist with the detection and management of duplicates.
No. Electronic submission is only for medicine adverse event reports. Medical device adverse event (incident) reports from sponsors can be submitted via the Sponsors/Manufacturers medical device incident report page.
Sponsors who have submitted an E2B formatted report as an XML file will receive a message delivery notification (MDN) from our system confirming receipt of the message. A standard acknowledgment message relating to the success or failure of the transmission will be sent following processing of the message. If the XML filesubmitted report was does not loaded successfully into the TGA's system, the acknowledgment message will include a description of the first error encountered.
If you do not receive an acknowledgement message, please contact firstname.lastname@example.org and include information on the date/time of your submission.
No. The existing methods for sponsors to submit adverse event reports will continue to be available.
Yes. Sponsors are required to undertake validation testing with the TGA prior to using the E2B system to system functionality. The validation process will be conducted with test reports in a dedicated testing environment at the TGA. Refer to the test scenarios to use the E2B standard.
Your company can register their interest with the TGA by submitting an email to email@example.com.
The MedDRA LLT should be used for fields such as B.1.8f (Indication) in the ICH M2 EWG - Electronic Transmission of Individual Case Safety Reports Message Specification where only one MedDRA coding level is available.
To meet the validation rules at least one patient characteristic field is required in the xml file to be populated with a value.
If you believe there is a real patient involved but do not have any specific patient characteristics available, you can still report the adverse event by including a value in the Patient Initials B.1.1 field (for example 'UNK').
It is the TGA's preference that personal information, such as the names of patients, health professionals, or health facilities; date of birth; and patient identification numbers, are not included in the case narrative. This information should instead be provided in the sender comments or applicable fields.
The TGA system can receive xml reports that include or do not include a <!DOCTYPE...> comment field. During the on boarding process each organisation specifies whether a <!DOCTYPE...> comment field will be used in the xml for the submitted cases.
The acknowledgement message sent by the TGA will include a <!DOCTYPE...> comment field.
The TGA system can support either the UTF-8 or UTF-16 character encoding formats.
During the on boarding process each organisation specifies the character encoding format that will be used in the xml for the submitted cases. Once configured all submitted cases need to be provided in the specified format.
No. Associated documents cannot be submitted using the TGA E2B functionality. All relevant additional documents held by the sender of the case should be specified in the xml (A.1.8.2) and only provided upon request by the TGA. For adverse event reports from literature, the literature reference must be provided in A.2.2 'Literature reference(s)'and the abstract included in B.5.1 'Case Narrative' if possible.
No. Whilst we strongly recommend our partners use Transport Layer Security (SSL) for security reasons, our system can be configured to not require it.
In the event the TGA E2B functionality is unavailable for a period which affects the sender's ability to meet regulatory reporting timeframes, the sender should submit the ICH E2B(R2) case safety report to TGA within two TGA business days of the gateway becoming available. In reviewing regulatory reporting timeframe compliance the TGA will consider relevant periods of gateway unavailability.
The TGA will also advise users when the TGA gateway will be unavailable for scheduled maintenance.
No. Sponsors can continue to use the existing email process to request and receive adverse event reports from the TGA.
No. The TGA currently only supports the submission of adverse event reports in the E2B R2 format.
At this stage the TGA does not have a set timeframe for when the service will be extended to include the E2B R3 format.