Building a Healthcare App in Australia: The Complete Compliance Landscape

Australia has no single HIPAA equivalent. Healthcare app compliance here is a stack of overlapping regimes, and which ones apply to you depends on what your app claims to do and who buys it.

That is good news, because the burden is proportionate rather than uniform: a wellness tracker and a clinical triage tool face very different obligations. The common failure is not overwhelm but assumption, where teams treat one regime as the whole picture and discover a second during a hospital procurement review. This guide maps the regimes so you know which apply before you write the product brief.

Start here: is your app a medical device?

The biggest fork in the road is whether the Therapeutic Goods Administration considers your software a medical device, because that determines whether you need inclusion in the Australian Register of Therapeutic Goods before you can legally supply it in Australia.

The test is your intended purpose as the manufacturer. Health and lifestyle apps sit outside the framework; software intended to diagnose, predict, prevent, treat, or monitor a disease or condition sits inside it. The TGA has been consistent that this test is technology-agnostic: adding AI does not trigger regulation, and avoiding it does not escape regulation.

One trap is worth naming early: your marketing copy can create your intended purpose. TGA guidance published in March 2026 on advertising software-based medical devices confirms that promotional claims can establish a therapeutic purpose, so a landing page, app store listing, or webinar deck can pull an otherwise unregulated product into scope. If you are unsure which side of the line you sit on, our breakdown of SaMD versus SiMD explains how the distinction changes your regulatory path.

The Privacy Act and the Australian Privacy Principles

Every healthcare app handling Australian patient data is bound by the Privacy Act 1988, regardless of company size.

Health information is sensitive information, which raises the consent bar for collection and use. The small business exemption for organizations under AUD 3 million in turnover does not apply to health service providers, so a two-clinician practice is in scope, as is your app if it delivers a health service. Three obligations shape the build directly:

• Security by design. APP 11 expressly requires reasonable security steps to include technical and organizational measures. Encryption, access control, and audit logging are legal requirements, not engineering preferences.
• Breach readiness. The Notifiable Data Breaches scheme applies, with a 30-day assessment window once you suspect an eligible breach. Your logging has to establish scope inside that window.
• Automated decision-making transparency, from 10 December 2026. New APPs 1.7 to 1.9 bite where a computer program uses personal information to make, or substantially contribute to, a decision that could reasonably be expected to significantly affect an individual’s rights or interests. Clinical triage, risk scoring, and eligibility logic can qualify. Your privacy policy must then disclose the kinds of personal information used and the kinds of decisions made. Systems built earlier are not grandfathered.

A second tranche of Privacy Act reform remains a commitment rather than law. The Attorney-General confirmed in February 2026 Senate estimates that it is progressing, with no timetable announced. Monitor it, but do not architect against it yet.

The state layer most offshore vendors miss

Federal privacy law is not the whole picture. New South Wales, Victoria, and the Australian Capital Territory each have their own health records legislation, and a national product has to satisfy the strictest applicable set.

New South Wales operates the Health Records and Information Privacy Act 2002, built on 15 Health Privacy Principles that bind public and private providers alike, and it adds conditions on disclosing health records outside the state. Victoria has the Health Records Act 2001, whose principles extend across health, mental health, disability, aged care, and palliative care information. Expanding from a Victorian pilot to a national rollout is therefore a compliance scope change, not just a go-to-market decision.

My Health Record: the two rules that shape your architecture

If your app touches My Health Record data, two rules change your build.

The residency rule is absolute. Section 77 of the My Health Records Act 2012 prohibits holding, taking, processing, or handling My Health Record data outside Australia, including copies and backups, and patient consent cannot waive it. If your product connects to My Health Record, your hosting decision is made for you.

The sharing mandate is now live. From 1 July 2026, under the Share by Default rules made in 2025 (the My Health Record (Share by Default) Rules and the Health Insurance (Share by Default) Rules), pathology and diagnostic imaging reports authored by or on behalf of a pathologist or radiologist must be uploaded to My Health Record unless an exception applies. Phase 1 covers written reports, not the underlying images, and an extension process exists. Vendors have conformance work to complete through the Australian Digital Health Agency, and consultation is progressing on medicines information from online prescribers, so this obligation is widening.

The data residency myth, and what it costs you

Section 77 applies to My Health Record data. It does not create a blanket onshore requirement for all Australian health data. Federal law otherwise permits offshore transfer with APP 8 safeguards, subject to any additional state conditions. Over-applying section 77 to an entire platform is common, sometimes encouraged by vendors selling premium onshore-only hosting. Confirm which rule actually binds which dataset before you sign a hosting contract.

Interoperability: AU Core is the benchmark

Building to AU Core is the defensible default for any app exchanging clinical data in Australia.

Australia has localized FHIR rather than adopting it raw. AU Core is the HL7 Australia implementation guide setting minimum expectations on FHIR resources for Australian systems, developed through the CSIRO-convened Sparked accelerator alongside the Australian Core Data for Interoperability. It builds on AU Base, which localizes concepts such as Medicare card numbers. The guide itself notes that conformance may become tied to regulatory or contractual agreements, which is a strong signal for anyone choosing a data model now.

