Connecting to Medicare runs on two things: PRODA, which proves who you are, and Web Services, which carry the claims. This guide sets out what a practice has to register, what a software vendor has to build and certify, the rules that decide whether Medicare pays, what has to be maintained once the connection runs, and what all of it costs in time and staff. The last section covers the other route: connecting through an API that already holds the certification.
Every connection to Medicare's digital channels sits on two pieces. PRODA (Provider Digital Access) is the identity layer: it verifies a person and an organisation, and issues the tokens that authorise each call. It is the front door, not the claiming system. Web Services are the channels that carry the work: patient verification, eligibility, and claiming.
This replaced the older adaptor and PKI-certificate channel, which was switched off for online claiming in 2022. Anything still describing PKI site certificates is out of date.
A practice does not build the connection. It connects through software that Services Australia has certified: its practice management system, a claiming service, or an API. Three things belong to the practice itself.
An organisation in PRODA. The responsible person registers an individual PRODA account, then registers the organisation, verified against the Australian Business Register, and links it to the Medicare services it will use.
A provider number and bank details for each location. The HW027, the Online Claiming Provider Agreement, registers a location for online claiming: the practice details, the bank account that receives benefits, and the provider numbers that claim from that location. It is a one-time form for each location, and takes about five business days to process.
A Minor ID for each location. The Minor ID identifies the location to Medicare. It is issued by the software vendor, not by Services Australia, so each product a practice claims through issues its own.
The HW027 and the Minor ID are for claiming. Patient verification and eligibility checks need no location registration.
To transmit real claims, a software product has to be integrated and certified with Services Australia. The path runs through a developer portal:
An individual account for the responsible person, then an organisation account verified against the Australian Business Register, and a B2B device registered for the product. The tokens PRODA issues expire, so the software refreshes and rotates them for as long as it runs.
Register your organisation in the Services Australia developer portal to reach the APIs, the technical specifications and the test material.
Implement the authentication and each channel's endpoints, then test in-house before booking integration testing with Services Australia.
Pass integration testing and Services Australia issues the Notice of Integration. Only then can the product send real claims.
There is no published timeframe for this. Services Australia sets no fixed clock, and in practice the build and certification run to months, not weeks. Once the product holds a Notice of Integration, each practice that claims through it still needs the registration above: its own organisation in PRODA, the HW027 for each location, and a Minor ID the vendor issues.
Medicare is not one switch. Each channel is registered, linked, and certified on its own:
Holding one does not grant the others. Each is its own linking in PRODA, its own integration test, and often its own agreement and conformance. A product certified for Medicare Online that later adds DVA or the AIR goes through integration testing again for that channel.
The connection carries the claim. Whether Medicare pays it depends on rules in the MBS and on records held in Medicare's own systems. Implementing those rules is the largest part of the work.
Rules on the form. Some rules can be checked from the details in front of the person raising the claim:
Rules in the claim history. Many items may only be claimed a set number of times in a period, so whether Medicare will pay depends on when it last paid that item for the same patient. That record is held by Medicare, not by the practice. For most items Services Australia confirms the limit online when an eligibility check is run before the claim. For 167 items, 2.8% of the schedule, it does not verify the limit online for out-of-hospital claims, and the item descriptor is the only rule there is.
The size of it. The MBS runs to around 6,000 items, and the rules that decide payment across them run to several hundred. A vendor writes and maintains its own version of each rule it checks before the claim. For the rules it does not check, the answer arrives after the claim as a 3-digit reason code, which explains how Medicare assessed the claim, or a 4-digit return code, which flags a transaction error. Someone then corrects the claim and resubmits it. The codes and the common causes are in how to reduce Medicare claim rejections.
The connection changes after it is built. Tokens are refreshed and rotated, endpoints are maintained, and the MBS schedule and its rules are tracked and updated as they change through the year.
MBS releases. The MBS is released several times a year, 8 times since November 2024. The 1 July 2026 release alone changed 5,381 schedule fees and 80 descriptions, and each change flows into the rules and the fees the software quotes.
Claiming rules. From 1 July 2026, bulk-billing consent may be given before or after the service, on paper or electronically, with a 12-month transition, and the software that captures consent changed with it.
Specifications. Services Australia publishes revisions to its technical specifications, and keeping the software on the current specification is the vendor's work for as long as it runs.
Locations. Each location a practice adds needs its own HW027 and its own Minor ID, and a vendor serving many practices does this for every one of them.
For the vendor, the build is a project of months with no published end date, and then the maintenance above for as long as the software runs, with a certification to hold for each channel.
For the practice, the cost is staff time, and it depends on when a rule is checked. A rule checked before the claim costs seconds at the desk. A rule checked by Medicare after the claim costs a rejection: it lands weeks after the visit, someone looks up the code, finds the cause, corrects the claim and resubmits it, and the revenue waits. Each rejection adds 6 to 12 days to the revenue cycle. Services Australia names three common causes: the wrong MBS item, a benefit limit the patient has already reached, and a patient or provider who is not eligible. The second depends on the claim history above, so software that does not query Medicare before the claim cannot catch it.
For the patient, a check before the service means the benefit is quoted in dollars before they consent. Without one, a patient told they will be bulk billed, and then billed when the claim is rejected, sees the bill and not the claim error behind it.
Yes. PRODA is the identity layer for every Medicare digital channel. A practice registers an organisation in PRODA and links it to the services it uses. A software vendor also registers a B2B device for its product. Some certified APIs hold the PRODA registration on their own side, so a practice connecting through them has no PRODA setup of its own.
A Minor ID identifies a practice location to Medicare for online claiming. It is issued by the software vendor, not by Services Australia, and it is registered for the location with the HW027 form. Patient verification and eligibility checks need no location registration; the HW027 and the Minor ID are for claiming.
No. Online claiming moved to Web Services, authenticated by PRODA, and the older adaptor and PKI-certificate channel was switched off in 2022.
Services Australia sets no fixed timeframe, and in practice building and certifying a connection runs to months. Each channel is tested on its own, so adding DVA or the AIR later is a further integration test.
No. Each channel is registered, linked and tested on its own: Medicare Online, DVA, the AIR, ECLIPSE and PBS Online. Holding one does not grant the others.
RebateRight holds the Medicare connection so you do not build it. It is Services Australia Certified. Its organisation and B2B device are registered in PRODA, its tokens are cached and refreshed automatically, and the whole path above sits behind a single API key, or behind the web app if your team would rather not integrate at all. There is no PRODA setup for you to do.
It checks 300+ rules on each item across the ~6,000-item MBS before the claim, including the frequency limits Services Australia verifies online, and returns each item as eligible, not eligible or cannot determine, with the reason in plain English. The 167 items Medicare does not verify online are marked indicative and listed in the eligibility check coverage guide. The rules and the fees are updated on each MBS release, and each release is written up on the MBS updates page.
For patient verification and eligibility, add your key and start. For claiming and the AIR, each clinic location needs a RebateRight-issued Minor ID and the one-time HW027, which takes about five business days. After that, you claim.
Your provider numbers, and every clinical and billing decision, stay with you. RebateRight covers Medicare, DVA, the AIR, MBS, and concession checks. In-hospital ECLIPSE claiming is on the roadmap, not offered yet. Every plan includes the connection, the rules, the test environment, support and training. The plans are on the pricing page, and the first 14 days are a free trial with unlimited requests.
Patient verification and eligibility are a single API call away, and every plan includes a test environment to build against.