The Hard Part of Healthcare AI Isn’t the Model

AI is already part of everyday healthcare work

Whether people in healthcare will use AI is no longer an open question. They already do, on both sides of the exam room.

Look at where that use shows up and a pattern appears.

• Patient questions

  Understanding a lab result, preparing questions before a visit, deciding whether a symptom can wait. Patients bring these to AI because it answers immediately and in plain language.

• Clinical documentation

  Drafting visit notes, summarizing long charts, rewriting instructions for patients. The AMA’s survey found that documentation and summarization are where most physician use and enthusiasm currently sit.

• Research and reference

  Summaries of research and standards of care. Nearly 40% of physicians in the AMA survey now use AI this way in their workflows, 26 points more than in 2024.

• Finding information

  Locating the one relevant detail in a long record, a dense policy document or a payer’s coverage rules.

• Administrative work

  Prior authorization letters, appeal drafts, coding questions and scheduling messages: the work that surrounds care rather than care itself.

What these uses have in common is that the person is doing the integrating. They decide what to share with the tool, they carry the output back to whichever system needs it, and they are the only check on whether it was right. That works, up to a point. It is also exactly where the limits begin.

Using AI is not the same as integrating it

When a clinician uses a general-purpose AI tool, the tool sees only what they paste in. It doesn’t know what was in last week’s note, what the most recent potassium was, or which medications were stopped at discharge. Its answer lands in a chat window, and from there it travels by copy and paste.

Integrating AI means something else. The system can read the right information for this patient, with permissions that match the user’s. Its output appears inside the workflow where the decision is made. Someone is accountable for reviewing it. There is a record of what it saw and what it produced. And when it gets something wrong, the organization finds out because the system is monitored, not because one user happened to notice.

Why healthcare raises the bar

In many industries, a tool that is usually right and saves effort is an easy win. Healthcare has a few characteristics that make the integration step both harder and more important.

• The systems of record are central and long-lived. Clinical work runs through the EHR, and changing how it behaves touches every department that depends on it.
• The data is sensitive by default. Almost everything that makes an AI system useful is protected health information, with obligations attached to every place it travels.
• Errors aren’t cosmetic. A wrong date in a marketing email is embarrassing. A wrong dose in a discharge summary is something else entirely.
• Work is shared across roles. One patient’s care passes through scheduling, nursing, physicians, pharmacy, billing and the patient. AI that helps one role but breaks the hand-off to the next hasn’t really helped.
• Reliability is expected, not hoped for. A tool that’s unavailable during clinic hours, or behaves differently after an unannounced update, creates work instead of saving it.

The regulatory side of this, from BAAs to technical safeguards, is covered in our guide to HIPAA-compliant AI. This article is about the engineering and operating model around it.

In a lot of healthcare AI today, the person using the tool is the integration layer. That doesn’t scale, and it shouldn’t have to.

AI is only as useful as the data it can reach

Ask an experienced clinician what they need to make a decision and the answer is rarely a single number. It’s the trend, the history, the specialist’s note, the medication that changed last month, the context that explains why a result is or isn’t worrying. AI needs the same thing. Without it, even a very capable model is answering a narrower question than the one being asked.

The difficulty is that a patient’s story almost never lives in one place.

Four problems tend to surface as soon as an AI project tries to use this data:

• Fragmentation. Information is spread across the EHR, departmental systems, other organizations and patient-facing apps, each with its own identifiers and update cycle.
• Quality. Duplicate records, stale problem lists, free-text fields holding what should be structured values, and codes that mean slightly different things in different systems.
• Structure. Lab values and medication lists are usually structured. The reasoning, the part that explains why, mostly sits in narrative notes and scanned documents.
• Movement. Data crossing organizational boundaries often arrives as a document rather than as data, and has to be matched and reconciled before it is useful.

None of this is news to anyone who has worked on a healthcare data project. What has changed is that AI raises the stakes. A dashboard built on incomplete data shows a misleading chart. An AI system built on incomplete data writes a confident paragraph. For a deeper look at the standards involved, see our healthcare interoperability guide.

The EHR is where AI becomes useful, or doesn’t

