A better hospital handoff
What LiveKit’s Acuity Health case study means for hospital buyers: compare platforms, check HIS access, and scope an administrative booking pilot.
The short answer
Choose a hospital AI receptionist by proving the appointment workflow in your hospital information system (HIS). A configurable platform can suit a standard process; custom development becomes useful when scheduling rules, permissions or handoffs cannot be represented reliably. Begin with one administrative task and synthetic records.
What changed
Case study published:
On 21 October 2026, LiveKit published an Acuity Health customer story describing customised patient-access voice agents and simulation tests before releases. The story reports that Acuity moved from a low-code provider to a code-based approach to address workflow constraints. This is vendor-published evidence about another company, not a Made of Systems deployment or proof that every hospital needs the same stack.
LiveKit’s Acuity Health case study. Source checked 23 Oct 2026.
Useful for: Hospital and clinic operations teams comparing AI receptionists for appointment administration.
Keep in mind: A vendor case study cannot establish compatibility with your HIS, clinical governance requirements or expected results.
One practical application
- 01Request captured
- 02HIS checks rules
- 03Change confirmed
- 04Staff sees outcome
The implementation recommendations below are Made of Systems’ analysis. This is a proposed workflow, not a claim of hands-on product testing or a client case study.
Buy the workflow first
Before comparing voices, write down one complete appointment journey. For a reschedule, identify the existing booking, establish which changes the caller may request, find eligible alternatives and confirm the final record. Decide what the receptionist should do when the request falls outside that scope.
Ask each provider to demonstrate your journey using synthetic appointments. Include a branch that their standard demo avoids: a clinician unavailable on the requested day, a booking owned by another department, or a caller asking for two changes at once. The demonstration should show the final scheduling record and the staff handoff, not just an agreeable conversation.
Check what the HIS allows
Ask your HIS supplier which supported interfaces can read availability, identify appointments and change a booking. Confirm permissions, a test environment, error responses and who maintains the connection. A logo on an integration page does not establish that these specific operations are supported for your installation.
If the system supports only reading or exports, design a request-to-staff workflow. The agent records a rescheduling request and tells the caller it awaits confirmation. A staff member makes the change and completes the follow-up. This can still be useful; presenting a request as a confirmed appointment would create extra work and confusion.
Platform or custom build?
A configurable platform is a reasonable candidate when your required actions, scheduling rules and escalation path fit its supported features. Ask how staff can review failed calls, export outcomes and change instructions. Price the complete workflow, including integrations, support and the work of resolving exceptions.
Consider a custom agent when a verified requirement cannot fit the platform: several scheduling systems, department-specific permissions, a precise handoff or a language workflow needing different speech components. Custom development also creates an ongoing responsibility for testing and maintenance. LiveKit is one option to evaluate; the case study is not a universal recommendation or a reason to replace a working system.
Avoid half-finished changes
Our proposed rescheduling pilot keeps the existing booking until the scheduling system confirms the replacement according to its supported transaction rules. If the interface cannot change a booking safely, stop at a staff-reviewed request. Do not cancel first and hope the new slot remains available.
Keep an operation identifier so a repeated webhook or disconnected call does not produce another change. Reconcile the saved appointment after an uncertain response before retrying. Give staff a concise outcome: completed, awaiting review, or failed with the next action owner. The caller hears a confirmation only when the record supports it.
Test before expanding
Use synthetic callers to test a corrected name, a date misunderstood, a timeout after saving, and an unavailable staff member. For Malayalam or mixed-language callers, have native speakers assess recognition and the final spoken date. Include a real telephone test because simulated conversations do not establish audio quality or network behaviour.
Keep the pilot administrative. Route clinical questions through the organisation’s approved staff process. Before patient data enters any provider, have the responsible hospital team approve the data flow, access, retention and contractual requirements. Do not copy entire records into prompts or place patient information in a shared knowledge base merely to simplify the integration.
Agree what success means
Compare the pilot with your existing handling process. Record correct completed changes, unresolved requests, staff correction time and the total operating cost. Review every failed or ambiguous change during the initial rollout, with a named owner able to pause automation.
A useful first scope is one department, one appointment type and an agreed operating window. Expand after the acceptance scenarios pass and the staff team can manage exceptions. Other companies’ booking speed or containment figures are not a forecast for your hospital.
Common questions
Can an AI receptionist connect to any HIS?
No. The available integration depends on your HIS version, supplier interfaces and permissions. If a supported write operation is unavailable, start with a clearly labelled staff-reviewed request.
Does an AI receptionist replace clinical staff?
This proposed pilot handles appointment administration. It does not diagnose, decide clinical urgency or replace the organisation’s approved clinical and emergency processes.
What should we send for an initial discussion?
Share your HIS name and version, the appointment task, languages and the current staff handoff. Do not send patient records; a synthetic example is enough to scope the first conversation.
Make it work for you.
We can map your appointment process, check integration options with your HIS team, compare providers and scope a working administrative pilot with clear acceptance tests.
Send your current tools, the task you want to improve and the result you need. We’ll use that to discuss a practical scope.
Discuss my booking systemPrefer email? Write to us.