Sponsor organisations assess CROs thoroughly on people, process, and price. Technology is often assessed thinly — a demo, a confirmation that the system is "21 CFR Part 11 compliant", and a tick in a qualification questionnaire. That is a gap worth closing, because when a regulator inspects you, the technology your provider runs on becomes your evidence base.
The marketing authorisation holder retains regulatory responsibility for pharmacovigilance regardless of who performs the work. In practice that means you will be asked to demonstrate oversight of activities performed in a system you do not own and may not have access to. Whether you can do that is decided during vendor selection and contracting — not during the inspection.
Who this guide is for, and its limits
This is written for sponsors and MAHs assessing a service provider's safety technology. It describes general industry practice to help structure a due-diligence exercise; it is not regulatory or legal advice, and your obligations derive from applicable legislation, your agreements, and your own qualified PV personnel. We build a PV platform, so weigh our perspective accordingly — the checklists below are written to be useful regardless of which system your provider uses.
Four things that happen routinely are all constrained by the provider's system rather than by their team's competence.
You are inspected, not them
An inspector asks you to evidence oversight of outsourced activities. If the provider's system cannot produce case-level history, submission evidence, and derived metrics on demand, you cannot answer well.
Your data is in their tenant
Segregation from the provider's other clients is an architectural property of their platform. You inherit whatever it actually is, and you will be asked to describe it.
Your reportability logic is their configuration
Which authority receives which case, on which clock, is configured in their system. A misconfiguration produces late or duplicate submissions attributed to you.
Contracts end
At transition you need your complete case history in a usable format on a defined timeline. If their platform makes export a bespoke engagement, your exit clause is unenforceable in practice.
"Your data is completely separate" is an assurance, not an answer. There are two credible architectures and you should establish which one applies to you specifically, because a provider may run both and place you on either.
| Model | What it means | Verify |
|---|---|---|
| Logical isolation (multi-tenant) | One application and database serving multiple clients, with data partitioned and access scoped per tenant | That partitioning is enforced below the permission layer; that reference data, code lists, and dictionary versions are tenant-scoped rather than global; that no cross-client view is reachable from your tenant |
| Physical isolation (single-tenant) | A separate application and database instance for you, optionally in a specified region | That it genuinely is a separate instance; who has administrative access; the hosting region; and how patching and release management work for your instance |
Neither model is inherently unacceptable — logical isolation is normal and appropriate for most relationships. What matters is that you know which you have, can describe it accurately to an inspector, and hold documentation supporting it. Ask explicitly what the provider is permitted to share with you and get that written into the agreement, because vendor documentation is frequently confidential by default.
Every safety system claims an audit trail. The differences are in depth, immutability, and whether you can get it out. Test it during the demo on a real case rather than reading the specification.
- Does it capture create, read, update, and delete — or only changes? Read access matters for confidentiality investigations.
- Does every entry record who, what, when, and the before and after values?
- Is it tamper-evident, and who at the provider could alter or purge it?
- Are AI-assisted or automated steps logged as clearly as human ones, including what was proposed and what a reviewer changed?
- Can you retrieve the complete history of one case — all versions, assessments, submissions, acknowledgements — as an export you can hand to an inspector?
- Are electronic signatures captured and verifiable, and bound to the records they approve?
- How long is it retained, and does retention survive the end of the contract?
The test that separates real from claimed
In the demo, ask them to pick a case at random, make a change, and show you the audit entry — then export the full history of that case. Systems with genuine audit depth do this in under a minute. Systems without it produce a filtered screen and an offer to "follow up with a sample".
Reporting rules encode regulatory interpretation, and regulatory interpretation is yours to own. A frequent and consequential ambiguity is that the provider configures rules based on their reading of your obligations, and nobody documents that you reviewed and approved them.
- Ask to see the configured reporting rules for your products in writing — which authority, which format, which timeline, driven by which case attributes
- Establish who approves the rule set and who approves changes to it; this should be you, under change control
- Confirm how Day 0 is determined and that it matches the definition in your safety data exchange agreement
- Confirm that rules are configurable per market and per protocol, so a new market does not require a vendor release
- Check that submission deadlines are tracked per obligation with escalation before breach, not reported after the fact
- Confirm which authorities and formats are supported — E2B(R2) and E2B(R3), CIOMS I, MedWatch 3500A at minimum — and whether the AS2 gateway is included or a separately licensed product
The clause most often missing
That you review and approve the reporting rule configuration for your products, and that changes to it require your documented approval. Without it, an interpretation of your regulatory obligations is being made and maintained on your behalf with no approval record — and a late or duplicate submission resulting from it is still attributed to you.
Demonstrating oversight is difficult if your only visibility is a monthly PDF produced by the party you are overseeing. Ask what direct access you can have, and what it is scoped to.
| Level | What you get | Oversight strength |
|---|---|---|
| Periodic report only | A monthly document compiled by the provider | Weak — you are accepting a manually produced figure with no ability to test it |
| On-request extracts | Data pulls when you ask | Moderate — better, but latency means problems surface after they matter |
| Read-only tenant access | Your own login, scoped to your tenant, showing live cases, queues and metrics | Strong — you can verify rather than trust, and see backlog and ageing as it develops |
| Read-only access plus derived metrics | The above, plus KPIs the system computes from submission records rather than compiled by hand | Strongest — the reported number and the underlying record are the same thing |
Read-only sponsor access is a reasonable ask and a good signal when granted readily. Where a provider cannot offer it, understand whether that is a platform limitation or a policy choice, and price the additional oversight effort accordingly.
On-time submission rate is the metric your agreement almost certainly specifies. The question to ask is how it is calculated. If it is compiled manually from exports, three things follow: it is expensive to produce, it is subject to human error, and it is difficult for you to verify. If it is computed by the system from submission records, the number and its evidence are the same artefact.
- Ask how each contracted KPI is calculated, and get the definition in writing — including what counts as on time and how the denominator is constructed
- Ask whether backlog and case ageing are reported; they are the leading indicators and the ones most often reported too late
- Ask for reconciliation discrepancy counts and how each was resolved, not just that reconciliation occurred
- Ask whether metrics are scoped strictly to your tenant, so no other client's data influences your figures
This is the area where terminology causes the most confusion. "Validation-ready" and "qualified in this environment" are different states, and a vendor supplying documentation is not the same as qualification having been executed for your instance.
The distinction to hold onto
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.
- Ask which documentation set the software vendor supplies — VMP, URS, FS, DS, IQ/OQ/PQ, RTM, SOP templates — and who executed the qualification for the instance your data sits in
- Ask to see the qualification summary and the traceability matrix for that instance, subject to whatever the provider may share
- Establish the change-control and release process: what is re-tested when the platform updates, and how you are notified
- Confirm there is a segregated training environment and that training records exist for the personnel processing your cases, dated against your SOP versions
- Ask who bears the cost and effort of re-qualification after a major platform change
Transition is the least-negotiated and most consequential part of an outsourcing agreement. When a relationship ends — by choice, acquisition, or failure — you need your complete safety data in a usable form, quickly, without depending on the goodwill of a party you may be leaving unhappily.
| Provision | What to specify |
|---|---|
| Export format | E2B XML as the vendor-neutral standard, plus source documents, attachments, and audit history — name the formats explicitly |
| Completeness | That the export includes all case versions and follow-up, not only the current state of each case |
| Timeline | A defined number of days from notice, not "reasonable endeavours" |
| Cost | Fixed or capped at signature, when you have negotiating leverage |
| Retention and deletion | How long they retain your data after termination, and certified deletion thereafter |
| Assistance | What migration support and reconciliation help is included in the exit, and at what rate |
| Continuity | Access to your data during transition, so PV operations do not gap |
Send this to any provider you are assessing, and ask for written answers. Vagueness on any of these is itself informative.
| Question | What good looks like |
|---|---|
| Is our data logically or physically isolated, and what documentation supports it? | A precise architectural answer plus documentation you are permitted to share with an inspector |
| Can we have read-only access to our tenant? | Yes, scoped to your tenant, covering live cases, queues, and metrics |
| Can you export the full history of one case, live, right now? | Done in the demo, in minutes, including all versions and submissions |
| Who approves the reporting rule configuration for our products? | You do, in writing, under change control |
| How is on-time submission rate calculated? | Computed by the system from submission records, scoped to your tenant, with a written definition |
| Which authorities and formats are supported, and is AS2 included? | E2B(R2)/E2B(R3), CIOMS I, MedWatch 3500A, with the gateway included rather than a separate licence |
| Who executed qualification for the instance holding our data? | A named party with a qualification summary and traceability matrix available |
| What is re-tested when the platform is updated, and how are we told? | A documented change-control and release process with notification obligations |
| Are staff processing our cases trained against our SOP versions? | Dated training records, with a segregated training environment |
| How is reference safety information versioned and effective-dated? | Version control with effective dates, so listedness calls trace to the correct datasheet |
| Where is our data hosted, and can we specify the region? | A named region, with the option to specify it where your contracts require |
| What are your RPO and RTO, and the availability target? | Specific figures, stated in the agreement |
| How do AI-assisted steps appear in the audit trail? | Proposal, confidence, reviewer change, and approver all recorded — with no autonomous regulated determinations |
| What are the exit format, timeline, and cost? | Named formats, a defined number of days, and a fixed or capped cost agreed at signature |
The short version
You remain accountable for pharmacovigilance you outsource, and your provider's platform is the evidence base you will rely on at inspection. Assess four things properly: how your data is isolated, how deep and exportable the audit trail is, who approves the reportability configuration, and what happens at exit. Everything else is negotiable — those four decide whether you can demonstrate oversight.
If you are the CRO on the other side of this assessment, the CRO pharmacovigilance workflow guide covers the same ground from your perspective, and pharmacovigilance software for CROs sets out how PVgenix supports a multi-sponsor operation. If you are a sponsor concluding that your provider's technology is the constraint, the platform overview is the place to start.
Frequently asked questions
Common questions
Yes. The marketing authorisation holder retains regulatory responsibility for pharmacovigilance regardless of who performs the activities, and the QPPV remains accountable. A service provider performs delegated work; it does not absorb your obligations. The practical consequence is that you must be able to demonstrate oversight of activities performed in a system you do not own, which depends heavily on what that system can produce as evidence.
Four areas matter most: how your data is isolated from the provider's other clients and what documentation supports it; the depth, immutability, and exportability of the audit trail; who configures and who approves the reporting rules that encode your regulatory obligations; and the exit provisions covering export format, completeness, timeline, and cost. Beyond those, check oversight access, how contracted KPIs are calculated, qualification status for your instance, change control, training records, hosting region, and continuity commitments.
It is a reasonable request and a useful signal when granted readily. Read-only access scoped to your tenant lets you verify rather than rely on a monthly report compiled by the party you are overseeing, and lets you see backlog and case ageing while they still can be acted on. Where a provider cannot offer it, establish whether that is a platform limitation or a policy position, and account for the extra oversight effort in your plan.
Validation-ready means the software is designed and documented to support qualification, typically shipping with a complete IQ/OQ/PQ documentation package. Qualification is a state reached only after that documentation is executed against a specific environment, its configuration, and the relevant SOPs. When assessing a provider, establish which documentation the software vendor supplied and, separately, who executed qualification for the instance holding your data.
You should. Reporting rules encode regulatory interpretation — which authority receives which case, in which format, within which timeline — and that interpretation is the marketing authorisation holder's responsibility. Ask for the configured rule set in writing, approve it formally, and require your documented approval for changes. Without that, an interpretation of your obligations is being maintained on your behalf with no approval record.
Named export formats (E2B XML plus source documents, attachments, and audit history), a requirement that the export covers all case versions rather than current state only, a defined timeline in days from notice, a fixed or capped cost agreed at signature, retention and certified-deletion terms, the migration assistance included, and continued access during transition so PV operations do not gap. Negotiate these before signing, while you still have leverage.