This is an illustrative scenario, not a client case study
We do not publish client outcome figures we cannot evidence. Every timeline number below comes from our documented provisioning capability (see the source note at the end), applied to a modelled CRO profile — it is not a record of a specific engagement, and it is not a promise about yours. Where a figure would depend on your own work rather than ours, the guide says so instead of estimating it.
The question a CRO actually asks in an evaluation is rarely "can the platform process a case". It is "what happens when I win the fourth sponsor contract this year, and how much of that is a project?" This walkthrough models that concretely.
| Parameter | Modelled value |
|---|---|
| Organisation | Mid-size CRO with a growing PV service line |
| Sponsors in scope | Five in the first year |
| Sponsor mix | Four post-marketing portfolios across differing markets; one sponsor with an interventional study |
| Existing safety system | None dedicated — cases tracked in spreadsheets and shared mailboxes |
| Internal IT function | None dedicated to PV infrastructure |
| QA / CSV capacity | One part-time QA resource |
| Commercial pressure | Sponsor contracts won with short mobilisation windows |
- Each new sponsor must not require a fresh environment, a vendor engagement, or a multi-week configuration cycle — otherwise the platform caps the growth of the service line
- Every sponsor will ask, during due diligence, how their data is separated from the other four — and will want something more than an assurance
- Each sponsor has different reporting rules, different reference safety information, and different SOPs to align to
- One sponsor's contract requires data to remain in a specified region
- On-time submission rate must be reportable per sponsor, monthly, without a person compiling it
- The part-time QA resource is the real bottleneck, not the software
These are our documented IT provisioning and documentation-handover figures. Read the scope caveat immediately after the table before using any of it for planning.
| Step | Instance setup | Setup documentation |
|---|---|---|
| One-time SaaS platform build | ~3 days (by our IT team) | ~3 days (by our IT team) |
| Sponsor tenant 1 | Self-provisioned from the portal — no IT-team involvement | ~1 day |
| Sponsor tenant 2 | Self-provisioned | ~1 day |
| Sponsor tenant 3 | Self-provisioned | ~1 day |
| Sponsor tenant 4 | Self-provisioned | ~1 day |
| Sponsor tenant 5 (dedicated, region-specific) | ~3 days (dedicated single-tenant, by our IT team) | ~4 days |
The point of the table is the shape, not the numbers
The one-time platform build is the only step that scales with our involvement. After it, four of the five sponsors are provisioned by your own team from the portal. The fifth is slower only because that sponsor's contract requires a dedicated single-tenant environment in a named region — and it runs the same codebase, so it does not fork your procedures.
What these figures explicitly do NOT cover
IT provisioning and setup-documentation handover only. They are not a computer system validation timeline. They exclude your qualification execution, SOP authoring, UAT, user training, data migration, sponsor-specific configuration sign-off, and PV operational go-live — all of which are client-led and take additional time. In the profile above, the part-time QA resource is the constraint on go-live, not our provisioning. Plan sponsor go-live dates against your own critical path.
This is the work that recurs with each new client, and the reason per-tenant configuration control matters more than raw provisioning speed. All of it is administered by your team, without a code change or a vendor ticket.
Reporting rules
Which authority receives which case, in which format, within which timeline — per market, and per protocol for study cases. Derived from that sponsor's safety data exchange agreement.
Reference safety information
That sponsor's CCDS/CCSI, SmPC and USPI under version control with effective dates, so listedness calls trace to the correct datasheet.
Workflow and review gates
Workflow states, review depth and sign-off roles aligned to that sponsor's SOPs — which may be stricter than your internal default.
Intake channels
A dedicated intake mailbox, reporter portal, form fields and validation rules per sponsor, so the tenant is determined by the channel rather than chosen afterwards.
Code lists and dictionary versions
Product names, study identifiers and picklists, plus the MedDRA and WHO-DD versions that sponsor is coded against. Dictionary licences are procured by the client.
Notifications and escalation
Distribution lists, escalation paths and alerts ahead of SDEA exchange deadlines as well as regulatory ones.
Access and roles
Tenant-scoped roles under least privilege, supporting segregation of duties so entry and approval cannot share a user.
Metrics definition
The KPI set that sponsor's contract specifies, including how on-time submission rate is calculated.
The following are capability statements about the platform, not measured outcomes. They describe what becomes structurally possible rather than what improvement any particular team will see.
| Area | What the platform provides |
|---|---|
| Sponsor segregation | Logical tenant isolation with tenant-scoped RBAC, encryption in transit and at rest, and tamper-evident audit logging — plus physical isolation for the dedicated tenant |
| Compliance reporting | On-time submission metrics computed from the submission records themselves, scoped per sponsor and per authority |
| Deadline management | Automatic Day 0 determination per reporter region, per-obligation due dates, and alerts before breach rather than reports after it |
| Cross-sponsor oversight | Operational dashboards for your own management roles, governed by role and never exposed inside a client tenant |
| Adding sponsor six | A portal provisioning task plus that sponsor's configuration and your own qualification and SOP work — not a new deployment |
| Audit response | Case-level history, submission evidence and derived metrics exportable per tenant on demand |
Where responsibility sits in this scenario
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.
- How much faster your case processing will be. We have no measured client benchmark to publish, and any figure would depend on your case mix, source document quality and current process maturity. Our guide on AI versus manual ICSR processing gives you a method for measuring it on your own historical cases instead.
- What it costs. Pricing is quoted per engagement, and dictionary licences, your qualification effort and your training are separate.
- How long your qualification will take. That depends on your QA capacity, your SOP maturity and your sponsors' expectations.
- Whether every sponsor's specific regulatory route is covered. Documented submission support is FDA, EMA and MHRA; other destinations are assessed per engagement, so ask directly about the ones that matter to you.
- Ask us to provision a tenant live in the demo, so the "self-provisioned" claim is demonstrated rather than described.
- Ask to see per-tenant configuration changed without a vendor ticket — a reporting rule, a workflow gate, a code list.
- Ask to see the on-time submission metric being derived from submission records, scoped to one tenant.
- Ask what documentation you may share with a sponsor's auditor, and get it in writing.
- Ask which of your sponsors' submission destinations are documented versus scoped per engagement.
- Then put the same questions to every other platform on your shortlist — our CRO buyer's guide has the full vendor-neutral questionnaire.
Source note
All provisioning and documentation timelines in this scenario are the documented figures from our platform capability documentation: a one-time SaaS platform build of approximately three days plus three days of setup documentation; each subsequent tenant self-provisioned from the portal with approximately one day of documentation; and a dedicated single-tenant environment at approximately three days setup plus four days of documentation. These cover IT provisioning and documentation handover only. The sponsor profile, sponsor count and mix are modelled illustrations, not a client record.
Related: pharmacovigilance software for CROs for the commercial view, multi-client pharmacovigilance system for how isolation is implemented, and CRO pharmacovigilance workflow for the operating model including SDEA obligations.
Frequently asked questions
Common questions
No, and it is labelled as a scenario for that reason. The provisioning and documentation timelines are our documented capability figures, but the sponsor profile, sponsor count and mix are a modelled illustration. We do not publish client outcome figures without a real, measured and permissioned engagement behind them, because a buyer in this industry will reasonably ask which client, over what period, and measured how.
Two timelines have to be added together, and only one of them is ours. Our part — the one-time SaaS platform build — is approximately three days of IT provisioning plus three days of setup documentation handover. Your part includes sponsor-specific configuration, qualification execution, SOP authoring, UAT, training and any data migration, and is typically the longer of the two, particularly where QA capacity is limited. Plan the go-live date against your critical path rather than ours.
After the one-time platform build, each additional tenant is self-provisioned from the portal with no involvement from our IT team and approximately one day of documentation handover. On top of that sits the sponsor-specific configuration work your team performs — reporting rules, reference safety information, workflow and review gates, intake channels, code lists and dictionary versions, notifications, access roles and the contracted KPI definitions — plus whatever qualification and training your procedures require.
Yes. Where a sponsor contract requires physical isolation or a specific hosting region, that client can run as a dedicated single-tenant deployment with an isolated application and database, at approximately three days setup plus four days of documentation. Because it runs the same codebase as the shared multi-tenant service, behaviour and feature parity are identical, so it does not fork your SOPs or training.
Because we have no measured client benchmark to publish, and an invented one would not survive scrutiny. Processing improvement depends on case mix, source document quality and current process maturity; cost depends on deployment model, tenant count, volume and agreed scope, with dictionary licences and your qualification effort separate. Our AI-versus-manual guide gives a method for measuring the processing side on your own historical cases, which is the only version of the number worth putting in a business case.