Why Health AI Is Hard to Build—and What It Takes to Scale

A small group of emergency physicians recently tested an ambient AI scribe.

Seventy-one percent preferred using it to documenting on their own. Yet only 43% trusted the accuracy of the notes it produced.

The study involved 14 physicians across four emergency departments, so it should not be treated as representative of medicine as a whole. Still, the tension in the results is worth paying attention to. The system sometimes missed information, performed poorly on parts of the clinical note, or required more editing than expected. Most of the physicians still preferred having a draft to returning to a blank screen.

A larger study involving 46 clinicians found a similar pattern. Ambient scribing was associated with 20% less time spent on notes per appointment and 30% less after-hours documentation. The technology did not eliminate documentation work, and experiences varied, but it reduced enough of the burden to change how clinicians experienced the job.

The physicians were not choosing inaccurate documentation.

They were choosing a better starting point.

That distinction gets to the heart of building health AI. People do not adopt a product because its model is impressive. They adopt it because the product makes something difficult meaningfully better.

The same principle applies to the company behind it.

A compelling demonstration can show that an AI capability is possible. It cannot show that the product will fit a real workflow, work with fragmented clinical data, earn trust, survive implementation, or make economic sense as usage grows.

That gap is proving difficult to cross. In research conducted by Bessemer Venture Partners, AWS, and Bain & Company, only 30% of completed healthcare AI proofs of concept had reached production. Security, integration costs, inadequate internal expertise, and data readiness were among the most commonly cited barriers.

The pilot-to-production gap is rarely one problem.

It is the accumulated effect of dozens of product, technical, clinical, and business decisions that have to work together.

Pick a job people are ready to change

The strongest health AI products usually begin with work that is already painful, frequent, and expensive.

Clinical documentation is a good example. Physicians do not need to be persuaded that the problem exists. The work is unavoidable, it consumes time beyond the patient encounter, and the person receiving the AI-generated draft can act on it immediately.

Ambient scribes did not create a new job for physicians. They entered an existing one and made the most frustrating part of it easier.

That is a fundamentally stronger starting point than an AI capability searching for a use case.

The first question in a health AI build should not be, “Where can we use a language model?”

It should be, “What work is painful enough that people will change how they operate?”

The answer needs to be specific.

Who experiences the problem? How often does it occur? What happens today? What decision or action needs to improve? How will the user know the product helped? Why would an organization invest the time and money required to deploy it?

If those answers are vague, better model performance will not rescue the product.

Health AI also does not have to automate an entire job to create value. A scribe may still require physician review. A patient-support product may still escalate to a care team. An operational system may still need someone to approve an exception.

The question is whether the product removes enough friction, cognitive load, delay, or cost to earn a permanent place in the work.

Fit the workflow—and hide the friction

An accurate output delivered in the wrong place can be useless.

An alert sent to someone without the authority or time to act becomes more noise. A product that saves a clinician five minutes but creates ten minutes of work for another team has not improved the system. A recommendation that arrives after the decision was made has little value, regardless of how sophisticated the model is.

Workflow cannot be delegated to an integration phase after the product has been designed.

For a clinician-facing product, the right place may be inside the EHR, the inbox, the documentation process, an order workflow, or a care-management queue.

For an administrative product, it may be inside scheduling, eligibility, prior authorization, claims, or revenue-cycle operations.

The workflow determines more than where the product appears. It determines what information is available, who takes responsibility, what happens next, and how value will be measured.

Patient-facing health AI has another challenge: the patient should not inherit the complexity of the healthcare system.

Health information comes from different sources. The terminology is unfamiliar. Decisions may involve uncertainty, risk, and emotion. Too often, all of that complexity is passed directly to the patient through another portal, another dashboard, or another unexplained set of numbers.

A good patient experience should quickly answer four questions:

What does this mean for me?

Why does it matter?

What should I do next?

When should I involve a healthcare professional?

Getting from information to action should feel almost frictionless. Patients should not have to search through menus, open another portal, repeat information, or wait for a callback simply to understand what the product just told them.

If they need more context, it should be available at that moment without forcing them to start over.

This requires more than polished UX and UI. Clinical understanding, product strategy, data, and AI behavior have to work together.

The technology behind the experience may be complicated.

The experience itself should not be.

The data is part of the product

Healthcare has enormous amounts of data. That does not mean the data is ready for AI.

