Servicing Provider Eligibility | RebateRight

Checks whether a servicing (rendering) provider may perform and claim a given MBS item. It runs before the claim is lodged, so a wrong-provider rejection is caught up front rather than at assessment.

The check runs entirely within RebateRight: no Medicare call and no patient details, only a ProviderNumber and an ItemNumber. That makes it fast enough to validate every line of a batch.

Provider Atlas: every specialty and credential

Every eligibility answer rests on the recognition Medicare holds for the provider. The Provider Atlas maps them all, and shows how the same recognitions decide who may render, claim, and refer each item.

The sources behind every check

RebateRight resolves the answer from the authoritative sources that govern who may render an item:

Provider recognitions

The specialties, fields and credentials Medicare recognises for the provider, expanded through RebateRight’s recognition hierarchy so that allowing a broad class (such as a specialist medical practitioner) automatically covers every sub-specialty beneath it.

MBS item structure

The item’s MBS category, group and sub-group (the layered structure mapped to eligible specialties), together with the item’s own descriptor, which can override the group rule where an individual item is tighter or broader.

Legislative determinations

The Diagnostic Imaging, Pathology and General Medical Services Tables on the Federal Register: the legislation that sets, item by item, which providers may render and bill a service, beyond what the descriptor alone states.

MBS explanatory notes

Conditions a specialty alone cannot express, such as Approved Pathology Practitioner status, nuclear-medicine credentialling, or CT coronary angiography recognition. RebateRight surfaces these in the Reason as a “verify separately” pointer with its MBS reference.

To stay accurate, RebateRight continually reconciles its determinations against Medicare. The result is advisory: the binding decision is made when the claim is assessed.

Reading the result

A 200 always returns a boolean IsEligible and a plain-language Reason. Three shapes come back:

IsEligible: true with a specialty named. One of the provider’s specialties may render the item; the Reason names the matching specialty and the MBS group or item rule it satisfied.
IsEligible: true, no restriction. The item is open to any provider, so no specialty gate applies.
IsEligible: false. None of the provider’s specialties may render the item; the Reason lists the provider’s specialties alongside the eligible ones, so the gap is explicit.

Where an item carries a further condition the API cannot confirm from a provider number (a credential, supervision, or accreditation rule), the Reason appends a “verify separately” note with its MBS reference, so nothing is silently assumed.

Status codes

200: eligibility determined; read IsEligible and Reason.
404: the ProviderNumber or ItemNumber was not found. The body is plain text (see the 404 example).

Authentication

x-api-keystring

API Key authentication via header

x-minor-idstring

Your Minor ID is three uppercase letters followed by five digits, such as MDE00001. Send the Minor ID exactly as issued. A malformed value gets a 400 with “The Minor ID is not valid.” on every endpoint.

Request

This endpoint expects an object.

ProviderNumberstringRequired

The servicing provider’s Medicare provider number, exactly as issued (case-sensitive, including the location and check-digit characters).

ItemNumberstringRequired

The MBS item number being checked.

Response

Eligibility was determined.

IsEligibleboolean

Whether the provider is eligible to perform and claim the item.

Reasonstring

Plain-language explanation of the eligibility decision, naming the matching or eligible specialties, the MBS group or item rule applied, and any “verify separately” note.

Errors

400

Bad Request Error

404

Not Found Error