ICSR management software built around one case record you can defend
Every report, every follow-up, every coded term, every assessment, and every submission attached to a single versioned case — so the question "show me the history of this case" has an answer that takes seconds, not days.
Where ICSR management usually breaks down
The individual case safety report is the atomic unit of pharmacovigilance, and almost every compliance finding traces back to something that happened to a case record — a missed duplicate, a lost follow-up, an untraceable assessment, a deadline nobody was tracking.
The same event processed twice
When the same case arrives from a call centre, a partner, and a literature article, without duplicate detection at intake you process it three times and submit it three times.
Follow-ups that overwrite history
If a follow-up edits the case in place rather than creating a new version, the record of what was known and reported at the time of the original submission is gone.
Assessments without traceable basis
A listedness call is only defensible if you can show which datasheet version was in force when it was made — and who made it.
Deadlines tracked outside the system
When the reporting clock lives in a spreadsheet rather than on the case, the on-time submission metric is a manual count and a late submission is discovered after the fact.
PVgenix holds all of it on the case: duplicate checks at intake, a new version for every follow-up, assessments recorded against the reference safety information version in force, and the regulatory clock running on the record itself with alerts before it expires.
What the case record carries
An ICSR in PVgenix is not a form — it is an accumulating record with its own history, its own obligations, and its own audit trail.
Intake from every channel
Email, messaging and social channels, a web reporter portal, and file and API intake, all resolving into the same structured case record regardless of how the report arrived.
See how it worksDuplicate detection before the queue
Inbound reports are matched against the existing case population so the same event is recognised rather than processed again.
See how it worksFollow-up tracking and versioning
Each follow-up creates a new case version, preserving exactly what was known — and what was reported — at every earlier point.
See how it worksCoding with version control
MedDRA and WHO Drug Dictionary coding with admin-controlled dictionary versions, auto-coding, and a recorded manual override on any term.
See how it worksAssessment with recorded basis
Seriousness, company and reporter causality, and expectedness against version-controlled CCDS/CCSI, SmPC, and USPI — each with attribution and rationale.
See how it worksWorkflow and review gates
Triage, data entry, quality review, and medical review as configurable workflow states, with the queue prioritised by risk.
See how it worksSubmission obligations on the case
The reporting rules engine resolves every obligation from the case attributes, sets Day 0, and tracks each deadline and acknowledgement against the record.
See how it worksClinical and post-marketing on one record
SUSAR handling, blinding and unblinding, and study-specific rules for trial cases, alongside spontaneous post-marketing cases in the same system.
See how it worksWhy teams pick PVgenix as their ICSR system
An ICSR system is judged on two things: whether it holds up under inspection, and whether it removes work rather than adding it.
Audit trail as a by-product of working
Every create, update, and delete is captured with who, what, when, and before/after values. The inspection evidence is generated by people doing their normal work, not assembled afterwards.
No exports between modules
Intake, processing, submission, surveillance, and quality all read and write the same case. Nothing is re-keyed into a second system, so nothing drifts out of agreement.
Reportability decided by configuration
Which authority, which format, which deadline — resolved from case attributes by a rules engine you configure, rather than remembered by whoever is on duty.
AI on the data entry, not the judgment
Extraction and coding are accelerated by AI with confidence scoring and mandatory review gates. Causality, expectedness, and seriousness sign-off remain human decisions.
Configurable to your SOPs
Workflow states, review gates, code lists, intake form fields, and reporting rules are configured per tenant from the admin console — no code change to match your procedures.
Scales with case volume, not seat count
Modern cloud-native architecture and pricing that follows actual need, rather than per-seat enterprise licensing that penalises growing a team.
Answers before the demo
The questions that come up in most evaluations. If yours is not here, ask it on the call.
Browse the full FAQAn ICSR — Individual Case Safety Report — is the structured record of an adverse event experienced by a single patient in connection with one or more medicinal products. Under ICH E2D, a valid ICSR requires four minimum criteria: an identifiable patient, an identifiable reporter, a suspect medicinal product, and an adverse event or reaction. ICSRs are the unit of exchange for safety reporting to regulators, typically transmitted in the ICH E2B format.
ICSR management software is the system that holds and processes case safety reports across their whole life: receiving reports from every channel, detecting duplicates, capturing and coding case data, recording medical assessment, versioning follow-up information, determining reporting obligations and deadlines, generating and transmitting submissions, and retaining a complete audit trail of every change.
Inbound reports are matched against the existing case population at intake, before the case enters a processing queue. Suspected duplicates are surfaced for a reviewer to confirm or reject rather than being merged silently, and the decision is recorded on the audit trail. Literature monitoring applies the same principle, detecting articles already assessed in earlier search cycles.
A follow-up creates a new version of the case rather than overwriting the existing data. Each version records what was known at that point, which assessments applied, and what was submitted — so an earlier submission can always be reconciled against the information available when it was made. Aggregate reports use the case versions in force at the data lock point for the same reason.
Yes. Both sources are processed in the same system on the same case structure. Clinical cases additionally support SUSAR identification and expedited handling, a blinding and unblinding workflow, and study-specific reporting rules configured per protocol.
Yes. Migration from an existing safety database is supported through E2B transfer, and data migration tooling covers legacy extraction, field mapping, and reconciliation where a standard E2B transfer is not sufficient. Migration scope and approach are agreed per engagement.
See your case types on PVgenix
Request a demo and we will walk a real case from intake through duplicate detection, coding, assessment, review, and submission.