Most healthcare AI initiatives begin with a question about technology: which model, which vendor, which pilot. The organizations getting real value from AI are often starting with a different question — and it begins with the work, not the technology.
The question that starts most projects — and why it’s the wrong
“Where can we use GPT?” is how a surprising number of healthcare AI initiatives begin. It sounds like a reasonable starting point. It rarely leads anywhere useful.
The problem with starting from the technology is that it forces you to go looking for a use case to justify a tool you’ve already decided on. Somewhere in the organization, someone finds a plausible-sounding pilot, builds it, demos it well, and months later discovers that nobody actually changed how they work because the tool solved a problem nobody was measuring in the first place.
The organizations getting real, durable value from AI ask a different opening question: “Where are our people spending, say, 500 hours a month doing repetitive information work?” That’s a workflow question. It starts with a number someone can point to, a team that’s actually feeling the pain, and a problem that existed before AI was ever mentioned. The technology comes later — as the answer to a defined problem, not the starting premise.
A framework worth working through before any project begins
A simple sequence is useful before recommending any specific AI capability: Workflow → Pain point → Data → AI opportunity → Human role → Integration → Measurement.
Workflow. Name the actual process, end to end — not “clinical documentation” in the abstract, but the specific sequence a discharge coordinator or a claims reviewer runs through every day, start to finish. Vague workflow definitions produce vague AI projects.
Pain point. Where in that sequence does time, accuracy, or consistency actually break down? This is where the 500-hours-a-month question does its work — it forces a real number instead of a general sense that “this could probably be faster.”
Data. What information already exists to support fixing this, and what condition is it in? A workflow with a real pain point but no usable data behind it may not be ready for the AI solution you’re considering — it may need a data cleanup project first, and saying so upfront saves months of wasted pilot work later.
AI opportunity. Only now does the question of which AI capability fits actually make sense — document summarization, extraction, classification, retrieval, drafting. The right tool is a consequence of the first three steps, not a decision made independently of them.
Human role. Every workflow redesign needs an explicit answer to what a person still does, and why. Skipping this step is how a technically successful pilot turns into an adoption failure six months later — nobody clarified what changes for the humans still in the loop, so nothing changes at all.
Integration. Where does this actually live — inside the system people already use every day, or as a separate tool they have to remember to open? A capability that requires a workflow change on top of a tool change usually gets neither.
Measurement. Return to the number that started the process. If the pain point was 500 hours a month, the project isn’t done when the model works — it’s done when someone can show the hours actually dropped.
What this looks like in practice
Consider a hypothetical mid-sized pharmaceutical company whose medical-affairs team spends significant time searching across clinical studies, publications and internal documents to answer recurring questions. The instinct many organizations would follow is to look for a generative AI tool that “does medical research.” Working through the framework instead surfaces something more specific: the actual pain point is the time spent finding, cross-referencing and synthesizing information across fragmented sources.
The data need turns out to be a clean, current repository of relevant documents — with appropriate access controls and source information — so that the team can retrieve the right material reliably. The AI opportunity becomes a retrieval and summarization capability built on top of that knowledge base, not a generic chatbot. The human role remains central: the medical-affairs professional reviews the sources and the generated summary before using it in their work. Integration means putting the capability into the tools and knowledge environment the team already uses, rather than creating another destination they have to remember to visit.
Measurement is straightforward, because the pain point was quantified from the start — time spent finding information, time spent preparing responses, and potentially the consistency and completeness of the resulting work.
The model came later, once the workflow, data and business problem were clear.
Why this matters more in healthcare than almost anywhere else
Healthcare and life sciences organizations face a particular version of this trap, because the stakes of getting a workflow wrong are higher and the instinct to move cautiously is strong — which can make some teams more likely to pursue a visible pilot simply to demonstrate momentum, rather than doing the less exciting work of mapping the actual process first.
Starting with the workflow can actually shorten the path to deployment, because it reduces the risk of building something technically impressive that nobody adopts.
Current healthcare AI research points in the same direction. Healthcare leaders identify administrative efficiency and clinical productivity as major areas of potential, while integration, capability gaps, risk management and the ability to demonstrate value remain important challenges. The AMA’s current AI evaluation framework also explicitly includes workflow integration and ongoing monitoring as core areas to assess.
At Arisanaa, this is the approach we recommend at the start of an AI engagement, healthcare or otherwise: understand the workflow and the real pain point before any conversation about which AI capability fits. It’s a less exciting first meeting than a model demo. It’s also more likely to produce a solution that becomes a permanent part of how a team works.
If your team has a workflow you suspect is costing real hours but haven’t yet mapped where the actual pain point lives, that’s exactly where we’d start.
