Safety Databases · Section 10.5
~6 min read · The Drug Safety Coach — Global PV Career Course
Key points
Full text
Every case that ends up in a safety database, however it’s eventually coded, assessed, and analysed, starts with intake: receiving a source document, whatever form it arrives in — a spontaneous report form, a physician’s letter, a literature article, a regulatory authority forward, a call centre transcript — and beginning the formal process of turning it into a structured case record.
Before that record is finalised, duplicate search is a critical, often underappreciated step. The same real-world adverse event can genuinely arrive at an organisation through multiple independent channels — a patient calls the company directly, their physician separately submits a report to a regulator who forwards it to the company, and the same event later shows up described in a published case report the company’s literature monitoring catches. Without deliberate duplicate detection, that single real event risks being booked in as two or three separate cases, each looking legitimate in isolation.
This isn’t just an administrative tidiness concern — it has genuine downstream consequences that connect directly back to Module 7. Disproportionality analysis, and every case count feeding into a PBRER’s data summary tabulations from Module 8, assumes the cases being counted represent distinct events. A missed duplicate inflates that count, potentially making a drug-event pair look more disproportionately reported than it genuinely is — a false signal manufactured not by a real safety issue, but by the same event being counted multiple times.
Book-in is the formal culmination of intake: creating the actual case record in the database and assigning it a unique case number, the point at which the case genuinely exists as a trackable entity in the system, ready to move into the workflow routing Lesson 10.6 covers next. Getting intake and duplicate search right — thoroughly, before book-in — is exactly the kind of unglamorous foundational discipline that everything more visible later in the case’s life, from coding through signal detection, quietly depends on.
Important
Duplicate detection is a genuinely high-stakes step, not a housekeeping formality. If the same real-world adverse event gets booked into the database as two or three separate cases — because it arrived through different channels, described in slightly different terms — every downstream disproportionality calculation and aggregate case count that includes it is inflated. Module 7’s entire signal detection methodology assumes case counts reflect distinct events — duplicate cases quietly violate that assumption.
Quick check
Test yourself before moving on — no pressure, just click an answer.
1. Why does a missed duplicate case have consequences beyond simple administrative clutter?