Healthcare Compliance in Australia: IT and AI Rules for Digital Health Products in 2026

Key Takeaways

1. Plan for several regulators at once: Healthcare compliance in Australia now spans privacy, cyber, medical device and AI rules together. As a result, one health app can answer to several regulators before launch.
2. Being small won’t exempt your health app: Holding a single piece of health information brings a business under the Privacy Act, whatever its turnover. So the small business exemption rarely helps health startups.
3. Your next hard deadline is 10 December 2026: From that date, privacy policies must disclose automated decisions that significantly affect people. The rule covers simple if-then logic as well as AI.
4. What your product claims decides the TGA rules: The TGA judges software by its intended purpose. That means the same AI model can be unregulated in one product and need registration in another.
5. Breach risk is already costing health businesses: Health providers lodged more data breach notifications than any other sector in 2025. Meanwhile, Australia’s first Privacy Act civil penalty, $5.8 million, followed a pathology breach.
6. AI rules apply today, even without an AI law: Australia has no standalone AI act since the government shelved mandatory guardrails. Even so, privacy, TGA and practitioner rules already shape every AI feature in healthcare in Australia.

If your team builds or buys software for Australian healthcare, you now answer to several regulators at once. Healthcare compliance in Australia covers how you store patient data and how you respond to a breach. It also decides whether your app counts as a medical device and how clinicians can use your AI features. For anyone working on healthcare software development, these rules shape product decisions long before launch.

The timing makes this more urgent. A new privacy rule on automated decisions starts on 10 December 2026. On top of that, the government plans to introduce a bigger wave of privacy reform before the year ends. Meanwhile, health providers lodged 225 of the 1,205 breach notifications the Office of the Australian Information Commissioner (OAIC) received in 2025, the most of any sector.

This guide maps each rule to the product features it affects, so you can plan for them early. First, you will see which rules your product triggers and what changed in 2026. After that, we explain how Australia regulates AI in healthcare. Finally, you get a 12-point checklist to use before you build or buy.

What Does Healthcare Compliance in Australia Actually Cover?Copy link to "What Does Healthcare Compliance in Australia Actually Cover?"

Compliance in Australian healthcare reaches well past privacy, so it helps to see the whole map first.

The Full Healthcare Compliance Map

Australia splits healthcare oversight across several bodies. Some reach your software directly, while others shape it through the clinicians and providers who use it.

Regulators that reach your software directly

Their rules apply straight to your code, data handling and product claims.

• Office of the Australian Information Commissioner (OAIC): Privacy and data breach rules for patient data
• Australian Signals Directorate’s Australian Cyber Security Centre (ACSC): Ransomware payment reports
• Cyber and Infrastructure Security Centre (CISC): Critical infrastructure duties for hospitals and large providers
• Therapeutic Goods Administration (TGA): Medical device rules, especially for AI features
• Australian Digital Health Agency (ADHA): My Health Record and national integration conformance

Regulators that reach it indirectly

Your product does not answer to them, yet your users do, and that changes your features.

Australian Health Practitioner Regulation Agency (AHPRA) and the National Boards: How clinicians use your AI tools
Australian Commission on Safety and Quality in Health Care (ACSQHC): Clinical safety standards
Medicare rules: The claims data your software creates
National Disability Insurance Scheme (NDIS) and Aged Care Commissions: The records and incidents they audit

The indirect group still counts. For example, Medicare rules look like a billing issue until your platform creates the claim.

Where Healthcare IT Compliance Fits

Healthcare IT compliance is the part of this map that lives inside your technology. It covers how your software collects, stores, shares and protects patient information, plus how your AI features behave.

In practice, that means the five direct regulators above. These rules decide your hosting region, access controls, audit logs and breach response plan. They also decide whether your AI tool needs an Australian Register of Therapeutic Goods (ARTG) listing before you can supply it in Australia.

Because of that, the rest of this guide stays on the software and AI layer. We still flag the indirect rules wherever they change a product decision.

With the full map in view, the next step is finding which of these rules your own product triggers.

Which Compliance Rules Will Your Health Product Trigger?Copy link to "Which Compliance Rules Will Your Health Product Trigger?"

Your obligations depend on what your product does, so start by finding your product type below.

