Home / Trust and security
HealthOS SaaS and HealthOS PaaS

Trust and security

There are two ways to use HealthOS. Use HealthOS SaaS for the standalone products, on our service shared by many subscribers. Use HealthOS PaaS for the full platform, in a cloud account you control. This page covers how each one keeps your data safe, and what to do if you find a problem.

In short

  • SaaS: your workspace is stored in Microsoft Azure in Australia, the database keeps each subscriber’s rows apart, and personal details expire after a day by default.
  • PaaS: HealthOS runs in a cloud account you control, onshore in Australia, signed in through your own identity provider, with every change kept for seven years.
  • Found a problem in either? Email security@healthos.net.au.

Two ways to use HealthOS

HealthOS SaaSHealthOS PaaS
What it isCode Navigator, Periscope and PurserThe full platform, from intake and care administration to care delivery and insights
Where it runsOur service in Microsoft Azure, Australia EastA cloud account you control, onshore in Australia
Who shares itMany subscribers, kept apart by the databaseNo other customer
Signing inA HealthOS account, with an authenticator app codeYour own identity provider
Personal detailsRemoved after 1 day by default, or 7 or 30 daysKept as part of the care record
Encryption keysHeld by us in AzureHeld in your own key vault

HealthOS SaaS

Code Navigator, Periscope and Purser, used from app.healthos.net.au.

Where your data lives

The HealthOS SaaS products run in Microsoft Azure, in the Australia East region. The database, uploaded files and backups all stay in Australia.

One product sends text outside that boundary. Code Captain, the AI coder, reads clinical documents through Azure AI Foundry, which may process a request in another Azure region. Before anything is sent, your browser removes the patient’s identifying details from the document, and the server checks the text again and refuses it if an identifier has survived. Periscope and Purser use no AI. Billing goes through Stripe. Everyone who handles data for us is on the Sub-processors page.

Kept apart from other subscribers

Every row in the database carries the workspace it belongs to, and PostgreSQL row-level security, forced on every table, returns only that workspace’s rows. The application connects to the database as a role that cannot bypass those rules, and the deployment refuses to finish without it. So a fault in a screen or a query cannot show one subscriber another’s records: the database does not hand them over.

Encryption

  • Everything between your browser and the service travels over HTTPS, and the service’s connections to its database and cache are encrypted.
  • The database, file storage and backups are encrypted at rest by Azure.
  • The credentials you connect, such as your GPMS machine credential, Developer Portal secret and PRODA device key, are stored encrypted and never shown again.

Signing in

  • Passphrases are checked against passwords known from data breaches. Only the first five characters of a hash of the passphrase leave our servers for that check.
  • Accounts can sign in with a code from an authenticator app.
  • Each person has their own account, and workspace managers decide who has access.

Personal details expire by default

Personal details in a workspace are removed every night once they are older than the period you choose: 1 day by default, or 7 or 30 days. Anything already lodged with GPMS or exported goes at the next purge. What the workspace is set up with, such as your connections, homes and pay category mappings, and totals that name nobody, are kept. The Your data page in the app shows what is held and the night each record’s details go. See Personal data and the nightly purge.

Audit trails

Who did what is recorded in append-only tables, which the database refuses to change or delete. That covers sign-ins, access to records, use of your government credentials and every lodgement, which is kept with its receipt. Refused attempts to reach another workspace are recorded as security events.

Backups

The database is backed up automatically, with point-in-time recovery, and backups are kept for 35 days in Australia.

HealthOS PaaS

The full HealthOS platform, in a cloud account you control. Written for IT, privacy and risk teams: this is what a security review will find.

In your cloud, onshore

HealthOS PaaS runs inside a cloud account you control, onshore in Australia. No other customer shares it, and data never leaves the country.

Encryption

Data is encrypted with AES-256 at rest and TLS 1.3 in transit. Secrets are encrypted with a key stored in your own key vault, and sensitive fields carry authenticated encryption (AES-256-GCM) on top.

Your identity provider, your roles

Staff sign in once through your existing identity provider, with role-based access control. Multi-factor authentication is enforced for admin accounts, and idle sessions time out automatically.

Kept apart by the database

Row-level security in the database means staff see only the records their organisation, facility and role permit. It is enforced on every query as well as on screen. If you have several organisations, they can share your HealthOS PaaS, and each one’s records stay walled off from the others.

Audit trails

Every record change is captured with the user, the time and the values before and after. The log is append-only, can be searched, and is kept for seven years. Nothing is ever hard-deleted.

Privacy and resilience

The platform is built against the Australian Privacy Principles, with consent management and data minimisation built into the product itself. Daily automated backups come with point-in-time recovery, restricted administrative privileges and network segmentation, following the ACSC Essential Eight maturity model. AI drafting works from de-identified records, inside your own cloud.

Certification

HealthOS is working towards ISO 27001 certification and does not hold it today. That work produces an information security management system, a risk register, an Annex A control mapping and evidence packs. Ask us for the detailed security pack and we will walk your team through each control.

Both

These apply to HealthOS SaaS and HealthOS PaaS alike.

Vulnerabilities and patching

  • Every week, an automated scan checks HealthOS’s software libraries and container images for known vulnerabilities, and a critical one with a fix available fails it and raises an issue for a person to act on.
  • Each build applies the operating system’s security updates, and every release is pinned to the exact version of the code it was built from.
  • A critical vulnerability is patched or mitigated ahead of other work, and sooner still if it is being exploited.
  • Our own development and testing systems never hold real data.

Security testing

Independent penetration test. On 1 November 2026 Penti, an independent security firm, tested the HealthOS SaaS service at app.healthos.net.au. Its autonomous penetration testing agents attacked the service from outside, the way an adversary would, alongside ZAP, Nuclei and security-header scans (certificate PNT-2026-5834F04E).

  • No critical findings.
  • We checked every finding against the code. The ones that needed a change are fixed and live. Two were false positives (one from how a single-page application is served, one a fixed number inside a third-party library), and two were accepted as low risk, with our reasons recorded.
  • Penti tested from outside, without signing in. Testing signed in as users is next.
  • Penti’s report and our response to each finding are available to customers on request, under a confidentiality agreement.

Our own testing.

  • We test HealthOS ourselves with automated security tools. Every change to the code is scanned before it can be released.
  • Before a release, we also run a full attack scan of every page and API route, and send over a hundred thousand malformed requests to the API to find anything that breaks.
  • We test on a separate copy of the SaaS service that holds only invented data, never on a real workspace. HealthOS PaaS is built from the same code.
  • What the tools find is fixed and tested again, and we keep a log of every finding and its fix.

Reporting a vulnerability

If you think you have found a security problem, email security@healthos.net.au. Our contact details are also published in security.txt.

  • Tell us what you found, where, and how to reproduce it.
  • Give us a reasonable time to fix it before you tell anyone else.
  • Do not access, change or keep other people’s data, do not degrade the service, and do not test against a workspace or a HealthOS PaaS that is not yours.

We will acknowledge your report, keep you told while we fix it, and credit you if you would like. We will not pursue anyone who reports in good faith and follows these rules.

Notifiable data breaches

If your data is involved in a breach, we will tell you promptly, tell you what we know, and help you meet your own obligations under the Notifiable Data Breaches scheme, including notifying the people affected and the Office of the Australian Information Commissioner.

Service status

For the SaaS products, the status page in the app shows whether the service is running, and needs no sign-in. It is at /status on the app’s own address. HealthOS PaaS is monitored in your own cloud account.

More

How we handle personal information is in the Privacy Policy. How the platform fits together is in How it works, and AI drafting from de-identified records is in AI Handover.