Four Ways to Run a Multi-Entity Practice Group. Only One Is a Decision.

Every healthcare group that grows by acquisition ends up in one of four architectures. Three of them are chosen. The first one isn’t — you arrive there by not choosing, which is exactly why most groups are in it.

This is no longer a niche problem. Eighty-two percent of U.S. physicians are now employed by hospitals, private equity firms, insurers, or other corporate entities, and non-physician ownership covers 63.9% of practices, up from 29.8% in 2018.¹ In 2024–2025 alone, corporate entities acquired 8,000 practices — more than hospitals did.¹ Every one of those transactions created the problem this article is about.

And the stakes are concentrated exactly where most integration plans put the least attention: Deloitte estimates that IT accounts for up to 70% of expected synergies in healthcare mergers and acquisitions.² The systems question isn’t a downstream consequence of the deal thesis. In most deals, it is the deal thesis.

Understanding which one you’re in, and which one you’re heading for, turns out to matter more than almost any other operational decision a consolidating group makes. It determines how fast an acquisition contributes cash, what your reporting can tell you, and whether the next deal gets easier or harder than the last one.

The baseline: many-to-many

You buy a practice. It arrives with its own EHR, its own billing system, its own clearinghouse relationship, and its own definition of what “outstanding” means on an aging report. You leave it alone, because everyone is busy and nothing is on fire.

Buy three more, and you own five of everything.

This isn’t a topology anyone selects. It accumulates. And it persists through three or four acquisitions for a reason that’s worth stating plainly: it has no implementation cost, and its running cost never appears as a cost.

There’s no line item for many-to-many. Nobody proposes it, nobody defends it, nobody has to get it approved. It shows up in the numbers as a rising DSO, an aging report with half the balance past 120 days, and a net collection rate nobody can fully explain. Every alternative has a visible price tag and a champion who has to justify it. The baseline has neither, so it wins by default.

What it actually costs:

• No enterprise truth. “What is our net collection rate?” requires exporting five systems and reconciling by hand, which means it gets answered monthly at best and trusted rarely.
• No accumulated payer knowledge. Five entities billing the same payer produce five separate accumulations of institutional knowledge, four of which are worse than the best one.
• Silent yield leak. Claims that were never denied — just never paid — sit unworked, because no rejection ever routed them to a queue. Nobody owns them because no system has a state for “pending indefinitely.” MGMA estimates that 50% to 65% of denied claims are never reworked at all, at an average rework cost of roughly $25 per claim.³ That’s the industry baseline for practices running one system. Across five, nobody has ever measured it, which is itself the point.
• Degrading deal velocity. Each acquisition makes the next one harder rather than easier. That’s the opposite of what a platform is supposed to do.

The numbers on acquired practices specifically are worse than the general benchmarks. MGMA’s 2024 Cost and Revenue Survey puts the median physician practice at 47 days in A/R, with better performers at 36.⁴ Newly acquired practices commonly carry 28% to 35% of total A/R in the 90-plus-day bucket against an 18% to 22% benchmark — and collection probability drops below 65% past 120 days and below 41% past 180.⁵ Charge capture leakage in acquired practices runs 0.5% to 2% of net patient revenue, with credentialing leakage adding another 0.3% to 1%.⁵

Meanwhile the denial rate that generates all of this hasn’t moved. MGMA’s DataDive Practice Operations data set showed a single-specialty aggregate first-submission denial rate of 8% — the same rate documented five years earlier.⁶ The problem isn’t getting worse. It’s that consolidation multiplies the number of places it can hide.

The three real options are all ways out.

Two of them share a structure worth naming, because it comes up constantly in these conversations and there’s no good vocabulary for it. In both, one system serves as the hub for many entities — many tax IDs, many locations, many practices that were separate companies eighteen months ago — while a second layer stays distributed. Each entity keeps its own data, its own permissions, its own fee schedules, its own reporting identity. What they share is the machinery: the payer rules, the claim edits, the denial patterns, the credentialing workflows, the appeal templates. We call this Multi-Tenant Single-Platform, or MTSP — multi-tenant because every entity remains a distinct business with its own isolated record, single-platform because they all run on shared operational infrastructure rather than parallel copies of it. That combination is the point: isolation where the business needs it, sharing where the economics need it. A rule learned about a payer in one entity applies in every entity billing that payer, without anyone rekeying it. Note what MTSP is not — it is not many-to-many. There is always exactly one hub. Which layer serves as that hub is the decision, and it is the only real decision in this architecture.

Option A: one EHR, multiple RCM

Consolidate the clinical system of record. Leave billing distributed.

Integration is easiest here. One stable, well-documented source feeds outward. It’s 1→N, and critically, the 1 is under your control. Adding a billing vendor means adding one consumer to an existing feed.

Implementation is expensive. Every entity’s clinical documentation has to migrate — historical records, active authorizations, appointments already on the books, clinicians relearning how to chart. Cost scales with provider count, not entity count, which means it grows faster than most people budget for.

