Connecting AI to your practice management system: what actually works
This is the question that decides everything. If an AI agent takes a booking and it does not land in your PMS, someone has to key it in, and you have created work rather than removed it. Here is what integration actually involves, including the parts that take longer than anyone admits.
The short version
Cloud systems like Halaxy and Cliniko expose modern APIs, so a booking made by an agent can write straight into your calendar. That is the straightforward case.
Desktop systems like Best Practice and Medical Director are a different problem, and the honest answer depends on what the vendor allows. Ask before you sign anything.
Expect a settling period. In one Queensland clinic it took about three months of tuning before the system was doing what it does now.
Most conversations about AI in general practice skip straight to what the agent says. That is the interesting part. It is not the part that determines whether the thing works.
The part that determines whether it works is whether it can read and write your practice management system. An agent that answers beautifully and then emails your reception a note saying "please book Mrs Patterson for Thursday" has moved the work, not removed it.
The Australian PMS landscape splits in two
There is no single answer to "can you integrate with my system", because the systems Australian practices run are not built the same way.
Cloud-native systems. Halaxy and Cliniko were built for the web and expose proper public APIs. Halaxy's is built on FHIR, the international healthcare data standard, and is documented at its developer portal. It supports webhooks, so changes push through as they happen rather than waiting for something to poll on a timer. Access runs through an API key manager, so an integration only ever holds the permissions the practice granted that key. That is the model you want: specific, revocable, auditable.
Desktop and server systems. Best Practice, Medical Director, Zedmed and Genie grew up as Windows software running in the practice, and integration with them is a different conversation. Depending on the vendor and your version, the route may be a partner programme, a supported interface, or secure messaging rather than an open API. This is not a criticism of those products, they are deeply embedded in Australian general practice for good reasons. It does mean the integration answer is specific to your setup and your vendor, and anyone who tells you otherwise before looking at your system is guessing.
Then there are booking layers like HotDoc sitting on top of a PMS, which adds another link in the chain and another place for things to fall over.
The questions that actually matter
Whatever system you run, the same four questions decide whether an integration is sound.
Does it write back, or only read? A read-only integration can tell a patient what is available. It cannot book them in. If the booking does not land in the calendar automatically, your receptionist is still doing the booking, just later and from a message.
What permissions does it hold? An integration should have access to exactly what it needs and nothing more. Appointment creation, yes. Full clinical notes, almost certainly not. If a vendor asks for broad access "to make things easier", that is a reason to slow down.
What happens when the PMS is down or slow? Every system has outages. The agent should fail visibly, take a message and tell the patient a person will confirm, rather than silently dropping a booking that everyone assumes was made.
Where does the data go? Patient information carries obligations under the Privacy Act 1988 and the Australian Privacy Principles. Ask where call recordings, transcripts and patient details are stored and processed, and get onshore in writing.
What it actually looked like: a Queensland clinic on Halaxy
Anonymised, with the client's agreement. A GP and specialist booking clinic in Queensland, team of six, running Halaxy. The owner was carrying the phone pressure personally, which is the pattern in most practices this size: everything that reception cannot absorb ends up with the person who owns the place.
We built a voice agent handling inbound patient calls, bookings, reminders and follow-ups, writing into Halaxy through its API. The patients calling range from their twenties to their seventies, which matters, because a system that only works for the comfortable-with-technology half of your patient list is not a system, it is a demo.
The part most case studies leave out: it took about three months of teething and tidying up. Real calls surface things no amount of planning does. Phrasing that confused people. Edge cases in how appointments were structured. Moments where the agent should have handed over sooner and did not. Every one of those was found by a real patient on a real call, and fixed afterwards.
Through that first three months the agent was handling roughly a quarter of call volume, with the rest still going to the team. That is the honest number, and it is the number a vendor promising instant transformation will not give you.
Six months in, the picture is different. The agent now handles around three quarters of daytime calls and all after-hours calls. The remaining daytime quarter is what it should be: the calls that genuinely need a person, escalated with context rather than dropped.
The owner's description of the change was not about call statistics. It was that the constant pressure eased, and there was finally room to manage the practice and look after the team's morale rather than firefighting the phone. That is the outcome that actually mattered to them.
What we would tell you before starting
Budget for the settling period. Anyone quoting you a system that is perfect on day one is selling a demo. Three months of tuning on real calls is a realistic expectation, and the tuning is where the value gets built.
Start where the volume is. After-hours is often the easiest win, because the alternative is currently a machine or a ring-out. Nobody is worse off, and it builds confidence before you touch daytime calls.
Keep the clinical line hard. Booking and admin, yes. Clinical advice, symptom interpretation and urgency decisions, never. Those go to a person immediately. We have written more about that in our piece on what an AI receptionist can and cannot do.
Insist on logs. Every call and every write to your PMS should be reviewable. If you cannot see what the system told a patient or what it changed in your calendar, you cannot stand behind it.
How we approach it
We build AI phone and chat agents for Australian clinics and practices, integrated with the systems you already run. Data stays onshore, every conversation and every system write is logged, permissions are scoped to what the workflow needs, and the clinical boundary is designed in rather than bolted on.
If your system is cloud-based with a proper API, the integration path is usually clear. If you are on a desktop system, we will tell you honestly what is and is not possible with your vendor before you commit to anything. See more of our healthcare work.
What system does your practice run?
Tell us your PMS and what your reception is drowning in. We will tell you honestly what can be integrated, what cannot, and whether it is worth doing.