Evidence before task approval
How to Review AI-Generated Follow-Up Tasks Before Approving
Inspect source, identity, conditions, authority and version before approving an AI-generated clinic task, with a worked conditional-referral example.
Reviewing an AI-generated follow-up task means deciding whether this exact proposed action is supported, complete and authorised for this patient and this moment. A fluent description is not enough. The reviewer needs to see what the consultation established, what the system inferred, what somebody added afterwards and what will happen if approval is given.
This guide is for clinicians, clinic coordinators and implementation teams designing that review step. It provides an operational method for checking administrative proposals around an approved care plan. It does not turn a task reviewer into a clinical decision-maker. The wider service scope is described in clinic consultation follow-up services.
Separate preparation, clinical authority and permission to execute
Before examining the task, identify what the approval button means. It might approve a draft for another professional, authorise an administrative request, or permit an external communication. Those are different decisions. A person who may correct a department name does not necessarily have authority to approve a referral or disclose information to that department.
Write an action-specific approval rule with the clinic's accountable owners. Specify the reviewer role, the information they must inspect, the circumstances requiring another professional and the permitted destination. An action that falls outside the rule should remain unresolved with a named escalation owner. Do not let the system convert a lack of authority into an ordinary missing-field warning that anybody can dismiss.
Keep patient agreement, lawful processing and channel permission distinct from internal approval. A clinician's approval of an administrative action does not automatically validate a phone number, a proxy recipient or a messaging channel. These checks may draw on different evidence and require different staff. The human oversight guide explains how to allocate the wider decision rights.
Make the source available without exposing the whole consultation
The reviewer should be able to connect the proposal to the relevant approved source: a passage from a consultation, a clinician-entered instruction or a current care-plan item. Show the necessary context, including a condition or correction that changes the meaning. An isolated phrase such as “send the referral” is misleading if the next sentence says to wait for the clinician's review.
Mark the origin of each important field. A recipient copied from the conversation differs from a directory match selected by a coordinator. A date explicitly stated by the clinician differs from a date calculated from relative wording. Both may eventually be correct, but the reviewer needs to know which transformation occurred and who supplied any missing detail.
Source visibility should follow the reviewer's access rights. A booking colleague may need an approved scheduling instruction without access to the complete sensitive history. Avoid distributing full transcripts merely because showing more text is easier to implement. Keep the minimum relevant evidence accessible through the approved system, with a route to the appropriate professional when the permitted context is insufficient.
Check the proposed action in a deliberate order
Start with identity and purpose before polishing wording. A beautifully written request attached to the wrong person is still wrong. Use the clinic's approved patient-identification process and current encounter context; do not rely on a familiar name, the order of open browser tabs or a language model's guess from the conversation.
| Check | Question for the reviewer | Reason to hold |
|---|---|---|
| Patient and encounter | Does the proposal belong to the verified context? | Identity or encounter is unresolved |
| Meaning and scope | Does it preserve the authorised instruction? | Unsupported action or missing condition |
| Owner and destination | Can the named person and receiving service accept this work? | Role, authority or destination is unverified |
| Timing and prerequisites | Are the approved timing and dependencies explicit? | A date was guessed or a prerequisite is unmet |
| Communication | Are recipient authority, channel and content appropriate? | Contact or disclosure conditions are unresolved |
| Version and outcome | Is this the exact version to execute, with a defined result? | Content changed or success cannot be verified |
Then inspect the action type. Preparing a document for clinical review is not the same as sending it. Requesting an appointment is not the same as confirming one. Updating an administrative field is not permission to alter a clinical record. The task description, approval label and destination operation should all express the same level of authority.
Finish by checking whether the task is still necessary. A colleague may already have resolved it, the consultation may have been amended or the patient may have requested a different communication arrangement. A duplicate proposal can be accurate to an earlier source and still be inappropriate to execute now.
Read conditions, negation and relative dates as decision-critical information
Small words can carry the whole restriction. “Prepare,” “consider,” “if,” “after” and “do not send” should not be normalised into an unconditional instruction. Keep the condition attached to the action itself, not buried in a summary that the next operator may never read. If the condition cannot be represented reliably, require clarification or a controlled manual route.
Relative dates need an explicit reference point and calendar interpretation. “Next Tuesday” depends on when and where the statement was made; an administrative deadline can also differ from a clinician's intended care timeframe. Display the proposed resolved date for confirmation, preserve the original expression and avoid inventing timing when the source did not specify it.
For Arabic-English consultations, check the operative meaning in both languages. A polite suggestion must not become an order, and a conditional Arabic phrase must not disappear when translated into a concise English task. A bilingual reviewer should assess the relevant professional context. The bilingual follow-up workflow gives a broader method for preserving meaning across the handover.
Do not ask an administrative reviewer to settle a clinical ambiguity through interpretation. The appropriate outcome may be a question to the clinician, with the proposed action held. Record the exact point needing clarification so the professional can answer it without reconstructing an entire conversation.
Work through a conditional referral example
Use a fictional instruction: “Prepare the referral draft for my review. Do not send it until I have checked the attachment. Ask the coordinator to confirm the receiving department.” The expected administrative output contains separate preparation, verification and approval needs. It contains no authority to send the referral immediately.
Suppose the generated list contains “Send referral to the specialist,” marks the attachment complete and chooses a department from an old directory entry. The reviewer should reject or return that proposal for correction. Changing only the wording to sound more cautious does not fix the unsupported attachment state or destination.
A corrected proposal should identify the draft, retain the clinician-review condition, show that the attachment remains unchecked and assign destination verification to the coordinator. If the clinician later approves a particular version, the execution path must use that version and recheck the necessary recipient and system conditions. The initial consultation text alone cannot establish those later facts.
Now change the attachment in the test environment after approval. The workflow should require the relevant review again rather than treating the previous approval as a permanent entitlement. This exposes whether approval is attached to a visible set of details or merely to a task identifier whose contents can change unnoticed.
Look for missing commitments as well as incorrect tasks
A review limited to the displayed proposals cannot detect an action that was never extracted. Ask the appropriately authorised professional to compare the proposed set with the approved source or an independently confirmed commitment list. The goal is to identify required administrative work that is missing, while respecting who may inspect the underlying clinical context.
Also check whether one proposal has combined several responsibilities. A single item saying “arrange everything” can conceal separate scheduling, document preparation and patient communication work with different owners. Conversely, several near-identical proposals may describe the same commitment. Resolve the action boundaries before approval so that neither omissions nor duplicates are hidden by a neat-looking list.
Record why a missing item matters and how it was restored. If omissions recur with conditional or mixed-language instructions, preserve those cases for investigation under the clinic's approved data-handling arrangements. The AI coordination failure guide explains how to investigate the mechanism. Correcting an individual list is necessary, but it does not by itself show that the recurring extraction problem has been resolved.
Give the reviewer more useful choices than approve or ignore
A practical review process distinguishes correction, clarification, rejection, deferral and approval. Correction changes a detail within the reviewer's authority. Clarification requests missing meaning from the right source. Rejection records that the proposed action should not proceed. Deferral records a real unmet condition and an owner who will revisit it. These outcomes should not all disappear into an undifferentiated “not approved” folder.
Require a useful reason where it affects the next person. “Wrong recipient” should identify the unresolved destination question without exposing unnecessary clinical information. “Waiting” should state what is awaited and who owns the next check. A rejected proposal may need to remain available for quality investigation, but it must not remain eligible for execution.
Use a structured clarification handover. AHRQ's check-back guidance describes a recipient confirming the information and the sender confirming that understanding. Applied to this administrative review, the principle helps ensure that a response actually resolves the question. A notification that somebody opened a clarification message is weaker evidence.
Design the approval screen around meaningful inspection
Keep action, source, changes, recipient, timing and dependencies close enough to inspect together. Show the difference between the original proposal and the corrected version. Make unresolved critical fields conspicuous, and use labels that distinguish approval of a draft from permission to send or update a destination system.
A batch approval feature needs a bounded use case. It should not hide different recipients, incompatible action types or unresolved clinical dependencies behind one checkbox. Where the clinic permits reviewing a group of routine administrative items together, define eligibility and show exceptions individually. The operating policy should make it possible to reject an unsuitable batch without losing the underlying work.
Measure review burden in realistic conditions. Include interruptions, mixed-language cases and requests arriving near the end of a session. If the interface requires repeatedly opening several screens to understand a single action, the fix may be to improve the evidence presentation or narrow the scope. Reducing the inspection requirement simply to achieve a faster average defeats the purpose of review.
Record what was approved and what happened afterwards
The approval record should identify the action version, reviewer, relevant role, time, scope and conditions. Keep changes after approval distinguishable from the approved content. The audit-trail guide explains how to reconstruct the path without copying sensitive consultation material into every log entry.
Approval is one event in the workflow. Record submission, destination acknowledgement, rejection and uncertain outcomes separately. If the destination refuses the request or the network result is unknown, the system should not present the action as successfully completed. Someone must own reconciliation and any communication needed to correct the patient's expectations.
Define when a task returns to review. Changes to the patient context, intended action, destination, attachment, timing or communication authority may invalidate the previous decision. The rule should reflect the nature of the change and the clinic's governance. Reusing an old approval because the task number has not changed is not an adequate version-control policy.
Evaluate reviewer performance with deliberately imperfect proposals
Build a synthetic set with independently agreed expected outcomes. Include unsupported additions, omitted dependencies, wrong recipients, changed attachments, ambiguous dates and a valid proposal that should be approved. If every test contains a mistake, reviewers may learn to reject everything; if every test is clean, the evaluation says little about error detection.
Measure consequential mistakes separately from cosmetic edits. A missing condition and a punctuation change should not contribute equally to an average correction score. Also track appropriate holds, unresolved clarification time and unnecessary rejection of valid work. Reviewers need enough feedback to learn why a decision was correct, not merely a pass mark.
WHO's ethics and governance guidance for health AI places human autonomy and responsibility at the centre of use. For this review process, that principle becomes a practical question: can the responsible person see, challenge and stop the proposed action? Assess that ability with the actual intended roles and access constraints.
To examine the review interaction, request an Echo walkthrough with a fictional conditional task. The public Echo demonstration allows proposed details to be checked before simulated follow-through. Use it to inspect the review experience, then separately establish the production permissions, clinical governance and integration evidence required by your clinic.
FAQ
Your questions, answered.
What information must be visible before approving a generated follow-up task?
Show the verified patient context, relevant source, proposed action, responsible role, destination, timing, prerequisites and exact version being approved. Distinguish source facts from added or inferred details. If essential information is missing, preserve the hold and route a specific question to the person authorised to resolve it.
Can an administrator approve a generated clinical referral?
Only within the authority established for that exact action. Preparing a referral draft or checking an address is different from authorising the clinical referral or disclosing its contents. The clinic should define the necessary professional approval and administrative checks, with a clear hold when either remains unresolved.
How should a reviewer handle a task inferred from conditional wording?
Keep the condition attached to the action and verify that the proposed state preserves it. If the source says to wait for an attachment review, the task must not become eligible for sending merely because a draft exists. Ask the authorised source to clarify any ambiguity before proceeding.
What happens if an attachment changes after a task was approved?
Assess the change against the approval rule and return the affected action for the appropriate review. The execution path must use the version that was actually authorised. Retaining the same task identifier does not make a changed attachment covered by the earlier approval.
Should reviewers use the AI confidence score as the approval threshold?
A score alone does not establish source support, clinical authority, recipient identity or current relevance. Review the evidence required for the action and test consequential failure cases. Confidence may be one interface signal if its meaning is understood, but it cannot replace the clinic’s approval criteria.
How can a clinic test whether reviewers notice important errors?
Use synthetic proposals with independently specified acceptable outcomes, including both valid actions and consequential mistakes. Test unsupported additions, omitted conditions and wrong recipients. Measure appropriate holds and unnecessary rejections as well as missed errors, and explain the reasoning during feedback rather than rewarding speed alone.
What should be recorded when the reviewer asks for clarification?
Record the specific unresolved question, the action version, the person asked and the owner responsible for following the response. Keep the action ineligible for the dependent step. A reply should resolve the question explicitly; an opened-message notification is not confirmation that the proposed instruction is correct.
Does approval mean the follow-up has been completed?
No. Approval authorises a defined next step. Submission, acceptance by a destination, booking, patient communication and clinical completion are separate outcomes. The workflow should report each supported state and leave failures or uncertain results with an accountable owner instead of converting approval into a success label.