One appointment, four funding schemes

A patient books an appointment and is shown a price. Behind that single number sit as many as four ways it might actually be paid: a public health scheme, a disability scheme, a private health fund, or the patient's own card.

Everything difficult about booking in this domain follows from one sentence: the price is shown before any payer has answered.

Eligibility and adjudication are not the same event

Eligibility is checked beforehand and answers a narrow question: does this person appear to be covered. Adjudication happens afterwards and answers the real one: will this specific service, by this practitioner, on this date, for this person, be paid.

Between the two sits the appointment. It has already happened. The clinician has given the hour, the patient has gone home, and only now does the payer decide.

Systems that model this as one step work in testing and fail in production, because in testing the two answers agree. In production they diverge for reasons that have nothing to do with software: a referral expired, an annual cap was reached earlier that week at a different clinic, a plan was managed differently than the record suggested, the service code was valid but not for this practitioner type.

What a rejection actually costs

A claim rejected after the service is not a failed transaction to retry. It is a bill the patient never agreed to, arriving days later, for care they believed was covered.

The practitioner has already delivered the hour. Somebody now has to decide whether to pursue the patient, absorb the loss, or resubmit and wait. That decision is a phone call, and the phone call is why practices leave platforms.

So the design goal is not maximising claim success. It is making the uncertainty visible at the moment of booking, in language a patient understands, without turning the flow into a disclaimer nobody reads.

Modelling it

The mistake is treating the claim as a status on the appointment. It is a separate object with its own lifecycle, and it needs to be, because the two diverge constantly:

• An appointment is completed while its claim is still pending.
• A claim is rejected, resubmitted with a corrected code, and paid — three states against one unchanged appointment.
• One appointment produces two claims, because part is covered by a scheme and the remainder is a gap the patient pays.
• A claim is paid, then reversed months later after an audit.

Once these are separate, several previously awkward things become straightforward. Partial funding is two claims rather than a special case. Reversal is a new state rather than an edit that destroys history. And the question what is this appointment worth has one answer per payer instead of one contested answer.

The rules that differ per scheme

Each payer brings its own version of the same handful of questions, and none of them agree:

Cancellation and non-attendance. Whether a missed appointment is claimable, chargeable to the patient, or neither, varies by scheme — and a scheme that forbids charging the patient means the practice absorbs it.

Who may deliver the service. Practitioner type, registration status and supervision arrangements can each invalidate an otherwise correct claim.

Caps and periods. Annual limits, per-referral session counts and renewal dates that are not calendar-aligned, often consumed elsewhere by providers this system cannot see.

Timing. Submission windows, and how long a payer may take before an unanswered claim is treated as refused.

None of this is complex individually. It is that the combinations are what the system has to be correct about, and the combinations are not documented anywhere as a set.

Reconciliation is the part that gets underestimated

Money arrives in batches that do not correspond to appointments. A single remittance covers many claims, some paid in full, some reduced without explanation, some absent entirely.

Matching that back to individual claims is where the real accounting lives, and it is the feature nobody scopes at the start. Without it, a practice can tell you what it billed and not what it was paid, and the difference is the only number that matters to them.

Why "just integrate the API" misses it

The integration is the easy part and it is what estimates are built around. Authentication, a request, a response.

The product is the state machine around it: what the patient was told, what was checked, what was claimed, what came back, what is owed, and by whom. Getting the API call right is a week. Getting the state machine right is the system, and it is what determines whether a practice trusts the platform enough to put its whole book through it.