AI agent workflows for Diagnostics labs & pathology

Build spec

2 agents — 1 fact-assembly agent (runs on every verified result — the high-volume step) + 1 escalation-scripting agent (runs only on the flagged minority). The numeric threshold check is a deterministic user-defined SpEL tool, not an agent; the ladder, the branch and the approval are workflow nodes. · Pattern: Deterministic SpEL threshold → cheap per-result agent → Condition → pathologist approval → Voice/SMS ladder in a retry Loop

System prompt (paste-ready)

You prepare ONE verified laboratory result for critical-value callback. The CRITICAL/LOW/NORMAL flag has already been computed deterministically by the `critical_flag` tool against this lab's signed table — take it as given and NEVER overrule it. Return strict JSON {critical, analyte, value, units, limit_breached, age_band, patient_ref, ordering_clinician, callback_ref}. You must NOT interpret the result, suggest a diagnosis, suggest treatment, or comment on the patient's condition. If units are ambiguous, the analyte is unmapped, or the ordering clinician cannot be resolved from the HIS, set needs_human=true with a reason — never guess a clinician and never assume a unit.

Agent roles & model tiers

• Fact assembler (per verified result) — Economy tier, with a configured fallback model for provider outages — runs on EVERY result, so this choice sets the whole bill; a lab cannot have callbacks stop because one provider is down

  Take the deterministic SpEL flag as authoritative, resolve the ordering clinician from the HIS, emit strict JSON. No interpretation, no diagnosis, no treatment comment. Unmapped analyte or unresolvable clinician ⇒ needs_human=true.

• Escalation scripter (per flagged value) — Standard tier with fallback — runs only on the flagged minority, where wording accuracy on a phone call matters

  Compose the callback script and SMS/WhatsApp backup for an APPROVED critical value: analyte, value, units, reference limit, patient identifier, callback reference, and the explicit read-back question. Facts only — no advice, no interpretation, no reassurance. Localise via Sarvam when the recipient's registered language is not English.

Guardrails

• The agent never diagnoses, never interprets a value, never suggests treatment — it reports only which documented limit was crossed
• The threshold decision is deterministic (the `critical_flag` SpEL tool over your signed table), so it cannot drift with a model change or a prompt edit; the agent is explicitly forbidden from overruling it
• The escalation is released by the on-duty pathologist at the Approval node — the agent proposes the call, a clinician owns it
• The approval timeout escalates UP the human ladder; there is no path in which the workflow calls a clinician without a human having released it
• Unmapped analyte, ambiguous units or unresolvable clinician ⇒ needs_human=true and routed to a person — no silent drop, no guessed recipient
• An exhausted ladder alerts a supervisor; the workflow can never close a critical value as 'done' by itself
• Every attempt and the read-back are written back keyed to `callback_ref` — auditable, and idempotent against a re-verified result

Cost strategy

Volume sits entirely on the fact assembler, which touches every verified result — economy tier, hard-capped, with a fallback model configured so a provider outage degrades to a second provider rather than to the paper register. The standard-tier scripter runs only on the flagged subset, so its price barely registers monthly. Note that moving the threshold comparison out of the model and into the SpEL tool also removes tokens from the highest-volume step: the cheapest inference is the one you don't make. Retries in the Loop replay the composed script, so they cost telephony minutes, not tokens.

Output & delivery

Every verified result hits the `critical_flag` SpEL tool for a deterministic verdict → a cheap agent resolves the clinician and assembles the callable fact → the Condition node splits routine from critical from unresolvable → the duty pathologist approves at the Approval node → an ElevenLabs Voice call plus SMS/WhatsApp backup runs the documented ladder inside a retry Loop until an explicit read-back is captured → a Tool (MCP) node writes the callback record into the LIMS, and an exhausted ladder alerts a supervisor instead of closing.

Build spec

2 agents — 1 mapper (once per rejected sample via the Loop node) + 1 reducer (once per batch). Chargeability is a deterministic SpEL tool; de-duplication is a Code node; the approval, the patient message and the write-back are workflow nodes. · Pattern: Map-reduce: Loop (map per sample, SpEL for policy) → Code de-dupe → reducer (one synthesis) → human approves cancellations, charges and messages

System prompt (paste-ready)

(Mapper) Triage ONE rejected specimen record. Return strict JSON {sample_id, test_ordered, reason_code (HAEMOLYSED|CLOTTED|QNS|WRONG_TUBE|UNLABELLED|TRANSPORT_TIME|OTHER), collector_ref, centre_ref, route_ref, charge_verdict (copied verbatim from the `recollect_charge` tool — never your own opinion), proposed_action (RECOLLECT_HOME|RECOLLECT_CENTRE|CANCEL|CLARIFY), patient_message_points[]}. Judge only from the record's own fields and the rejection-criteria SOP in Knowledge. Never infer a clinical meaning from a rejection, never state or hint at any result, and never mark a test cancelled — CANCEL is a recommendation a human approves. Malformed or ambiguous ⇒ proposed_action=CLARIFY.

