Quick answer: A PE-backed MSO can standardize missing patient data checks across multiple practices by setting one central required-data standard for each service line, applying automated detection at the intake layer above the individual EHRs, and reporting completeness by location. The standard lives with the MSO, the checks run the same way everywhere, and each practice resolves its own gaps against shared deadlines. That approach works even when no two acquired practices share an EHR.
Why is this harder for an MSO than for a single practice?
A single practice has one front desk culture and one EHR. An MSO has the opposite. Each acquired practice arrives with its own systems, its own intake habits, and its own idea of what counts as a complete referral.
One location may require a member ID and a recent note before scheduling. Another books first and sorts out coverage later. A third runs a different EHR where the insurance field is optional. None of them is wrong in isolation. Together they produce uneven patient experiences, unpredictable authorization delays, and a central team that can't tell which sites are leaking referrals.
The stakes rise with scale. Industry research cited by MGMA puts the share of faxed referrals that never become scheduled appointments at roughly 45%. Across a dozen locations, even a modest improvement in how many referrals are complete on arrival adds up to meaningful visits and revenue. And the AMA's 2024 prior authorization survey found physicians and staff spend about 13 hours a week on prior authorization, a burden an MSO multiplies across every site.
For a sponsor underwriting an integration plan, uneven front-end data quality is also a hidden drag on the synergies the deal assumed.
What is a central required-data standard?
A required-data standard is a short, written definition of what "complete" means for each type of inbound item, owned by the MSO rather than by any one practice.
Build it by service line, not by site. A cardiology referral, a dermatology new-patient visit, and an orthopedic authorization each need different information. Within a service line, every location applies the same definition.
A workable standard has four parts:
- Required fields: the minimum information needed to schedule or act, such as patient identifiers, coverage, referring provider, reason for referral, and urgency
- Supporting documents: the records required before a visit or authorization, such as recent notes, labs, or imaging
- Payer-specific rules: extra items that particular payers require for authorization
- Owners and deadlines: who resolves each type of gap, and how fast
Keep it short. A standard with dozens of fields turns every referral into an exception and gets ignored. Block work only on what you truly need, and treat the rest as helpful but optional.
Then give someone at the MSO ownership of it. Without a named owner, each practice quietly drifts back to local habits within a few months.
How do you apply the standard across different EHRs?
This is where most MSO efforts stall. Each EHR has its own fields, its own validation, and its own limits on what you can enforce. Trying to configure the standard inside every system is slow and fragile, and it never reaches the unstructured information that arrives as faxes and outside records.
The cleaner approach is to enforce the standard in a layer above the EHRs. Incoming faxes, referrals, and forms flow through a central intake layer that reads each item, extracts the fields, and compares them to the standard. Complete items route to the right location and write back into that practice's EHR. Incomplete ones go to a gap queue with the reason attached.
That gives you three advantages. The rules are written once and apply everywhere. New acquisitions plug into the same layer without rebuilding the standard. And you get a single view of completeness across locations, regardless of which EHR sits underneath each one.
The tradeoff is integration work. Cloud EHRs with open APIs connect faster. Epic and on-prem systems take longer because of interface work, and some older systems need desktop automation as a bridge. Plan the rollout in waves, starting with the sites that connect most easily.
Honey Health works as this kind of EHR-agnostic layer. Its referral intake and data fetching agents read inbound items, check them against requirements, and route or retrieve what's missing across different systems, which suits MSOs running mixed EHR environments. Any vendor you evaluate should be able to show how it handles your specific mix of systems.
Who should own gap resolution, the MSO or the practice?
Splitting this well prevents most of the friction.
Central ownership works best for work that benefits from scale and consistency: maintaining the standard, running the detection layer, handling payer-rule updates, and routing items to the right location. A central team can also take on gaps that don't need local knowledge, such as retrieving records or verifying coverage.
Local ownership works best for work that needs context: calling a referring office the practice has a relationship with, deciding how to handle an unusual patient situation, or scheduling around a provider's preferences.
A sensible default is central for detection and routine resolution, local for relationship-based and judgment calls, with shared deadlines applied to both. If a gap sits past its deadline, it escalates to a regional lead automatically.
Be explicit about this split during integration. Practice managers who feel the MSO is taking over their front desk will resist. Practice managers who see it removing busywork usually welcome it.
What should the completeness dashboard show?
Reporting is what turns a standard into a management tool. Without it, you can't tell which locations are following the standard or where gaps come from.
Track a small set of measures by location and service line:
- Percent of referrals complete on arrival. The cleanest measure of intake quality at each site.
- Days from arrival to complete. Watch the median and the long tail, since a few stuck items hide behind a healthy average.
- Gaps by source. Break down by referring office and document type to find the repeat offenders.
- Percent scheduled on first pass. This ties completeness to the outcome that matters.
- Staff minutes per gap. The number that supports the business case when you present results to the board or sponsor.
Review these monthly with regional operations leads, and use them to share practices across sites. If one location runs well ahead of the others, find out what it does differently and spread it.
How does this speed up integrating a newly acquired practice?
Standardization pays off most during onboarding. A newly acquired practice typically spends its first months untangling intake, with front-desk staff following legacy habits and no shared definition of complete.
With a central standard and an intake layer in place, onboarding becomes a defined sequence. Connect the practice's fax lines and referral channels to the intake layer. Map the practice's EHR so completed items write back correctly. Train staff on the gap queue and the escalation path. Start reporting completeness from week one.
That turns a vague "harmonize operations" goal into a checklist with dates. It also gives the sponsor early, concrete evidence of progress, because completeness data is available almost immediately rather than after a long process cleanup.
What does a phased rollout look like?
Trying to standardize every site and service line at once is the fastest way to stall. A phased plan keeps momentum and gives you proof before you scale.
Phase 1: Baseline and standard. Pick one or two service lines with high referral volume. Pull a sample of recent referrals from several locations and tag the gaps you find and where they came from. Draft the required-data standard with input from practice managers, and agree on owners and deadlines.
Phase 2: Pilot at two or three sites. Choose locations on different EHRs, since that tests the cross-system approach. Connect their intake channels to the detection layer, run it against live volume, and tune the rules. Hold weekly reviews of false positives and missed gaps.
Phase 3: Expand by wave. Add sites in groups, starting with the easiest integrations. Reuse the standard and the training materials. Report completeness to regional leads as each wave goes live.
Phase 4: Extend to new service lines and acquisitions. Once the pattern works, add service lines and make the intake layer a standard part of onboarding for every new practice.
At each phase, compare against the baseline from Phase 1. The comparison is what turns a project into a result you can show a board.
What change management hurdles should you expect?
The technology is rarely the hard part. Three people problems show up repeatedly.
Local resistance. Established practices have their own ways of working and may see central standards as a loss of autonomy. Involve practice managers in drafting the standard, and show them the gaps their own data reveals.
Standards that are too rigid. A single standard across every service line and payer will fail. Build in room for service-line differences and a clear process for requesting changes.
Underinvesting in the exception queue. Automation shifts work from reading every item to resolving exceptions, which means the gap queue needs real owners and capacity. Staff it from the time savings elsewhere, and measure whether it's keeping up.
Plan for a tuning period of several weeks per wave. Expect false positives early, and have a quick way for practices to flag rules that don't fit.
Frequently Asked Questions
How can a PE-backed MSO standardize missing patient data checks across practices?
Set one required-data standard per service line, enforce it with automated detection at a central intake layer above the individual EHRs, and report completeness by location. The MSO owns the standard, while practices resolve local gaps against shared deadlines.
Do all practices need to be on the same EHR?
No. A central intake layer sits above the EHRs, reads incoming items, applies the same standard, and writes completed information back into each practice's system. That makes it suitable for MSOs with mixed EHR environments.
Who should own the required-data standard?
The MSO should, usually through a named operations or revenue cycle leader. Without clear ownership, practices drift back to local habits. Involve practice managers in drafting it so it fits real workflows.
How long does it take to roll out across locations?
It depends on each site's EHR and number of channels. Cloud EHRs with open APIs connect faster, while Epic and on-prem systems take longer. Most MSOs roll out in waves, starting with the easiest sites and expanding.
What metrics should we show the board or sponsor?
Percent of referrals complete on arrival, days from arrival to complete, percent scheduled on first pass, and staff minutes per gap, all broken out by location. Together they link front-end data quality to throughput and cost.
