Medical Software Development in Australia: Compliance, Cost, and the Offshore Model That Actually Works

Building medical software in Australia means treating your product as a regulated medical device from the first sprint, registering it on the ARTG, and meeting Privacy Act obligations for every piece of patient data it touches. The line that decides whether you are inside that regime is intended purpose, not technology or branding. A wellness app that starts “detecting” a condition has just walked into device regulation.

That framing matters more in 2026 than it did even a year ago, because the regulator has shifted from clarifying the rules to enforcing them. This guide covers what Australian compliance actually requires, what a compliant build costs, why so many Australian health teams engineer offshore in India, and how we approach these builds at Ailoitte.

Why medical software in Australia is its own discipline

Medical software is not a consumer app with extra paperwork. A consumer app can ship, break, and be patched next sprint. A regulated device cannot, because every requirement has to trace to a test and every release to an auditable record before it reaches a patient.

The TGA is the gatekeeper. Software as a Medical Device must be included on the ARTG before it is legally supplied in Australia unless it is exempt, and what determines regulatory status is intended use and clinical effect, not the interface or the pitch deck. Digital therapeutics, meaning evidence-based software that prevents, manages, or treats a condition, are regulated. General health and wellness apps that make no medical claim generally sit outside the regime, right up until a feature quietly crosses into diagnosis or treatment.

If you are still working out which side of that line your product sits on, the distinction between standalone medical software and embedded device software changes everything downstream. Our explainer on SaMD vs SiMD walks through the test in plain language, because misclassifying here is one of the most expensive early-stage mistakes a team can make.

The compliance stack you actually have to clear

This is where Australian builds succeed or stall. There are two regimes stacked on top of each other: the device regime under the TGA, and the privacy regime under the Privacy Act.

SaMD classification under the TGA

Australia classifies SaMD using the IMDRF (International Medical Device Regulators Forum) risk framework, harmonised with the EU Medical Device Regulation. The class is set by two things: the seriousness of the condition the software addresses, and the significance of the information it provides. Software that diagnoses a critical condition sits at the top of the scale; software that informs the management of a minor condition sits at the bottom. The software-specific classification rules were introduced through reforms that took effect on 25 February 2021, and higher classes carry a heavier conformity-assessment and clinical-evidence burden.

Underneath classification sits a standards stack that any serious build engineers against from day one: IEC 62304 for the software lifecycle, ISO 14971 for risk management, and ISO 13485 for the quality system. Clinical evidence has to be proportionate to the risk class. Demonstrating that the software works technically is not the same as demonstrating that it is safe and effective for its intended use.

The AI-specific rules, updated in early 2026

In February 2026 the TGA released guidance on when software that is, or uses, AI is regulated as a medical device. The message was deliberately familiar: regulation is triggered by the manufacturer’s intended purpose, not by the presence of AI in the underlying technology. AI-enabled medical devices are handled inside the existing SaMD framework rather than through a separate AI-specific regime. If your product diagnoses, predicts, monitors, or treats, the fact that it does so with a model rather than a rules engine does not exempt it.

Enforcement is no longer theoretical

The TGA has expressly identified SaMD as a priority focus area for its compliance and enforcement activities in 2026 and 2027, with a more proactive posture and regular reviews. Separately, from 21 March 2026, public, private, and day hospitals must report device-related injuries to the TGA, a requirement being phased in through 2030. The direction of travel is clear: more scrutiny, more reporting, and real consequences for teams that get it wrong.

The Privacy Act layer

Patient data brings a second regime. The Privacy Act 1988 governs personal information through 13 Australian Privacy Principles (APPs). The teeth are serious: penalties for serious or repeated breaches can reach AUD 50 million, three times the benefit obtained, or 30 percent of adjusted turnover. This is not hypothetical either. Australian Clinical Labs paid AUD 5.8 million in October 2025 in the first civil penalty issued under the Act. A statutory tort for serious invasions of privacy has also been in force since June 2025, which means an aggrieved individual can act even before the regulator does.

For teams building medical device software in Australia, the practical takeaway is that compliance is the product, not a phase. It shapes architecture, evidence, and roadmap from the first design decision.

What medical software development costs in Australia

