Study startup & go-live
Someone has to read the vendor documentation closely.
An independent editorial resource on RTSM, IRT, and clinical technology for study teams planning a realistic go-live: what actually delays a deployment, which qualification steps run on their own clock, and how change control is decided before it is needed.
Released
Supply depot
Kit cartons staged by shelf bay, with the shipped position empty while the next shipment is packed.
Study team
Configuration decisions, protocol questions, and the UAT script all pass across one desk.
Freight & release
Pallets wait on the apron until the release decision is written down, not assumed.
Section one
Study startup is often treated as one phase on a Gantt chart, which hides the fact that it is a sequence of steps that depend on each other. Protocol finalization feeds RTSM configuration. Configuration feeds user acceptance testing. UAT feeds the go-live decision. Vendor qualification runs across all of it and can hold any of them. When one step slips, the ones behind it slip by default unless someone actively compresses the sequence. That is why RTSM timelines slip by weeks when a single configuration question goes unanswered for days.
Protocol finalization
Randomization scheme, strata, and supply thresholds are frozen before configuration starts.
RTSM configuration
Build, review, and documentation of the configured system against the protocol.
User acceptance testing
Scripted scenarios run against your protocol, not the vendor's template.
Vendor qualification
Documentation review, quality agreement, and validation evidence — run in parallel.
Go-live decision
A real date backed by signed UAT and closed qualification, not a steering-committee target.
Section two
User acceptance testing on an RTSM is not a checkbox. It is a scripted set of scenarios that covers randomization, resupply, unblinding, and the site-facing interface, and it should be run by the people who will use the system rather than by the study team on their behalf.
The scenarios need to reflect your protocol's specific scheme, including edge cases like a randomization that triggers a resupply within the first enrolment block. Teams that scope UAT from the vendor's template tend to find the gaps after go-live. Teams that scope it from their own protocol find them in the test environment, which is cheaper.
Write the scenario list once from the protocol, then review it against the RTSM's own configuration documentation before you execute. The second pass catches the scenarios that exist in your protocol but are not covered by anything in the test template, which is usually where the interesting problems live.
Vendor qualification is the part of startup that most often runs in parallel and gets forgotten until it becomes critical. It includes the documentation review, the quality agreement, and whatever validation evidence your organization requires before the system touches live subjects.
The clock on this is not under your control in the way the RTSM build is, because it depends on the vendor producing documentation and your quality team reviewing it. Start it earlier than feels necessary. The two most common causes of a stalled go-live are a missing vendor document and a quality review slot that has to wait for the next cycle.
ParallelChange control decisions look obvious in hindsight and are painful in the middle of a live study. The startup phase is where you decide how amendments will be handled. Does the study team stage changes and request a review, or does every amendment go through the vendor's change process?
Is there a threshold above which a change requires a formal qualification review, or does the existing validation cover it? Decide before go-live and write it down, because mid-study decisions about change control tend to become negotiations with the vendor, and negotiations take longer than any technical work.
Decide earlySuperseded terminology
Clinical technology vendors rename the same category every few years. When a protocol or a quality document still uses an older term, the comparison work is the same — only the searches get harder. Use the row below to read a legacy label against the term used in current vendor documentation.
The release condition
Good startup is not fast startup. It is startup where the critical path is visible, the parallel work stays parallel, and nothing is waiting on an unanswered question. The study team knows which configuration scenarios matter, has written its own UAT script from the protocol, and has submitted vendor qualification paperwork before the build started. The go-live date is a real date, not an aspiration someone is defending in a steering committee. That is a modest standard, and it is the one most RTSM delays fail against.
Beyond one country
The week of go-live is not a launch event. It is the week when the system first encounters real subjects, real sites, and real data. Plan for a small buffer between the UAT sign-off and the first subject enrolment, because sites need training time on the site-facing interface, and that training rarely happens on the schedule anyone intended.
Have a named person on the study team who can answer configuration questions during that first week, and have the vendor's support contact documented in the protocol binder rather than in someone's inbox.
Review multinational considerationsFreight apron at dusk
When it slips
When it does slip, work backwards from the go-live date and find the next real constraint. It is almost never the RTSM build itself. It is usually the qualification review slot, the UAT execution window, or a protocol question that nobody has escalated. Escalate the constraint, not the symptom.
And if the constraint is outside your control, decide early whether to shift the go-live date or accept a partial launch with the first subjects enrolled under a paper backup. Both are legitimate. Deciding late is what turns a slip into a delay.
There is no universal number, and vendors who quote one without knowing your protocol should be treated carefully. The realistic range depends on your study's randomization scheme, integration points, UAT scope, and vendor qualification requirements. Ask each vendor for a recent example of a study at your complexity and for a breakdown that includes the build queue, not just the configuration work.
Both, and in that order. The study team writes and executes the protocol-level scenarios first, then site staff run the site-facing interface scenarios before go-live. Teams that skip the site-facing UAT tend to find their interface problems during the first subject visit, when the fix cost is much higher.
Yes, and it should be. The documentation review, the quality agreement, and the validation evidence are largely independent of the specific configuration work. Starting them in parallel removes them from the critical path, and in most delayed go-lives we see discussed publicly, the qualification step is where the delay actually landed.
It depends on whether it touches randomization or supply rules. An amendment that changes strata or kit allocation thresholds may require a configuration change and a UAT re-run for the affected scenarios. An amendment that touches dosing or visit windows usually does not. Decide early which amendments go through the RTSM change process and write the rule down before the first one arrives.
Keep going: the guide explains every term used here, the platform comparison sets the same criteria against named vendors, and the vendor profiles show how each one handles qualification and change control.
Editorial note
Suvodav Agent is an independent editorial resource. We are not a vendor and we do not sell RTSM software, which is why this page can say plainly that most go-live delays are not a build problem. If a study team wants to compare platforms on delivery criteria or ask a specific question about startup sequencing, the contact page and the comparison set are the places to continue.
Released