Product type	Rules it triggers	TGA risk	Related build guide
Wellness and fitness app	Privacy Act and Australian Privacy Principles (APPs) once it records health information, Notifiable Data Breaches (NDB) scheme	Low. General wellness tools usually sit outside TGA rules	None
Patient portal or booking platform	Privacy Act, NDB scheme, APP 8 for offshore hosting, Healthcare Identifiers (HI) Service conformance if you use healthcare identifiers	Low	Patient management software
Telehealth platform	Privacy Act, NDB scheme, AHPRA practitioner obligations, Medicare rules for claimable consults	Low, unless you add diagnostic features	Telemedicine app development
Clinic CRM	Privacy Act, APP 7 consent rules for marketing with health data, Spam Act 2003 for email and SMS	Low	Healthcare CRM software
AI scribe	Privacy Act, consent to record, Automated decision-making (ADM) disclosure, AHPRA guidance	Medium. Scribes that suggest diagnoses or treatments can count as medical devices	None
Clinical decision support or diagnostic AI	TGA, Privacy Act, ADM disclosure	High	None
Mental health app	Privacy Act, NDB scheme	Currently excluded, but the TGA wants this reviewed	None
NDIS or aged care platform	Privacy Act, NDB scheme, NDIS Commission or Aged Care Commission record and incident rules	Low	Home care software
Pharmacy or ePrescribing system	Privacy Act, ADHA ePrescribing conformance	Low	Pharmacy management software

The CRM row surprises many teams. Under APP 7, you need consent before using health details in marketing campaigns. So if you plan custom CRM development for a clinic, consent tracking belongs in the first release.

Is My Health App a Medical Device?

The TGA judges software by its intended purpose, not by the technology inside it. Work through these four steps to find out where your product sits.

1. Write down your intended purpose

Include what your website, app store listing and sales pitch claim the product does.

2. Check for a medical purpose

Look for diagnosis, prevention, monitoring, prediction, prognosis or treatment of a disease, injury or disability. If none apply, your app is likely not a medical device.

3. Check the exclusions

General wellness and purely administrative tools usually fall outside TGA rules. Digital mental health tools sit here too, at least for now.

4. Plan for ARTG inclusion

If your app has a medical purpose and no exclusion applies, it needs ARTG inclusion before you supply it in Australia.

Feature creep is the usual trigger. For example, a scheduling app can become a medical device the day it starts flagging which patients look high risk.

The Small Business Exemption Trap

Most Australian businesses under $3 million turnover sit outside the Privacy Act. Health businesses work differently, though. Any organisation that provides a health service and holds health information is covered, whatever its turnover.

The definition of a health service is also broad. If your app assesses, maintains or improves someone’s health, or records their health information, it most likely qualifies. As a result, a two-person startup with a symptom tracker carries the same core privacy duties as a hospital group.

The current Tranche 2 draft does not touch the small business exemption. Even so, health businesses never relied on it, so nothing changes for them here.

Knowing your product type tells you which rules apply, and the next question is which of those rules changed recently.

Which Australian Healthcare Rules Changed in 2026, and Which Are Still Coming?Copy link to "Which Australian Healthcare Rules Changed in 2026, and Which Are Still Coming?"

Several rules shifted over the last 18 months, and their status decides what your team should build first.

Some of these changes already carry penalties, while others are still drafts. The table below lists each one in date order, so you can see exactly where things stand.

Rule or milestone	Status	Key date	What it means for your product
Tiered privacy penalties and stronger OAIC powers	In force	11 Dec 2024	Smaller privacy failures can now attract fines, not just serious ones
Ransomware payment reporting	In force	30 May 2025	Report any ransom payment within 72 hours if turnover tops $3 million or you run critical infrastructure
Statutory tort for serious invasions of privacy	In force	10 Jun 2025	Patients can sue directly over serious privacy invasions
First Privacy Act civil penalty	Enforcement milestone	9 Oct 2025	First civil penalty ordered over a pathology data breach
National AI Centre (NAIC) Guidance for AI Adoption	Voluntary guidance	21 Oct 2025	A practical AI governance baseline that replaced the earlier voluntary standard
Mandatory AI guardrails	Shelved	2 Dec 2025	No standalone AI act. Existing privacy, TGA and consumer laws cover AI instead
TGA AI scribe clarification	Current guidance	30 Jan 2026	Check whether your scribe crosses into medical device territory
TGA AI and medical device software guidance	Current guidance	5 Feb 2026	Intended purpose decides whether you need ARTG inclusion
Tranche 2 privacy reform draft	Proposed	31 Aug 2026	A fair and reasonable test, 72-hour breach notice, a right to sue, and privacy impact assessments
Automated decision-making disclosure	Commencing	10 Dec 2026	Privacy policies must explain significant automated decisions
Children’s Online Privacy Code	Due for registration	By 10 Dec 2026	Relevant for paediatric, family and youth health apps
Digital mental health tool regulation	Under review	No date yet	These tools may move into TGA scope

What Should You Prioritise First?

You can sort this timeline into three groups to decide what needs action first.

1. Live risk today

The breach rules, ransomware reporting and the privacy tort already apply. If your product holds patient data, your incident response plan should cover all three right now.

2. The next hard deadline

The automated decision rule starts on 10 December 2026. So any product that scores, triages or approves people needs its disclosures ready before then.

3. Design signals

