Skip to main content
zatersio

Build Compliant MVPs With Onshore Australian Health Data Hosting

Build Compliant MVPs With Onshore Australian Health Data Hosting

Decorative Australian health data hosting title card

Only My Health Record data is subject to an absolute onshore rule. Section 77 of the My Health Records Act 2012 blocks that dataset from ever touching offshore infrastructure, no exceptions. Every other patient dataset falls under APP 8, which allows offshore handling once you’ve taken “reasonable steps” to protect it. The practical move: classify each dataset first, lock MHR data onshore, then build architecture and contracts around the rest.

TL;DR:

  • My Health Record data must remain onshore at all times, with no exceptions for offshore handling, according to Section 77 of the My Health Records Act 2012.
  • Other patient datasets can be stored offshore if “reasonable steps” are taken to ensure they comply with Australian Privacy Principles, including contractual safeguards and technical controls.
  • Simply hosting data in an Australian region is insufficient; proper access controls, key management, and audit logs are essential to truly meet compliance standards.
  • The best architecture patterns involve either customer-managed encryption keys or keeping sensitive data in onshore repositories, especially for highly sensitive health information.
  • Using a dataset classification approach before development ensures compliance, reduces delays, and aligns procurement requirements with data protection needs from the start.
Zatersio
zatersio.com.au
Build Your Compliant MVP Faster
Zatersio combines bespoke engineering and AI-driven automation to build working software rapidly, with data residency options for privacy needs.
Explore Zatersio

Table of Contents

Section 77 doesn’t leave room for negotiation. It prohibits holding, taking, processing, or handling My Health Record data outside Australia, full stop. There’s no consent workaround, no contractual exception, no “but our cloud provider has an Australian entity” loophole. If a dataset originated from or connects to the My Health Record system, it stays on Australian soil, on Australian infrastructure, processed by systems that never route it overseas even temporarily.

Everything else in your patient data universe runs on different rules. APP 8 of the Privacy Act 1988 permits cross-border disclosure of personal information when you take reasonable steps to confirm the overseas recipient won’t breach the Australian Privacy Principles. The OAIC’s guidance frames “reasonable steps” as a mix of contractual commitments, technical safeguards, and ongoing oversight, not a single checkbox.

Reasonable steps typically include:

  • Contractual clauses binding the overseas party to APP-equivalent handling
  • Due diligence on the recipient’s jurisdiction and its own data protection laws
  • Technical controls like encryption and access restrictions that travel with the data
  • A documented risk assessment specific to that transfer, not a generic policy

State and territory laws add another layer. NSW and Victoria both maintain health-records legislation with consent and access provisions that can be stricter than the federal baseline, particularly around mental health records or information shared between public health services. A clinic operating across state lines needs to check whether the strictest applicable state rule, not just the federal one, governs a given dataset.

The decision rule that saves you rework: classify per dataset, not per project. Document that classification in your procurement paperwork before you talk to any vendor. A single health app might carry MHR-linked records, general patient intake data, and de-identified analytics data all governed by different rules simultaneously.

Which Architecture Actually Keeps Health Data Compliant?

Geography alone doesn’t solve compliance. A server sitting in a Sydney data center still needs the right access controls, key management, and audit trail behind it, or the “Australian region” label means very little in practice. Industry guidance on AI services and data sovereignty for regulated firms is blunt about this: residency and sovereignty are not the same thing, and buyers who treat them as interchangeable get caught out.

Four patterns cover most real-world MVP builds, in order of increasing control:

  1. Region-pinned cloud with customer-managed keys. Data sits in an Australian region, and you hold the encryption keys rather than the provider, a strategy detailed in practical vendor-level security controls and customer-managed key examples. This handles most non-MHR patient data well, provided the vendor contract backs up the region promise.
  2. Local vector store with isolated retrieval. For AI features, keep the sensitive corpus in an onshore vector database and route only de-identified snippets to any external inference layer, an approach regulated-industry guidance increasingly recommends for healthcare AI.
  3. Tokenization or de-identification before the model boundary. This works when your AI feature genuinely doesn’t need identifiable data to function, think appointment scheduling logic rather than diagnostic support. It fails when re-identification risk is high or when the clinical value depends on context that tokenization strips out.
  4. Private model deployment or on-prem inference. Reserved for your highest-sensitivity datasets, where even a compliant offshore API call is too much risk for your board or your insurer to accept.

