The depot bench
Where kit stock actually lives
Blinded cartons, shelf bays, and the empty position left behind by a shipment — the physical record the RTSM mirrors.
RTSM, IRT, IWRS: one system, four labels
Someone has to read the vendor documentation closely.
RTSM and IRT are the same technology under two vintages of naming. This guide works through the terminology, then what the systems actually do across randomization and trial supply, and finishes with a way to read vendor claims critically — without a demo in front of you.
The physical chain behind every screen
Every decision the software makes lands somewhere on a bench. These are the three places a study-startup lead actually sees kit and subject data meet — the depot where supplies are stored, the coordinator's desk where assignments are entered, and the freight apron where shipments leave.
The coordinator wall
Where randomization gets entered
Every stratified allocation, every subject entry — the interface a site coordinator touches many times a week.
The freight apron
Where depot resupply ships out
Between RTSM trigger and cold-chain delivery, every resupply passes through this floor.
The four functional halves
Where vendor claims sit against what the system actually does.
Reading an RTSM platform is easier when you separate it into four working halves. Randomization and supply are the two operational halves; the terminology and integration story sit on top of them and decide how much of the work lives inside the platform.
01
Randomization engine
Static, dynamic, stratified schemes — and whether study teams can configure them without a vendor build ticket.
02
Trial supply management
Kit allocation rules, resupply triggers, depot visibility, and emergency unblinding behavior.
03
Terminology mapping
Which current product labels describe a full RTSM scope and which still quote a narrower IRT spec.
04
Integration architecture
How the platform connects to EDC, eCOA and reconciliation reporting — native module versus middleware layer.
Terminology, in plain language
RTSM, IRT, IWRS, IVRS: one system, four labels.
The acronym shift happened because the scope of the systems expanded. RTSM stands for randomization and trial supply management, and it describes precisely what the software does. IRT, short for interactive response technology, was coined when site staff interacted with the system over the phone or a web portal to receive an assignment, and it covered the breadth of the interaction rather than the function. IWRS and IVRS split that interaction into web and voice modes, and vendors still use both.
Legacy term → current label
IVRS
Interactive voice response system
The phone-only era; assignments delivered by touch-tone.
IWRS
Interactive web response system
Assignments through a browser portal.
IRT
Interactive response technology
Breadth of interaction; not yet a function.
RTSM
Randomization and trial supply management
The current label; names both functions performed.
The practical consequence for buyers is that RFP language may still specify an IWRS when what the study needs is a modern RTSM with kit management and resupply algorithms. Ask the vendor to map their product's functionality to the acronym, not the other way around.
The two operational halves
Randomization decides the arm. Supply management decides the kit.
Half one — randomization
The randomization half
Randomization in RTSM means assigning an enrolled subject to a treatment arm according to the scheme the protocol defines. Static randomization fixes the allocation ratio up front and does not adjust as enrolment progresses. Dynamic randomization, sometimes called adaptive or stratified allocation, adjusts the probability based on the current balance of subjects across arms and strata.
Which one you need comes from the statistical section of the protocol, not from the vendor. What matters at evaluation time is whether the system supports the scheme without custom code, whether stratification factors can be added or changed mid-study, and how the system handles randomization for cohorts that open later.
Ask on the call
- Can the study team configure a stratified, dynamically adjusted randomization without a vendor build ticket?
- How does the system handle randomization for a cohort or extension study that opens after the main study has enrolled?
- What happens to the randomization log if a protocol amendment changes a stratification factor mid-study?
The answers reveal how much of the work sits in the platform and how much sits in the vendor's professional services queue. Neither answer is disqualifying, but the queue is where study timelines go to wait.
Half two — supply
The supply half
Trial supply management is where most evaluation mistakes happen. The system has to decide which kit number goes to which subject, track what is at each site and depot, and trigger resupply before stock runs out. That last part depends on enrolment forecasts that rarely hold, so the resupply algorithm needs thresholds and triggers the study team can tune without raising a change order every month.
Kit allocation rules matter too: whether kits are pooled across sites, reserved per site, or allocated by a block or cohort scheme. Emergency unblinding sits inside this half as well, because a kit that gets unblinded is no longer available for allocation. These rules are the difference between an RTSM that saves coordinator time and one that creates a monthly reconciliation project.
The operational risk
The most common operational complaint about RTSM is not randomization failure. It is a site running out of kits because nobody saw the depletion curve in time. Ask whether the site-facing interface shows remaining stock with enough lead time to act — and whether the site can request an emergency kit outside normal allocation.
The release condition
How the term RTSM became the default.
Vendors moved to RTSM for a mundane reason: it describes what the software does and it sells more cleanly into procurement conversations than an acronym that predates web portals. The shift is mostly complete in current product naming, though you will still find IRT and IWRS in contracts, regulatory submissions that predate the change, and job postings written before someone updated the template.
For the buyer, this matters in one concrete way. A vendor who quotes you an IRT product may still be selling a phone-first system built before modern kit management. A vendor who says RTSM is making a scope claim about supply functionality. Read the module list, not the label.
Reading vendor claims critically
Separate the functionality claim from the outcome claim.
Two habits help here. First, separate claims that describe functionality from claims that describe outcomes. A vendor saying their RTSM supports dynamic randomization is a functionality claim you can verify against the documentation. A vendor saying their system reduces study costs is an outcome claim that depends on your study, your team, and your existing systems.
Second, check the integration architecture. If the RTSM connects to your EDC through a middleware layer, ask who maintains it and what happens to reconciliation reports when either system updates. Viedoc RTSM is built natively into the Viedoc eClinical suite, which removes one class of integration work, though not every downstream reconciliation. Veeva RTSM connects with Veeva EDC and Veeva eCOA, which carries a similar argument inside the Veeva stack. Both are legitimate; both are also ecosystem arguments, so weigh them against what you already run.
01
Viedoc RTSM
Built natively into the Viedoc eClinical suite.
What this changes for the buyer
- Integration class Removes one category of middleware work
- Reconciliation limits Downstream reporting still needs review
- Ecosystem argument Weigh against the tools you already run
02
Veeva RTSM
Connects with Veeva EDC and Veeva eCOA inside the same stack.
What this changes for the buyer
- Integration class Native to the Veeva eClinical stack
- Reconciliation limits Depends on what sits outside the stack
- Ecosystem argument Strongest where Veeva is already the spine
Across boundaries
When legacy terminology matters
A vendor's choice of label can be a signal about product vintage. IRT and IWRS naming often, though not always, correlates with systems that were built as response technologies and had supply management bolted on later. That shows up in the site-facing UI and in how much configuration sits behind a vendor ticket.
This is not a reason to reject a platform outright. A system with twenty years of validated deployments and predictable change control may beat a newer RTSM with a smaller track record. What you want is to know which one you are buying before the contract, not after the first amendment.
A practical evaluation sequence
Work order for a study-startup lead.
01
Define the protocol's randomization scheme
Static or dynamic, stratification factors, and how you expect the scheme to change.
02
Write down the supply rules
Kit allocation, resupply triggers, emergency unblinding flow.
03
List the integration points
The ones you actually need — not the ones the vendor suggests.
04
Run the same scenarios past each vendor
Same data across vendors so the answers compare.
05
Score on build effort, amendments, integration, support
Nothing on that list requires a demo. The demo confirms what the documentation already told you.
Common questions
Questions buyers ask before the RFP.
Is RTSM the same as IRT?
They describe the same class of system with different levels of scope implied. IRT stands for interactive response technology and originally covered the phone or web interaction sites used to receive assignments. RTSM stands for randomization and trial supply management and describes both functions the system performs. Most current vendor products use RTSM in their naming, but the older terms remain in contracts and some product lines.
Can we run randomization without supply management in the same system?
You can, but it is rarely worth it. The kit allocation depends on the randomization result, so splitting them creates a handoff where resupply decisions wait on the other system. Some studies with simple supply schemes and low enrolment volume manage this. Most do not, and the reconciliation work tends to arrive in the middle of the study rather than at the start.
How much configuration should we expect to handle ourselves?
That varies more than the feature lists suggest, and it is worth testing directly. Ask each vendor to walk through a specific scenario from your protocol, then note whether the configuration happens in a study-team-accessible interface or behind a vendor change request. Vendors that give study teams control tend to be faster on amendments and slower on launch support. Vendors that keep configuration in-house trade one for the other.
Do dynamic randomization schemes cause more build work than static ones?
They can, though not always. A standard dynamic scheme with stratification factors your vendor has implemented before is usually a configuration task. A scheme with unusual strata, mid-study stratification changes, or cohorts that open late is more likely to land in a build queue. Ask specifically how stratification factors are added or changed after randomization has begun.
Read the documentation closely
The right questions come before the demo.
If your team is weighing an RTSM decision, the fastest way through is a written comparison — not another demo. The vendor profiles and platform comparison sit on the same criteria this guide uses: build effort, amendment turnaround, integration architecture, and support arrangement for your study type.