Telling patients their lab report is ready, without putting results in a message

Three choices keep results out of messages:

• The workflow never asks for results. The API call to the lab system requests release status, order reference, branch, patient first name, phone, consent and the hold flag. Result values never enter the run, so they cannot leak into a message, a log or a table.
• The message names no test. "Your report for order LB-48213 is ready" says enough. A test name alone can reveal a condition to anyone who sees the phone.
• The portal does the identity check. The link opens the lab’s own patient portal, where the patient verifies their identity before the report opens. Agent Serve does not host reports.

Workflow 1: from release to message

No lab or EHR integration ships with Agent Serve, so the lab information system is reached through the generic API block, with its key stored as a workspace secret.

1. Trigger. If the lab system can send an event when a report is released after sign-off, point it at a workflow Webhook trigger. If not, a Schedule trigger runs every 15 minutes and the API block pulls reports released since the last run. Either way, the workflow only acts on reports the lab has already released.
2. Checks. A Condition block skips patients without messaging consent and any report carrying the lab’s hold flag. Held reports go straight to the staff queue, so a person decides how the patient hears.
3. Send. WhatsApp patients get an approved template through Send Template, with a link button to the portal and a quick-reply button to request a call back. SMS-only patients get a Twilio text with the portal link and "reply CALL for a call back".
4. Record. A row goes into a notifications table in Tables: order reference, branch, channel and sent time. Delivery statuses from WhatsApp and the Twilio SMS status trigger update it later. Failed deliveries land in the staff queue for a phone call.

Workflow 2: every call-back goes to a person

A second workflow starts on the WhatsApp webhook trigger and the Twilio SMS-received trigger. It does one thing with every reply, whether it is the call-back button or free text such as "is this value high": it writes the request to a call-back queue table and sends a holding reply with the hours staff will call.

It does not interpret the report or answer questions about it. Staff call the patient back, explain what the lab is able to explain and refer them to their doctor for anything clinical. The queue row records who called and when.

The dashboard and the monitor

A dashboard on the two tables shows reports released, messages sent and delivered, failed deliveries and open call-backs by branch. Because the workflows write rows as events happen, the panels update as rows land.

A monitor re-checks the queue as often as every 5 minutes and alerts the duty lead by email, in the app or in Slack when a call-back has waited longer than the time you agreed, such as four working hours. A second monitor watches failed deliveries per branch, which often points to a wrong number captured at registration.

Records and access

Every run is in Logs, block by block, which answers "did we message this patient, and when" in one search. PII redaction in Settings → Data retention masks phone numbers and names in logs and block outputs. Row-level access keeps each branch to its own queue. Labs that need patient data to stay on their own infrastructure can run Agent Serve self-hosted. Agent Serve makes no compliance certification claims, so confirm the health-data and messaging rules where you operate with your counsel.

Rolling it out

Start with one branch and routine reports while the front desk keeps answering calls. Check a week of notifications against the lab system: every released report should have one message or one skip reason, and no held report should have a message. Then add branches, and review the call-back queue each week to see which questions patients ask most. Those questions often belong on the portal page itself.