Clinician Adoption Barriers for AI Decision Support Tools

Elsevier's "Clinician of the Future" survey found that only 16% of clinicians currently use AI tools to support clinical decisions. That single number tells you almost everything about the gap between what AI decision support can do and what it actually does, day to day, in the rooms where care gets delivered. The same research found a substantial share of healthcare organizations had either not yet actively considered AI solutions or were still stuck at preliminary evaluation. Advanced language models now match medical experts on certain diagnostic tasks, and clinical decision support tools built on them can sharpen diagnostic accuracy and cut cognitive load. None of that matters much if adoption stalls at 16%, and understanding why it stalls requires looking at more than one layer of the problem.

Trust and transparency problems at the human level

Clinicians don't distrust AI because they fear new technology. They distrust it because most AI tools hand them a conclusion with no visible reasoning behind it, and there's no way to check the work.

That's not a minor complaint. Evidence-based medicine, the framework nearly every clinician trained under, requires blending personal clinical judgment with external evidence traced back to its source, such as a trial, a guideline, or a peer-reviewed study. An algorithm that outputs a recommendation without showing where that recommendation came from doesn't fit inside that framework. It sits outside it, asking clinicians to trust a black box in a field built on the opposite instinct.

Research bears this out directly. Clinicians consistently prefer tools that cite the specific guideline or study behind a recommendation over tools that just assert one. A systematic review published in JMIR in 2025, which pulled together studies from January 2020 through November 2024, landed on four things necessary to build trust in AI-based decision support: explainable models, thorough training, involving stakeholders in the tool's design, and building the interface around how clinicians actually work rather than around the model's convenience. Skipping any one of those leaves the tool a stranger in the room, technically present but never fully accepted.

The organizational infrastructure that AI-CDS requires but most health systems have not built

Even a perfectly transparent AI tool runs into a wall if the hospital underneath it can't feed it clean data. A CHIME survey found 62% of health systems name data integration as their single biggest obstacle to AI adoption, ranking it above budget, staffing, and regulatory concerns combined.

Structural factors explain this. A single hospital network typically runs several different clinical systems side by side, each storing data in its own proprietary format with limited ability to talk to the others. Getting to a unified, FHIR-compliant data layer, the kind AI needs to generate recommendations grounded in a patient's full record, isn't something that happens alongside deployment. It has to happen first, or the AI is working off fragments.

The Human-Organization-Technology framework used in a recent Safety Science review groups this under the organizational cluster: weak infrastructure, thin leadership support, and regulatory friction. But that framework also points to something less obvious, which is that the culture-level barriers people usually chalk up to individual clinician skepticism, like attitudes toward evidence or the quality of relationships across departments, trace back to organizational choices too. Transparency and accountability at the institutional level shape clinician trust in anything new the institution rolls out, AI included.

Alert fatigue and EHR integration as the technical friction that erodes daily usability

EHR integration is supposed to be where AI-CDS earns its keep. Instead, it's often where the tool loses clinicians for good.

Rule-based decision support systems tend to fire off large volumes of alerts with limited precision. Most are false positives or generic enough to apply to nearly any patient. Clinicians, buried under interruptions, learn to click through them without reading, a defensive habit built out of necessity. Human-computer interaction research on clinical software names usability as the real bottleneck here: it isn't that the underlying logic is wrong, it's that the burden the interface places on a clinician's attention outweighs what the alert is worth. A separate review in Safety Science identifies the technology-side barriers in similar terms: accuracy concerns, gaps in explainability, and a lack of adaptability to the specific clinical context in front of the user. A tool can be statistically sound and still be clinically useless if it doesn't fit the situation.

Machine learning models trained on outcomes data offer a real counterpoint. Instead of a fixed set of rules, they can pick up on combinations of clinical signals that predict deterioration, sepsis, readmission, or a poor response to medication, often with better sensitivity and specificity than a manually written rule set could ever manage. Fewer alerts, each with higher confidence, and a model that keeps refining itself as it sees more data: that's a direct answer to alert fatigue, at least in principle. Whether it plays out that way depends on how well the model gets tuned to the population it's actually serving.