The most-cited figure comes from a Health Affairs study of a typical five-physician practice: $162,000 in implementation and $85,500 in first-year maintenance.⁷ The productivity cost is better documented than most vendors admit, and — usefully — less catastrophic than the marketing suggests. AHRQ’s study found RVUs 8% lower during the first six months following implementation, recovering to 4% below baseline by twelve months, with ongoing maintenance at roughly $1,650 per physician FTE per month.⁸ Vendor sources routinely claim 10% to 20% volume reductions for 30 to 90 days; the peer-reviewed number is smaller and longer.

Both directions matter. An 8% RVU decline across a 200-provider group is a serious number. It is also survivable, recoverable, and — critically — a one-time cost rather than a recurring one.

Maintenance is the weak point. One EHR to maintain, but N billing relationships, N contracts, N sets of performance standards, N accumulations of payer knowledge that never compound into one. Reconciliation across vendors is permanent overhead, and vendor management grows with every deal.

Choose it when clinical compliance and audit exposure are the dominant risk and you need one documentation standard immediately.

The cost of choosing it: you consolidated the expensive-to-change layer and left the cash layer fragmented. Revenue visibility still requires manual work. It’s the worst starting position for the next acquisition.

Option B: one RCM, multiple EHR

Consolidate the revenue system of record. Leave clinical systems in place.

Integration is hardest here. It’s N→1. Every EHR has a different data model, different charge-capture semantics, different export fidelity. Each acquisition adds an inbound interface, and the normalization burden sits entirely on the receiving platform.

Implementation is the cheapest and fastest of the three. No clinical migration. No retraining. Nobody’s day changes. Time-to-first-value is measured in weeks rather than quarters.

Maintenance is middling but improves with scale. One billing operation, one payer rule set, one denial queue — knowledge compounds, and a rule learned about a payer in one entity applies everywhere that payer is billed. The recurring tax is interface maintenance: each source EHR upgrade can break its feed.

That tax is quantifiable, and it’s the honest cost of this option. Published integration guides converge on $3,000 to $15,000 per interface per year for monitoring, error resolution, and API version updates.⁹ Build costs run $50,000 to $750,000 depending on scope, with typical deployment of six to twelve months, and a reasonable rule of thumb is 30% to 50% of year-one build cost annually thereafter — roughly 2× the initial build over a three-year ownership horizon.¹⁰

Worth noting that the independent integration literature arrives at this architecture on its own. Hub-and-spoke integration “costs more upfront but reduces per-interface maintenance cost and simplifies adding new systems,” as one guide puts it.⁹ The structure isn’t novel. Only the name is.

Choose it when deal velocity matters, and you can’t afford to stop revenue while you integrate.

The cost of choosing it: you inherit the documentation quality of systems you don’t control. If a source EHR makes it easy to write a note that won’t survive payer review, the revenue layer can flag it, score it, and route it back — but it can’t prevent it at the point of care. Clinical variation, and its audit exposure, persists.

Option C: full consolidation

One platform. One system of record for both clinical and revenue.

Integration is not hard — it’s absent. The problem is dissolved rather than managed. No interfaces to build, version, or repair.

Implementation is the most expensive. It’s Option A’s clinical migration plus billing conversion, for every entity.

Maintenance is the lowest by a wide margin. One vendor, one data model, one upgrade path, one support relationship. No interface tax. No reconciliation. No arbitration between vendors pointing at each other.

KPMG’s analysis of integrated revenue cycle and EHR operation found faster bill processing, more fluid cash flow, and up to a 2% to 4% increase in net revenue.¹¹ For context on what’s at stake in getting there: disciplined acquirers capture 9% to 23% of a target’s cost base in synergies, but most fall well short, and Harvard Business Review has documented M&A failure rates in the 70% to 90% range across industries.¹² Private equity sponsors typically underwrite 200 to 300 basis points of margin improvement within two years of close.⁵ That underwriting assumption is what a stalled integration actually breaks.

Choose it when you’re at steady state, or when the acquisition pace is slow enough to absorb the migration per deal.

The cost of choosing it: maximum change management, concentration risk with a single vendor, and — if you’re still acquiring — you pay a migration for each deal until the playbook is standardized enough to be routine.

The comparison

The adjacent systems

Patient engagement and cash processing don’t get their own topology. They follow the hub — and that produces an asymmetry worth understanding before you pick one.

Patient engagement follows the EHR. It runs on the schedule and the clinical record: appointments, reminders, intake, recall, reactivation.

Cash processing and credentialing follow the RCM. They run on the ledger and on payer enrollment: what’s owed, what posted, what was adjusted, who is enrolled with whom.

So Option A consolidates engagement cleanly and fragments cash — N merchant accounts, N statement formats, N enrollment tracks, and patients receiving bills that look like they came from different companies, because they did. Option B does the reverse: one ledger, one statement, one payment experience, one credentialing pipeline, but N reminder systems and no enterprise view of patient acquisition or retention.

