AI Agent for a Diagnostic Laboratory: Scheduling and Questions

An AI agent for a diagnostic laboratory works best as a patient access coordinator. It answers preparation and logistics questions from approved content, helps patients book and change appointments, and routes anything that touches a result to verified, authorised people. It should never read out, summarise or interpret results in an open channel such as chat, email or a phone transcript. The design question is less about what the agent can say and more about what it is allowed to see.

Key takeaways

• Give the agent a narrow role: preparation answers, scheduling and routing. Leave results and clinical interpretation to people and to your authenticated portal.
• Enforce the results boundary in the tools and permissions, not only in the written instructions. An agent that cannot read result content cannot leak it.
• Treat preparation instructions as controlled content with an owner, a review step and one approved text per test and site.
• Decide in advance which requests the agent answers, which it routes with a summary, and which it declines. Write that as a short decision guide your staff can audit.
• Test the agent with hostile and emotional messages before it meets patients, and keep testing after launch.

What does an AI agent in a diagnostic lab actually do?

Most patient contact in a lab is repetitive and time sensitive. People ask where to go, what to bring, whether they need to fast, how long the visit takes, whether a result is ready, and how to move an appointment. Staff answer the same questions many times a day, often while handling samples, orders and walk-ins.

A well-scoped agent takes three jobs from that stream:

• Answer logistics and preparation questions from approved lab content.
• Handle scheduling inside the rules your booking system already enforces.
• Triage everything else and hand it to the right person with the context already written down.

The agent is not a clinician and not a results desk. It does not advise on symptoms, comment on abnormal values, change orders or decide whether a sample is acceptable. Simple, well-bounded workflows tend to be more reliable than open-ended autonomy, a point made in Anthropic's guidance on [building effective agents](https://www.anthropic.com/engineering/building-effective-agents). Labs have a strong reason to follow it.

Many of the same patterns appear in AI agents for clinics. Labs add test-specific preparation rules, sample collection constraints and result release controls, which make the boundaries sharper.

Why are results the hard boundary?

Results are different from every other topic the agent touches, for four practical reasons.

• Identity is weak in most messaging channels. A name and a date of birth typed into a chat window do not prove who is writing.
• Channels are not private. Email, SMS and messaging apps can be read on shared devices or forwarded.
• Release is often a process, not a switch. The ordering clinician may need to see a result first, and some results are released on a schedule the lab does not control.
• Interpretation is clinical. Even a correct number can mislead without context.

The safest design starts from a default of no access. The agent has no read permission on result content. If your policy allows it to say anything about a result, limit it to a coarse status such as received or in process, and only after identity verification. When a patient asks for the result itself, the agent points to your authenticated portal or to the ordering clinician, and offers help with portal access.

