For a PE-backed MSO, prior authorization packet assembly software works as a layer above your EHRs. It applies one packet standard and one payer-rule library to every practice, pulls documents from each EHR and from inbound faxes, builds the packet in a consistent format, and routes exceptions to a central team. You don't migrate anyone to a single EHR to get there.
Why is prior authorization packet assembly harder for an MSO?
A single practice has one EHR, one front office, and one way of doing things. An MSO has several of each. After a few acquisitions you might run three or four EHRs, with different note templates, different fax habits, and a prior auth process that lives in the heads of whoever has been at each location the longest.
The work itself is the same everywhere. The AMA's 2024 prior authorization survey found physicians and their staff handle an average of 39 prior authorizations a week, about 13 hours of work. Multiply that across dozens of providers and several locations and the staffing cost becomes a board-level number.
The harder problem is inconsistency. Location A builds a clean packet for a lumbar MRI. Location B sends the same request with a missing therapy note and gets a denial. Nobody at the MSO level can see why, because the process isn't standardized and the data sits in separate systems.
What does "a layer above your EHRs" actually mean?
It means the packet assembly tool doesn't replace any EHR. It connects to each one, reads what it needs, and applies the same logic everywhere.
In practice that layer does four things:
- Reads from each EHR. It pulls diagnoses, visit notes, orders, labs, and medications through whatever connection each system supports.
- Reads inbound documents. Faxed referrals, outside imaging reports, and scanned records come in through the same channel for every location.
- Applies one rule set. For each payer and procedure, the same list of required documents is checked, regardless of which practice the request came from.
- Produces one packet format. Staff at every location review the same kind of finished packet with the same checklist.
This is a standardization play first and an automation play second. Automation without a standard just makes inconsistent work faster.
How do you handle different EHRs without migrating?
Ask any vendor how it connects to each EHR you run, one by one. Some systems offer modern APIs. Others need a different route, such as a connection to the document store or a structured export. A vendor that has worked with a mix of systems will tell you plainly which connection type each one needs and what limits come with it.
Honey Health's Prior Authorization and Data Fetching agents are built to work this way: the Data Fetching agent retrieves records and chart data from the EHR a location already uses, and the Prior Authorization agent assembles the packet for staff review. The point for an MSO is that the packet comes out the same way whether the source was one EHR or another.
Two cautions. First, the depth of the connection varies by system, so confirm what's read-only and what's writable before you commit. Second, expect the first connection at each EHR to take real effort. The second location on the same EHR is usually much faster.
How do you normalize documents from different systems?
Each EHR names things differently, formats notes differently, and stores attachments differently. Normalizing means mapping all of that to one internal structure so the payer rules can run against it.
A workable approach looks like this:
- Define the packet standard. For each of your top procedure and payer pairs, list the exact documents and data points required.
- Map each EHR's fields to that standard. A visit note type that's called one thing at one location and something else at another should land in the same slot.
- Handle unstructured records. Faxes and scanned PDFs need to be read, classified, and attached to the right patient and request, whatever location they arrived at.
- Test on real packets from each location. Compare the output to what staff built last month and fix mismatches before going live.
Documentation habits matter here too. If providers at one location don't document conservative treatment, the software will flag it every time, and that's useful: it shows you where training will improve approval rates across the group.
What does governance look like for payer disputes?
At MSO scale, you need to prove what you sent. When a payer says a document wasn't included, or a denial goes to appeal, someone has to produce the packet exactly as it went out.
Ask about four things:
- Audit trail. What was included, when, by whom, and from which source system.
- Rule versioning. Which version of the payer rule applied when the packet was built.
- Access controls. Who at which location can see which patients' packets, consistent with HIPAA and your business associate agreement.
- Change ownership. Who updates payer rules when a policy changes, you or the vendor, and how you're notified.
A central team should own the rule library. Locations shouldn't each maintain their own version, because that's how the inconsistency comes back.
How do you roll it out practice by practice?
Don't switch everything on at once. A staged rollout gives you clean comparisons and limits risk.
Start with one location and one payer set. Pick a location with a typical EHR and a steady prior auth volume. Run the new process on its top procedure and payer pairs.
Run in parallel for a short period. Have staff build a sample of packets the old way and compare. This builds trust and finds rule gaps.
Add locations by EHR. Once the first connection works, roll out to other locations on the same EHR, then move to the next system.
Centralize exceptions early. Create a small central team, or name a coordinator at each location, who handles flagged packets and clinical judgment questions. Routine, complete packets go through with a quick review.
A rollout that goes location by location also gives your integration team something concrete to measure at each step.
What does a standardized packet look like in practice?
Take a lumbar MRI request that comes in from three locations on three different EHRs. Before standardization, location A attaches a visit note and imaging history. Location B attaches only the order. Location C includes a note, but not the physical therapy record the payer asked for. Each location thinks it's doing the job correctly, because nobody has written down the shared requirement.
After standardization, all three requests run through the same checklist: a recent visit note documenting symptoms, a record of conservative treatment, prior imaging if any, and the correct diagnosis and procedure codes. The software finds each item in the source EHR or in the inbound records, assembles the packet in the order the payer expects, and flags the missing therapy record at location C before submission.
The coordinator at location C sees the flag, requests the record, and the packet goes out complete. The central team sees the same gap pattern appear at that location three times in a month and schedules a documentation fix with the providers there. That feedback loop is the real value for an MSO: one process, visible across every site.
How does this fit with the rest of your prior auth workflow?
Packet assembly is one stage. Eligibility and benefits verification come before it, and submission, status tracking, and appeals come after. Many MSOs start with assembly because it's the most labor-intensive stage and the easiest to measure.
Plan for hand-offs. The answer to "does this service need authorization?" should flow into the packet process without anyone re-keying it, and the decision that comes back should flow to scheduling and billing at each location. Ask vendors how the tool passes information to the stages on either side, and which of those stages the product covers itself.
Which metrics should an MSO track?
Pick a small set and report it by location, so you can see where the standard is working and where it isn't:
- First-pass approval rate. The share of requests approved without additional information requests or denials.
- Turnaround time. Days from order to submission, and from submission to decision.
- Staff hours per packet. Minutes of coordinator time, measured before go-live and after.
- Gap flag rate. How often the software finds missing documentation before submission, by location and provider.
- Exception volume. The share of packets that need hands-on work, which should fall as rules improve.
Baseline these before you start. Most MSOs have never measured packet assembly time by location, and the first surprise is often the spread between the best and worst site.
What are the common mistakes?
A few come up often in multi-site rollouts.
- Treating each location as its own project. You lose the standardization benefit and multiply the effort.
- Skipping the baseline. Without before numbers, you can't show the investment committee a result.
- Letting local rule variations creep in. One rule library, centrally owned.
- Pulling human review too early. Let the software earn trust over several weeks, then reduce checks.
- Ignoring provider documentation. No tool can invent a missing therapy note.
Frequently Asked Questions
Can prior authorization packet assembly software work across different EHRs?
Yes. The software connects to each EHR a location uses and applies one packet standard and one payer-rule library to all of them. The depth of each connection varies by EHR, so confirm what each integration reads and writes before you sign.
Do we need to move all practices onto one EHR first?
No. A standardization layer above the EHRs is meant to avoid that. Migrating EHRs is expensive and slow, and packet assembly doesn't need it. Look for tools that work alongside the systems you already run.
Who should own the payer rules in an MSO?
A central team. Locations shouldn't maintain separate rule sets, since that recreates the inconsistency you're trying to remove. Confirm whether your vendor or your team updates rules when payers change policy.
How long does a multi-location rollout take?
It depends on the number of EHRs, locations, and payers. Plan a staged rollout that starts with one location and its top procedure and payer pairs, then adds locations by EHR. Ask vendors for a timeline based on your actual mix of systems.
What does an MSO need to prove in a payer dispute?
You need the exact packet that was sent, what it contained, when it went out, and which payer rule version applied. Ask each vendor how its audit trail records this, and whether you can export it for an appeal.
