EudraVigilance is the European system for exchanging and analysing individual case safety reports for authorised medicines and investigational products in the EEA. XEVMPD, also known as the Article 57 database, holds structured information on authorised and investigational medicinal products.
Compliance depends on more than registration. Organisations need controlled user roles, trained users, an appropriate reporting mode, maintained product data, acknowledgement handling, reconciliation and clear ownership between the MAH or sponsor, QPPV or Responsible Person, database team and service providers.
The EudraVigilance components in practical terms
| Component | What it is used for |
|---|---|
| EudraVigilance | EU system supporting electronic ICSR exchange and safety-data analysis |
| EVWEB | Web application for creating, viewing and submitting ICSRs through EudraVigilance |
| Gateway | System-to-system transmission route used by organisations sending messages from a safety database or reporting platform |
| EVDAS | Data-analysis environment used for access to EudraVigilance data according to the organisation's role and applicable access policy |
| XEVMPD / Article 57 database | Structured medicinal-product information submitted using XEVPRM messages |
| EMA Account Management and OMS | Account and organisation-management services used as part of registration and access control |
Each component has a different purpose. Access to one function does not automatically mean that registration, reporting, product-data and analytical-access requirements are all complete.
View the EMA EudraVigilance overview
Who owns what?
| Role | Core responsibility |
|---|---|
| Marketing authorisation holder | Ensure that reporting and product-data obligations are fulfilled and that delegated activities are appropriately controlled |
| EU QPPV | Be registered for the MAH, maintain appropriate oversight and control or approve relevant user and delegation arrangements |
| Regulatory contact point | Provide an MAH contact route for applicable EMA regulatory communication |
| Sponsor Responsible Person for EudraVigilance | Represent a commercial or non-commercial sponsor for EudraVigilance registration and user administration |
| Trusted deputy or authorised user | Perform delegated access-administration or operational functions within approved permissions |
| PV operations or database team | Create, review, transmit and reconcile reports according to the approved process |
| Third-party service provider | Perform contracted activities on behalf of the registered MAH, applicant or sponsor within the access and oversight model |
A CRO or IT vendor does not replace the MAH or sponsor as the regulated organisation. The agreement and system access should reflect that relationship.
EudraVigilance registration and access setup
The implementation sequence should cover:
- Confirm the legal organisation and role: MAH, applicant, commercial sponsor or non-commercial sponsor.
- Create or confirm active EMA accounts for the relevant users.
- Register or verify the organisation in EMA's Organisation Management Service.
- Nominate and register the EU QPPV for an MAH or the Responsible Person for a sponsor.
- Establish the regulatory contact point where applicable.
- Select the intended reporting mode and complete the required registration documentation.
- Request and approve user roles based on responsibilities.
- Complete required training or competency steps for the selected functions.
- Test the reporting route, acknowledgements and operational procedures.
- Document ongoing user administration, changes, contingency and reconciliation.
View EMA's current EudraVigilance registration instructions
EVWEB or gateway?
The reporting mode should be selected based on the operating model rather than a universal case-volume threshold.
EVWEB may be suitable when:
- the organisation needs a web-based reporting route;
- case entry and submission can be managed within the EVWEB process;
- direct database integration is not justified;
- trained users and appropriate contingency coverage are available.
A gateway may be suitable when:
- ICSRs are managed in a safety database or reporting platform;
- system-to-system transmission is part of the approved architecture;
- message generation, acknowledgements and reconciliation can be validated and supported;
- the organisation can maintain the technical and operational controls.
The decision should consider volume, workflow, database architecture, validation, support, business continuity and the total operating model.
ICSR reporting needs an end-to-end control process
The documented process should address:
- applicable reportability and reporting timelines;
- data collection, coding, medical review and quality control;
- ISO/ICH E2B(R3) message creation;
- sender and receiver identifiers;
- initial, follow-up, nullification and amendment handling;
- successful and failed acknowledgements;
- duplicate management;
- gateway or EVWEB downtime;
- submission reconciliation;
- overdue, failed or unresolved-report escalation;
- retention of submission and acknowledgement evidence.
Technical transmission does not by itself demonstrate compliance. The organisation should be able to reconcile what was due, what was sent, what was accepted and what still requires action.
View EMA's EudraVigilance electronic-reporting guidance
XEVMPD and Article 57 product data
Marketing authorisation holders submit and maintain structured information on authorised medicines in the Article 57 database. XEVPRM is the message format used to submit data to XEVMPD.
Product-data governance should define:
- the source of approved product information;
- ownership of initial submissions and updates;
- review and approval before transmission;
- product, substance, organisation and authorisation identifiers;
- handling of variations, transfers, withdrawals and other lifecycle changes;
- acknowledgement review and correction of rejected messages;
- reconciliation between authorised product information and XEVMPD records;
- coordination with QPPV and regulatory-affairs changes.
Changing the QPPV or organisation data in one EMA system should not be assumed to update every medicinal-product record automatically. Each affected process should be checked.
View EMA's current XEVMPD submission guidance
Prepare for IDMP without neglecting current obligations
EMA's SPOR and ISO IDMP programmes are changing how medicinal-product data are standardised and managed. Implementation timelines and detailed requirements continue to evolve.
Organisations should:
- keep current XEVMPD data accurate;
- maintain controlled substance, product, organisation and referential data;
- monitor current EMA implementation guidance;
- assess the impact on regulatory, safety and master-data systems;
- include data ownership and transition capability in vendor decisions.
Future IDMP work does not remove current EudraVigilance or Article 57 obligations.
How NextPV can support EudraVigilance and XEVMPD
NextPV can support:
- registration and role-model planning;
- QPPV, Responsible Person and user-access coordination;
- EVWEB or gateway operating-model assessment;
- reporting-process and acknowledgement workflow design;
- E2B(R3) implementation and testing support;
- reconciliation and compliance-monitoring procedures;
- XEVMPD product-data submission and maintenance processes;
- SOPs, work instructions and training;
- vendor oversight, issue remediation and inspection readiness;
- transition support when the organisation, QPPV, database or provider changes.
Related NextPV guidance
- EU Market Entry pharmacovigilance
- EU QPPV and local pharmacovigilance services
- Safety database setup and validation
- All NextPV pharmacovigilance services
Discuss your EudraVigilance or XEVMPD setup
Share your organisation type, product stage, reporting mode, safety database and current registration status. We will help identify the access, data, process and ownership steps that remain open.
Prepared and reviewed by the NextPV Pharmacovigilance Team · Updated July 2026