Walk the floor of almost any risk-bearing organization and you will find the same thing: data scattered across 8 to 15 vendor portals, payer SFTP drops landing files nobody fully reconciles, and the connective tissue holding it together is Excel. Each tool was bought to solve a real problem. Each one solved its slice. None of them talk to each other, and the people using them cannot see what the others are doing to the same member.
This is vendor portal sprawl. It rarely shows up as a line item, which is exactly why it is expensive. The cost is hidden in duplicated work, in decisions that wait on an analyst queue, and in problems found too late to fix. Let me put numbers and shape to it.
What the sprawl actually looks like
Picture a single member with three things going on: a suspect diagnosis the risk team wants confirmed, an overdue screening the quality team is tracking, and a lapsing medication the pharmacy team is watching. In a sprawled stack, that member appears in three different systems, on three different lists, owned by three different teams who never see each other's view.
So the member gets called three times in a week. Once about a coding visit, once about a screening, once about a refill. To the member, it looks like an organization that does not know its right hand from its left. To the operation, it is triple the outreach effort for what one well-prepared touch could accomplish. The cost is not the third call. It is the first two that should never have been separate.
Meanwhile, any question that crosses team boundaries (which of our members are slipping on both a Stars measure and a diagnosis?) cannot be answered by any one portal. It becomes a ticket to the BI team, who pull, join, and reconcile the data by hand. That is the 3-week bottleneck almost every operations leader will recognize. By the time the answer lands, the window to act on it has often already moved.
The most expensive part: everything is retrospective
Here is the failure that costs the most, because it is the hardest to see. When the operation runs on disconnected tools reconciled quarterly, you are always looking backward. Problems surface at reconciliation, after the period they affected has closed. A gap that could have been closed in May is found in August, when it is too late to count. An avoidable admission is discovered in the claims run, long after the member was discharged.
The most visible symptom of this is the provider representative who walks into a practice carrying printouts that are already weeks out of date, ready to discuss performance against numbers that have since changed. The conversation is earnest and the data is stale, because the data was always going to be stale by the time it made it through the stack and onto paper.
In a risk-bearing contract, retrospective is a synonym for too late. The whole point of running the operation on a live, single record is to catch these while they can still be changed.
Putting a number on it
We can be precise about parts of this, and honest about the parts we cannot yet benchmark across the industry.
At our flagship customer, a physician-led IPA in New York running risk on 175,000 patients, consolidating the stack recovered roughly 10 hours per user per week with 100% team adoption. Across Pelica deployments, customers have tripled outreach capacity per coordinator and retired 12 separate tools and 5 point vendors. Ten hours per user per week is a useful way to read the problem in reverse: those are hours that were being lost today to swivel-chairing between portals, re-keying data, and chasing reconciliations by hand.
What we do not yet have is an industry-wide benchmark for how much sprawl costs the average risk-bearing organization, in dollars, hours, or duplicated touches. We are running a forthcoming State of Value-Based Care Operations survey to put real numbers to it. Until that data is in, we will not assert figures we cannot stand behind.
The benchmark will quantify three numbers we hear estimated but rarely measured:
- The average number of vendor portals and data feeds a risk-bearing organization logs into each week.
- Analyst turnaround time on a cross-team question, from request to answer.
- The share of members contacted by more than one team in the same week.
The consolidation thesis
The instinct, when a stack is failing, is to add another tool to patch the gap. That makes the sprawl worse. The way out is the opposite: collapse the stack into one canonical record per member, and put execution on top of it.
One record means claims, EHR, pharmacy, lab, ADT, payer SFTP drops, and call recordings, normalized and resolved across identity, into a single live picture of the member. Every team reads and writes the same record, so the right hand finally knows what the left hand is doing. The triplicate call disappears because the second team can see the first team already reached out.
Execution on top means the work does not just become visible, it gets done: the outbound call, the portal entry, the follow-up, handled by an action layer rather than a coordinator swiveling between tabs. That is the difference between analytics and an operating system, a distinction we make in full in AI agents vs. analytics dashboards.
You do not fix a stack of fifteen tools by buying a sixteenth. You fix it with one record everyone shares, and an action layer that does the work the tools only described.
Sources and further reading
- Peterson-KFF Health System Tracker: How US spending on healthcare has changed over time (administration as a share of national health expenditure)
- Shrank, Rogstad, Parekh: Waste in the US Health Care System (JAMA, 2019); administrative complexity estimated at $265.6B
- American Medical Association: 2025 prior authorization physician survey (staff time consumed by manual administrative work)