The privacy of health apps under the Australian Privacy Principles

A headache logged at the kitchen table looks private. It is a note on a phone you hold. In practice it is often a record sitting on someone else's server, sometimes in another country, sometimes sold on as "insights", and sometimes kept long after you delete the icon.

Australian privacy law can reach that record. It does not reach it in the way many people assume. The Australian Privacy Principles sit in the Privacy Act 1988. They are the main federal rules for how APP entities handle personal information. Health apps sit awkwardly across those rules, the My Health Records Act, state health-records laws, and a consumer market that still markets itself as wellness.

This is a map of that awkwardness, not a verdict on any named product. It is also not a substitute for legal advice or for the clinical record your usual practice keeps.

What the APPs actually do

The thirteen Australian Privacy Principles are outcomes, not a software specification. They tell organisations when they can collect information, what they must tell you, how they can use and disclose it, and how they must protect it. They do not certify an app as safe.

An APP entity is usually an Australian government agency or a private organisation with annual turnover above the small-business threshold, with important exceptions. Health service providers are generally pulled in even when they are small. That exception matters for clinics. It is less tidy for a start-up that calls itself a coach.

Health information is not only a hospital file

Under the Privacy Act, health information is a kind of sensitive information. It includes information or opinion about your health, disability, or the health services you have received or will receive. A menstrual cycle log, a mood score, a photo of a rash, and a list of medicines can all qualify.

Sensitive information has a higher bar for collection. Consent is usually required unless a narrow exception applies. Marketing copy that says "we value your privacy" is not consent. Neither is a pre-ticked box buried under a "continue with Apple" button.

The same data can also be a consumer profile. App companies do not have to choose one description. They can treat a symptom as health information in the privacy policy and as engagement data in the analytics dashboard. The law looks at the information, not the product category.

Wellness is a marketing word

Many consumer apps insist they are not medical devices and not health records. That can be true for Therapeutic Goods Administration purposes and still false for privacy purposes. A product can be a wellness app in the store and a holder of health information under the Privacy Act.

The opposite mistake is also common. People assume that anything health-related is inside My Health Record. It is not. My Health Record is a national summary system with its own statute, access controls, and cancellation rules. A period tracker, a calorie counter, or a wearable companion app is usually outside that system unless a clinician or a connected device explicitly sends something in.

If you want the consumer-facing version of who can open the national record, read who can see your My Health Record. The short version for apps is simpler. Most of them never touch it. They build a parallel file you may not be able to export, correct, or kill.

Overseas servers and APP 8

APP 8 deals with cross-border disclosure. If an APP entity discloses personal information to an overseas recipient, it must take reasonable steps to ensure the recipient does not breach the APPs, or it must meet another permitted path, such as a recognised consent.

That is the rule in outline. The practice is messier.

Plenty of health and wellness apps are built by companies registered in the United States, Europe, or Singapore. Their Australian privacy policy may say data is "stored securely in the cloud". That phrase does not tell you the country, the subprocessors, or whether a foreign government can compel the host. It also does not tell you whether the Australian operator remains accountable after the transfer.

An overseas server is not automatically unlawful. An unreadable sentence about "global affiliates and trusted partners" is not automatically consent.

Some vendors use Australian data centres and still send support tickets, model training samples, or crash logs offshore. Location of the primary database is only one hop. The relevant question is every place the record can be read.

Consumers rarely get a list of those places. Clinicians who recommend an app to a patient inherit some of that opacity. If a practice is going to put a QR code for a symptom diary on the waiting-room wall, someone at the practice should read the data map first. The same caution belongs in any conversation about wearables in Australian general practice. A watch that streams heart-rate variability to a US dashboard is a disclosure decision, not a lifestyle accessory.

Permissions are the first leak

Before the privacy policy, there is the permission prompt. A symptom app that wants the camera may have a reason. A symptom app that wants the full contact list, precise location at all times, and access to Bluetooth "for personalisation" is collecting a neighbourhood, not a temperature.

On current iPhone and Android versions you can usually:

• deny a permission and still use the core function, if the developer bothered to build that path
• grant location only once, or only while the app is open
• see which apps used the microphone, camera, or clipboard
• revoke access later without uninstalling

