Best Practice software API: what you can and can't build with it

Quick answer: Best Practice Software has an API. It covers more than people assume — appointments, billing, patient records, and provider data are all addressable. What it doesn’t cover is the chunk of practice operations that happens around clinical software: reminders, online intake forms, follow-up sequences, patient portals, billing reconciliation. The integrations that get built sit almost entirely in that surrounding space, with Best Practice as one node in a larger system.

Best Practice (BP) is one of the two clinical software products most Australian general practices and allied health clinics use, alongside Medical Director. For its core job — clinical record-keeping, prescribing, Medicare claiming — it does enough that nobody’s in a hurry to replace it. What changes over time is everything around BP: how patients book, how reminders go out, how billing flows into accounting, how operational reports get produced, how the practice manages referrals.

That “everything around BP” layer is where API integration work usually shows up. Four patterns cover most of what we build for medical and allied health practices.

What the BP API actually does

Worth being specific. BP’s API exposes the entities you’d expect — appointments, patients (demographics, contacts, allergies), providers, billing items, accounts — through a REST interface. There’s reasonable read access and constrained write access; you can create appointments and patients, update certain fields, and pull most of what’s in the database for reporting purposes.

What you can’t do (as of writing):

• Modify clinical notes from outside BP. Clinical text stays inside the consult workflow, by design.
• Trigger Medicare claims from your integration. Claims still happen through BP’s own claiming flow.
• Have BP push events to you (no native webhooks). The integration is poll-based or scheduled.

That last point shapes most of the architecture. You can’t subscribe to “tell me when a new patient is created”; you have to ask — on a sensible schedule — what’s changed since you last asked.

Pattern 1 — Reminder and recall systems

BP’s native reminder system covers the essentials. Practices needing multi-channel or chronic-disease recall workflows extend it. Practices that have outgrown it usually want:

• Multi-channel reminders — SMS and email at different intervals, with smart fallbacks (try SMS first, email if SMS bounces, voicemail drop if both fail)
• Recall workflows for chronic disease management (annual care plans, cervical screening, immunisation due dates) that pull from BP’s clinical fields
• “Confirm by reply” flows that update BP’s appointment status when a patient texts back

The build shape: a daily extract of upcoming appointments and patients due for recall, joined against the contact preferences in BP, run through a messaging platform like Twilio. Status updates flow back into BP via the appointment update endpoint, so the front desk sees the same picture as the integration.

Watch out for the one-way blast version. The reply path is what makes it useful. Without it, you’ve rebuilt BP’s native reminders with extra steps.

Pattern 2 — Online booking and intake

Patients booking online via the practice website is now expected. The integration is more nuanced than “book a slot”:

• Real-time availability has to reflect not just empty slots but provider preferences (this provider only sees new patients on Tuesdays, that one doesn’t do telehealth before 10am). BP’s appointment availability endpoint returns slots; the business rules around them live somewhere else.
• Intake forms completed online should populate BP’s patient record so reception isn’t re-typing during a 10am rush. This means mapping form fields to BP’s patient demographics — trivial in concept, fiddly in practice because BP’s field validation isn’t always documented.
• Returning patient matching matters more than it seems. A new booking from a patient who’s already in BP shouldn’t create a duplicate record. Email + date of birth + Medicare number is a reasonable matching key; phone alone isn’t.
• Payment at booking for private appointments is increasingly normal. The payment platform (Stripe, Tyro, Eftpos) needs to coordinate with the booking so that an abandoned payment doesn’t leave an orphan appointment.

This one pays back quickly. Every minute reception isn’t reading dates back over the phone is a minute of value.

Pattern 3 — Billing and accounting reconciliation

BP handles Medicare claims and patient billing; Xero (or MYOB) handles the practice’s books. The integration that needs to exist:

• Daily import of billed services from BP into Xero as sales invoices
• Bank feed matching that ties Tyro/EFTPOS receipts back to BP’s billing records
• Bulk-bill remittance from Medicare matched against BP’s expected claim amounts, with a flag on any short-pay
• Provider payment splits (when a practice runs multiple practitioners on different commission structures) calculated from BP’s billing data rather than spreadsheets

What the practice gets is a single accurate view of revenue per provider per day — instead of a fortnightly reconciliation between three reports that never quite agree. The trick is doing it without forcing the bookkeeper to learn a new tool.

Pattern 4 — Patient portal / clinical communication

A patient portal that pulls from BP — appointment history, upcoming bookings, scripts on repeat, results communicated by the provider — is becoming a more common ask. It’s also the integration where the boundaries matter most:

• The portal should read patient-facing data, not full clinical notes. The integration layer enforces what’s visible to the patient, not BP itself.
• Two-way messaging (patient sends a question, provider replies) usually lives in the portal, not in BP, with a copy filed to the patient record as a clinical note.
• Authentication needs to be more rigorous than “email and password” — patient identifiers cross-checked against BP’s record on each login.

The build is heavier than the other patterns — it’s closer to a custom application than an integration — but it’s also where Australian practices increasingly differentiate. A patient portal that works is hard to take a patient away from.

When it’s not worth the build

Three cases where the off-the-shelf BP add-ons are still the right call:

• A single-provider practice with low volume. Any custom integration costs more than the manual work it would replace.
• Practices without the operational maturity to maintain it. A custom integration needs a known person who notices when it’s broken. Without that, you’ve added a fragile dependency.
• A practice about to migrate off BP. The half-built integration to a system you’re leaving is the worst sunk cost in the category.

The threshold where custom pays back is roughly three providers, regular new patient flow, and an existing person (practice manager or operations lead) who already feels the manual work as a cost.

How a BP project usually starts

A BP project usually starts with a half-day audit: what data is being typed twice, which reports are being reconciled by hand, where the friction shows up in the practice manager’s week. The replacement plan stages the highest-friction items first (usually reminders and online booking), layers in billing reconciliation next, then takes on the heavier patient-portal work if it’s a fit.

If Best Practice is the core of your practice and the above is sounding familiar, the next step is usually a conversation about what to swap out first.

What a Best Practice integration typically costs

A first Best Practice integration typically lands in the $15,000–$40,000 range (ex GST) for a V1 build, depending on how many of the patterns above are in scope and the depth of each. Reminders and online booking sit at the lighter end; a patient portal pulling live clinical data sits at the heavier end. Build timelines are usually 6–12 weeks from engagement, with the security review and clinical-data alignment being the longest single workstream given the sensitivity involved. Plan for an ongoing maintenance retainer — typically $500–$1,500/month — covering API change monitoring, hosting, security updates and light support, because a clinical integration needs someone watching it.

Common questions

Do we need to leave Best Practice to do this? No. A custom integration works alongside Best Practice, which stays the clinical source of truth. The integration reads from and writes to BP through its API; it does not replace it.

How is patient data kept secure? Australian data residency, encryption in transit, least-privilege access scoped to only the data the integration needs, and audit logging. It is built to support the practice in meeting its own privacy and security obligations.

Will it break when Best Practice releases an update? APIs change, so the maintenance retainer covers monitoring Best Practice API changes and keeping the integration current. The build itself uses idempotent, well-tested patterns, so a transient error does not corrupt data.

How soon do we see value? Most projects stage the highest-friction item first — usually reminders or online booking — so the first piece is typically live within the first few weeks rather than waiting for the whole build.

What size practice does this make sense for? Roughly three or more providers, a regular flow of new patients, and someone in the practice who already feels the manual work as a cost. Below that, the manual process is usually cheaper than the integration that would replace it.