Recent updates.
The latest, in one place.
Each update to the product, the plans and the agreements is recorded here, with the reason for it and what it means for you.
New endpoints: in-patient claims (ECLIPSE).
The change. The API now lodges in-patient claims, for the medical services a patient receives while admitted to hospital.
| Lodge a claim | |
|---|---|
| Each claim type has a general, a specialist and a pathology endpoint. | |
| Agreement | The fund pays the provider both benefits in one payment, under the provider’s agreement with the fund. |
| Scheme | The fund pays the provider both benefits in one payment, under a scheme with the fund. |
| Billing Agent | Medicare and the fund each pay the billing agent. |
| Medicare Only | Medicare pays the billing agent, and no fund takes part. |
| Patient Claim | For a paid account, Medicare pays the claimant, who may not be the patient, and the fund pays the patient. Otherwise each pays by a cheque made out to the provider. |
| Follow the claim | |
| Status Report | Whether a claim’s report, or its payment, is ready. |
| In-Patient Claim Report | Medicare’s assessment of each service, and the fund’s where the claim type has one. |
| Remittance Advice | The amount deposited, its reference on your bank statement, and the benefit paid for each claim. |
-
When you lodge
Acknowledged
Medicare accepts the claim for processing.
Item 30026
-
Once assessed
Reported
- Medicare
- $46.95
- Health fund
- $15.63
-
Once paid
Paid
$62.58
One payment from the health fund, for both benefits.
The reason. Your in-patient claims go through the same API as your bulk bill, patient and DVA claims, from lodgement to payment.
Your next step. If you use the API, add in-patient claims to your integration, and build against the test environment first.
New endpoints: health fund checks.
The change. The API now asks the patient’s health fund, through Services Australia, whether it holds their membership and what it pays for an admission.
| Get Participants | The health funds and DVA, each with its code and the checks and claims it accepts. |
|---|---|
| Health Fund Verification | Whether the fund holds the patient’s membership. |
| Medicare and Health Fund Verification | Whether Medicare knows the patient, then whether the fund holds the membership, in one request. |
| Health Fund Eligibility Check | An estimate of what the fund and the patient pay for an admission to a hospital or day surgery. |
Hazel Nash
- Date of birth
- 14/08/1993
- Medicare card
- 2954 53642 1 IRN 1
- Health fund
- TST member 1234567
- Medicare Patient is eligible to claim for Medicare with details provided.
- Health fund Patient is known to the Health Fund specified in the request.
The reason. Before an admission, the patient sees what their fund is estimated to pay, so they can give informed financial consent. The answer comes from the fund itself.
Your next step. If you use the API, run the checks before each admission.
Read Health fund checks in the docsPrint the estimate with Eligibility Report (PDF)
New endpoint: Overseas Visitor Eligibility Check.
The change. The API now asks an overseas visitor’s health fund what it pays for their treatment, in hospital or out of it.
| Overseas Visitor Eligibility Check | The visitor’s cover, and an estimate of the fund’s benefit for each medical service. |
|---|
-
In hospital
Item 30026
- Charge
- $120.00
- Fund benefit
- $20.00
-
Out of hospital
Item 23
- Charge
- $60.00
- Fund benefit
- $20.00
The reason. Before treatment, the visitor sees what their fund is estimated to pay, so they can give informed financial consent.
Your next step. If you treat overseas visitors and use the API, run the check before their treatment.
Read Overseas Visitor Eligibility Check in the docsPrint the estimate with Eligibility Report (PDF)
Browser extension: check eligibility from your practice software.
The change. RebateRight now has a browser extension. It opens beside your practice software, in your browser, and one click reads the patient on your screen.
The reason. You no longer enter the patient’s details by hand: the extension takes them from your practice software.
Your next step. Add the extension to your browser and connect it with the API Key and Minor ID you use in the web app.
Extra requests now cost your plan’s rate.
Action needed
The change. Before the September update, each request beyond your plan cost 50 cents. Now each extra request is charged at your plan’s rate, shown with each plan on the pricing page. We invoice extra requests at the start of your next billing cycle, on the same invoice as your plan.
The reason. A busy month should cost you the same for each request as your plan does. In a busy month, you should still receive one invoice each billing cycle, on the same billing day.
| Row | Now | September update | Before the September update |
|---|---|---|---|
| When you use all your requests | Your billing cycle continues | A new billing cycle begins that day | Your billing cycle continues |
| What you pay | Your plan’s rate, for each extra request | Your full plan fee, for the new cycle | 50 cents for each extra request |
| When it is invoiced | At the start of your next billing cycle, with your plan | That day, on an invoice of its own | When the cycle ends, on an invoice of its own |
| Your billing day | Stays the same | Moves to the day the new cycle began | Stays the same |
Your next step. If you are an existing customer, accept the updated Pricing Agreement in the web app, under Accept terms.
The web app shows your usage and billing.
The change. The home page of the web app shows your billing cycle and your plan history.
Within the plan
- Used
- 308 / 1,000requests since 1 Oct
Up to 1.5 times the plan
- Used
- 612 / 1,000requests since 1 Oct
More than twice the plan
- Used
- 1,180 / 1,000requests since 1 Oct
- Extra requests
- 180invoiced when this billing cycle ends
- Your plan
- Tier 21,000 requests a month
- Best plan for your pace
- Tier 32,000 requests a month
| Colour | By the end of the cycle, at your current pace, you use |
|---|---|
| Blue | Your plan’s requests or fewer |
| Yellow | Up to 1.5 times your plan’s requests |
| Orange | Up to twice your plan’s requests |
| Red | More than twice your plan’s requests |
- Plan
- Tier 2
- Included requests
- 1,000 a month
- Invoiced on
- 1st of each month
- Joined
- 17 June 2026
- Trial ended
- 30 June 2026
-
1 October 2026
Tier 2Current
1,000 requests a month · invoiced on the 1st of each month
-
1 July 2026
Tier 2
1,000 requests a month · invoiced on the 1st of each month
Until 30 September 2026
-
17 June 2026
Trial
Until 30 June 2026
1 October 2026. Tier 2 moved from $300 to $290 a month, when five plans cost less. The web app shows no prices, so the two Tier 2 rows read the same. Each price is on your invoice.
The reason. You can see where your billing cycle stands while it is running, in time to switch plans before the next one begins.
Your next step. There is nothing to set up. Your billing cycle is on the home page of the web app and on Insights.
Pay-as-you-go has ended.
Superseded
Superseded. The October 2026 update replaces this one.
The change. Previously, each request beyond your plan cost 50 cents. Now, as soon as you have used all your requests, a new billing cycle begins. It is the same plan at the same price, and your access continues. The new cycle is invoiced on the day it begins. A request beyond your plan now costs what a request within your plan costs, and is no longer a pay-as-you-go charge.
| Row | March2,000 requests | April1,000 requests | Two months3,000 requests |
|---|---|---|---|
| Before | $800$300 plan + $500 pay-as-you-go | $300$300 plan | $1,100$800 + $300 |
| Now | $600$300 + $300, the second cycle beginning when the first is used up | $300$300, one cycle | $900$600 + $300$200 less |
The reason. A busy month should not cost more for each request than a quiet one. Every request now costs what your plan charges, so a practice whose usage sits between two plans pays the plan rate for the extra, not a higher rate.
Your next step. Accept the updated Pricing Agreement in the app, under Accept terms.
Five plans cost less.
The change. Each of the 5 plans in the table is $10 a month less than it was.
| Plan | Requests a month | Before | Now |
|---|---|---|---|
| Tier 2 | 1,000 | $300 | $290 |
| Tier 3 | 2,000 | $500 | $490 |
| Tier 4 | 5,000 | $1,000 | $990 |
| Tier 5 | 10,000 | $1,800 | $1,790 |
| Tier 6 | 20,000 | $3,200 | $3,190 |
Your next step. If you are on one of these plans, no action is needed. The lower price applies to your account from your next billing cycle.
A new plan for small practices.
The change. Tier 1 is a new plan, smaller than any plan we offered before. It includes every feature, the same as every plan.
| Plan | Requests a month | A month |
|---|---|---|
| Tier 1 | 200About 10 a business day | $190 |
The reason. A small practice should have a plan of its own size.
Your next step. If you use fewer than 200 requests a month, email hello@rebateright.com.au to move to Tier 1. The change takes effect at the start of your next billing cycle, and there are no additional fees.
MBS lookups in the web app are free.
The change. Look up any MBS item in the web app, as often as you need to, and it never counts as a request. This is in place now, on every plan.
MRI scan of musculoskeletal system for derangement of one or both temporomandibular joints or their supporting structures (R) (Contrast) (Anaes.)
- Schedule fee
- $386.55
- Benefit
- $328.60 out of hospital, 85%$289.95 in hospital, 75%
- Category
- 5
- Group
- I5
- Subgroup
- 12
- Fee from
- 1 July 2026
- Item from
- 1 August 2004
- Referral
- An approved dental practitioner, a dental specialist or a specialist medical practitioner.
- Claim history
- Not more than three times in a 12 month period.
Every eligibility result shows its checks.
The change. Previously, an eligibility check gave one answer for each item and, if the item was not eligible, one reason. Now it shows every check that ran on the item: which passed, which did not, and why, in plain words. More than one check can fail, and you can see that the rest ran and passed.
7 checks · 1 flagged
- Patient age This Medicare item does not have patient age restrictions.Eligible
- Referrer eligibility A referral is optional for this item, so it is accepted with any referrer or with none.Eligible
- In-hospital status The rebate for this Medicare item is available to both in-hospital and out-of-hospital patients.Eligible
- Patient sex This item is not restricted based on patient sex.Eligible
- Frequency of service Maximum number of services for this item already paidNot eligible
- Multiple item restrictions No conflicting or mutually exclusive item restrictions applied to this claim.Eligible
- Other Medicare checks Medicare's remaining checks (servicing provider, referral requirements, and similar) raised no restrictions.Eligible
The reason. Previously, a check stopped at the first rule it caught. You would correct it, run the check again, and find another rule hadn’t passed. Now every rule is checked and listed together, showing what passed and what needs correcting, so the claim is right the first time.
Your next step.
- If you use the web app, no action is needed. Every result already shows its checks.
- If you use the API, we strongly recommend showing the list of checks in your own application, so the people using it see what stopped an item and what passed. The change is backward compatible: the single reason is still there, and your integration keeps working as it is. The eligibility check page in the docs shows the list.
Patient details are optional in an eligibility check.
The change. You can leave the patient’s details out of an eligibility check, in the web app and through the API. Every check that does not need them still runs. A check that does need a detail says which one it was missing, instead of the whole item coming back unanswered.
The reason. Many checks never needed the patient. The age, referrer, in-hospital and sex rules are rules about the item, and RebateRight runs them itself, so a missing family name should not blank them.
Your next step.
- If you use the web app, no action is needed. Leave any detail you do not have blank.
- If you use the API and your integration requires the patient’s details before it sends a check, you can remove that requirement. A check without them still returns a valid result, with each check’s finding.
Insights shows the reasons behind your checks.
The change. Insights now ranks the reasons behind your eligibility checks for the month: why items were not eligible, why some could not be determined, and why the rest were eligible. The most common reason sits at the top, with its count and its share.
Not eligible reasons
Medicare or our rules found a reason the item would not be paid.
- Maximum number of services for this item already paid160 431 34.9%
- Referrer specialty ineligible 288 23.3%
- Requires in hospital 201 16.3%
- Age out of range 154 12.5%
- Coning applied 92 7.4%
- Patient sex mismatch 41 3.3%
The reason. The reasons that surface most often are the ones worth acting on. Now they are counted, ranked and easy to interpret.
Your next step. There is nothing to set up. Open Insights in the web app and choose a month.
New endpoint and page: Benefit Calculator.
The change. The Benefit Calculator is a new endpoint and a new page in the web app. Give it an MBS item number, the patients seen and the setting, and it returns the schedule fee, the benefit for each patient and what Medicare pays for the occasion, with how the amount was worked out.
- Schedule fee
- $53.35per patient
- Benefit
- $53.35per patient
- Setting
- Out of hospital
Medicare item 5010 has a derived fee: the fee for item 5000 ($34.70), plus $55.95 divided by the number of patients seen (3), rounded to the nearest 5 cents. The schedule fee is $53.35 per patient, and Medicare pays a benefit of 100% of that fee, as published in the MBS Ready Reckoner.
Your next step.
- If you use the web app, no action is needed. It is under Benefit Calculator.
- If you use the API, the Benefit Calculator page in the docs shows the request and the response.
New endpoint: Servicing Provider Eligibility.
The change. A new endpoint, Servicing Provider Eligibility, tells you whether a servicing provider may render and claim an MBS item, before the claim is lodged. Send a provider number and an item number, and it answers eligible or not, with the reason in plain words: the specialty that qualifies, or the provider’s specialties beside the ones the item needs. No patient details are sent and no call to Medicare is made, so it is fast enough to check every line of a batch.
-
Eligible
Item 10952 · Audiologist
An audiologist may render this Medicare item.
MBS item 10952, audiology service, rendered by an audiologist.
-
Eligible
Item 30071 · Physiotherapist
Any provider may render this Medicare item.
No servicing-provider restriction is recorded for this item’s MBS group.
-
Not eligible
Item 23 · Physiotherapist
The provider is not eligible to render this Medicare item.
- Provider
- Physiotherapist
- Eligible to render
- General Practitioner
MBS Category 1, Group A1, general practitioner attendances.
The reason. A claim rendered by a provider who may not render the item is rejected at assessment, after the service. This check runs before the claim is lodged.
Your next step. The endpoint is included in every plan. If you use the API, add the check to your integration. The Servicing Provider Eligibility page in the docs shows the request and the answers.
Questions about any update are welcome at hello@rebateright.com.au.