AI in health: one workflow at a time

One response to AI is to pause: commission strategies, establish governance forums and wait for the data estate to be "ready". Another is to launch a parade of pilots: ambient documentation, coding, contact-centre automation, triage, rostering. Sound familiar? Neither of these paths necessarily changes daily operations or leads to meaningful success.

The wrong unit of transformation

Boards and executive teams are often presented with AI as a technology agenda: a platform decision, an enterprise data programme, a policy suite, a capability uplift and a portfolio of use cases.

All of those may be necessary over time. But none is the basic unit of value.

The basic unit is a workflow that now performs better in the real world: fewer avoidable touches, shorter waits, less duplication, clearer hand-offs, more clinician time, fewer errors, or lower cost to serve.

Healthcare has no shortage of technology that looks convincing in a demo, then falls apart when it meets a hectic Monday morning. A tool can give the right answer and still make a team's day harder if it adds steps, makes people second-guess their judgement, requires more checking, breaks established hand-offs, lacks the information they need, or leaves no clear answer to: "Who owns this when something goes wrong?"

A pilot shows that a tool can work. A live workflow shows that people can work differently and that the organisation can support them to do it.

Choose the first workflow with discipline

The first workflow should not be the most exciting AI opportunity. It should be the one most likely to create credible evidence within a short, controlled period.

A strong first candidate meets five tests:

1. It has enough volume for improvement to make a credible impact.
2. One executive owns the outcome and has authority to change the process.
3. The safety risk is low and the consequences of error are contained.
4. The required information is accessible without a major integration programme.
5. Success can be measured in a number already understood by the executive team.

In health, this often points to administrative or operational work before clinical decision-making. Examples include referral handling, clinical correspondence, coding quality assurance, discharge documentation, prior authorisation, procurement queries, rostering, invoice exceptions or patient contact-centre work.

This is not a retreat from clinical AI. It is how an organisation builds confidence and experience to use AI in higher-consequence settings. The first workflow builds the practical muscles that later clinical work requires: governance, validation, escalation, monitoring, staff training and integration into the workday.

Begin with the work, not the technology

The most common implementation mistake is selecting a tool before agreeing how the work should change.

Start by mapping the current workflow in enough detail to expose friction:

• Where does work wait?
• Where is information re-entered, copied or chased?
• Which decisions are routine, and which require professional judgement?
• Where do errors or rework occur?
• What exceptions are common?
• Who has authority to change each step?

Then design the future workflow. Be clear about which tasks will stop, what will become easier, how people will use their judgement alongside the system, and how they will recognise, challenge and respond to uncertain or incorrect outputs. Only then should technology selection begin.

This prevents the familiar outcome in which a capable tool is bolted onto an unchanged process and staff inherit another screen, login or review task. AI should remove work or improve a decision or an outcome. If it simply relocates effort, it is not a meaningful result.

Give one person ownership of the result

AI projects often have many sponsors and no owner.

The accountable owner should be the executive responsible for the operational outcome, not simply the CIO, digital lead or innovation team. If the target is referral turnaround time, the owner should be able to change the referral process. If the target is reduced documentation burden, the owner must have credibility with the clinicians and managers whose work will change.

Their job is to own the process and the result, not a piece of software.

The owner should facilitate agreement on at least one primary measure before work begins. It might be median turnaround time, cost per completed case, the proportion of work resolved first time, clinician minutes released per consultation, backlog volume, error or rework rate, or patient waiting time.

A secondary safety or quality measure should sit beside it. Faster processing at the expense of quality, privacy or staff workload is not a win.

Treat governance as part of the service

In digital health, governance is not a compliance step added after the solution is built. It is what makes the solution safe, trustworthy and usable in real care.

For every AI-enabled workflow, operators should be able to answer a short set of practical questions:

• What decision or task is the system supporting?
• What information does it use, and where does that information go?
• What is the human role in reviewing, accepting or overriding its output?
• What errors are plausible, and how will they be detected?
• Who handles exceptions or incidents?
• What will be monitored after launch?
• Under what conditions would the workflow be paused or withdrawn?

These questions apply to administrative work as much as clinical work. A drafting assistant that sends incorrect correspondence, exposes sensitive information or creates unreviewed documentation is still a safety and trust issue.

Good governance helps teams move with confidence. It gives staff clear boundaries: what they can use, what they need to check, and when to involve someone else.

Design adoption before build begins

A good test is whether the team can clearly explain how the new way of working will fit into a normal, busy day.

That means answering:

• Which staff will use it?
• What will they no longer do?
• What new judgement or review is required?
• How will they learn the workflow?
• What happens during peak demand, downtime or unusual cases?
• How will frontline feedback change the design after launch?

This matters particularly for clinicians. Trust is not created through a project promise or a training module; it is built through experience. Clinicians need to be involved in shaping the workflow, understand what the tool can and cannot do, and retain meaningful professional judgement over its use. Trust grows when the tool is reliable in the realities of care, fits naturally into existing systems and hand-offs, reduces rather than shifts administrative burden, and when feedback leads to visible improvements.

Successful implementation teams include the people who perform the work every day. They see the exceptions, workarounds and downstream consequences that process maps usually miss.

A practical 90-day starting pattern

A 90-day window can provide a disciplined way to create evidence.

Days 1 to 30: Select and define.
Choose one workflow. Name the accountable executive. Establish the baseline measure and the safety measure. Assemble a small multidisciplinary team: operational lead, frontline users, technology, information governance, risk and procurement as needed.

Days 31 to 60: Redesign and prepare.
Map the current work and agree the future-state process. Decide where human review sits. Select or configure the smallest viable technology solution. Test with realistic cases, including edge cases and failures. Prepare training, support and incident handling.

Days 61 to 90: Launch in production and learn.
Use real users and real work, initially in a controlled scope. Monitor performance, quality, safety and user experience. Fix the workflow as well as the technology. Report the results honestly, especially if the expected value did not materialise.

That final point matters. A credible organisation does not use the first workflow to validate a predetermined answer. It uses it to learn whether it can safely move from idea to operational change.

Build capability as a consequence of delivery

Health organisations need stronger data, digital capability, practical governance and leaders who can make informed decisions about AI. But these capabilities do not need to be perfected upfront. Trying to build them all at once can delay the improvements patients, clinicians and staff need now.

A compounding loop makes the idea easier to grasp: each workflow delivers an improvement now while strengthening the organisation’s ability to deliver the next one.

The answer is to build only the amount required for the next real workflow, then reuse it. For clinical use cases, this includes ensuring the tool can work with complete, current and clinically meaningful information. Systems being connected is not enough: semantic interoperability is needed so that a diagnosis, medication, result or care-plan item carries the same meaning wherever it appears. Without it, AI can produce a polished response based on an incomplete or misunderstood clinical picture.

The question for leaders

The right opening question is not: "Where can we use AI?"

Ask instead: "Which important workflow are we prepared to improve, change, measure and own?"

If there is no clear answer, the organisation is not yet ready to turn AI investment into meaningful improvement, regardless of how advanced its technology strategy appears.

If there is one, start there. Make the improvement safe, practical and measurable. Use what you learn to improve the next workflow.

Related: Transformation friction, on why change stalls between a temporary project and the permanent organisation. The first 90 days, on making a deliberate start in a senior role. Digital health advisory.