A compliant SaMD build costs more than a standard app, because classification, clinical evidence, quality-system setup, cybersecurity, and post-market surveillance are line items rather than afterthoughts. The main cost drivers are risk class, the number and complexity of device or system integrations, the clinical evidence burden, and delivery scope, whether that is a proof of concept, an MVP, or a full product.

Two Australia-specific realities push the number around. First, domestic senior engineering rates are among the highest in the Asia-Pacific region, so a fully in-house Australian build carries a heavy labour cost. Second, and more importantly, the largest cost risk is not the day rate at all. It is rework. A build that reaches conformity assessment with gaps in its risk file, its traceability, or its evidence trail can lose months and force a re-scope, and that is precisely the failure mode the TGA’s enforcement priority makes more expensive to court.

The right way to reason about budget is total cost of ownership across the device lifecycle, not sticker price per hour. For a detailed breakdown of where the money actually goes across risk classes and pathways, see our guide to medical device software development cost.

Why Australian health teams outsource to India, and the one rule you cannot break

Outsourcing a regulated build to India gives Australian health teams three things: access to a deep pool of engineers experienced in regulated healthcare software, a meaningful cost differential against domestic rates, and the ability to staff a compliant program quickly rather than spending a year hiring for it.

Then there is the catch that too few vendors mention. Under APP 8 of the Privacy Act, and reinforced by recent reforms, an Australian organisation that discloses personal information to an overseas recipient remains accountable for how that information is handled abroad. The Office of the Australian Information Commissioner is explicit that the disclosing entity stays responsible if the overseas recipient mishandles the data. In plain terms, liability follows the data, not the contract. A neat set of contractual clauses does not transfer the accountability away from you.

Two further points sharpen this. APP 11 now expressly requires that “reasonable steps” to protect personal information include both technical and organisational measures, so generic assurances that a vendor “takes security seriously” no longer satisfy the standard. And while the reforms created a mechanism to prescribe trusted jurisdictions whose laws are treated as substantially similar to the APPs, no countries have been prescribed as of mid-2026. India is not on a whitelist, which means full APP 8 accountability applies to any disclosure of Australian patient data to an Indian development partner.

None of this makes offshore delivery a bad idea. It makes vendor governance the deciding factor. Outsourcing to India is entirely viable, but only with a partner whose certifications, data-handling practices, contractual APP-equivalent commitments, and data-residency options actually carry the accountability you cannot offload. The vendor’s discipline becomes your compliance evidence.

The role of AI: in the product and in the build

It helps to separate two very different meanings of “AI in medical software,” because they carry different obligations.

AI inside the product is regulated SaMD. If a model diagnoses, predicts, or drives clinical management, it is a device, and the hard problem is that a model designed to improve after release collides with a regulatory model built for fixed devices. This is why change-control planning, and for adaptive systems a predetermined change control approach, has to be designed in from the first sprint rather than retrofitted before launch. If you are deciding what belongs in a first regulated release and what should wait, our guide to building an AI medical device software MVP covers what to ship first and what to skip.

AI inside the build process is a different thing entirely. This is where we use AI-native engineering and agentic QA to accelerate delivery and testing without touching the product’s regulatory status. Keeping that line clean, using AI to build faster while the device itself stays under proper design control and human oversight, is what lets a regulated program move quickly without loosening the controls it depends on.

Compliance is built in, not bolted on. We engineer to an IEC 62304 lifecycle with an ISO 14971 risk file maintained continuously, and we support your ISO 13485 quality system with the documentation it needs. On the organisational-measures side that APP 11 now demands, we operate under ISO 27001, ISO 9001, and SOC 2 Type II certifications with HIPAA-ready practices, meaning encryption, anonymisation, access controls, and audit logging by default rather than before an audit.

Delivery runs through our AI Velocity Pods, a fixed-price, outcome-based model that suits regulated work well: predictable cost against a compliance-gated scope, with senior architects rather than a rented seat count. Our Agentic QA Pipeline produces continuous verification evidence, which is exactly the kind of traceable, requirement-to-test record a submission and a post-market file rely on. Behind all of it are proof points that matter in regulated healthcare: 300+ products delivered across 21 countries, 50M+ downloads, and named work such as the AssureCare connected-care platform serving tens of millions of members.

Discover how Ailoitte AI keeps you ahead of risk

Let's Talk

Sunil Kumar

Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 5× faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering. Connect on LinkedIn