How should an AI patient assistant connect to a clinic scheduling system?

The short answer

Connect the assistant as a tightly limited scheduling client, not as a user with broad access to the patient record. Give it only the approved actions, require the clinic system to confirm every write and tell the patient that an appointment is booked, changed or cancelled only after that confirmation returns.

If the system is unavailable or the result is uncertain, the call should end with a visible pending case and a named owner instead of a confident promise. The clinic remains responsible for identity rules, access, appointment policy, clinical boundaries and the fallback used when automation cannot finish safely.

• See the AI Patient Assistant 24/7 product scope

Define allowed actions before discussing the API

Start with an action matrix. Separate reading available times, proposing a slot, creating a booking, moving an existing appointment, cancelling it and joining a waiting list. For each action, record the identity check, fields required, system response that counts as success, staff owner and fallback state.

This prevents a technical connection from quietly expanding the service. An integration that may read cardiology availability does not automatically need access to clinical notes, test results or every clinic location. The approved workflow should decide the data scope before credentials and endpoints are configured.

Let the scheduling system own the appointment status

Availability is not the same as a confirmed booking. The HL7 FHIR Appointment specification makes that distinction explicit: checking a slot does not guarantee that the appointment can be made, and an appointment can move through states such as proposed, pending, booked, cancelled or waitlist. A clinic using another interface still needs equivalent states.

The assistant should read back the final date, time, location and status returned by the source system. A conversational phrase such as 'Thursday afternoon works for me' is a patient choice, not proof of a write. Keep the request, system response and confirmation sent to the patient tied to the same case.

• Appointment confirmation, cancellation and waiting-list workflow

Give each action the least access it needs

Use a service identity made for this workflow and restrict what it may read or change. Patient lookup, availability search and appointment updates may need different permissions. Limit access by action and, where the clinic can support it, by location, service or other operational scope. Do not reuse a staff administrator account for the assistant.

FHIR provides data structures and interaction patterns, but it assumes that a security layer handles authentication, access control and audit. The GDPR principles of purpose limitation and data minimisation apply as well. The integration should fetch only the information needed for the current task and avoid copying a wider patient record into the conversation log.

• Identity verification before an appointment change

Make every write safe to repeat

Phone calls and APIs fail in awkward places. A timeout may happen after the clinic system accepted a booking but before the assistant received the response. Blindly sending the same request again can create a second appointment. Give each attempted action a stable correlation identifier and check the current source record before retrying.

Rescheduling needs one clinic-approved sequence for the old and new appointment. The workflow must not release the existing time and assume the replacement succeeded. Version checks, conditional updates or a transactional operation can help where the interface supports them, but the acceptance test must prove the behaviour of the actual system in use.

Plan for a slow or unavailable system

Set a response window for each live action. When it expires, stop presenting cached availability as current and do not announce success. Capture the minimum details for follow-up, mark the requested action as pending and tell the patient what will happen next without inventing a callback time.

The recovery process matters as much as the live call. Staff need to see whether a write was attempted, which response arrived and whether the patient received a confirmation. After service returns, reconcile uncertain cases before any retry. A hidden queue that later changes appointments without checking their current state creates a new risk.

• Clinic phone fallback and recovery guide

Keep clinical and exceptional decisions with people

The assistant may follow approved administrative rules. It should not infer clinical urgency from symptoms, decide referral eligibility, choose an appointment type that requires medical assessment, release protected capacity, overbook a clinician or bypass a restriction because the caller insists. Those actions need the clinic's authorised process.

A symptom, safeguarding concern, disputed identity, unusual consent issue or request outside the action matrix should stop the scheduling flow. The assistant can capture limited context and use the approved clinical or emergency route. It must not turn an integration error into a clinical decision or rank patients by its own judgement.

Model scenario: the booking succeeds but the response is lost

This is a model scenario, not a customer case. At 10:14, the assistant sends a booking request with correlation identifier APPT-2041. The scheduling system creates the appointment, but the connection closes before the success response reaches the assistant.

The assistant does not repeat the create call and does not tell the patient that nothing happened. It checks the source by the correlation identifier or an approved lookup. If the appointment is visible, it reads back the returned details and sends the confirmation. If the result remains unclear, it creates an owned case for staff without making a second write.

Seven acceptance tests for the source-system contract

Run each test in a safe environment. Keep the request identifier, source response, resulting appointment record, audit event and patient-facing message as one evidence set.

Test the saved outcome, not just the conversation

Run end-to-end tests with two callers selecting the same slot, a patient changing their mind, a dropped call, a timeout after a successful write, the wrong clinic location, expired access and a complete outage. Inspect the source system, patient confirmation, case status and audit event after every test.

Fail the release if the assistant can confirm an unsaved appointment, duplicate a write, hide an uncertain result or expose data outside the approved task. Useful pilot measures include incorrect confirmations, duplicate actions, unresolved pending cases, staff correction time and whether the audit trail explains exactly what happened.