Pro Tip: Match the pattern to the dataset, not the whole project. Most MVPs blend two or three of these patterns across different data types, and forcing everything into the strictest tier just slows delivery without buying extra protection.

What Should You Demand From a Hosting or AI Vendor?

Procurement teams often ask vendors the wrong questions, focusing on where servers sit rather than what happens to the data once it’s there. Cloud platforms now routinely offer Australian region selection and encryption features, but a feature list isn’t a guarantee. You need contractual teeth behind it.

Contract clauses worth insisting on:

  • A current subprocessors list, updated whenever a new one is added
  • Audit rights letting you or a third party verify claimed controls
  • Explicit data residency and retention clauses, including where backups live
  • A clause disabling use of your data for model training or improvement
  • Confirmation you control the encryption keys, not just the vendor

On the technical side, ask for evidence rather than assurances: encryption at rest and in transit, role-based access control, audit logging that captures who touched what and when, and a written incident response plan. Certifications like IRAP assessment, SOC 2, or ISO 27001 add weight where the vendor has them, though their absence isn’t automatically disqualifying for an early-stage MVP.

For AI-specific services, add questions about prompt retention windows, whether retention can be disabled entirely, which regions process inference requests, and which subprocessors touch the pipeline. These contract and audit steps are, in effect, how you satisfy the APP 8 “reasonable steps” test in a way that would hold up under scrutiny.

How Do You Get an MVP Both Compliant and R&DTI-Ready?

Rapid delivery and compliance don’t have to trade off against each other, but only if you sequence the work correctly. Here’s the order that avoids expensive rebuilds:

  1. Classify every dataset against Section 77 and APP 8 before writing a line of code, and map each one to an architecture pattern.
  2. Lock procurement requirements into the vendor contract: subprocessors, audit rights, key control, and acceptance criteria tied to evidence, not promises.
  3. Separate core from supporting R&D for tax purposes. AusIndustry guidance is specific here: hypothesis-driven experimentation, like testing whether a novel retrieval approach improves diagnostic triage accuracy, can qualify as core R&D activity, while routine integration work usually counts as supporting R&D at best.
  4. Keep the paper trail as you build, not after. Spike tickets, documented hypotheses, and test outputs are what substantiate an R&DTI claim later.
  5. Finalize operational basics: privacy policy, consent flows matched to your data classification, audit logging, and a breach response plan that names who does what within the first 24 hours.

Healthcare startups that bolt compliance on after launch tend to pay for it twice, once in rework and once in delayed go-live, particularly when TGA classification questions surface late.

Why Compliant MVPs Don’t Have to Be Slow

Why Compliant MVPs Don't Have to Be Slow — overview diagram

Most delays on health-data projects come from treating compliance as a gate at the end rather than a design input from day one. Build classification and security controls into the first sprint, and the rest of the build moves faster, not slower, because nobody is retrofitting encryption or renegotiating a vendor contract three weeks before launch.

The teams that get this right deliver audit-ready artifacts alongside the code itself: architecture decision records, encryption configuration, and access logs a compliance officer can actually read. Some vendors structure fixed-price MVP builds this way, with data residency choices set at the scoping stage rather than negotiated after the fact.

— Lakitha

How Zatersio Builds Compliant MVPs Without the Usual Delays

Some companies offer fixed-price MVPs with Australian data-residency options and R&DTI-aware recordkeeping built into delivery rather than reconstructed later.

Zatersio

That means fewer surprises during due diligence and a shorter path from scoping to something a clinician can actually test. These builds can include direct access to the engineering team doing the work and come with operational artifacts, architecture decisions, encryption setup, and access logs that procurement teams often require. If you’re commissioning a health data project and want data residency handled correctly from the outset, start with Zatersio’s MVP development page to scope your build and confirm timelines.

Where to Verify These Rules Yourself

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Sources