Health Data, Privacy and the Australian Privacy Act for Builders

If you’re building a health platform-whether it’s a telehealth marketplace, a wellness app, or an AI agent that processes patient records-you’re handling information the Australian Privacy Act treats differently from other data. Get this wrong and you’re looking at potential fines, reputational damage, and a product you can’t legally operate. Get it right from day one, and you’ve built a competitive moat your competitors will struggle to replicate.

The Privacy Act isn’t optional bureaucracy. It’s the foundation your product sits on. Most founders discover this after they’ve architected their database, chosen their cloud provider, or hired offshore contractors. By then, the fix costs time and money you don’t have. This post walks through the real constraints and the architecture decisions that matter.

The Australian Privacy Act Applies to Your Health Data

The Privacy Act 1988 (Cth) is Australia’s main privacy law, and it covers most businesses handling personal information-including health data. There’s no separate “health data law” in Australia the way there’s HIPAA in the US. But the Privacy Act treats health information as “sensitive personal information,” which means stricter rules than, say, a user’s email address.

Key thresholds:

• If your organisation has an annual turnover of AUD 3 million or more, the Privacy Act applies to you. Startups under that threshold aren’t exempt-the Act still applies, but the Australian Information Commissioner has limited enforcement power.
• Health information includes genetic data, medical history, disability status, counselling records, and anything a health professional holds about a patient’s physical or mental health.
• If you’re a private health insurer or a private hospital, you’re also bound by the Health Records Act-a stricter regime with slightly different obligations.

The practical issue: if you’re building a B2B health platform (say, software for allied health clinics), you’re probably handling health information on behalf of those clinics. That makes you an “APP”-an Australian Privacy Principle entity-and you need a Privacy Policy and documented handling procedures before you go live.

The 13 Australian Privacy Principles (APPs) That Matter Most

The Privacy Act codifies 13 principles. For health-data builders, four are non-negotiable:

1. APP 1: Open and transparent management of personal information. You need a published Privacy Policy. It must describe what health data you collect, how you use it, who you disclose it to, and how users can access or correct it. This isn’t a 50-page legal document-it’s a clear, plain-language explanation. Most founders skip this until launch; it should be drafted alongside your product spec.
2. APP 3: Collection of solicited personal information. You can only collect health information if it’s reasonably necessary for your business function, and you must tell the user you’re collecting it. If you’re collecting genetic data “just in case” or bundling health questions into a signup form without clear consent, you’re in breach.
3. APP 6: Use or disclosure of personal information. You can’t use health data for a secondary purpose without fresh consent. If a user signed up for a mental health check-in service, you can’t use their data for marketing or sell it to an insurance broker without asking them again.
4. APP 11: Security of personal information. You must take reasonable steps to protect health data from misuse, loss, and unauthorised access. This means encryption in transit and at rest, access controls, staff training, and incident response procedures. If you suffer a breach affecting more than a small number of users, you’re obliged to notify affected individuals and the Commissioner.

APP 11 is where most startups get caught. “Reasonable steps” isn’t precisely defined, but the Commissioner’s guidance is clear: if you’re storing health data in an unencrypted database on a shared server, or if your contractors have full database access without logging, you’re below the bar. If you’re using a reputable cloud provider (AWS, Azure, Google Cloud) with encryption and access controls configured, you’re roughly in the right zone-though you still need documented procedures.

Consent, Retention, and Offshore Contractors

Health data consent must be explicit. A tickbox saying “I agree to the Terms of Service” is not consent to process health information. You need separate, clear language: “I consent to Amora storing my mental health questionnaire responses to provide me with personalised insights. I can withdraw this consent at any time.” Users must be able to say yes or no without losing access to core features (unless that core feature genuinely requires the data).

Retention is equally strict. You can’t keep health data “just in case.” If a user deletes their account, you must delete their health records within a reasonable timeframe-usually 30 days, unless you have a legal obligation to retain it (e.g., a clinic must keep patient records for seven years under state healthcare regulations). If you’re exporting data to train an AI model, that’s a secondary use and requires fresh consent.

This is where offshore subcontracting becomes a real problem. If you hire contractors in the Philippines or Eastern Europe to build your database layer or integrate APIs, and they touch health data-even just to test the system-you’ve potentially breached the Privacy Act. The Act applies to your business; you can’t contract around it. If your overseas contractor has a security incident or poor access controls, you’re liable. Most Australian founders don’t realise this until they’ve already hired and committed budget. If you’re building a health product and you need development support, keep the work in-house or use Australian developers who understand these constraints. When you’re ready to move faster on product development and growth, talk to Amora about your build-we’re an Australian team with no offshore subcontracting.

The Real Build Constraints

Privacy requirements affect your architecture, not just your documentation. Here are the concrete trade-offs:

Database design: You need to separate identifiable data (name, email, Medicare number) from health information where possible. Some platforms store health data with a token or pseudonym, keeping the lookup table encrypted separately. This adds a database layer but gives you flexibility-if a user requests deletion, you delete the lookup entry and their health records become orphaned and harmless.

Backups and disaster recovery: You can’t back up health data to an unencrypted S3 bucket or a developer’s laptop. Backups must be encrypted and stored securely. This costs slightly more (encrypted backups are slower and use more storage), but it’s non-negotiable.

Third-party integrations: If you integrate a payment processor, SMS service, or AI API that touches health data, you need a Data Processing Agreement (DPA) in place. The third party must agree to handle the data according to your privacy obligations. Some SaaS tools (especially US-based) won’t sign a DPA or will charge extra for it. Factor this into your vendor selection.

Audit trails: If multiple users (e.g., a clinician and a patient) access the same health record, you need logged access. Who viewed what, when, and from where. This is useful for security and essential for compliance audits. Most health platforms add an immutable audit table.

Practical Next Steps

If you’re pre-build and considering a health product:

1. Draft your Privacy Policy now, not after launch. Use the Australian Information Commissioner’s template as a starting point. Have a lawyer review it for AUD 800-1500. It’s cheap insurance.
2. Map your data flows. What health information will you collect? Where does it go? Who has access? How long do you keep it? Document this before you code.
3. Choose a cloud provider with encryption, access controls, and a clear terms of service covering health data. AWS and Azure explicitly support regulated healthcare workloads in Australia.
4. If you’re hiring contractors or employees, include privacy training and written agreements about data handling. Make it part of onboarding.
5. Plan for breach notification. How will you detect a breach? How will you notify users and the Commissioner? Have a process documented before you go live.

Privacy isn’t a feature you bolt on at the end. It’s part of your product architecture, your hiring decisions, and your vendor relationships. Get it right early, and you’ve built trust with users and regulators. Get it wrong, and you’re rewriting code and facing legal bills at a moment when you should be scaling.