A pharmacovigilance safety database supports the controlled intake, processing, medical review, reporting and retrieval of individual case safety reports. The appropriate model depends on the product portfolio, case sources, reporting territories, integrations, internal capability and long-term operating strategy.
The database cannot be selected in isolation from the PV process. Its configuration, validation, user access, interfaces and maintenance must reflect the activities described in SOPs and pharmacovigilance agreements.
What should a safety database support?
Depending on the organisation's scope, the system may need to support:
- intake and tracking of safety information from all applicable sources;
- ICSR data capture using the required data elements and controlled terminology;
- duplicate search and case linking;
- seriousness, expectedness and causality workflows;
- medical review and quality-control steps;
- MedDRA coding and version management;
- follow-up management and due-date monitoring;
- electronic ICSR reporting in ISO/ICH E2B(R3) format;
- transmission to EudraVigilance and other applicable authorities;
- acknowledgement receipt, reconciliation and submission-failure management;
- aggregate-report and signal-management data extraction;
- complete audit trails for relevant data and configuration changes;
- role-based access, security, backup, recovery and archiving.
Not every organisation needs to own an enterprise platform. Every organisation does need a controlled way to perform the required activities and evidence how the chosen system remains fit for its intended use.
Own, use a hosted environment or outsource?
| Model | May be appropriate when | MAH or sponsor still needs to control |
|---|---|---|
| Own and operate the database | The organisation has sufficient case volume, internal system ownership, validation capability and long-term need for direct control | Validation, administration, security, maintenance, change control, interfaces, business continuity and vendor oversight |
| Use a hosted or managed database | The organisation wants a dedicated environment without operating all infrastructure internally | Intended use, configuration approval, validation responsibilities, access, service levels, changes, data ownership and exit arrangements |
| Use a PV provider's validated environment | Case volume or portfolio size does not justify a separate platform and operations are substantially outsourced | Oversight, data access, reporting compliance, reconciliation, audit rights, continuity, data return and transition arrangements |
The choice should be based on process and governance requirements rather than licence price alone.
Define requirements before selecting or configuring the system
A useful requirements process starts with the PV operating model and converts it into testable system needs.
Document at least:
- products, territories and report types in scope;
- expected current and future ICSR sources and volume;
- required case workflow and approval steps;
- reporting destinations and transmission modes;
- data standards, terminology and coding requirements;
- interfaces with intake tools, literature systems, clinical systems and regulatory gateways;
- migration and legacy-data needs;
- user roles, segregation of duties and access locations;
- availability, backup, recovery and continuity needs;
- privacy, security, retention and archiving requirements;
- audit-trail, reporting and inspection-access expectations;
- vendor support, incident, problem and change-management processes.
Requirements should be specific enough to evaluate vendors and later demonstrate that the configured system was tested against its intended use.
Validation should follow the system lifecycle
Validation is documented evidence that the configured system is fit for its intended use. The scope and depth should be based on risk, complexity, novelty, configuration and the potential impact of failure on patient safety, data integrity and regulatory compliance.
| Lifecycle stage | Expected evidence |
|---|---|
| Planning and supplier assessment | Intended use, system scope, risk assessment, supplier evaluation, roles and validation plan |
| Requirements and design | Approved user requirements, process mapping, configuration or functional specifications and traceability |
| Build and configuration | Controlled configuration records, environment information and technical verification as applicable |
| Testing | Approved test scripts, expected results, actual results, evidence, deviations and retesting |
| Release | Traceability review, unresolved-risk assessment, validation summary and authorised go-live decision |
| Operation | Access control, incident management, backup, recovery, audit-trail review, training and performance monitoring |
| Change and periodic review | Change impact assessment, proportionate regression testing and documented confirmation that the system remains in control |
| Retirement | Data migration or archive verification, access arrangements and controlled decommissioning |
Supplier documentation can support validation, but it does not replace the organisation's assessment of its own intended use, configuration, interfaces and procedures.
View EU EudraLex Volume 4 and Annex 11
Database migration requires more than moving records
A safety database migration should protect the meaning, integrity and traceability of safety data.
The migration plan should address:
- source and target data models;
- field mapping and transformation rules;
- case relationships, null values, attachments and audit-history treatment;
- MedDRA and other controlled-terminology versions;
- duplicate management and case-number strategy;
- reconciliation of record counts and critical data;
- sampling or full verification based on risk;
- electronic-reporting and downstream-interface testing;
- cutover, freeze periods and business continuity;
- ownership of legacy access and retention;
- approved acceptance criteria and migration reporting.
The receiving system should not go live until the organisation can demonstrate that migrated data are complete enough, accurate enough and accessible for the intended PV processes.
EudraVigilance and E2B(R3) interfaces
Where the safety database connects to EudraVigilance through a gateway, the implementation should cover more than successful transmission of one test message.
The operating process should define:
- generation of compliant E2B(R3) messages;
- sender and receiver identifiers;
- routing and report classification;
- acknowledgement processing;
- rejected or failed-message handling;
- duplicate and follow-up logic;
- downtime and manual contingency procedures;
- reconciliation between the database and EudraVigilance;
- monitoring of submission compliance and unresolved acknowledgements.
Review EudraVigilance and XEVMPD responsibilities
Maintaining the validated state
Control continues after go-live. The organisation should maintain documented processes for:
- user creation, modification, removal and periodic access review;
- training before access and after relevant changes;
- incidents, service requests, problems and deviations;
- software releases, patches and configuration changes;
- validation-impact assessment and regression testing;
- MedDRA and controlled-terminology updates;
- backup monitoring and recovery testing;
- interface, acknowledgement and submission monitoring;
- vendor performance and service-level review;
- audit-trail review where required by procedure or risk;
- periodic review of system performance, compliance and fitness for use;
- data retention, archiving and inspection access.
The frequency of each control should follow the approved risk assessment, procedure and service model rather than an unsupported universal schedule.
Vendor oversight and exit readiness
If a vendor hosts or operates the database, the agreement should define:
- data ownership and permitted processing;
- system and service responsibilities;
- validation-document access;
- security, privacy and breach notification;
- availability, backup, recovery and incident escalation;
- planned and emergency changes;
- audit rights and inspection support;
- reporting, metrics and governance meetings;
- subcontractor controls;
- data export, transition support and termination arrangements.
An exit plan matters from the start. The organisation should know how it will obtain usable case data, attachments, configuration information and required records if the provider or platform changes.
How NextPV can support a safety database project
NextPV can support:
- operating-model and requirements definition;
- database and vendor evaluation;
- validation strategy and risk assessment;
- user requirements and process mapping;
- configuration and workflow review;
- validation planning, testing and summary documentation;
- migration planning and verification;
- EudraVigilance interface and reconciliation processes;
- SOPs, work instructions and user training;
- vendor oversight and service governance;
- periodic review, change assessment and inspection readiness.
We can support a dedicated database implementation or provide access to an appropriate database model as part of a wider outsourced PV service.
Related NextPV guidance
- EU Market Entry pharmacovigilance
- EudraVigilance and XEVMPD
- PV systems, PSMF and quality management
- All NextPV pharmacovigilance services
Discuss your safety database model
Share your product portfolio, case model, reporting territories, existing technology and planned change. We will help identify the system, validation and oversight workstreams that need to be controlled.
Prepared and reviewed by the NextPV Pharmacovigilance Team · Updated July 2026