Quick answer: Prior authorization software for MSOs is a centralized platform that submits, tracks, and manages PA requests across multiple affiliated practices, specialties, and payer mixes from one operational hub — rather than each practice running its own tool in isolation. It differs from single-practice PA tools in three core ways: a multi-tenant data model that handles different EHRs across acquired sites, a cross-practice workqueue that lets a shared PA team handle volume from any location, and consolidated reporting that gives MSO operations visibility into PA performance across the network.
Why MSOs can't just deploy single-practice PA tools at every site
The instinct, when an MSO acquires its third or fourth practice, is to replicate whatever PA tool the largest practice uses across the rest of the portfolio. It rarely works. The economics of a single-practice PA tool assume one EHR, one stable payer mix, one PA coordinator team, and one set of provider documentation patterns. An MSO running a dozen affiliated practices breaks every one of those assumptions.
Most MSOs inherit heterogeneous EHRs through acquisition. The cardiology group runs Nextech. The dermatology group is on athenahealth. The recently-acquired GI group kept eClinicalWorks because the migration cost wasn't worth it. The MSO hub runs NextGen. A PA tool deployed at the cardiology group's Nextech instance doesn't write structured PA data back into the derm group's athena chart — and forcing every acquired practice onto the same EHR as a precondition to PA automation is the project that takes 18 months and usually fails to land the savings.
The PA volume distribution also breaks the single-practice model. A single-practice tool assumes the PA coordinators are part of the practice's local team. At MSO scale, the operational answer is often a shared PA pod that handles volume from every affiliated practice — which means the tool has to route work across practices, surface workqueues by specialty rather than by location, and let the central team flex across the portfolio without losing the specialty nuance that gets PAs approved on first pass.
The reporting layer is the third break point. MSO leadership needs per-specialty, per-site, per-payer rollups across the whole network. Single-practice tools ship reports designed for one practice's PA workflow, which means MSO operations is either manually aggregating reports from a dozen tools or flying blind on cross-portfolio performance. Neither produces actionable decisions.
PA software built for MSOs solves all three problems by sitting above the EHR layer, not inside any single one.
The four architectural differences that matter
Strip away the marketing language and four architectural differences separate PA software built for MSOs from single-practice tools retrofitted to multi-site deployments.
Centralized payer rule libraries. A single-practice tool maintains the payer-rule library for that practice's specific payer mix. An MSO platform maintains rule coverage across the union of every affiliated practice's payers — typically 200+ payers across a 10-site MSO portfolio. The depth matters because each acquired practice brings new payer contracts, new state-specific Medicaid rules, and new commercial plans the central library has to absorb. Per the 2024 CAQH Index, manual PA costs $10.97 per request versus $5.79 electronic — the gap widens at MSO scale because payer-rule coverage breadth is what determines which side of that math each PA lands on.
Multi-tenant data model. Every PA in the system carries entity attribution — which practice the PA belongs to, which EHR the clinical context lives in, which payer contract applies, which provider ordered the service. The central team sees the full network's workqueue; each practice sees only its own. Audit trails and compliance reporting stay clean even when the same PA coordinator handles cases from multiple practices.
Cross-practice workqueues. PA work routes to whoever has the right specialty expertise and capacity, not whichever location the PA originated at. A surge in cardiology PAs at one acquired practice doesn't require local backfill if the central team has cardiology coordinators available. The platform handles the assignment logic and tracks per-coordinator performance across the network.
Consolidated MSO-scale reporting. Three reports drive operational decisions at the MSO level: per-specialty first-pass approval rate broken out by payer and procedure, per-site TAT distribution for routine and complex PAs, and aged-PA exposure rolled up across the portfolio. The platform ships these out of the box with drill-down to the individual PA, which is what makes MSO operations capable of acting on the data rather than just reporting on it.
How the shared-service PA model becomes viable
Most MSOs try to centralize PA at some point and discover that the operational pattern is harder than the technology pattern. The shared-service PA model — one PA pod working across every affiliated practice — only works if the platform handles the routing, payer-rule lookup, and EHR write-back across the network. Without that, the central team becomes the bottleneck the MSO was trying to eliminate.
The platform's job is to make the centralized model invisible to clinical staff at each practice. The cardiologist at the cardiology practice writes an order in Nextech. The PA shows up in the central PA pod's workqueue with the patient's clinical context already pulled, the right payer rule applied, and a draft submission package ready for review. The PA coordinator reviews, approves, and submits — the same workflow they'd run at a single practice, except the submission, status tracking, and reporting all happen at the central layer.
Three operational patterns work at MSO scale:
- Centralized AI processing of routine volume, with embedded specialty coordinators handling the judgment cases (peer-to-peers, novel payer policies, complex denials). The platform owns the queue mechanics; the specialty coordinators own the cases that need their clinical context.
- Phased rollout starting with one specialty or one EHR before expanding across the portfolio. Trying to flip every acquired practice to the new platform at once is the move that breaks rollouts; sequential rollout lets each site's lessons feed into the next.
- Single named contact at the MSO PA hub for each acquired practice, so trust doesn't break when the local team's PA work moves to a central pod. The technology handles the workflow; the named contact handles the relationship.
Honey Health's Prior Authorization agent is built for this MSO operating pattern — multi-tenant by default, multi-EHR by architecture, and designed for centralized AI processing with embedded specialty review.
The integration story across heterogeneous EHRs
The single biggest technical question at MSO scale is whether the PA platform handles heterogeneous EHRs natively or forces consolidation. Forcing every acquired practice onto the same EHR before deploying PA automation is the path that takes 18 months, costs $1M+ in migration services, and usually fails to land the operational improvement the MSO was trying to capture.
The integration patterns that work operate above the EHR layer. Central PA intake and AI processing happen at the network level, regardless of which EHR each site runs. Write-back fans out to each site's existing system through whatever integration mechanism fits — APIs for cloud-native EHRs, HL7 v2 messaging through interface engines for on-prem deployments, desktop automation for legacy specialty EHRs that don't expose modern integration points.
Typical implementation cadence at a 5–10 site MSO with mixed EHRs:
- Cloud-native EHRs (athenahealth, NextGen Office, Elation, eClinicalWorks cloud) reach go-live in 4–6 weeks per site through native APIs.
- Epic deployments run 8–12 weeks per site because the integration combines HL7 v2 messaging with Bridges or Connection Hub for document filing.
- On-prem deployments (NextGen Enterprise, eClinicalWorks on-prem, MEDITECH) run 10–14 weeks per site because per-deployment interface engine configuration is unavoidable.
- Legacy specialty EHRs without modern integration points get bridged through desktop automation in 4–8 weeks.
The vendor question worth pressing on isn't "do you integrate with our EHRs?" — they'll all say yes. The right questions are which specific deployment patterns the vendor has shipped at production scale, what the per-site timeline looks like, and what the path is for the long-tail specialty EHRs the vendor hasn't shipped at before. Vendors with answers grounded in production deployment history are the ones worth piloting; vendors that retreat to roadmap promises are the ones whose timelines slip post-contract.
The honest failure modes worth naming
No PA platform — MSO-scale or otherwise — handles every case automatically. Three failure modes are worth being honest about during vendor evaluation.
Peer-to-peer cases. A meaningful share of PAs end up in peer-to-peer review where a clinician at the practice has to call a payer's medical director to discuss the case. The platform can route the case, pre-populate the clinical context, and track the outcome — but the actual call still needs a human. Most platforms handle 70–85% of PA volume straight-through; the remaining 15–30% involves peer-to-peers or complex appeals where the platform's role is workflow support, not decision automation.
State-specific Medicaid quirks. Medicaid managed care plans vary by state, with each state's policies updating on their own schedule. Even mature payer-rule libraries occasionally lag the latest state Medicaid update, particularly for newer specialty drugs or recently-added procedure codes. Strong platforms surface rule-library staleness as a flag rather than silently submitting against an outdated policy.
Brand-new specialty drugs. Novel biologics, gene therapies, and recently-approved specialty drugs often don't have stable payer policies yet — payers are still building their utilization-management protocols in real time. The platform can flag these cases as low-confidence and route them to the PA team for manual handling; what it can't do is invent a stable rule library where the payer doesn't have one.
These limits aren't reasons to skip PA automation. They're reasons to require the vendor to be specific about exception handling, surface flag rates honestly, and design the workflow so the exceptions get to the right human quickly rather than getting lost.
Frequently asked questions
Does an MSO need to consolidate EHRs before adopting PA software?
No, and trying to is usually the wrong sequence. The PA platforms built for MSO operations sit above the EHR layer with central processing and per-site write-back into each acquired practice's existing system. EHR consolidation is a separate, much larger decision that's almost never worth bundling with PA automation. The platform handles the heterogeneity natively; the MSO captures the centralization benefits without the multi-year migration project.
Can a single PA tool really handle multiple specialties at MSO scale?
Yes, if the platform was built for it. Multi-specialty PA software runs specialty-specific payer-rule libraries (cardiology imaging policies, ortho surgical authorizations, derm biologics, oncology infusions) in parallel, with content-based routing that reads the actual PA request and applies the right specialty's logic. Single-practice tools retrofitted to multi-specialty MSO use rarely handle the cross-specialty routing well, which is why architecture matters more than feature checklist comparisons.
How does MSO PA software handle the shared PA pod vs embedded coordinator decision?
The shared-service model works well for the routine 75–85% of PA volume where the workflow is repetitive and benefits from scale. The embedded model works better for the judgment cases — peer-to-peers, novel payer policies, complex appeals — that need specialty expertise and local clinical context. The hybrid that works at most multi-specialty MSOs is centralized AI processing of routine volume with embedded specialty coordinators for the judgment cases. The platform owns the queue mechanics; the specialty coordinators own the cases that need their clinical context.
How long does PA platform implementation take across a 10-site MSO?
Plan for 3–6 months end to end. The first site reaches go-live in 4–8 weeks depending on EHR pattern. Subsequent sites layer on at a 2–4 week cadence each once the platform is configured for the MSO's routing logic and rule library. Larger MSOs (20+ sites) typically run multi-quarter rollouts with the highest-volume sites going first. The biggest variable is EHR mix — MSOs running primarily cloud-native EHRs move faster than MSOs with significant Epic or on-prem footprints.
What reporting should MSO leadership expect from the platform?
Three reports drive operations decisions at MSO scale: per-specialty first-pass approval rate broken out by payer and procedure type, per-site TAT distribution for routine and complex PAs, and aged-PA exposure rolled up across the portfolio. These reports surface where the rule library is leaking, which sites have provider documentation patterns that drag TAT, and where the largest aged-PA revenue is at risk. Platforms that ship these out of the box with drill-down to the individual PA produce the actionable operations decisions MSO leadership needs.
