Quick answer: A PE-backed MSO should automate prior auth submissions by centralizing intake into a single AI-driven workqueue that normalizes requests across every site's EHR and payer mix — rather than replicating manual PA teams at each acquired practice. The pattern is centralize first, then automate: consolidate PA work into one operation, deploy AI agents to handle determination, packet assembly, submission, and status tracking across all locations, and keep a small central exception team for denials and peer-to-peer work. Done right, the platform gets one rules layer, one queue, and one set of metrics instead of a dozen local processes.
Why per-site prior auth staffing breaks at scale
Every MSO inherits the same pattern with each acquisition: a couple of staff members at each practice who handle prior auths the way that practice has always handled them. It works — at one site. Multiply it across a platform and the cracks become structural.
The first crack is inconsistency. Each site's PA process reflects its own habits, so first-pass approval rates and turnaround times vary wildly between locations doing essentially identical work. When a platform can't explain why Site A's denial rate is triple Site B's, it doesn't have a process — it has a dozen processes wearing the same logo.
The second is trapped knowledge. Payer rules expertise lives in individual coordinators' heads, so when the PA person at an acquired dermatology group leaves, their payer knowledge leaves with them — and PA roles turn over frequently, given the AMA's finding that practices burn roughly 13 hours per physician per week on PA work nobody enjoys.
The third is cost that scales linearly. Per-site staffing means every acquisition adds headcount proportional to its auth volume. For a PE-backed platform whose investment thesis depends on operating leverage, a cost line that grows one-to-one with volume is precisely the thing centralization exists to fix.
There's also a quieter fourth crack: nobody can see the whole picture. With PA scattered across sites, the platform has no consolidated view of turnaround times, denial patterns, or payer behavior — which means no way to negotiate with payers from data, and no way to prove operational improvement at exit.
Centralize first, then automate
The playbook that works runs in that order, because automating twelve different local processes produces twelve automated messes. The sequence:
- Consolidate intake. Route every site's auth-triggering orders into one platform-level queue, regardless of which EHR generated them. Sites stop owning PA; the platform does.
- Normalize the work. Define one standard for what a complete PA case looks like — documentation requirements, payer routing, escalation rules — so an auth from the cardiology group in Phoenix and the GI group in Tampa move through the same stages.
- Deploy the automation against the central queue. AI agents handle determination against plan-level payer rules, extract clinical evidence from each site's chart, assemble payer-specific packets, submit through the right channel — portal, EDI 278, API, or fax — and track status until determination.
- Keep a small central exception team. Denials, peer-to-peer scheduling, and ambiguous cases route to a platform-level team that sees every payer across every site — which is exactly how payer expertise compounds instead of fragmenting.
Notice what this isn't: it isn't building a large central PA department of humans. That's the 2015 version of centralization, and it just relocates the linear cost. The point of centralizing in 2026 is to give the automation one queue to drain — the agents do the volume, and the central team handles judgment.
How does an MSO automate prior auth submissions across different EHRs?
The multi-EHR problem is the technical heart of this question, because acquisitions rarely share a chart. A typical platform runs athenahealth at some sites, eClinicalWorks or ModMed at others, and something older at the practice it bought last quarter. Forcing EHR consolidation before fixing PA means waiting years; the migrations routinely run 12–18 months each.
AI agents sidestep the wait because they connect to each EHR as it is. The integration pattern varies by system — native API or FHIR where the EHR exposes one, HL7 interface feeds where it doesn't, supervised portal-level automation for closed legacy systems — but the agent normalizes everything into the same case format in the central queue. The site keeps its chart; the platform gets uniform PA work.
This matters doubly because the integration surface keeps improving underneath you. ONC data shows FHIR-based connectivity in outpatient settings climbing from 49% in 2021 to 64% in 2024, and the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires payer FHIR PA APIs by January 2027. An MSO that centralizes on an agent layer now plugs each new pipe into one place — instead of upgrading twelve local processes every time a payer or EHR modernizes.
The practical evaluation question for any vendor: can you show this working on our worst EHR, not our best one? Platform buyers should weight the hardest integration case, because that's the site that breaks the centralization story.
The metrics a platform should run PA against
Centralized, automated PA produces something per-site staffing never could: comparable numbers. Four metrics tell the story, and a platform operations leader should review them monthly by site and by payer.
- Turnaround time — order date to determination date. Watch it against the new CMS windows (72 hours expedited, 7 days standard for affected payers); your submission side of the clock is the part you control.
- First-pass approval rate — the share of auths approved without resubmission or appeal. This is the cleanest measure of packet quality, and the number that moves when automated assembly replaces manual form-filling.
- Cost per auth — fully loaded, including the platform fee and the exception team. The CAQH Index benchmark gap — roughly $11.12 per manual transaction versus $2.11 electronic — is the spread you're capturing at volume.
- Denial-overturn rate — of the auth-related denials you appeal, how many you win. A high overturn rate signals the underlying auths were sound and the payer friction is upstream; a low one means packet quality needs work.
The same dashboard becomes diligence collateral. When the platform can show a buyer consistent, improving PA metrics across all sites, back-office operations stop being a diligence risk and start being part of the equity story.
Build versus buy for an MSO
PE-backed platforms have internal ops teams and sometimes real technical talent, so the build question comes up. The honest framing: what you'd be building isn't one tool, it's three ongoing operations. A payer-rules layer that someone updates as rules shift quarterly across every payer in every market you operate in. An integration layer across every EHR in the portfolio — including the ones you haven't acquired yet. And the AI extraction and assembly capability itself, which is a product, not a project.
An internal RPA team can genuinely script some portal workflows, and for a single-EHR, single-market group that might carry meaningful load. At MSO scale, the maintenance burden is the killer: every payer portal redesign and EHR version update breaks scripts, and the team that built them becomes a permanent cost center with key-person risk — the same trapped-knowledge problem you centralized to escape.
Buying the agent layer turns that maintenance into the vendor's problem and prices it predictably per auth or per site. This is the model Honey Health's Prior Authorization agent is built for — multi-site, multi-EHR groups running one centralized PA operation — and because it sits alongside agents for eligibility, referral intake, and denial management, the same centralization investment extends to the adjacent workflows that feed and follow prior auth. The build option makes sense mainly when a platform's auth volume is concentrated in one narrow, stable payer-and-EHR combination — a description that fits almost no acquisitive MSO.
Sequencing the rollout across the portfolio
Don't flip every site at once. The rollout that works starts with one or two sites chosen for signal value — typically the highest-auth-volume site plus the one with the worst denial rate — runs the agent in parallel with existing staff for a few weeks, and uses the measured straight-through rate to set expectations for the rest of the portfolio.
Two organizational notes from how these rollouts actually go. First, tell site staff what happens to their roles early: the local PA grind moves to the platform, and local staff shift to the patient-facing and clinical-support work that sites are perpetually short on. Handled openly, this lands as relief; handled quietly, it breeds the rumor that automation equals layoffs and sites drag their feet on adoption.
Second, resist the urge to preserve site-specific exceptions. Every acquired practice believes its payer situation is unique; nine times out of ten it's the same payers with the same rules approached with different habits. The exceptions worth keeping are payer-driven, not habit-driven — and the central queue makes the difference visible within a quarter.
Frequently asked questions
Should an MSO centralize prior auth before or after consolidating EHRs?
Before — and for many platforms, instead. EHR consolidation takes years per wave, while an agent layer connects to each site's existing system in weeks. Centralizing PA on automation also removes one of the main operational arguments for rushing risky EHR migrations, since the platform gets uniform workflow without uniform software.
How many central PA staff does an automated MSO operation need?
Far fewer than the sum of today's site staff, but not zero. The central team works exceptions: denials, peer-to-peer coordination, ambiguous documentation, and novel payer policies. Size it to your exception rate — typically the 10–30% of volume the agents route for judgment — and let it shrink as the straight-through rate climbs.
What happens to PA when we acquire a new practice?
Onboarding becomes a repeatable playbook instead of a staffing scramble: connect the agent to the new site's EHR, map its payer mix to the existing rules layer, and route its volume into the central queue. Most platform additions onboard in the 30–60 day integration window, regardless of which EHR the acquisition runs.
Does centralized automation work when sites are in different states with different payers?
Yes — multi-market payer variation is an argument for centralizing, not against it. Regional payer rules live in the agent's rules layer rather than in local coordinators' heads, and the central exception team sees patterns across markets that no single site could. The agent submits through whatever channel each regional payer requires.
How do we keep individual practices from feeling like they've lost control?
Give sites visibility instead of ownership: status write-back into their own EHR, site-level dashboards, and a named escalation path into the central team. Most practice managers discover quickly that what they wanted was never control of the PA process — it was confidence that auths get done before patients show up.