Clinical information was created for many reasons: to support care, communicate between professionals, document decisions, bill for services, or meet regulatory requirements. It was not created as a clean and consistent dataset for a new AI product.

Important context may be buried in free text. Information may arrive late, appear more than once, or be represented differently across institutions. The meaning of a field can depend on the workflow that produced it.

Connecting to an EHR does not make those problems disappear.

Stanford Health Care’s experience building ChatEHR offers a useful view of what sits beneath a seemingly simple AI interface.

From the clinician’s perspective, the experience is straightforward: open a patient record inside Epic and ask questions about the chart.

Underneath that interface, Stanford had to build a near-real-time clinical data foundation, transform raw FHIR data into formats that language models could use effectively, preserve metadata for auditing, process different parts of the patient record concurrently, centralize authorization and logging, and embed the application into the existing EHR workflow.

Stanford did not build only a chatbot.

It built a platform around the chatbot.

That platform determines whether the information is current, which context is included, how an answer can be traced back to its source, and whether the system can continue working across large and complicated patient histories.

The lesson is not that every company should copy Stanford’s architecture. Most startups will not have the same resources, requirements, or starting point.

The lesson is that data strategy cannot be separated from product strategy.

A health AI company needs to understand where its information came from, why it was created, what may be missing, and what changes when the product enters another institution, specialty, or patient population.

The quality of the model matters.

So does the quality of the reality the product is able to show it.

Model strategy is not a vendor decision

Companies often begin by asking which model they should use.

That is too narrow a question.

A real model strategy determines how the product combines instructions, retrieval, large and small models, specialized models, conventional software, business rules, and human judgment.

Fine-tuning may be useful when a repeated task requires specialized behavior, terminology, or a highly consistent output. It can also introduce new requirements around training data, evaluation, versioning, and maintenance. It should be a deliberate choice, not the automatic first step. Current model-optimization approaches include retrieval for adding relevant knowledge, fine-tuning for adapting behavior, and custom models for more specialized requirements.

Retrieval may matter more when the product needs current or patient-specific information. A smaller model may be sufficient for a narrow classification task. A deterministic rule may be safer and cheaper than a generated response. A high-risk decision may require human approval regardless of the model’s performance.

The goal is not to find one perfect model.

It is to choose the right method for each part of the workflow.

This becomes especially important when the product begins to grow.

During a pilot, a company may send every request to its most capable model, process an entire medical record each time, manually inspect difficult outputs, and build a custom integration for the first customer.

That can work long enough to prove the concept.

At scale, brute force becomes the business model.

A single interaction may require data retrieval, multiple model calls, safety checks, logging, evaluation, monitoring, and human review. If the product repeatedly processes years of patient history, uses the largest model for every task, or depends on a custom technical path for each customer, costs can grow faster than the value being created.

Stanford’s platform reflects several decisions intended to avoid that outcome. It includes a model router, shared logging and monitoring, intelligent caching, and parallel processing of different parts of the clinical record. Those capabilities create infrastructure that can be reused across multiple applications rather than rebuilt each time.

Architecture determines whether increased usage creates leverage or erodes the company’s margins.

Some tasks need the strongest available model. Others do not. The right system will often use a combination—and make it possible to change that combination as the technology evolves.

Trust has to survive real use

Privacy, security, compliance, and validation are essential.

None of them alone creates trust.

Trust develops through the way the product behaves after it enters the workflow.

Can users see where the information came from? Can they recognize uncertainty? Is human review required at the right moment? Can an error be reported and investigated? Is it clear who remains accountable?

The ambient-scribe example is useful here.

Physicians did not need to believe that every generated sentence was correct. They needed to understand the role of the product: it created a draft, and the physician reviewed and approved the final note.

The product could be dependable within a defined workflow without being treated as infallible.

That balance becomes more demanding as health AI moves from documentation and administrative work into diagnosis, treatment decisions, and patient guidance.

In the AMA’s 2026 survey, 88% of physicians said robust safety and efficacy validation was important for broader AI adoption. Eighty-six percent cited data-privacy assurances, and 85% wanted physicians involved in adoption decisions.

Those concerns should not be dismissed as resistance to technology.

They are product requirements.

Evaluation also cannot end when the product launches. Models change. Data changes. Workflows change. Performance may shift when the system enters another institution, specialty, or patient population.

Stanford is adding continuous evaluation capabilities to its platform for precisely this reason: the product needs to be studied in real use, not only tested before deployment.

A trustworthy health AI company needs to know whether the complete product is still working—not simply whether the model passed its original test.

