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

Quick answer: Best Practice Software has an API, and 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 are almost always 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 that most Australian general practices and allied health clinics use, alongside Medical Director. It does what it’s designed for — clinical record-keeping, prescribing, Medicare claiming — well 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 about: 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

The native BP reminder system works but is limited. 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.

The trap to avoid: building this as a one-way blast. The reply path is what makes it useful; without it, you’ve replicated BP’s built-in 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 an appointment”:

• 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 is one of the integrations that pays back quickly. Every minute reception isn’t spending on the phone reading dates back to a patient 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 this gives the practice 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.

What custom doesn’t buy you

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

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

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

How we approach BP integration work

Most BP integration projects we take on start with a half-day audit: what data is currently being typed twice, what reports are being reconciled manually, 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 — then layers in billing reconciliation, then the heavier patient-portal work if it’s a fit.

If you’re running Best Practice across a medical or allied health practice and recognising any of the above, that’s usually the prompt to talk about replacing the parts that aren’t holding.