Agent roles & model tiers

• Mapper (per rejected sample) — Economy tier with a fallback model — runs N times per batch, so it is the dominant cost term and must survive a provider blip mid-batch

  Classify ONE rejection into schema-valid JSON with a proposed action and plain-language patient message points; copy the chargeability verdict from the SpEL tool verbatim. No clinical inference, no result disclosure, no autonomous cancellation. Ambiguous ⇒ CLARIFY.

• Reducer (once per batch) — Standard tier with fallback — pattern-finding across the run, and the only output a manager reads

  Aggregate validated per-sample results into a run summary: reason-code distribution, recurring collector/centre/route/tube-lot clusters, the re-collect worklist, and items needing a human decision. Use only supplied items and cite real counts — never estimate a rate, never invent a trend.

Guardrails

• The agents only propose — every cancellation, every chargeable re-collect and every patient-facing message passes the Approval node before anything is written or sent
• Patient messages are strictly operational (what to repeat, how to rebook). No result, no clinical interpretation, no reassurance about what a rejection 'means'
• Chargeability is decided by the `recollect_charge` SpEL formula, not by the model — the agent copies the verdict verbatim and is forbidden from forming its own opinion about who pays
• Reason codes come only from your rejection-criteria SOP in Knowledge — no invented policy
• Schema validation per mapper output; a malformed record becomes CLARIFY and is queued for a human, never silently cancelled
• The Code node normalises and de-duplicates barcodes, and write-backs are idempotent per sample id — a re-sent export cannot double-cancel or double-charge

Cost strategy

Linear and forecastable: N × (economy-tier, hard-capped mapper) + ONE standard-tier reduce. The mapper runs across the whole batch so it must stay on the economy tier — that single choice sets the bill; the reducer's one call is where the reasoning budget belongs. Pushing the chargeability rule into SpEL removes the most token-hungry ambiguity from the per-sample step. Run the map in Parallel batches for wall-clock speed at unchanged per-sample cost, and configure a fallback model so a provider blip does not strand a half-processed run.

Output & delivery

The Loop maps a cheap agent over every rejected sample, with the `recollect_charge` SpEL tool deciding who pays → a Code node normalises barcodes and drops duplicates → the reducer produces one run summary with the recurring clusters → the lab in-charge approves cancellations, charges and messages at the Approval node → an Output node notifies patients on WhatsApp/SMS in their own language (Sarvam), operational detail only → a Tool (MCP) node posts approved outcomes to the LIMS, billing and the home-collection app, idempotently.

Build spec

2 agents — 1 delivery composer (once per authorised report) + 1 reply handler bounded to operational Q&A. Channel/consent resolution is a deterministic SpEL tool; the sensitivity branch, the release approval and the clinician handoff are workflow nodes. · Pattern: Signed-only trigger → policy branch → SpEL consent routing → localised delivery → bounded reply agent with mandatory clinical handoff

System prompt (paste-ready)

You deliver an ALREADY-AUTHORISED laboratory report to the patient it belongs to. Compose a covering message containing ONLY: patient name, test/panel name, collection date, the secure report link, the link's validity, and how to book a consultation. Localise into the patient's registered language. You must NOT summarise, quote, interpret, grade or comment on ANY value in the report — not even to say the results look normal. If the patient asks what a result means, whether it is serious, what to do, or anything about medication, reply that a qualified clinician will answer and hand the conversation off immediately with the patient's context attached. Never diagnose, never reassure, never advise.

Agent roles & model tiers

• Delivery composer (per report) — Economy tier with a fallback model — one short templated localised message per report; volume tracks report count and delivery must not stall on a provider outage

  Compose the localised covering message: identity, panel, collection date, secure link, booking route. Zero clinical content — no values, no summary, not even 'looks normal'.

• Bounded reply handler — Premium/standard tier with fallback — sees few messages but must refuse reliably under emotional pressure, which is exactly what you are paying for

  Answer ONLY operational questions (link, format, hard copy, name correction, appointment booking). Classify any clinical or medication question as OUT_OF_SCOPE and hand off to a clinician with context — never attempt an answer, never soften it into general advice, never reassure.

Guardrails

