Quick answer: Setting up a centralized referral intake hub across an MSO's clinics runs as a 90-day rollout in three phases — consolidate the inbound channels into one ingestion layer (weeks 1–4), define the routing rules per specialty and per site (weeks 4–8), then cut over one clinic at a time and measure referral leakage before and after (weeks 8–12). The work is roughly half operational and half technical; the operational half (change management, partner communication, defining "centralized" sharply) is what usually determines whether the rollout sticks.
Why a 90-day rollout works better than big-bang or per-site
Two failure modes dominate MSO centralization projects. The first is the big-bang rollout where the central team tries to flip every clinic simultaneously and ends up with multiple sites in partial cutover at once, none of them fully working. The second is the unbounded per-site rollout where the central team works one clinic at a time with no time pressure and the project stretches into year two before half the network is live.
A 90-day rollout splits the difference. It's structured enough to force phase discipline — you can't move to phase two until phase one is working — and bounded enough that the central team commits to a clear timeline the executive sponsor can defend.
The three phases are sequenced by complexity rather than by clinic size or geography. Phase one is the foundational work that applies to every clinic regardless of EHR or volume. Phase two is the per-network routing logic that the AI agents and central team will operate against. Phase three is the actual clinic-by-clinic cutover, starting with the anchor clinic and adding others as the model proves out.
Inside those three phases, the central team handles the technical integration; the local clinics handle the operational change management; and an executive sponsor — usually the COO or VP of Operations — owns the timeline and unblocks the cross-functional decisions that the central team can't make on its own.
Phase 1 — Consolidate the inbound channels (weeks 1–4)
The first four weeks are about inventory and ingestion. Every clinic in the MSO has its own set of inbound referral channels, and the first job is to know what they are and route them all into a single platform.
Start by inventorying each clinic's existing channels. Five things matter: the inbound fax numbers (often more than one per clinic — main line, scheduling line, specialty-specific lines), the patient portal submission flows, any direct EHR-to-EHR exchange relationships (CommonWell, Carequality, regional HIE participation), the email addresses where referrals occasionally land, and the phone-based referral intake. The AMA tracks ongoing fax dependence in healthcare, which is why fax inventory usually surfaces the most surprises — older clinics often have three or four numbers that no one's tracked centrally.
Once the inventory is complete, set up forwarding. Inbound fax traffic forwards from each existing number to the central ingestion layer (the original number stays the same from the referring provider's perspective). Patient portal submissions get routed through the central platform. Direct EHR exchange feeds get aggregated into the same intake queue. The point is that every inbound channel ends up in one place by the end of week four.
The clinics don't lose anything operationally in phase one. Their existing channels still work; the central platform is just observing inbound traffic and tagging it by source clinic. This is intentional — phase one is shadow operation. Nothing changes about how the local front desk processes referrals yet.
The deliverable at the end of week four is a single dashboard showing every inbound referral across the MSO, with the source channel, source clinic, and document type tagged automatically. That dashboard is the artifact the central team uses to design the routing rules in phase two.
Phase 2 — Define the routing rules (weeks 4–8)
Phase two is where the operational work gets harder. Now the central team has to define what should happen to each referral once it lands in the central ingestion layer. The decisions are specific and they don't transfer cleanly across MSOs.
The first decision is the queue structure. Two viable patterns. Single shared queue, where every inbound referral routes into one queue and the routing logic distributes from there — simple to manage, harder to specialize. Per-specialty queues, where cardiology referrals route into a cardiology queue, dermatology into a dermatology queue, and so on — more specialization but more queues to monitor. Most MSOs end up with a hybrid: one shared queue for the initial classification, then per-specialty sub-queues once the AI has routed the referral.
The second decision is the routing rule set itself. For each specialty, the team has to define which receiving clinic is the right destination based on the patient's geography, the patient's payer, the referring provider relationship, and provider capacity. These rules don't fit on a whiteboard for a 10-clinic MSO; they fit in a routing configuration that maps thousands of combinations. AI agents handle most of this by reading document content and applying network-wide policy, but the policy itself has to be defined by the central operations team during phase two.
The third decision is the exception path. What happens when a referral is genuinely ambiguous — a multi-specialty patient, a referring provider the system doesn't recognize, a payer the central team hasn't loaded yet? Strong implementations route these to a central exception queue with clear ownership; weak implementations let them sit in limbo while the team debates who owns the resolution. Defining the exception path on day one is what prevents the queue from becoming a graveyard.
The deliverable at the end of week eight is a documented routing policy, a configured AI agent or central team that applies it, and a tested exception path. The clinics are still operating per-site, but the central platform is now ready to take over for the first clinic in phase three.
Phase 3 — Cut over one clinic at a time (weeks 8–12)
The cutover is the operational step where the central platform actually starts processing referrals end-to-end for a specific clinic, and the local front desk stops doing the work.
The right starting clinic is rarely the largest. Pick the anchor clinic by three criteria: it runs a cloud-native EHR with mature APIs (athenahealth, Elation, NextGen Office), the local practice administrator is a willing partner rather than a skeptic, and the referral volume is meaningful enough to validate the model but not so high that any glitches cause material patient harm. A 6-provider primary care practice on athenahealth tends to be a better anchor than the 25-provider flagship on Epic.
The cutover itself runs over two weeks. Week one is parallel operation: the central platform processes the clinic's referrals and writes scheduling tasks into the clinic's PM system, but the local front desk also continues to process referrals in parallel as a control. Any discrepancies between the two flows surface and get resolved before the central platform takes full ownership. Week two is the actual handoff: the local front desk stops processing referrals; the central platform owns the intake; the local schedulers start picking up scheduling tasks from the PM system queue rather than from the fax tray.
Measure two metrics during the cutover. Time-to-first-outreach (median elapsed time from referral arrival to first scheduling call) should drop from 12–48 hours pre-cutover to under an hour post-cutover. Referral-to-appointment conversion rate should hold or improve over 30 days; if it drops, the routing logic or the scheduler handoff is broken and needs adjustment before adding more clinics.
Once the anchor clinic is stable at 30 days post-cutover, the central team starts cutting over additional clinics in parallel — typically two to four per phase. The full 90-day rollout lands one anchor clinic in production by day 60 and 2–4 additional clinics by day 90. The rest of the network follows over the next 60–120 days using the same per-clinic playbook.
What to centralize versus leave at the site
The most common rollout failure mode is over-centralization — pulling work into the central hub that should have stayed local. The reverse failure mode is under-centralization, where the central layer doesn't own enough of the workflow to actually relieve the local front desk. Getting the boundary right is what determines whether the model works.
Centralize at the hub: multi-channel referral ingestion across every inbound channel, document classification and structured data extraction, eligibility and prior auth verification against payer data, content-based routing across specialties and locations, the network-wide exception queue, and the analytics and reporting layer that shows MSO-level referral patterns. These are functions where consolidation produces real operating leverage and where per-site duplication is pure cost.
Leave at the site: the scheduling call itself (the warm patient conversation), appointment confirmation and reminder workflows, the relationship with patients who come in for the visit, and the in-clinic intake process that happens at check-in. These are functions where the local relationship matters more than the central consolidation, and where centralizing actually harms the patient experience.
There's a third category that goes either way: referring-provider relationships. Some MSOs centralize partner relationships at the hub (one network-wide contact for high-volume referring offices); others keep them local. The honest answer is that it depends on whether the referring partners care more about consistency across the network or about the specific local relationships they've built over years. Survey them before deciding.
The EHR integration question
The integration layer is the technical work that the central team and the vendor partner own, but the practice administrator should understand the structure because it determines the rollout sequence.
Cloud-native EHRs (athenahealth, NextGen Office, Elation, smaller cloud platforms) integrate through native APIs in 2–4 weeks per clinic. The implementation is the lightest of the EHR tiers and is the right place to start phase three.
Epic uses a combination of HL7 v2 messaging, Bridges or Connection Hub for document filing, and FHIR APIs increasingly handling read operations. Implementation runs 6–12 weeks because Epic-side scheduling adds time. The integration is reliable once live and is usually the most stable in the long run, but it's the wrong starting point for a 90-day rollout.
On-prem deployments of eClinicalWorks, NextGen Enterprise, MEDITECH, and similar legacy systems typically need an interface engine like Mirth Connect or Rhapsody to bridge the central platform to the EHR database. Implementation runs 8–12+ weeks, with the long tail of legacy systems often requiring desktop automation as a bridge while the interface work is in progress.
We've worked with PE-backed MSOs at Honey Health where the Referral Intake agent handles the central layer of this rollout — multi-channel ingestion, AI-driven routing, eligibility verification, and structured task write-back into each clinic's existing PM system regardless of EHR. The same architecture extends across the rest of the back office (prior authorization, denial management, eligibility, refill management, payment posting) so the intake hub typically becomes the entry point to a broader operations consolidation across the network.
Frequently asked questions
Do we have to centralize every clinic, or can we run a hybrid model permanently?
You can run permanently hybrid, and some MSOs do — typically with cloud-native clinics on the central platform and on-prem clinics still operating per-site until their EHR situation changes. The downside of permanent hybrid is that the analytics layer only sees the centralized portion, so the MSO-level visibility is partial. Most MSOs centralize the whole network eventually, but the timeline for the last 20% is often longer than the timeline for the first 80%.
What's the right size of the central operations team?
For a 5–15 clinic MSO, the central operations team typically runs 4–6 people once the rollout is complete. The team handles the exception queue across all clinics, partner relationships with high-volume referring offices, the analytics layer, and ongoing tuning of the routing rules. During the rollout itself, plan for 2–3 additional people on the project team for the first 90 days who can hand off to steady-state operations once the system is stable.
How do we handle a clinic where the local administrator is resistant to centralization?
Don't force the anchor clinic to be a resistant site. Pick a willing partner for phase three, prove the model works, and then bring the resistant clinics in once the rollout has visible wins. Most administrators get more comfortable once they see the operational metrics — faster time-to-first-call, higher conversion rate, fewer dropped referrals — than they were when the rollout was abstract. If a specific administrator stays resistant after seeing the data, that's usually a deeper change-management issue the executive sponsor has to own.
What's the budget envelope for a typical 90-day rollout?
Platform subscription for a 5–10 clinic MSO typically runs $40,000–$120,000 annually depending on volume and vendor. Implementation cost — integration work, AI tuning, central team onboarding — usually adds $20,000–$60,000 amortized in year one. Internal staffing during the rollout (project sponsor time, central team setup, local clinic change management) is usually the largest cost and the one most often underestimated. Budget at least 0.5 FTE of executive sponsor time across the 90 days.
How do we measure whether the rollout is actually working?
Three metrics drive whether the model is working post-cutover. Time-to-first-outreach should drop to under an hour; referral-to-appointment conversion rate should hold or improve over the first 60 days; and central exception queue volume should stabilize at under 15% of inbound referrals once the AI is tuned. If any of these three goes the wrong direction past day 30 of the cutover, the rollout team has a specific operational issue to fix before adding more clinics — usually in the routing logic or the scheduler handoff.
