RebateRight APIMedicare Eligibility

Eligibility Check

View as Markdown
<Card title="Will Medicare pay for this service provided to this patient?"> That is the question this endpoint answers, for up to 50 MBS items in one call, with the reasoning behind every answer. </Card> Verifies the patient with Medicare and checks each item you send. One item can be eligible while another is not. ## What you get back ``` PatientVerification Rebates[] ├─ ItemNumber ├─ IsEligible ├─ Reason ├─ ReasonCode ├─ Benefit ├─ ItemScheduleFee └─ Checks[] ├─ Title ├─ IsEligible ├─ Reason └─ ReasonCode ``` Three levels, each answering a narrower question: | Level | Answers | Use it for | |---|---|---| | The patient (`PatientVerification`) | Did Medicare recognise this patient? | Correcting the patient's details | | Each item (`Rebates`) | Can the patient claim this item? | The answer you act on | | Each check on an item (`Checks`) | What one rule found | The working behind that answer | Items and checks carry the same three fields: | Field | What it holds | |---|---| | `IsEligible` | The answer. `true`, `false`, or `null` | | `Reason` | Why, in one sentence you can show as it is. | | `ReasonCode` | A code for that reason, for analytics only. | An item carries four more: | Field | What it holds | |---|---| | `ItemNumber` | The item you asked about, echoed back. `"104"` | | `Benefit` | What Medicare pays, in dollars. `"88.36"`, never cents | | `ItemScheduleFee` | The MBS fee for the item. `"103.95"` | | `Checks` | One entry per check that ran on this item | A check carries one more, `Title`, naming what it looked at: `"Patient age"`, `"Frequency of service"`. <Card title="See a full result, rendered" href="https://rebateright.com.au/eligibility-check-result"> The answer on each item, the benefit and the checks, laid out as a screen. For the front desk as much as the developer. </Card> A full response is in the example panel alongside this page. ## `IsEligible`: `true`, `false`, or `null` `IsEligible` is not a yes/no flag. Handle all three values: | `IsEligible` | Result | Meaning | What to do | |---|---|---|---| | `true` | **`eligible`** | The patient is eligible to claim this item. | Proceed with the claim. | | `false` | **`not eligible`** | The patient is not eligible. | Show `Reason`. A claim would not be paid. | | `null` | **`cannot determine`** | The item couldn't be checked for this patient. | Show `Reason`, and see below. | ## When `IsEligible` is `null` Something a check needed was missing or unavailable, so the item could not be decided. A `null` is never a quiet `false`. Only `false` says the patient can't claim. The causes include: | Cause | What to do | |---|---| | No referrer sent, on an item that requires one | Send `ReferrerProviderNumber` and check again. See [Provider Atlas](/provider-atlas). | | A field is missing, or its value is wrong | Fix that field and check again. `Reason` names it. | | Medicare doesn't verify this item online, and it has a claim-frequency limit | Nothing is missing from your request. Decide using the patient's history. See [coverage](/eligibility-coverage). | | The details you hold don't match Medicare's current record | Correct the details and check again. `PatientVerification` says what was wrong, and `Checks` shows what could still be checked. | ## The checks Every check that ran on an item appears as an entry in its `Checks`: patient age, referrer eligibility, in-hospital status, how often the item has been claimed, items that conflict on the same day, the servicing provider, and more. Check titles stay stable. New checks appear as coverage grows, so handle unfamiliar titles gracefully. Not every item can be confirmed with Medicare online. Those answers are **indicative**. The [coverage guide](/eligibility-coverage) lists which items fall where. ## How to use each field | Field | Use it for | Don't | |---|---|---| | `IsEligible` | Branching your logic. | Treating it as a boolean. | | `Reason` | Showing the outcome to staff or patients. | Parsing it. The wording changes. | | `ReasonCode` | Analytics, grouping, and reporting. | Branching your logic. | <Note> **New `ReasonCode` values appear over time**, as RebateRight covers more checks. That is not a breaking change, so treat the set as open. </Note> <Warning icon='gavel'> **Display `Reason` exactly as supplied.** It is a requirement by Services Australia that its messages are displayed to the end user exactly as supplied in the response, not truncated, transformed, or changed in any way. The wording may be updated at any time, so never parse `Reason` for logic. This applies at both levels, the item's `Reason` and each check's. </Warning>

Authentication

x-api-keystring
API Key authentication via header
x-minor-idstring
API Key authentication via header

Request

Only MedicareItems is required. Without the patient details, RebateRight still checks each item’s MBS rules, such as in-hospital and referrer restrictions. To verify the patient and confirm eligibility with Medicare, send the patient details, the servicing provider number and the principal provider number.

MedicareItemslist of objectsRequired

MBS items to evaluate. Up to 50 items total, grouped into up to 16 medical events (via MedicalEventId) with up to 14 items per event.

DateOfServicedateOptional

Date the service was / will be performed (YYYY-MM-DD). Defaults to today when omitted. Cannot be in the future or more than 2 years in the past.

InHospitalTreatmentbooleanOptional

Whether the service is provided to an in-hospital patient. Drives the in-hospital vs out-of-hospital rebate percentage and several MBS restriction rules. Defaults to false when omitted — the service is treated as out-of-hospital.

BulkBilledbooleanOptional

Optional. Indicates the service will be bulk-billed. Used only by rules that differ between bulk-bill and non-bulk-bill scenarios. Defaults to false when omitted — benefits are quoted at the not-bulk-billed rate, so an item carrying the bulk-billing incentive quotes 85% rather than 95% of the Schedule Fee unless you set it.

PatientDateOfBirthdateOptional

Patient date of birth (YYYY-MM-DD). Cannot be a future date or more than 130 years in the past.

PatientFamilyNamestringOptional
Patient family name as it appears on the Medicare card.
PatientGivenNamestringOptional
Patient first given name as it appears on the Medicare card.
PatientSexenumOptional
Patient sex (Services Australia coding). | Code | Meaning | |---|---| | `1` | Male | | `2` | Female | | `3` | Other | | `9` | Not stated / inadequately described | On a sex-restricted item, `9` returns `IsEligible: null`, since the restriction can't be checked without a recorded sex.
Allowed values:
PatientMedicareNumberstringOptional

Patient’s 10-digit Medicare card number.

PatientMedicareRefNumberstringOptional

Individual Reference Number (IRN) from the patient’s Medicare card, a single digit identifying the family member.

ReferrerProviderNumberstringOptional
Referring provider's Medicare provider number. Required when any requested item has a referrer restriction. Omit it and those items return `IsEligible: null` (**`cannot determine`**); supply a referrer Medicare doesn't recognise for the item and they return `IsEligible: false` with a plain-language reason. See the [Provider Atlas](/provider-atlas) for who may refer what.
ServicingProviderNumberstringOptional
Provider number of the health professional who performs the service.
PrincipalProviderNumberstringOptional

Provider number of the practice / principal provider the service is billed under. Often the same as ServicingProviderNumber.

Response

OK
PatientVerificationobject

Did Medicare recognise this patient? Always present. Same outcome as the Patient Verification endpoint, which documents the corrections in full.

Rebateslist of objects

One entry per item you sent, on every response. Match entries by ItemNumber rather than by position, since rules that weigh items against each other (such as coning) can reorder them. If you sent the same item twice, the duplicates keep their relative order.

Reasonstring

Legacy summary field, kept for backward compatibility. New integrations can ignore it and read PatientVerification and Rebates instead.