What building compliant healthcare software in Australia actually takes.

"Compliant" is the most overworked word in healthcare software, because it appears on every landing page and almost never arrives with a list of what it actually means - so here is the list.

Behind that single word sits a stack of architectural decisions, most of which have to be made before the first feature is built, and almost none of which a clinic can see from the outside. That is why compliance in Australian health software is not a certificate you bolt on at the end; it is instead a set of constraints that shape the database schema, the hosting bill, and the answer to the question every practice should put to a vendor: what happens to our patients' data, exactly? The rest of this piece walks through those constraints one at a time.

Where the data lives is an architecture decision

Where your patients' data physically lives is decided in the architecture, not in a settings panel. The Australian Privacy Principles don't ban offshore storage outright, but the moment patient data leaves the country you take on APP 8¹ and a chain of accountability that is hard to audit and harder to unwind, so the clean answer is not to send it offshore at all.

For that reason Trenthos hosts in AWS ap-southeast-2, the Sydney region.² That is a decision with teeth, because the leaks are rarely the database itself; they are the conveniences bolted on around it. Think of the error-tracking service that ships a stack trace, patient data and all, to a server in Virginia, or the email and SMS gateways, the font or script loaded from an overseas CDN, the analytics pixel, the third-party API a feature quietly calls. Every one of those is a place data can cross a border without anyone deciding that it should, which means residency is only as good as the weakest of them.

Done properly, then, data residency is a procurement discipline rather than a configuration flag. The artefact that proves it is a sub-processor register you can actually produce: every third party that touches data, where it physically runs, and under what terms, with the offshore ones either removed or contained. The flag is a checkbox, but the register is the work, and only the register can tell you whether the checkbox is true.

One database, many clinics, zero leaks

In multi-tenant clinical software, keeping one clinic's patients invisible to another is the whole game. Most clinical software is multi-tenant, which means many practices share the same infrastructure, and so the entire job is making sure clinic A can never see clinic B's patients: not through a bug, not through a crafted request, not through a query someone wrote in a hurry.

To see why that is hard, picture the query that forgets its clinic filter, the missing WHERE clinic_id = ?. Under application-only isolation, that query happily returns every clinic's rows, so the leak is silent and total. But push isolation down into the database with row-level security and the same buggy query returns an empty set instead, because the database applies the tenant policy itself regardless of what the query asked for. With that one change the failure mode flips from silent-and-catastrophic to silent-and-safe.

The stronger version goes further still, because the application connects to the database as a role that cannot turn that policy off. So even a serious bug, or an injected query, still can't reach across the boundary; the floor holds even when the walls don't. None of this is visible to a clinic, which is exactly why it gets skipped, and yet the right answer is to do both layers on purpose: guards on every endpoint and database-enforced row-level security underneath them. One of those layers is a convenience, but two of them together are a control.

Encryption is table stakes; the audit log is the real test

Encryption is the easy part of a clinical system, and the audit log is where the real work begins. Encryption in transit and at rest means TLS everywhere, encrypted volumes and encrypted backups, all of which is expected and none of which is where the hard problems live.

The real test of a clinical system is instead whether it can tell you, months later, who looked at a particular patient's record, when, and from where. That is the audit log, and it is the line between saying "we take privacy seriously" and actually being able to answer a regulator, or a patient, who asks.

A useful audit log records, for every access, the same four things: who (which user), what (which patient and record), when (a precise timestamp), and from where (the session). It is append-only, so an intruder who gets in can't quietly rewrite history to cover the visit. And, in the part most systems miss, it captures reads and not just writes, which matters because logging who changed a record is straightforward while logging who merely viewed one is the hard and important part. The day something goes wrong the question is not "what changed" but "whose data was seen", so a system that logs edits but not views can tell you what was altered and not what leaked, which is the wrong half.

Keeping data is a liability; deleting it is a feature

In health software, holding data is a liability and deleting it on schedule is a feature you have to build. Health records carry retention obligations that vary by state and by the patient's age, often in the order of seven years from the last entry for an adult and longer for records created while a patient was a child,³ and the practical point rather than the precise figure is what matters here: you cannot simply delete on request the way a consumer app can.

But you also cannot keep everything forever and call it caution, which is why good software treats retention and deletion as first-class features rather than something to bolt on later. Soft-delete withdraws a record from clinical view and from ordinary queries while preserving it intact until its legal retention runs out, and hard-delete then removes it for good once that clock finally expires. For every category of data the system holds, there is a written, defensible answer for which of the two applies and when.

The naive approach of never deleting anything, ever, is not safety at all. It is instead an expanding liability and a larger blast radius the day there is a breach, because the more you hold the more there is to lose. Restraint about what you keep is therefore itself a control, and it is one that costs nothing to design in and a great deal to retrofit.

The law sets the floor, not the ceiling

The law sets the minimum these decisions have to clear, not the standard worth aiming for. Underneath all of this is the Privacy Act 1988 and the Australian Privacy Principles, plus the Notifiable Data Breaches scheme, and that scheme is narrower than "any bad thing": an eligible data breach, broadly the unauthorised access to, disclosure of, or loss of personal information that is likely to result in serious harm, must be reported to the OAIC and to the individuals affected.⁴ You can only do that accurately if your audit log can tell you what was actually accessed, which is why the breach-notification obligation and the read-level audit log are, in practice, the same requirement seen from two ends.

Connecting to national infrastructure then adds more gates on top of that floor. Patient and provider identifiers, the IHI together with the HPI-I and HPI-O, are issued through the Healthcare Identifiers Service,⁵ and reaching production is itself a sequence: organisation registration through PRODA and HPOS, then NASH PKI certificates,⁶ each granted through an approval process rather than a sign-up form. Uploading to services such as My Health Record is conformance-assessed by the Australian Digital Health Agency,⁷ which is a structured evaluation against a published specification rather than a self-declaration, and the moment software starts guiding clinical decisions it can fall within the TGA's Software-as-a-Medical-Device framework.⁸ Because each of those is an approval rather than a claim, the honest position for any new product is "designed to align with these requirements and working toward the relevant pathways", never "approved" or "certified" as a finished fact.

What good looks like

You can tell the real thing from the rhetorical one by asking a handful of plain questions and listening for plain answers. None of the work above shows up on a feature list, which is precisely why "compliant" gets used as a one-word stand-in for all of it, and so the questions that separate the two are simple to ask and revealing to answer:

• Where is our data physically held - and every sub-processor's, too?
• Can you show me who accessed a given record, not just who changed it?
• What is the deletion policy, by data type - and what is soft-deleted versus hard-deleted?
• What is actually live today, versus on a roadmap?

A vendor who can answer those questions plainly has done the work, whereas one who reaches for "we take security seriously" has just told you where to keep looking.

Trenthos builds Lumen this way because the alternative, retrofitting compliance onto a system that was never designed for it, doesn't really work. These constraints are far easier to live with when they have been load-bearing from the first commit than when they are propped up against the building after it is finished, and that is the difference the word "compliant" is meant to carry.