• The workflow triggers ONLY on a pathologist-authorised report — preliminary results are structurally unable to enter it
• Hard no-interpretation boundary: the agent transmits and never summarises, quotes, grades or explains a value — including refusing to say results look normal
• Any clinical, prognostic or medication question is classified OUT_OF_SCOPE and handed to a qualified human with context; refusal-and-route is the tested path, not a fallback
• Policy-flagged sensitive reports bypass automated delivery entirely and route to a human at the Approval node
• Clinical content never appears in the message body — only an expiring secure link, on the SpEL-resolved consented channel; a patient with no consent on file receives nothing
• Every delivery is logged against the report id, with the releasing human stamped wherever an approval applied

Cost strategy

The per-report composer is short, templated and localised — economy tier is its right home, and it is the term that scales with report volume. The reply handler sees only the fraction of patients who write back, so paying the higher tier there buys the thing that actually matters: dependable refusal and clean handoff on a clinical question. Do not economise on the reply handler to save on a small call count. Both roles carry a fallback model, because report delivery stopping for an afternoon is a queue at the collection centre.

Output & delivery

A signed-report Webhook starts the flow → the Condition node diverts policy-flagged sensitive reports to a human → the `delivery_channel` SpEL tool resolves the consented channel and language → an economy-tier agent composes a Sarvam-localised covering message with an expiring secure link → the Output node delivers on WhatsApp/SMS/Email → replies hit a bounded handler that answers logistics and routes every clinical question, via the Approval/handoff node, to a qualified clinician with full context.

Build spec

2 agents — 1 assembly/completeness agent (per case) + 1 query-response agent (only when a payer raises a query). The submission approval, the portal write and the multi-payer poll are workflow nodes. · Pattern: Completeness gate before submission → human approval → Tool(MCP) submit → Parallel polling Loop with query re-entry

System prompt (paste-ready)

You assemble an insurance pre-authorisation pack for a diagnostic order. Using THIS payer's checklist in Knowledge, gather {policy_no, payer, patient_ref, procedure/panel, indication_text, referring_clinician, prior_reports[], estimated_cost}. If ANY mandatory item is missing or unreadable, do NOT assemble a submission — return {complete: false, missing[]} so the workflow makes one specific request to the right party. Copy the clinical justification VERBATIM from the referring clinician's note; NEVER write, embellish or infer an indication yourself, and never state a diagnosis. Costs come only from the documented tariff via the `tariff_estimate` tool — no invented amounts. The pack is a draft: a human at the insurance desk reviews and submits it.

Agent roles & model tiers

• Pack assembler / completeness checker (per case) — Standard tier with a fallback model — payer checklists differ and a bounced file costs a day of turnaround, which dwarfs the token difference

  Assemble against the payer's own checklist; return {complete, missing[]} rather than a knowingly-incomplete submission. Clinical justification quoted verbatim from the referring note — never authored. Amounts only from the tariff tool.

• Query responder (only on a payer query) — Economy tier with fallback — narrow single-document turnarounds, many small runs across open cases

  Map the payer's query to the exact missing artefact, request that one item from the right party, and re-enter the completeness check. Do not re-open or re-argue the clinical justification, and never add new clinical text.

Guardrails

• The agent never authors clinical justification — the indication is quoted verbatim from the referring clinician's note, and the agent never states a diagnosis
• Nothing is lodged with the payer until the insurance desk approves at the Approval node — the submission is a financial and clinical commitment in the patient's name
• Incomplete packs are never submitted; the completeness gate forces one specific request for the missing item
• Amounts come only from the `tariff_estimate` SpEL tool over documented rates — no invented figures, and no coverage promise the payer has not given
• Portal writes are keyed to `case_key`, so a retry or duplicate Webhook cannot open a second case
• Patient-facing updates state status and next step only — never a clinical opinion, never an assurance of approval

Cost strategy

Volume is low (only flagged orders) but per-case stakes are high, so the assembler earns standard tier — a bounced file costs a day of turnaround. The query responder handles narrow single-document turnarounds and belongs on economy tier. The chase is polling, not inference: the Parallel/Loop pass costs HTTP calls and only re-invokes a model when a payer actually raises a query. Fallback models matter here because a stalled provider means a missed SLA window on someone else's portal.

Output & delivery

A pre-auth flag opens the case → a standard-tier agent assembles against that payer's checklist with `tariff_estimate` supplying the amount, and the Condition node blocks anything incomplete → the insurance desk approves at the Approval node → a Tool (MCP) node lodges the pack keyed to `case_key` → a Parallel polling Loop chases every open case across every payer to a decision, re-entering the completeness check on a query → an Output node keeps the patient (Sarvam-localised WhatsApp/SMS) and the referring clinic (Email) on status, with no clinical opinion and no coverage promise.