Xantrion joined healthcare and technology leaders at the California Healthcare Innovation Conference to take part in the featured panel, “From AI Hype to Healthcare Impact: A Practical Readiness Approach.” Alongside Suman Mishra of EnsureCare and Iago Maciel of Reefo, we discussed what healthcare organizations need to put in place before AI can deliver measurable value: clear use cases, reliable data, practical governance, and the operational discipline to move from experimentation to adoption.
The missing middle between interest and outcomes
Healthcare organizations don’t lack interest in using machine learning and generative tools. What they often lack is the connective tissue between interest and results: the practical readiness to choose the right work to change, run it safely, and show that it made a difference. In a recent panel run-through, that “missing middle” kept coming up as the real point of the conversation. It is less about new capabilities, more about what has to be true inside the organization for any of it to hold up in day-to-day operations.
Redefining readiness: execution, not artifacts
One clear thread was that readiness can’t be defined by the existence of a committee, a modern data platform, or a list of approved vendors. Those are inputs. Readiness is demonstrated by execution: the ability to select a workflow that matters, define the problem in measurable terms, govern the risks that come with changing clinical and operational decisions, and make the solution usable enough that it actually gets adopted. When those pieces aren’t in place, teams tend to move from headline-driven enthusiasm to pilots that don’t survive contact with reality.
The practical questions that predict whether a pilot will stick
The panelists kept circling back to a small set of grounding questions that tend to expose whether an initiative is ready to proceed or simply trying to move quickly. What workflow, specifically, is being changed? What is the pain point in that workflow that leadership agrees is worth addressing now? What data is required to support the change, and is it accessible and reliable in the form the project needs? What governance applies (privacy, security, compliance, clinical safety) and who is responsible for meeting it? Most importantly, who owns the workflow operationally, with both authority and accountability? Those questions aren’t academic. They decide whether an initiative will be something staff can use without creating parallel work, exceptions, and confusion.
When “we need an AI strategy” really means “we need a decision system”
This is where the phrase “we need an AI strategy” can become unhelpful. In practice, it often means “we need to do something so we aren’t behind.” The panel’s implicit counterpoint was that a real strategy should function less like a declaration and more like a decision system. It should help teams prioritize use cases, define what “value” will mean before work begins, manage risk without turning governance into a stop sign, and prevent the pattern of disconnected pilots that each solve a narrow problem but never add up to a program.
A better ROI question: how do you choose the first project out of twenty?
The discussion about return on investment landed in a similar place. Instead of debating how to calculate ROI perfectly, a conversation that can quickly become abstract, the more useful question was framed as a selection problem. If you have twenty plausible projects, how do you pick the first one? That shift matters because it keeps the team out of theoretical arguments and forces a practical comparison across initiatives. It brings the right criteria into the open: impact on an agreed operational metric, clarity of the workflow, whether the data needed is truly ready, the risk profile and how it will be managed, likelihood of adoption, and whether the financial story is credible enough to clear internal scrutiny. ROI remains part of the decision, but it sits alongside feasibility and operational fit, which is usually where projects succeed or fail.
Operational ownership is the difference between a demo and a deployed change
Another point that surfaced repeatedly is that ownership is not interchangeable with sponsorship. Projects often have executive support and still stall because no one owns the workflow end-to-end. Without an operational owner who feels the current pain, can change the process, and will be accountable for outcomes, teams end up building something that works in a demo but doesn’t land in real practice. The panel’s emphasis on keeping answers short and grounded was really a proxy for this: if you can’t explain the workflow, the owner, the proof, and the risk controls plainly, the project likely isn’t ready to scale.
The Monday-morning checklist: one workflow, one owner, one proof standard
The strongest “Monday morning” takeaway from the run-through was intentionally simple: pick one workflow, define the measurable pain point, identify the owner, and decide what proof would make the project worth expanding. From there, confirm the data path and governance requirements early, then design around adoption rather than novelty. This is not about moving slowly; it’s about preventing the common failure mode where a pilot produces interesting output but no operational change. If the proof standard is clear at the start: what improves, by how much, compared to what baseline, then teams can make better decisions faster about what to scale, what to revise, and what to stop.
Readiness is the capability to scale outcomes
Taken together, the panel’s message is straightforward: the hard part isn’t getting a tool in the building. The hard part is building the capability to consistently choose high-value workflows, manage the risk that comes with changing decisions, and demonstrate outcomes in ways that finance and operations will accept. That capability is what readiness should mean, and it’s the difference between a year of pilots and a program that improves how work gets done.
