EudraVigilance: electronic reporting

Marketing authorisation holders and sponsors of clinical trials must report and evaluate suspected adverse drug reactions both during development and after a medicine is authorised in the EEA and also submit the data of their authorised or investigational products to the Extended EudraVigilance Medicinal Product Dictionary (XEVMPD). National competent authorities must report reactions they receive from patients or healthcare professionals to the EV system.

EU pharmacovigilance legislation and the clinical trials legislation and guidance define the reporting obligations, which apply to the electronic submission and exchange of:

• individual case safety reports (ICSRs) and acknowledgement messages in the context of clinical trials;
• ICSRs and acknowledgement messages for centrally and non-centrally authorised medicinal products;
• extended EudraVigilance medicinal product report messages (XEVPRMs) and acknowledgements related to information on investigational medicinal products in clinical trials;
• XEVPRMs and acknowledgements related to information on authorised medicinal products.

Who needs to report what?

Interventional clinical trials

Who	What	Reference
Sponsors of clinical trials Marketing authorisation holders National competent authorities	Reports of suspected unexpected serious adverse reactions (SUSARs) via safety reports (ICSRs/acknowledgements)	Regulation (EU) No 536/2014 (Article 42 and Annex III) Regulation (EU) No 536/2014 - Questions & answers
Sponsors of clinical trials Marketing authorisation holders	Information on investigational medicinal products via product reports (XEVPRMs/acknowledgements)	Regulation (EU) No 536/2014  (Article 81(3))

 

Spontaneous reports and non-interventional clinical trials

