EudraVigilance: electronic reporting
Marketing authorisation holders and sponsors of clinical trials must report and evaluate suspected adverse drug reactions during the development and following the marketing authorisation of medicinal products in the European Economic Area (EEA). Marketing authorisation holders must also electronically submit information on medicinal products authorised in the European Union (EU).
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.
Interventional clinical trials
| Who | What | Reference |
|---|---|---|
|
| |
|
|
|
Spontaneous reports and non-interventional clinical trials
| Who | What | Reference |
|---|---|---|
|
| |
|
|
The EudraVigilance system does not accept ICSR messages in the ICH E2B (R2) format. This is stated in the
Announcement of the EMA Management Board
(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:
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 | Complete steps 1 to 6 (see testing steps below) |
New organisation using EVPOST and a local safety/pharmacovigilance database | Complete steps 1, 4, 5 and 6 (see testing steps below) |
New organisation using EVWEB | Complete step 1 (see testing steps below) |
Major change (gateway and/or a local safety/pharmacovigilance database) | 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
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:
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.
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.
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:
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:
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. |
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.
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:
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.
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 phv-noncompliance@ema.europa.eu. 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).
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).
Only if this arrangement is not possible, users should contact EMA Service Desk (Tel. +31 (0)88 781 8520) 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.