On September 3, we hosted a live webinar exploring one of the most underestimated parts of pharmacovigilance operations: choosing, implementing, and living with a computerised system. More than 50 professionals from across the PV industry joined us live.
Why we picked this topic
Our software and services — literature screening, the adverse event (safety) database, and AI agents — are already used by more than 60 companies in over 30 countries. But across those implementations, we kept seeing a familiar pattern: companies sign a contract, complete a demo, and then never quite get around to rebuilding their processes around the new system — quietly reverting to old habits instead of capturing the efficiency they paid for.
So rather than presenting our own product, we invited a guest who has seen this pattern from the buyer’s side, across dozens of vendors and systems.
A conversation from the buyer’s side
The webinar, titled “What the Demo Doesn’t Show: Lessons from Selecting and Implementing Computerised Systems in Pharmacovigilance,” featured Jan Kolouch — CEO, EU QPPV, and Strategic PV Advisor at NextPV Services (Prague) — as our guest speaker, with our CEO, Dmytro Horilyk, co-hosting and pressing him on the details vendor demos rarely cover.
Jan brings more than 13 years of pharmacovigilance experience, largely on the vendor and consultancy side, working closely within MAH and sponsor teams. Over the past several years he has implemented dozens of computerised systems in GxP environments — safety databases, case intake systems, reporting and signal-detection tools, and document-heavy processes like PSMFs and PV agreements moving out of Excel, Word, and PowerPoint into dedicated systems. He also hosts the “What’s Next in PV” podcast on YouTube.
What we covered
Jan’s presentation walked through the full lifecycle of a computerised system implementation:
- Defining the business case — knowing precisely what you want to move into a system (PVAs, PSMF, signals, etc.), mapping the current process against the future one, and deciding between a “lift and shift” versus a leaner, system-agnostic redesign.
- Requirements and risk classification — listing KPIs and functional requirements up front, and assigning the GxP risk category (GAMP 3/4/5) early, since it drives the validation effort.
- Choosing the right vendor — preselecting the market, deciding build vs. buy, putting CDAs/NDAs in place, checking whether a vendor offers out-of-the-box or configurable solutions, asking about other clients using the system, and assessing interoperability (APIs, E2B connections) — including concrete examples like whether a system can pull SOPs, audit findings, or KPIs directly into a PSMF.
- Why the demo always works — and why the first real case may not. Vendors know their own system inside out, and out-of-the-box demos are built to look good. The real test is how well your own requirements were shared beforehand, whether you get real sandbox access with dummy data, and whether both business users and backend/IT colleagues (who ask about uptime, servers, RTO/RPO) are in the room.
- Data migration — described as the point where “another chapter” of the project really begins. Topics included bulk-uploading large ICSR volumes, structuring PSMF documents and metadata, and how systems can replace manual email-based reconciliation and reminders with tracked tasks and notifications.
- Change management and onboarding — setting a clear cutover date, training before onboarding, dedicated system pages or intranet hubs, and regular drop-in sessions after go-live.
- Integrations, maintenance, upgrades, and revalidation — how vendors publish updates, what environments (dev/test/validation/production) actually mean, whether upgrades roll out in bulk or continuously, and the ongoing need to document upgrade reviews and reassess revalidation needs.
- What auditors actually ask — whether the system is validated and how often it’s revalidated, whether AI features are present and how they’re governed, and how user onboarding/offboarding is controlled. Jan noted that MAHs and sponsors remain accountable for these answers even when a vendor helps prepare them.
Live Q&A highlights
Our audience — which included working PV professionals — pushed the conversation further, asking about:
- Where AI genuinely helps today (often layered on top of core functionality, such as comparing PVA or PSMF versions) versus where it still produces inconsistent results.
- The tension between system-enabled quality control and long-standing manual SOPs — and why companies often keep doing QC by hand even when a system could automate it, simply because updating an SOP takes time.
- Whether Jan has ever advised a client to walk away from a system they’d already paid for (his answer: rarely a full reversal, but often a candid conversation about whether a solution’s scope actually matches the company’s footprint).
- What one change Jan would make in PV overall — his answer centered on spending less time talking about systems and more about patients, and closing the gap in adverse event reportability.
To close, Jan fielded a few rapid-fire questions from us: there’s no single vendor phrase that ends a conversation for him, but a lack of responsiveness during vendor comparisons is a real warning sign; red flags during a first-hour system walkthrough tend to show up as unexplained disconnects or cluttered backend data; and reference calls with other clients — while not something vendors always expect — are often the most revealing step in the process.
Watch the recording
If you couldn’t join us live, the full recording is now available on YouTube watch here.
Stay in the loop
We regularly host webinars with pharmacovigilance practitioners and industry experts. Follow DrugCard on LinkedIn to be the first to know about upcoming sessions.