Tranche 2 is still a draft. However, its fair and reasonable test would also cover data you already hold, including data collected before the law passes. In other words, the data you collect today may face tomorrow’s standard.

With the timeline clear, the next step is the privacy layer, because every health product shares it.

How the Privacy Act Shapes the Way You Build Healthcare SoftwareCopy link to "How the Privacy Act Shapes the Way You Build Healthcare Software"

Every health product that touches patient details sits on top of the Privacy Act, so its rules shape your architecture from day one.

Most privacy problems in health software start as data model decisions. Once patient records spread across tables, logs and third-party tools, fixing them later gets slow and expensive. That is why it pays to map these rules to features before your first sprint.

Why Health Information Gets Stricter Treatment

The Australian Privacy Principles treat health information as sensitive information. As a result, you usually need consent to collect it, and you should only collect what your product genuinely needs.

Secondary use is where many teams slip. For example, patient engagement platforms often reuse booking data for reminders, surveys or marketing. Reminders tied to care usually fit the original purpose. Marketing campaigns, however, typically need fresh consent.

In practice, this means three build decisions:

• Consent records with timestamps. Store what each patient agreed to, when they agreed and which version of your notice they saw.
• Minimal form fields. Every extra field adds risk without adding value, so cut anything your workflow does not use.
• Purpose tags on data. Label records by the purpose you collected them for, so later features cannot quietly reuse them.

APP 8: Where Your Patient Data Travels

APP 8 covers personal information that leaves Australia. If an overseas party mishandles data you sent them, your business generally stays accountable under the Privacy Act.

This affects more than hosting. Overseas cloud regions, offshore support desks and global AI APIs can all move patient data across borders. Many AI tools, for instance, process prompts on servers outside Australia by default.

Offshore development and onshore data can still work together. A common pattern looks like this:

• Production data stays onshore. Keep it in an Australian cloud region, with every access logged.
• Developers use safe test data. They build and test against synthetic or de-identified records instead of real patient data.
• A subprocessor register stays current. It lists every vendor that can reach patient data and where each one operates.

My Health Record data has stricter location rules, which the integration section below covers.

APP 11: Turning Security Duties Into Product Features

APP 11 asks you to protect personal information and to destroy or de-identify it once you no longer need it. Here is how that rule, and the principles around it, turn into features:

• Encryption at rest and in transit, so stolen data stays unreadable
• Role-based access and MFA, so each user only sees what their role needs
• Audit logs that show who opened which record and when
• Scheduled retention and deletion, so old records get destroyed or de-identified on time
• A privacy policy and collection notices at signup, to meet APP 1 and APP 5
• Self-service export and correction requests, so patients can use their APP 12 and 13 rights

APP 11 is no paper exercise either. Australia’s first Privacy Act civil penalty centred on it, as the breach section below explains.

State and Territory Health Records Laws

Federal law is only part of the picture. Victoria, New South Wales and the ACT each have their own health records laws, and the Victorian and NSW laws reach private sector health providers too.

These laws add specific duties, especially around record retention. For instance, Victoria and NSW generally require health providers to keep adult records for at least seven years. They also require records about minors to be kept until the patient turns 25.

This creates a design tension. Your deletion features must respect APP 11, yet they cannot erase records that state law requires you to keep. So build retention rules per record type and per state, instead of a single delete button.

These privacy rules already apply today, and two upcoming reforms will raise the bar again.

What the December 2026 Privacy Deadline Means for Your Health AppCopy link to "What the December 2026 Privacy Deadline Means for Your Health App"

Australia’s first wave of privacy reform is still rolling out, and the second wave already exists in draft form.

The first change has a fixed date. From 10 December 2026, your privacy policy must explain how your product uses automated decisions. Meanwhile, the Tranche 2 privacy reform draft points to stricter rules for the data you collect today.

The Automated Decision Rule (APP 1.7 to 1.9)

The new rule adds three disclosure duties to APP 1. Your privacy policy must describe the personal information your automated systems use and the kinds of decisions they make.

The rule casts a wide net. It covers AI models, but it also covers rule-based tools and automated assessments. So even a simple if-then rule in your workflow can count.

The test is whether a decision could reasonably be expected to significantly affect someone’s rights or interests. In healthcare, that bar is easy to reach.

Decisions Made Solely by Automation

These are decisions your system makes with no person involved. Common health examples include:

• A triage chatbot that routes patients to urgent or routine care.
• A booking system that blocks appointments for patients flagged as likely no-shows.
• A referral portal that automatically rejects incomplete forms.

Decisions Where Automation Plays a Substantial Role

Here, a person makes the final call, but your software does most of the work. For example, a risk score might rank which patients a nurse calls first. Similarly, an NDIS software might pre-assess funding requests before a coordinator signs off.

Both types need disclosure. The features that make disclosure possible are straightforward:

