Study Complexity
Which platform class your study really needs
Two trials of the same size can need completely different technology. Complexity, not headcount, decides whether a focused RTSM provider is enough or whether the study requires a full eClinical suite.
The standfirst
Complexity decides the platform class
A focused RTSM provider and a full eClinical suite are not better or worse at what they do — they are sized for different studies. This page walks the factors that push a design from one class to the other, so teams can name the class before the vendor shortlist.
The six factors below are the ones that move a platform requirement the most: how the allocation behaves, how many countries and depots the supply chain touches, whether participants do anything on a screen, and how many systems the trial reconciles every week. Read them as a set — a study that answers simple on five and hard on one is a different study than one that answers hard on three.
A controlled supply room at the start of the workday. Kits sealed, log open, nothing dispatched yet.
The six factors read in order
Complexity as a budget line
Each factor below reads on its own — a design that adapts, a supply chain that crosses borders, a participant who touches a screen, a stack of systems that reconcile weekly, and the two honest shapes a study lands in. Skim the six and name the ones that fit your protocol before you price anything.
Factor one
Randomization design is the first fork
Simple static randomization with a fixed allocation ratio is the easy case. Anything beyond it raises the platform requirement. Dynamic randomization, response-adaptive designs, and stratification across site, country, and baseline factors all demand more from the randomization engine. If the design may change after first patient in, the platform has to accept that change without invalidating what already ran.
A study that will never adjust its allocation sits comfortably with a focused RTSM provider. One that plans to adapt belongs on a platform with a proven amendment path — where the change lands as a documented protocol version rather than a rebuild.
Fixed ratio, no mid-study change, no response-adaptive branch. A focused RTSM provider with a stable randomization engine covers this cleanly, and the study ships with one interface to build against.
Response-adaptive allocation, dynamic ratio changes, or stratification that spans site, country and baseline factors. The engine has to record every change without reopening the patients already randomized, and the vendor should be able to point at a study where an amendment ran live.
Each region brings its own depot arrangement, import requirements, and labelling formats. Resupply triggers that work in one country may over-ship in another, and the shipment rules live in very different places from state to state.
Excursion handling stops being a footnote and becomes a working process. Local reporting rules and support coverage that follows the study's actual hours decide whether the platform is still the right answer in month eighteen, when the first region is asking questions on a Sunday.
Factor two
Global sites change the supply problem
A US-only study with a single depot has a manageable supply chain. Add countries and the problem changes shape. A trial that planned for one region now reconciles shipments, returns, and expiries against a set of local calendars that do not agree with each other.
For sponsors running global clinical trials, the questions to settle early are the local supply routes and whether support hours follow the study, not the sponsor's home office. Those two answers tend to decide which platform a team is still comfortable with a year and a half in.
Factor three
Participant workflows raise the bar
The moment a study asks participants to do something on a screen, the platform requirement widens. eConsent, ePRO questionnaires, and visit reminders all touch the participant directly, which means language coverage, accessibility, and device support stop being optional.
Medidata's myMedidata is the clearest current example of a participant-facing layer sitting alongside EDC and RTSM. IQVIA covers participant engagement as part of a broader suite. If your study has a participant-facing component, a platform without one pushes that work to a separate vendor and a separate integration, with its own contracting and its own reconciliation rules.
eConsent, ePRO questionnaires, and visit reminders touch the participant rather than the site. That moves language coverage, accessibility behaviour, and device support from a nice-to-have into the operating requirements the study is judged against.
A suite with a participant-facing product keeps the workflow in one data model. A platform without one works too — but pushes the participant side to a separate vendor, a separate contract and a separate handoff for every consent event and every diary entry.
One interface to worry about, usually with EDC. Reconciliation effort is limited and the data-management team absorbs it inside an existing weekly cycle rather than standing up a separate meeting for it.
Add CTMS, eConsent, eCOA, and eTMF from separate vendors and the interface count jumps. Every new system arrives with an owner, a schedule and a set of reconciliation rules that your data managers absorb week after week.
Integration load is the strongest argument for a suite on a complex trial, and the strongest argument against one on a simple trial, where the extra modules add contract weight without removing any real handoff.
Factor four
Integration load is a multiplier
Integration complexity scales with the number of systems the trial actually touches. Two studies of the same size can carry four interfaces and eleven, purely because one uses a suite and the other stitches five vendors together. The interface count is the number worth writing down before you compare contracts.
Factor five
When a focused RTSM provider is enough
A single-country, fixed-design study with a straightforward depot network does not need a full suite. It needs a randomization engine that works, a supply plan that holds, and support that answers.
YPrime's positioning on consent, randomization, trial supply, and outcome data, or a dedicated IRT provider's narrower scope, fits this shape well. The risk to watch is a study that looks simple at design and grows arms or countries after startup — if that is plausible, plan for the growth now rather than rebuilding mid-study.
- One country, one or two depots, a supply route the team already understands from a previous study
- Allocation that is fixed before first patient in and does not intend to move
- No participant-facing instrument that needs its own vendor
- Document control that is real but not the center of the operational effort
- Multi-country, with region-specific depots and an adaptive element the protocol may revisit
- Participant-facing instruments — eConsent, ePRO, reminders — inside the same data model
- A monitoring-heavy operational model, where CTMS and EDC are read together every week
- A document record under inspection pressure, where eTMF is not a side archive
Factor six
When a suite earns its place
A multi-country adaptive study with participant-facing instruments, a monitoring-heavy operational model, and a document control requirement is the case where breadth starts to pay. One data model across RTSM, EDC, CTMS, eCOA, eConsent, and eTMF removes a set of handoffs that would otherwise need owners, schedules, and reconciliation rules.
Medrio, IQVIA, and Medidata all compete in this space with different module histories. None of them is automatically right. The suite earns its place when the integration work it removes is work your team was actually going to do.
The two answers, read across
Focused provider or full suite
The same six complexity factors, read against the two class shapes. What sits on the left is what a focused provider carries cleanly; what sits on the right is what a suite carries. Most teams land on a mix once they see the row.
Where a side-by-side stops making sense
Some studies do not compare across the two class shapes — where the protocol is fixed from the start, participant-facing work is absent, and every region shares a depot, a suite is a contract your team signs without a matching handoff to remove. We say so, rather than stacking a table the study cannot use.
The same boundary runs the other way: a multi-country adaptive study with participant instruments and a document control requirement is not a case a focused RTSM provider can carry on its own, and pretending otherwise costs more at month eighteen than the suite would have cost at signature.
Empty state, on purpose
This configuration has no comparable on the other side of the line. Read the six factors again for your protocol, and price the class you actually need rather than the class a template suggests.
Jump to the checklist
The operations room, before the first call of the day. The plan from design lands here or it lands in a spreadsheet.
The short complexity checklist
Write the answers down before you talk to vendors
Five straightforward questions. If most answers are simple, a focused provider is the honest starting point. If several point the other way, price a suite and see whether the removed handoffs justify the difference.
Complexity is a budget line, not an abstraction — and one written before the vendor shortlist is worth more than one negotiated after it.
Common questions from study teams
Answers worth having in writing
Does a Phase 1 study need an RTSM platform?
Not always. A small, single-site study with simple allocation can run on a lighter system or manual process. Once multiple sites, blinding requirements, or supply tracking enter the picture, an RTSM platform usually becomes the practical choice.
My study might add countries later. Does that change the platform decision?
Yes. A platform that handles one country's depot structure may strain when a second region is added. Raise the possibility with vendors during evaluation and ask how they handled a country addition on a comparable study, including the timeline.
What is a realistic timeline for adding a module mid-study?
It depends on the module and the vendor's service model. Rather than a generic figure, ask for the last two cases where a module was added to a live study and how long from request to release. In-house teams typically move faster than partner-routed ones.