Two Approaches to the Same Problem
I've spent a fair amount of time in the past year talking with site operations teams at growing biopharma sponsors and CROs about what they're actually using for site activation and patient referral management. The answer, more often than I expected, is some version of a CRM platform — Salesforce, HubSpot, or a specialized clinical CRM — combined with email and phone-based site outreach, tracked through spreadsheets or the CRM's pipeline views.
This is not a failure of sophistication. CRM-based site activation works in the sense that every working process works: it produces enrollments, it tracks activity, it gives someone a dashboard. The question is how it performs against the alternative — AI-signal-driven referral generation based on EHR phenotype matching — in terms of the metrics that actually determine program success: time from site activation to first enrollment, screen failure rate, coordinator burden per enrolled patient, and enrollment velocity over the activation period.
The comparison is not entirely clean, because CRM-based outreach and AI-signal-driven referral are not strictly parallel — they target different bottlenecks in the enrollment process. But the operational realities are comparable enough to draw useful conclusions.
How CRM-Based Site Activation Actually Works
In a conventional CRM-based site activation model, the workflow looks roughly like this: the sponsor or CRO clinical team builds a contact list of investigators and site coordinators for candidate sites. These contacts are imported into the CRM. Outreach sequences are configured — typically 2-3 emails followed by phone calls, tracked in the CRM with disposition notes. Interested sites progress through the CRM pipeline from "prospect" to "feasibility assessment" to "activated."
Once a site is active, coordinator outreach for patient referrals typically happens through the same CRM contact history, supplemented by periodic site monitoring calls. Sites report on enrollment progress through the CRM or through the sponsor's CTMS (Clinical Trial Management System). Referrals are generated when site coordinators identify candidates through their normal clinical workflow — passive identification — and enter them into the referral tracking system.
The CRM is genuinely useful for this workflow. It provides contact management, activity tracking, pipeline visibility, and a historical record of site communications. For programs where the limiting factor is sponsor-side coordination and site relationship management rather than patient identification, CRM-based activation is a reasonable operational backbone.
Where CRM-based approaches show consistent limitations: patient-side referral generation. The CRM tracks communication with site contacts. It doesn't help those contacts find patients. Coordinators who receive CRM-driven reminders that "now is a good time to screen patients for Trial XYZ" still need to independently identify which patients to screen — and they do that through the same passive-identification methods they've always used. The CRM adds organizational infrastructure around an identification process that remains fundamentally unchanged.
How AI-Signal-Driven Referral Works
AI-signal-driven referral approaches the problem from the opposite direction. Rather than organizing communication with site contacts and hoping that coordinators will identify patients on their own, the platform analyzes EHR data at each site to surface specific candidate patients who match the trial's eligibility criteria. The output is not a reminder to screen; it is a list of specific named patients (or de-identified candidate records, depending on the data use agreement structure) who have been pre-scored against the protocol's inclusion and exclusion criteria.
The coordinator's job changes from investigator to reviewer: rather than scanning their patient panel for candidates, they receive a candidate list with matching rationale and review it for any criteria that require clinical judgment or recent-data verification. The time required per candidate is substantially lower than passive identification, and the starting quality of the candidate pool is higher because obvious exclusions have been filtered before coordinator review.
The activation timeline effect is significant. A CRM-driven site that activates in week 6 but relies on passive identification may enroll its first patient in week 14 or 16, as coordinators gradually find candidates through normal clinical flow. An AI-signal-driven site that activates in week 6 with a pre-populated candidate list may enroll its first patient in week 8 or 9, because candidates were identified in the EHR before or concurrent with activation. The time-to-first-enrollment difference is a direct measure of the identification methodology's impact on enrollment velocity.
Comparative Performance: What Operations Data Shows
Direct head-to-head comparison between CRM-only and EHR-signal-driven approaches within the same trial program is rare in published literature — most published enrollment optimization analyses aggregate data across heterogeneous site and program types in ways that make clean attribution difficult. But observations from clinical operations teams that have deployed both approaches across different programs, and from EHR-matching platform deployments across site networks, are instructive.
Screen failure rate is the most reliable comparative metric. Sites receiving AI-generated pre-screened referral lists consistently show lower screen failure rates than sites relying on coordinator-driven passive identification within the same trials, controlling for therapeutic area. The pre-screening filter — removing obvious ineligibles before coordinator review — is the primary driver. In biomarker-selected oncology programs, where screen failure rates in passively-identified populations often reach 50-65%, AI-pre-screened candidate pools can show rates in the 30-40% range, a difference with substantial per-enrolled-patient cost implications.
Enrollment velocity per activated site — patients enrolled per site per month, post-activation — tends to be higher at AI-signal-driven sites, particularly in the first 90 days after activation when the candidate pipeline is being built under passive identification. A site that already has a candidate list at activation starts enrolling faster, which matters significantly for programs under timeline pressure.
Where CRM-Based Approaches Remain the Right Tool
The practical comparison should not be framed as "AI-signal versus CRM" as a binary choice, because they address different parts of the activation and enrollment process. CRM infrastructure is still necessary for managing the organizational aspects of a multi-site trial: site contact management, feasibility outreach pipeline, communication records for monitoring purposes, regulatory document tracking, and site relationship management across a program lifecycle that may span years.
There are also trial types where passive CRM-supported referral is adequate and AI-signal enhancement adds limited value: high-prevalence conditions where patient identification is not the limiting factor, protocols with broad eligibility criteria where virtually any patient with the target diagnosis qualifies, and early-phase dose-escalation studies where enrollment capacity is intentionally constrained rather than maximized.
We're not arguing that CRM has no role — we're saying that for Phase II/III programs where the limiting factor is patient identification velocity and screen failure efficiency, CRM-based site activation alone does not address the core bottleneck. It organizes the process around a bottleneck rather than eliminating it.
Integration Rather Than Replacement
The most operationally coherent approach for growing biopharma sponsors managing Phase II/III programs is integration: CRM or CTMS for site relationship management and operational tracking, EHR-signal-driven referral generation for patient identification, with the two systems connected such that candidate lists generated by the matching platform flow into the site's operational workflow without requiring coordinators to use two disconnected systems.
Integration at the workflow level — not just the data level — determines whether the AI-signal benefit is actually realized. A matching platform that delivers candidate lists via an API that no coordinator ever accesses is not delivering operational improvement. The operational improvement comes from candidates appearing in the workflow that coordinators actually use: whether that's the site's EHR inbox, a portal they're trained to check, or a structured communication within the sponsor's CTMS site management workflow.
The integration question is not glamorous, but it is where the difference between a technology pilot and an operational program lives. Sponsors who have worked through the integration layer — who have defined the communication protocol between the matching platform and the site workflow — are the ones seeing the enrollment velocity and screen failure improvements at scale. Those who haven't are often running a matching platform in parallel with their existing process, rather than through it, and wondering why the numbers look similar.
