Security & compliance
A patient record is not ordinary business data. This page sets out exactly how Patient360 protects it — in plain terms, so you can judge it for yourself.
Every record in Patient360 belongs to exactly one provider, and that boundary is enforced by the database itself through row-level security — not by the application, and not by the interface. No provider can read another provider’s records, even if a request were crafted by hand. The single documented exception is our own named administrators, described below.
A small number of named Patient360 administrators can read records across providers, so that we can investigate faults, recover data and support your staff. That access is read-only — we cannot create or alter a patient record, document or clinical note in your records — and it is logged in the same audit trail as your own staff. We would rather write this down than let you assume an access boundary that does not exist.
Administrators, clinicians and records officers each get a different view of the system. Those rules live on the server. Hiding a button in the browser is not a security control, so we do not rely on it.
There is no public sign-up. A person can only reach your organisation’s data if your administrator has invited that specific account. Sign-in goes through Google, so you inherit its protections — including two-factor authentication where your staff have it enabled.
Views, edits and document downloads are written to an append-only audit log with the user, the record and the timestamp. The log is partitioned and retained so it stays queryable as it grows.
All traffic is served over HTTPS with modern TLS. Database contents and uploaded documents are encrypted at rest by the underlying platforms, and documents are only reachable through short-lived signed links that expire.
New staff start with the minimum their role needs. Access to a record outside a user’s normal scope goes through an explicit request-and-grant flow, which is itself logged.
Data protection
Patient360 is designed around the obligations the NDPA places on a provider as the data controller. In practice that means the product gives you the mechanisms you need to meet them:
Lawful basis and consent
Consent is captured and stored against the patient record, with a timestamp, so you can show when and how it was given.
Data minimisation
We collect what a patient record needs and no more. There is no advertising tracking on the product, and we do not sell or share data with third parties.
Right of access and portability
A patient’s record can be exported on request, so you can satisfy a subject access request without a manual file hunt.
Accountability
The audit log gives you evidence of who accessed what — the record-keeping the Act expects you to be able to produce.
Retention
Records are retained according to the policy you set, rather than kept indefinitely by default.
On roles and responsibility. Under the NDPA your organisation remains the data controller for your patients' records; Patient360 acts as your data processor. We are happy to sign a data processing agreement, and to walk your legal adviser through the technical controls described above.
The database is backed up continuously, so a record can be recovered if something goes wrong.
You can export your records at any time. There is no lock-in clause that holds your data hostage.
Errors and performance are monitored so problems are found before they are reported.
Access rules are covered by automated tests that run on every change, so an isolation rule cannot be quietly broken.
We would rather hear about it than not. Report it to support@patient360.health and we will acknowledge it quickly. We will not pursue anyone who reports a genuine vulnerability in good faith.
We are happy to take your IT or legal adviser through the architecture in detail, and to answer a security questionnaire.
