Read this framing first
This scenario is illustrative, not a client case study, and it deliberately contains no case-processing speed figures. The only time numbers we can evidence are our documented provisioning and documentation-handover timelines. Everything else in the critical path belongs to you, and estimating it on your behalf would be misleading — so instead the scenario shows you how to build that estimate yourself.
"How quickly can we be live?" is the most commonly asked and most commonly mis-answered question in a safety system evaluation. Vendors answer with provisioning time, because that is the part they control. Buyers hear it as time to go-live. The gap between those two numbers is where implementation projects overrun.
| Vendor timeline | Your timeline | |
|---|---|---|
| What it covers | Environment provisioning, platform configuration handover, setup documentation | Qualification execution, SOPs, configuration decisions, UAT, training, migration, sponsor or partner sign-off |
| Who performs it | The vendor's IT team, or self-service where the platform supports it | You, or your contracted QA / CSV resource |
| Typical order of magnitude | Days, for a modern hosted platform | Weeks to months, depending on your QA capacity and SOP maturity |
| What compresses it | A managed hosted model and self-service provisioning | A supplied documentation set, existing SOPs, and available QA capacity |
| Who is accountable if it slips | The vendor | You — including to a sponsor whose go-live date you committed to |
The single most useful question to ask any vendor
"Which of these activities do you perform, and which do we?" Then ask for it in writing. Most implementation overruns are not a vendor failing to deliver their part — they are a buyer having assumed the vendor's number was the whole number.
These are our documented figures. Note that they cover IT provisioning and setup-documentation handover only.
| Deployment | Instance setup | Setup documentation |
|---|---|---|
| SaaS — one-time initial platform build | ~3 days (by our IT team) | ~3 days (by our IT team) |
| SaaS — each new tenant thereafter | Self-provisioned from the portal, no IT-team involvement | ~1 day |
| Dedicated single-tenant | ~3 days (by our IT team) | ~4 days (by our IT team) |
The scope boundary on those numbers
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.
This is the part no vendor can compress for you, and the part worth planning properly. The activities below are the recurring long poles.
Regulatory interpretation
Deciding which authority receives which case, in which format, within which timeline, for each product and market. This is your obligation matrix, and it has to be approved before rules can be configured.
Qualification execution
Running the IQ/OQ/PQ against your configured environment and documenting it. Usually the longest single item, and constrained by QA capacity rather than by software.
SOP authoring or update
Procedures have to match the configured workflow, not the other way round. If your SOPs are new, this is substantial work.
Dictionary procurement
MedDRA and WHO Drug Dictionary licences are client-procured. Starting this late is a surprisingly common cause of delay.
Test submissions with authorities
Authority test environments have their own lead times and findings to resolve. Sequence this rather than treating it as a single task.
UAT and training
Users have to be trained against the current SOP version, with dated records — an inspection expectation as well as an operational one.
Data migration
If you hold existing cases, E2B transfer plus field mapping and reconciliation. Scope this early; it is rarely as clean as expected.
Sponsor or partner sign-off
For CROs, the sponsor may need to review configuration and reporting rules before go-live. Build the review cycle into the plan.
The two items most often started too late
Dictionary licence procurement and authority test-environment access. Neither is technically difficult and both have external lead times you do not control. Start them on day one, in parallel with everything else, rather than when you reach them in the plan.
- **Take the vendor's provisioning figure at face value but label it correctly** — it is the start of your path, not the length of it.
- **List your eight activities** from the section above and assign each an owner and a duration based on your own capacity, not on a benchmark.
- **Identify what runs in parallel.** Dictionary procurement, authority test access and SOP drafting can all start before provisioning completes.
- **Find your real constraint.** For most small teams it is QA capacity for qualification; for CROs it is often sponsor review cycles.
- **Add contingency to the external dependencies** — authority test environments and dictionary licensing are outside your control.
- **Commit the go-live date from that model**, not from the vendor's provisioning number. If you are committing a date to a sponsor, this is the difference between a plan and a hope.
Setup time is a one-off. The time question that matters for the next five years is whether deadlines are managed structurally or by people remembering — and that is where the durable difference sits. These are capability statements, not measured improvements.
| Mechanism | What it changes |
|---|---|
| Automatic Day 0 determination per reporter region | Removes the most common cause of late submission, and makes the basis auditable rather than asserted |
| Per-obligation deadlines | One case can create several obligations on different clocks to different authorities; each is tracked separately rather than as one date |
| Escalation on time remaining | Alerts before a deadline is breached rather than a report of what is already late |
| Re-derivation on new case versions | A follow-up with significant new information recalculates obligations instead of inheriting the original ones |
| Pre-transmission validation | Schema and business-rule checks in-house, so avoidable authority rejections do not consume clock |
| Acknowledgement reconciliation | An unacknowledged transmission is detected rather than assumed complete — the failure mode that silently costs the most time |
| Derived on-time submission metrics | The compliance number is computed from submission records rather than compiled monthly by a senior person |
Reframing the question
"How fast can we go live?" is a project question you should answer with your own model. "Will we still be submitting on time in three years, at three times the volume, without adding headcount?" is the operational question — and it is answered by whether the clock is a property of the case or an entry in someone's calendar.
- How many days or weeks your go-live will take. That depends on your QA capacity, SOP maturity, migration scope and external lead times, and a vendor estimating it for you is guessing.
- How much faster your case processing will be. We publish no measured benchmark; AI versus manual ICSR processing gives you a method for measuring it on your own historical cases.
- Whether every authority you report to is a documented submission route. FDA, EMA and MHRA are documented; others are assessed per engagement.
Source note
Provisioning figures are the documented timelines 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 — all covering IT provisioning and documentation handover only. The activity list on the client side and the ordering guidance are general implementation practice, not a client record, and no case-processing speed figure appears anywhere in this scenario.
Related: deployment and onboarding for both deployment models in full, E2B(R3) implementation for the submission-readiness workstream, and expedited reporting timelines for the clocks you will be running against once live.
Frequently asked questions
Common questions
Two timelines add together. The vendor's part — environment provisioning and setup documentation handover — is days for a modern hosted platform; ours is approximately three days plus three days of documentation for a one-time SaaS platform build. Your part — regulatory interpretation and the obligation matrix, qualification execution, SOP authoring, dictionary procurement, authority test submissions, UAT, training, data migration and any sponsor sign-off — is typically weeks to months and depends on your QA capacity. Commit the go-live date from your own model, not from the vendor's provisioning figure.
For most teams, qualification execution — running the IQ/OQ/PQ against the configured environment and documenting it — because it is constrained by QA or CSV capacity rather than by software. For CROs, sponsor review and sign-off cycles frequently rival it. Neither is compressed by choosing a faster-to-provision platform, although a supplied documentation set changes the size of the qualification effort.
MedDRA and WHO Drug Dictionary licence procurement, and authority test environment access. Neither is technically difficult, both have external lead times you do not control, and both are commonly started when the plan reaches them rather than in parallel from the outset — which is why they show up so often as the reason a go-live date slipped. SOP drafting can also start before provisioning completes.
Setup time is a one-off, and for most organisations it is not the largest number in the project. The durable time gain is structural: automatic Day 0 determination, per-obligation deadline tracking, escalation on time remaining rather than time elapsed, re-derivation of obligations on new case versions, pre-transmission validation so avoidable rejections do not consume clock, and acknowledgement reconciliation so an unacknowledged submission is detected. Those affect every case for years, not one project once.
Because we have no measured, permissioned client benchmark to publish, and a generic figure would depend entirely on case mix, source document quality and current process maturity. Our AI-versus-manual guide instead sets out an eight-step method for measuring it on your own historical cases, segmented by source document type — which produces the only version of the number that will survive an internal business review.