• A decision register. List each automated decision, the data it uses, its logic type, and where a human steps in.
• Plain-language policy text. Describe each kind of decision in words a patient can follow.
• Decision logs. Record what the system decided, when, and on what inputs.
• A human review path. Give patients a way to ask a person to check a decision.

The hardest step is usually finding the decisions in the first place. Rule-based logic often hides inside old workflows, so start with a full feature audit.

What Tranche 2 Privacy Reform Proposes

The government released the Tranche 2 exposure draft on 31 August 2026 and plans to introduce the bill before the year ends. If it passes in its current form, five changes would reach health software teams:

• A fair and reasonable test: Every collection, use and disclosure must pass a seven-factor fairness check, even with patient consent.
• 72-hour breach notification: The draft would require notice to the OAIC within 72 hours of having reasonable grounds to believe a breach occurred.
• A direct right to sue: Patients could take action over Privacy Act breaches without waiting for the OAIC.
• Privacy impact assessments: High-risk features would need one before launch.
• A controller and processor split: SaaS vendors may carry different duties from the clinics they serve.

The seven factors are reasonable expectations, genuine choice, the link to your business functions, data minimisation, impact on the person, proportionality and the best interests of any children involved.

Design Choices That Hold Up Under Tranche 2

The draft is still a proposal, yet its direction is already clear. More importantly, its fairness test would also apply to data you already hold. That makes these choices worth building now:

• Collect less from the start

Data minimisation is one of the seven factors, so lean data models lower your future risk.

• Separate consent for sensitive data

Keep health data consent apart from general terms, so you can prove it later.

• Rehearse a 72-hour breach response

Map who assesses, who decides and who notifies, then test the plan.

• Add a privacy impact step to feature planning

A short template for every high-risk feature saves rework later.

• Review vendor contracts

Define who acts as controller and who acts as processor before the law defines it for you.

Privacy law sets the rules for handling data, while breach and cyber law decides what happens when something goes wrong.

Why Healthcare Leads Australia’s Data Breach Numbers, and How to Stay Out of ThemCopy link to "Why Healthcare Leads Australia’s Data Breach Numbers, and How to Stay Out of Them"

Health tops the national breach tables year after year, which turns cyber security into a compliance task as much as an IT task.

The OAIC received a record 1,205 breach notifications in 2025, up 8% on the year before. Malicious or criminal attacks caused 716 of them. At the same time, public trust is wearing thin, with 82% of Australians now worried about data breaches.

How the Notifiable Data Breaches Scheme Works for Health Providers

The NDB scheme applies when a breach is likely to cause serious harm. Health information almost always meets that bar, so most health data breaches become notifiable.

Once you suspect a breach, you have two duties:

1. Assess quickly. Work out whether the breach is likely to cause serious harm, and finish the assessment within 30 days.
2. Notify promptly. If it qualifies, tell the OAIC and affected individuals as soon as practicable.

Today, the NDB scheme sets no fixed 72-hour deadline. Tranche 2 would add one, while the 72-hour ransomware rule below already applies. Third parties make this harder. When a vendor suffers the breach, both parties can carry duties. Generally, the business with the most direct relationship to affected patients should notify them. So your contracts should spell out who assesses, who informs and who notifies.

The 72-Hour Ransomware Reporting Rule in Australia

Since 30 May 2025, the Cyber Security Act 2024 has required businesses to report ransomware payments. If you pay a ransom, or someone pays on your behalf, you must report it within 72 hours.

The rule covers businesses with annual turnover above $3 million. It also covers critical infrastructure operators, whatever their size. This $3 million line belongs to the Cyber Security Act and works separately from the Privacy Act threshold. Health businesses fall under the Privacy Act at any turnover, as covered earlier. Your report must include incident details, the demand, the payment and any contact with the attackers.

This report sits alongside the NDB scheme. A single ransomware attack can therefore trigger two separate reports, each with its own timeline and audience.

When Healthcare Counts as Critical Infrastructure

The SOCI Act treats some hospitals as critical infrastructure assets. In general, that applies to hospitals with a general intensive care unit.

Covered hospitals carry extra duties, including mandatory cyber incident reporting and a formal risk management program. Software vendors feel this too. If you sell to a critical hospital, expect its security duties to flow into your contract, especially around data storage and incident response.

Essential Eight as a Practical Healthcare Baseline

The ASD’s Essential Eight is a set of eight controls for reducing cyber risk. It is voluntary for private health businesses, but insurers and enterprise buyers increasingly ask about it.

For a healthcare software product, the most relevant controls are:

• Multi-factor authentication for clinicians, admins and support staff.
• Regular patching of applications and operating systems on a set schedule.
• Restricted admin privileges so a single compromised account cannot reach everything.
• Tested backups that you can actually restore under pressure.