Most clinical work happens inside the EHR: orders, notes, results, messages, the inbox. A clinician who has to leave that environment, open another tool, re-establish which patient they’re looking at, paste in context and then carry the answer back has gained something, and paid for it in clicks and attention.

That’s why the same AI capability can feel transformative in one setting and pointless in another. A summary that appears inside the chart, for the right patient, when the clinician opens the encounter, saves time. The identical summary in a separate window is one more thing to check.

Every arrow in that chain is an integration someone has to build, secure and maintain. In practice, that involves:

• Standards-based access. FHIR APIs give applications a consistent way to read, and increasingly write, clinical data. Certification rules under the 21st Century Cures Act require certified EHRs to offer standardized FHIR-based APIs, which has made this far more practical than it was a few years ago.
• The feeds that already exist. A great deal of real-time clinical data still moves as HL7 v2 messages through interface engines. An AI system that ignores those feeds is working from an incomplete picture.
• Launch in context. SMART on FHIR lets an application open inside the EHR already knowing the user and the patient, so nobody has to re-identify anyone by hand.
• Write-back. The most useful output usually has to land somewhere: a draft note, a task, a message. Writing back safely, with attribution and a review step, is harder than reading.
• Context, not just data. Knowing that a result was flagged, who ordered it and what happened at the last visit is often the difference between a useful summary and a generic one.

We’ve written in more detail about HL7 v2 and FHIR trade-offs in EHR integration pipelines and about FHIR-based data exchange.

Deploying AI is the start of the work, not the end

Traditional software mostly does the same thing tomorrow that it did today. AI systems differ in ways that matter: their output varies, their behavior can shift when a model or prompt changes, and their mistakes tend to look plausible rather than obviously broken. That makes oversight an ongoing activity, not a sign-off at launch.

“Governance” can sound bureaucratic. In practice it comes down to a short list of questions that someone should be able to answer for every AI use in the organization:

Clinicians want a hand in this. In the AMA’s 2026 survey, 85% of physicians said they want to be consulted on, or responsible for, bringing AI into their practice. The factors they rated most important for wider adoption were validation of safety and efficacy (88%) and assurances about data privacy (86%). Governance is how those expectations turn into day-to-day practice.

Our post on enterprise AI governance, risk and compliance goes further into frameworks and operating models.

The model is one layer of the system

Put the previous sections together and a picture forms. A useful healthcare AI system is a stack, and the model is one layer in it. Governance isn’t another layer on top; it surrounds all of them.

The layers depend on each other in both directions. A strong model on weak data underperforms. Good data with no integration never reaches anyone. A well-integrated tool with no oversight is a problem waiting to be found. In our experience, healthcare AI projects that stall are rarely stuck on the model. They’re stuck a layer below it, or a layer beside it.

Where the next wave of healthcare AI will be built

Models will keep getting better, and quickly. That progress is real and welcome. But because it is available to everyone, a better model on its own is a shrinking advantage. The slower, harder and more durable work is everything that lets a model do something useful inside a specific health system.

For healthcare organizations, and for the companies building for them, that points to a handful of places to focus:

1. Data connectivity

   Reliable pipelines from the systems that hold patient data, with identity matching and quality checks, so AI works from the full picture rather than whatever was easiest to reach.

2. EHR and workflow integration

   AI that opens in context, writes back drafts for review, and shows up at the moments where decisions are actually made.

3. Interoperability by default

   Building on FHIR and existing exchange standards instead of one-off connectors, so each new use case doesn’t start from zero.

4. Governance as infrastructure

   Audit trails, evaluation suites, access controls and monitoring built into the platform, rather than bolted onto each project after the fact.

5. Reusable foundations

   Shared services for identity, consent, logging and evaluation that every AI use case can rely on, so the tenth deployment is easier than the first.

None of this is as visible as a new model release. It tends to show up as an absence: no copy and paste, no surprising outputs, no project that worked in the pilot and stalled in production. It is also the work that decides whether AI becomes part of how care is delivered, or stays a set of clever tools on the side.

Questions we hear about healthcare AI infrastructure