Who	What	Reference
Marketing authorisation holders National competent authorities	Reports of suspected serious adverse reactions for authorised medicinal products via safety reports (ICSRs/acknowledgements): suspected serious adverse reactions occurring within and outside the EEA suspected non-serious adverse reactions occurring within the EEA	Directive 2001/83/EC (Articles 107(3) and 107a(4)) Guideline on good pharmacovigilance practices (GVP) - Module VI – Collection, management and submission of reports of suspected adverse reactions to medicinal products (Rev. 2)
Marketing authorisation holders	Information on authorised medicinal products via product reports (XEVPRMs/acknowledgements)	Regulation 726/2004 (Article 57(2)

 

The EudraVigilance system does not accept ICSR messages in the ICH E2B (R2) format. This is stated in 

Announcement of the EMA Management Board - Confirmation of the mandatory use of the ISO Individual Case Report standard based on ICH E2B(R3) modalities and related ISO standard terminology

(19/12/2019)

Users should report ICSRs using the ISO ICSR/ICH E2B(R3) format and use the related ISO standard terminology for pharmaceutical form and route of administration.

For more information, see:

• Guidance on using ISO standard format for individual case safety reports

EudraVigilance: Obtaining EDQM terms from SPOR

Reference Number: EMA/580322/2021

Use of EDQM terminologies for Dose Forms and Routes of Administration for Individual Case Safety Reports in E2B(R3) message

Summary:

This spreadsheet provides a common template that summarises the core ICH E2B(R3) data elements, business rules and any associated questions and answers.

Preparing for the electronic exchange of safety reports

EudraVigilance supports the electronic transmission of ICSRs between electronic data interchange (EDI) partners: EMA, national competent authorities (NCAs), marketing authorisation holders (MAHs) and sponsors of clinical trials in the European Economic Area (EEA).

Organisations are required to perform testing before they can initiate the electronic transmission with the EudraVigilance production environment. This is to ensure that their local safety/pharmacovigilance database is compatible with the EudraVigilance system and compliant with messaging format and terminology requirements.

At least one user per organisation should be trained using EudraVigilance, who can subsequently train other in-house staff as necessary. For details on the training offerings see EudraVigilance training and support. Following successful completion of the training, users can register with EudraVigilance.

Type of organisation

Testing applies to organisations that electronically report ICSRs to EudraVigilance for the first time (“new organisations”) or organisations that introduce a major change to their local safety/pharmacovigilance database which might impact the electronic reporting of ICSRs (“major changes”).

In addition, EMA supports initial testing of software/system solutions by IT vendors and third party service providers (“third party service providers”).

Below is an overview of the steps users should follow for the electronic transmission of ICSRs depending on their type of organisation and technical infrastructure:

Type of organisation	Steps
New organisation using a gateway and a local safety/pharmacovigilance database National competent authorities Marketing authorisation holders Sponsors of clinical trials	Complete steps 1 to 6 (see testing steps below)
New organisation using EVPOST and a local safety/pharmacovigilance database National competent authorities Marketing authorisation holders Sponsors of clinical trials	Complete steps 1, 4, 5 and 6 (see testing steps below)
New organisation using EVWEB National competent authorities Marketing authorisation holders Sponsors of clinical trials	Complete step 1 (see testing steps below)
Major change (gateway and/or a local safety/pharmacovigilance database) National competent authorities Marketing authorisation holders Sponsors of clinical trials	Complete steps 4, 5 and 6 (see testing steps below)
Third party service providers	Complete steps 1 to 6 (see testing steps below)

Organisations need to carry out the actions described below in step 4, on development and validation testing, before initiating the quality assurance testing (QAT) with EMA. They can raise a QAT request following the instructions given in the EudraVigilance support guide:

EudraVigilance support guide

Reference Number: EMA/434681/2023

They should also provide their full safety report identifiers (ICH E2B R3: C.1.1 “Sender’s (case) safety report unique identifier”) in the QAT request of their step 5 test cases. This can be done after submitting the test cases (1a-10) in XCOMP, and having received a positive acknowledgement for each test.

If one or more acknowledgments are missing, organisations need to raise a separate request to EMA’s gateway team for further investigation. This is done via Service Desk.

Organisations using software developed by a vendor should check if it is vendor tested for the version and configuration settings in use. If no modifications / customisations are made to the vendor software, this information is to be included in the QAT request. 

Use of EudraVigilance test system (XCOMP)

EMA enables EDI partners to register and connect to XCOMP to analyse and test whether their software/IT system is interoperable with EudraVigilance.

Please note, the Agency accepts no responsibility or liability arising out of or in connection with XCOMP (including but not limited to any direct or consequential loss or damage that might occur to you and/or any other third party).

The Agency aims to minimise disruption caused by technical errors. However, the Agency cannot guarantee that XCOMP will not be interrupted or otherwise affected by such problems. The Agency accepts no responsibility whatsoever with regard to such problems incurred as a result of using the system.

This disclaimer is not intended to limit the liability of the Agency in contravention of any requirements laid down in applicable legislation or to exclude its liability for matters, which may not be excluded under that law.

EudraVigilance testing steps

Step 1: Register with EudraVigilance

To complete the registration of a new organisation for the submission of ICSRs, follow the processes described in EudraVigilance: how to register.

Step 2: Obtain EudraVigilance gateway confirmation

Organisations need to obtain a confirmation to use the EudraVigilance gateway. The Agency does not mandate any particular software for the electronic reporting of ICSRs, however the software needs to adhere to the standards as outlined in chapter I.C.2.1.5.2 Gateway configuration and communication testing of:

European Union individual case safety report (ICSR) implementation guide

Adopted Consultation dates: 30/04/2014 to 30/06/2014 Reference Number: EMA/51938/2013 Rev. 2 Summary:

This guidance specifies the technical requirements and the process of transmission of individual case safety reports (ICSRs) and is applicable to all stakeholders, which are exchanging ICSRs electronically within the European Economic Area.

Step 3: Communication test

This test will assure successful gateway-to-gateway communication. To establish the connection, organisations need to:

• document their transport choice;
• exchange profile information;
• exchange public keys for encryption;
• test the connection.

Once a successful connection has been established, safety and acknowledgement messages can be transferred between each party in the programme by sending an encrypted safety and acknowledgement message to the EV gateway. Here, it will be decrypted, checked for basic accuracy, then re-encrypted and sent to the ultimate destination.

This test is required between EMA and all organisations connected to the gateway.

Once the communication testing has been completed successfully, EMA will confirm this and the organisation can move on to the next steps of testing.

Step 4: Development and validation testing

EDI partners should carry out their own development and validation testing activities with XCOMP before requesting quality assurance testing with EMA. In that way, they ensure that their system does not modify data upon transmitting the ICSRs to the EudraVigilance system.

Organisations therefore need to verify that the test files output from their system are the same as the original test files provided by EMA (available in a zip folder under testing step 5). Some administrative fields are expected to be changed, but the rest of the data should remain intact.

Organisations are encouraged to use the RTF files contained in the zip folder below to compare the test data against the output of their own system. This should include checking each field and addressing any differences found.

Test cases (1a-10) RTFs

Failing to perform this sender side validation will result in delays to completion of QAT as organisations will be required to correct the issues detected by EMA.

Once organisations have completed this test phase, they should notify EMA and other potential EDI partners to move to the XML test phase.

Any deliberate abuse of XCOMP (e.g. by sending a large volume of data, preventing others from testing) will result in the withdrawal of access to the system.

Step 5: XML test phase for organisations using the E2B(R3) format / Quality assurance testing (QAT)

Sample test cases need to be sent as XML files to the receiver identifier specified in the safety message as either EVTEST or EVCTMTEST in XCOMP. Organisations are required to follow ICH E2B guidance and assign their own C.1.1 ‘Sender’s (case) safety report unique identifier’ to the test cases.

This will allow EMA to check if the XML files are correct and comply with the required specifications: syntax, field lengths, minimum information and data coding against the applicable standard terminology.

This includes the correct use of EDQM-related terminology on Routes of Administration and Dosage Forms, in line with the

Announcement of the EMA Management Board - Confirmation of the mandatory use of the ISO Individual Case Report standard based on ICH E2B(R3) modalities and related ISO standard terminology

 published in December 2019.

The following zip file contains the sample test cases:

• European Union example instances - E2B(R3) testing files

Depending on the available software it may be necessary to manually set a receiving organisation identifier within the XML file.

The messages need to be loaded into the organisation's system and then sent back to EVTEST or EVCTMTEST, as applicable.

In every case a suspect medicine called 'Spare drug' has been included, enabling the organisation to import and process a case for its own medicine. It has 'Spare MAH' as the marketing authorisation holder and 'Spare substance' as the substance. It is optional to amend any of the fields populated in this section, but none of the other drug sections may be changed and no other fields may be added to this medicine. The medicine is not referenced in the narrative.

For cases 1-6, 9 and 10, the only allowed changes are for the following fields / sections:

• safety report ID (C.1.1);
• receive date (C.1.4);
• receipt date (C.1.5);
• suspect medicine 'Spare drug' and the populated fields within that section.

For cases 7 and 8, there are specific instructions in the sender's comment field on what follow-up to do. Testers need to send the first versions of these two ICSRs together with the other ICSRs (making the same changes as in cases 1-6), then make the required additional changes and send them again.

Failing to follow EMA's guidance above and, thus, modifying the test cases beyond what was requested (namely by adding, deleting or editing data) will result in unsuccessful EV QAT. In this scenario, organisations will be requested to correct the error(s) and resubmit the test case(s), which will prolong the QAT process.

Notes

EMA operates the QAT Service Desk on a first come, first served basis. However, the Agency aims to provide an initial assessment within two weeks of raising a request.

The QAT process can be lengthy, depending on the number and types of issues EMA may detect and on how long a company takes to properly address the raised issues.

Organisations will be asked to address all the issues detected before submitting updated test cases for review.

The QAT process can be completed in two weeks if the sender has performed a correct sender side validation (step 4) in advance.

If the sender has not performed their own validation correctly, the average time to QAT completion is three months.

Therefore, organisations should factor in time for the QAT to be completed, i.e. have enough time to accommodate any potential delays.

In addition, a high number of requests in the QAT queue may prolong the process further.

Software vendors should NOT raise multiple EV QAT requests at the same time or raise new EV QAT request(s) if they already have one request raised.

If applicable, EMA will confirm the successful completion of the testing via the QAT request service desk ticket. The following disclaimer applies:

The confirmation provided upon completion of the testing process through the EudraVigilance test system (XCOMP) is for information purposes only, and does not entail any implicit or explicit recommendation or endorsement by the Agency. The EDI partner is restricted from using this confirmation as an endorsement by the Agency.

By confirming the completion of the testing process the Agency makes no warranty of any kind, implicit or explicit, including, without limitation, the implied warranty of merchantability, fitness for a particular purpose, non-infringement and data accuracy of the software. The Agency neither represents nor warrants that the operation of the software will be uninterrupted or error-free, or that any defects will be corrected. The Agency does not warrant or make any representations regarding the use of the software or results thereof including but not limited to the correctness accuracy, reliability, or usefulness of the software.

Step 6: Production

EDI partners who are in the EDI process with EudraVigilance or using their locally established pharmacovigilance system need to acknowledge that for all legal and regulatory purposes, a safety or acknowledgement message or a message disposition notification (MDN) is just as valid as an equivalent paper document.

Once all tests are successfully completed, production can start with operational electronic transmission of ICSRs.

EDI partners must communicate major technical changes immediately in writing to EMA. Major technical changes may require re-testing as described above.

Preparing for the electronic exchange of product reports

Step 1: Register with EudraVigilance

To complete the registration of a new marketing authorisation holder (MAH) and/or sponsor organisation for the submission of XEVPRMs in the new XEVPRM community, organisations should follow the processes described in: EudraVigilance: how to register.

Organisations who wish to use a local gateway can perform transmission testing and load XEVPRMs using the XCOMP environment. MAHs/sponsor organisations wishing to use EVWEB for XEVPRM submissions can skip to step 5.

Step 2: Obtain EudraVigilance gateway certification

Organisations need to obtain a certification to use the EudraVigilance gateway. EMA does not mandate any particular software for the electronic reporting of XEVPRMs, however, the software needs to adhere to the standards outlined in chapter I.C.2.1.5.2 Gateway configuration and communication testing of:

European Union individual case safety report (ICSR) implementation guide

Adopted Consultation dates: 30/04/2014 to 30/06/2014 Reference Number: EMA/51938/2013 Rev. 2 Summary:

This guidance specifies the technical requirements and the process of transmission of individual case safety reports (ICSRs) and is applicable to all stakeholders, which are exchanging ICSRs electronically within the European Economic Area.

Step 3: Communication test

This test will assure successful gateway-to-gateway communication. To establish the connection, organisations need to:

• document their transport choice;
• exchange profile information;
• exchange public keys for encryption,
• test the connection.

Once a successful connection has been established, safety and acknowledgement messages can be transferred between each party in the programme by sending an encrypted safety and acknowledgement message to the EudraVigilance gateway. Here, it will be decrypted, checked for basic accuracy, then re-encrypted and sent to the ultimate destination.

This test is required between EMA and all organisations except national competent authorities (NCAs) – the EudraVigilance gateway already links to all NCAs in the EEA.

Once the communication testing has been completed successfully, EMA will certify this and the organisation can move on to the next stages of testing.

Step 4: Development and validation tests

Electronic data interchange (EDI) partners carry out their own development and validation testing with the external compliance testing environment (XCOMP).

This step is required to test the data exchange between EMA and the MAH/sponsor organisation. Other EDI partners may follow the same step.

Step 5: Production

EDI partners who are either in the EDI process with EMA or using their locally established pharmacovigilance system need to acknowledge that for all legal and regulatory purposes, a product or acknowledgement message or a message disposition notification (MDN) is just as valid as an equivalent paper document.

Once all tests are successfully completed by gateway users, production can start with operational electronic transmission of medicinal product messages.

Major technical changes must be communicated immediately in writing between the electronic data interchange partners. Major technical changes may require both test phases to be re-initiated.

Masking of personal data in ICSRs/SUSARs submitted to EudraVigilance

The European Medicines Agency (EMA) has published the GVP Module VI Addendum II – Masking of Personal Data in Individual Case Safety Reports Submitted to EudraVigilance. This addendum was developed at the request of the European Data Protection Supervisor, in collaboration with the EU Network and the EudraVigilance Expert Working Group.

The addendum provides supplementary guidance to Section VI.C.6.2.2.10 on data protection laws in GVP Module VI and it outlines the specific data elements that must be masked or omitted when submitting Individual Case Safety Reports (ICSRs) to the EudraVigilance database. These instructions are considered an integral part of the existing GVP Module VI guidance.

In addition, the addendum considers the data elements necessary to fulfil pharmacovigilance and safety monitoring obligations as defined in EU pharmaceutical legislation.

All ICSR/SUSAR senders are expected to implement the instructions outlined in this document as soon as possible and within a reasonable timeframe.

ICSR compliance and quality

EMA operates robust quality assurance processes to help ensure the accuracy, completeness, and integrity of data submitted to EudraVigilance and the XEVMPD. These processes are aligned with EU pharmacovigilance legislation and Good Pharmacovigilance Practices, particularly GVP Module VI, forming the foundation for reliable pharmacovigilance activities. Two key initiatives undertaken by the Agency support these goals:

Compliance monitoring of reporting timelines

Following a successful pilot programme, EMA has introduced automated compliance monitoring for reporting timelines defined in EU legislation.

Since September 2025, marketing authorisation holders, sponsors of clinical trials, and National Competent Authorities receive monthly compliance reports generated by EVDAS. These reports cover submissions made to EudraVigilance in the previous month and track adherence to the 7-/15-/90-day reporting timelines for ICSRs and SUSARs.

This initiative strengthens timely and accurate data submission, ensuring regulatory compliance and supporting patient safety across the EU.

For more information, please refer to the following document:

• Compliance notifications explanation and Q&A

Data management and quality assurance

EMA is committed to help maintaining the highest standards of data quality in EudraVigilance whilst monitoring the compliance with the legally defined timelines in the EU pharmacovigilance legislation. To achieve this, the Agency performs multiple checks and tasks. Key activities include:

• validation and verification of ICSRs and medicinal product data to ensure consistency and compliance with regulatory standards;
• duplicate detection and management, preventing redundant or conflicting case information;
• automated and manual database checks to maintain data reliability for signal detection and other pharmacovigilance processes.

Through these measures, adherence to regulatory requirements is monitored, ensuring that pharmacovigilance activities produce accurate, high-quality outcomes.

For more information, please refer to the following document:

• Detailed guide regarding the EudraVigilance data management activities by the European Medicines Agency

What to do in case of system failure

Organisations should make sure that adequate business continuity processes and back-up systems are in place to deal with system failures in line with the recommendations given in good pharmacovigilance practices (GVP) Module I.B.11.3. 'Critical pharmacovigilance processes and business continuity'. This will ensure that any system failures can be resolved within a short period of time and reporting compliance is maintained.

EMA does not accept CIOMS I forms. This option should not be part of the business continuity process.

Gateway failure at the sender's side

If a gateway failure occurs at the sender's side, but the organisation is able to generate valid safety message(s), they should submit these primarily via the EVWEB application or EVPOST.

The organisation does not need to inform EMA, unless it is unable to comply with the 7, 15 or 90-day timelines set in legislation. 

If the organisation is unable to comply with set timelines, they should write to [e-mail]. For more information, see Contacts at EMA (under 'Compliance issues with pharmacovigilance obligations').

Users should note that if their profile is set up to make submissions as a gateway trader and they wish to use the EVWEB application or EVPOST functionality instead, they should use a separate 'Affiliate' or 'Virtual Affiliate' profile that has been set up as a webtrader. More information is available in the EudraVigilance registration manual below (under section 6.2).

EudraVigilance registration manual

Reference Number: EMA/13454/2020 Rev.16

EudraVigilance - EVWEB user manual

Reference Number: EMA/501718/2018 Version 1.11

They should send no more than 50 cases in a single XML file (EVPOST) or in a batch transmission of ICSRs (EVWEB). More information is available in the document below (question 2.118).

Launch of the new EudraVigilance system: questions and answers from stakeholders

Reference Number: EMA/132042/2018 Version 1.7 Summary:

The launch of the new EudraVigilance system: questions and answers from stakeholders

Only if this arrangement is not possible, users should contact EMA Service Desk (Tel. [phone]) to inform EMA of the issue. Users should explain in the request that they are experiencing gateway system failure at the sender's level, and include why they are not able to use EVWEB or EVPOST for the submission. 

Users have two options, depending on the volume of the data to be submitted.

If the data volume is small, they can use Eudralink to submit the valid E2B (R3) XML files to an email address provided by EMA in response to their EMA Service Desk request. 

EMA will manually process these files.

If the data volume is large, they can send the data (valid E2B (R3) XML files) to EMA via physical media (CD-ROM or DVD). Users should obtain prior agreement from EMA via the EMA Service Desk request before pursuing this arrangement.

They will receive acknowledgment messages for the reports received on physical media via EudraVigilance gateway. Since no ICSR-MDN will be generated in this process, the date of dispatch of the physical media will be sufficient to prove regulatory compliance.

Failure of message receipt by the EudraVigilance gateway at EMA level

In the event of prolonged unavailability of the EudraVigilance gateway, including the EV-Post function, which could affect the sender's ability to meet regulatory reporting timeframes, the report sender can send the ICH E2B(R3) safety messages to EMA when the gateway becomes available again. Reports submitted within two EMA business days of the gateway being made available again will have their reporting compliance calculated against the first day of system failure.

EMA will provide the official dates of when the EudraVigilance gateway was unavailable.

Failure of the EudraVigilance web application

In the event of prolonged unavailability of the EudraVigilance web application during EMA business hours which could affect the sender's ability to meet regulatory reporting timeframes, the report sender should send the safety messages to EMA when the web application becomes available again. These reports will be excluded from reporting compliance monitoring as long as they are submitted within two EMA business days of the EudraVigilance web application becoming available again.

Page update history

An update log is available to show the date and summary of changes to this webpage. It does not include updates to linked documents or minor edits like typos or broken link fixes.

The tracking of updates begins in February 2026.

See update history

24 February 2026

Section 'Step 5: XML test phase for organisations using the E2B(R3) format / Quality assurance testing (QAT)' updated with added information about ICH E2B guidance.

Section 'ICSR compliance and quality' added.

Section 'List of reference documents' added.