Safety / PV Database
Pharmacovigilance Database (Safety Database)
The safety database is the system of record for pharmacovigilance: every individual case safety report an organisation receives — from trial sites, healthcare professionals, patients, literature screening, licensing partners, and market programmes — is entered, coded, assessed, and dispatched to regulators from this system. A case moves through a defined lifecycle: intake and triage, duplicate checking, data entry, coding of events and drugs against controlled dictionaries, assessment of seriousness, expectedness, and causality, medical review, and submission. The definitions the whole machine runs on — what makes an event serious, what makes it unexpected — come from ICH E2A, and they decide which regulatory clock starts ticking.
What this page does not claim
A system class is not a product. SPEQ describes what a CTMS or a LIMS is; the vendor directory at /tools lists the products that implement one, and a GAMP category is a property of an implementation, not of a class.
What a Safety / PV Database actually is
The safety database is the system of record for pharmacovigilance: every individual case safety report an organisation receives — from trial sites, healthcare professionals, patients, literature screening, licensing partners, and market programmes — is entered, coded, assessed, and dispatched to regulators from this system. A case moves through a defined lifecycle: intake and triage, duplicate checking, data entry, coding of events and drugs against controlled dictionaries, assessment of seriousness, expectedness, and causality, medical review, and submission. The definitions the whole machine runs on — what makes an event serious, what makes it unexpected — come from ICH E2A, and they decide which regulatory clock starts ticking.
The clocks are the defining pressure of the class. A trial sponsor must submit an IND safety report for a serious and unexpected suspected adverse reaction within 15 calendar days of first awareness — 7 for an unexpected fatal or life-threatening one — under 21 CFR 312.32; the marketed-product analogue is the 15-day alert report under 21 CFR 314.80; and the EU runs equivalent expedited timelines into EudraVigilance under GVP Module VI. Day zero starts when anyone in the organisation first learns of a valid case, not when the safety team does, and compliance is measured case by case. A safety database is therefore built around the clock: every case carries its due dates, and late submissions are the metric a pharmacovigilance inspection reads first.
Transmission is standardised: the ICH E2B(R3) format defines the electronic individual case safety report exchanged with FDA, EMA, and other authorities and partners, and the database's rules engine decides, per case, which destinations must receive it, in which format, on which timeline — one case can obligate a dozen submissions under different national rules. Beyond the single case, the database is the substrate for everything aggregate: periodic reports such as the PBRER under ICH E2C(R2) and the EU periodic safety update report regime, development safety update reports for trials, and the signal-management work of GVP Module IX, which mines the accumulated case series for patterns no single report reveals.
It is among the most heavily inspected system classes in the industry. EU pharmacovigilance inspections test the system the QPPV formally owns and describes in the pharmacovigilance system master file; FDA inspections reconstruct case handling against the regulations directly. Validation expectations are correspondingly strict — GAMP 5 Category 4 as the working posture, with the reporting-rules engine, expedited-timeline calculations, and E2B(R3) transmission behaviour verified with the rigour their consequences deserve, and 21 CFR Part 11 controls on records, signatures, and audit trails throughout. The database also cannot be an island: it reconciles against the clinical database for trial SAEs and exchanges cases with partners under agreements whose timelines are contractual as well as regulatory.
WHERE THE BOUNDARY ACTUALLY SITS
Not the clinical database. An SAE captured on an eCRF is clinical data; the safety case built from it is a separate record of record in the PV database, and the two are reconciled field by field before database lock.
EDC owns it →Not the complaint system. A product-quality complaint lives in the eQMS; when a complaint carries an adverse event — or a case suggests a quality defect — the record must flow both ways, and the interface between the two is a classic inspection probe.
eQMS owns it →Not the signal-analytics environment in every deployment. Statistical signal detection often runs in separate analysis tooling over the case series, but the cases of record — and the audit trail of what was reported — remain in the safety database.
Not the aggregate-report author. PBRERs and PSURs draw their case listings and summary tabulations from the database, but the documents are authored, reviewed, and submission-tracked outside it.
RIM owns it →WHAT IT HOLDS, AND WHAT CROSSES ITS BOUNDARY
CORE RECORDS
- Individual case safety reports across their full version history, with audit trail from intake to final
- Source documents attached to each case — the reporter's account, records, and follow-up correspondence
- Coded event, indication, and drug data against controlled dictionary versions
- Seriousness, expectedness, and causality assessments, with the medical review behind them
- Submission records per destination — what was sent where, when, in what format, and the acknowledgement received
- Regulatory-clock and compliance data: day zero, due dates, and on-time performance per case
- Duplicate-search and case-merge records preserving what was combined and why
DATA FLOWS OUT
Case listings and summary tabulations feeding aggregate safety reports, and the submission tracking of those reports
Cases indicating a possible product-quality defect routed into complaint investigation — and complaint-sourced adverse events received back
Reconciliation output on trial SAEs — discrepancies between the safety case and the clinical database queried back before lock
HOW THIS CLASS IS USUALLY VALIDATED
- SPEQ synthesis: safety databases are configured commercial platforms — GAMP 5 Second Edition (2022) Category 4 — but they sit at the strict end of that category's spectrum, because the configuration under test includes the reporting-rules engine that decides which authority receives which case on which clock. A rules defect does not look like an error; it looks like a late or missing submission discovered by an inspector. The category is a property of the implementation, not the product.
- Expedited-timeline logic is verified with scripted evidence across the awkward cases: day-zero determination from different intake routes, clock resets on significant follow-up, downgrades and upgrades of seriousness, and the divergent national rules a single case can trigger.
- E2B(R3) transmission is tested end to end — generation, gateway exchange, and acknowledgement processing — because a case the organisation believes was submitted, but for which no acknowledgement exists, is a compliance failure hiding as a success.
- Dictionary upgrades are a recurring validated activity, not maintenance: recoding impact on existing cases, expectedness assessments, and signal continuity is assessed and evidenced at every version step.
SPEQ synthesis, not a rating. This is SPEQ’s reading of how this system class is commonly approached, offered to help you scope your own work. A GAMP category is a property of a specific implementation, not of a product class, and one deployment routinely spans several. It is not a classification service and does not replace your own documented risk assessment.
- Stage 1 · Reactive
Cases arrive by email and spreadsheet, day zero is whenever the safety team noticed, and expedited submissions are tracked by hand. Late reports are discovered at inspection, duplicates inflate the case series, and reconciliation with the clinical database happens at lock, in crisis.
- Stage 2 · Defined
A validated safety database manages the case lifecycle with defined workflows, coding, and submission tracking. Compliance metrics exist but are compiled retrospectively, follow-up is chased manually, and the reporting rules are trusted rather than periodically re-verified against changing national requirements.
- Stage 3 · Controlled
Intake routes are controlled so day zero is captured at first receipt anywhere in the organisation, duplicate detection and follow-up scheduling are systematic, reconciliation with the EDC runs on a cadence, and on-time performance per destination is known continuously — not assembled for the PSMF.
- Stage 4 · Predictive
Case processing is measured and tuned: quality sampling targets the assessments that matter, workload models absorb volume spikes without timeline erosion, and signal detection runs on a defined statistical cadence with a documented path from signal to evaluation to action under GVP Module IX.
- Stage 5 · Adaptive
The pharmacovigilance system operates as a learning loop: automation carries the clerical load of intake and triage under human accountability, cross-source data sharpens detection, and safety insight flows back into risk-management planning and benefit-risk decisions ahead of the regulator's question.
SPEQ’s shared five-stage progression, labelled synthesis. It is not the FDA QMM rating scale and not the scored maturity-assessment domains — assess your quality system for those.
WHAT AN INSPECTION PROBES, AND WHERE IT GOES WRONG
INSPECTION SIGNALS
- On-time submission performance, case by case and destination by destination — the first metric a pharmacovigilance inspection pulls.
- Day-zero discipline: whether the clock starts at first receipt anywhere in the organisation, including partners, sales staff, and medical information lines.
- Reconciliation between the safety database and the clinical database for trial SAEs, and between the safety database and the complaint system for quality-related cases.
- Whether the database the inspector sees matches the pharmacovigilance system the PSMF describes — including the compliance metrics the QPPV is accountable for.
- Follow-up pursuit: whether incomplete cases show documented, timely attempts to obtain the missing information rather than quiet closure.
COMMON RISKS
- Reporting-rule configuration drifting behind changing national requirements, producing systematically late or missing submissions to one authority while every dashboard shows green.
- Day zero anchored to the safety department's receipt rather than the organisation's first awareness, silently shortening every clock the inspector will recalculate.
- Submissions without acknowledgement tracking, so gateway failures accumulate as unnoticed non-submissions.
- Duplicate cases from multiple intake routes inflating — or, merged wrongly, deflating — the case series that signal detection runs on.
- Partner-exchange timelines in safety data exchange agreements that are incompatible with the regulatory clock they feed, making lateness structural.
WHO WORKS IN IT, AND WHERE IT IS SHAPED
ROLES
- Drug safety associate / case processor
- Pharmacovigilance physician / medical reviewer
- QPPV and deputy
- PV compliance and submissions specialist
- Safety database administrator / business owner
- CSV analyst
DELIVERY-LIFECYCLE PHASES
[ POSITION IN THE FRAMEWORK ]
6 OF 7 DIMENSIONS · 24 LINKSThe pharmacovigilance system of record — where individual case safety reports are processed, coded, assessed, and submitted on the regulatory clock; among the most heavily inspected system classes, built around the day-zero clock.
06 · QUALITY MATURITY — SAFETY / PV DATABASE, REACTIVE TO ADAPTIVE
Cases arrive by email and spreadsheet, day zero is whenever the safety team noticed, and expedited submissions are tracked by hand. Late reports are discovered at inspection, duplicates inflate the case series, and reconciliation with the clinical database happens at lock, in crisis.
A validated safety database manages the case lifecycle with defined workflows, coding, and submission tracking. Compliance metrics exist but are compiled retrospectively, follow-up is chased manually, and the reporting rules are trusted rather than periodically re-verified against changing national requirements.
Intake routes are controlled so day zero is captured at first receipt anywhere in the organisation, duplicate detection and follow-up scheduling are systematic, reconciliation with the EDC runs on a cadence, and on-time performance per destination is known continuously — not assembled for the PSMF.
Case processing is measured and tuned: quality sampling targets the assessments that matter, workload models absorb volume spikes without timeline erosion, and signal detection runs on a defined statistical cadence with a documented path from signal to evaluation to action under GVP Module IX.
The pharmacovigilance system operates as a learning loop: automation carries the clerical load of intake and triage under human accountability, cross-source data sharpens detection, and safety insight flows back into risk-management planning and benefit-risk decisions ahead of the regulator's question.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 8
Derived from the 8 standards SPEQ maps to this subject, across 4 regulatory bodies: FDA, ISPE, EMA, ICH.
RECORDS & OBJECTIVE EVIDENCE
- Individual case safety reports across their full version history, with audit trail from intake to final
- Coded event, indication, and drug data against controlled dictionary versions
- Seriousness, expectedness, and causality assessments, with the medical review behind them
- Submission records per destination — what was sent where, when, in what format, and the acknowledgement
- Regulatory-clock and compliance data: day zero, due dates, and on-time performance per case
COMMON INSPECTION FINDINGS
- Late or missing expedited submissions, case by case and destination by destination
- Day zero anchored to the safety department's receipt rather than the organisation's first awareness
- Reporting-rule configuration drifting behind changing national requirements
- Submissions without acknowledgement tracking, so gateway failures accumulate unnoticed
- Trial-SAE discrepancies between the safety database and the clinical database left unreconciled
Choosing, validating, and living with Safety / PV Database
FREQUENTLY ASKED
What is an ICSR and when does the reporting clock start?
An individual case safety report is the record of a single suspected adverse reaction in a single patient, and it becomes reportable — a valid case — when four minimum elements exist: an identifiable patient, an identifiable reporter, a suspect medicinal product, and an adverse event. Day zero is the first day anyone in the organisation, or a partner acting for it, holds all four — not the day the case reaches the safety department. From day zero, the applicable clock runs: 15 calendar days for expedited cases under 21 CFR 312.32 and 21 CFR 314.80, 7 days for the initial IND report of an unexpected fatal or life-threatening suspected adverse reaction.
What is ICH E2B(R3)?
The international standard format for transmitting individual case safety reports electronically. E2B defines the structured data elements a case is expressed in — patient, reporter, suspect and concomitant products, events, narratives — so that a case generated in one organisation's database can be received and understood by a regulator's or partner's system without re-entry. The R3 revision is the current generation, exchanged with FDA, EMA's EudraVigilance, and other authorities and partners via electronic gateways. For the safety database, E2B(R3) competence is a validation matter: generating conformant files, transmitting them, and processing the acknowledgements that prove each submission actually arrived.
Why do trial SAEs exist in both the EDC and the safety database?
Because the two systems answer different obligations from the same event. The eCRF captures the SAE as clinical trial data — it will be analysed, listed in the study report, and locked with the database. The safety case built in the PV database serves regulatory reporting: assessed for seriousness, expectedness, and causality, and submitted on the expedited clock where required. The records are created through different routes at different times by different people, so they drift — dates, terms, outcomes — and reconciliation before database lock exists to find and resolve every discrepancy. An unreconciled difference is a data-integrity finding in both directions.
How is a safety database validated compared with other clinical systems?
With the same framework and less forgiveness. Like its neighbours it is configured commercial software — GAMP 5 Category 4 — but the functions under test have direct regulatory consequence: the rules engine that routes each case to the right authorities, the timeline calculations that set expedited due dates, the E2B(R3) generation and acknowledgement handling, and the audit trail on every assessment. These earn scripted, evidence-heavy verification even in an organisation that leans CSA elsewhere, and the work recurs: every reporting-rule change, dictionary upgrade, and new destination re-opens the exercise. 21 CFR Part 11 controls on records and signatures apply throughout.