Allied Health Medicare Claiming: The Rules Software Must Enforce

The shape of an allied health claim

Chronic condition allied health items sit in the 10950–10970 range of the MBS, with one item per discipline (podiatry is 10962, for example). A claim needs everything an ordinary claim needs, plus referral details:

• Patient: name, date of birth, Medicare card number and IRN, all exactly as Medicare holds them.
• Servicing provider: the provider number of the practitioner who delivered the service, valid for that location on that date.
• Referral: the referring GP's provider number and name, and the referral issue date. The referral must be dated on or before the service.
• Item and benefit: the discipline's item number, the service date, and, for bulk billing, the full benefit for the financial year the service falls in.

Claim under the right provider number

The most expensive mistake in this area is also the simplest: lodging claims under the business's or principal's provider number instead of the number of the practitioner who actually treated the patient. Medicare does audit for it, and the result can be a suspension of claiming plus a backlog of unclaimed services to recover. The software should take the servicing provider from the practitioner who did the visit and show it on every claim, rather than using one number for the whole business.

The other provider-number trap is timing. A provider number is only valid from its start date, at its location. When we ran this client's first large backlog batch, most of the declines had a single cause: the practitioner's provider number for that location started after the services being claimed. A second group was declined because the practitioner's authorisation to claim through the intermediary hadn't been approved by Medicare yet. Check both before the first batch: each practitioner's number is active for every location and date being claimed, and the claiming authorisation is in place.

Caps that Medicare counts and you don't

Eligible patients can claim up to five allied health services per calendar year, combined across all disciplines and providers. Your system knows only about the visits it delivered. If a resident saw a physiotherapist from another business in March, Medicare's count is higher than yours, and your fourth visit gets declined as the patient's fifth or sixth.

So treat your count as a lower bound and Medicare's response as the real answer:

• Hold back claims that would exceed the cap by your count. Visits already billed, plus visits lodged and still outstanding, plus the new selection, must not go over five.
• Learn from cap rejections. When Medicare declines a claim because the cap has been reached, record the patient as 'Medicare max reached' for that year, even if your own count is under five, and move the service to private or facility billing.
• Don't treat every decline as a cap. Claims are declined for many reasons. Automatically marking a patient as capped because a claim was declined sends services to private billing that should have been corrected and resubmitted. Let staff mark cap rejections in bulk, but keep it a deliberate action.
• Keep a ledger, not a counter. Use one entry per patient per service date, tied to the referral period it counts against. Then a new referral resets the count properly, a reversal can't change the wrong period, and imported historical visits are marked for review instead of quietly changing the count.

Keep 'Max' and 'Invalid' separate

Staff need to tell apart a patient who has used their allowance and a patient whose claim data is wrong, because the next step is completely different. Track them as separate states, with invalid taking priority when both apply:

• Active: a valid referral with services remaining. Claim to Medicare.
• Max: the cap is reached for the year. Bill privately or to the facility, and label it that way on the invoice (for example 'EPC Max – Facility Funded').
• Invalid: missing or bad data, or an unusable referral. The data needs to be chased before anything else happens. Don't send it to private billing automatically just because a field is empty, because missing data doesn't mean the patient isn't eligible.

Getting claim data off paper

In aged care and other outreach settings, nobody fills in the patient's Medicare details at a front desk. They come from facility profiles, photographed day sheets and scanned referral forms, some of them handwritten. We used an LLM to read the referral forms and extract the six fields a claim needs (Medicare number, IRN, date of birth, and the referring GP's number, name and referral date). What made it reliable:

• Evidence for every field. Each extracted value comes back with a confidence level, the text it was read from, and which document it came from, using a strict JSON schema.
• All referral fields from one document. The GP's number, name and date must all come from the same referral, preferring the newest. Combining fields from different forms produces a referral that doesn't exist.
• Check digits after extraction. Medicare number and provider number check digits are re-checked after the model replies. A value that fails is flagged, not filled in. Validation details here.
• Read on upload, then store it. Extract when the form is uploaded, save the verified values to the patient profile, and reuse them. Don't read the form again for every claim. Never overwrite a value a person has already confirmed.
• Look in free-text notes too. Without a dedicated field, staff type Medicare numbers into notes. Include the notes in the extraction rather than assuming the structured fields are complete.
• Treat it as health data. Use an organisation-owned API key, turn off data retention and sharing, set a spend cap, and send only the documents for the patient being processed.

Workflow lessons from the first months

• Every patient on a visit report needs a route. A report is complete only when every patient seen has been claimed, billed privately, or marked not seen or deceased. One unrouted patient keeps the whole report open, so show a 'remaining actions' list on each report instead of a bare status.
• One word, one meaning. 'Declined' meant both 'the resident declined the visit' and 'Medicare declined the claim' until the first was renamed 'Not seen'. Check every billing word staff use before building screens around it.
• Decide what syncs into unsubmitted claims. Claim rows that took a copy of the profile when created stopped picking up later fixes to date of birth or name. Unsubmitted claims should follow the profile; submitted claims should keep the values they were sent with.
• Treat the old process as its own migration. Services handled under the previous manual process have no status in the new one, so the queue suddenly looks huge. Agree a cut-over rule, such as 'before date X, invoiced, never sent to the intermediary, so close it', and apply it once.
• Make the live site the one that's tested. In platforms with a preview environment, staff test the live site while fixes are only in preview. Agree a release routine, or fixed bugs will keep being reported as broken.