Evaluating Referral Automation for Multi-Site Groups: The Criteria Single-Site Buyer's Guides Miss

Evaluating referral automation for a multi-site group requires criteria that single-site buyer's guides never test: whether the platform standardizes workflow across sites while allowing controlled per-site configuration, whether it integrates with multiple EHRs at once, whether analytics roll up to network level with site benchmarking, which coordination team model it supports, and whether the vendor can execute a phased multi-location rollout.

If you are buying referral automation for one clinic, the established checklists work fine. Start with our referral management software buyer's guide for the core capability list: intake, tracking, closed-loop workflow, outreach, integration basics, and security. This article assumes you have read something like it.

Buying for five, fifteen, or forty locations is a different purchase. The failure modes that kill multi-site deployments (workflow fragmentation, integration sprawl, analytics that cannot compare sites, rollouts that stall after the pilot clinic) do not appear in single-site evaluations at all. Below are the six criteria that decide multi-site outcomes, and how to test each one before you sign.

Criterion 1: Standardization vs per-site configuration

The central tension of any multi-site tool: your network needs one standard workflow (that is most of the ROI), but your sites are genuinely different. Different specialties, different payer mixes, different staffing depth, sometimes different states with different Medicaid rules.

Weak platforms resolve the tension in one of two bad ways. Either everything is globally configured, so the workflow that fits your flagship site gets forced on the rural clinic with one coordinator, or everything is site-configured, so within a year you own fifteen divergent workflows again, which is exactly the problem you were buying your way out of. If your group is a PE-backed platform standardizing acquired practices, the operating-model side of this problem has its own playbook; see referral standardization for PE-backed clinics.

What good looks like is layered configuration:

• Network-level defaults for statuses, service levels, routing logic, and documentation standards, owned centrally.
• Explicit, bounded per-site overrides (specialist panels, hours, languages, local payer quirks) that central admins can see and audit in one place.
• Change control: a workflow change should be deployable to all sites at once, not re-clicked into fifteen admin panels.

How to test it: in the demo, ask the vendor to change a network-wide routing rule, then add a site-specific exception, and show you the audit view of which sites deviate from standard. If the answer involves configuring each site separately, price in the ongoing admin cost of that honestly.

Criterion 2: Multi-EHR and multi-instance integration

Single-site guides ask "does it integrate with my EHR?" Multi-site groups, especially those built by acquisition, need a harder question answered: does it integrate with all of ours, at the same time, into one worklist?

Three scenarios to evaluate against your actual footprint:

1. One EHR, one instance. The easy case; almost any vendor handles it.
2. One EHR, multiple instances. Common post-acquisition (two athenahealth tenants, two Epic instances not yet consolidated). Some platforms treat each instance as a separate deployment with separate logins and separate data, which quietly destroys the network-level view you are paying for.
3. Multiple EHRs. The acid test. A referral originating in eClinicalWorks at one site that lands with a specialist on Epic at another should appear as one referral with one status trail, not two records in two silos.

Also probe the transition story: if you plan to consolidate EHRs in two years, what does the migration path look like inside the referral platform? A vendor with 20+ EHR integrations in production is a reasonable proxy for having seen your combination before, but make them name sites running your specific mix.

How to test it: give the vendor your real EHR inventory (vendors, versions, instance count) in the RFP and require the demo to show a cross-EHR referral end to end. General AI-vendor diligence questions (claims validation, references, security review) apply on top of this; that checklist lives in how to evaluate healthcare AI vendors.

Criterion 3: Network-level analytics and site benchmarking

At one site, referral analytics answer "how are we doing?" At fifteen sites, the valuable question changes to "which sites are outliers, and why?" That question is what justifies central operations existing.

The reporting layer must natively support:

• Roll-up and drill-down: network totals to site to provider to individual referral, without exporting to spreadsheets.
• Site benchmarking on operational metrics: completion rate, time to first patient contact, time to scheduled, leakage rate, aging referrals, per-coordinator throughput. For what those distributions look like across the industry, see the 2026 referral leakage benchmark report.
• Cross-site leakage visibility: referrals leaving the network from each site, and to whom. Multi-site groups usually discover that keepage varies wildly by site, and that variance is found money.
• Cohort comparisons that survive rollout phasing: site A live for a year should be comparable against site B live for a month without hand-built normalization.

