Healthcare & Disability /Document Generation live field guide · 9 min

MBS Coding Assistant

Maps the services in a clinical note to the right Medicare Benefits Schedule item numbers, showing the criteria it matched and any co-claiming restrictions, so the coder checks each suggestion against the note before it is billed.

Open the live demo

theater/demos/healthcare_mbs-coding.html · sandbox · read-only

Open

FIG. 1

The live demo, running on fabricated data. Open it to step through the full flow — every output is shown for a person to approve before anything happens.

How it would work

Reads the clinical note, matches the documented service to the MBS item the record actually supports, and surfaces the item, the evidence and the audit risk for a coder to approve before any claim is lodged.

Input 01

The clinical note

A consultation note — subjective, objective, assessment, plan — plus the provider type, place of service, and any time or complexity markers in the record.

Agent 02

Matches, checks, scores risk

Maps the documented service to a candidate MBS item, checks the item's time and content criteria against what the note records, and scores the audit risk of over- and under-coding.

Output 03

A suggestion, with its evidence

A suggested item with the lines of the note that met each criterion, the co-claiming and audit flags, and the alternatives — laid out for a coder or practice manager to check and approve before the claim is lodged.

Where it works well

It does the descriptor-by-descriptor check every time, and shows which line of the note earned the item.

Done by hand it is a judgement call per note — and under volume the descriptor check is the first thing skipped, which is exactly what under-coding and PSR exposure come from.
Best for a coder or practice manager reviewing in volume: high-throughput general practice, specialist clinics, billing services running claims for several practices.
At a day's encounters reviewed in one batch, the recaptured hours go back into the genuinely ambiguous notes and the audit-prep, not the easy ones.

The slow, invisible work in MBS coding is reading a note against an item's descriptor — does the record actually document the time, the history and the examination Item 23 or Item 36 requires? — for every encounter, when the descriptors and Schedule fees are reissued at least annually.

Where it works badly

It is confidently wrong when the note is thin or the item criteria have moved — and a clean suggestion looks more defensible than the record behind it.

The MBS item is the documentation, not the consult — if the note doesn't record the time and the examination, the item isn't earned no matter what the clinician did. The tool reads the note, not the room.
Weak where the service doesn't map cleanly to one item — co-claiming, after-hours, telehealth and chronic-disease items that turn on conditions a free-text note doesn't state. It should flag, not guess.
It cannot see the descriptor change you didn't load — Level B (Item 23) now turns on a 6-minute minimum, not the 10 minutes older guidance taught.

The honest test

If you cannot say, right now, which MBS Schedule version this is coding against and whether the note documents every criterion the item requires — this tool makes your wrong claim faster to lodge, not safer to defend.

Point it at a sparse note, or run it against last year's descriptors, and it suggests a tidy, plausible item the record does not actually support. The suggestion reads as defensible; the documentation underneath is not. That is the trap.

What it doesn't do — and shouldn't

It suggests. A coder approves. That boundary is deliberate.

WHAT IT DOES

Surfaces the candidate item and the line of the note that met each criterion

Flags audit risk — over-coding to a longer item, or under-coding a documented one

Shows the alternatives and the co-claiming or time restriction it checked

WHAT IT WON’T

Lodge the claim to Medicare

Certify the note as adequate for the item

Decide whether the service was clinically warranted

An MBS claim is a legal assertion that the service met the item's descriptor. A wrong item — over or under — is recoverable as a debt and can trigger a Professional Services Review for inappropriate practice, where reliance on templated, under-personalised notes is itself a finding. The accountable person — the billing provider — stays on the decision because the debt and the PSR exposure land on them, not the tool.

What your data has to look like

A note that actually documents the criteria, coded against the Schedule in force today.

Typical readiness

across orgs we see, before the first job

Clinical notes that record the criteria, not just the diagnosis

Needs shaping

The current MBS Schedule, machine-readable

Usual weak point

Provider type and place of service as structured fields

Usual weak point

Co-claiming and item-restriction rules

Needs shaping

Practice billing history for over/under-coding context

Needs shaping

The real first job

The note is usually the weak point — it records the diagnosis but not the minutes, the history depth or the examination the item actually requires. Fixing how the consultation is documented — so the record earns the item — is usually the real first job, larger and more valuable than the coding layer on top. Once the note documents the criteria, every claim after that is faster and defensible by default.

Right fit if…

You review MBS claims in volume — a clinic or billing service, not the occasional consult

Your clinical notes already record consultation time, history and examination

You can point to the MBS Schedule version in force today

Your bigger risk is consistent under-coding or PSR exposure, not one-off claims

Walk away if…

Your notes record the diagnosis but rarely the time or the examination performed

Most of your billing is non-standard — heavy co-claiming, after-hours, bespoke item mixes

You have no machine-readable, current copy of the Schedule

You want a tool that signs off the claim so you don't have to

Open questions

The worried-buyer questions, answered straight

It can suggest a wrong item — over or under — which is exactly why nothing is lodged on its say-so. It matches the documented service to a candidate MBS item, checks the descriptor’s time and content criteria against what the note records, and shows its working plus an audit-risk flag. A coder checks that before approving. Suggesting Item 36 (Level C, at least 20 minutes) on a note that only documents 15 minutes is precisely the case it flags rather than waves through — because that mismatch is what a Professional Services Review looks for. The tool surfaces the item; the billing provider stands behind it.

Only as well as the note. The MBS item is earned by what the record documents — consultation time, history taken, examination performed — not by what happened in the room. On a one-line note the tool can only suggest a low-level item like Item 3 (Level A), because nothing higher is evidenced. Getting consultations documented so the note records the criteria each item requires is usually the first piece of work, and the piece that pays off across every claim after.

No. It removes the descriptor-by-descriptor reading on the clear-cut notes so the coder spends their judgement on the genuinely ambiguous ones — the co-claiming, the after-hours and telehealth items, the notes that sit on a time threshold. The claim is still theirs to approve and the provider’s to stand behind. The capacity it frees goes back into audit-readiness and the hard cases, not into fewer coders.

Current to the Schedule in force on the date of service. MBS item descriptors and Schedule fees are reissued at least annually, indexed each 1 July, and individual items change mid-year — Item 23 (Level B) now turns on a 6-minute minimum, where older guidance taught a longer threshold. Code against last year’s descriptors and it confidently suggests items the current rules no longer support. The honest test: do you know, today, which Schedule version this is coding against?

A clinical note is sensitive health information under the Privacy Act and the Australian Privacy Principles, and a practice carries obligations around it including under My Health Record where relevant. Any deployment runs against your own systems and data handling, not a shared pool — we scope where the note data sits and who can see it as part of the build. The demo here runs entirely on fabricated data; Sarah Mitchell is not a real patient.

No. It codes to the descriptors it is given and flags where a note doesn’t meet an item’s criteria, but it does not certify the claim. Whether the service was clinically warranted, whether the note is adequately personalised, and whether the item is the right one for this occasion of service come from the billing provider’s own obligations — a person confirms those. The tool gets the suggestion most of the way; the accountable provider closes the last step.

What it takes to build

3–4 weeks · 4 phases

Reused from template~70%

Bespoke to this skin~30%

stack · Claude · MBS rule set · review UI

What it would cost

Fixed scope, fixed price, fixed dates.

Bite-sized first piece

One contained change, low risk

Pilot build

Most builds land here

Embedded support

Scale on proof

Considering this for your practice?

The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where the coding hurts; we'll play it back, scope it, and show you what's possible.

Book a call How we work