Healthcare AI Adoption: Why Strategy Can't Be One-Size-Fits-All

The most typical answer to a failed AI rollout is about the model itself: the accuracy was poor, the vendor overbooked, the output was untrustworthy. However, in a conversation recorded during the Put Data First conference in Las Vegas, Ritu Chakrawarty, an engineer turned AI product strategist with nearly two decades across analytics, consulting, and enterprise AI, shares a different view. In her experience, products seldom fail because of a bad model. Rather, the failure is due to the potential users of the product being unprepared for such an offering due to various factors, which include the tool not being embedded in their workflow, the tool being complex to use, the change being too disruptive, and the unwillingness to give up the comfort of the status quo.

This perspective shift is significant, as it means the greatest challenge of AI is not the algorithm, but rather the alignment of the tool to the actual users. At Hutchins Data Strategy Consultants, this scenario is often presented to us when clients inquire why a technically robust system was not positively embraced by its target users. The key takeaway from Chakrawarty's remarks is that healthcare AI strategy cannot be deployed from a template; rather, it must be customized to the potential value, the available data, and the everyday work being done.

Start From Value, Not From the Tool

Chakrawarty, who was involved with AI product strategy, had the experience of developing in a fast-moving, daily evolving marketplace. The first decision to be made was whether to build or buy, whether to create a clone, or whether to buy a base product and build additional features. The decision was difficult. Her approach focuses not on the tool but on what value can be gained from the product. She emphasized understanding the high-priority use cases where quick wins in revenue or cost saving would be most beneficial, and the low-hanging fruit would be considered most important, rather than the most impressive product demo.

Chakrawarty was careful to not give way to an AI-first approach. She was careful to add that even though AI may be the most appealing tool, not all product-related challenges are AI-related, and the most difficult aspect of focus is avoiding the temptation to think that every use case gap can be an AI opportunity, especially in healthcare where, as she noted, a situation in which a single solution manages to address only a small piece of a larger critical gap may very quickly become costly.

The Should-and-Could Test

Chakrawarty uses a quick litmus test to keep the value lens honest before committing to a build. The first question is should. Is it really an AI problem, or could a simpler tool do the job? She provided an example of her own restraint: if it is a task that is easy to do for a human, she does not make it complicated and push it through a tool just to meet her goals and claim the feature. The second question is could. Do I have the digital data to support and verify it? Her reasoning is simple: if you cannot trust the data, you cannot use it, and you cannot support and use anything that runs on it. She treats that as the first real test of whether adoption is even possible.

What the should-and-could test really does is that it screens almost everything out. A problem can clear the should test and still fail the could test if the data is not digital or not trustworthy. What do make it through both questions are the only candidates that are worthwhile to build, and that is how the tools that no one needs are kept from growing in number.

Designing for Adoption: Stop, Easy, and Flow

Chakrawarty provides a great example of how to design for use. She articulated a sort of design framework called stop, easy, and flow, and integrates her eventual users into the design process as opposed to providing them with a prototype as the finished product.

The stop question asks what a person stops doing once the product comes, and is designed to surface what the new tool replaces instead of sitting in the tool's periphery. Flow means the new tool has to reside within the existing work. As an example, Chakrawarty described a scenario in which someone is analyzing data and needs to ask a question in order to proceed with the analysis. Instead of breaking off into another chat window, the person is better served if the new tool is designed to allow for the question to be asked in context. Last, easy is the test of friction. The tool is better served if it requires a natural step in order for the person to proceed, instead of three or four setup steps. Chakrawarty's argument is that in order for a tool to be useful, it must be designed so that use is the default action.

She paired this with what she calls a signal for knowing whether the work is landing. If people keep returning to something that is only a partial solution, that is the signal that they find the work of value, and it gives you a clue about what to improve. In her case, adoption is not assumed, it is something you look for.

Trust, Fear, and the Threat to the Job

The resistance Chakrawarty described is less about technology and more about culture and emotion. People fear the tool is coming for their job, and the tool adds one more line to a long list of work that is expected of them. Her counter is built into the stop question turned forward. Rather than asking what is one more thing you want a person to do, she asks what the tool will help them do that they want to do but cannot do today. Framed that way, the tool helps a person become a more capable version of themselves.

Chris Hutchins made a comparison to data analysts. Based on what he said, they spend considerable amounts of time shaping data to meet standards for analysis and spend minimal time on the analysis of the data. When that shaping process is automated, they feel their worth is diminished because their value is in the technical work. The answer to both is the same. Real value lies not in the command of the technology, but in the ability to exercise judgment about the problems to be solved and the ways to go about solving them. When the tedious tasks are automated, it allows them to do the work for which only they are qualified, and saying that plainly is part of restoring confidence in the process.

Literacy Has to Be Sponsored From the Top

Chakrawarty cites the cause of the anxiety as being the uncertainty of what is to come. The solution is to educate people. This is why she emphasized that AI literacy, especially within the context of the workplace, is of utmost importance, and asserted that it must be sponsored from the top. She emphasized that when people understand the tool and the reasoning behind its existence, then the integration of the tool will be easier. When this understanding is lacking, people begin to make their own assumptions, which in turn creates resistance.

Kicking off the sponsorship with a leadership activity she prefers, she asked the leader to record a brief video showing the tool helping them do in one take what used to take five, and then show the video to the team and ask for feedback. When employees observe that the CEO is not only utilizing the tool but is not afraid of it, the question flips to why they would not use it themselves. The institutional knowledge people hold, the way the data behaves, and the recipe for how the work really gets done, does not become worthless; it is part of why a good tool needs the people around it. When this is understood, she said, the barriers loosen and adoption follows.

Every Leader Needs an AI Advisor Who Blends Business and Technology

Chakrawarty's final theme focused on who directs the strategy. She started not with AI but with self-awareness. A leader must understand where their strengths lie, identify their weaknesses, and be honest about the gaps. She then asserted that every CEO must have an AI advisor reporting directly to them, and was firm that folding the role into an existing seat by default is a mistake. AI tools can give a leader a starting point and provide them with some self-education; however, she saw that as superficial against the stakeholder responsibility a chief executive actually carries.

The advisor she describes is specific. One who restricts their understanding to technology cannot fill the advisor role because of the business understanding gap. The ideal candidate is a generalist who has achieved business results and also possesses substantial technical depth. Hutchins offered the mirror image from the technical side, in that the best technical people are biased toward doing technical work. This is exactly what is desired from them, and therefore, the marrying of business and technology is left to a rarer kind of person.

How Hutchins Approaches Healthcare AI Adoption

Our work treats adoption as a design and leadership problem, not a download. We help organizations decide where AI is genuinely the right answer and where a simpler fix wins, scope tools against trustworthy data rather than ambition, and design them to sit inside existing workflows so they remove steps instead of adding them. That sits alongside the AI literacy work that turns fear into informed use, and the broader healthcare AI consulting discipline that keeps tools in production once they land. The strategy is tailored every time, because the value at stake, the data on hand, and the people doing the work are never the same twice.

These themes run through The Signal Room podcast, where practitioners describe what it actually takes to move a tool from a clever demo to something people choose to use.

Authoritative sources

• WHO — Ethics & governance of AI for health
• NIST AI Risk Management Framework
• Agency for Healthcare Research and Quality
• NEJM AI
• HIMSS