Pharmacovigilance Interview Prep

01

What is Pharmacovigilance?

WHO Definition

Pharmacovigilance (PV) is the science and activities relating to the detection, assessment, understanding and prevention of adverse effects or any other drug-related problem.

⚕ Why PV Exists

Clinical trials involve limited patient populations under controlled conditions. Post-market surveillance captures real-world safety data across millions of patients — different ages, comorbidities, co-medications, and genetic backgrounds — that trials cannot cover.

Post-Market Patient Safety Risk Minimization

🎯 Core Objectives

Detect new ADRs not found in trials
Monitor known risks in real-world use
Identify drug-drug interactions
Assess benefit-risk balance continuously
Communicate risk to healthcare professionals
Support regulatory decisions (label changes)

📋 PV Lifecycle Overview

Adverse Event (AE) Intake

Events received from patients, HCPs, literature, clinical trials, regulatory authorities, partner companies.

Case Processing (ICSR)

Triage → Data Entry → Medical Review → Narrative Writing → Causality Assessment

Regulatory Reporting

Expedited reports (7-day / 15-day) to FDA, EMA, PMDA etc. via E2B XML / MedWatch / CIOMS

Signal Detection

Statistical methods (PRR, ROR, BCPNN) on aggregate data to find new safety signals

Aggregate Reporting

PSUR / PBRER / DSUR — periodic summaries of cumulative safety data submitted to regulators

Risk Management

RMP (EU) / REMS (US) — educational materials, restricted distribution, monitoring programs

02

Regulatory Framework

Region	Authority	Key Regulation	Database / System
USA	FDA	21 CFR Part 312, 314, 600 / FAERS	MedWatch, FAERS, FDA Adverse Event Reporting
EU	EMA	EC Regulation 726/2004; DIR 2010/84/EU	EudraVigilance (EVDAS)
Global	ICH	E2A, E2B, E2C, E2D, E2E, E2F	VigiBase (WHO-UMC)
Japan	PMDA	ICH E2B(R3) since 2019	EPPIC-Net / PMDA system
India	CDSCO	Schedule Y / PvPI guidelines	VigiFlow
UK	MHRA	Human Medicines Regs 2012	Yellow Card Scheme

📅 ICH E2 Guidelines Family

E2A — Definitions & standards for expedited reporting
E2B(R3) — Data elements for ICSR transmission
E2C(R2) — PSUR / PBRER structure
E2D — Post-approval expedited reporting
E2E — Pharmacovigilance planning
E2F — DSUR (Development Safety Update Report)

⏱ Reporting Timelines

7 calendar days — Fatal/life-threatening unexpected SADRs (initial)
15 calendar days — All other serious unexpected ADRs
Follow-up — 15 days from new information receipt
Non-serious — Periodic/quarterly submissions
PSUR/PBRER — 6-monthly or annual per product

03

E2B R2 vs R3 Deep Dive

What is E2B?

ICH E2B is the international standard for electronic transmission of Individual Case Safety Reports (ICSRs). It defines the data elements, structure, and format for submitting adverse event reports to regulatory authorities electronically.

E2B(R2) — Legacy

Format: SGM (SGML-based)
Structure: Flat, non-hierarchical
Used by: FAERS (FDA), older EV submissions
MedDRA: Single reaction term
Identifier: Local Report Number
Drug info: Simple fields only
Global ID: Not standardized
Status: Being phased out

E2B(R3) — Current Standard

Format: XML (HL7 v3 based)
Structure: Hierarchical, rich data model
Used by: EudraVigilance (EU), PMDA, MHRA
MedDRA: Multiple reactions per event
Identifier: Universally Unique ID (UUID)
Drug info: Role codes, indication MedDRA
Global ID: Sender/receiver safety report ID
Status: Mandatory — EU since Nov 2017

📦 E2B(R3) Key Data Elements (Sections)

Section	Content	Key Fields
C.1	Safety Report Identification	Report ID, type, date of creation, sender/receiver
C.2	Primary Source	Reporter name, address, qualification (HCP/Consumer/MAH)
C.3	Sender & Receiver	Organization ID, country, type
C.4	Literature Reference	Publication details, authors, journal
C.5	Study Information	Study number, name, type (clinical trial etc.)
D	Patient Characteristics	Age, sex, weight, height, relevant medical history
E	Reaction/Event	MedDRA PT/LLT, onset date, outcome, seriousness
F	Results of Tests	Lab values, dates, normal ranges
G	Drug Information	Drug name, dose, route, dates, indication, role code
H	Narrative / Summary	Case narrative, reporter's comments, MAH assessment

🔄 Migration Challenges R2→R3

XML schema validation rules are stricter
New mandatory fields (UUID, nullFlavor handling)
Drug role codes changed (Suspect/Concomitant/Interacting)
NullFlavor (UNK, ASKU, NASK) must be used correctly
Duplicate detection via worldwide unique case ID
Acknowledgement (ACK) mechanism is mandatory

🏛 Gateways & Submission

EV Gateway — EMA's system for E2B(R3) XML
ESM — EMA's Electronic Submission Manager
EVWEB — Manual web portal for EV reports
FDA FAERS — Still primarily E2B(R2) via MedWatch Plus
VigiFlow — WHO system using E2B messaging
Safety DB / ARISg — Common safety databases

04

ICSR Reports

Individual Case Safety Report (ICSR)

An ICSR is a report describing one or more suspected adverse reactions in a single patient at a specific point in time. It is the fundamental unit of pharmacovigilance data collection and reporting worldwide.

⚡ The 4 Minimum Criteria for a Valid ICSR

1. Identifiable Reporter

Name, address, or qualification of the person reporting the event (cannot be anonymous)

2. Identifiable Patient

Age, sex, initials, or any patient identifier — full name not required

3. Suspect Drug

At least one suspect medicinal product must be identified

4. Adverse Event

At least one adverse event or reaction must be described

📥 Sources of ICSRs

Spontaneous — Voluntary reports from HCPs/patients
Clinical Trials — SAEs from ongoing studies
Literature — Published case reports / articles
Regulatory Authority — Reports forwarded by HA
Partners / Licensees — Business partner exchange
Digital / Social Media — Emerging source (AI-monitored)
Patient Support Programs — Disease registries

🔬 Seriousness Criteria (ICH E2A)

An AE is serious if it results in any of the following:

Death
Life-threatening condition
Hospitalization (initial or prolonged)
Persistent or significant disability/incapacity
Congenital anomaly / birth defect
Medically important event (may not be fatal but jeopardizes the patient)

📊 ICSR Processing Workflow

Day 0 — Receipt / Triage

Determine validity (4 minimum criteria). Classify: serious vs non-serious, expected vs unexpected. Assign case ID. Start clock for regulatory timelines.

Data Entry

Enter all available data into safety database (ARISg, Veeva Vault Safety, Oracle Argus, etc.). MedDRA code assignment for reactions and indications.

Medical Review / Causality Assessment

