Guides
Build an outpatient scheduling workflow that checks referral readiness, matches approved services and sites, books live availability, and routes exceptions to central scheduling.
Last updated
Outpatient scheduling should move an eligible request from referral or self-scheduling intake to a confirmed visit without pretending every request is ready to book. A reliable workflowWorkflowA workflow is a defined sequence of steps, decisions, actions, delays, and outcomes used to complete a business process. checks the scheduling prerequisites defined by the organization, reads current availability, commits the appointment once, and gives incomplete or sensitive cases an owned human route.
Thoughtly's point of view is direct: automate the administrative path to an outpatient appointment, not the clinical or coverage judgment around it. The source system owns order, authorization, and scheduling readiness. The scheduling system owns slots and resources. The AI agent owns the conversation, deterministic routing, and confirmation only when those systems return an approved result.
This guide is narrower than Thoughtly's overview of healthcare appointment scheduling and patient intake. That page explains the category. This one shows how an outpatient team can design the event contract, readiness states, location and resource rules, booking action, exception queue, and measurement layer for a referral-to-appointment workflow.
See how Thoughtly handles appointment scheduling
Outpatient scheduling is the administrative workflow that turns an eligible request into the correct appointment at the correct site, with the correct visit type and required resource. The useful automation target is not every call. It is the repeatable subset whose booking rules can be expressed and verified before a slot is offered.
A strong first deployment usually covers a narrow catalog: a few non-emergency visit types, one or two locations, defined referral states, current scheduling templates, and explicit staff-review reasons. Breadth is not the first milestone. Correct bookings with clean exception ownership are.
The workflow should be able to:
| Stage | System or agent action | Required output | Human boundary |
|---|---|---|---|
| 1. Request received | Inbound call, approved form, referral event, or callback starts the workflow | Event ID, source, contact channel, permission state | Reject duplicates, suppressed contacts, and unsupported sources |
| 2. Person matched | Look up an existing record or create a limited scheduling inquiry | Stable person or inquiry ID and identity state | Do not reveal record details until identity rules pass |
| 3. Readiness checked | Read organization-owned order, referral, authorization, and scheduling states | Ready, incomplete, staff review, or stop | The agent does not interpret clinical documentation or coverage |
| 4. Request classified | Map the request to an approved service, site, resource, and appointment type | Normalized scheduling request | Unknown or conflicting requests go to central scheduling |
| 5. Availability read | Query the live scheduler with approved constraints | Short list of valid slots | Never quote cached, guessed, or unapproved availability |
| 6. Booking committed | Recheck the chosen slot and create the appointment once | Confirmed status, appointment ID, site, resource, and time | A failed or ambiguous write is not a confirmed visit |
| 7. Confirmation sent | Deliver approved instructions through a permitted channel | Delivery status and help path | Avoid unnecessary health detail in messages |
| 8. Result written back | Store disposition, booking ID, handoff reason, and next action | Auditable source-system record | Failed writes enter an owned exception queue |
The triggerTriggerA trigger is an event or condition that starts, resumes, changes, or stops an automated workflow. should tell the workflow why it is running. A phone number alone is not an event contract. The minimum useful payload needs a unique event ID, source, received time, contact channel, permission state, and any source-system identifiers the organization has approved for the workflow.
Thoughtly's current automation documentation supports several starting points: On Inbound Call before the call connects, Incoming WebhookWebhookA webhook sends event data from one system to another through an HTTP request when a defined event occurs. for events from external systems, native integration triggers, and On Call Completed for post-call work. The implementation choice should follow the system that owns the event, not whichever trigger is easiest to demo.
For phone-first central scheduling, use the On Inbound Call trigger to look up approved context before connecting the caller. For referral or form events, use a webhook or native trigger with an idempotent event ID. Thoughtly's trigger guidance explicitly recommends lean payloads, tested sample schemas, and idempotency for retried events.
Idempotency is not plumbing trivia. A retried referral event must not create a second contact, second call, or second appointment. Store the event ID before any irreversible action and define what a replay returns.
The agent needs structured scheduling facts, not the whole chart. Separate durable facts from request-specific context so later calls do not inherit stale referral or appointment details.
Durable contact attributes may include:
Call-specific metadata or source-system lookups may include:
Thoughtly's Attributes versus Metadata guide makes the same distinction: Attributes persist on a Contact, while Metadata belongs to one call. Our recommendation is stricter for outpatient scheduling: keep clinical, referral, and authorization details in the source system whenever the agent only needs a readiness state or opaque reference.
A thin data model makes routing easier to test and reduces the damage from stale context. If the agent cannot explain why a field must exist in the conversation layer, leave it in the system of recordSystem of recordA system of record is the authoritative source for a defined category of business data..
The most important branch happens before availability. The workflow should consume a readiness state produced by organization-owned rules or staff, not create that state from a free-form conversation.
A practical readiness enum can be simple:
The agent may state that the request is not yet ready for automated booking and explain the approved next step. It should not tell the patient that a referral is clinically valid, that coverage is guaranteed, that an order is correct, or that a reported symptom is appropriate for a particular outpatient service.
This boundary is what makes automation useful to a central scheduling team. The agent absorbs repeatable work and gives people a smaller queue of cases that actually require judgment.
A production agent should be a state machine wearing a conversational interface. Friendly language matters, but the outcome must come from explicit variables, actions, and rules.
For an inbound call, use pre-call automation to match the caller and retrieve the current readiness state, service catalog entry, and allowed scheduling constraints. If the lookup is missing, ambiguous, or returns multiple people, connect to a limited fresh-inquiry path or transfer without exposing record details.
The safest default is no silent guessing. A failed lookup changes the route; it does not lower the evidence required to book.
Collect only what drives an approved scheduling branch, such as requested service, preferred site, date range, time preference, communication preference, and whether the caller is asking for accessibility support. Use enumerated outputs where possible and return an explicit unknown value when the caller's answer does not map cleanly.
A variableVariableA variable is a named value captured, calculated, or retrieved during a conversation and reused in logic, messages, actions, or integrations. should never become a clinical conclusion. For example, reason_for_request may preserve the caller's words for staff, while scheduling_service must come from the approved catalog or a human decision.
Use rule-based outcomes after lookups and booking actions. ready_to_schedule proceeds to availability. missing_information creates or updates an owned task. staff_review transfers or queues the case. booking_confirmed proceeds to confirmation. Every other booking result should be treated as unresolved.
Thoughtly's automation Actions reference supports Conditions, contact updates, inbound connection, SMS, scheduling actions, and webhooks. The platform provides the pieces. The implementation team still owns the states, data contracts, stop rules, and queue owners.
Outpatient scheduling fails when an agent offers a plausible time instead of an available resource. Availability must come from the approved scheduler at the moment of the conversation, filtered by the service, site, appointment type, resource, date range, and any other rule the scheduling team has encoded.
The booking sequence should be short and unforgiving:
Thoughtly's voice agentVoice agentA voice agent is a conversational software system that listens, responds, follows a defined workflow, and can take approved actions during a phone conversation. scheduling guide documents the same production pattern: Variables capture dates, Actions check current availability and book, rule-based Outcomes separate confirmation from fallbackFallbackA fallback is a safe alternate path used when input is unexpected, a tool fails, or the agent cannot complete the intended step confidently., and the agent offers only times returned by the scheduler.
If the scheduler times out after the caller selects a slot, the correct response is not optimism. Tell the caller the booking is not yet confirmed, preserve the request, and route it to an owned recovery queue.
A booking is incomplete until the source systems agree. The scheduler should have a confirmed appointment. The referral or inquiry record should hold the appointment ID and disposition. The permitted confirmation channel should show a delivery result. Failed writes should be visible to an owner.
The post-call payload should include:
Use On Call Completed for post-call automation and a Thoughtly webhook or supported integration to push the structured result to the scheduling, referral, CRMCRMA CRM is the system used to manage leads, contacts, accounts, opportunities, activity, ownership, and follow-up., or reporting system. A transcriptTranscriptA transcript is the written record generated from a spoken conversation, typically showing what the caller and agent said during a call. may support review, but it should not be the only place the outcome exists.
Reconciliation should run independently of the conversation. Compare accepted booking events with scheduler records and flag missing appointment IDs, duplicate external references, delivery failures, and unresolved handoffs. The call can sound perfect while the operational result is wrong.
Healthcare workflow design must start with the applicable contract, not a marketing label. HHS explains that a cloud service provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate is itself a business associate, even when the data is encrypted and the provider cannot view it.
Review the current Thoughtly Terms of Service with counsel and security before implementation. Then apply the HHS cloud computing guidance to the actual architecture, including the scheduler, CRM, middleware, messaging provider, call recordingCall recordingCall recording captures phone audio for review, quality assurance, training, dispute handling, or regulated retention., transcripts, logs, and analytics.
For administrative scheduling data, design toward the HHS minimum necessary standard: keep only the information required for the purpose, define role-based access, and avoid copying the whole record into the conversational layer. Legal and security teams should decide how exceptions apply to the organization's specific use.
The product boundary and the workflow boundary must match. If the permitted data scope is uncertain, the implementation is not ready for live patients.
A happy-path booking proves almost nothing. A production test plan should force the workflow through ambiguity, missing data, race conditions, integration failures, and human handoffs.
At minimum, test:
Run these cases in Thoughtly's draft or test mode with synthetic records. Verify the trigger, identity lookup, readiness API, scheduling action, confirmation channel, write-back, and exception queue as one system. Passing each integration separately does not prove the workflow.
The correct conversion unit is a completed, appropriate outpatient visit. Calls answered and appointments created are leading indicators. They are not the outcome if duplicate bookings, scheduling errors, no-shows, or unresolved exceptions rise.
Track:
Compare these measures with the prior baseline for the same services, sites, referral sources, and patient populations. More automation is not the goal. Fewer lost requests and more correctly completed visits are.
Thoughtly can serve as the conversational and orchestration layer around an organization's existing scheduling, referral, CRM, and messaging systems. An inbound call or approved event starts an Automation; pre-call steps retrieve permitted context; Variables capture the request; Actions query availability and create the appointment; Outcomes enforce each route; and post-call automations write a structured result back.
The strongest deployment keeps the agent narrow. It handles high-volume administrative scheduling consistently, books only against live approved inventory, and delivers exceptions to central scheduling with the context already attached. It does not replace schedulers, clinicians, utilization teams, coverage specialists, privacy teams, or the source system.
Start with one service line, a small appointment catalog, named queue owners, and a synthetic-data test suite. Expand only after booking accuracy, write-back reliability, completed-visit measurement, and the applicable data agreement are all visible.
Map an outpatient scheduling workflow with Thoughtly
Outpatient scheduling is the administrative process for matching an eligible patient request or referral to the correct non-inpatient service, site, resource, appointment type, and time. A production workflow also manages readiness checks, identity, confirmations, reschedules, human review, exceptions, and source-system updates.
Yes, for appointment types whose readiness and booking rules are explicit. The agent should read an organization-owned readiness state, query live availability, create the appointment through an approved action, and confirm only after the scheduler returns a successful result and appointment ID.
General booking may need only a host, event type, and available time. Outpatient scheduling can add referral or order readiness, service-line mapping, site and resource constraints, identity controls, accessibility requests, and named queues for clinical, coverage, authorization, and scheduling review.
No. The workflow should consume a ready, incomplete, review, or stop state produced by the organization's approved systems or people. The agent can explain the administrative next step and collect approved facts, but it should not decide whether clinical documentation is sufficient or correct.
The agent should report that no approved slots were returned, offer another permitted date, site, or appointment type only when the rules allow it, and otherwise create an owned callback, waitlist, or central-scheduling handoff. It should never invent a slot or promise an accommodation.
A workflow that creates, receives, maintains, or transmits PHIPHIPHI, or protected health information, is individually identifiable health information held or transmitted by a HIPAA covered entity or business associate. requires a HIPAA-specific legal, security, contracting, access-control, retention, messaging, and connected-vendor review. Confirm the controlling agreement and exact data scope before live use, especially because Thoughtly's current public Terms restrict Customer Data subject to heightened security requirements.
