Reference
Every active EU GVP module and every PV-specific ICH E2 guideline, summarized from the source documents themselves — not a secondhand paraphrase of someone else's summary.
EU framework
Twelve active modules, not sixteen — Module numbers XI through XIV were never issued as standalone documents; EMA covered those topics through other guidance instead. That gap is normal, not a mistake in this list.
Key points
This is the module inspectors reference first — if the QPPV’s authority, access, or availability doesn’t match what’s documented, everything downstream gets questioned too.
In depth
In practice, "quality system" means a genuinely specific set of artefacts, not an abstract commitment: SOPs covering every stage of the case lifecycle from intake to submission, a training matrix that ties each staff member to the exact SOP versions they were trained on (not just "PV training completed"), a deviation-management process for when something goes wrong outside the SOP, and computerised system validation records for every database the PV system touches, safety database included. The QPPV’s role is easy to picture only at the dramatic moments — signing off during an inspection, being named in a regulatory letter — but the actual day-to-day job is closer to continuous oversight: reviewing case quality metrics, being looped into signal discussions, and knowing enough about the operational reality to answer a regulator’s question without needing to check first. A QPPV who only engages during audits and inspections is, by GVP’s own definition, not doing the role as written.
Key points
Vendor and CRO oversight lives here in practice — confirming a contracted PV provider is actually running a PSMF-compliant system, not just processing cases generically.
In depth
A PSMF is deceptively simple to describe and genuinely hard to keep accurate in a large organisation, because it has to reflect reality at all times, not just at the moment it was last submitted — a new vendor contract, a change in the QPPV’s deputy, or a database migration all trigger an update obligation within 30 days, whether or not anyone remembers to action it. Inspectors lean on the PSMF heavily precisely because a well-maintained one tells them, at a glance, whether the company’s own documentation matches what staff actually describe doing when interviewed — a mismatch between the PSMF’s org chart and who someone says they report to is a classic, and telling, inspection finding. For anyone evaluating a vendor or CRO’s PV capability from the outside, asking to see how current their PSMF is (not whether one exists, but when it was last meaningfully updated) is a genuinely useful diagnostic question.
Key points
The distinction between "inspection" (Module III, done by regulators) and "audit" (Module IV, done internally or by a contracted auditor) trips people up constantly — they’re not the same activity.
In depth
The clearest way to keep the distinction straight: an inspection is something a regulator does to you, an audit is something you (or someone you hired) does to yourself, and both exist precisely because self-assessment alone isn’t considered sufficient assurance in a system where patient safety is at stake. Inspection types matter operationally too — a routine inspection is planned and risk-based, a "for-cause" inspection is triggered by a specific concern (a signal, a complaint, a prior finding that wasn’t properly closed) and tends to be narrower but more intense. Pre-authorisation inspections specifically check readiness before a product is even approved, which is why a company’s PV system sometimes gets scrutinised before it has any real cases to show yet — inspectors are assessing capability, not just track record.
Key points
This is where CAPA (corrective and preventive action) documentation actually gets tested — a finding without a real, evidenced closure stays open indefinitely.
In depth
The word "risk-based" in audit scheduling isn’t decorative — it means genuinely higher-risk parts of the PV system (a newly onboarded vendor, a process that’s had a recent near-miss, a database migration) get audited more frequently than stable, long-running processes, and an audit programme that treats every area identically regardless of risk profile is itself a finding waiting to happen. The CAPA loop is the part that separates a functioning quality system from a paper one: identifying a finding is easy, writing a corrective action plan is routine, but the actual evidence bar — proving the action was implemented AND that it worked, not just that a checkbox was ticked — is where audits genuinely improve a system rather than just documenting its flaws. A note of audit finding can only be removed from the PSMF once that evidence exists, which is a real, enforced incentive to close things out properly rather than let them linger as "in progress" indefinitely.
Key points
RMPs and PSURs interact directly — a benefit-risk change identified in a PSUR often triggers an RMP update, and the two can be submitted together when that’s the case.
In depth
The three-part structure is worth understanding as a genuine workflow, not just a template to fill in: the Safety Specification is the honest inventory of what’s known, suspected, and simply unknown about a product’s risk profile; the Pharmacovigilance Plan is the concrete answer to "how will we find out more about the things we don’t yet know"; and the Risk Minimisation Plan is what actually gets done about the risks that are already identified. A common misconception is treating the RMP as a one-time submission document rather than a living one — in reality, safety concerns move between categories over a product’s life (a potential risk becomes identified once enough evidence accumulates, or gets downgraded and removed if it doesn’t hold up), and the RMP is expected to reflect that movement, not just the picture as it stood at initial approval.
Key points
Timelines here (15 days serious, 90 days non-serious) are the numbers every case processor works against daily — covered in full on the Regulatory Guidelines page.
In depth
The four-criteria validity test looks simple written down but is where a genuinely large share of real case-processing judgment calls actually happen: an "identifiable reporter" doesn’t require a full name and address, a first initial and a professional role can be sufficient; an "identifiable patient" can be as minimal as an age range and sex if that’s truly all that’s available. The instinct to reject a case for being "too incomplete" is often wrong — the bar is lower than people expect, and a genuinely valid case with minimal information should still be processed and followed up on, not discarded. Duplicate management (Addendum I) matters more than its administrative-sounding name suggests: the same real-world event can enter a company’s system through a spontaneous report, a literature article, and a patient support programme almost simultaneously, and failing to recognise it as one case rather than three doesn’t just create paperwork, it distorts signal detection statistics built on report counts.
Key points
This module is where GVP and ICH genuinely converge — EU procedure, ICH-harmonised document structure.
In depth
The shift from PSUR to PBRER wasn’t just a rename — the older PSUR format was closer to a comprehensive data dump organised by topic, while PBRER specifically requires an integrated benefit-risk narrative, meaning the report has to actually argue a position (the product’s benefit-risk balance remains favourable, or it doesn’t, and here’s why) rather than just presenting tables and letting the reader draw conclusions. The Data Lock Point discipline matters more than it might seem: everything in the report is either "within this reporting interval" or "cumulative to this point," precisely, with no ambiguous middle ground — a case that arrived one day after the DLP genuinely belongs in the next report, not a footnote in this one, even if that feels administratively awkward. The EURD list schedule (rather than a per-product negotiated cadence) is also a real operational constraint worth knowing: a company doesn’t choose when its PSURs are due, EMA’s published schedule does.
Key points
PASS results feed directly back into the RMP and PSUR — it’s not a standalone deliverable, it closes the loop on questions the RMP raised.
In depth
The interventional versus non-interventional distinction is the single most consequential fork in this module: an interventional PASS means the treatment assignment or care pathway is determined by the study protocol, which brings it under essentially the same clinical-trial regulatory machinery as any other interventional study — ethics committee approval, full authorisation pathway, the works. A non-interventional PASS, by contrast, observes patients receiving treatment as part of normal clinical practice, with no protocol-driven intervention, and follows a lighter (though still regulated, per Addendum I) pathway. Getting this classification wrong at the design stage is a genuinely expensive mistake — realising partway through that a study needed interventional-level oversight after already running it non-interventionally isn’t something that’s easily corrected retroactively.
Key points
The distinction between detection and validation matters in interviews specifically — a detected signal isn’t automatically a validated one, and conflating the two is a common fresher mistake.
In depth
Detection is the noticing stage — a disproportionality score crosses a threshold, or a case processor spots a pattern reading through recent reports — and by itself it means almost nothing yet; plenty of detected signals turn out, on closer look, to be statistical noise, reporting artefacts, or already-known effects that were simply under-documented in the system. Validation is the deliberate step of asking whether the detected pattern actually holds up: is the underlying data quality good enough to trust, is there a plausible biological or pharmacological mechanism, does it survive a second look with fresh eyes. Only signals that clear validation move to prioritisation and assessment, where the real analytical work happens — confounders, alternative explanations, comparison against what’s already known. Treating "we detected something" as equivalent to "we found a safety issue" is exactly the kind of overclaim that makes a case processor’s escalation lose credibility with a medical reviewer.
Key points
A frequently misunderstood point worth getting right: the black triangle signals closer scrutiny is warranted, not that the product is known to be more dangerous.
In depth
The confusion is understandable — a black triangle next to a medicine’s name in the patient information leaflet reads, to an untrained eye, like a warning label, when what it actually communicates is closer to "we’re still filling in the picture on this one." Every genuinely new active substance gets the triangle automatically for a defined period, regardless of how clean its trial safety profile looked, simply because clinical trials before approval can never capture rare adverse events, long-term effects, or interactions across the full diversity of the real patient population the way years of post-marketing use eventually will. The practical upshot for anyone in case processing: additional-monitoring products deserve proportionally more attention to completeness and follow-up in case reports, since every report genuinely matters more to the evidence base while the picture is still being built.
Key points
This is the module that turns signal and PSUR findings into something a prescriber or patient actually sees and acts on — the last mile of the whole system.
In depth
A Direct Healthcare Professional Communication is the module’s highest-stakes output, and it earns that seriousness: it’s reserved for urgent, actionable safety information where the time between "we know something" and "prescribers need to know it too" genuinely matters for patient outcomes, not routine label updates. The effectiveness-evaluation requirement is the part that’s easy to skip and important not to — sending a DHPC and assuming the job is done ignores the real, well-documented problem that safety communications sometimes simply don’t reach or change behaviour among their intended audience. A communication that technically satisfied the notification requirement but that prescribers never actually read or acted on hasn’t achieved what this module exists for, even if every procedural box was checked.
Key points
The evaluation requirement in Addendum II is the part people forget — a risk minimisation measure that’s never assessed for effectiveness is incomplete under current GVP expectations.
In depth
The routine-versus-additional distinction is really a question of proportionality: routine measures (what’s already in the product information, pack size, prescription-only status) are the default and are considered sufficient for most identified risks, and reaching for additional measures — patient alert cards, mandatory prescriber training, a controlled distribution programme — should be a deliberate escalation, not a reflexive one, since additional measures carry real implementation cost and can create their own access burden for patients. Addendum II’s effectiveness-evaluation requirement exists because additional risk minimisation measures have a documented history of looking reasonable on paper while doing very little in practice — a patient alert card that’s handed out but never read, an educational programme that’s completed as a formality rather than genuinely absorbed. Measuring whether the tool actually changed prescribing or patient behaviour, not just whether it was distributed, is what separates real risk minimisation from a compliance exercise.
Global framework
The PV- and clinical-development-relevant guidelines from ICH's harmonised standard set.
Every ICH guideline is officially classified into one of four categories: Quality (Q) covers pharmaceutical development, manufacturing, and stability; Safety (S) covers nonclinical toxicology and animal studies; Efficacy (E) covers the design, conduct, and reporting of human clinical trials; and Multidisciplinary (M) covers cross-cutting topics that don't sort cleanly into the other three — shared terminology, submission formats, and standards used across all of them. Every guideline on this page is Efficacy or Multidisciplinary: the E2 series (case safety data, ICSRs, PSURs) and E6/E8/E9 (trial conduct, planning, and statistics) are Efficacy; M1 (MedDRA) and M4 (the Common Technical Document) are Multidisciplinary, since terminology and submission structure aren't unique to any one category — every guideline on this page, and most of pharmacovigilance itself, depends on both.
Key points
If you can only deeply learn one ICH guideline before an interview, this is the one — its definitions are assumed knowledge in every other document on this page.
In depth
The "reasonably related" element of the three-part expedited-reporting test is where most of the real judgment calls live — serious and unexpected are comparatively binary determinations, but causality assessment is inherently probabilistic, and E2A doesn’t pretend otherwise. It explicitly acknowledges that a single case report rarely provides definitive proof of causation, and that expedited reporting is meant to flag reasonable suspicion for further investigation, not to assert a proven causal link. This is worth internalising early: a case processor forwarding a report for expedited reporting isn’t claiming the drug caused the event, they’re saying the possibility is real enough that regulators and other stakeholders need to know about it promptly. Blinding considerations matter more than they first appear too — in a properly blinded trial, an unexpected serious event may require unblinding that specific case before a causality judgment is even possible, which is itself a deliberate, controlled process, not an ad hoc decision.
Key points
Every "which E2B version does this authority require" question on the Regulatory Guidelines page traces back to this document — it’s the technical backbone behind that whole page.
In depth
It’s worth being precise about what E2B(R3) actually governs versus what it doesn’t: it’s a transmission and structure standard, not a content standard — it defines where information goes in a message and how systems exchange it, while E2A and E2D define what information needs to be collected and by when. Confusing the two is common: someone might correctly cite "E2B(R3)" when the real question is about reporting timelines, which actually sits with E2A/E2D instead. The R2-to-R3 transition itself is a genuinely useful case study in how slowly global harmonisation actually moves in practice — R3 was finalised years before most major authorities completed their transition, and as the Regulatory Guidelines page shows, TGA in Australia still hasn’t moved to it at all. "Harmonised" doesn’t mean "simultaneously adopted everywhere," and assuming otherwise is a real practical trap when working across multiple markets.
Key points
People still say "PSUR" constantly in casual conversation even though the actual required document is a PBRER — know both terms, since interviewers use them interchangeably.
In depth
The benefit-risk framing is the genuinely substantive change from the older PSUR format, and it’s worth being able to explain why it matters rather than just naming it: a document that only lists adverse events without weighing them against the product’s established benefits leaves regulators (and the company itself) without a real basis for deciding whether anything needs to change. A PBRER has to make an actual argument — here is what we knew about benefit and risk at the start of this interval, here is what changed, here is our reasoned conclusion about whether the balance still holds. That reasoning is exactly what a PRAC or other reviewing committee scrutinises most closely; a PBRER that’s comprehensive on data but thin on actual benefit-risk reasoning is a weak submission even if every required data table is technically present.
Key points
The revision itself is a good interview signal to bring up — mentioning E2D(R1) by name, and that it’s replacing the older E2D specifically because newer safety-data sources needed covering, reads as genuinely current knowledge rather than memorized material.
In depth
The gap the R1 revision closes is a real, practical one: the original E2D dates from an era when "safety data source" mostly meant spontaneous reports, literature, and formal company contact — it had no real framework for a patient describing a side effect in a company-sponsored Facebook group, or a market-research survey incidentally surfacing an adverse event, or a patient-support-programme nurse noting something during a routine check-in call. All of those are genuinely common sources now, and without updated guidance, companies were left making inconsistent judgment calls about which ones triggered a reportable case. The "day zero" definition — the moment ANY personnel of the company becomes aware, not specifically the safety team — is worth sitting with, because it means a sales representative hearing about a side effect in casual conversation with a physician starts the same regulatory clock as a formal report reaching the PV department directly. Awareness training across non-PV functions exists precisely because of this rule.
Key points
This is the conceptual bridge between "we collect adverse event reports" and "we have a deliberate plan for what we’re trying to learn" — worth being able to explain in your own words, not just name-drop.
In depth
The distinction between routine and additional pharmacovigilance activities is the practical core of what E2E actually asks a company to decide: routine activities (standard case processing, PSURs, basic signal detection) are the baseline every product gets regardless of its specific risk profile, while additional activities — a targeted post-authorisation safety study, an enhanced-monitoring registry, active surveillance in a specific population — are reserved for products whose Safety Specification flags something specific enough to warrant them. A common mistake is treating every identified risk as automatically needing additional activities, when E2E’s actual framing is more disciplined: additional activities should be proportionate to the seriousness and uncertainty of the specific safety concern, not applied as a blanket precaution. Knowing how to argue that routine pharmacovigilance is genuinely sufficient for a given risk, not just reaching for more monitoring by default, is itself a real pharmacovigilance planning skill.
Key points
Fresher candidates sometimes conflate the DSUR with the PBRER/PSUR since both are periodic aggregate reports — the clean distinction is development-phase (DSUR) versus post-approval (PBRER), and that alone is a strong interview answer.
In depth
The "all trials globally, one product" scope is what makes the DSUR genuinely useful rather than just another paperwork requirement — a sponsor running six concurrent trials across different regions and phases for the same investigational product gets one integrated view of that product’s emerging safety picture, rather than six fragmented ones that might individually look unremarkable but collectively suggest a pattern. This matters practically: a signal that wouldn’t be visible from any single trial’s data in isolation can become apparent once all trials for that product are viewed together, which is exactly the blind spot the DSUR is designed to catch. The annual cadence, anchored to the Development International Birth Date rather than any individual trial’s start date, means the reporting clock doesn’t reset every time a new trial for the same product begins — it’s one continuous safety narrative across the whole development programme, not a fresh one per study.
Key points
If E2A is the one guideline worth knowing cold for case processing, E6(R3) is its equivalent for anyone touching clinical trial conduct — and unlike most ICH revisions, this one is recent enough that citing the R3 changes specifically, not just "GCP," reads as current knowledge.
In depth
The restructure into a Principles document plus separate annexes isn’t just organisational tidiness — it’s a deliberate response to a real problem the old single-document format had: E6(R2) tried to cover both timeless ethical principles and specific operational guidance in one document, which meant the whole guideline needed formal revision every time trial technology or methodology moved on, a genuinely slow process for fast-moving areas like digital health tools. Splitting principles (meant to be durable) from annexes (meant to be updated as trial designs evolve) means Annex 2’s coverage of decentralized and pragmatic trial designs can be revised on its own timeline without reopening the entire GCP framework. The reduction from 13 principles under R2 to 11 under R3 isn’t a simplification of substance so much as a consolidation — several R2 concepts were merged or reorganised under broader principle headings rather than dropped, which is exactly the kind of detail worth getting right rather than assuming R3 asks for less.
Key points
Worth knowing which guideline came first conceptually: E8(R1)’s quality-by-design framing predates and informs E6(R3)’s restructure — not the other way around, even though E6 gets more attention day to day.
In depth
The "critical to quality" concept is the practical heart of this guideline, and it’s a genuine mindset shift from older quality-assurance thinking: rather than treating every process step and data point as equally important to get perfect, E8(R1) asks trial teams to identify upfront which specific factors would actually threaten participant safety or the reliability of the trial’s conclusions if they went wrong, and focus monitoring and resource intensity there. A missing signature on a routine administrative form and a missing informed consent document are not equally critical, even though both are technically "protocol deviations" — E8(R1) gives teams explicit permission, even an expectation, to treat them differently rather than applying uniform scrutiny everywhere out of caution. This proportionality principle is exactly what later shows up as "risk proportionality" as one of E6(R3)’s own overarching principles — the two guidelines share one underlying philosophy, just applied at different stages of the trial lifecycle.
Key points
This is more statistics-adjacent than most PV interview content, but the core idea — that a trial needs to define exactly what question it’s answering before it can claim to answer it — is a genuinely useful concept to be able to explain in plain language.
In depth
An "intercurrent event" is anything that happens after randomisation that complicates interpreting the treatment effect — a participant stops taking the study drug due to a side effect, switches to rescue medication, or the disease progresses to the point that the originally planned measurement no longer applies cleanly. Without an explicit estimand, different analysts looking at the exact same trial data can reach genuinely different, defensible conclusions about "what the drug did," simply because they made different implicit choices about how to handle those intercurrent events — count the dropout as a treatment failure, exclude them from analysis, or something else entirely, each a legitimate choice that produces a different number. R1’s real contribution is forcing that choice to be made explicitly and in advance, before seeing the data, rather than letting it happen implicitly during analysis where the temptation to pick whichever approach produces the more favourable result is a genuine, well-documented risk to trial integrity.
Key points
This is the guideline behind the Skills and Certifications page’s MedDRA coverage and the PV Toolkit’s calculators — the M-category "multidisciplinary" label exists precisely because terminology standards like this don’t belong uniquely to Quality, Safety, or Efficacy; every category depends on it.
In depth
The practical reason MedDRA coding consistency matters more than it might seem: signal detection is fundamentally a counting exercise — disproportionality analysis compares how often a specific term co-occurs with a specific drug against how often it appears elsewhere in the database — and that counting only works if the same clinical concept is reliably coded to the same Preferred Term across thousands of case processors, companies, and countries. A case processor who codes "felt dizzy" as one PT and a colleague who codes an essentially identical description as a different, related-but-distinct PT isn’t making an obviously wrong choice necessarily, but the two decisions fragment what should be one signal into two smaller, less statistically visible ones. This is exactly why MedDRA coding conventions and "coding to the most specific accurate term available" guidance exist — not as bureaucratic pedantry, but because the entire statistical apparatus built on top of MedDRA data depends on that consistency holding up at scale.
Key points
"Which CTD module does this document go in" is a genuinely common regulatory affairs interview question, and the clean answer — quality in 3, nonclinical in 4, clinical in 5 — is worth having automatic.
In depth
A useful way to remember the module split: Module 2 isn’t a fifth category of content, it’s the summary layer sitting on top of Modules 3 through 5 — the Quality Overall Summary, Nonclinical Overview, and Clinical Overview are all reviewer-facing distillations of the detailed reports that follow, meaning a reviewer can often get the gist of an application from Module 2 alone before deciding which Module 3/4/5 sections need closer scrutiny. Module 1 being region-specific rather than common is the detail most likely to catch someone out — the same core dossier (Modules 2 through 5) can, in principle, support submissions to multiple regulators, but the administrative wrapper around it (application forms, prescribing information format, region-specific declarations) has to be rebuilt for each authority. This is precisely why eCTD publishing tools spend so much engineering effort on Module 1 templating specifically — it’s the part of the submission that genuinely can’t be reused wholesale across markets.
A note on how this page ages
GVP modules and ICH guidelines get revised — Module XVI is on its 3rd revision, E2D just moved to its R1 revision effective March 2026. This page reflects the current state as of when it was written; always cross-check against EMA's and ICH's own published documents before relying on a specific detail for a real regulatory decision.