Physician reviews: Is there a reasonable causal relationship between drug and event? Assessment: Related / Not Related / Unclassifiable. Methods: WHO-UMC, Naranjo, Bradford-Hill.

Narrative Writing

Clinical summary of the case in plain language: patient history → drug exposure → event onset → outcome → causality. Must be concise yet complete.

Quality Review & Submission

QC check → Generate E2B(R3) XML → Submit to regulatory authority within deadline. Receive and process ACK.

Follow-Up

Actively seek additional information. Restart 15-day clock for significant new information. Document follow-up attempts.

05

Aggregate Reports

Report	Full Name	Who Submits	Frequency	Guideline
PSUR / PBRER	Periodic Safety Update Report / Periodic Benefit-Risk Evaluation Report	MAH (post-approval)	6-monthly, annually, or per EURD list	ICH E2C(R2)
DSUR	Development Safety Update Report	Sponsor (pre-approval / clinical trials)	Annual	ICH E2F
SUSAR	Suspected Unexpected Serious Adverse Reaction	Sponsor / Investigator	Expedited (7/15 days)	ICH E2A / GCP
ASR	Annual Safety Report	MAH (US-specific)	Annual	FDA 21 CFR 312.33
RMP	Risk Management Plan	MAH (EU)	Updated with MAA/variation	GVP Module V
REMS	Risk Evaluation and Mitigation Strategy	MAH (US)	Per FDA requirement	FDAAA 2007

📖 PSUR / PBRER Structure (ICH E2C R2)

Executive Summary
Introduction (product, indication, status)
Worldwide Market Authorization Status
Actions Taken for Safety Reasons
Changes to Reference Safety Information
Estimated Exposure & Use Patterns
Presentation of Individual Case Histories
Cumulative Summary Tabulations
Analyses of Individual Case Histories
Studies (ongoing/completed)
Other Information (literature, risk-benefit)
Overall Safety Evaluation
Conclusions

🔬 DSUR Structure (ICH E2F)

Executive Summary
Introduction
Worldwide Clinical Trial Status
Actions Taken for Safety Reasons
Changes to Reference Safety Information
IB and Patient Information
Non-clinical safety studies
Clinical trials & safety data (IB period)
Safety from marketing experience
Literature reports
Other DSURs
Overall Safety Assessment
Conclusion

06

GAMP 5

Good Automated Manufacturing Practice — 2nd Edition

GAMP 5 (published by ISPE) provides a practical framework for the validation of computerized systems used in regulated life sciences environments. In PV, it governs how safety databases (e.g., Oracle Argus, Veeva Vault Safety, ARISg) must be validated.

🗂 GAMP 5 Software Categories

Category	Type	Example in PV	Validation Level
Cat 1	Infrastructure Software	OS, middleware, SQL Server	Vendor qualification only
Cat 3	Non-configured products	Standard office software, basic COTS	Testing of standard functions
Cat 4	Configured products	Oracle Argus, Safety Reporter, ARISg	Configuration testing, IQ/OQ/PQ
Cat 5	Custom / Bespoke software	In-house built PV tools, custom reports	Full lifecycle validation (IQ/OQ/PQ + code review)

📋 Validation Life Cycle (V-Model)

URS — User Requirements Specification
FS — Functional Specification
DS — Design Specification
IQ — Installation Qualification (installed correctly?)
OQ — Operational Qualification (works as designed?)
PQ — Performance Qualification (meets user needs?)
Periodic Review — Annual or change-triggered revalidation

📜 21 CFR Part 11 (FDA)

Governs electronic records and electronic signatures in FDA-regulated systems. Key requirements:

Audit trails — who changed what, when
Electronic signatures = legally binding
Access controls & user authentication
System validation documented
Record retention & backup
Computer-generated date/time stamps

🔗 GAMP 5 in PV Context — Why It Matters for Interviews

When you work on a PV system (like Argus or ARISg), you must ensure:

Any configuration change goes through Change Control
All changes are documented in a Change Request with risk assessment
Testing follows test scripts (IQ/OQ/PQ protocols)
All defects / deviations are documented
UAT (User Acceptance Testing) is sign-off by business users
Regression testing ensures existing functionality not broken
System goes live only after validation sign-off

07

Signal Detection

📡 What is a Signal?

Information that arises from one or multiple sources (including observations and experiments) which suggests a new potentially causal association, or a new aspect of a known association, between an intervention and an event or set of related events, either adverse or beneficial.

(ICH E2C R2 / GVP Module IX definition)

📐 Quantitative Signal Detection Methods

PRR — Proportional Reporting Ratio (EU approach)
ROR — Reporting Odds Ratio
EBGM — Empirical Bayes Geometric Mean (FDA)
IC — Information Component / BCPNN (WHO-UMC)
MGPS — Multi-item Gamma Poisson Shrinker

PRR ≥2 + χ²≥4 = Signal

🔁 Signal Management Process (GVP Module IX)

Signal Detection

Automated or manual review of databases (EudraVigilance, FAERS, VigiBase, company database, literature)

Signal Validation

Determine if signal is new or known. Check SmPC/IB. Assess if causality is plausible. Decide if further evaluation needed.

Signal Prioritization

Rank by seriousness, severity, reversibility, preventability, public health impact

Signal Assessment

In-depth evaluation with all available data. Epidemiological analysis. Benefit-risk assessment.

Recommendation & Action

Label update / DHPC / regulatory notification / RMP update / product withdrawal if needed

08

Key Terminologies

Term	Full Form	Definition
ADR	Adverse Drug Reaction	A response to a medicine which is noxious and unintended and occurs at doses normally used. Causality implied.
AE	Adverse Event	Any untoward medical occurrence in a patient. Does NOT imply causality with the drug.
SAE	Serious Adverse Event	Any AE meeting one of the 6 seriousness criteria (death, LT, hosp, disability, congenital, medically significant)
SADR	Serious Adverse Drug Reaction	Serious + causally related to the drug
SUSAR	Suspected Unexpected Serious Adverse Reaction	Serious + unexpected (not in IB/SmPC) + causal relationship cannot be ruled out
MedDRA	Medical Dictionary for Regulatory Activities	Standardized medical terminology used globally for AE coding. Hierarchy: SOC → HLGT → HLT → PT → LLT
SmPC	Summary of Product Characteristics	EU label / prescribing information for a medicinal product
IB	Investigator's Brochure	Pre-marketing reference document for clinical trials (defines expectedness)
MAH	Marketing Authorization Holder	Company that holds the license to market a drug
QPPV	Qualified Person for PV	EU-mandated individual responsible for PV system at MAH
PSMF	Pharmacovigilance System Master File	EU required document describing the MAH's PV system
GVP	Good Vigilance Practice	EMA's guidelines (Modules I–XVI) governing PV operations in EU
CIOMS	Council for Intl Organizations of Medical Sciences	Provides CIOMS I form — alternative to MedWatch for expedited reporting
DLP	Data Lock Point	The date after which no new data is included in an aggregate report period
IBD	International Birth Date	Date of first marketing authorization for a drug anywhere in the world. Anchors PSUR cycle.