Retrofitting a proprietary data model onto national standards later costs multiples of designing to them from the first sprint. If FHIR is new to your team, start with our guides to HL7 FHIR fundamentals and FHIR R4 in app integration.

If you are in TGA scope: what compliance actually involves

Where your software is a medical device, inclusion in the Australian Register of Therapeutic Goods is a prerequisite for legal supply, and the evidence burden is substantial.

Risk classification drives cost and timeline, so classify early. The recognized standards are IEC 62304 for the software lifecycle and ISO 14971 for risk management, alongside usability, cybersecurity, and post-market monitoring requirements. February 2026 TGA guidance on AI-based software medical devices expects documented model design, training processes, data quality, and clinical validation against the Essential Principles.

Two signals are worth acting on. Under the TGA Compliance Principles 2026-2027, software as a medical device is one of 12 priority focus areas for compliance and enforcement from 1 January 2026 to 31 December 2027, reviewed quarterly. And unique device identification requirements began on 1 July 2026, starting with Class IIb and Class III devices.

Change control deserves particular attention for AI products: regulators will look at how updates are managed, how versions are tracked, and when reassessment is triggered. That is a direct challenge to unmodified continuous deployment.

◆ Ailoitte / Insight

In our medical device software work, the costliest pattern is teams deciding regulatory status after the architecture is set. Run classification during discovery. Retrofitting IEC 62304 traceability and clinical validation into a product built as ordinary software routinely doubles the compliance timeline and forces rework that a two-week scoping exercise would have prevented.

Ailoitte Healthcare Engineering, 2026

Cybersecurity: your customers’ obligations become your contract terms

Even if you are not directly regulated under the Security of Critical Infrastructure Act, your hospital and health service customers are, and their obligations flow into your agreements.

The Act captures the healthcare and medical sector, including critical hospitals with intensive care units. Responsible entities need a board-approved Critical Infrastructure Risk Management Program aligned to a recognized framework such as the Essential Eight or ISO 27001, and must report critical cyber incidents within 12 hours and others within 72 hours. Suppliers inherit those obligations through security questionnaires and contract clauses. For a healthtech vendor, demonstrable Essential Eight maturity alongside ISO 27001 and SOC 2 is now a tender prerequisite, not a differentiator. Treat evidence generation as a product feature.

AI governance: no AI Act in force, and a moving target

Australia has no AI Act in force, and this is the fastest-moving part of the landscape, so treat any guide written before mid-2026 as out of date.

The National AI Plan of 2 December 2025 shelved the proposed economy-wide mandatory guardrails in favor of technology-neutral regulation through existing law, supported by an advisory Australian AI Safety Institute. The National AI Centre’s Guidance for AI Adoption, published October 2025, sets out six essential practices and remains the primary government guidance.

Then the position moved. On 15 July 2026 the Prime Minister announced a national AI framework, establishing an Office of AI within the Department of the Prime Minister and Cabinet and committing to legislate Australian Standards for AI, with legislation expected in Parliament in early 2027. On current reporting those standards center on large data centres, AI training, and Australian copyright material rather than clinical software, so healthcare AI obligations still run through the TGA. Watch the drafting anyway.

Do not read the absence of an AI Act as the absence of exposure. For clinical AI the teeth sit today with the TGA’s intended-purpose test, the Privacy Act’s automated decision-making obligations, and consumer law enforcement against overstated AI claims. The Australian Commission on Safety and Quality in Health Care is also developing guidance on AI safety in clinical settings. In our experience the sequencing that de-risks an AI roadmap is operations first, clinical second: administrative automation earns return without triggering device obligations, and buys the governance maturity a clinical feature will later demand.

What this means for your build sequence

Compliance in Australian health tech is a sequencing problem before it is a documentation problem. In practice:

1. Scope intended purpose and TGA classification before the product brief, then reassess whenever features change.
2. Map privacy obligations across the Privacy Act and every state you will operate in.
3. Decide data residency per dataset, based on what actually binds it.
4. Choose AU Core as your data model from the first sprint.
5. Build audit logging, consent capture, and change control as platform capabilities.
6. Prepare Essential Eight and ISO 27001 evidence before your first enterprise tender.

Where to go next

If you are scoping a specific product, these go deeper on the pieces this guide only introduces:

• Medical software development in Australia for compliance, cost, and delivery model
• Hospital management system development in Australia for enterprise and facility-scale builds
• Custom mHealth app development and healthcare SaaS development for patient-facing products
• EMR and EHR software development and telehealth platforms for clinical systems
• Medical software development in the United States if you are planning a dual-market launch

Ailoitte builds compliant, interoperable healthcare software for the Australian market, with ISO 27001 and ISO 9001 certification and a healthcare engineering practice spanning EMR systems, remote monitoring, and regulated device software. If you need to move faster, you can also extend your team with dedicated healthcare developers.

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