Most descriptions of CRO pharmacovigilance describe case processing — intake, triage, coding, assessment, submission — as though the only difference from in-house PV is who is doing the typing. In practice the case workflow is the part that goes well. What goes wrong in outsourced pharmacovigilance is almost always a boundary problem: an obligation each party believed the other owned, a datasheet version that was updated on one side only, a reconciliation that surfaced fifty discrepancies a week before a periodic report was due.
This guide walks the operating model rather than the case lifecycle: the agreement that defines the boundaries, how responsibilities split, what has to be configured per sponsor, how case flow works when one team serves many clients, the reconciliation cadence, and the metrics that get reported every month.
Scope of this guide
This describes general industry practice to help you structure an operation and specify a system. It is not regulatory advice. Your obligations come from your agreements, applicable legislation, and your own qualified PV personnel — not from a vendor's guide.
The safety data exchange agreement — the SDEA, sometimes called a PV agreement or safety agreement — is the document that makes an outsourced operation workable. It is negotiated per sponsor, and every downstream configuration decision derives from it. If your SDEAs are vague, no system configuration will save the operation.
At minimum, an SDEA should settle the following. Treat any item left unresolved as an operational risk you have accepted on the sponsor's behalf.
| Area | What must be explicit |
|---|---|
| Case ownership | Who holds the master safety database, and whether the CRO's system or the sponsor's is the system of record |
| Reporting responsibility | Which party submits to which authority, in which format, for which market and case type |
| Exchange timelines | How quickly cases and follow-up move between the parties — usually in calendar days from receipt, tighter than the regulatory clock to leave the submitting party room |
| Day 0 definition | Whose receipt date starts the clock when a case arrives at one party and is submitted by the other |
| Reference safety information | Who maintains the CCDS/CCSI, SmPC and USPI, how version updates are communicated, and the effective date of a new version |
| Medical assessment | Who performs causality and expectedness assessment, and whose assessment prevails where they differ |
| Literature monitoring | Which party searches, which databases and journals are in scope, and the cadence |
| Signal management | Who runs detection, who reviews signals, and how a signal escalates to the sponsor |
| Aggregate reports | Who authors, who supplies listings and tabulations, and the data lock point schedule |
| Reconciliation | Frequency, scope, the format of the exchange, and how discrepancies are resolved and documented |
| Audits and inspections | Notice periods, right-of-audit scope, and how the CRO supports a regulatory inspection of the sponsor |
| Metrics | Which KPIs are reported, at what frequency, and how they are calculated |
| Exit | Data return format, timeline, retention obligations after termination, and who bears the cost |
The two clauses most often too loose
Reference safety information versioning and exchange timelines. If the SDEA does not state how a new datasheet version reaches the processing team and when it takes effect, listedness assessments will be made against a superseded version — and that is a finding. If exchange timelines are not tighter than the regulatory clock, the submitting party inherits an impossible deadline.
Outsourcing execution does not outsource accountability. The marketing authorisation holder retains regulatory responsibility for pharmacovigilance regardless of who performs the work, and the QPPV — whether the sponsor's own or provided under contract — remains personally accountable. A CRO performs activities; it does not absorb the sponsor's obligations.
That has a practical consequence for system design: the audit trail has to be good enough for a party who was not present to reconstruct what happened. A sponsor being inspected will need to demonstrate oversight of your activities, which means they will ask for evidence out of your system.
Retains
Regulatory accountability, the QPPV function (unless contracted), reference safety information ownership in most arrangements, benefit-risk decisions, and oversight of the CRO's performance.
Performs
Case receipt and processing, coding, assessment where delegated, submission where delegated, literature screening, reconciliation, and reporting of agreed metrics.
Share
Reconciliation, signal escalation, inspection readiness, and change control when either side updates SOPs, datasheets, or reporting rules.
Supplies
The application, environment setup, and supporting documentation. Not PV decisions, not regulatory interpretation, not SOP content, and not validation execution.
Where our own responsibility ends
PVgenix develops and delivers the software, the environment setup, and the supporting documentation. The client and their qualified PV personnel own PV decisions, regulatory interpretation, validation execution, and compliance obligations.
Once the SDEA is signed, the configuration work is essentially a translation exercise: the agreement's clauses become system settings. This is where a platform either supports a CRO or fights it — if any of the following requires a vendor ticket or a release, your ability to onboard and adapt is capped by someone else's queue.
- Reporting rules — which authority receives which case, in which format, within which timeline, driven by seriousness, expectedness, market, and study versus spontaneous source
- Regulatory clock configuration — Day 0 determination per reporter region, consistent with the SDEA's definition
- Workflow states and review gates — matched to that sponsor's SOPs, including who signs off what
- Intake channels and forms — a dedicated mailbox, reporter portal, form fields, and validation rules per client
- Reference safety information — the sponsor's CCDS/CCSI, SmPC, and USPI under version control, with the effective date recorded
- Dictionary versions — MedDRA and WHO Drug Dictionary versions, administered centrally (licensed by the client, not the software provider)
- Code lists and picklists — product names, study identifiers, and sponsor-specific values
- Study and protocol configuration — study-specific reporting rules, blinding requirements, and SUSAR criteria for interventional work
- Notifications and escalations — distribution lists, escalation paths, and alerts before an SDEA or regulatory deadline is breached
- User access — tenant-scoped roles under least privilege, aligned to segregation of duties
- Metrics — the KPI set and calculation method the contract specifies
In PVgenix all of the above is administered per tenant from the admin console without a code change. See multi-client pharmacovigilance system for how tenant scoping is implemented, and pharmacovigilance software for CROs for the operating model in commercial terms.
The case lifecycle itself is standard — intake, duplicate check, triage, data entry and coding, assessment, quality review, medical review, submission. What changes in a CRO context is that every step carries a tenant context, and getting that context wrong is a data-integrity event rather than a typo.
| Stage | The CRO-specific consideration |
|---|---|
| Intake | Each sponsor needs its own intake route so the tenant is determined by the channel, not chosen by a person after the fact |
| Duplicate detection | Matching must run within the tenant's case population — a cross-tenant match would itself be a segregation breach |
| Triage | Prioritisation competes across sponsors for the same team's time; the queue needs to respect each SDEA's exchange timelines, not just the regulatory clock |
| Coding | Dictionary version is per tenant, so the same term may code differently for two sponsors on different MedDRA versions — and that is correct |
| Assessment | Expectedness resolves against that sponsor's datasheet version in force on the assessment date; causality algorithm may differ per sponsor |
| Quality review | Review gates and sign-off roles follow the sponsor's SOPs, which may be stricter than your internal default |
| Submission | Only for authorities the SDEA delegates to you — submitting a case the sponsor also submits creates a duplicate in the authority's database |
| Follow-up | Versioning must preserve what was reported at each earlier point, because reconciliation and periodic reports depend on it |
The duplicate-submission trap
Where both parties can submit, an unclear SDEA produces duplicate reports in the authority's database — which is visible to the regulator and difficult to explain. Reporting responsibility must be unambiguous per authority, per market, and per case type, and it must be configured in the rules engine rather than remembered by whoever is on duty.
Reconciliation is the periodic comparison of case populations between two systems or two parties to confirm nothing was lost in transit. In a CRO operation there are usually three kinds running, and they catch different failures.
| Type | Compares | Catches |
|---|---|---|
| Sponsor reconciliation | Your case population against the sponsor's, per the SDEA cadence | Cases that never arrived, follow-up that was not exchanged, status mismatches |
| Partner reconciliation | Cases exchanged with licence partners or distributors | Missing partner cases, which are a common inspection finding because the flow is easy to neglect |
| Clinical-versus-safety | The clinical database against the safety database for study cases | Adverse events recorded in the trial database that never became ICSRs |
Two practical points. First, run reconciliation frequently enough that a discrepancy is a small correction rather than an investigation — monthly is common, quarterly is often too late, and discovering fifty discrepancies the week before a data lock point is a predictable consequence of an infrequent cadence. Second, the resolution of each discrepancy has to be documented, not just fixed: an inspector will ask what the root cause was and what changed as a result.
PVgenix supports licence-partner reconciliation and clinical-versus-safety database reconciliation with a discrepancy tracking and resolution workflow, and quality findings can be routed into CAPA and deviation records — see quality management.
Almost every sponsor contract carries a monthly performance report, and the metric that matters most is on-time submission rate. The important operational question is not what the number is but where it comes from: if it is compiled by hand from exports, it consumes senior time every month and you are contractually asserting a manually produced figure.
| Metric | What it actually tells you |
|---|---|
| On-time submission rate | The headline compliance number, per sponsor and per authority — the first thing an inspector or sponsor auditor asks for |
| SDEA exchange compliance | Whether cases moved between the parties inside the contractual window, which is usually tighter than the regulatory clock |
| Case processing cycle time | Throughput and capacity health; a rising trend predicts a late submission before one happens |
| Data quality / QC failure rate | Where training or configuration is weak, broken down by processor and case type |
| Duplicate detection rate | Whether intake routing and matching are working, or effort is being spent twice |
| Follow-up cycle time | Responsiveness on incomplete cases, which drives both data quality and reportability |
| Backlog and ageing | The leading indicator of a compliance problem, and the one most often reported too late |
| Reconciliation discrepancy count | The health of the interfaces between parties and systems |
PVgenix computes on-time submission metrics from the submission records themselves, scoped per sponsor and per authority, with overdue and at-risk queues surfaced to an accountable owner before a deadline passes rather than after. See regulatory submission.
A CRO gets audited more often than a single MAH does, because every sponsor has a right of audit and each exercises it on their own schedule. Add regulatory inspections of your sponsors, in which you may be visited or asked to produce evidence at short notice. Readiness therefore has to be a standing state, not a project.
- Can you produce the full history of any case — every version, every assessment, every submission, every acknowledgement — within minutes?
- Can you show which datasheet version was in force when a listedness call was made?
- Can you demonstrate tenant segregation architecturally, not just by showing role settings?
- Can you evidence that the people who processed a sponsor's cases were trained on that sponsor's SOPs, with dated training records?
- Can you show your on-time submission figure being derived, rather than asserted?
- Can you produce the reconciliation history and the resolution of each discrepancy?
- Can you show change control for a configuration change — who requested it, who approved it, when it took effect?
Every one of those is a system capability question as much as a process question. A platform that captures the audit trail as a by-product of normal work answers all seven; one that relies on people remembering to record things answers none of them reliably.
Validation is environment-specific
PVgenix is validation-ready and audit-ready: it ships with a complete IQ/OQ/PQ documentation package to support client-led validation. 'Validated' is a state achieved only after qualification is executed in a specific client environment.
The failure modes of a growing CRO PV operation are predictable, and most are structural rather than a matter of effort.
| Failure mode | Structural fix |
|---|---|
| Onboarding becomes the bottleneck | Tenant provisioning that your team performs without a vendor engagement, so a new sponsor is a configuration task |
| Configuration drift between sponsors | Per-tenant configuration held in the platform and change-controlled, rather than in local documents and habit |
| Metrics reporting consumes senior time | KPIs computed from system records per tenant instead of compiled manually each month |
| Deadline misses at volume | A rules engine that derives obligations and deadlines automatically, plus escalation before breach |
| Training records fall behind | A segregated training environment and training-record tracking tied to roles |
| Audit preparation becomes a project | An audit trail generated by normal work, exportable per tenant on demand |
| One sponsor's residency clause blocks a deal | The option of a dedicated single-tenant deployment in a specified region, on the same codebase |
The short version
CRO pharmacovigilance is a boundary-management discipline. Get the SDEA explicit, translate every clause into per-tenant configuration you control, keep reconciliation frequent, and derive your metrics from the system rather than assembling them. The case workflow is the easy part.
Next: best pharmacovigilance software for CROs for the evaluation questionnaire, what PV technology your CRO should have if you are the sponsor doing the assessing, and the reporting rules engine for how obligations resolve into submissions.
Frequently asked questions
Common questions
An SDEA — also called a PV agreement or safety agreement — is the contract between a marketing authorisation holder and a partner such as a CRO or licence partner that defines how safety information is exchanged. It settles who holds the master safety database, which party reports to which authority, the exchange timelines between the parties, how Day 0 is defined, who maintains reference safety information, who performs medical assessment, reconciliation cadence, audit rights, the metrics reported, and what happens to data at contract end. Every per-sponsor system configuration decision derives from it.
The marketing authorisation holder retains regulatory responsibility regardless of who performs the work, and the QPPV remains accountable. A CRO performs delegated activities; it does not absorb the sponsor's obligations. Practically this means the sponsor must be able to demonstrate oversight of the CRO's activities during an inspection, which is why the CRO's audit trail and metrics have to be produceable as evidence by a party who was not present when the work was done.
Frequently enough that a discrepancy is a small correction rather than an investigation. Monthly is common practice; quarterly frequently proves too late, particularly when a data lock point for a periodic report is approaching. The specific cadence should be stated in the SDEA. Equally important is documenting the resolution of each discrepancy and its root cause, because an inspector will ask what changed as a result rather than just whether it was fixed.
An SDEA that does not state reporting responsibility unambiguously per authority, per market, and per case type. Where both parties believe they may submit, the same case reaches the authority twice, which is visible to the regulator and awkward to explain. The fix is contractual clarity translated into a configured rules engine, so the destination of a case is derived by the system rather than recalled by whoever is on duty.
On-time submission rate is the headline, reported per sponsor and usually per authority. Contracts commonly add SDEA exchange compliance, case processing cycle time, data quality or QC failure rate, follow-up cycle time, backlog and ageing, duplicate detection rate, and reconciliation discrepancy counts. Backlog and ageing are the most useful leading indicators — they predict a late submission before one occurs — and are the most frequently reported too late.
Through tenant isolation enforced by the platform rather than by process. In a multi-tenant system, each sponsor is a separate tenant with data partitioning, tenant-scoped role-based access control under least privilege, per-tenant configuration and reference data, and audit logging within that tenant. Where a sponsor contract requires physical separation, a dedicated single-tenant deployment provides an isolated application and database, optionally in a specified region.