09

Interview Q&A

Click any question to reveal the answer.

FUNDAMENTALS

What is the difference between an Adverse Event and an Adverse Drug Reaction?+

An Adverse Event (AE) is any untoward medical occurrence in a patient administered a pharmaceutical product — it does NOT necessarily have a causal relationship with the treatment. For example, a patient breaks their leg while on a drug; that's an AE.

An Adverse Drug Reaction (ADR) implies a causal relationship — the reaction is attributed to the drug. Post-marketing ADRs follow the WHO definition: noxious, unintended, occurring at normal doses.

Key interview tip: In clinical trials, all untoward events are AEs. Post-marketing, spontaneous reports are classified as ADRs (causality implied by the reporter).

What are the 4 minimum criteria for a valid ICSR?+

1. Identifiable Reporter — A real person must report it (HCP, patient, caregiver — cannot be anonymous).
2. Identifiable Patient — Age, initials, sex or any identifier (full name not needed for privacy).
3. Suspect Medicinal Product — At least one drug suspected of causing the event.
4. Adverse Event — At least one adverse event or reaction described.

If any of these 4 are missing, the report is invalid and should not be processed as a case — it becomes a non-case (document why).

What is "expectedness" and how is it determined?+

Expectedness refers to whether the nature, severity, specificity, and outcome of an adverse reaction is consistent with the reference safety document:

Pre-market (clinical trials): Reference = Investigator's Brochure (IB)
Post-market: Reference = SmPC / Company Core Data Sheet (CCDS)

An event is Unexpected if it is not listed in the reference document, or if listed, differs in nature, severity, or specificity.

Why it matters: Unexpected + Serious + Causal = SUSAR → Expedited 7/15 day reporting obligation is triggered.

E2B & REPORTING

What are the main differences between E2B R2 and R3?+

Format: R2 uses SGML (older flat format); R3 uses XML based on HL7 v3 standard — more structured and machine-readable.

Structure: R3 is hierarchical with sections C.1 to H; R2 had flat fields in a single block.

Identifiers: R3 mandates globally unique case identifiers (UUIDs) to prevent duplicate processing across authorities.

MedDRA: R3 allows multiple reaction terms per event; R2 had limited coding capacity.

Drug roles: R3 uses standardized role codes (Suspect, Concomitant, Interacting, Drug Not Administered).

NullFlavor: R3 uses HL7 NullFlavor codes (UNK, ASKU, NASK, NA) for missing data instead of leaving fields blank.

Acknowledgement: R3 has a mandatory ACK mechanism confirming receipt and validation status.

EMA mandated E2B(R3) for EudraVigilance submissions from November 22, 2017.

What is the EudraVigilance Gateway and how does submission work?+

EudraVigilance (EV) is EMA's European database for managing and analyzing information on suspected adverse reactions to medicines authorized in the European Economic Area.

EV Gateway is the electronic system through which MAHs and sponsors submit E2B(R3) XML ICSRs directly to EMA. Submissions must pass XML schema validation and business rule validation before acceptance.

EVWEB is the web-based manual interface for smaller organizations or individual report submission.

ESM (Electronic Submission Manager) is the EMA portal used to manage submission accounts and access.

After submission, EMA sends an acknowledgement (ACK) message indicating: Accepted / Accepted with warnings / Rejected (with error codes).

What is the 15-day clock rule and when does it start?+

The 15-calendar-day clock starts from the date the MAH (or any employee/partner) first receives information that constitutes a valid ICSR — this is called Day 0.

For 7-day reports (fatal/life-threatening unexpected): Clock starts from Day 0, initial report must be submitted in 7 days, with follow-up within 8 more days.

Key nuance: If a follow-up contains significant new information that changes the seriousness, expectedness, or causality assessment — a new 15-day clock starts from the date that new info was received.

Missing the deadline = regulatory non-compliance = warning letters and potential fines.

GAMP 5 & VALIDATION

What is GAMP 5 and why is it important in pharmacovigilance?+

GAMP 5 (Good Automated Manufacturing Practice, 2nd Edition) is an ISPE guideline for validating computerized systems in regulated life science industries.

In pharmacovigilance, systems like Oracle Argus Safety, Veeva Vault Safety, ARISg, and custom reporting tools fall under GAMP 5 validation requirements because they:

→ Store and process patient safety data (regulated records under 21 CFR Part 11 / EMA GVP)
→ Generate regulatory submissions (ICSRs, aggregate reports)
→ Must have full audit trails

GAMP 5 categorizes software into 5 categories based on complexity and risk (Cat 1 = Infrastructure → Cat 5 = Custom). Higher categories require more rigorous validation (IQ/OQ/PQ + full documentation).

What is the difference between IQ, OQ, and PQ?+

IQ — Installation Qualification: Verifies that the system is installed correctly according to approved specifications. Checks hardware, software versions, network configuration, database installation. "Is it installed right?"

OQ — Operational Qualification: Verifies that the system operates according to its functional specification in the installed environment. Tests individual functions, workflows, boundary conditions, error handling. "Does it work as designed?"

PQ — Performance Qualification: Verifies that the system consistently performs according to user requirements under real-world conditions. Uses real business scenarios and data. "Does it meet user needs in practice?"

All three must be documented with approved protocols and signed off before the system goes live.

SIGNALS & AGGREGATE REPORTS

What is PRR and how is a signal identified using it?+

PRR (Proportional Reporting Ratio) is a disproportionality analysis method used by EMA for signal detection in spontaneous reporting databases.

Formula: PRR = (A/A+B) / (C/C+D)
Where A = reports of drug X with reaction Y; B = reports of drug X without reaction Y; C = reports of all other drugs with reaction Y; D = reports of all other drugs without reaction Y.

Signal threshold (Evans criteria):
→ PRR ≥ 2
→ Chi-squared (χ²) ≥ 4
→ N (number of cases) ≥ 3

All three must be met simultaneously for a signal to be flagged. PRR > 1 means the drug is reported with that reaction more than expected compared to all other drugs.

What is the difference between a PSUR and a DSUR?+

PSUR (Periodic Safety Update Report) / PBRER:
→ Submitted by MAH (Marketing Authorization Holder)
→ For authorized / marketed products
→ Covers post-approval safety data
→ ICH E2C(R2) guideline
→ Submitted to EMA, FDA, etc. at defined intervals (6-monthly or annual per IBD cycle)

DSUR (Development Safety Update Report):
→ Submitted by Clinical Trial Sponsor
→ For investigational / pre-approval products in clinical trials
→ Covers development phase safety data
→ ICH E2F guideline
→ Submitted annually to all regulatory authorities where trials are ongoing

Simple way to remember: PSUR = post-market, DSUR = development phase.

What is the QPPV and what are their responsibilities?+

