Short answer: Telvana answers the call, screens the caller against your rules, books the visit, and writes a real appointment back into your system. Not a voicemail, not a message in a queue, not a callback request for someone to deal with in the morning. A booking that exists when the caller hangs up.
On Open Dental that write is the full record. Telvana creates the patient if they are new, books the appointment with the time pattern that sets its length, the operatory, the provider and the procedure codes attached, and writes a note back to the patient's communication log. Cancellations and reschedules run through the same connection. We walk through that sequence step by step in how an appointment actually gets written into Open Dental.
This is an operational buying guide. It is not billing, clinical, legal or compliance advice.
What "integrates" actually means, and why you should make people say it plainly
Integration is a range, not a yes or no. When a vendor says they integrate with your practice management system, it can mean any of these:
- The system reads your open slots so it can offer real times on the call.
- The system creates a calendar event that sits next to your practice management system.
- The system creates a real appointment inside the practice management system.
- The system creates a real appointment with the correct type, length, operatory, provider and procedure codes attached.
All four get called an integration. Only the last one means your front desk has nothing left to type.
That last gap is where a demo can look perfect and a live schedule can still go wrong. An appointment is not one field. In Open Dental's published appointment documentation, the appointment resource carries the patient, the status, the time pattern that sets its length, the operatory, the provider, the date and time, and the procedures on the visit, each as its own field. A system that creates the record but leaves half of those blank has technically written into your PMS and has still handed you cleanup. Getting those fields right is its own discipline, which is why we wrote up appointment types, codes and chair time separately.
So the question worth asking is never "do you integrate." It is "what exists in my schedule at 8:05pm when a new patient calls at 8pm, and which fields are filled in."
Three things have to be true before anyone can write into your system
This is true of any vendor you talk to, not just us. Two of these are about your software and one is about you.
One: your system has to expose an interface a partner can use
Some practice management systems are cloud platforms with a documented developer interface. Some are server software running in your office. Some publish an interface openly, some run a partner program with an application and a review process, and some do neither. We are not going to characterize anyone else's software here, because that changes and we would be guessing. Ask your practice management vendor directly. It is one short call and they are the only authority on the answer.
Two: that interface has to allow creating an appointment, not just reading one
Reading availability is easier than writing a booking, and plenty of interfaces do the first without the second. Open Dental is a useful worked example because its documentation is public. Its API specification states that the service supports GET to retrieve, POST to create, PUT to update and DELETE to remove, acting on resources including Patient and Appointment. That is what a genuine write capability looks like when it is documented. If a system's interface is read only, no vendor can write your appointment into it, and any vendor who says otherwise is describing something else.
Three: your practice has to switch it on
This is the gate nobody mentions on a sales call, and it decides more outcomes than the other two. On Open Dental the practice holds the switch. Per Open Dental's API setup documentation, the office runs the eConnector, the developer works with the customer to enable the API, and someone at the practice opens API Setup and checks the Enabled box. Every request then carries two keys, a developer key belonging to the vendor and a customer key belonging to your office, which your office can also disable. Open Dental's specification additionally advises that developers hold a Business Associate Agreement with their clients.
Read that as a feature rather than a hurdle. Your practice grants the access, your practice can revoke it, and there is a paper trail. It also means the answer to "can you connect to my system" always contains a step that belongs to you, and any vendor who tells you otherwise has skipped something.
How to check any vendor's claim this week
Two short calls. Take these questions to each one.
Ask your practice management vendor:
- Do you offer an API or a developer program, and can a third party my practice authorizes use it?
- Does it support creating an appointment, or only reading the schedule?
- What do I have to do at my end to enable it, and is there a fee or an approval step?
Ask the AI receptionist vendor:
- Name the systems you write a real appointment into. Not integrate with. Write into.
- Which fields do you fill in when you book: patient, provider, operatory, length, procedure codes?
- Show me a booking you made for a practice running my software, start to finish, on a live schedule rather than a slide.
There is no wrong answer here, only an answer you want before you sign rather than after.
Frequently asked questions
Does an AI receptionist need access to our patient records?
To recognize an established patient from their phone number, it needs to look one up. On Open Dental that lookup runs through the API your office enables and can disable at any time. Open Dental's own documentation advises that developers hold a Business Associate Agreement with their clients. Confirm your own obligations with your compliance advisor rather than with any vendor, including us.
We schedule on a calendar rather than a PMS. Does this still work?
Yes. Telvana books into calendar and CRM systems the same way, as a real booking with the caller's details attached rather than a message for someone to action later.
What if we run something else?
Tell us what you run when you book a demo and we will tell you exactly what happens with it, plainly, on the first call. What our customers actually run is also how we prioritize what to build next. If you are still deciding whether an AI receptionist beats the service you have now, we compared the two directly.
How do we test this before committing?
Book a demo and have us place a real booking end to end, then go and look at your own schedule. Not a slide, not a recording. The screen you look at every morning.
Bring the name of your software to the call
The fastest route through all of this is to say what you run and let us show you the booking land. Book a demo and bring the name of your practice management system with you. If you want the wider picture first, start with what an AI receptionist does for a dental practice.
