Medicare Batch Claiming Through Tyro Health

Three stages from manual to integrated

Staging the work kept the business claiming the whole time, and each stage paid for itself before the next one started:

• Stage 1: restore claiming. Set up the Tyro Health Online account and enrol each practitioner for Medicare claiming in it. Practitioners already registered with Medicare still need to be set up in Tyro, which takes time, so start it first. Then map the business's data to Tyro's bulk-bill CSV template and run a small controlled batch. After it validates, clear the backlog in staged batches, not one large resubmission.
• Stage 2: one-click export. Build the claim workflow into the existing platform. It finds services ready to claim, validates the data, flags incomplete claims, and generates the Tyro batch file automatically. The only manual step left is uploading the file.
• Stage 3: direct integration. Replace file upload with API submission, track claim status as it changes, and handle declines automatically. Staff then deal only with the exceptions.

The batch file

Tyro's Medicare bulk-bill template is a wide CSV, with around fifty columns in current versions, using dotted column names that mirror its API objects (patient.firstName, healthFundAccount.membershipNumber, medicare.claimItems.itemCode). A referred allied health bulk-bill claim needs only about twenty of them:

• Claim header: invoiceReference, the servicing providerNumber, funder set to medicare, and medicare.claimType set to bulkbill.
• Patient: a stable internal patient.refId, first and last name, and date of birth as YYYY-MM-DD.
• Medicare card: healthFundAccount.healthFundCode set to MDC, the 10-digit card number as membershipNumber, and the IRN as cardRank.
• Referral: the referrer type, the referring provider's number and full name, the referral issue date, and the period and referral type codes.
• Item: the MBS item code, the service date, and the price. For a bulk-billed claim the price is the full Medicare benefit, which changes each financial year, so read it from configuration by service date rather than hard-coding it.

Invoice references are the key to everything

The invoiceReference is the only field that reliably comes back in Tyro's transaction reports, so it's what you'll reconcile on. Make it deterministic: derive it from the patient and the service date (for example a prefix, the date, and a short hash of the patient's internal ID). Then exporting the same visit twice produces the same reference, a resubmitted decline keeps its reference, and a duplicate shows up as a duplicate instead of looking like two separate claims.

Random or sequential references seem harmless until someone downloads a batch, edits it, and uploads it twice. Without a stable reference you can't tell whether two Tyro rows are two claims or the same claim lodged twice.

Lock rows at export time

Once a row is in a downloaded file, assume it will be lodged. Mark it as exported at download time, in the database and in the same transaction as the final eligibility check, so the next export can't include it again. Show the batch as 'CSV in progress' until results come back. Re-check everything at download: a visit that was valid when the batch was built can be billed some other way, have its referral expire, or push the patient over an annual cap before anyone clicks download.

Keep 'uploaded to Tyro' and 'billed' as separate states. An early version of this workflow treated an upload as billing and marked reports complete while some claims were still unassessed. Medicare hadn't paid anything yet. Billing is only complete when the results have been reconciled, and that is a separate step.

Reconciling Tyro's transaction report

Tyro's transaction export contains one row per claim attempt: transaction ID, date, invoice reference, membership number, provider number, amounts charged, benefit paid, amount outstanding, any cancelled or refunded amount, status, and rejection reason. Importing it back is how a claim moves from 'lodged' to 'billed' or 'declined'. The reconciliation guide covers the matching rules in detail. The main ones:

• 'Approved' isn't the same as paid. For a bulk-billed claim, the benefit should equal the charge, with nothing outstanding, cancelled or refunded. Anything else needs review.
• Repeated references. When the same reference appears more than once, a fully paid attempt beats a declined one, and otherwise the newest attempt wins.
• 'Outstanding' usually means processing. A claim Medicare is still assessing shows as outstanding, which can last from a few hours to a few days. Show it as its own state ('with Medicare'), not lumped in with 'CSV in progress' (not yet uploaded) or with failures.
• Cross-check before applying. The Medicare number, IRN, provider and service date on the Tyro row should match the claim you think it is. If they don't, flag the row instead of applying it.
• Make imports idempotent. Record transaction IDs so that re-importing an overlapping report does nothing, and stop a transaction ID from being linked to a different claim later.
• Claims lodged by hand. Staff will sometimes lodge a claim directly in Tyro. Those rows have no reference from your system, so match them on membership number, provider and visit date, and leave weaker name-only matches for a person to confirm.

Adding claiming to an AI-built or no-code app

Many smaller healthcare businesses run on internal platforms built with tools like Lovable, often on Supabase. Claiming can live there, but a few things make it easier:

• Keep claiming in its own module. Use separate tables, routes and permissions. Existing screens like scheduling and visit reports shouldn't change because billing was added.
• Put the rules in the database. Eligibility checks, export locking and reconciliation belong in database functions and constraints, not only in the client. That stops a tab left open overnight from exporting a stale batch.
• Watch latency. These platforms can host the backend far from Australian users. In one build, each request was a round trip to Europe, so combining many small queries into single database calls made a much bigger difference than any front-end change.
• The business owns the code. Work in the business's own repository and accounts, so nothing depends on the developer's environment after handover.

Moving to the API

Once the data is clean and the reconciliation is trusted, the remaining manual steps are uploading the file and importing the results. Tyro Health's partner integration removes both: claims go in over the API, status changes arrive as Medicare assesses them, and declines land straight in an exceptions queue. It needs Tyro's developer and partner onboarding, the business's authorisation, and production acceptance testing, all on Tyro's timeline rather than yours. Start onboarding while you're still improving the CSV workflow, not after.

The data model shouldn't change at this stage. If the claim rows, references, statuses and reconciliation rules already work for CSV, the API replaces only the transport. That's why we built the CSV workflow properly first.

Responsibilities that stay with the practice

Software can enforce the rules, but it doesn't take responsibility for them. Eligibility, correct MBS item selection, provider compliance, and valid assignment of benefit for bulk-billed claims stay with the business and its practitioners. Say so in the scope of any claiming project, and build the workflow so staff can see why a claim is going to Medicare, going to private billing, or being held.