Tristella Advisors
How Do You Get Physician Buy-In for Healthcare AI?

How Do You Get Physician Buy-In for Healthcare AI?

Tristella Advisors·Healthcare IT

Here is the paradox every health system is sitting with right now: more than 80% of physicians are already using AI in their professional work, double the rate from three years ago. 84% say it makes them better at their jobs. And yet 81% say they are frustrated with how their organizations are implementing AI tools.

The physician buy-in problem is not, in most health systems, a problem of physician resistance to AI. It is a problem of how health systems involve physicians in AI decisions, which is to say, they mostly don't. 71% of physicians report having little to no influence over which AI tools get adopted in their organizations. Only 10% say they have meaningful control over those decisions.

When physicians resist a healthcare AI implementation, the instinct is to assume the resistance is about the technology. It usually isn't. It's about that.


Why physicians are a different change management problem

Organizational change management in healthcare tends to treat clinical staff as a single category. They're not. Physicians respond to change management interventions differently than nurses, administrators, or operational staff, and understanding why matters before you design a buy-in strategy.

Physicians carry a professional identity built around clinical judgment. Years of training, accumulated experience, and accountability for patient outcomes are not separable from the way physicians understand their own professional value. When an AI tool enters that environment framed as a decision-support system, what the physician often hears, even if that's not what was said, is "something has been determined to be better at part of your job than you are."

Research on professional identity threat shows that AI systems provoke resistance along two specific dimensions: threats to a physician's expert status and threats to their role as an autonomous care provider. Neither of these is irrational. Both are predictable. And neither responds to training programs or go-live communication plans the way other organizational change problems do.

The second thing that makes physicians different: they are already operating at cognitive saturation. As we've covered in our work on why healthcare AI pilots stall, any tool that adds steps, increases alert volume, or disrupts established routines will be abandoned regardless of its clinical accuracy. This is not stubbornness. This is rational time management from people who are already documenting, managing EHR systems, and seeing patients simultaneously. The bar for "worth my attention" is higher for physicians than for almost any other knowledge worker category.

And the third thing: knowledge gaps are more significant than most implementations account for. A 2025 meta-analysis of 115 studies found that only 19.6% of physicians have high overall AI knowledge, while 36.3% have low knowledge. You cannot build trust in a tool you don't understand. You cannot evaluate its outputs, advocate for it to peers, or provide useful feedback to the implementation team. Physicians being asked to adopt AI tools they don't understand will default to distrust, and that distrust is entirely reasonable given the stakes.


The three types of physician resistance

Not all physician resistance looks the same, and conflating them produces the wrong interventions.

The informed skeptic has genuine questions about accuracy, bias, and clinical applicability. They want to know the false positive rate. They want to see the validation data. They want to understand what patient populations the model was trained on and whether those populations match the patient population they see. This physician is not the obstacle. This physician is your most valuable early partner if you treat their skepticism as a clinical quality concern rather than a change management problem to be overcome.

The workflow objector isn't skeptical about AI in principle. They're skeptical that this specific tool, deployed in this specific way, will actually make their day better rather than worse. They've been through EHR implementations that promised to reduce the documentation burden and instead added two hours to their day. They are waiting to see proof that this time is different. This physician responds to evidence, specifically to seeing a peer whose workflow actually improved, and to having a feedback channel that goes somewhere.

The identity-threat resistor experiences AI adoption as a challenge to professional standing. The tool feels like a statement about clinical judgment rather than a support for it. This physician needs the framing changed before any other intervention will work. No amount of training, clinical champion advocacy, or workflow redesign reaches someone who experiences the tool itself as a professional affront. The conversation has to start earlier and at a different level.

Most buy-in strategies are designed for the third type while misidentifying the first two. Informed skeptics get put in change management workshops instead of validation committees. Workflow objectors receive training sessions rather than pilots with their actual patient panel. The result is a strategy that doesn't account for the actual distribution of resistance in the room.


Co-design is not the same as consultation

The most common physician buy-in failure is what health systems call "physician engagement," but it is actually a series of communications: a newsletter, a town hall, and a feedback survey after the tool is already selected and contracted.

That sequencing is backward, and physicians know it. 70% of physicians say they want to be involved from design through implementation to integration. Surveys after the contract is signed are not part of the involvement. They are documentation of a process that appears to involve.

Co-design means something specific. It means physicians are in the room when the use case is being defined, not when the tool is being configured. It means clinical workflows are mapped with physicians rather than presented to them. It means the question "does this clinical presentation pattern match what our physicians actually see?" is asked before a vendor is selected, not after go-live when physicians start questioning the alert logic.

The practical difference shows up in what gets built. A physician who co-designed a sepsis alert helped determine the threshold values, reviewed the SIRS criteria weighting, and raised the interoperability question about the EHR field that feeds it. A physician who was consulted after selection got a demo and was asked if the interface looked reasonable. The first physician will advocate for the tool and troubleshoot it when it underperforms. The second physician will stop looking at alerts that don't seem calibrated to their patient population.

