Security & data handling
Written to be checked, not believed.
This page states what the system does, what it leaves to the platform you deploy on, and what it refuses to do. Where a control is your responsibility we say so, because a security page that claims everything is a security page nobody can verify.
| Images | Stored at the acquiring site or in your datacentre |
| Reports | Stored with the record system you host |
| Credentials | Generated per installation, never shipped in the software |
| Vendor access | None by default; granted, time-bound and logged if you want support |
| Telemetry | None sent off-site |
Access
Who can reach a study, and how that is decided.
Authentication
Accounts are held by your installation. Sessions are carried in a signed, HTTP-only cookie, marked secure once the deployment is behind TLS. Passwords are stored as salted hashes, never recoverable.
Roles and privileges
Roles are configured by the operator, and individual privileges — administration, export, sharing, deletion — are attached to accounts rather than assumed from a role name.
Scope enforced at the source
A user's reach is checked in the application layer that serves the study, not by hiding a button. A request outside scope is refused, and refusal means a refusal — not a silent sign-out that teaches staff to re-authenticate reflexively.
Service accounts are narrow
Components that need to read on a patient's behalf get accounts limited to what they do. The film and delivery service, for instance, can read an appointment and its report, and cannot see the patient register or any financial record.
Sharing is signed and revocable
A public link to a report or a study is signed, time-limited, individually revocable, and can be gated so that it does not resolve until the examination is settled. Every link is attributable to the account that created it.
Tenant isolation
Rows belong to exactly one institution. A search from inside one tenant does not return another tenant's patient, including a search by national identifier.
Transport, storage and the network
What we do, and what your platform does.
| Control | Provided by | Detail |
|---|---|---|
| Transport protection | you, with our spec | HTTPS is terminated at a reverse proxy under your control. The deployment guide sets the required configuration and the cookie flags that follow from it. |
| Storage protection | your platform | Volume or full-disk encryption on the hosts. We specify it in the deployment architecture rather than reimplementing it above the filesystem. |
| Database exposure | us | The databases are never published to a public interface. They are reachable only from the services that use them. |
| Site reachability | us | Sites dial outward to a gateway you control. No inbound port is opened on a clinic router, and no site needs a public address. |
| Secrets | us | Generated per installation at setup, held outside the source tree, and never present in the distributed software. |
| Backups | shared | We provide the backup and restore procedure and the configuration export; you own the schedule, the destination and the off-site copy. |
Record keeping
What is recorded, and what it is for.
Audit exists to answer a question after the fact. These are the questions it is built to answer.
-
Who opened this study, and when
Sign-in, study retrieval, export and share creation are recorded against the account that performed them.
-
Who was refused, and for what
A denied action is recorded as a denial. A pattern of refusals against one account is a signal, and it is only a signal if refusals are kept.
-
What changed administratively
Role changes, privilege grants, storage and node configuration, and template changes are attributable.
-
What the system itself did
Retention runs, purges, reconciliation decisions and integration refusals are logged with the reason, so an automated action can be explained to an auditor.
Retention & disposal
A policy the system applies, not one it documents.
Held for as long as you say
- Retention configured per institution and per class of study
- Applied by a scheduled process, with each run recorded
- Storage tiering so that long retention does not mean expensive storage
- Disposal is a logged event, attributable to the policy that caused it
And exportable at any point
- Studies leave as standard DICOM, readable without our software
- Reports export as documents and as structured results
- Configuration exports and re-imports, so a rebuild is not a re-entry
- No format, index or key that only we can read
Send your security questionnaire.
We answer them in the format you use, and we mark the rows where a control belongs to your platform rather than to us.