Pharmacovigilance software: build vs buy
Build or buy a pharmacovigilance system? Case intake, MedDRA coding and licensing, E2B(R3) reporting, signal detection, validation and AI-assisted intake.
- Most companies should buy or subscribe to a proven safety database; building makes sense only for unusual workflows, a product you plan to sell, or deep integration needs.
- The hard parts are compliance-grade: E2B(R3) exchange, MedDRA coding, reporting timelines, audit trails and validation.
- MedDRA needs a subscription for commercial use — budget for it whether you build or buy.
- AI can speed up case intake and coding suggestions, but a qualified person should review and approve every case.
Most marketing authorisation holders and service providers should buy or subscribe to a validated pharmacovigilance system rather than build one. Build only when your workflow is unusual, you need deep integrations, or the software is itself your product. Either way, check E2B(R3) reporting, MedDRA coding, audit trails, validation evidence and how AI is supervised.
Pharmacovigilance software sits under close regulatory scrutiny: late or wrong safety reports are inspection findings. This guide walks through what the system must do, the build-or-buy trade-offs, and how AI-assisted intake can help without taking people out of the loop.
What pharmacovigilance software must do
| Function | What it involves |
|---|---|
| Case intake | Receiving adverse event reports from email, forms, call centres, literature, partners and regulators; duplicate checks |
| Case processing | Data entry, seriousness and expectedness assessment, causality, narratives, medical review |
| Coding | MedDRA for events and medical history; a drug dictionary such as WHODrug for products |
| Regulatory reporting | ICSRs in ICH E2B(R3) format to regulators and partners, within required timelines |
| Aggregate reports | Data outputs for periodic reports such as PSURs/PBRERs |
| Signal detection | Reviewing case data for new or changing safety signals, and tracking signal evaluation |
| Compliance and audit | Audit trails, electronic signatures, access control, submission tracking and metrics |
Every one of these carries regulatory weight, which is why the build-or-buy decision is really about who carries the compliance burden.
Build vs buy, side by side
| Factor | Buy or subscribe | Build (custom) |
|---|---|---|
| Time to go live | Weeks to months, mostly configuration and validation | Many months, including design, build and full validation |
| E2B(R3) and gateways | Usually built in and maintained by the vendor | You build, test and maintain the message handling yourself |
| Regulatory change | Vendor updates for new rules and standard versions | Your team tracks and implements every change |
| Workflow fit | Configurable within the product’s design | Exactly your workflow |
| Validation | Configured system; vendor evidence can be leveraged | Full Category 5 life cycle |
| Cost profile | Subscription or licence plus implementation | Higher upfront cost plus ongoing development and upkeep |
| Ownership | Vendor roadmap; data export terms matter | You own the code and roadmap |
When building makes sense
- You are a PV service provider or technology company and the software is your product.
- You need a custom layer — intake portals, partner exchanges or analytics — around an existing safety database.
- Your case volume, product mix or partner model doesn’t fit available products without heavy workarounds.
For many teams, the middle path works: keep a proven safety database and build integrations or intake tools around it. Our custom software vs SaaS guide covers that hybrid approach in general terms.
MedDRA coding and licensing
MedDRA, the Medical Dictionary for Regulatory Activities, is the standard terminology for coding adverse events in regulatory safety reporting. It is owned by ICH and maintained by its Maintenance and Support Services Organization (MSSO), with new versions released twice a year.
Whether you build or buy, the system should:
- Load new MedDRA versions and support version upgrades, including recoding where terms change.
- Code at the Lowest Level Term and show the full hierarchy up to System Organ Class.
- Keep a record of the version used for each coded term.
E2B(R3) reporting and timelines
ICH E2B(R3) defines the electronic format for individual case safety reports (ICSRs). Major regulators, including the EMA through EudraVigilance, use it, and regional implementation guides add their own rules on top of the core standard.
What the software has to handle:
- Generating valid E2B(R3) XML, including regional rules for each regulator you report to.
- Importing E2B messages from partners and regulators, not only sending them.
- Acknowledgements — tracking whether each submission was accepted or rejected, and why.
- Due-date calculation from the day the company first knew of a valid case, with alerts before deadlines.
- Follow-up versions and nullifications linked to the original case.
- Submission history and compliance metrics you can show an inspector.
Building this well is a significant piece of work on its own, and it needs testing against each regulator’s requirements. It is one of the strongest reasons to buy rather than build.
Signal detection
Signal detection looks across cases for new or changing risks. Common approaches combine:
- Case review — medical reviewers look at serious and unexpected cases and case series.
- Disproportionality analysis — statistics such as the proportional reporting ratio (PRR) or reporting odds ratio (ROR) highlight drug–event pairs reported more often than expected.
- External data — literature and regulator databases, where access is available.
- Signal management — recording each signal, its evaluation, decisions and actions, with an audit trail.
Statistics flag candidates; qualified people decide whether a signal is real. The software’s job is to make that review efficient and traceable.
Validation and data integrity
A pharmacovigilance system is a GxP computerised system. Expect to validate it using a risk-based approach such as GAMP 5, with controls for 21 CFR Part 11 and EU Annex 11 where they apply. Inspectors will usually look closely at:
- Audit trails on case data, coding and assessments.
- Electronic signatures on medical review and submission.
- Role-based access, including for partners and service providers.
- Correct due-date calculation and E2B output, tested against realistic cases.
- Change control for MedDRA upgrades, configuration changes and software releases.
Buying a system doesn’t remove validation; it reduces it to your configuration and use, with vendor evidence leveraged. See our GAMP 5 guide and CSV vs CSA explainer.
AI-assisted intake, with human review
Case intake is where AI helps most today. Reports arrive as emails, PDFs, scanned forms and call notes, and much of the work is reading them and filling in fields. Language models can:
- Extract patient, reporter, product and event details into a draft case.
- Check the four minimum criteria for a valid case and flag what’s missing.
- Suggest MedDRA terms for reported events, for a coder to confirm.
- Flag possible duplicates and likely serious cases for priority review.
To use AI safely in a regulated process:
- A person reviews and approves every case — AI drafts, it doesn’t decide.
- Show the source — each extracted field links back to the text it came from.
- Measure accuracy on a representative test set before go-live and after each change.
- Log AI suggestions and human edits in the audit trail.
- Protect patient data — know where it is processed and that it isn’t used for model training.
We built PVgenix, a pharmacovigilance SaaS with AI-assisted intake, on these principles: AI prepares the draft and a qualified reviewer approves it.
Next steps
Start by listing your case volumes, sources, partners, regulators and reporting obligations, then check each option against them — including validation evidence and data export terms. If you’re weighing a new system, a custom intake layer or a way to add AI to an existing process, we can help you think it through. See our regulated software service, read how we use AI with human approval, or get in touch.
Frequently asked questions
Should we build or buy pharmacovigilance software?
Most companies should buy or subscribe to a validated safety database. Building makes sense for unusual workflows, a PV product you plan to sell, or custom intake and integration layers around an existing system.
What is E2B(R3) in pharmacovigilance?
ICH E2B(R3) is the international standard for the electronic exchange of individual case safety reports (ICSRs) between companies and regulators, with regional rules added by each regulator.
Do we need a MedDRA licence for pharmacovigilance software?
Commercial organisations need a MedDRA subscription from MSSO to use it, whether they build or buy their software. Fees depend on the type and size of the organisation.
Can AI be used for adverse event case intake?
Yes, AI can extract case details, check validity criteria and suggest MedDRA terms. A qualified person should review and approve every case, with AI suggestions and edits recorded in the audit trail.
Does pharmacovigilance software need validation?
Yes. It is a GxP computerised system, so it should be validated using a risk-based approach such as GAMP 5, with Part 11 and Annex 11 controls where they apply.