Quick answer: You centralize prior authorization across an MSO by moving submission, status tracking, and payer rule logic to a shared platform while leaving clinical context (the actual request, attached chart data, peer-to-peer escalations) inside each practice's existing EHR workflow — so practice managers see less PA burden, not a new tool to learn. The operational pattern that works pairs centralized AI processing of routine PA volume with embedded specialty coordinators at each practice handling judgment cases, rolled out phased rather than all-at-once.
Why centralizing PA is operationally harder than centralizing other workflows
PA centralization sounds straightforward — pull every practice's PA work into a shared service org, run it from one team, capture economies of scale. Most MSO COOs who've tried it know the operational reality is different. PA is the workflow most coupled to the practice's clinical context, the provider's documentation patterns, the local payer relationships, and the patient-facing scheduling workflow. Moving that work to a central team without breaking the local practice's operations is a real design problem.
The friction shows up in four predictable places. Practice managers at each acquired location lose visibility into PA status and start fielding patient calls they can't answer. Providers start hearing "I don't know — that's central's responsibility now" from staff who used to own the workflow. Local clinical staff lose informal communication channels with the practice's longest-tenured PA coordinator, which is where most of the institutional payer knowledge actually lived. The MSO's central team becomes a bottleneck for every escalation, and the per-PA TAT gets worse before it gets better.
These problems aren't theoretical. The AMA's 2024 prior authorization physician survey reports that 94% of physicians say PA delays patient access to care and 93% see negative clinical outcomes. A centralization rollout that drags TAT in the first 90 days isn't an operational hiccup — it's a clinical impact issue that drives provider pushback at the practices the MSO acquired.
The good news is that centralized PA does work at MSO scale. The hard part is the operational design, not the technology. The rest of this article walks through the patterns that work, the sequencing that protects each practice's workflow, and the change-management discipline that earns the local team's trust.
The operational case for centralization
Before sequencing the rollout, it helps to be specific about what centralization actually delivers. Three operational gains drive most of the ROI math.
Per-PA cost drops as volume consolidates. The 2024 CAQH Index puts manual PA at $10.97 per request versus $5.79 electronic. Centralization compresses the gap further because the central team's per-PA labor cost drops as the team specializes and the AI absorbs the routine work. A typical 10-site MSO captures 25–40% labor recovery on PA work within 12 months of full centralization.
Denial-rate variance flattens across practices. Pre-centralization, the cardiology group's first-pass approval rate might run 88% while the dermatology group's runs 71% — not because dermatology is harder, but because the local team's institutional knowledge of payer rules and documentation patterns varies. A central team with shared rule library and AI-driven clinical extraction lifts the underperforming practices toward the top performers, recovering the rework cost on the gap.
Staff burnout drops at every practice. PA work is one of the most-cited drivers of front-desk and admin burnout. Centralization moves the routine submission and status-polling work off the local team, which redeploys local staff hours to higher-leverage work and reduces the per-coordinator burnout load. Practices that adopt this model typically see their PA coordinator turnover drop by half within 18 months.
These three gains are real. The rollout pattern that captures them without breaking each practice's workflow is the harder problem.
What to centralize and what to leave decentralized
The single most consequential design decision in a PA centralization rollout is the line between what moves to the central team and what stays with the local practice. Get this line wrong and either the local team loses too much context (and patient outcomes drift) or the central team gains too little scope to capture the operational benefits.
The pattern that works at most MSOs splits the workflow this way:
Centralize:
- Payer-rule lookup and rule-library maintenance across the MSO's full payer footprint
- Initial PA submission across all channels (ePA 278, portal, fax)
- Status polling and follow-up across all open PAs
- Aggregated reporting and analytics by practice, specialty, and payer
- Standardized escalation paths for aged or stuck PAs
Leave decentralized:
- Clinical judgment on whether a peer-to-peer is worth pursuing
- Direct communication with the local provider on cases needing additional documentation
- Local payer relationships built over years (these don't transfer well)
- Urgent or stat PA escalations that need same-day local decision-making
- Patient-facing communication when a PA decision affects a scheduled visit
The split lets the central team capture scale on the repetitive 75–85% of PA volume while preserving the clinical and relational context at each practice that drives the remaining cases. Practice managers at the local sites should feel like the platform removed the most painful 80% of their PA workload, not like central operations took over their workflow.
A phased rollout pattern that protects each practice
The biggest single rollout failure mode is trying to centralize all PA work at all practices in one move. The teams aren't ready, the platform's payer-rule library hasn't tuned to each practice's mix yet, and the local change management hasn't happened in parallel. Practices revolt within 60 days, and the rollout either reverses or limps along producing none of the projected savings.
The pattern that works at most MSOs is a three-phase rollout:
Phase 1 — Pilot on one specialty at one practice (weeks 1–6). Pick the specialty and practice combination with the cleanest payer mix and the most willing local team. Run the centralized workflow on real production traffic with the local team continuing to see every PA the central team handles. Tune the AI to the practice's specific documentation patterns and payer rules. Build local trust through visible accuracy and faster TAT before expanding.
Phase 2 — Expand to one EHR across multiple practices (weeks 6–14). Once the pilot is delivering on TAT and first-pass approval rate, expand to other practices on the same EHR. Most of the integration work is already done; the per-practice ramp is shorter (typically 2–3 weeks per practice). Continue running shadow review for the first two weeks at each practice before flipping to full central handling.
Phase 3 — Add remaining EHRs and practices (weeks 14–28). With the centralized workflow proven across the same-EHR cohort, add the other EHRs in the MSO's portfolio. Each new EHR requires its own integration work (4–14 weeks per EHR depending on cloud vs on-prem). Layer practices on as the EHR integration goes live.
By month 6, most MSOs running this pattern have centralized 60–80% of PA volume. By month 9–12, the rollout is typically complete with all practices on the centralized workflow.
Honey Health's Prior Authorization agent is built around this phased pattern — multi-tenant from day one, multi-EHR by architecture, with central AI processing that adapts to each practice's documentation patterns during the pilot phase before expansion.
The integration patterns that make mixed-EHR centralization work
Most MSOs inherit heterogeneous EHRs through acquisition, and the technical question is whether the centralization platform handles this natively or forces EHR consolidation. Forcing consolidation as a precondition is the path that takes 18 months and usually fails. The pattern that works operates above the EHR layer.
Three integration patterns cover the typical MSO portfolio:
- Cloud-native EHR API integration for athenahealth, NextGen Office, eClinicalWorks cloud, and Elation. Implementation runs 4–6 weeks per practice. The central platform reads patient demographics and clinical context through the EHR's APIs and writes PA results back into the chart with structured metadata.
- HL7 + interface engine integration for Epic and on-prem deployments of eClinicalWorks, NextGen Enterprise, and MEDITECH. Implementation runs 8–14 weeks per practice because per-deployment configuration is unavoidable. The platform's central processing handles the AI workflow; the interface engine bridges to the EHR's database layer.
- Desktop automation bridging for legacy specialty EHRs without modern integration points. Implementation runs 4–8 weeks. The platform's agent operates the legacy EHR through the same UI screens local staff use, writing PA documentation into the appropriate chart sections.
The vendor evaluation question worth pressing on isn't "do you integrate with our EHRs?" — every vendor says yes. The right question is which specific EHR-and-deployment-pattern combinations the vendor has shipped at production scale at multi-EHR MSO customers, with named references. Strong vendors have answers grounded in production deployment history; weak vendors retreat to roadmap promises.
Change management that earns each practice's trust
The technology integration is usually well-resourced. The change-management piece at each acquired practice is usually under-resourced, which is why most rollouts that fail fail on the human side rather than the technical side.
Three change-management practices work consistently:
Name a single contact at the MSO PA hub for each acquired practice. Not the vendor's customer success rep — a person on the MSO's central PA team whose job is to be the named contact for that specific practice. When the local team has a question about a stuck PA or an unusual case, they call the named contact. The technology handles the workflow; the named contact handles the relationship.
Run a 30-60-90 review with each practice's office manager. At 30 days, 60 days, and 90 days post-go-live at each practice, the MSO's PA team lead walks through the data with the local office manager — what's working, what isn't, which cases are still causing pain. Most local concerns surface in this review before they become formal escalations, and the review itself is what builds trust that central operations is listening rather than dictating.
Don't shift local PA coordinator roles until the centralized workflow is stable. Pre-centralization, the local PA coordinator team is the safety net. Telling them their roles will change before the central team has proven it can carry the work is what generates resistance. After the centralized workflow is delivering on TAT and approval rate, the role shift becomes obvious and the conversation is easier. Some practices retain a local PA coordinator for peer-to-peer and urgent cases; others redeploy that role to denial follow-up or patient outreach.
Frequently asked questions
How long should the full PA centralization rollout take across an MSO?
For a 5–10 site MSO with mixed EHRs, plan for 6–9 months end to end. The first pilot site reaches full centralization in 6–8 weeks. Subsequent same-EHR practices layer on at a 2–3 week cadence each. Adding new EHRs adds 4–14 weeks each depending on cloud vs on-prem. Larger MSOs (20+ sites) typically run multi-quarter rollouts with the highest-volume practices going first.
How do we handle practices that resist centralization?
Start with the willing practices. Build a track record of TAT and approval-rate wins at the first 2–3 sites, then approach the resistant practices with data rather than mandate. Most resistance is about loss of control rather than disagreement with the operational goal — when the local team sees that centralization removed their most painful workflow without removing their patient-facing influence, the resistance usually softens. Mandating centralization at a resistant practice before the track record is built is the move that breaks rollouts.
What happens to the local PA coordinator team after centralization?
Most MSOs redeploy local PA coordinators rather than reduce headcount. The recovered hours go to denial follow-up, patient outreach, appeal work, and peer-to-peer coordination — work the central team can't do because it requires local context and relationships. Some practices retain a part-time local PA coordinator for stat escalations and provider liaison work. The financial case typically works better when the hours redeploy into revenue-positive local work that compounds the centralization ROI.
How do we handle peer-to-peer requests in a centralized model?
Peer-to-peer requests need the local provider's clinical judgment. The pattern that works routes peer-to-peer cases back to the originating practice with the central team's prep work attached — payer rule context, prior submission history, the specific clinical question the payer is raising. The provider takes the call from their own location with full context, rather than the central team trying to coordinate a call between a provider they don't work with and a payer they don't know.
What reporting should each practice's office manager see after centralization?
Each practice's office manager should see practice-level rollups on the same metrics the MSO sees centrally — first-pass approval rate by payer and procedure, TAT distribution, aged-PA exposure at the practice. The local view tells the office manager where the local payer mix or provider documentation patterns are driving variance from the MSO average. This is what makes the office manager an operational partner in the centralized workflow rather than a passive recipient of central operations decisions.
