A PE-backed MSO should standardize prior authorization follow-up by setting one cadence and escalation policy for every location, centralizing open-authorization visibility in a single queue regardless of EHR, and using automation to enforce the cadence while site staff handle exceptions. The goal of prior authorization follow-up standardization is simple: the same case gets the same attention at every practice in the group.
Why does prior authorization follow-up break down across an MSO?
When a management services organization acquires practices, it inherits their habits. One site tracks authorizations in a spreadsheet. Another relies on a veteran coordinator who keeps it all in her head. A third checks the payer portal "when things slow down."
Each approach can work at a single practice. Across a group, they produce inconsistent results that nobody can see. You can't tell whether a slow approval is a payer problem, a staffing problem, or a site that stopped checking on Tuesday.
The scale makes it worse. The AMA's 2024 prior authorization survey found practices complete an average of 43 prior authorizations per physician per week and spend more than 12 hours on them. Multiply that by dozens of providers across multiple sites and several EHRs, and prior auth follow-up becomes one of the biggest sources of hidden labor in the group.
What does a standardized follow-up policy look like?
Standardization starts on paper, before any software. Write down a one-page policy that every site follows. It should answer five questions:
- What is the follow-up cadence? For example, daily for urgent requests and every two to three days for standard requests.
- When does a case escalate? For example, no payer response within 48 hours on an urgent request, or any request past the payer's decision window.
- Who owns each exception type? Documentation requests, denials, and expiring approvals each get a named role.
- What gets recorded, and where? Status, reference number, decision date, and next action, in a consistent place.
- What counts as done? An approval entered in the chart and communicated to scheduling, not just an approval received.
The policy doesn't need to be perfect. It needs to be the same everywhere, so you can compare sites and improve it over time.
How do you get cross-location visibility when sites use different EHRs?
This is the hard part for most MSOs. Your sites may run eClinicalWorks, athenahealth, NextGen, and a couple of legacy systems, and none of them share a view of open authorizations.
You have two options. The first is to build reporting from each EHR and stitch it together. That can work, but it's slow, brittle, and dependent on whatever each EHR lets you export. The second is to put a layer above the EHRs: a single queue where every open authorization, regardless of source system, shows up with the same fields.
An automation layer gives you the second option almost as a side effect. When an agent tracks status for every open request, it has to keep a normalized record: payer, service, submission date, last status, next check, owner. That record is the group-wide view you've been trying to assemble by hand.
Ask any vendor you evaluate how it handles multiple EHRs. The right answer is that one configuration and one reporting view span the group, with site-specific connections underneath.
How do you handle payer variation across locations?
Payers behave differently by plan, by region, and sometimes by specialty. A national payer might have a good portal for one product line and a phone-only process for another. A regional plan might still require fax.
Don't try to write one rule per payer on day one. Start with your highest-volume payers across the whole group and map each one's channel, typical turnaround, and quirks. Typically a short list of payers covers most of your volume.
Pooling data across sites is one of the real advantages of operating as a group. If one payer takes nine days to decide at every site, you have evidence for a payer conversation that no single practice could bring. And with the CMS interoperability and prior authorization final rule requiring impacted payers to decide urgent requests within 72 hours and standard requests within 7 days beginning in 2026, you now have a benchmark to measure them against.
Should ownership be central or local?
Most MSOs land on a hybrid, and it's worth being deliberate about the split.
Centralize the policy, the tooling, and the reporting. One cadence, one set of exception rules, one dashboard. This is what makes the group comparable and lets you improve everywhere at once.
Keep the exceptions local when they need local knowledge. A coordinator at the site knows the surgeon who needs a same-day peer-to-peer and the patient who has been waiting three weeks. Those cases should route to the person at the site who can act on them.
Centralize the volume work. Routine status checks, deadline tracking, and expiration alerts don't need local knowledge. That's what automation takes over, and it's also where a central team or shared service can help sites that are short-staffed.
The split also protects you in transitions. When a site coordinator leaves, the policy and the queue stay in place instead of leaving with her.
How do you roll it out without disrupting staff?
Sequence matters more than speed. A rollout that works for most MSOs looks like this:
- Pick one or two sites with high authorization volume and a manager who wants the help.
- Baseline first. Count open authorizations, aged cases, and average days to decision before you change anything.
- Run the automation alongside existing work for a couple of weeks so staff can see what it catches.
- Move routine checks over, and keep staff on exceptions.
- Expand site by site, using the first sites' results to answer the next sites' objections.
Tell staff plainly what changes. They're not being replaced. They're being moved off portal logins and hold music and onto the cases where judgment matters. In groups that have seen heavy turnover in these roles, that message lands.
Which metrics should the MSO track?
Four numbers give you a group-wide view and a site-by-site comparison:
- Days from submission to decision, by payer and by site.
- Aged authorizations, meaning open requests past seven days for routine cases and past two days for urgent ones.
- Touches per authorization. How many times did a person have to handle each case?
- Care delays attributable to authorizations, such as rescheduled procedures.
Review them monthly with site leaders. The comparison between sites is where you find the next improvement, and where the best practices from your strongest coordinator can spread to everyone.
Platforms like Honey Health are built for this kind of group deployment. Its Prior Authorization agent tracks open requests, checks payer status on a schedule, and routes exceptions to the right person, so one workflow can run across locations on different EHRs.
Frequently Asked Questions
What is the first step in standardizing prior auth follow-up across an MSO?
Write a one-page policy covering cadence, escalation triggers, exception owners, what gets recorded, and what counts as done. Then baseline each site's open and aged authorizations so you can measure change.
Can one prior auth follow-up workflow work across different EHRs?
Yes, if the tooling sits above the EHRs and connects to each one separately. Ask vendors how they handle multiple EHRs and whether one reporting view spans all locations.
Should prior authorization follow-up be centralized or handled at each site?
Most MSOs use a hybrid. Centralize the policy, tooling, and reporting, and let routine checks be automated, while site staff handle exceptions that need local knowledge.
How do you measure whether standardization is working?
Track days from submission to decision, aged authorizations, touches per authorization, and care delays tied to authorizations. Compare them by site and by payer each month.
How long does it take to roll out across a group?
A pilot at one or two sites can start within weeks. Full rollout depends on the number of sites, EHRs, and payers, and goes more smoothly when you expand site by site.
