What Optum Scrutiny Means for Vendor Diversification

I have sat in enough vendor reviews to know how this goes. The first reaction is usually tactical: “Should we pause that renewal?” “Do we need a second clearinghouse?” “Can we keep the analytics tool and just swap the RCM layer?” That is the right instinct, but it is also where teams get trapped. They treat diversification like a contract cleanup exercise when it is really an architecture decision.

The DOJ scrutiny around UnitedHealth, Optum, and Change Healthcare changed the conversation because it put a hard spotlight on vertical integration. Once the market sees how much flow can be concentrated under one umbrella, every health system starts asking a question they should have asked earlier: what happens when the same vendor family sits in the path of claims, payments, reporting, and care management? If that stack breaks, slows down, or simply changes commercial terms, you do not have a nuisance problem. You have an operations problem.

That sounds obvious until you are inside a renewal cycle. Then the market reality gets messy. The RCM team likes one platform because it reduces appeals friction. The analytics group likes another because it has decent population health dashboards. Care management wants whatever integrates fastest with the EMR. Procurement wants one agreement, fewer vendors, and a lower legal bill. And the technology team, if it is honest, often wants the platform with the least operational drama.

The problem is that the lowest-friction choice today can become the highest-friction choice tomorrow. We have seen this pattern in integration work with HL7v2 feeds, payer connectivity, and revenue cycle interfaces: teams overvalue initial convenience and undervalue what happens when a vendor changes ownership, a product line gets bundled, or a dependency becomes a bargaining chip. A merger or antitrust action does not create the risk. It exposes the risk that was already hiding in the procurement chart.

RCM is where diversification pressure shows up first, because RCM is where operational downtime becomes instantly visible. If your claims submission, remittance posting, eligibility checks, or denial workflows depend on a single dense ecosystem, you do not have good leverage. You have one negotiation surface. In practice that means health systems are now splitting contracts more deliberately: one route for clearinghouse connectivity, one for claims editing, one for payment integrity analytics, and sometimes a separate layer for patient financial engagement.

The counterintuitive part is that more vendors is not always more risk. More vendors can be less risk when the interfaces are clean and the exit plan is real. I have seen organizations panic about “too many tools,” then end up more brittle after they consolidated around one platform that nobody could replace without a six-month cancellation window and a full data migration. Variety is not the enemy. Hidden coupling is.

That same logic applies to analytics. A lot of healthcare analytics products look independent on the surface and are anything but under the hood. They may differ in UI and reporting depth, but they often ingest the same claims feeds, same EHR extracts, same patient identity layer, and same warehouse. If one parent company controls multiple points in that chain, your reporting independence is weaker than your contract language suggests.

Analytics diversification is especially important because vendors love to sell “single source of truth” language. I do not buy it as a strategy. You want a reliable source of truth, yes, but you also want a way to challenge it. If your quality metrics, risk stratification, and referral leakage analysis all come from one tightly coupled vendor stack, then a product defect looks like a business truth. That is dangerous.

Care management is the third area where antitrust scrutiny should force a reset. Care management tools often look harmless because they sit on the edge of the core financial stack. But they become strategically important fast when they depend on claims data, utilization feeds, prior authorization status, and patient outreach workflows. If your care management platform is tied to the same ecosystem that touches your revenue flows, then your clinical outreach and your financial operations may be more coupled than you realize.

That matters because care management contracts often get justified on workflow efficiency alone. The better framing is continuity risk. Can you preserve outreach, tasking, care gap closure, and program reporting if the vendor gets acquired, repriced, or sunset? If the answer is no, then the contract is not a software decision. It is a resilience decision.

Here is where AST sees the real work. In our integration and platform work, the hardest part is rarely “can the system connect?” It is “can we disconnect later without breaking the hospital?” That question drives architecture, mapping, and contract language. We have seen teams assume an export button equals portability. It does not. If the field mappings, code sets, patient matching rules, or batch schedules are proprietary, the button is cosmetic.

We also learned something unglamorous but important: diversification fails when it is treated as a procurement event instead of a data-control strategy. A second vendor does not help if the first vendor still owns the canonical workflow definitions, the matching logic, or the archived historical data you need for audits and appeals. In our rollouts, the organizations that stayed nimble were the ones that insisted on clean interfaces, documented data ownership, and actual exit testing. Not “we think we can leave.” Actual testing.

So what should a health system do this week? I would start with a focused contract and dependency review, not a broad transformation program. You do not need to boil the ocean to get relief. You need to identify where concentration is highest and where replacement would be hardest. That gives you leverage in the next renewal cycle and keeps diversification from becoming a slogan.

1. Map the parent company tree List every RCM, analytics, and care management vendor and identify who owns what. If product branding hides common ownership, write the ownership structure down anyway.
2. Trace the dependency chain For each product, document the upstream feeds, shared services, clearinghouses, identity layers, and warehouse dependencies. If two tools fail together, you have not diversified.
3. Classify by exit difficulty Separate vendors that can be swapped at contract expiry from those that need data migration, interface rewrites, or workflow redesign. Those are different risk classes.
4. Rewrite the contract asks Push for export rights, termination assistance, data retention windows, interface documentation, and service continuity terms that survive ownership changes.
5. Test one exit path Pick one workflow and actually simulate leaving. If you cannot extract data, remap interfaces, and preserve reporting, the market concentration problem is still yours.

If you want a heavier lift, build your diversification program around three questions:

• Where do we have one vendor family controlling more than one mission-critical workflow?
• Which systems can we replace without touching the EMR, and which ones are structurally welded to it?
• What data do we need in plain formats so we can move if ownership, pricing, or product support changes?

That third question is the one people dodge. They will spend hours debating dashboard colors and licensing tiers, then get quiet when you ask who owns the historical claims data and whether export is complete or partial. That is usually the moment the room realizes the risk is not abstract.

This is also why I push teams to think in terms of operating domains, not product categories. RCM, analytics, and care management are not just software types. They are control points. Whoever controls the control points has leverage over cash, visibility, and patient follow-up. Vertical integration amplifies that leverage. Diversification reduces it only if the organization does the hard work of separation.

And yes, separation costs time. It creates interface work. It may slow down your short-term rollout plan. I would still do it. I would rather spend time building a durable vendor architecture than spend the next three years negotiating from a position of dependency. That is not a clean story, but it is the honest one.