You cannot see, from the permission screen, whether the app later uploads a photo to a contractor that trains a model. You cannot see whether a "health connect" or "Apple Health" link copies years of steps, sleep, and workouts into a new company. Those bridges are convenient. They are also a second collection event.

Treat every new permission as a fresh decision. Treat every health-kit connection as a disclosure.

What a complaint to the OAIC looks like

The Office of the Australian Information Commissioner is the federal privacy regulator. It is not a helpdesk that will retrieve yesterday's leaked spreadsheet.

In outline, a privacy complaint about an app usually runs like this.

First, complain to the organisation. Use the contact point in the privacy policy. Say what happened, what information was involved, and what you want. Keep the email.

Second, if that goes nowhere, or if it is not reasonable to expect you to deal with them, complain to the OAIC. The Commissioner can decline some matters, try conciliation, or investigate. Outcomes range from a closed file to an enforceable undertaking or court proceedings in serious cases.

Third, if the incident is a suspected eligible data breach, the organisation may have its own duty to assess and notify under the Notifiable Data Breaches scheme. That duty sits on the entity, not on you. A notification is not a finding that you will be compensated.

The OAIC path is slow relative to a viral leak. It is still the right formal path when an Australian-linked app mishandles health information. It is a weak path when the developer has no Australian presence and no assets here. That is one reason the overseas-server question is not academic.

State health complaints bodies and the Australian Information Commissioner can overlap when a public hospital app is involved. A purely consumer wellness product is usually a federal privacy matter if it is in jurisdiction at all.

A consumer checklist before you log a symptom

Use this before the first entry, not after the first breach notification.

• Who is the company, and which country is it based in? If you cannot name a legal person, stop.
• Is there an Australian privacy policy that says what is collected, why, and who it is shared with? A US policy that never mentions the APPs is a warning, not a technicality.
• Does the app need an account? Accounts create a file that can be requested, hacked, or sold with the company.
• What permissions does it request on day one? Deny anything that is not required for the task you actually want.
• Does it connect to Apple Health, Google Health Connect, a wearable, or your practice software? Each connection is another copy.
• Can you export your data in a readable format, and can you delete the account rather than merely the app?
• Is the product making a therapeutic claim? If it is diagnosing or titrating treatment, privacy is only one of the regulatory questions.
• Would you be comfortable with that information being read by an insurer, an employer, or a former partner who still knows your passcode?

If the answer to the last question is no, write the note in a local file, tell your usual GP, or wait until you are in a consulting room. Not every symptom needs a product.

What practices should say, and what they should not

General practices are under pressure to look modern. Recommending an app can feel like helping. It can also look like an endorsement of a vendor the practice does not audit.

A safer pattern is to describe categories, not champions. Explain that consumer apps are usually outside the practice record and outside My Health Record. Explain that screenshots of an app are not a substitute for a proper history. If the practice uses a specific remote-monitoring tool, say so, name the operator, and say where the data sits.

The same practice still has to secure its own systems. App privacy on the patient's phone does not cancel the work in cybersecurity for small medical practices. A clinic that cannot patch its practice software is in a poor position to lecture anyone about overseas servers.

Reception staff should not set up a patient's wellness account, and they should not accept a shared family password as identity. If a relative wants to log symptoms on someone else's behalf, that is a consent and authority problem, not an IT problem.

Where this sits in a wider privacy habit

Health-app privacy is one corner of a larger Australian argument about health data. The APPs were not drafted for always-on sensors. My Health Record was not designed as a consumer marketplace. Wearables arrive in the consulting room with charts that look clinical and contracts that are not.

The sceptical position is not "never use an app". It is "do not confuse a convenient log with a protected record". If you need a national summary, use the system that is actually built for that, and learn its limits. If you need a clinic to act, tell the clinic. If you want a private diary, a paper notebook still has the advantage that it does not update its terms on Tuesday.

For the rest of Digital Doctor's reporting on records, breaches and everyday permissions, start at the privacy and safety hub. Read the policies. Turn off the permissions you did not mean to grant. And do not log a symptom in a product whose owner you cannot name.