> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.rebateright.com.au/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.rebateright.com.au/_mcp/server. # What Services Australia requires of your software RebateRight holds a [Notice of Integration](/api-reference#notice-of-integration) from Services Australia, so your software needs none of its own. Your software still follows the rules on this page, which Services Australia sets. ## Messages Services Australia requires your software to show the user each message exactly as the response supplies it, with nothing truncated, transformed or changed. Services Australia may change the wording at any time, so never parse a message for logic. The messages include: | Response | Show exactly as returned | | ---------------------------------------------------------------------------------------------- | ----------------------------------------- | | A claim | Each error message | | [Same Day Delete](/api-reference/medicare-claiming/interactive-patient-claims/same-day-delete) | `serviceMessage[].reason` | | [Patient Verification](/api-reference/medicare-eligibility/patient-verification) | `Reason` | | [Eligibility Check](/api-reference/medicare-eligibility/eligibility-check) | `Reason`, for the item and for each check | | Every AIR endpoint | `message` and `errors[].message` | ## Claims Send no more than one bulk bill claim per second, and no more than one patient claim per second, as [Availability](/claiming#availability) sets out. Services Australia also requires software that lodges patient claims to: * Check the patient's and the claimant's Medicare details before claiming, with [Patient Verification](/api-reference/medicare-eligibility/patient-verification). * Offer [Same Day Delete](/api-reference/medicare-claiming/interactive-patient-claims/same-day-delete) alongside patient claims. ## Printed statements > **Warning** > > Services Australia advises that legislation requires your software to use the current statements, declarations and privacy notes. When an interactive patient claim is lodged, the location must give the claimant a printed statement. Which statement depends on the claim's outcome: #### Statement of Claim and Benefit Payment The location issues this statement when Medicare assesses the claim in real time and returns a benefit amount. #### Lodgement Advice The location issues this advice once the claim is **pended**: accepted by Medicare and queued for manual assessment by an operator. It must be printed and given to the claimant. Download the templates: * Statement of Claim and Benefit Payment: Download PDF * Lodgement Advice: Download PDF The location may also keep its own copy of each statement, electronic or printed. ### Override indicator requirements When a claim uses one of these override indicators, the printed statement must also show: | Field | Printed form requirement | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | `duplicateServiceOverrideInd` | Indicator value plus text explaining the reason | | `multipleProcedureOverrideInd` | Indicator value plus text explaining the reason. If set to `Y` (Not Multiple), the service `text` giving the reason is required | | `restrictiveOverrideCode` | Indicator value | Any relevant supporting material or text must also appear on the printed statement. ### Other printed forms * **Pathology patient claims.** The combined request form carries the details, the privacy notice and the patient's authority that [Pathology Request Form](/patient-claim-interactive#pathology-request-form) lists. * **DVA claims.** Services Australia requires a treatment service voucher for the services in a DVA claim. [Treatment Service Voucher](/dva#treatment-service-voucher) gives the exception and the endpoint that generates the voucher. ## AIR display requirements Services Australia sets what software using AIR shows its users. Full vaccine and disease names come from the [Reference Data](/air#reference-data) endpoints. | Endpoint | What your software shows | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authorisation | Only the services the response allows, under the labels on the [Authorisation](/api-reference/air/authorisation/authorisation) page. | | Identify Individual | Each indicator that is `true`, as an alert or icon labelled: `catchupDate` "Planned Catch Up", `medContraindicationIndicator` "Medical Contraindication", `naturalImmunityIndicator` "Natural Immunity", `vaccineTrialIndicator` "Vaccine Trial", `actionRequiredIndicator` "Action Required", `additionalVaccineIndicator` "Special Risk Group". | | Immunisation History Details | Each vaccine due, with the disease's full name, the dose and the due date, earliest due date first or filterable. Each encounter, with the date of service, the vaccine's full name, the dose, the status, the reason code and message text where present, the vaccine type and route as descriptions, and the antenatal indicator, most recent first or filterable. With nothing due, "There are no vaccinations due for this individual". With no history, "No immunisation history is recorded for this individual". | | Immunisation History Statement | The PDF, which the user can download, view and print. The PDF is shown unaltered. | | Medical Contraindication History | Each active contraindication with the vaccine's full name, earliest start date first or filterable. With none, "No active medical contraindication is recorded for this individual". | | Natural Immunity History | Each active immunity with the disease's full name, earliest notification date first or filterable. With none, "No active natural immunity is recorded for this individual". | | Vaccine Trial History | Each active trial with the disease's full name, earliest start date first or filterable. With none, "No active vaccine trial is recorded for this individual". | | Add and Remove Additional Vaccine Indicator | The acknowledgement text before the user sets or clears the indicator. After an add, the Additional Vaccines Required alert. After a removal, the alert is cleared. | | Indigenous Status Update | The current Indigenous status after a successful update from `false` to `true`. | | Planned Catch-up Date | The acknowledgement text before the user submits, and the returned `catchupDate` on success. | | Record Encounter | The valid vaccines as a pick list, and options to record past vaccinations and vaccinations given overseas. | | Update Encounter | Only encounters the provider may edit, the valid vaccines as a pick list, and the updated encounter from Immunisation History Details after a successful update. | | Record Medical Contraindication | Pick lists of the valid vaccines, the types (permanent or temporary) and the valid reasons for each type. | | Record Natural Immunity | A pick list of the valid diseases. | | Reference Data | A way for users to see the reference data your software uses. |