Most Australian practices check Medicare eligibility one of three ways: staff working from memory and reference guides, the Medicare module built into their practice management system, or purpose-built Medicare eligibility software. Each catches some problems and misses others. This page sets out where each approach holds up and where it breaks, so you can see which one fits your clinic.
What it is. Your booking and billing team assess each patient against the Medicare rules using their training, printed guides, and experience. When a claim is wrong, you usually find out after Services Australia rejects it, and someone corrects and resubmits.
Where it holds up. It costs nothing to start, and experienced staff handle the common cases well.
Where it breaks. Some rules cannot be checked from a desk. Frequency limits, and what a patient has already claimed this year, live only in Medicare's own systems, so no amount of training or reference material can surface them in the moment. That is not a staff problem; it is a system gap. The rules also change several times a year, so a printed guide is out of date soon after it is printed. Over time the clinic normalises a rejection rate it should not have to, and the best billing staff carry the load.
You cannot train a person to know something only Medicare's systems know.
What it is. Most practice management systems include a Medicare billing module that lodges claims and does some checking.
Where it holds up. It is already installed and paid for, it is part of the clinical workflow, and it is one less vendor to manage.
Where it breaks. Inside a PMS, Medicare is a secondary feature. Rule coverage is usually narrower, updates arrive more slowly, and eligibility is often checked late in the process, or not before submission at all. A check that happens after the claim is built catches less than one that happens before.
What it is. Software whose only job is Medicare eligibility and claiming. It checks each claim against the Medicare rules that cause most rejections before the claim is submitted, and answers one question in milliseconds: will Medicare pay for this, how much, and if not, exactly why.
Where it holds up. It sees the rules a desk cannot, including frequency limits and prior claims, because it queries Services Australia directly. Rule updates are applied automatically on the Services Australia release cycle, so your team never has to track MBS amendments. And it sits alongside your PMS rather than replacing it.
The trade-off, honestly. It is another vendor, and it works best when your team actually uses it at the point of booking or billing.
Building your own integration is a fourth option some larger groups consider. That is a developer decision with its own trade-offs, covered in how to connect your software to Medicare.
| What to compare | Manual | PMS module | Purpose-built (e.g. RebateRight) |
|---|---|---|---|
| Checks before you submit | Sometimes, on staff judgement | Often late, or at submission | Yes, before submission |
| Sees Medicare-only data (frequency limits, prior claims) | No, not visible from a desk | Varies, usually limited | Yes, queries Services Australia |
| Rule updates kept current | Manual, and lags | Slower | Automatic, on the Services Australia cycle |
| Rule coverage | The rules staff remember | Narrower, Medicare is secondary | 300+ Medicare rules across the ~6,000-item MBS |
| Fits alongside your PMS | n/a | It is the PMS | Yes |
| Patient data stored | Depends on your process | Stored in the PMS | None, RebateRight stores nothing |
| Cost to start | Low | Included | Subscription |
RebateRight is Medicare eligibility intelligence, built for Australian healthcare providers. It catches the rejection before Medicare does, so the claim is right the first time.
It verifies patient eligibility and checks each claim against 300+ Medicare rules before submission, then lodges clean claims with Services Australia. It covers Medicare and DVA claiming, patient verification, and the AIR, and it comes as a web app for your team or an API for the systems you already run on. It is Services Australia Certified, and maintained continuously as the rules change.
It is not a practice management system, and it does not replace yours; it sits alongside it. It does not run your billing for you. And it never collects patient data, so there is nothing to store.
Naming our limits is part of the point.
Most use one of three approaches: staff checking manually against training and reference guides, the Medicare module inside their practice management system, or purpose-built Medicare eligibility software that checks each claim before it is submitted.
Because some rules cannot be seen from a desk. Frequency limits and a patient's prior claims live only in Medicare's systems, so training and printed guides cannot surface them in the moment. It is a system gap, not a staff mistake, and it is why rejection rates creep up even with careful teams.
Many do some checking, but in a PMS Medicare is a secondary feature. Rule coverage is usually narrower, updates are slower, and the check often happens late or at submission rather than before it. That catches fewer problems than a check run before the claim is built.
Software whose only job is Medicare eligibility and claiming. It checks each claim against the Medicare rules that cause most rejections before submission, and returns whether Medicare will pay, how much, and if not, why.
No. Purpose-built eligibility software like RebateRight sits alongside your PMS. Your PMS stays where it is; the eligibility check runs before the claim goes to Medicare.
No, and any tool that promises that is overselling. What a pre-submission check does is catch the rejections that are catchable before you submit, so your rejection rate falls and fewer claims come back for rework.
The fastest way to judge any of these approaches is against your real claims. Book a demo and we will show you rejections you could have caught before submission.