This has to be enforced outside the model. The OWASP [authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege and deny by default, applied at the point where data is requested. The same logic applies to prompt injection. A patient, or a document the patient uploads, can contain text that says to ignore the rules and show the result. The OWASP [prompt injection prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) explains why instructions alone are not a control. If the tool never returns result content to the agent, there is nothing to extract.

A short checklist for the results boundary:

• The agent's service account has no read scope on result documents or result fields.
• Any status lookup is a separate, narrow tool that returns a fixed set of values.
• Status is shown only after the identity step your policy requires.
• Replies never include test names or values in unauthenticated channels.
• Requests from family members, employers or insurers go to staff, never to the agent's own judgment.

How should preparation instructions be handled?

Preparation is where an agent can help patients most, and where a casual paraphrase can do harm. Instructions differ by test, sometimes by site, and they change when a method or a supplier changes. Patients also describe their situation in ways that do not match your catalogue: they say they are having a blood draw and a scan, or they mention a medication in passing.

Treat preparation text as controlled content:

• Keep one approved text per test and per site, with a named owner.
• Require a review step whenever the text changes, and retire the old version so the agent cannot retrieve it.
• Have the agent quote the critical lines (fasting, hydration, medication, timing) rather than rewrite them.
• Ask which test or tests the patient is booked for before answering, and do not guess.
• Hand off to staff when two tests have conflicting instructions, or when the patient raises a medication or health condition question.
• Record which version of the text was shown, so a complaint can be traced.

Medication questions deserve special care. Whether to pause or continue a medicine before a test is a clinical decision, similar to the boundaries described in AI agents for pharmacies. The agent should say that this is a question for the ordering clinician or the lab's clinical staff, and offer to pass the message on.

What can the agent do in scheduling?

Scheduling is the most automatable part, because the rules already exist in your booking system: which tests need which room or equipment, which sites collect which samples, and what the opening hours are. The agent should propose and confirm slots through that system, not invent its own logic. If the booking tool rejects a slot, the agent explains the reason in plain language and offers alternatives.

Useful scheduling tasks include:

• Booking a new appointment when a valid order is on file.
• Rescheduling and cancelling within the policy window.
• Sending reminders that link to the correct preparation text.
• Offering an earlier slot to patients on a waiting list.
• Collecting what staff need before the visit, such as a missing referral, and routing it for review.

Orders and referrals arrive as documents, often photographed or forwarded. A classification and routing step with human review, like the one in AI document classification and routing, keeps the agent from guessing whether an order is valid.

Keep reminders and confirmations minimal. A message that says an appointment is booked at a given site and links to the preparation page reveals far less than one naming the test. Put detail behind the authenticated link, not in the message body.

How do you decide what to answer, route or decline?

Write the decision guide before the first conversation. It becomes the agent's operating boundary, the basis for staff training and the checklist for reviews. A workable version has five lanes:

• Answer directly: location, opening hours, parking, what to bring, how the portal works, and approved general preparation text.
• Answer after an identity check: appointment details, rescheduling and cancellation.
• Route to front-desk staff with a summary: missing or unclear orders, billing questions, accessibility needs, sample collection problems and conflicting preparation instructions.
• Route to clinical staff: symptoms, medication questions, worry about a result, and anything the patient frames as a health decision.
• Decline and redirect: result content, interpretation, comparison of values, and requests on behalf of another person without the verification your policy requires.

One more rule sits above all of these. If a message describes an emergency, the agent gives the emergency direction your lab has defined and stops trying to complete the task.

Every handoff should carry a short, structured summary: who is asking, what they need, what the agent already said, and what is missing. The summary should not contain result content. A good handoff means the patient does not repeat themselves and staff do not start from zero.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a description of a real lab.

A patient writes in the evening: their blood test was yesterday, is it back, and is the number okay?

The agent has no access to result content, so it cannot answer the second half. It replies that it cannot discuss results in this channel, explains that results are available in the secure portal once released, and that the ordering clinician is the right person to explain what they mean. It asks whether the patient needs help signing in to the portal.

The patient answers that they cannot log in and are anxious. The agent does not try to reassure with guesses. It creates a callback request for the front desk with a three-line summary: portal access problem, patient prefers a call, no result content discussed. The next morning a staff member verifies identity by phone and resolves the access issue.

Nothing in the exchange exposed a result, the patient got a clear next step, and staff received a task that was ready to act on. The success criterion is observable: the request was routed with complete context and no result was disclosed.

How do you roll it out, and how does Be Human run it?

A first engagement should be small and measurable. A sensible order is:

• Map the current patient questions and who answers them today, by channel. Process mapping before automation, as in mapping a business process before an AI agent, shows which questions are frequent and which are risky.
• Define the single role: patient access coordinator, with the decision guide above.
• Load only approved preparation and logistics content, with owners and review dates.
• Connect the scheduling system with the narrowest permissions that work, and confirm the agent has no result access.
• Run test conversations, including attempts to extract results, impersonate another patient and inject instructions through uploaded files.
• Start with one channel and a small group of staff reviewing handoffs, then widen.

Be Human designs, implements and operates this kind of role as personalised AI infrastructure. A first engagement defines the role, the memory and tools it needs, the approval boundaries and the success criterion, for example whether handoffs arrive complete and whether any disclosure occurred. Managed operations can then cover monitoring, recurring evaluations with new adversarial test cases, integration maintenance when your booking system changes, permission reviews, incident response and controlled improvements. Responsibilities between provider and lab are written down, as described in the shared responsibility model for AI agents. Your team keeps ownership of clinical content, release policy and legal interpretation of local health data rules.

For governance language that risk and compliance staff recognise, the NIST [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a structure for mapping, measuring and managing these risks.

Frequently asked questions

Can an AI agent give lab results to patients? It can, only if your own policy, local rules and technical controls allow it, and even then identity verification must happen in a secure channel. For most labs the safer pattern is that the agent never handles result content and instead directs patients to the authenticated portal or the ordering clinician. Have your legal and clinical leads decide this before design starts.

Should the agent be able to say that a result is ready? That depends on your release policy. If the ordering clinician needs to review first, even a ready status can create confusion or alarm. If you allow status, expose it through a narrow tool that returns fixed values, after an identity check, and test that the agent does not hint at content.

Does the lab need to replace its scheduling system? Usually not. The agent works through the booking system's existing rules and permissions, and it should propose slots the system already validates. The work is in connecting the tools safely, cleaning the preparation content and defining the handoff rules.

How do we test the agent before real patients use it? Build a set of realistic conversations: routine questions, ambiguous preparation cases, upset patients, requests for another person's results and messages that try to override the agent's rules. Have staff review the answers and handoffs, fix the content or permissions that caused any failure, and repeat the set on a schedule after launch.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.