In recent months, several potent healthcare players announced their intent to build foundation models using the data flowing through their platforms: Epic announced Curiosity, with the specific callout that the model would eliminate the need for point solutions. Abridge has tapped chip-maker NVIDIA for raw compute power. Mayo Clinic inked a partnership with Microsoft.

Foundation models have gained hype for their potential to solve a spate of thorny healthcare issues with their vast base of clinical knowledge. The term has become one of the latest health AI buzzwords, and the context is critical to understanding the full implication for the industry.

Epic said that across 78 clinical prediction cases, things like extended hospitalization, 30-day readmission, and ASCVD risk, its Curiosity model "outperformed individual models, each specifically designed for one of the cases" in a majority of them.

Abridge, which already relies on large language models to turn voice into text, is buying GPUs directly from NVIDIA rather than paying per-token fees to Anthropic or OpenAI — reducing cost as the company grows. Mayo Clinic's partnership with Microsoft points to a third motivation for building a foundation model: contributing its own data to train a model for internal use, rather than relying on outside vendors.

For us at Vega Health, that sparked a question: how will these bets change the status quo of model development and, ultimately, clinical care?

Through conversations with Vega Health advisors, I set out to understand how foundation models work, their pros and cons, and what AI developers think about their ability to outperform the predictive models of the last decade.

What is a foundation model?

Let’s start with the basics. A foundation model is a large model built on transformer architecture that ingests and produces text, voice, or images. GPT, Claude, and Gemini are all foundation models. Unlike older approaches to building AI models, they're adaptable across tasks by design, meaning a single base model becomes the foundational layer other tools are built on top of.

Older model types, like logistic regression or tree-based models, require heavy upfront data cleaning: clinicians spend hours standardizing abbreviations, removing copy-forwarded notes, and labeling data before a model can even be trained to generate a prediction. Foundation models automate most of that cleaning step, according to Irene Chen, assistant professor of computational precision health at University of California Berkeley and UC San Francisco.

Foundation models can also be chained together to perform a sequence of tasks, called chaining. One model extracts diagnosis from a note, then hands the output to a second model that predicts risk. "Chaining makes intermediate steps inspectable and correctable," a key step to overseeing the performance of the models, Chen said.

Most of Vega Health's advisors are skeptical that any of this replaces the point solutions health systems already run for three overlapping reasons.

Why point solutions survive

A vertical solution, by contrast, is a model built for one specific job, like predicting sepsis.

The first is the workflow. "Statistical performance isn't the measure of success; it's the implementation," said Gabriel Escobar, formerly a research scientist at Kaiser Permanente Northern California. Escobar's team built the Advance Alert Monitor, a model that flags hospitalized patients at risk of deterioration, but it only became useful once his team built a workflow around it. Escobar and his team created an hourly risk score reviewed by a remote alert team, which triggers a bedside evaluation from a rapid response team, looping in palliative care to adjust the care plan when appropriate. Without that integration, an accurate prediction is just a number no one acts on.

"I think how you interface with the workflow, tightly interjecting the information that's needed into the workflow — is where we should be focusing," said Suresh Balu, executive director of the Duke Institute of Health Innovation. "Foundational models are okay, but they're not going to solve the whole problem."

Joe Futoma, staff ML data scientist at Ōura, agreed that a catch-all foundation model would still need localization and hands-on integration, — it might cut the time to build a new solution, but he's skeptical one model can do everything, everywhere, within the next six months to a year. Every hospital has its own patient mix, workflows, equipment, and procedures, and EHRs are built to be modified locally, so the same data looks different from site to site. "You're always going to need tailored validation on a site-by-site basis," he said.

Balu agreed. "That localization has to be done by somebody so they can solve the problem, realize the value, and make it sustainable," he said. "Innovation, in my view, is about looking at local problems and how you solve them."

The second reason is technical. Escobar doesn't doubt a foundation model could statistically outperform a point solution, but a slightly more accurate model doesn't necessarily lead to better healthcare decisions. And Futoma pointed out that a general-purpose model can fail in unexpected ways once it's pointed at a narrow task it wasn't trained for. "Healthcare data is highly idiosyncratic," he said. "It is brittle and sensitive to models trained on a certain imaging or X-ray machine."

"Most large language models can do very clear summarization, that is not the problem," Balu said. "But if you ask it to perform a specific task, like 'what is the right dose calculation for this particular regimen,' I don't think these general-purpose models can do that across the board. There are so many subspecialties, so many nuances. I don't think a single foundational model will suffice. You'd still want a variety of point solutions, which might be made available as tools consumed by agent solutions to produce the result. So, it's not going to be one model that rules everything."

Foundation models are also probabilistic — the same question can get a slightly different answer each time — where clinicians, Balu said, prefer deterministic tools that return the same result given the same inputs.

The third is oversight. Balu argued that scale makes monitoring and auditing harder, not easier: a model that performs well on summarization might not perform as well on something like prior authorization, and there's no way to know without a way to check.

Curiosity, for instance, is trained only on what's in the EHR, but a lot of relevant clinical information never makes it into the chart. And when a vended model predicts something like readmission risk, health systems often can't see why. "Those things won't be available in a vended product from a healthcare vendor," Balu said. "Whereas when we build models and build monitoring ourselves, we look at the whole context, and the whole context is what's going to matter."

There's a related cost to relying on an outside vendor's model at all: the more proprietary data a health system feeds in to make the model useful, the more of its own institutional knowledge ends up baked into someone else's product, sometimes called the reverse information paradox. Balu wants vendors held to an ongoing standard: performance broken out by use case — what were the outcomes, the safety events, the bias, the drift — disclosed continuously rather than once, since vendors keep improving the underlying model and performance can shift as it evolves.

"We need those basics fully made available, including what types and sources of data were used to train that specific model," Balu said. "And the validation results as well, from other systems or wherever they've done the validation." He wants monitoring tools shipped with the model, too, rather than left for health systems to build themselves. "Otherwise, we'll be spending a lot of money, time, and resources monitoring the model ourselves."

Balu ended with the bigger picture: "If we want to advance science and advance treatment plans and interventions, I think health systems interested in building these things should collaborate with each other and share data, to really build the next-generation model. I don't have to hand this off to big tech, because the domain knowledge clearly sits with the clinical care teams, and I think we should leverage that as much as we can."

Discussion Questions

  • What are unique workflows in your health system that would require AI models to be localized for your site?
  • What information would you want from a vendor before trusting their model's predictions at your organization?
  • Which of your current point solutions would be hardest to replace with a single, general-purpose model?
  • Would your organization benefit more from building AI in-house, partnering with a big tech vendor, or collaborating with peer health systems?