Older platforms often struggle with these controls. In those cases, legacy app modernization can close the gap without disrupting daily clinical work.

What Non-Compliance Costs: Lessons From the Australian Clinical Labs Penalty

The consequences of non-compliance in healthcare in Australia became very real in October 2025. That month, the Federal Court ordered Australian Clinical Labs to pay the first civil penalties under the Privacy Act.

The total reached $5.8 million. Most of it, $4.2 million, came from failing to take reasonable steps to protect personal information under APP 11.1. The remaining $1.6 million covered a slow breach assessment and a late statement to the OAIC.

The most useful lesson for software buyers sits in the background. The court found ACL failed to spot serious IT weaknesses at Medlab before acquiring the business, then moved slowly to fix them. In other words, inherited systems became inherited liability.

That pattern applies well beyond acquisitions. Ageing healthcare systems and unvetted vendors carry the same hidden risk. Privacy and cyber rules protect patient data, and AI adds a newer layer of obligations on top.

AI in Healthcare Australia: What Your AI Feature Needs Before LaunchCopy link to "AI in Healthcare Australia: What Your AI Feature Needs Before Launch"

AI in healthcare in Australia runs on existing laws applied to new technology, since the country has no standalone AI act.

That means three layers apply at once. Privacy law covers the data your AI uses. The TGA covers what your AI product claims to do. Meanwhile, AHPRA and the ACSQHC shape how clinicians may use it.

1. The TGA Intended-Purpose Test for AI Software

The four-step test from earlier applies to AI as well, since the TGA looks at intended purpose regardless of the model or platform. So AI with a medical purpose needs ARTG inclusion before supply. That usually includes clinical decision support tools that recommend treatment. It also covers screening tools for conditions like diabetic retinopathy and radiology tools that flag pneumothorax, pneumonia or tumours.

On the other side sit administrative tools. Scheduling, billing, rostering and general wellness tracking usually fall outside TGA rules, because they have no medical purpose.

Likely in scope	Likely out of scope
Clinical decision support that uses generative AI to recommend treatment	Appointment scheduling and reminders
Screening tools for conditions like diabetic retinopathy	Billing and claims admin
Radiology tools that flag pneumothorax, pneumonia or tumours	Staff rostering
Risk prediction that guides clinical decisions	General wellness and fitness tracking

Roles matter here too. If your company both designs and supplies the AI product, the TGA may treat you as the manufacturer and the sponsor. You then carry the duties of both.

Updates add another layer. AI products change often through agile releases, and each change can shift performance. The February 2026 guidance explains how existing rules apply to those updates and what evidence you need. On a positive note, it also confirms that synthetic data can support training and validation, as long as you document how you created it.

2. AI Scribes After the January 2026 TGA Clarification

AI scribes spread quickly through Australian clinics, often without anyone checking their regulatory status. On 30 January 2026, the TGA clarified which scribing tools count as medical devices.

The line comes down to features. A scribe that only transcribes and summarises usually stays outside TGA rules. However, once it starts suggesting diagnoses or treatments, it can cross into medical device territory. In that case, it needs ARTG inclusion before anyone can advertise or supply it. The TGA has since stepped up its stance. At the HIC2026 conference in Sydney in August 2026, it confirmed its scribe review had moved into compliance action. That action targets suppliers whose scribes work as medical devices without TGA approval.

For product teams, this makes scope control a compliance decision. Before adding a clinical suggestion feature, check whether it changes your intended purpose. Our breakdown of the benefits of AI medical scribes covers where these tools add value without crossing that line. You can also see how we approached data handling and clinician review in our AI clinical documentation platform case study.

3. AHPRA and ACSQHC Expectations, Built Into Your Product

AHPRA’s AI guidance applies to registered practitioners, not software vendors. Even so, clinicians can only meet those duties if your product supports them. Similarly, the ACSQHC’s AI Clinical Use Guide splits safe use into before, during and after stages.

Practitioner obligation	Feature your product needs
Apply human judgment to any AI output	A review and approve step before AI output enters the patient record
Tell patients when AI is in use	AI-use disclosure in patient notices and consent screens
Get informed consent before patient data goes into an AI tool	Consent capture before any patient data enters the AI tool
Get consent before recording a consultation	Recording that only starts after consent is logged, plus a visible recording indicator
Stay accountable after use	Output logs, model version tracking and a full audit trail

TGA approval does not remove these duties either. Practitioners must still apply oversight to any AI tool, approved or not. As a result, review and consent features belong in every clinical AI product.

4. Patient Data Inside LLMs

Large language models create a specific privacy risk. Many AI providers process prompts on servers outside Australia, which brings APP 8 into play.

Training is the bigger issue. If patient transcripts help improve a global AI model, that counts as a secondary use. In Australia, the safe default is simple: no consent, no training.