QPPV (Qualified Person for Pharmacovigilance) is a mandatory EU regulatory requirement under GVP Module I. Every MAH must designate a QPPV who:

→ Resides and operates in the EEA
→ Is the single point of contact with EMA for all PV matters
→ Has authority and oversight over the entire PV system
→ Is responsible for the PSMF (PV System Master File)
→ Ensures adequate reporting of ADRs within required timelines
→ Oversees periodic aggregate report preparation
→ Maintains awareness of all safety signals

The QPPV can delegate tasks but NOT ultimate responsibility. If anything goes wrong with PV compliance, the QPPV is accountable.

What is MedDRA and what is its hierarchy?+

MedDRA (Medical Dictionary for Regulatory Activities) is an international standardized medical terminology used globally for coding adverse events, medical history, indications, and diagnostic procedures in PV and clinical trials.

Hierarchy (5 levels, top to bottom):

SOC → System Organ Class (e.g., Cardiac disorders) — 27 SOCs
HLGT → High Level Group Term (e.g., Cardiac arrhythmias)
HLT → High Level Term (e.g., Rate and rhythm disorders NEC)
PT → Preferred Term (e.g., Atrial fibrillation) — used for regulatory reporting
LLT → Lowest Level Term (e.g., AF, Auricular fibrillation) — maps to PT

SMQ (Standardised MedDRA Query): Predefined groupings of PTs used for signal detection and aggregate analysis (e.g., SMQ for Anaphylaxis, SMQ for Cardiac failure).

How do you perform causality assessment?+

Causality assessment evaluates whether there is a reasonable causal relationship between a drug and an adverse event. Key methods:

WHO-UMC Scale:
→ Certain: Plausible time sequence, known reaction, confirmed on rechallenge, no other explanation
→ Probable: Plausible time sequence, reasonable reaction, improves on dechallenge, other causes unlikely
→ Possible: Plausible time sequence, not a known reaction, could be due to other causes
→ Unlikely: Improbable time sequence, other causes more plausible
→ Conditional: Insufficient information to assess
→ Unassessable: Conflicting or inadequate data

Naranjo Algorithm: Score-based questionnaire (10 questions) → ≥9: Definite, 5-8: Probable, 1-4: Possible, ≤0: Doubtful

Key factors: Temporal relationship, dechallenge (stops on drug withdrawal), rechallenge (recurs on reintroduction), known pharmacology, alternative causes.

10

IQVIA / CRO Context

🏢 IQVIA's PV Services

End-to-end ICSR case processing for pharma clients
Safety database management (Argus, ARISg, Vault Safety)
Aggregate report writing (PSUR, DSUR, RMP)
Signal detection and benefit-risk assessment
Regulatory submissions (E2B R3 to EV, FDA)
QPPV services and PV system audits
Literature monitoring and screening
PV training and SOP development

💼 Common IQVIA PV Roles & Skills Expected

PV Associate — Case intake, triage, data entry, MedDRA coding
Senior PV Scientist — Medical review, narrative writing, causality
PV Systems Analyst — Argus/Vault config, GAMP 5, validation
Aggregate Report Writer — PSUR/DSUR authoring, signal summary
Signal Manager — PRR/ROR analysis, EVDAS, VigiBase queries
Regulatory Affairs (PV) — E2B submissions, HA communications

🎯 Top Tips for PV Job Interviews (CRO / Pharma)

Know your 4 minimum criteria cold

Interviewers ask this in 80% of PV interviews. Reporter, Patient, Drug, Event — never forget.

Understand the 7-day vs 15-day rule

When does the clock start? What triggers each timeline? Can you give an example?

Be able to explain E2B R2 vs R3 practically

Don't just say "XML vs SGML" — explain impact: UUID, NullFlavor, EV Gateway, ACK process.

Relate GAMP 5 to real system work

Mention change control, UAT, IQ/OQ/PQ, audit trail — show you've worked in validated environments.

Mention specific tools you've used

Oracle Argus, ARISg, Veeva Vault Safety, EudraVigilance EVWEB, MedDRA Browser, VigiAccess

Prepare a real case processing story

Walk through a case you processed: triage → coding → medical review → submission. Show your practical knowledge.

🔑 Quick-Fire Answers — Common Rapid Questions

Question	Answer
What does IBD stand for?	International Birth Date — first global marketing authorization date
What is a DLP?	Data Lock Point — cutoff date for data included in an aggregate report
What is a DHPC?	Direct Healthcare Professional Communication — urgent safety letter to HCPs
What is GVP?	Good Vigilance Practice — EMA's 16-module PV guideline for the EU
What are SOC and PT in MedDRA?	System Organ Class (top level) and Preferred Term (used for regulatory reporting)
What is a CIOMS form?	Standardized paper form for reporting serious ADRs (alternative to MedWatch for non-US)
What triggers a SUSAR?	Serious + Unexpected + Causal relationship cannot be ruled out (in clinical trials)
Who is responsible for PV in EU?	QPPV — Qualified Person for Pharmacovigilance (mandatory EU designation)
What is an SMQ?	Standardized MedDRA Query — predefined PT groupings for signal searches
What is EudraVigilance?	EMA's central EU database for ICSRs on authorized medicines in the EEA

11

MedDRA Versions & WHO-DD

What is MedDRA?

Medical Dictionary for Regulatory Activities (MedDRA) is the international standard medical terminology used across the entire regulatory cycle — from pre-clinical to post-market. It is owned and maintained by ICH and managed operationally by MSSO (Maintenance and Support Services Organization). Every adverse event, indication, and medical history entry in an ICSR must be MedDRA-coded.

🏗 MedDRA Hierarchy — 5 Levels

SOC — System Organ Class (27 classes)

Top-level anatomical/physiological grouping. e.g., Cardiac disorders, Nervous system disorders, Gastrointestinal disorders

HLGT — High Level Group Term

Groups HLTs. e.g., Cardiac arrhythmias (incl subtypes)

HLT — High Level Term

Groups related PTs. e.g., Supraventricular arrhythmias

PT — Preferred Term ⭐ (Used for regulatory reporting)

The primary term for coding. Unique, clinically meaningful. e.g., Atrial fibrillation

LLT — Lowest Level Term (links to exactly 1 PT)

Verbatim/synonymous terms that map to a PT. e.g., AF, Auricular fibrillation, Atrial flutter and fibrillation

⚠ An AE term is always coded at PT level for ICSR submission. LLT is where the verbatim term lands first, then maps up to PT. One PT can belong to multiple SOCs (multi-axiality) but has a single Primary SOC.

🗓 MedDRA Version Release Cycle

Twice a year — March (v.x.0) and September (v.x.1)
Example: v27.0 (March 2024), v27.1 (Sept 2024)
Each release adds new PTs, retires obsolete LLTs, revises hierarchies
Safety databases (Argus, ARISg) must be upgraded after each release
MSSO provides full release notes and change documentation
Regulators may mandate minimum version for submissions

