How a clinician-controlled health agent produces a recommendation

Published by Kalibra · Last reviewed 19 September 2026

A clinical AI recommendation should arrive with a receipt.

The receipt should show what changed, which sources support that conclusion,
what information is missing, which interpretation is being proposed, what
other explanations were considered, the smallest permitted next step, who must
approve it and when the result will be reviewed.

Without that chain, a polished recommendation is just an answer with hidden
workings. It may be right. The clinician has no efficient way to know why.

This guide describes a practical workflow for clinical decision support. It is
not a claim that every AI system, including every Kalibra deployment, performs
every step automatically. The point is to make the standard inspectable.

Kalibra's long-term architecture separates the jobs. Deterministic services
such as Kali handle rules, eligibility and repeatable workflow state.
Probabilistic intelligence such as Kay handles language, synthesis and
open-ended questions inside a governed harness. The blend matters because a
model should not mark its own homework.

Step 1: define the decision before collecting more data

The first question is not “What does the data say?” It is “What decision are
we trying to support?”

A follow-up review might need to decide whether:

• a material change needs practitioner attention;
• more information is required before interpretation;
• an approved action should continue, change or stop;
• no action is warranted.

That decision boundary determines which evidence matters. Without it, a system
can produce an impressive summary that leaves the practitioner with the same
work as before.

Step 2: build a source map, not a data soup

Suppose a patient reports fatigue after travel. Their wearable shows lower
sleep duration and recovery scores. A recent laboratory report is present, but
the collection date conflicts with the date in the clinic record. Two actions
from the previous plan are marked incomplete.

A weak system blends those facts into a narrative.

A stronger system first labels them:

The table is less eloquent than a paragraph. It is more useful because it
preserves the difference between evidence types.

Step 3: establish what changed

An agent should compare the current state with a relevant baseline, not with a
generic population average by default.

Useful questions include:

• What is genuinely new?
• What persists?
• What resolved?
• Which change is large enough to matter for this workflow?
• Did the measurement conditions change?

For the example above, the safest conclusion may be narrow: sleep duration and
reported fatigue changed after travel; the laboratory date is unresolved; the
care-plan status needs context.

That is not yet a diagnosis. It is a reviewable description of state.

Step 4: check what is missing

Fluent systems are good at making incomplete information feel complete.

Before proposing a next step, the workflow should ask what would materially
change the interpretation. In this example:

• When did the fatigue begin?
• Was the wearable worn consistently?
• What was the travel schedule?
• Why were the previous actions not completed?
• What is the correct laboratory collection date?
• Is there any information that requires urgent clinical review?

Missing-data checks should be specific. “More context may be needed” is true
and useless.

Step 5: separate deterministic checks from model interpretation

Not every task needs a language model.

A date comparison, threshold rule, dosage calculation or eligibility check may
be better handled by deterministic logic with a known formula. A language
model may be useful for extracting information from prose, grouping related
events or drafting a concise explanation.

The output should say which is which.

For example:

• Deterministic: sleep duration decreased relative to the patient's
  four-week baseline.
• Extracted: the questionnaire reports fatigue beginning after travel.
• Unresolved: two documents contain different collection dates.
• Interpretation for review: the recent changes may be travel-related, but
  the evidence is insufficient to attribute a cause.

This prevents generated language from acquiring the authority of a measured
fact.

In a hybrid workflow, the hand-offs should remain visible:

The model's flexibility is useful in the middle. It should not quietly seize
control of the beginning or the end.

Step 6: rank options, including no action

A decision-support system should not be forced to recommend intervention.

Its option set might be:

1. no action; continue monitoring;
2. ask the patient one or two targeted questions;
3. prepare a non-clinical follow-up for approval;
4. route the case for practitioner review;
5. hold because the evidence is contradictory or outside scope.

The best option is the smallest safe next step that resolves the important
uncertainty. In the example, that may be to correct the date conflict and ask
for travel and adherence context before any clinical interpretation.

The system has still done useful work. It has prevented a premature answer.

Step 7: create the recommendation receipt

Every consequential suggestion should be packaged in a form a busy
practitioner can challenge.

Recommendation receipt

• What changed: the smallest factual description of the new state.
• Why it may matter: an interpretation, clearly labelled.
• Sources: direct links to the record, result or report.
• Missing or conflicting information: explicit and prioritised.
• Alternatives considered: including no action.
• Proposed next step: one bounded action.
• Authority required: who can approve, modify or reject it.
• Follow-up: when the result or response will be checked.
• Stopping condition: what would halt the workflow.

This is more demanding than adding a “show reasoning” button. Generated
reasoning can itself be plausible but false. The receipt anchors the suggestion
to evidence, workflow state and decision rights.

Step 8: let the clinician make a real decision

A review screen is not meaningful if the practitioner can only click
“accept”.

They should be able to:

• inspect the source;
• correct the patient state;
• change the proposed action;
• reject it with a reason;
• defer it;
• assign it;
• see what will happen next;
• reverse it where reversal is possible.

The review burden also matters. A system that sends fifty low-value suggestions
to a doctor has technically kept a human in the loop while practically
creating an approval factory.

Clinical decision-support research on alert fatigue has shown the cost of
repeated, low-value interruption. Restraint is part of safety.

Step 9: close the loop

A recommendation is not complete when it is approved or sent.

The workflow should record:

• whether the patient received it;
• whether they accepted, deferred or declined;
• whether the action started;
• whether a response or measurement is due;
• whether the expected signal changed;
• whether a practitioner needs to reassess.

Otherwise the system optimises for issuing recommendations, not learning
whether anything useful happened.

What the agent must not do

It must not:

• hide conflicting evidence;
• convert missing data into an invented assumption;
• present a generated explanation as a verified causal account;
• collapse a population association into an individual diagnosis;
• treat model confidence as clinical certainty;
• send a consequential recommendation outside its authority;
• keep notifying until a patient complies;
• preserve a suggestion after the clinician has rejected its premise.
• allow a probabilistic model to set or waive its own safety rules;
• present a variable model output as if a repeatable clinical rule produced it.

A five-minute audit for your current system

Pick one AI-generated recommendation and ask:

1. Can I open every supporting source?
2. Can I see what changed from the relevant baseline?
3. Can I see what is missing or contradictory?
4. Is fact separated from interpretation?
5. Was no action considered?
6. Can the responsible clinician modify or reject the next step?
7. Is there a follow-up state after approval?

If three answers are no, the system is producing text, not accountable
decision support.

The practitioner should retain judgement. The system should retain
provenance.

Read what makes a healthcare AI system an agent,
explore Kalibra's approach to trust and clinician control or see
how health-data integration is scoped.

Sources

• US FDA. Clinical Decision Support Software: Guidance for Industry and Food
  and Drug Administration Staff. 2026.
• NIST. Artificial Intelligence Risk Management Framework 1.0. 2023.
• US ONC/ASTP. HTI-1 Decision Support Interventions and Algorithm
  Transparency resources.
• Obermeyer Z et al. Dissecting racial bias in an algorithm used to manage the
  health of populations. Science. 2019.
• Ancker JS et al. Effects of workload, work complexity, and repeated alerts
  on alert fatigue in a clinical decision support system. BMC Medical
  Informatics and Decision Making. 2017.

This guide is educational and does not provide medical or legal advice.