You have three practical options:

• Use enterprise AI terms that block training on your data and specify processing locations.
• Choose Australian processing regions where your AI provider offers them.
• Run models privately or locally so patient data never leaves your controlled environment.

The third option suits the most sensitive workloads. For NDA work, SolGuruz runs local Ollama setups, so zero client data goes to cloud AI. If you want to explore this path, see our private LLM development service or our guide to running LLMs locally.

5. Mandatory AI Guardrails Were Shelved. Here Is What Applies Instead.

In 2024, the government proposed mandatory guardrails for high-risk AI. Then, in December 2025, the National AI Plan dropped them in favour of updating existing laws.

So the current picture looks like this:

• Existing laws apply in full. Privacy, TGA, consumer and anti-discrimination laws all cover AI.
• A new AI Safety Institute will monitor risks and support regulators, backed by $29.9 million.
• Voluntary guidance fills the gaps. The NAIC’s Guidance for AI Adoption replaced the earlier voluntary safety standard in October 2025.

Your AI compliance therefore runs through the laws covered earlier in this guide, including the December 2026 automated decision rule.

The Watch List: What Could Change Next

Two TGA review areas could affect AI health products soon. First, digital mental health tools sit outside the medical device definition today, but the TGA has recommended an urgent review. Second, the TGA may widen its definition of supply to include digital access to software.

If you build in either space, design as if TGA scope already applies, with evidence and controls in place from your first release.

Beyond regulation, many Australian health products also need national system integrations.

What It Takes to Integrate With My Health Record and National SystemsCopy link to "What It Takes to Integrate With My Health Record and National Systems"

National integrations help your product win over Australian clinics, and each one comes with its own conformance steps.

Clinics increasingly expect health software to connect with national systems. Those connections also act as a quality signal, because buyers can check which products passed conformance. So for many teams, integration becomes a sales requirement as much as a technical one.

My Health Record Integration: What Your Team Needs to Plan

My Health Record integration involves four connected steps, and each one depends on the step before it:

1. Connect to the HI Service

My Health Record relies on patient and provider identifiers, so this comes first.

2. Secure your connections

Use the national digital certificates issued to health organisations.

3. Choose your gateway

Clinical software typically uses the business-to-business gateway, while consumer apps follow a separate app pathway.

4. Test and declare conformance

Run your product through the test environment, then declare conformance for the version you release.

Two design rules apply throughout. First, My Health Record data must stay in Australia, so your hosting choices need to reflect that. Second, patients can control who sees their record. As a result, your product must respect those settings and log every access.

The Digital Health Implementer Hub publishes the toolkits and specifications your developers will need. In practice, reading them early saves rework, since they shape your data model and access controls.

Healthcare Identifiers Service Conformance

Australia uses three healthcare identifiers. Patients have an Individual Healthcare Identifier (IHI), individual providers have a Healthcare Provider Identifier for individuals (HPI-I), and organisations have a Healthcare Provider Identifier for organisations (HPI-O).

If your software uses these identifiers, it must meet a set of national conformance requirements. Your developers then complete an Implementation Conformance Statement. That document declares which requirements your implementation satisfies.

Identifier errors carry real patient safety risk. For example, a mismatched IHI could attach one patient’s results to another patient’s record. Because of that, build strong validation, clear error handling and a manual review path for failed matches.

ADHA Conformance Registers and Why Buyers Check Them

The Australian Digital Health Agency publishes several conformance registers that list software products meeting national requirements. Buyers and regulators both use them.

Three registers matter most for health software teams:

• The register of conformity

It lists products and versions assessed against national digital health requirements, such as viewing My Health Record or uploading prescriptions.

• The Electronic Prescribing Conformance Register

Providers use it to choose ePrescribing software that conforms to legislation. This matters if you build pharmacy management software or any prescribing feature.

• The Practice Incentives Program (PIP) eHealth Incentive register

It lists products that meet the requirements of a government incentive for general practices.

The last register has direct commercial weight. If a practice relies on that incentive, a product without a listing becomes a much harder sell.

Conformance also attaches to specific product versions. So when you ship a major release, plan time to review and update your declarations. Treat conformance as a recurring roadmap item instead of a one-off launch task.

With the rules and integrations mapped, the next step is turning everything into a practical checklist.\

Healthcare Compliance Checklist: 12 Questions to Answer Before You Build or BuyCopy link to "Healthcare Compliance Checklist: 12 Questions to Answer Before You Build or Buy"

These 12 questions turn every rule in this guide into decisions you can check off before development starts.

Use them in two ways. If you are building a product, answer each question during discovery. If you are buying one, ask the vendor for the evidence listed under each question.

Data and access