Clinical value and commercial value have to meet

Healthcare often separates the person using a product from the person buying it—and from the person receiving the financial benefit.

A clinician may use the product.

A patient may benefit.

A health system may purchase it.

A payer may capture the savings.

An IT team may carry the implementation burden.

A clinical leader may carry the risk.

This is why a health AI product can create obvious clinical or workflow value and still struggle to become a viable business.

The company has to identify who owns the problem, who controls the budget, what outcome will be measured, and where the return will appear.

That return might be greater clinical capacity, lower labor costs, faster reimbursement, fewer denials, better access, reduced medical costs, improved outcomes, or a better clinician or patient experience.

But the value has to be visible and attributable.

Bessemer’s research found that 60% of surveyed healthcare buyers expected to see positive ROI in less than 12 months. It also found that 75% believed startups failed to recognize the true cost the customer carries during a proof of concept.

That cost includes more than the software.

A customer may need to involve clinical leaders, IT, security, legal, compliance, operations, and training teams before a product reaches routine use.

Implementation is not what happens after the sale.

In healthcare, implementation is part of the sale—and part of the product.

This does not mean a startup should become a custom-development shop. It means the product and commercial model must account for the work required to make adoption real.

There is an opportunity for companies willing to work this way. Sixty-four percent of the buyers in Bessemer’s research said they were open to co-developing solutions with startups.

But healthcare organizations expect those partners to understand the environment they are entering, define success early, involve the necessary stakeholders, and share responsibility for reaching the outcome.

Trust can become distribution

Healthcare’s dependence on trust can slow adoption.

Once earned, however, that trust can create an advantage that is difficult to reproduce.

In a healthcare platform our team previously built, physicians invited patients to use the product and connected their test results to an application.

The patients did not arrive through an advertisement. A trusted relationship created the entry point.

The connected test results made the experience personal. Instead of navigating generic information, patients could make choices based on their individual health profiles and better understand which options were safest for them.

The experience was easy to use repeatedly and useful beyond a single visit or test result.

Patients began inviting friends and family.

The growth loop looked like this:

Physician trust → Patient adoption → Personalized value → Confidence → Friends and family → New users

The interesting part was not simply that referrals generated growth.

The product, data, experience, and distribution model had been designed to strengthen one another.

Physician trust lowered the barrier to adoption. Personalization made the product more valuable. A low-friction experience kept people engaged. Value created advocacy, and advocacy extended the product beyond its original clinical channel.

In healthcare, trust does more than reduce risk.

Properly designed, it can become distribution.

The earliest decisions are the hardest to reverse

Most health AI scaling problems are difficult to see during the demo.

They appear when the company connects to live systems, processes more data, adds customers, enters new workflows, and operates under greater scrutiny.

By then, the foundational decisions may already be embedded in the product.

The data architecture is established. The workflow is designed. The model strategy has been selected. Product claims have been made. The patient experience has taken shape. The cost structure has begun to form.

Changing those decisions becomes slower and more expensive with every customer added.

This is why choosing a health AI partner based only on who can ship the first version fastest can be a costly mistake.

Engineering capability is essential. It is the starting point.

The right team must also understand how healthcare workflows, data, patient experience, model strategy, evaluation, security, economics, implementation, and distribution affect one another.

These are not separate layers to be built independently and reconciled later.

Together, they are the product.

Why we created Healthcare AI Launch

DeepStart came out of healthcare.

We have learned these lessons by building inside healthcare—not by studying the category from the outside. Our work has included products connected to real healthcare data and workflows, personalized patient experiences, and growth systems in which clinical trust became distribution.

That experience shapes how we evaluate what should be built, what should not be built, and which early decisions will determine whether a product has a credible path to scale.

Healthcare AI Launch is for clinicians, healthcare entrepreneurs, and companies with a clearly defined opportunity that need more than an AI demonstration.

In 10 weeks or less, we move the opportunity from product strategy to a working MVP. Along the way, we establish the workflow, data requirements, product architecture, model strategy, patient or clinician experience, evaluation approach, privacy boundaries, operating economics, and initial path to adoption.

The goal is not to solve every future scaling challenge in 10 weeks or less.

It is to prevent the most important early decisions from being made by accident.

The health AI companies that endure will not be those with the most impressive demos.

They will be the ones that make intelligence useful, trusted, and economically viable inside healthcare.

That is the work DeepStart was built to do.