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.
Pay-as-you-go has ended.
Action needed
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, not 50 cents.
| 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.
Your plan costs less.
The change. Every plan is $10 a month less than it was.
Your next step. 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, at $190 a month plus GST, is a new plan for a practice with fewer requests than any plan we offered before.
The reason. A small practice should have a plan of its own size.
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.
Every eligibility result shows its checks.
Action needed
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 Having a referral for this Medicare item is optional, therefore, referral check was skipped.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. One reason told you what stopped an item. The full list shows what to correct and what is already right, 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.
Action needed
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 come up most often are the ones worth acting on. Now they are counted, ranked and in plain words.
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. In the web app, the item’s description appears beside its number before you calculate, so a wrong number is caught first.
- 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 An ‘Audiologist’ may render this Medicare item. MBS item 10952 — audiology service, rendered by an audiologist.Eligible
- No restriction Any provider may render this Medicare item. No servicing-provider restriction is recorded for this item’s MBS group.Eligible
- Not eligible The provider is not eligible to render this Medicare item. Provider specialties: [ ‘Physiotherapist’ ]. Specialties eligible to render this item: [ ‘General Practitioner’ ]. MBS Category 1, Group A1 — general practitioner attendances.Not eligible
The reason. A claim rendered by a provider who may not render the item is rejected at assessment, after the service. This check happens before the claim goes in.
Your next step. 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.