The AMA's framework for physician co-design identifies physician involvement in clinical workflow design as the highest-leverage intervention for adoption, not communication, not training, not executive mandate. Front-line physician input on how an AI tool fits into the actual sequence of clinical decision-making determines whether it is used.


What "involving physicians" actually requires

In practice, involving physicians meaningfully in AI implementation requires a few specific structural commitments that most health systems skip because they're harder than adding a physician to an IT steering committee.

Dedicated time, not borrowed time. Physicians can't co-design in the margins of a clinical schedule. The organizations that get this right budget physician time explicitly: hours per week during the design phase, with protected capacity to participate in workflow review sessions, validation exercises, and feedback loops. This is a line item. It's not a favor physicians do on top of their clinical workload.

Clinical access to technical information. Physicians can't evaluate what they can't understand. This requires translation, not simplification. Physicians want to understand model training, validation data, and failure modes. They don't need to understand the mathematics. They need to understand why the tool produces this recommendation in this context, what it misses, and what they should do when they disagree with it. Providing that information requires implementation teams to explain their tools at a clinical level, which most vendors are not prepared to do without prompting.

A real feedback channel. The highest-correlation factor between pilot and sustained adoption is whether physicians believe their feedback goes somewhere. Not a suggestion box. Not a quarterly steering committee update. A named person whose job includes reviewing clinical feedback within a defined response window, and a process for communicating what changed based on that feedback. Physicians who see their input result in calibration adjustments become advocates. Physicians who submit feedback and hear nothing become the ones who no longer look at alerts.

Starting small, in the right place. The first AI use case deployed in a health system shapes the entire culture of physician AI adoption. The organizations that build physician trust fastest start with high-frequency, low-stakes workflows where the value is visible quickly and the consequences of errors are correctable. Documentation support, pre-visit summaries, and administrative workflow automation enable physicians to experience AI improving their day before they're asked to trust it with higher-acuity clinical decisions. The clinical AI skepticism that hardens in organizations often traces back to a first implementation that was high-stakes, poorly calibrated, and never fixed.


The framing that works and the framing that backfires

How you describe what an AI tool does determines how physicians receive it, and the difference between buy-in and resistance often lives in that framing.

Framing that backfires: "This AI will help us catch what physicians miss." "The algorithm outperforms average physician judgment on this metric." "This tool reduces unnecessary clinical variation." Each of these is probably true on some level. All of them are professional identity threats that activate the resistance patterns described above.

Framing that works: "This tool handles the information aggregation so you can focus on the clinical decision." "This is designed to surface the data you would want before you walk into the room, assembled faster than you can pull it manually." "This flags the pattern and gives you the context to evaluate whether it applies to this patient." The framing puts physician judgment at the center of the decision and positions AI as the thing that makes that judgment better informed, not as the thing that replaces it.

The language distinction is not cosmetic. It reflects a genuine difference in how the tool is designed to function in clinical practice. If the tool is designed to override physician judgment, the framing problem is actually a design problem. If the tool is designed to augment it, the framing should make that honest and specific rather than vague.

92% of physicians say they want more education and training on AI. That number reflects an opening, not a problem. Physicians who want to understand what they're working with are physicians who can become advocates. The buy-in strategy that takes that seriously, rather than treating education as a check-the-box training requirement, produces a different result than the one that doesn't.


Building the buy-in infrastructure before the tool arrives

The organizations that get physician buy-in right don't build it during implementation. They build it before the project starts, by establishing the conditions in which physician involvement is real and physician feedback produces change.

That means governance structures that include physician voices in AI selection decisions, not just in deployment review. It means physician AI literacy programs that run before specific tools are introduced, so physicians have a framework for evaluating clinical AI rather than encountering it for the first time under implementation pressure. It means named accountability for physician experience with AI tools, separate from the technical implementation track.

Understanding where your organization actually stands on these conditions before you launch a physician buy-in initiative is the step that most health systems skip. The gap between what your leadership believes about physician readiness and what your front-line clinical staff actually think and know is often significant, and it's a more reliable predictor of implementation outcomes than the tool you've selected.


At Tristella Advisors, our Healthcare IT practice works with health system leaders on the organizational and change-management infrastructure that determines whether AI implementations achieve sustained clinical use. Physician buy-in is not a communications problem. It's a design problem, and it starts with how physicians are involved before the first conversation with a vendor.

Learn more about how we approach healthcare AI adoption at tristellaadvisors.com/services/healthcare-it, or start with our Healthcare AI Adoption Scorecard to understand where your organization stands before your next implementation.


Sources:

How Do You Get Physician Buy-In for Healthcare AI? | Tristella Advisors