1. Where will patient data live, and who can reach it from overseas? Ask for the hosting region and a subprocessor register with locations. (APP 8, My Health Records Act)
2. Who can access patient records, and how is that access limited? Ask for a role-based access matrix and admin privilege policy. (APP 11)
3. Is data encrypted at rest and in transit? Ask for documented encryption standards and the key management approach. (APP 11)
4. Does the system log every access and change? Ask for a sample audit log and the log retention period. (APP 11, My Health Record rules)

Consent and decisions

1. How does the product capture and store consent? Ask for sample consent records with timestamps and notice versions. (APP 3, APP 6, AHPRA AI guidance)
2. Which automated decisions does it make, and are they disclosed? Ask for a decision register and draft privacy policy text. (APP 1.7 to 1.9, from 10 December 2026)

Incidents

1. What happens in the first 72 hours after a breach? Ask for the incident response plan and its last test date. (NDB scheme, proposed Tranche 2)
2. Is someone ready to report a ransomware payment? Ask for a named owner and a reporting runbook. (Cyber Security Act 2024)

Product and proof

1. Does any feature have a medical purpose? Ask for an intended purpose statement and an ARTG entry if needed. (Therapeutic Goods Act 1989)
2. Which national systems does it connect to, and is it conformant? Ask for a register listing and the Implementation Conformance Statement. (ADHA conformance, HI Service)
3. How long are records kept, and how does deletion work? Ask for a retention schedule by record type and state. (APP 11.2, state health records laws)
4. Which certifications and tests back these answers? Ask for the ISO 27001 certificate and scope, plus a recent penetration test summary. (APP 11 reasonable steps)

For larger builds such as a hospital management system, run this checklist twice. Do it once at discovery and again before launch, because scope often shifts in between.

Compliance Software vs Compliant Software

The phrase healthcare compliance software in Australia covers two different needs. Some teams want tools that manage policies, staff training and credentialing. Others want their own patient-facing product to meet the rules.

This checklist focuses on the second need. Even so, the same questions help when you assess compliance software for healthcare in Australia. After all, those tools also hold sensitive staff and patient data.

Questions to Ask a Development Partner

The right partner should answer these questions clearly and with examples:

• Healthcare experience: Which health products has your team shipped, and which rules did they meet?
• Data handling during development: Will developers work with synthetic or de-identified data instead of real patient records?
• Transparency: When do we get access to the code repository, design files and documentation?
• Security testing: How do you test security before each release, and what do you share with us?
• Scope changes: How do you flag a feature that could change our TGA classification?
• Documentation ownership: Who owns the compliance documentation once the project ends?

Clear, specific answers here usually signal a team that treats compliance as part of the build.

How Much Does Compliance Add to Healthcare Software Cost and Timeline?Copy link to "How Much Does Compliance Add to Healthcare Software Cost and Timeline?"

Compliance work shows up in your budget as architecture, testing and documentation, so it helps to plan for it from day one.

Compliance rarely appears as a separate line item. Instead, it spreads across every phase of the build. The earlier you plan for it, the less it costs, because retrofitting is always slower than designing it in.

Where Compliance Effort Sits in a Build

Each project phase carries its own compliance work:

1. Discovery: Map your data flows, confirm your TGA classification and list every automated decision.
2. Architecture: Choose your hosting region and design access controls, audit logging and retention rules.
3. Development: Build consent capture, decision logs, patient export and deletion workflows.
4. Testing: Run security tests and complete conformance testing for any national integrations.
5. Launch and beyond: Rehearse breach responses, update conformance declarations and refresh your privacy policy as rules change.

Skipping discovery work creates the costliest gaps. For example, consent you never recorded cannot be added later. Similarly, moving to an Australian hosting region after launch means a full data migration.

What Pushes the Cost Up or Down

Four factors move your compliance budget the most:

• National integrations: My Health Record and HI Service connections need conformance testing, which adds time to your schedule.
• AI features with a medical purpose: The TGA pathway requires evidence and documentation that can extend timelines significantly.
• Hosting and data residency: Keeping data onshore narrows your choice of cloud providers, regions and AI tools.
• Audit and documentation needs: Enterprise health clients often ask for penetration test reports, privacy documentation and privacy impact assessments before signing.

On the other side, lean data models lower costs. Collecting less data means fewer fields to protect, log and eventually delete.

Ballpark Ranges for Healthcare Software

As a starting point, here is what healthcare software builds typically cost at SolGuruz, in Australian dollars:

• Basic MVP: around AUD$22,000 to AUD$36,000+
• SMB platform: around AUD$43,000 to AUD$72,000+
• Enterprise system: around AUD$100,000 to AUD$145,000+

These ranges include core compliance features such as access controls, audit logs and consent records. However, TGA pathways and national integrations sit on top and vary widely by scope.

For a closer number, try our patient management software cost calculator. Building a virtual care product instead? The telemedicine app cost calculator covers video, messaging and integration features.

