Quick answer: Multi-location specialty groups centralize referral intake in ModMed by consolidating every site's fax lines and referral inboxes into one automated queue, applying a single extraction and completeness standard across all locations, then routing each referral to the right site and provider based on payer, geography, and schedule availability. The technology is the straightforward part. The hard part is getting five acquired practices to agree on what a complete referral looks like, and ModMed referral intake automation only works as well as that agreement does.
What "decentralized referral intake" actually looks like
A multi-site specialty group on a shared ModMed instance usually has referral intake running six different ways at once, and leadership often doesn't know it.
Site A has a physical fax machine and a coordinator who's been doing this for eleven years and keeps her own spreadsheet. Site B forwards its fax line to a shared email inbox that three people check. Site C was acquired eight months ago and still uses its pre-acquisition workflow because nobody has had time to change it. Site D routes everything to the central billing office, which wasn't designed for intake and treats it as a side task.
The symptoms show up in the numbers before anyone traces them to the cause. Referral-to-visit conversion varies by 20 points across sites with similar payer mix. One location's schedule runs full while another has open blocks. A referring PCP group complains that they never hear back, and it takes two weeks to determine which site dropped the referral.
MGMA's work on closed-loop referral management frames the root issue precisely: referrals stall when ownership of each step is unclear. Distribute that ambiguity across six sites and it compounds.
The centralized operating model
Centralizing doesn't mean one person doing everything. It means one process, one queue, and one standard — executed by automation with a small central team working exceptions.
The shape most groups land on:
- One inbound endpoint. Every site's referral fax number and portal feed points at a single digital intake, regardless of which location the referral names.
- One automated processing pass. Classification, extraction, patient matching against the shared ModMed instance, and completeness checking run identically for every referral in the group.
- One central intake pod. Two or three people, not one per site, working the exception queue and chasing incomplete packets. This team is usually smaller than the sum of the site coordinators it replaces.
- Site-level scheduling stays local. Schedulers at each location still own their calendars. Centralization is about getting the referral clean and routed, not about taking scheduling away from the people who know their providers.
That last boundary is what makes the model survive contact with practice leadership. Site managers will resist losing control of their schedules and are usually right to. They resist far less when the pitch is that referrals will arrive already parsed, already matched, and already checked.
Honey Health's Referral Intake agent is designed to sit at exactly this layer — one automated intake pass across the whole group, writing into the shared ModMed instance, with routing rules the group defines centrally.
How does routing decide which location gets the patient?
This is the question that separates a real multi-site implementation from a single-site tool used by several sites.
Routing logic generally weighs four inputs:
- Referring provider intent. If the PCP named a specific physician or location, that's the default and it should be honored unless something overrides it.
- Payer and network. Not every provider in a group participates with every plan. Routing a Medicare Advantage referral to a provider who's out of network for that plan creates a denial and an angry patient.
- Geography. Patient home address against site locations, with a realistic drive-time assumption rather than straight-line distance.
- Capacity and subspecialty. Which locations have availability inside the clinically appropriate window, and which providers actually do the procedure being requested.
Groups usually get inputs one and three right immediately and underweight two and four. Payer-network routing in particular is where automation earns its keep, because a human coordinator cannot hold every plan-provider combination in their head across a fifteen-provider group.
Build the routing rules as an explicit, reviewable document before configuring anything. When conversion drops in month four, you'll want to be able to read the rules and see what changed rather than guessing at a black box.
There's also a tie-breaking question most groups don't answer until it bites them: what happens when two locations are equally appropriate. Round-robin distributes load evenly but ignores that some providers convert referrals to procedures at higher rates. Routing to the earliest available appointment maximizes speed to care but can concentrate volume at your newest site. Neither default is wrong, but the choice should be deliberate and revisited quarterly, because it shapes where your growth lands.
The visibility layer leadership actually needs
Centralized intake produces group-level data that decentralized intake structurally cannot. Four views are worth building on day one:
Referral volume by referring provider, by site. This turns referral relationships into a managed asset. You'll find PCP groups sending you thirty referrals a month that nobody at the group level knew about, and others that dropped off six months ago without anyone noticing.
Conversion to scheduled visit, by site. The single clearest measure of intake health. Sites that lag on this after centralization usually have a scheduling capacity problem, not an intake problem — which is a much easier thing to fix once you can see it.
Time from receipt to first scheduling touch. Where leakage originates. Referrals that sit for days convert worse, and the effect is steep.
Incomplete-packet rate by referring office. Your ammunition for a productive conversation with a referring practice. "Forty percent of your referrals arrive without the imaging report, and here's what that costs both of us in patient delay" is a conversation that changes behavior.
Why acquisitions make this urgent
PE-backed and MSO-affiliated specialty groups acquire practices faster than they integrate them, and referral intake is one of the workflows that stays broken longest because it doesn't show up as an outage.
Each acquired practice arrives with its own fax numbers, its own coordinator, its own tribal knowledge about which referrals matter, and often its own patient records that overlap with yours. The referrals keep flowing, so nothing looks urgent — but the group is now running two intake standards, and the newly acquired site's conversion rate is invisible until someone builds a report that spans both.
A centralized automated intake layer makes each subsequent acquisition materially cheaper to integrate. The playbook becomes: point the acquired practice's fax numbers at the group endpoint, add the site and its providers to the routing rules, run a duplicate-chart cleanup, and the new location is on the group standard in weeks rather than quarters.
One caution worth naming: do the duplicate-chart cleanup before you point the fax lines. Acquired practices frequently share patients with your existing locations, and automated patient matching against a database full of duplicates will propagate the problem at machine speed. This is unglamorous work that saves your billing team months.
Sequencing a rollout across sites
Don't go live everywhere at once. The sequence that works:
- Pick one site as the pilot — ideally a mid-volume location with a cooperative manager, not your biggest or your most troubled.
- Write the group referral standard before touching technology. What fields are required, what makes a packet complete per referral type, what the routing rules are. Get clinical leadership to sign it.
- Run the pilot site in shadow mode for two to four weeks. Automation processes everything; the existing coordinator keeps working normally; compare outputs.
- Go live at the pilot, then add sites in waves. Two or three at a time, with a week between waves to absorb what breaks.
- Consolidate the intake staffing last. Let the automation prove itself before you reorganize people around it. Reversing a technology decision is cheap; reversing a staffing decision is not.
Expect the whole sequence to take a quarter for a group of five to ten sites, and expect most of that calendar time to go to fax line consolidation and internal agreement rather than configuration.
One political note, since this is the part that actually derails projects. The site that resists hardest is usually the one whose coordinator is genuinely excellent — she catches things the process would miss, and her site's numbers prove it. Treating her as an obstacle is a mistake. Bring her into writing the group standard instead, because the rules living in her head are the ones you want encoded. Groups that do this end up with better automation and a champion at the site that would otherwise have been the holdout.
Frequently asked questions
Does centralizing referral intake mean cutting front-desk staff?
Usually not, and groups that promise a headcount reduction to their board tend to regret it. The typical outcome is that site coordinators stop doing data entry and move to patient outreach and scheduling — work that directly increases conversion. The central intake pod is smaller than the site coordinators it consolidates, but the reclaimed capacity is generally redeployed rather than eliminated.
Can this work if our sites are on separate ModMed instances?
It's harder and worth knowing before you start. A shared instance makes centralized patient matching straightforward. Separate instances mean the automation has to know which instance to write to, and cross-site patient matching becomes unreliable. If instance consolidation is on your roadmap, sequence it before intake centralization.
How do we handle referrals that name a specific physician?
Honor them by default. A referring PCP who sends a patient to a named surgeon has usually made that choice for a reason, and overriding it to balance capacity damages the referral relationship. Build the override as an exception requiring a human decision, not as an automatic capacity-balancing rule.
What happens to referral relationships when intake stops being local?
This is the legitimate concern site managers raise. The answer is that the relationship work — calling the PCP office, resolving problems, building rapport — should stay local and become more informed. When a site manager can see exactly which referring offices send them volume and which packets arrive incomplete, those conversations get better, not worse.
How long before we see the numbers move?
Time to first scheduling touch improves almost immediately, usually within the first two weeks at a site. Conversion to scheduled visit takes longer to read cleanly because it depends on scheduling capacity and patient outreach downstream. Give it a full quarter before drawing conclusions, and measure against the baseline you captured before go-live rather than against a vendor benchmark.