How the transparency problem is being addressed technically: source-verified and auditable AI

The trust issue laid out earlier now has a technical answer taking shape. A 2026 framework from researchers at the University of Cincinnati, Alu and Oluwadare, writing in Frontiers in AI, lays out an architecture built on three pieces: a curated medical knowledge base that tracks exactly where each piece of information came from, a retrieval-augmented reasoning engine that ties every recommendation to a specific, identifiable guideline or peer-reviewed source, and a tamper-evident audit log that records the inputs, the evidence retrieved, and each step of the model's reasoning for anyone to review later.

Put simply, a clinician using a tool like this doesn't just get an answer. They get the trail that led to it, which is the exact thing evidence-based medicine has always demanded and traditional AI has always withheld.

OpenEvidence is a working example of the principle rather than just a proposal on paper. In an evaluation by Hurt et al., physicians using the tool rated its answers as clear, relevant, and well-supported, largely because the tool's approach to supporting its responses gave physicians confidence in the answers they received. The framework's authors are upfront about what still needs solving: keeping the knowledge base current and well-governed, making sure citations in a retrieval-augmented system stay accurate rather than drifting, guarding against bias baked into the underlying evidence itself, managing the latency and usability trade-offs that come with retrieving sources in real time, and handling privacy properly throughout. None of these are solved problems. They're the next set of problems, now that the first one, opacity, has a credible answer.

What the regulatory environment now requires

Regulation is no longer sitting on the sidelines here. The EU AI Act treats medical AI that's embedded in or constitutes a medical device requiring notified body assessment, which covers MDR Class IIa devices and above, as high-risk by default. That classification comes with real obligations: AI-specific risk management, high-quality datasets built to minimize bias, clear disclosure that AI is involved in the recommendation, a requirement for human oversight, and ongoing monitoring of the tool's performance after it's out in the field. It's a heavy compliance load, and it's meant to be.

The FDA has taken a different tack for lower-risk products. In January 2026, the agency issued new guidance scaling back oversight for certain low-risk digital health tools, including some AI-enabled software and decision support products, which opens a faster path for the applications that carry less clinical risk to begin with.

Money is moving too, funding a national reimbursement structure through a hospital outpatient payment system for a specific AI-assisted cardiac imaging service, CPT code 75577, which covers AI-enabled... The 2026 Hospital OPPS Final Rule sets up national reimbursement under a hospital outpatient payment system for a specific AI-assisted cardiac imaging service, CPT code 75577, which covers AI-enabled quantitative coronary plaque analysis from CT angiography. The same rule declined to finalize a broader payment pathway for AI-driven clinical software generally, so this is a narrow but real win. The AMA's CPT Editorial Panel has gone further and established Category I codes, the permanent, fully recognized kind, for AI-assisted retinal imaging analysis and for coronary CT angiography plaque analysis, while other cardiac AI applications remain in the provisional Category III status. More codes are reportedly under consideration. Reimbursement infrastructure for AI-CDS is being built now, piece by piece, not just argued about in policy papers.

Platforms trying to shortcut the adoption gap through distribution rather than enterprise procurement

Some companies are going straight to the clinician instead of waiting for hospital procurement cycles to catch up. They're going straight to the clinician instead.

Doximity gives physicians free access to scribe tools and conversational AI, often on personal devices, with minimal friction compared to formal enterprise EHR integration. Uptake has been fast for exactly that reason: there's no procurement committee, no IT sign-off, nothing standing between the clinician and the tool. The cost is that it never really embeds into the clinical workflow itself, since it sits alongside the EHR rather than inside it.

OpenEvidence takes a similar distribution approach, delivered free directly to clinicians, and it's building trust at the point of care by doing what the framework in the prior section describes: citing its sources clearly enough that physicians in the Hurt et al. evaluation rated it as clear and well-supported.

