What "Integrates With" Should Actually Mean (and the Questions to Ask a Vendor)

Every clinic software website has an integrations page, and almost every one is a wall of logos. The logos tell you a connection exists; they do not tell you whether it moves appointments both ways, whether invoices land in your accounts or only leave them, or whether "integrates with" means a nightly export someone has to open. Capra's own integrations page tries to answer those questions in plain terms, and this post is the general version: what the phrase should mean, the five questions that pin it down, and the review patterns that show what happens when nobody asked.

What the logo wall hides

Behind a single logo there can be any of these:

• A two-way sync. A change in either system appears in the other, within moments or on a schedule.
• A one-way push. Data leaves one system for the other and never comes back. Common for accounting: invoices go to Xero, payment status does not return.
• A partner link. The two vendors have a referral relationship and a button that opens the other product.
• An export. A CSV you can download from one system and upload to the other.
• An API. The vendor exposes an interface and someone, possibly you, has to build the connection.

All five get a logo. Only the first is what most clinics picture when they read "integrates with".

The five questions

1. What moves?

Ask for a list, not a sentence. Patients and contact details, appointments, intake and consent, documents, messages, invoices, claim status, notes. Then ask which fields within each: a "patient sync" that moves name and phone but not date of birth will create duplicates in the first week.

2. In which direction?

The question that catches one-way syncs. For each item on the list, does it flow A to B, B to A, or both? Allied-health software reviews are full of the discovery that the accounting sync is one way, so payments recorded in the accounts have to be re-entered in the clinic system, and the calendar sync is one way, so a slot moved on the phone never reaches the diary.

3. How fast, and how visible?

As it happens, every few minutes, nightly? And where can the clinic see that it happened? A sync with no log is a sync nobody can troubleshoot. Dental practice reviews describe bookings reaching the practice system hours late, with the front desk discovering it at checkout.

4. Who builds it, and who owns it afterwards?

For calendars and messaging, self-serve is fine: each clinician signs in once. For record, claims, exchange and accounting systems, the honest answer is that someone has to map fields, test against real records and watch it after go-live. If the vendor's answer is "there's an API", the someone is you.

5. What happens when a connected system is down?

Every system goes down. The question is whether the clinic software keeps working on its own data, queues what needs to be sent, delivers it when the other side is back and logs it, or whether the updates are silently dropped. Ask for the exact behavior, because the answer is rarely on the website.

The review patterns

Reading a few hundred clinic software reviews, the integration complaints fall into four groups:

1. "It's one way." The accounting or calendar sync that turned out to flow in one direction, discovered after go-live.
2. "It's slow or late." Bookings or updates that reach the other system hours later, so the front desk works from stale data.
3. "It's manual." An export that has to be requested from support, or a CSV that someone has to upload.
4. "It broke and nobody owns it." A sync that stopped after an update on either side, with each vendor pointing at the other.

Each of the five questions above would have surfaced one of these before the contract was signed.

Two kinds of integration, honestly described

There is nothing wrong with a self-serve directory; it is the right model for Google Calendar, Outlook, SMS and email, where the connection is standard and each user can set it up in a minute. The problem is describing a record, claims or exchange connection the same way. Those are different per clinic, per region and per payer, and they need scoping, building and testing.

The honest vendor page therefore has two sections: what is connected today and self-serve, and what is built for you during onboarding. Capra's integrations page is laid out that way. Calendars, SMS, WhatsApp and email are live from your first days. EHRs, accounting packages, claims platforms and health-information exchanges are scoped on your onboarding call, built and tested against your data, and switched on with every exchange logged, by a named lead who stays your contact.

A short script for the demo

When you sit through a demo, ask the five questions for each system you run and write the answers down:

• "We use [system]. Show me what moves between it and yours."
• "Which direction, for each of those?"
• "How quickly, and where do I see that it happened?"
• "Who builds that, who tests it, and who do I call?"
• "What happens if [system] is down for an afternoon?"

A vendor who can answer all five without opening a slide is describing an integration they have built before. The answers also make a fair comparison between vendors possible, which the logo walls never do; the comparison pages use exactly that framing.

A worked example: the accounting sync

Take the most common case, the link between a clinic system and an accounting package. The logo says the two connect. The five questions reveal what that means.

What moves: invoices and payments, or invoices only? Many links send invoices and stop there, so a payment recorded in the accounts never marks the invoice paid in the clinic system, and reception chases patients who have already paid.

Which direction: clinic to accounts is the usual answer. Accounts to clinic, for payments and credit notes, is the one to ask about by name.

How fast: nightly is fine for accounting, as long as the clinic knows that the morning report lags a day.

Who builds it: for a standard package, self-serve is reasonable; for a bespoke chart of accounts, someone has to map invoice lines to ledger codes, and that someone should be named.

What happens when it is down: an invoice raised during an outage should queue and post when the package is back, with the log showing it did. A link that drops those invoices leaves the accounts short with no error.

Asked up front, the five questions take a vendor ten minutes to answer. Discovered after go-live, the gaps take a bookkeeper a quarter.

Reading an integrations page

A quick test for any vendor's integrations page: pick the three systems you depend on most and, for each, look for the words that answer the five questions. Direction words such as two-way, one-way, sync and push. Timing words such as real time, hourly, nightly. Ownership words such as built for you, set up by you, available via API. If none of those words appear next to a logo, the page is a directory and the answers live in a sales call. Write the three systems down and ask.

What to expect from Capra

Plain answers to the five questions for every system named on the integrations page, a scoping call that fills in the table for your clinic, a build tested against your records, a log of every exchange, and queue-and-retry when a connected system is down. The practice management software page covers the platform the connections feed; a demo is where the questions get answered for your systems by name.