The bottleneck isn’t the API. It’s deciding what data should sync.
That sentence sums up the biggest surprise for clinics planning to wire an AI assistant into their management software. The technical bit (the actual connection between the assistant and the clinical system) usually gets solved in days or a couple of weeks. What drags on, and where the conflict shows up, is answering questions nobody asks at first:
- Can the assistant see the patient’s full history?
- Should it create appointments without human confirmation?
- What happens when a patient mentions a sensitive symptom?
Those decisions separate an integration that works from one that duplicates appointments and frustrates the team.
This post walks through how to integrate HeyCAi (or any AI assistant) with the clinic management platforms used in chiropractic, physio and osteopathy: QuiroHiro (our own software, designed for HeyCAi from day one), PracticeHub, Cliniko, Jane App and the rest. What types of integration exist, how long each takes, what data actually syncs, and the mistakes that keep showing up.
The three integration types and when each makes sense
Not all integrations are equal. Three main models, and picking the wrong one costs you time and money.
Native API integration
The deepest option. The assistant talks directly to the clinical software through the provider’s official API. Reads availability in real time, writes appointments without intermediaries, keeps the patient record synced on both sides.
Fastest in daily use, fewest errors. With a native integration, a phone call turns into a booked appointment in under 3 seconds.
QuiroHiro is the cleanest case because it was built alongside HeyCAi: same team, same data model, zero translation layer. PracticeHub, Cliniko and Jane App also publish documented APIs that allow this kind of connection, and HeyCAi connects to all of them natively.
Webhooks
An alert system rather than constant polling. When something changes in the clinical software (a patient cancels, a record gets created, a slot moves), the system fires an event the assistant receives instantly.
Webhooks avoid the cost and latency of pulling the API every few seconds. Ideal for clinics wanting immediate response to specific events without saturating the network.
Sync with an external calendar
The lightest option. The assistant syncs only with Google Calendar or Outlook, not the full clinical software. No access to patient history, no payment data, no patient tagging.
Works for tiny clinics with simple flows. Doesn’t scale. If the goal is to take real administrative load off the team, this is the least useful option.
What software is compatible
Compatibility isn’t uniform. Some systems have native integrations ready, some need middleware like Zapier or Make, and a few only allow indirect sync.
| Clinical software | Integration available | Approx. setup time |
|---|---|---|
| QuiroHiro (our native default) | Native, built-in | Same day |
| PracticeHub | Native, via API | 1 to 2 weeks |
| Cliniko | Native, via API + webhooks | 1 to 2 weeks |
| Jane App | Native, via API | 2 weeks |
| ChiroTouch | Partial API, needs middleware | 3 to 4 weeks |
| Kareo / Athenahealth | Full API, needs HIPAA accreditation | 4 to 6 weeks |
| Google Calendar | Light sync | 1 to 2 days |
Tellescope (2025) reports typical integration times for clinical management platforms ranging from 4 to 6 weeks for full EHR systems and dropping to one week for systems with very open APIs like Cliniko.
If your software isn’t on the list, three options exist: generic webhook, middleware like Zapier, or a custom integration (with extra setup cost). Before signing anything with a provider, confirm your system is supported.
How long the integration really takes
Real timing varies a lot depending on the software and the depth of the connection. A surface integration (calendar + patient name) takes days. A deep one (history, payments, cross-reminders, internal handoffs) can take 4 to 6 weeks.
What few clinics realise is that most of that time isn’t development. It’s decision-making.
The questions that drag setup out tend to be these:
- What types of appointment can the assistant create without human supervision?
- Does it block the calendar while talking to the patient or only when closing the booking?
- What if the patient changes therapist mid-conversation?
- Can the assistant read clinical history or only the calendar?
- What does it do when the patient mentions an emergency symptom?
Each of those needs alignment between the clinical team, the technical team and (often) the data protection officer.
Clinics that arrive at setup with those answers already clear integrate in a week. Those that don’t, in six.
What data actually syncs
A well-designed integration syncs only what’s necessary. More data doesn’t mean better integration. More data means more failure surface, more GDPR risk, more maintenance.
For chiropractic, physio and osteopathy clinics, the standard sync pattern has three blocks.
Flowing into the assistant: calendar availability, list of services and durations, list of practitioners, cancellation policy.
Flowing back from the assistant into the system: new appointments, cancellations, basic patient data (name, phone, email), reason for the visit in free text.
Better left out by default: clinical history, SOAP notes, diagnoses, payment data, attached documents.
The reason to exclude clinical history isn’t technical. Under GDPR and HIPAA, clinical data is a special category. The less the assistant sees, the less audit the integration needs. The HeyCAi default behaviour follows this minimum-exposure principle.
For advanced flows (reminders with specific instructions, segmentation by patient type, automated handoffs), it makes sense to enable extra fields after the first month in production. The integration should grow with real usage, not with the wishlist from day one.
Common integration mistakes and how to avoid them
The recurring errors we see in clinics integrating AI assistants aren’t technical. They’re design errors.
Doubled calendars. Happens when the assistant and the reception team modify appointments in parallel with no priority rule. Fix: define on day one who’s in charge (usually the clinical system) and configure the assistant to read changes every 30 seconds at most.
Slow sync from polling. If the assistant queries the API every 5 minutes instead of receiving webhooks, last-minute appointments can duplicate. Enabling webhooks solves 90% of these cases.
Missing human fallback. The assistant should be able to hand off to a person when it doesn’t understand, rather than inventing an answer. Setting a confidence threshold (say, hand off below 70% confidence) avoids 80% of the complaints we’ve seen in tests.
Not testing with real data before launch. Demos are clean. Reality is noisy: patients who change their mind mid-call, background noise, local terminology. A week of testing with real calls before production catches 95% of config problems.
These four cause most of the real delay in integration projects. Providers with clinical experience anticipate them. Generic ones discover them with you.
What to have ready before you start
Before talking to the provider, it helps to have clear:
- What management software you use, and which version.
- What processes you want to automate first (booking, reminders, cancellations).
- Who decides when the assistant doesn’t know: the on-call therapist, reception, or nobody until next day.
- What data can leave the clinical software and what can’t.
- What budget you have for monthly cost and any initial setup.
With that information ready, a standard native integration usually costs between €200 and €400 per month, depending on call volume and integration depth.
Frequently asked questions
What if my clinical software doesn’t have a public API?
Three options. First: middleware like Zapier or Make, which connects systems without a direct API but adds latency. Second: sync via external calendar (Google Calendar) if your software supports it. Third: a custom integration from the assistant provider (extra cost). Before ruling your software out, ask the provider if they’ve already built a specific connector.
Is it safe for an AI assistant to access patient data?
Depends on the configuration and the provider. A well-configured assistant under GDPR only accesses the minimum data needed for its function (name, phone, reason for the visit, calendar) and never clinical history or SOAP notes. Max audio retention should be 90 days, with automatic deletion. Ask for the data processing agreement and review which subprocessors are used.
Can I integrate the assistant with multiple systems at once?
Yes, with added complexity. Typical case: a clinic using one EHR for history and a separate system for payments or WhatsApp. The assistant usually lives in the middle as a central hub that writes to each system. Be careful with update conflicts: if two systems can modify the same appointment, you have to define who wins.
How much load does this take off reception?
Linear Health (2026) reports that deep integrations can reduce up to 70% of reception’s administrative load. Actual figure depends on what you automate. Bookings and reminders typically take off 50 to 60%. Add billing and waitlist management and you can hit 70%. Reminders alone gives you 20 to 30%.
What happens with calls the assistant doesn’t understand?
In well-configured systems they transfer to a human automatically when model confidence drops below a defined threshold (typically 70%). In small clinics that transfer goes to the manager’s mobile. In larger clinics it goes to reception. The handoff should be silent to the patient: no “please hold while I transfer you”.
If you want to see what a HeyCAi integration with PracticeHub or Quirohiro actually looks like in practice, get a live demo call in 30 seconds. For deep technical questions about the voice side specifically, HeyCAi Voice on callcai.ai has more detail.