The goal of triage is not always to know exactly what is wrong. Sometimes it is to know what should happen next.
One of the easiest mistakes to make when thinking about AI in healthcare is to assume that usefulness requires certainty.
The patient describes a problem. The model identifies the condition. The system gives an answer.
Clean.
Healthcare is rarely that cooperative.
A patient can present with symptoms that support several possible explanations. Important information may be missing. Sometimes the safest decision has to be made before anyone knows exactly what the diagnosis is.
That changes how I think AI triage systems should be designed.
In our pilot study at the University of Abuja Teaching Hospital, we used MedGemma in a multi-turn triage system that classified cases into three urgency levels: routine, urgent and emergency. Those classifications determined what happened next. An emergency classification directed the patient toward in-person care rather than a virtual consultation.
The model's job was therefore narrower than answering:
What disease does this patient have?
The more immediate question was:
Given what we know right now, what should happen next?
That distinction matters.
Triage does not require complete diagnostic certainty
Diagnosis and triage are related, but they are different problems.
Diagnosis asks what condition explains the patient's symptoms.
Triage asks how urgently the patient needs care.
Sometimes you can make progress on the second without resolving the first.
Imagine someone presents with severe chest pain.
There may be several possible causes. A conversational AI system may not have enough evidence to determine which one is responsible.
But it may still have enough information to conclude:
This person needs urgent in-person assessment.
That is a useful decision.
The system doesn't need to pretend that it knows the diagnosis when the evidence does not support one.
This is why I think one of the most useful design questions for clinical AI is not:
Can the model solve the entire clinical problem?
It is:
What is the smallest safe decision the available evidence allows us to make?
For triage, that might be routing rather than diagnosis.
Narrowing the decision is not necessarily reducing the usefulness of the system. It can make the boundary of the system clearer.
And in healthcare, clear boundaries matter.
Uncertainty should change what the system does
Suppose a patient says:
“I feel dizzy.”
There is not much to work with yet.
How long has it been happening?
Did it start suddenly?
Have they fainted?
Are they taking medication?
Is there chest pain?
Has this happened before?
At that point, forcing the system to produce an urgency classification may be the wrong behaviour.
The better behaviour may simply be to ask another useful question.
Our triage system was multi-turn and incorporated the patient's recorded history as context rather than treating every symptom as an isolated prompt.
The pilot also gave us a small clue that context mattered. Agreement was stronger in conversations with four or more patient turns, although the sample was small and the confidence intervals were wide, so that finding should be treated cautiously.
I don't think the lesson is simply that longer conversations are better.
They aren't necessarily.
Ten irrelevant questions are not better than three useful ones.
The more interesting design problem is whether the system can recognise that it does not yet have enough information and change its behaviour accordingly.
That means uncertainty has to have consequences.
If the system lacks relevant information, it should gather.
If enough information exists for a safe routing decision, it should route.
If the problem exceeds what the system should handle, it should escalate.
A system that says “I am uncertain” and then continues behaving exactly as though it were certain has not really managed uncertainty.
It has only described it.
The system needs an exit
This is the part I think matters most.
AI products are usually judged by how much they can do without a human.
Can the model answer more questions?
Can it complete more tasks?
Can it operate autonomously?
In healthcare, I am not convinced autonomy should always be the thing we maximise.
There should be cases where leaving the AI workflow is the correct system behaviour.
Our design had one explicit boundary: an emergency classification directed the patient toward in-person care rather than continuing into virtual consultation. Participants were also onboarded on the limitations of AI triage and the available escalation pathways.
That is not a failure of the system.
It is part of the system.
I would go further:
Escalation is a capability.
A good triage system should not be measured only by how many cases it can resolve independently. It should also be judged by whether it recognises the cases it should not resolve independently.
That is a different engineering mindset.
Instead of asking:
How do we keep the AI in control for longer?
Ask:
Under what conditions should the AI stop being the decision-maker?
There may be situations where another question reduces uncertainty enough to make a safe routing decision.
There may be situations where the system can make a limited decision without knowing the diagnosis.
And there may be situations where continuing to ask questions is itself the wrong choice.
High risk.
Conflicting information.
Symptoms requiring physical examination.
A context the system has not been adequately evaluated in.
At that point, the useful output may simply be:
Stop here. Escalate.
Confidence is not the same as evidence
There is another boundary worth keeping in mind.
Our study did not evaluate MedGemma in Nigerian languages or code-switched English. Participants with known physical disabilities were not represented, and the study was conducted at a single institution with a relatively small concordance sample.
That creates a different kind of uncertainty.
Not uncertainty about the patient's symptoms.
Uncertainty about whether the system's evidence base extends to the situation in front of it.
A model can sound completely confident while operating outside the population, language or context in which it has been adequately evaluated.
Its confidence doesn't solve that problem.
Evidence does.
That is why I would be careful about designing uncertainty management around confidence scores alone.
Our pilot did not directly evaluate calibrated model uncertainty, so I don't want to pretend it did.
What it does offer is a useful architectural starting point.
A triage system should not have one behaviour for every uncertain situation.
Sometimes it should ask.
Sometimes it should make a limited routing decision.
Sometimes it should stop and escalate.
The goal is not to eliminate uncertainty.
Healthcare probably won't give us that luxury.
The goal is to make sure uncertainty changes what the system does.
This article draws from my research, “Artificial Intelligence and Mobile Health Technologies for Improved Healthcare Access: Design and Pilot Evaluation of an Integrated Digital Health Platform for a Nigerian Teaching Hospital,” published as a medRxiv preprint in September 2026. The study was designed as a feasibility pilot and has been submitted for peer review. DOI: 10.64898/2026.09.02.26361014.