March = .0 release Sept = .1 release

🔄 MedDRA Version Upgrade — What Changes in PV Systems

New dictionary loaded into safety DB (GAMP 5 validated process)
Retired LLTs get auto-upgraded to their replacement PT/LLT
Cases coded with old terms may need recoding review
MedDRA version used must be documented in each ICSR (E2B field)
Aggregate reports must state the MedDRA version used
SMQs (Standardized MedDRA Queries) also updated each release

🔬 SMQ — Standardized MedDRA Queries

SMQs are validated, pre-defined groupings of MedDRA terms (PTs and LLTs) used to retrieve cases related to a specific medical condition or area of concern. They are critical tools in signal detection, aggregate reporting, and regulatory responses.

HOW SMQs WORK

Broad scope — Captures many related PTs across SOCs
Narrow scope — Targeted subset of highly specific terms
Algorithms: Simple (OR logic) or Complex (weighted scoring)
Used in signal detection queries on FAERS, EudraVigilance

COMMON SMQ EXAMPLES

SMQ: Anaphylactic reaction
SMQ: Cardiac failure
SMQ: Hepatotoxicity
SMQ: Embolic and thrombotic events
SMQ: Drug-induced liver injury
SMQ: Stevens-Johnson syndrome

💊 WHO Drug Dictionary (WHO-DD) — Drug Coding

While MedDRA codes adverse events, the WHO Drug Dictionary (WHO-DD) is the international standard for coding medicinal products in safety databases. Maintained by WHO-UMC (Uppsala Monitoring Centre).

WHO-DD Enhanced (Standard)

ATC (Anatomical Therapeutic Chemical) codes
Ingredient-level coding
Medicinal product ID (MPID)
Used in most commercial safety DBs
Updated quarterly

WHO-DD Global (Newer)

Combines Enhanced + reference data
Links to regulatory product IDs
Supports E2B(R3) product coding
Aligns with IDMP standards
Preferred for new implementations

Why it matters in interviews: When a reporter says "I gave the patient Aspirin 100mg" — the system must map that to the correct WHO-DD entry with ATC code B01AC06. Coding must capture: drug name, dose, route, formulation, and ATC classification. The version of WHO-DD used must be documented in the case.

❓ Interview Q: MedDRA & WHO-DD

What is multi-axiality in MedDRA?+

Multi-axiality means a single PT (Preferred Term) can be linked to more than one SOC. For example, "Atrial fibrillation" belongs primarily to Cardiac disorders SOC, but can also be associated with Investigations SOC when it appears as an ECG finding.

However, each PT has only one Primary SOC which is used for ICSR tabulations and regulatory submissions. Secondary SOCs exist for cross-referencing. Interviewers test this to see if you understand why the same event might appear under different SOCs in different contexts.

What is the difference between LLT and PT, and which do you submit?+

