Security
Clarirad holds patient records for radiology practices, so the controls below are built into the product and switched on by default: mandatory multi-factor sign-in, impossible-travel blocking, tenant isolation enforced by the database, and an audit trail that cannot be changed without leaving a trace.
- Multi-factor authentication, mandatory
- Impossible-travel blocking
- Tenant isolation in the database
- Tamper-evident log
Signing in
Multi-factor authentication, mandatory
Every staff member and referring doctor must enrol an authenticator app before their first session. There is no skip, no per-user exemption and no practice opt-out. Recovery is by backup codes or an administrator, never by email or SMS, so a compromised mailbox cannot bypass it. Patients can add two-step sign-in to their portal account.
Impossible-travel blocking
Each sign-in is compared with where the account's recent sessions were opened. A correct password from a place the account holder could not have reached since their last session is refused, recorded as a high-severity event, and the account owner is told. The speed and distance thresholds are security policies a practice can tighten.
Lockouts and guessing protection
Accounts lock after repeated failures, with escalating lockout periods. An address that fails against many accounts is blocked, repeated attempts must solve a bot challenge, and a correct password that arrives in the middle of a guessing attack raises an alert even though it succeeded.
Network allow-lists
A practice can limit staff sign-in, and continued use, to its own office and VPN addresses, with separate lists for the patient and referrer portals. The restriction is checked on every request, not only at sign-in.
Session controls
Sessions have configurable lifetimes and a cap on how many may be open per user. Users see their active sessions and can end any of them, and changing a password ends them all. A sign-in from a browser or device not seen in the last 30 days notifies the account owner.
Password policy and account hygiene
Passwords must be at least 12 characters and are checked against common patterns. Email addresses are verified before an account is used, and password expiry and inactive-account rules run on a schedule.
Protecting the data
Tenant isolation in the database
Every record carries the practice it belongs to, and PostgreSQL row-level security is on for every tenant table, so a query from one practice cannot return another's rows even if application code were wrong. A check in the release process fails any query that omits the tenant.
Encryption in transit
Browsers and portals connect over TLS 1.2 or higher with HTTP Strict Transport Security, and the application connects to its database over TLS. Images are never carried through Clarirad: the system links to the practice's PACS and the image bytes stay there.
Encrypted secrets
Credentials, authenticator secrets, integration keys and claim payloads are encrypted field by field with AES-256-GCM under a managed master key before they are stored.
Backups
The database is dumped before every release and backed up nightly as encrypted archives. A restore-verification tool rebuilds a dump into a throwaway database and checks it, so a backup is known to restore before it is needed.
Retention by region
How long each kind of record is kept is set per region. Clinical records and the audit trail are kept for the statutory period and are never purged automatically; operational data is purged on a schedule. A practice can lengthen a period, not shorten it.
Personal data export
A user can export the personal data held about them as a single download. Exports are rate-limited and every one is written to the audit trail.
Seeing who did what
An audit trail for every change
Every create, update and delete, every sign-in and every view of a patient record is written to the audit log with who, when, from where and what changed. Event types come from one catalogue, so the trail reads the same across the product.
Tamper-evident log
Audit rows are sealed into a SHA-256 hash chain: each row's hash includes the previous row's, so an edited, deleted or inserted row breaks the chain. A verification job re-checks the chain and the result appears in the practice's compliance report.
Roles and permissions
Access is granted by role, with a permission matrix administrators can review and per-user overrides that are themselves audited. Front-desk roles cannot search across practices; clinical and finance screens are gated separately.
Break-glass with oversight
Emergency access to a patient record outside the normal scope needs a stated reason, is limited to clinical and administrative roles, expires after 24 hours and notifies the practice's overseers. Every record opened under it is marked as such in the audit trail.
Privacy incident handling
Detectors such as a sign-in during a guessing attack or a break-glass use open a draft privacy incident. The module tracks the regulator's notification deadline for the region and drafts the notices; a person always reviews and sends them.
Security policies and dashboard
Lockout thresholds, session limits, location rules and more are security policies with a platform floor that a practice can tighten but not loosen. Administrators see failed sign-ins, blocked addresses and active sessions on a security dashboard.
Running the platform
Isolated regional deployments
Australia and Chile run as separate deployments with their own databases, keys and configuration. Nothing is shared between regions, and a practice's data never leaves its region's deployment.
Hardened edges
Every response carries a Content Security Policy, HSTS and frame-ancestors restrictions. Requests are rate-limited per address and per user, oversized bodies are refused, and addresses that abuse sign-in are blocked at the edge.
Secure development
Every commit is scanned for leaked secrets before it can be pushed, dependency advisories are gated against a reviewed baseline, and queries, migrations and schema are checked against both regions' databases before an image is built.
Compliance alignment
Controls are mapped to the Australian Privacy Principles and the Notifiable Data Breaches scheme, with HIPAA and PHIPA mappings maintained for North American deployments. The written control mapping is available to prospective customers on request.
Security Reporting
If you discover a security vulnerability, please report it responsibly to our security team at [email protected]. We appreciate responsible disclosure and will work with you to address any issues.
[email protected]