Medicare Web Services Integration: PRODA and B2B

The transition that reshaped Medicare claiming

For years, software claimed through Medicare Online using the client adaptor — a locally installed component authenticated by Medicare PKI site certificates. That era is over: Services Australia decommissioned the adaptor channel and moved digital claiming to Medicare Web Services, with authentication through PRODA (Provider Digital Access) instead of Medicare PKI. Legacy certificate-based channels have progressively reached end of support.

The consequence for vendors is bigger than a protocol swap. The adaptor hid queuing, retries and report retrieval inside a black box on the practice's server; with web services, your software owns those behaviours directly. Teams porting adaptor-era products discover the adaptor was doing more work than anyone remembered.

What you can claim through Medicare Web Services

The web services cover the digital claiming channels practices actually use:

• Medicare bulk bill and patient claims — the core interactive and store-and-forward claiming flows, plus the processing and payment reports that reconcile them.
• Online patient verification — checking Medicare enrolment details before claiming, the front-desk workflow that prevents most claim rejections.
• DVA claiming — Department of Veterans' Affairs treatment claims, structurally similar to Medicare claiming with its own rules.
• ECLIPSE — in-hospital and private health insurer interactions (eligibility checks, in-patient medical claims coordinated across Medicare and health funds).
• AIR — the Australian Immunisation Register: recording encounters and querying immunisation history.

The PRODA B2B device model

Authentication is the part that reshapes your architecture. The model: the healthcare organisation holds a PRODA organisation account; within it, a B2B device is registered to represent an installation of your software. Activating the device is a two-step dance — PRODA issues a device activation code with a short validity window (about an hour), your software exchanges it for the device's key, and from then on authenticates by presenting signed JWTs to obtain access tokens for the web services.

Three properties matter operationally. Device keys need periodic refresh, and software that isn't used for a stretch can let the key lapse — re-activation then needs a human with PRODA access. The PRODA organisation belongs to the practice, not to you, so onboarding involves guiding a practice manager through PRODA registration, linking, and device activation. And each software installation site needs its own device registration, which makes 'how many devices, owned by whom' a real design decision for cloud products — work through it with Services Australia's onboarding process rather than assuming the desktop-era pattern.

Provider numbers, locations and payees

Medicare's identity model predates the national identifiers and follows its own logic: the Medicare provider number identifies a practitioner at a location, so one clinician working across three sites bills under three provider numbers. Claims also distinguish the servicing provider (who delivered the care) from the payee provider (whose account is paid) — the mechanics behind common arrangements like registrars and locums billing under a practice's payment arrangements.

Model this properly from the start: provider numbers as location-scoped attributes of a practitioner, payee arrangements as first-class configuration, and validation that stops a claim leaving with a provider number that doesn't match the site. Retro-fitting location-scoped billing into a product that modelled 'one doctor, one number' is a rewrite that has claimed better products than yours.

Registration, development and testing

Integration runs through Services Australia's developer channel — start at the Health Systems Developer Portal. The shape of the process: register as a developer, get access to the specifications and a vendor test environment, build and test against supplied test data, then complete Services Australia's integration testing for each claiming channel you implement before production access is granted for your product. The specifics — forms, environments, current API versions, which channels require what evidence — move on Services Australia's schedule; treat the portal as the source of truth.

Plan channel by channel. Each claiming channel (bulk bill, patient claims, DVA, ECLIPSE, AIR) has its own specifications and test scope; vendors typically sequence them rather than certifying everything at once.

Common failure modes and gotchas

• Adaptor-era assumptions in a web services world. The old adaptor queued claims and fetched reports on its own. With web services, submission retries, idempotency, and report retrieval are your code. The classic bug: a claim submitted twice after a timeout because nobody designed the retry to be safe.
• Reports are a pull, and reconciliation is on you. Processing and payment reports must be retrieved and matched back to submitted claims. Practices live off this reconciliation; a product that submits cleanly but reconciles badly fails where bookkeeping meets the BAS.
• Transmission success ≠ claim success. A 200 from the API means Services Australia received the claim. Assessment happens later, and rejections arrive in reports with reason codes. Surfacing 'sent' as 'paid' is the most common UX lie in claiming software.
• Device key lapse at quiet sites. A part-time clinic that doesn't claim for a few weeks can come back to an expired device key and a workflow needing PRODA credentials nobody remembers. Monitor key age in-product and refresh proactively while the software is running.
• The 60-minute activation window. Device activation codes expire quickly. Onboarding flows that generate the code before the site is actually ready to activate burn the code — and the practice manager's patience. Generate late, activate immediately.
• Who holds the PRODA keys. Staff turnover at practices strands PRODA organisation access with departed employees. It's the practice's account, but you'll wear the support call — documentation that tells a practice how to keep two people linked to the PRODA organisation pays for itself.
• Verification skipped, rejection guaranteed. Products that don't run patient verification before claiming push enrolment errors downstream into claim rejections that cost days instead of seconds. Verify at the desk, claim clean.

Sequencing a Medicare Web Services integration

A sensible order: patient verification first (it's the simplest channel and proves the PRODA plumbing end to end), then bulk bill, then patient claims and the report/reconciliation machinery, then DVA, ECLIPSE and AIR as your market requires. If your product also touches the ADHA stack, the My Health Record integration guide and ADHA conformance checklist cover that parallel workstream — different portal, different credentials, different calendar.