Before connecting an AI receptionist to your scheduling system, verify the exact actions it can perform, the rules it must follow, and how staff will resolve an uncertain result. Seeing an available time and saying an appointment is booked are different steps.
This guide is for a practice manager reviewing a proposed integration with their scheduling and technical teams. It describes checks to request from any provider, not a list of available Koltra integrations. For the broader choice between people, AI and message-taking coverage, start with choosing a reception service.
Specify the actions you need
Ask the provider to identify your exact practice-management or scheduling system, the proposed connection method, and which actions have been demonstrated in that setup. A vendor name or an integration logo does not establish that your appointment types and local rules are supported.
Separate the actions before evaluating them:
| Action | What to ask the provider to demonstrate |
|---|---|
| Read availability | The right location, clinician, appointment type, duration and time zone, using current scheduling information. |
| Book a visit | A permitted appointment saved against the correct patient, with its final status visible in the scheduling system. |
| Reschedule | The new arrangement and the disposition of the original appointment, including what happens if only part of the change succeeds. |
| Cancel | The intended appointment is cancelled under the practice’s rules, with no unrelated visit changed. |
| Send a confirmation | The notification is tracked separately from the booking. A saved appointment does not prove the message was delivered. |
Request an explicit list of unsupported actions and cases that staff must handle. Reading a calendar does not establish permission or capability to change it.
Agree identity, permissions and booking rules
Have the practice define how the workflow identifies the patient and appointment, what information it may disclose, and when a staff member must verify the request. Include a person calling for someone else and two records with similar details. Uncertainty should follow the agreed verification route before any appointment is changed.
Write down the permitted appointment types, locations, clinicians, durations and notice periods. Decide who handles requests outside those rules. Access should be limited to the information and actions needed for the agreed work; ask who can grant, review and remove it.
Have the practice’s privacy and security owners review the proposed data flow and access arrangements before using patient information. Early tests can use fictional patients in an appropriate test environment.
Check the saved result
For each test, inspect the scheduling system before and after the action. Match the patient, appointment reference, time, location, clinician and status to the request. Ask what the agent uses as confirmation before telling the person the change is complete.
An open slot can become unavailable before booking. The HL7 FHIR R4 Appointment specification explicitly distinguishes availability from a successful booking. A provider’s use of FHIR still does not prove that the required actions work in your installation; verify the supported version and actual behavior with both providers.
Worked test to request: using a fictional patient, move a Thursday appointment to Friday. Check the resulting Friday appointment and what happened to Thursday. Then repeat while another authorized user changes the original appointment. The workflow should detect or resolve the conflict under an agreed rule, rather than silently overwrite newer work. This is a proposed test, not a reported Koltra result.
Test uncertainty and interruption
Ask the provider to run these cases in a controlled test environment. Record what the person hears, what changed in the scheduler and who owns any remaining work.
| Test case | What a satisfactory response needs to establish |
|---|---|
| The selected slot is no longer available | No false booking confirmation; alternatives or a staff route follow the practice’s rules. |
| Access expires or a write is rejected | The workflow states that it could not complete the change and preserves enough context for staff to continue. |
| The request times out after submission | The result is checked before another write is attempted. An unknown result is not automatically treated as a failed booking. |
| The same request arrives twice | A repeated message or retry does not silently create two appointments. |
| Staff change the appointment during the conversation | Newer work is not overwritten without the agreed conflict check. |
| The conversation ends partway through a reschedule | Staff can identify what was changed, what remains and how the patient will be informed. |
For a technical reviewer, FHIR R4 describes version-aware updates. Ask which conflict and duplicate-prevention mechanisms the particular integration actually supports; the standard alone cannot answer that.
Decide who handles unfinished work
Agree the receiving team, coverage hours, acceptance process and escalation route. If nobody is available, the person needs an accurate next step. A callback request should not become a promised callback time unless the practice has committed to that time.
Ask where staff can see failed or uncertain scheduling changes during operation, who is alerted, and who reviews requests left open beyond the agreed time. Before retrying, that owner needs a way to reconcile the request with the scheduler’s actual state; an automated retry should not create a second booking or overwrite a staff correction.
Distinguish a message sent to a queue, responsibility accepted by a person or staffed team, and the eventual outcome. The handoff guide explains what should travel with the request and how to handle unavailable staff.
Finish with a bounded decision
Use the evaluation worksheet to retain the cases, evidence, unresolved issues and owners. The decision can be to test a narrower set of actions, keep particular changes with staff, or defer the connection until an issue is resolved. A successful demonstration does not establish performance across the practice’s full request mix.
For Koltra’s current development scope and published test conversation, see Patient access. Compatibility and workflow fit are assessed with each practice.