Wolters Kluwer took a different route in September 2025, launching an Expert AI assistant that layers generative AI on top of the UpToDate library, a reference clinicians already trust and already use daily. Instead of keyword search, clinicians can ask questions in plain language. The AI doesn't need to earn trust from zero, because it's riding on a brand that already has it.

Epic, meanwhile, is building AI natively into the EHR itself, which sidesteps the integration barrier by keeping the system unified from the start. By 2025, Epic reported somewhere between roughly 160 and 200 active AI projects, with more than 150 additional AI features planned for 2026. That includes AI-assisted charting, a set of AI assistants named Art, Penny, and Emmie, and a generative foundation model called CoMET, trained on Epic's own Cosmos real-world patient dataset.

The tension between these two approaches doesn't resolve cleanly. Direct-to-clinician tools win trust fast but stay outside the institutional workflow. EHR-native tools integrate directly but move at the pace of enterprise IT, which is to say, slowly.

Why barriers compound across layers rather than stacking independently

The HOT framework names three separate clusters, human, organizational, and technical, but treating them as three parallel lists misses how they feed each other.

Consider what happens when a clinician doesn't trust a tool. They won't bother reporting when it gets something wrong, since flagging failures takes effort and they've already mentally written the tool off. Without that feedback, the organization has no signal the tool needs fixing for its local patient population. The tool never improves for that context, the errors persist, and the original distrust just gets confirmed. That's a closed loop, and nothing inside it points toward a fix.

A second loop runs through data. An organization without unified infrastructure feeds its AI incomplete records, so the AI's recommendations are working with gaps it can't see. Errors follow, clinicians notice the errors and stop trusting the output, adoption stalls, and without adoption, there's no usage data to build an ROI case for the infrastructure investment that would have fixed the problem at the root. The organization stays stuck exactly where it started.

A third loop runs through alert fatigue specifically. Clinicians trained to ignore alerts by years of low-value rule-based warnings will ignore a better, machine-generated alert too, at least at first, simply out of habit. That means learned desensitization at the human layer hides the fact that the technology layer actually improved. Nobody notices the improvement, so nobody credits it, and the tool gets judged by the reputation of the systems that came before it.

The path forward for health systems, tool developers, and clinical teams

Health systems need to treat data integration as the foundation. With 62% of organizations naming it the top blocker, it belongs in the same conversation as capital planning and facility investment, not filed under routine maintenance. Adoption tends to follow clinical champions who are convinced. Governance built around continuous monitoring needs to start on day one, because the EU AI Act and the FDA's newer guidance expect it, and because clinicians are watching for ongoing scrutiny that earns trust over time.

Tool developers face a parallel set of choices. Source verification and audit logging aren't features to bolt on after the compliance team asks for them. Based on the Frontiers in AI framework and on how physicians responded to OpenEvidence, they look more like a precondition for anyone actually using the tool. Cutting the volume of alerts and raising the specificity of the ones that remain will do more for adoption than adding another feature to the list, since alert fatigue is fundamentally a trust-destruction mechanism, not a mere annoyance. And where EHR integration isn't an option yet, a direct-to-clinician model can plant the seed of trust early, so long as developers plan for the fact that workflow integration will eventually be non-negotiable for the tool to stick.

Clinical teams have a role here too, and it isn't passive. The JMIR review from Tun et al. names comprehensive training as one of the core mechanisms for building trust in AI-CDS, and teams that understand what a model can and can't do are the ones who calibrate their trust correctly instead of over- or under-relying on it. Getting involved in how these tools are designed, not just how they're eventually used, is the stakeholder involvement the research keeps coming back to as necessary, not optional.

The 2026 reimbursement moves, the OPPS rule and the AMA's new CPT codes, create a financial logic for specific AI-assisted services that had not previously had permanent reimbursement recognition. Once the money follows the evidence, the rest of the adoption curve tends to move faster than anyone expects.