Signant Health Alternatives for eCOA, ePRO and Randomization: Buy, Switch or Build

Why sponsors and CROs start looking for an alternative

The first trigger is arithmetic. Specialist eClinical vendors price and staff per study, because that is genuinely how the work arrives: a protocol, a build, a user acceptance test cycle, a go live, then maintenance until database lock. If you run one large trial, that model is efficient and you should not be reading this section. If you run six modest trials a year with broadly the same visit structure and the same instruments, you pay for six builds of something very close to the same thing, and at the end of it you own none of it.

The second trigger is timing. Study startup is where sponsors lose weeks they never recover, and any system that has to be built, configured and tested before first patient in sits directly on that critical path. When a protocol amendment lands after go live, and amendments always land, the change flows through the same build, test and release cycle. Nobody is being obstructive. It is what validated software requires. It still hurts when the amendment is a single visit window.

The third trigger is data. Sponsors increasingly want endpoint data flowing into their own environment continuously rather than in periodic transfers, and want the same instrument to behave identically across a programme so the analyses are comparable. That ambition sits awkwardly with a model where each study is its own configured island.

What Signant genuinely does well

Signant Health, formed from the combination of Bracket and CRF Health, sits in the small group of vendors that can carry eCOA, randomization and trial supply, eConsent and endpoint quality work across a global study. The value is not the software alone. It is that they have done it before under inspection conditions: device provisioning and logistics to sites in multiple countries, translations and linguistic validation of instruments, site training, help desk coverage across time zones, and the documentation an auditor expects when they ask how a patient reported score got from a screen into the submission.

Randomization and trial supply is worth calling out separately. Getting randomization wrong is not a bug, it is a compromised study. Drug supply forecasting that keeps sites stocked without over shipping expensive investigational product is a specialised discipline with real money attached. Vendors who do this for a living have seen failure modes you have not.

The parts you should not casually rebuild

Any honest build conversation starts with what stays off the table. Validated clinical outcome assessment instruments are frequently licensed intellectual property, and migrating a paper instrument to a screen is a governed process with published expectations about faithfulness of migration, not a design decision your product team makes. Translation and linguistic validation of each instrument in each locale is separate work again. Randomization integrity, blinding, emergency unblinding and the audit trail around them are the definition of high consequence. And the whole stack sits under electronic records and signatures expectations, which means validation evidence, controlled change and inspection readiness for the life of the study and beyond.

None of that makes a build impossible. It makes an unscoped build reckless. The teams that succeed treat regulatory and quality as design inputs from week one rather than a review gate at the end.

Where the vendor model strains

Repetition without accumulation is the core strain. Every study starts near zero and the learning stays with the vendor. Mid study changes cost time and money because the validated envelope has to be re established, and the sponsor absorbs that on the critical path. Reporting is bounded by what the platform exposes, so cross study questions, the ones a programme lead actually asks, tend to be answered by exporting and rebuilding the picture elsewhere. And the patient facing experience is largely fixed, which matters if retention is your problem rather than data capture.

That last point deserves weight. If you are running long duration studies where patients drop out, the app is not a data collection tool, it is a retention tool. Sponsors who want to change how reminders, education and burden reduction work quickly find that these are configuration options rather than something they can iterate weekly.

Your realistic options

• Stay and negotiate at programme level. If you are placing several studies, price and contract as a programme with reusable configuration rather than as unrelated studies. This is the cheapest lever and it is routinely left unpulled.
• Move to a lighter eCOA vendor. A number of smaller platforms target mid sized sponsors and academic sponsors with faster builds and simpler commercial terms. For phase two work, investigator initiated trials and device studies, this is often a better fit than an enterprise vendor.
• Split eCOA from randomization. These are different disciplines and bundling them is a convenience, not a requirement. Some sponsors keep a specialist for randomization and supply, where the risk is concentrated, and use a lighter or custom solution for patient data capture.
• Build for a protocol family. If your studies share a structure, build once against that structure with validation baked in, and treat each new study as a configuration of a validated product rather than a new build.
• Build a patient facing layer only. Keep the validated endpoint capture where it is and build the engagement, education and scheduling experience around it. Lower regulatory exposure, direct effect on retention.

When a custom build pays back

Three situations justify it. First, protocol repetition: a sponsor or a CRO running a steady stream of structurally similar studies can amortise one validated build across many, and the second study onwards is configuration rather than construction. Second, patient experience as a differentiator: decentralised studies, registries, long term follow up and real world evidence programmes live or die on whether people keep engaging, and owning that interface means you can change it on your timeline. Third, data ownership: if your scientific strategy depends on pooling endpoint data across a programme in your own environment, building the capture layer to your own model removes a permanent reconciliation cost.

Against that, one situation kills it outright. A single pivotal study with a fixed readout and a regulatory submission behind it is not the place to learn how to build validated clinical software. Buy it, run it, and revisit the question when the pressure is off.

Migration reality

Mid study migration is close to unthinkable and you should treat it as such. Endpoint continuity, instrument version consistency and blinding all argue for finishing what you started on the system you started it on. Plan changes at the boundary between studies, not inside one.

At that boundary, the work is mostly evidence and logistics. You need historical data exported in a form your biostatistics team accepts, with the audit trail intact, and you need it retained for the full record retention period, which is measured in years after study close. Device logistics, site training and help desk coverage transfer with the platform, and sites bear the cost of that change, so factor site goodwill into the decision. If you are standing up a custom system, run it alongside the incumbent on a small, low risk study first. Do not let your first validated release carry a primary endpoint.

Cost bands

Specialist eClinical vendors quote per study, typically as a build fee plus per site, per patient and per month running costs, with device provisioning and translations priced separately and mid study amendments handled as change orders. The total scales with study size, duration, country count and instrument complexity.

On the custom side, based on what Digital Heroes typically delivers: a protocol family specific patient data capture application, or a randomization and supply engine for a defined design, runs roughly $80k to $180k over 12 to 20 weeks including validation documentation. A reusable platform intended to serve multiple studies, with configuration tooling, role based site access, integrations to your data environment and full evidence packages, runs roughly $250k to $500k. Instrument licensing, translation and linguistic validation sit outside those numbers and belong in a separate line.

The honest recommendation

Stay with a specialist vendor when the study is pivotal, global, complex in its randomization, or simply too important to experiment with. That is most sponsors most of the time, and there is no shame in the recommendation. Move to a lighter vendor if you are a mid sized or academic sponsor carrying enterprise scale overhead for phase two work. Build when repetition, retention or data ownership makes the same problem recur every single year, and build the low risk layer first so your organisation learns validation on something that cannot compromise an endpoint. The worst outcome is a half built system carrying regulated data with nobody named as its owner. Decide who owns it before you decide to build it.