LLT (Lowest Level Term) is where the verbatim (reporter's exact words) term is first mapped. It is the most granular level and may include synonyms, abbreviations, or old terms. Each LLT maps to exactly one PT.

PT (Preferred Term) is the standardized, unique clinical concept. It is the level used for all regulatory reporting and submission in E2B files.

Workflow: Reporter says "heart pounding" → LLT: Palpitations → PT: Palpitations → submitted in ICSR.

Key rule: You always submit at PT level. The LLT is retained in the system for verbatim traceability but regulators receive the PT.

12

Blinded vs Unblinded Reports

Why Blinding Matters in PV

In clinical trials (study cases), blinding protects the integrity of the trial. Participants and/or investigators do not know which treatment (active drug or placebo) a patient received. PV must handle adverse event reporting while preserving this blind — which creates specific rules for how drug information appears in ICSRs, SUSARs, and aggregate reports like the DSUR.

🖥 Visual Example — Blinded vs Unblinded ICSR Drug Section

The same case — same patient, same event — looks different depending on blinding status:

🔒 BLINDED Report (Study Case)

G — DRUG INFORMATION

Drug Name: STUDY MEDICATION

Study Number: STUDY-2024-001

Study Arm: BLINDED / NOT DISCLOSED

Dose: 100mg BID

Drug Role: Suspect

Actual drug name NOT shown — replaced with study name/code
Treatment arm hidden (active vs placebo unknown)
Study number & protocol number visible
Preserves trial integrity — no unblinding of site/sponsor
Submitted to regulators as blinded during trial conduct
Used in: SUSAR expedited reports, DSUR

🔓 UNBLINDED Report (Unblinded / PM Case)

G — DRUG INFORMATION

Drug Name: ATORVASTATIN 40mg

Manufacturer: Pharma Corp Ltd

Route: Oral

Dose: 40mg OD

Drug Role: Suspect

Full drug name, dose, manufacturer fully visible
All concomitant medications also fully listed
Treatment arm and assignment known
Used for: post-marketing ICSRs, unblinded SUSARs
Mandatory for EudraVigilance / FAERS submissions
Used in: PSUR, signal detection, aggregate analysis

📊 Study Cases vs Post-Marketing Cases — Full Comparison

Aspect	Study / Clinical Trial Case	Post-Marketing (PM) Case
Source	Clinical trial investigators, CRO, sponsor	HCPs, patients, literature, regulatory authorities
Drug disclosure	Blinded (study medication / protocol code) or unblinded if SAE unblinded	Always unblinded — full drug name and details
Term used	SAE (Serious Adverse Event) or SUSAR	ADR / SADR (post-market terminology)
Reference document	Investigator's Brochure (IB) — defines expectedness	SmPC / CCDS — defines expectedness
Reporting timeline trigger	SUSAR = 7/15 days (unexpected serious)	Serious unexpected ADR = 15 days
Submitted to	Competent authorities + Ethics Committees; also DSUR	EudraVigilance, FAERS, PMDA; also PSUR/PBRER
Aggregate report	DSUR (Development Safety Update Report)	PSUR / PBRER (Periodic Benefit-Risk Evaluation)
Drug in narrative	"Patient received study medication per protocol" — no name disclosed	Full product name, brand name, batch number included
Unblinding event	If SUSAR — unblinding by sponsor/DSMB; blinded version still sent to sites	Not applicable — always unblinded
Causality assessment	Investigator + Sponsor both provide separate assessments	Reporter's assessment + MAH assessment

🔓 The Unblinding Process — When & How It Happens

Unblinding of a clinical trial case is a critical decision. It should only happen when strictly necessary to protect patient safety or meet regulatory requirements.

SAE Occurs in a Blinded Trial

Investigator reports the SAE. Case is received blinded — drug field shows "study medication / [protocol code]". The 15-day reporting clock starts from receipt.

SUSAR Assessment — Is Unblinding Required?

Safety team assesses: Is the event serious? Is it unexpected per the IB? Can the relationship be excluded? If YES to all → it is a SUSAR candidate → unblinding is triggered.

Unblinding by Sponsor (Breaking the Code)

Only the unblinded pharmacovigilance team (firewall team) or DSMB (Data Safety Monitoring Board) breaks the blind. The patient's treatment allocation is revealed. The rest of the trial team remains blinded.

Two Reports Generated

Unblinded SUSAR → Submitted to regulatory authorities (EudraVigilance, competent authority). Contains full drug name.

Blinded version → Sent to investigators and Ethics Committees. Drug name still masked as "study medication". Protects trial integrity at site level.

DSUR Inclusion

All SUSARs (unblinded and blinded) are listed in the annual DSUR. Unblinded line listings go to regulatory authorities; blinded listings go to sites/ECs where necessary.

📋 What IS Visible in a Blinded Submission

Study number / Protocol number
Study phase (Phase I, II, III)
Study arm label (Arm A / Arm B — not which drug)
Dose level (e.g., 100mg — if dose itself isn't unblinding)
Route of administration
Start and stop dates of study medication
Indication being studied
Patient demographics (age, sex, weight)
Event details (MedDRA coded, outcome, dates)
Investigator causality assessment

🚫 What is HIDDEN in a Blinded Submission

Actual drug name (INN or brand)
Drug formulation / manufacturer details
Treatment arm assignment (active vs placebo)
Batch / lot number of study drug
Sponsor's causality assessment (based on unblinded data)
Any information that reveals treatment allocation
Comparator drug identity (if active control trial)

The narrative will say: "The patient received study medication as per the protocol schedule."

📦 How Blinding Reflects in E2B(R3) XML Fields

E2B Field	Blinded (Study)	Unblinded / PM
G.k.2.2 — Drug Name	Study medication / Protocol code (e.g., "XYZ-001-IMP")	Full INN or brand name (e.g., "Atorvastatin")
G.k.2.3 — WHO Drug Dictionary	Not populated (unknown/blinded)	WHO-DD coded entry with MPID
C.5 — Study Info	Populated: study number, study type, study phase	Populated only if study-related; often blank for PM
G.k.1 — Drug Role	Suspect (suspected study medication)	Suspect / Concomitant / Interacting
H — Narrative	Describes event without revealing treatment; uses protocol language	Full drug name, dose, and regimen stated explicitly
G.k.8 — Action taken	Study drug discontinued / dose reduced (no name)	Drug name + action fully stated

BLINDING Q&A — INTERVIEW QUESTIONS

Why is blinding maintained in clinical trial ICSRs even when reporting to regulators?+

The key principle is protecting trial integrity. If drug identity were revealed in expedited reports sent to all investigators and ethics committees, it could introduce bias — investigators might alter their clinical judgment, patients might withdraw, or the trial's statistical validity could be compromised.

Regulatory authorities (competent authorities) do receive unblinded SUSARs — they need the full picture for safety oversight. However, the blinded version is sent to investigators and ethics committees to keep the trial uncontaminated.

This is why two parallel reports are often generated for a SUSAR: one unblinded for regulators, one blinded for sites.

What happens when an SAE in a clinical trial is NOT a SUSAR?+

An SAE that does NOT meet SUSAR criteria (i.e., it is expected per the IB, or the drug relationship is clearly excluded) is:

→ Still documented and tracked in the safety database
→ Not subject to expedited 7/15-day reporting
→ Included in aggregate reporting — the DSUR (line listings of all SAEs)
→ The drug field remains blinded in the DSUR line listing sent to sites

The DSUR submitted to regulatory authorities contains unblinded data; the version for investigators/ECs may be blinded depending on regional requirements.

In a post-marketing case, what is always different from a study case in the drug section?+

In a post-marketing (PM) case:

→ Drug name is always fully disclosed — INN (International Nonproprietary Name) and/or brand name
→ WHO-DD coded entry with ATC code is populated
→ Batch/lot number may be included (especially for biologics or vaccine cases)
→ All concomitant medications are also fully named
→ There is no study number — the C.5 study section is not applicable
→ The narrative states the drug explicitly: "The patient was taking Atorvastatin 40mg once daily..."

Contrast this with a blinded study case where you would read: "The patient was receiving study medication as per Protocol STUDY-2024-001."

Who can unblind a clinical trial case, and what controls exist?+

Unblinding is a controlled, documented process governed by the clinical trial protocol and SOPs. Key controls:

Who can unblind:
→ The Sponsor's unblinded pharmacovigilance team (firewall team)
→ The DSMB / IDMC (Data Safety Monitoring Board / Independent Data Monitoring Committee)
→ In emergencies: the treating physician can request emergency unblinding via 24/7 code break

Controls:
→ Emergency unblinding instructions and sealed envelopes / electronic code-break at site
→ Code-break is logged in audit trail with reason, date, time, person
→ The blind must not be broken unnecessarily — all unblinding decisions are documented
→ Investigators who unblind are usually removed from the trial to prevent bias

13

Oracle Argus Workflows

What is Oracle Argus Safety?

Oracle Argus Safety is the world's most widely used pharmacovigilance safety database. It is a web-based enterprise system used by MAHs and CROs (including IQVIA) to manage the complete ICSR lifecycle — from intake and triage through medical review, regulatory submission, and aggregate reporting. It is a GAMP 5 Category 4 configured product and must be fully validated under 21 CFR Part 11.

🗺 Argus Architecture — Key Modules

Argus Safety (Core)

Main case processing module. Intake, triage, data entry, medical review, workflow routing, submission tracking.

Argus Interchange

E2B import/export engine. Handles E2B R2 and R3 XML generation, gateway submission, ACK processing, partner exchange.

Argus Analytics

Reporting and signal detection. Dashboards, KPI tracking, aggregate line listings, regulatory submission reports.

Argus Console

Admin/configuration module. User management, workflow rules, coding dictionaries, business rules, system settings.

Argus Affiliate

Lightweight portal for affiliate/partner companies to enter local cases without access to full Argus. Cases flow into central Argus for processing.

Argus Dossier / MedDRA / WHO-DD

Dictionary management sub-modules for loading and managing MedDRA and WHO-DD versions within Argus.

🔁 End-to-End Case Workflow in Oracle Argus

Step 1 — Case Intake / Receipt

Case enters Argus via: E2B XML import (partner/regulatory), manual data entry (phone/fax/email), or Argus Affiliate portal.
System assigns: Case Number (e.g., IQVIA-2024-001234), Initial Receipt Date (Day 0 for clock), Country of Incidence.
Argus auto-checks: Does it meet 4 minimum criteria? If not → marked as Non-case.

Step 2 — Triage / Initial Assessment

Triage team assigns: Seriousness (Serious/Non-serious), Listedness (Expected/Unexpected vs SmPC/IB), Causality (initial), Case Priority.
Argus auto-calculates Due Date based on: seriousness + listedness + receipt date. System shows countdown timer.
Case routed to appropriate workflow queue (7-day queue or 15-day queue).

Step 3 — Data Entry

PV Associate enters all case details across Argus tabs:
General tab → Case type, source, report type
Patient tab → Demographics, medical history, lab data
Products tab → Drug name (WHO-DD coded), dose, route, dates, role
Events tab → AE description, MedDRA PT/LLT coding, onset/resolution dates, outcome, seriousness criteria
Analysis tab → Causality, listedness, reporter narrative

Step 4 — MedDRA & WHO-DD Coding

Verbatim term entered → Argus opens MedDRA browser → Coder selects appropriate LLT → auto-maps to PT → SOC assigned.
Drug verbatim → WHO-DD browser → Coder selects product → ATC code assigned.
Coding must match the current dictionary version loaded in Argus.

Step 5 — Medical Review

Physician / Senior PV Scientist reviews: seriousness, causality, expectedness, coding accuracy.
Writes or approves the case narrative — a structured clinical summary of the case.
May initiate follow-up requests (Argus generates follow-up letters automatically).
Signs off with electronic signature (21 CFR Part 11 compliant).

Step 6 — Quality Check (QC)

QC reviewer checks for completeness, consistency, regulatory compliance.
Argus validation checks run automatically (mandatory fields, date logic, coding rules).
Any errors flagged → case sent back to data entry queue with comments.
QC approved → case moves to submission queue.

Step 7 — Regulatory Submission via Argus Interchange

Argus Interchange generates E2B(R3) XML for each required authority.
Submission rules configured per product/country: e.g., Serious + Unexpected → EudraVigilance + FDA FAERS.
XML transmitted via EV Gateway (EU) or uploaded to FDA ESG.
Argus tracks submission status: Submitted → ACK Received → Accepted / Rejected.
ACK errors auto-flagged for correction and resubmission.

Step 8 — Follow-Up & Case Lock

Follow-up information received → new version created (v1, v2, v3…).
If significant new info → new 15-day clock starts.
Once no more follow-up expected → case is Locked.
Locked cases require a Change Request to reopen (audit trail maintained).

⚙ Argus Configuration — What PV Analysts Must Know

Workflow rules — Define routing logic (who gets which case type)
Auto-scheduling — Argus auto-calculates due dates based on rules
Reporting rules — Country × Seriousness × Listedness = report destination
Dictionary versions — MedDRA and WHO-DD must be loaded and validated
Product configuration — SmPC / CCDS / IB loaded per product for listedness check
User roles — Data Entry, Medical Reviewer, QC, Submission, Admin (RBAC)
Audit trail — Every field change logged with user, timestamp, old/new value
Lock/Unlock controls — Only authorized users can unlock a case

🛡 System Validation of Oracle Argus (GAMP 5 Cat 4)

URS — Argus must meet all user requirements (case processing, E2B, audit trail)
IQ — Verify correct Argus version installed, DB configured, network set up
OQ — Test each configured function: workflows, routing, auto-calculations, E2B export
PQ — End-to-end business scenario testing with real-world case types
Change Control — Any config change (new workflow rule, dictionary upgrade) goes through formal CCR
Regression Testing — After every change, existing functions re-tested
Traceability Matrix — Maps each URS requirement to test scripts and test results

🔍 Common Argus Interview Q&A

What is the difference between Argus Safety and Argus Interchange?+

Argus Safety is the core case processing module where PV teams intake, process, review, and manage ICSRs. It handles all the clinical and regulatory data entry, workflow routing, and narrative writing.

Argus Interchange is the electronic transmission engine. It generates E2B R2/R3 XML files, manages submission schedules and profiles per authority, handles gateway connectivity (EV Gateway, FDA ESG), processes inbound E2B files from partners, and manages ACK (acknowledgement) tracking.

Think of it this way: Argus Safety = where the work happens; Argus Interchange = where the reports go out and come in.

What is a reporting rule in Argus and how does it work?+

A reporting rule in Argus is a configured logic statement that automatically determines whether a case needs to be submitted to a specific regulatory authority and within what timeframe.

Rules are based on: Product + Country of Incidence + Seriousness + Listedness + Case Type

Example rule: If Product = Drug A AND Country = Germany AND Serious = Yes AND Listed = No (unexpected) → Submit to EudraVigilance within 15 days.

Argus evaluates all applicable rules when a case is saved and auto-schedules the required submissions. PV teams must regularly audit these rules, especially after product label updates (SmPC changes affect listedness determination).

What happens in Argus when an ACK comes back as rejected?+

When an ACK (acknowledgement) from EudraVigilance or another authority comes back as Rejected, Argus Interchange flags the case with an error status. The rejection includes an error code and description — common reasons include:

→ XML schema validation failure (missing mandatory field)
→ Business rule violation (e.g., date logic error — onset before birth date)
→ Duplicate detection (same worldwide unique case ID already exists)
→ MedDRA version mismatch

The PV team must: (1) identify the error from ACK message, (2) correct the data in Argus, (3) re-generate the E2B XML, (4) resubmit within the original deadline. All correction steps are documented in audit trail. Repeated rejections must be escalated per SOP.

14

Mock Interview Scenarios

How to Use This Section

These are scenario-based interview questions — the kind where the interviewer describes a real situation and asks how you would handle it. Read each scenario, think through your answer, then reveal the model response. These test practical knowledge, not just definitions.

📋 CASE PROCESSING SCENARIOS

Scenario: You receive a call from a nurse reporting that a patient taking your company's drug developed severe liver failure and was hospitalized. She gives her name and the patient's initials. What do you do?+

Step 1 — Validate the 4 minimum criteria:
✅ Reporter: Nurse (name given) ✅ Patient: Initials provided ✅ Suspect drug: Company drug named ✅ AE: Liver failure
→ Valid ICSR. Day 0 clock starts NOW.

Step 2 — Assess seriousness:
Severe liver failure + hospitalization = Serious (hospitalization + potentially life-threatening criteria met).

Step 3 — Determine expectedness:
Check current SmPC / CCDS — is severe liver failure listed? If NO → Unexpected.

Step 4 — Reporting obligation triggered:
Serious + Unexpected + Drug relationship cannot be excluded = 15-day expedited report required to all applicable authorities.

Step 5 — Immediate actions:
→ Document all information in Argus immediately
→ Attempt to gather additional details: patient age, concomitant medications, lab values (ALT, AST, bilirubin), outcome, dose and duration, rechallenge/dechallenge
→ Inform medical/safety physician for urgency review
→ Raise follow-up request to nurse for medical records
→ Monitor case due date in Argus — do not miss the 15-day deadline.

Scenario: You get an E2B XML file from a business partner with 50 cases. When imported into Argus, 8 cases are rejected with duplicate errors. What do you do?+

Understand the error: Duplicate detection in E2B R3 works via the worldwide unique case safety report ID. If a case with the same ID already exists in Argus, it's flagged as a duplicate.

Investigation steps:
1. Pull the 8 rejected case IDs from the Argus Interchange error log
2. Search Argus for these case IDs — do they already exist as cases entered by another route (e.g., direct reporter, literature)?
3. If true duplicates → link them as duplicates in Argus (do not process twice), notify partner, document the resolution
4. If NOT true duplicates (ID collision due to a system issue) → investigate with partner's PV team, correct the IDs, re-import

Regulatory impact:
Duplicate cases must NOT be submitted twice to regulators. If one route already resulted in a submission, document which submission covers the case and close the duplicate accordingly. All decisions documented in audit trail and communicated to partner per SLA timelines.

Scenario: A case comes in with the reporter saying "the patient took the drug for 3 months and then died." There's no mention of any adverse event. Is this a valid ICSR?+

Yes — Death itself IS the adverse event.

This is a classic trick question. "Death" qualifies as an adverse event on its own. The 4 minimum criteria are:
✅ Reporter: Yes (assumed from contact) ✅ Patient: Yes (implied) ✅ Suspect drug: Yes ✅ AE = Death ✅

Action:
→ Process as a valid ICSR
→ MedDRA code: Death (PT) under SOC: General disorders and administration site conditions
→ Seriousness = Fatal
→ If unexpected → 15-day expedited report (or 7-day if life-threatening was also suspected)
→ Actively seek follow-up: cause of death, autopsy results, medical history, concomitant medications

Key learning: Always look at what the reporter is telling you holistically — death is an outcome AND an AE.

🛡 SYSTEM VALIDATION SCENARIOS

Scenario: Your team upgrades Oracle Argus from version 8.1 to 8.2. A new workflow routing rule is added. What validation steps are needed before go-live?+

This is a configured system change → GAMP 5 Category 4 validation process applies.

Step 1 — Change Control:
Raise a formal Change Request (CCR). Document: what is changing, why, risk assessment, rollback plan. Get approval from PV management and QA.

Step 2 — Impact Assessment:
Determine which existing functions may be affected by the version upgrade and new routing rule. Create regression test scope.

Step 3 — Update Validation Documents:
→ Update or create: Test Scripts (OQ level) for the new routing rule
→ Update traceability matrix linking URS → test scripts

Step 4 — Testing in Validation Environment:
→ IQ: Confirm v8.2 installed correctly, system logs, DB migration complete
→ OQ: Test new routing rule — create test cases matching rule criteria, verify correct routing
→ Regression: Re-run existing test scripts for core functions (data entry, submission, E2B export)
→ UAT: Business users test real-world scenarios

Step 5 — Defect Resolution & Sign-off:
All defects triaged, resolved, and retested. QA signs off. Validation Summary Report produced.

Step 6 — Go-Live & Post-Implementation Review:
Controlled release to production. Monitor for 30 days. Document any issues.

Scenario: An auditor asks you to prove that a case was not modified after submission. How does Argus support this?+

Argus Audit Trail is the answer — a 21 CFR Part 11 compliant, tamper-proof log of every action taken in the system.

What the audit trail captures:
→ Every field-level change: old value → new value
→ User ID of who made the change
→ Date and timestamp (system-generated, not user-editable)
→ Reason for change (for locked case modifications)
→ Workflow actions: routing, approvals, electronic signatures

How to demonstrate to auditor:
1. Open the case in Argus → go to Case History / Audit Log tab
2. Show all versions of the case (v0 = initial, v1 = follow-up, etc.)
3. Show the submission record with timestamp and authority
4. Show that after the submission timestamp, no data-critical fields were modified
5. If changes were made post-submission → a new version was created and resubmitted (documented)

The audit trail cannot be edited, deleted, or circumvented — this is a core 21 CFR Part 11 requirement that Argus is validated to meet.

🔒 BLINDING & STUDY SCENARIOS

Scenario: An investigator calls and says a patient in Trial XYZ-001 had a serious cardiac arrest. He doesn't know if the patient was on active drug or placebo. What do you do, and how does blinding affect your SUSAR assessment?+

Immediate actions:
→ Confirm 4 minimum criteria — valid ICSR, Day 0 clock starts
→ Enter in Argus with drug as: "Study Medication — Protocol XYZ-001" (blinded)
→ Seriousness = Fatal/Life-threatening → potential 7-day report if confirmed

Blinding assessment challenge:
The case is blinded — you don't know if active drug or placebo caused it. Standard approach:

→ Worst-case assumption: Treat as if the patient was on active drug for SUSAR assessment
→ Check IB — is cardiac arrest listed? If NO → Unexpected
→ Serious + Unexpected + Causality cannot be excluded = SUSAR

Unblinding decision:
→ SUSAR identified → sponsor's unblinded safety team breaks the blind to confirm
→ If patient was on active drug → confirmed SUSAR → unblinded report to regulators within 7 days
→ If patient was on placebo → not a SUSAR for the study drug; still document, may still report depending on protocol
→ Blinded version sent to investigator and Ethics Committee

Key principle: When in doubt about blinding, always escalate to unblinded safety team — never make unblinding decisions alone as a PV associate.

Scenario: Interviewer asks — "Tell me about a time you handled a complex case or validation challenge at IQVIA." How do you structure your answer?+

Use the STAR method — Situation, Task, Action, Result. Here's a template framed for PV:

Situation: "While working at IQVIA on [client name / therapeutic area], we received a batch of E2B XML files from a partner that had multiple ACK rejections due to MedDRA version mismatch after a dictionary upgrade."

Task: "I was responsible for identifying the root cause, coordinating with the partner's PV team, and ensuring all affected cases were corrected and resubmitted without missing the regulatory deadline."

Action: "I pulled the ACK error logs from Argus Interchange, identified that the partner was submitting MedDRA v26.1 terms while our system expected v27.0. I escalated to the technical team to map the affected terms, updated the cases in Argus with the correct v27.0 codes, and regenerated the E2B XMLs. I also flagged the partner to update their dictionary going forward."

Result: "All 12 affected cases were resubmitted and accepted within the 15-day deadline. We then created a standard pre-submission checklist to verify dictionary version alignment for all partner exchanges — which prevented recurrence."

Tip: Always quantify where possible (number of cases, timeline, outcome). Show you understand both the technical and regulatory sides of the problem.

⚡ Mock Rapid Fire Round — 30-Second Answer Questions

Question	Expected Answer
What Argus module generates E2B XML?	Argus Interchange
What is Day 0 in case processing?	Date MAH first receives valid case information
Name 3 Argus workflow states	Data Entry → Medical Review → QC → Submission
What is a locked case in Argus?	A case where no further changes are expected; reopening requires Change Request + audit trail
How does Argus detect duplicates?	Via worldwide unique case safety report ID (UUID in E2B R3)
What validation category is Oracle Argus?	GAMP 5 Category 4 — Configured Product
What does UAT stand for in validation?	User Acceptance Testing — business user sign-off before go-live
What is a traceability matrix?	Document mapping URS requirements → test scripts → test results
What triggers a new 15-day clock?	Significant new information on an existing case
Can you edit a submitted case in Argus?	Only via a new version (follow-up case) — original submission is immutable in audit trail