Budget clarity matters most when the team building your product treats compliance as part of the design.

How SolGuruz Builds Compliance Into Healthcare SoftwareCopy link to "How SolGuruz Builds Compliance Into Healthcare Software"

Here is how our delivery process lines up with the requirements covered in this guide. Each step below maps to a requirement covered earlier in this guide:

1. Discovery comes before any budget talk.

We map data flows, TGA risk and automated decisions first, so compliance shapes the estimate from the start.

2. An NDA is signed before the first conversation.

Your product idea and any sample data stay protected before you share a word.

3. ISO 27001 and ISO 9001 certified.

Both are independently audited, covering information security and quality management on every project.

4. Full code and Figma access from day one.

You hold the build evidence auditors and enterprise buyers ask for, throughout the project.

5. Two review layers before every merge.

Automated code review runs on every commit, and an AI quality agent scores each pull request across nine criteria.

6. Daily updates from every team member.

Paired with weekly timesheets, they give you a clear record of who built what and when.

The same process runs on our healthcare projects. For example, we built a healthcare staffing platform for a US client that delivered 3x faster shift fulfilment. It also cut manual scheduling effort by more than 60%, and client satisfaction rose from 6.5 to 9.2. You can read the full story in our healthcare staffing app case study.

Australian clients work with the same daily process too. If you want to test the fit first, we offer a one-week risk-free trial with no contract or deposit. That gives your team a real look at how we handle custom software development in Australia before you commit.

With the process covered, here is where to start.

Where to Start With Healthcare Compliance in AustraliaCopy link to "Where to Start With Healthcare Compliance in Australia"

Healthcare compliance in Australia can feel like a moving target, but three priorities cover most of the ground.

1. First, map your product category: Your obligations depend on what your product does, so confirm whether it handles health information, makes automated decisions or has a medical purpose. That single step tells you which rules apply.

2. Second, prepare for 10 December 2026. If your product scores, triages or approves people, map your automated decisions and update your privacy policy now. Meanwhile, design with Tranche 2 in mind, since its fairness test would also cover data you already hold.

3. Third, treat AI features as regulated by default. Plan for consent capture, human review and output logs from the first sprint. As a result, a later TGA or AHPRA question becomes a quick answer instead of a rebuild.

Each of these steps fits naturally into discovery, so that is the best place to begin. If you are scoping a new health product, our team can map your features against these rules in a free discovery call.

Frequently Asked QuestionsCopy link to "Frequently Asked Questions"

1. How is AI being used in healthcare in Australia?

Australian providers use AI for clinical documentation, medical imaging analysis, triage chatbots, appointment scheduling and patient risk scoring. AI scribes have grown fastest, which is why the TGA clarified their regulatory status in January 2026.

2. How does AI affect healthcare compliance in Australia?

AI adds three layers of obligations. Privacy law covers the data it uses, the TGA covers any medical purpose, and AHPRA guidance shapes how clinicians use it. Automated decisions also need disclosure from December 2026.

3. What are the consequences of non-compliance in healthcare in Australia?

Consequences include civil penalties, OAIC investigations, patient lawsuits under the privacy tort and lost contracts. In 2025, a pathology group paid $5.8 million in Australia's first Privacy Act civil penalty case.

4. Does the Privacy Act apply to a small health app?

Usually, yes. Any business that provides a health service and holds health information falls under the Privacy Act, whatever its turnover. That includes apps that track symptoms or record health details.

5. Is my health app a medical device under TGA rules?

It depends on your intended purpose. If your app aims to diagnose, prevent, monitor, predict or treat a disease, it likely counts as a medical device and needs ARTG inclusion before supply.

6. Can Australian patient data be stored or processed overseas?

It can, but APP 8 keeps you accountable for how overseas parties handle it. My Health Record data is stricter and must generally stay in Australia. Many health providers choose onshore hosting to reduce risk.

7. What changes on 10 December 2026 for healthcare software?

From that date, privacy policies must explain automated decisions that could significantly affect people. Health products that triage, score or approve patients need to list those decisions, the data used and where humans step in.

8. Does Australia have mandatory AI rules for healthcare?

Australia has no standalone AI law. The government shelved its proposed mandatory guardrails in December 2025. Instead, privacy, TGA, consumer and anti-discrimination laws apply to AI, alongside AHPRA guidance for clinicians.

9. What does My Health Record integration involve?

Integration starts with the HI Service for healthcare identifiers. Your team then secures connections with national certificates, uses the right gateway, completes conformance testing and declares conformance for each released version.

10. Is ISO 27001 enough for healthcare compliance in Australia?

ISO 27001 shows strong information security management, yet it covers only part of the picture. You still need Privacy Act processes, breach response plans, TGA checks where relevant and conformance for national integrations.