Trust
Privacy policy
Echo Pathways is designed to hold as little clinical data as it possibly can, and to be able to prove what it did with the rest. This page explains exactly what that means.
The short version
Where a hospital's record system already holds a result, we do not keep a second copy of it. We keep proof of what we saw and what we decided — a cryptographic hash, the source reference, and the inputs to the rule — so any decision can be replayed and checked against the original. There are two narrow exceptions, set out below, where we do retain the document. We never train models on patient data. Not on identifiable data, and not on de-identified data either.
1. Who we are
Echo Pathways is a product of Visualisation Hub Pty Ltd ("we", "us"), an Australian company, trading as Echo Pathways. Our sister product Echo-Health operates under a separate privacy policy; this policy covers Echo Pathways only, and the two products do not share a data store.
In almost all deployments the healthcare service is the data controller (or, under Australian law, the APP entity accountable for the health information) and we act as its processor, under a written agreement that sets out what we may do with the data. Where that agreement conflicts with this page, the agreement governs.
2. The law we work under
- Australia — the Privacy Act 1988 (Cth) and the Australian Privacy Principles, including the additional protections that apply to health information as sensitive information, plus applicable state health-records legislation.
- New Zealand — the Privacy Act 2020 and the Health Information Privacy Code 2020.
- United Kingdom / EEA — the UK GDPR and EU GDPR, where a partner is established there.
3. What information we handle
| Category | Examples | Why |
|---|---|---|
| Clinical results | Pathology observations, laboratory reports, the marker values a protocol watches | To match a patient to a protocol and evaluate its rules |
| Patient context | A pseudonymous record identifier, and the minimum demographic and treatment context a protocol needs | To determine whether a protocol applies and who is responsible |
| Actions & provenance | The recommendation raised, the rule that fired, its recorded inputs, the source reference and hash, who was alerted and when | To make every decision replayable and auditable — this is the record we do keep |
| Clinical user accounts | Name, work email, role, service, authentication events | To operate the service, assign accountability, and secure it |
| Operational logs | Processing-ledger entries, error traces, access logs | Safety, security and regulatory evidence |
We collect only what a protocol actually needs. Where a protocol can run against a pseudonymous identifier, that is what we use.
4. Retention — proof, not custody
This is the part of our design we would most like you to read carefully, because it is unusual.
The default: we do not keep the clinical payload
For data we pull from a record system that already holds it — a FHIR or HL7 result from Epic, Oracle Health or a laboratory system — that system remains the record of truth, and we do not become a second custodian of it. Once a result has been evaluated, we discard the payload and retain only:
- a
source_sha256— a one-way hash of exactly what we read; retrieved_at,source_system_idandsource_version_id— where it came from and which version;mapping_version— how we interpreted it; and- the recorded inputs to the rule that fired.
Together these make the decision fully replayable: re-fetch the result from the source system, re-hash it, compare. If the hash matches, we can prove precisely what we saw and precisely what we did with it — without holding the data.
The two exceptions, where we do retain the document
The argument above only works when there is an upstream record of truth to point back to, and when a hash is a sufficient account of what happened. In two cases it isn't, and we retain the artefact — encrypted, access-controlled, and subject to a retention window agreed with the service:
- (a) Documents we receive directly
- A document uploaded to us, or an HL7 feed where we are the endpoint, has no upstream custodian to refer back to. If we discarded it, the evidence would simply cease to exist.
- (b) Anything a model read
- Where a value was extracted from an image or a scanned document by a model, a hash cannot tell a reviewer whether the extraction was correct. Only the original image can. Retaining it is what makes the extraction auditable — and therefore challengeable.
Retention outside these two cases is treated as a defect in our system, not a policy choice.
Everything else
Actions, provenance and ledger records are retained for the period required to evidence the safety of the device and to meet the service's own clinical-record obligations — set per deployment, and never shorter than the law requires. Accounts and logs are retained while the service is provided, then deleted or de-identified.
5. Artificial intelligence — the hard limits
- We never train models on patient data. Patient information is never used to adapt, fine-tune or otherwise bake data into model weights — not identifiable data, and not de-identified data. This is a stricter position than most of the sector takes, and we hold it deliberately.
- Models never make the clinical decision. They read documents. Trend detection, threshold logic, schedules and action selection are deterministic rule execution.
- Models are version-pinned. A replay of a past decision uses the model version that made it.
- We do not send your data to a third party's model for that party's benefit. Where a third-party model is used for document reading, it is under a contract that forbids training on, or retaining, the content.
6. Who we share it with
We do not sell personal information, and we do not use it for advertising. We disclose it only to:
- the healthcare service itself, which is the party the data belongs to;
- infrastructure providers that host the service under contract, bound to confidentiality and used only to run it; and
- a regulator, court or authority, where we are legally compelled — and we will tell the service unless we are prohibited from doing so.
7. Where it is held
Echo Pathways is deployed into the customer's own tenancy. For Australian services, data is held in Australian regions by default; New Zealand and UK deployments are hosted in-region on the same basis. Data residency is a term of the deployment agreement, not a setting we change unilaterally.
8. How it is protected
Row-level security is enforced on every table, so a query cannot reach a row a user is not entitled to see. Secrets are held server-side only; no key beyond the public anonymous key ever reaches a client. Access is least-privilege and logged. Every data path writes to a processing ledger — instrumentation is a build requirement here, not an add-on, which means the record of what we did with data is generated by the system rather than asserted by us. See Security & data handling.
9. Your rights
If you are a patient whose information may have been processed by Echo Pathways, your first point of contact is the healthcare service treating you — it holds your record and is accountable for it, and it can reach us. You may ask it to access, correct, or complain about the handling of your health information, and we will support it in responding.
You may also contact us directly at privacy@echo-pathways.com. We will acknowledge within 5 business days and respond within 30 days.
If you are not satisfied with our response, you may complain to your regulator:
- Australia — Office of the Australian Information Commissioner, oaic.gov.au
- New Zealand — Office of the Privacy Commissioner, privacy.org.nz
- United Kingdom — Information Commissioner's Office, ico.org.uk
10. Breach notification
If a data breach occurs that is likely to result in serious harm, we will notify the affected healthcare service without undue delay so it can meet its own obligations, and we will notify the relevant regulator where the law requires it of us.
11. Changes
We will post any change here and update the version and effective date above. Where a change materially affects how we handle health information, we will notify the services we work with directly rather than relying on this page.
12. Contact
Privacy: privacy@echo-pathways.com
Security: security@echo-pathways.com
Visualisation Hub Pty Ltd, Australia.