Which means the right hub depends on where your money actually leaks. A consumer-facing group with high patient responsibility and a no-show problem loses more to fragmented engagement. A group billing third parties — workers’ compensation, personal injury, Medicaid, independent medical examinations — loses more to fragmented cash posting and enrollment. Same architecture question, opposite answers.

Answer that question before you pick a hub, not after.

The sequence — and where MTSP ends

All three options end in the same place. A single system of record is the destination — fewer seams, one source of truth, one accountable party. The question is never whether to get there. It’s the order.

B → C is the cheap path. A → C is the expensive one.

Option B generates cash inside the first year: recovered yield, faster DSO, enterprise visibility, denials worked to one standard. That cash funds the clinical migration. Option A spends the money first and delays the cash, so the clinical migration gets financed out of pocket while the revenue you acquired is still sitting in five aging reports.

Most acquisitive groups instinctively choose A, because clinical standardization is visible, feels like control, and is the thing executives can see when they walk into an acquired clinic. It is usually the wrong first move.

A caveat worth stating plainly, because the alternative is to overclaim: this sequencing argument is reasoning from cost structure, not a published finding. There is no controlled study comparing revenue-first against clinical-first integration in physician groups. What exists is consistent directional support — integration practitioners describe revenue cycle consolidation as a sequenced 180-day program with measurable interim milestones,⁵ while the peer-reviewed EHR literature documents a twelve-month productivity recovery curve.⁸ Put those two timelines side by side and the ordering follows from arithmetic. But it follows from arithmetic, not from evidence, and anyone who tells you otherwise is selling something.

The sequencing argument matters because the two migrations have genuinely different risk profiles. Revenue consolidation is urgent and comparatively safe — no clinical workflow changes, and the upside is immediate. Clinical migration is slow and risky — records convert, authorizations have to survive the move, booked appointments have to land, clinicians relearn documentation. Run them as one project and the risky one sets the pace for the safe one.

Decouple them, and you consolidate revenue in months, then migrate clinical systems in phased cohorts on a timeline the clinical organization can absorb.

Which is the honest way to describe MTSP: it is a sequencing structure, not a resting place. Both hub-and-spoke options exist to carry a group from the baseline to full consolidation without stopping revenue on the way. A group that stays in Option A or B indefinitely is paying an interface tax and a vendor-management tax forever to avoid a migration it will eventually do anyway.

The test

One question tells you where you actually stand:

From the day a deal closes, how long until that practice’s revenue appears in your consolidated reporting and is worked to the same standard as everything else you own?

If the answer is measured in quarters, that number — not capital, not clinical capacity, not deal flow — is the real constraint on your growth. And it’s determined by which of the four architectures you’re running.

Three of them you can choose. The first one you’re in already, if you haven’t.

References

1. Physicians Advocacy Institute and Avalere Health, Physician Employment Trends and Practice Acquisitions: 2018–2026, May 2026. physiciansadvocacyinstitute.org
2. Deloitte, “Health care M&A synergies through IT transformation.” deloitte.com
3. MGMA data reports — 50% to 65% of denied claims never reworked, at an average rework cost of roughly $25 per claim. mgma.com
4. MGMA, 2024 Cost and Revenue Survey — median 47 days in A/R across physician practices; better performers at 36 days. mgma.com
5. MD Clarity, Post-Acquisition Revenue Cycle Integration: MSO Playbook, May 2026. Practitioner source, not peer-reviewed; figures are stated industry benchmarks rather than survey results. mdclarity.com
6. MGMA, 2023 DataDive Practice Operations — single-specialty aggregate first-submission denial rate of 8%, unchanged from 2019. mgma.com
7. Fleming NS, Culler SD, McCorkle R, Becker ER, Ballard DJ. “The Financial and Nonfinancial Costs of Implementing Electronic Health Records in Primary Care Practices.” Health Affairs 2011;30(3):481–9. doi.org/10.1377/hlthaff.2010.0768
8. Fleming NS, Becker ER, Culler SD, et al. “The Impact of Electronic Health Records on Workflow and Financial Measures in Primary Care Practices.” Health Services Research 2014;49(1 Pt 2):405–420. RVUs 8% lower in the first six months post-implementation, recovering to 4% by twelve months; maintenance ~$1,650 per physician FTE per month. doi.org/10.1111/1475-6773.12133
9. Published EHR integration cost guides, 2026 — $3,000 to $15,000 per interface per year in maintenance; hub-and-spoke architecture reduces per-interface maintenance versus point-to-point. Vendor-authored.
10. Interface build and total-cost-of-ownership guides, 2026 — HL7 build $50,000 to $750,000 depending on scope, 6 to 12 month typical deployment, 30% to 50% of year-one build cost annually for ongoing operations. Vendor-authored.
11. KPMG, A Nexus of Value: Optimize Revenue Cycle and EHR System Performance — integrated revenue cycle and EHR operation associated with up to a 2% to 4% increase in net revenue. kpmg.com
12. Christensen CM, Alton R, Rising C, Waldeck A. “The Big Idea: The New M&A Playbook.” Harvard Business Review, March 2011. hbr.org