How to test it: ask for a live view of an existing multi-site customer's dashboard structure (anonymized) rather than screenshots. Then ask a specific question: "show me how a regional director would find the site with the worst 30-day completion trend this quarter." Watch how many clicks and exports it takes.

Criterion 4: Which coordination team model does it assume?

Multi-site groups run referral coordination in one of three models, and platforms carry silent assumptions about which one you use.

None of these is universally right. Centralized models win on consistency and cost per referral; distributed models win on local relationships and site accountability; most groups over about ten sites end up hybrid. The evaluation question is not "which model is best" but "does the platform support the model we run today and the model we are moving toward?" Buying a tool that locks in today's org chart is a two-year mistake. Patient-facing phone coverage across locations is a related but separate decision; that territory is covered in multi-location voice AI for patient access.

A note on automation depth: the more coordination work the platform automates rather than merely queues, the less the team-model question costs you either way. Platforms that automate up to 90% of coordination work, as Linear Health's referral coordination software does, shrink the human queue to exceptions, at which point a small central exceptions team plus site-level relationships becomes the natural structure.

How to test it: describe your current model and your two-year target model in the RFP, and make the vendor demo both queue structures with your site list.

Criterion 5: Phased multi-location rollout capability

Multi-site deployments do not fail at the pilot. They fail between site 2 and site 6, when vendor implementation attention moves on and the rollout becomes your project team's problem.

Evaluate the rollout as a product feature:

• A written wave plan template. The vendor should propose sequencing logic (start with a high-volume site to prove value, or a low-complexity site to derisk, and be able to argue why), not just ask for your go-live dates.
• Repeatable site onboarding. After the first wave, adding a site should be a templated exercise (site profile, specialist panel load, staff training, cutover) measured in weeks. Ask what the marginal site actually requires from your team, in hours.
• Config cloning. New sites should inherit network defaults automatically, with only the bounded per-site items from criterion 1 needing setup.
• Training that scales. Train-the-trainer materials and role-based paths, because flying the vendor to fifteen sites does not happen.
• A stated reference pace. Vendors with real multi-site experience can name how many sites per month they have onboarded for comparable groups. Vendors without it will say "as fast as you want," which is the wrong answer.

How to test it: require a named implementation lead and a wave-by-wave draft plan for your site list as part of the proposal, and reference-check a customer at your site count, specifically asking what happened after the pilot wave.

Criterion 6: Multi-site demo and pilot red flags

Finally, the anti-pattern list. Any of these in the sales cycle predicts trouble at scale:

• Every demo is a single-clinic demo. If the vendor cannot demo two sites, two queues, and a network dashboard, they are selling a single-site product with a multi-site slide.
• "Each site is its own instance." Separate logins, separate reporting, separate admin per site means you are buying N deployments, not one platform.
• Site benchmarking arrives via "custom reports." Cross-site comparison should be native. Custom-report promises are where analytics roadmaps go to die.
• The pilot is scoped to your easiest site only. A fair pilot includes your hard site: the different EHR, the different state, the two-person front desk. Insist on piloting at two dissimilar sites in parallel.
• Pricing punishes growth. Per-site license stacking with mandatory per-site implementation fees can double effective cost by the end of the rollout. Model total cost at full deployment, not pilot pricing.
• No customer at your scale. If their largest customer runs fewer sites than you do, you are the beta program. That can be acceptable, but only knowingly and with contract terms that reflect it.

A useful calibration point when judging vendor scale claims: real multi-site referral automation deployments exist at the size of Aunt Martha's Health & Wellness, 35 sites and 100 providers running 10,000+ referrals and coordination events per month through one platform. Ask any vendor for their equivalent, with numbers.

If you are building a multi-site shortlist, pressure-test these six criteria against each vendor, including us. A multi-site evaluation should start with your site list and EHR inventory, not with a feature tour.

Frequently asked questions

Sources: HHS HIPAA Security Rule, HHS Sample Business Associate Agreement Provisions, NIST AI Risk Management Framework, ONC SAFER Guides, and HL7 FHIR R4 ServiceRequest.