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 and safe to run with no patient data in play.

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).

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 and safe to run with no patient data in play. <CardGroup cols={1}> <Card title="Provider Atlas: every specialty and credential" icon="sitemap" href="/provider-atlas"> 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. </Card> </CardGroup> #### The sources behind every check RebateRight resolves the answer from the authoritative sources that govern who may render an item: <CardGroup cols={2}> <Card title="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.</Card> <Card title="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.</Card> <Card title="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.</Card> <Card title="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.</Card> </CardGroup> 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

API Key authentication via header

Path parameters

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

404

Not Found Error