Security

1. Tenant isolation

Every laboratory’s data lives behind row-level security in PostgreSQL. Each table that holds laboratory data carries a policy that admits only rows belonging to the laboratory of the current request, and the policy is forced: the application’s database role cannot bypass it, and a query that forgets to filter returns nothing rather than everything. The set of protected tables is checked in continuous integration on every change, so a new table cannot ship unprotected.

2. Access within a laboratory

• Roles and permissions. Each staff member holds a role and an explicit set of permissions. Screens, navigation and every server action check the permission, not just the screen.
• Branches. A staff member works only at the branches an administrator has assigned. The assignment is the grant; switching site is navigation among granted sites and never widens access. Administrators reach every branch of their own laboratory by role.
• The Console — laboratory configuration, staff, catalogue, prices, reports — is available to administrators only, enforced at each action.

3. Identity and sessions

• Passwords are stored as bcrypt hashes (cost 12); we cannot read them. Sign-in and signup are rate-limited per address and per account.
• Sessions are signed, HTTP-only cookies. On every request the session is re-checked against the database: a deactivated account, a changed role or a removed branch takes effect on the next request, not when the session expires.
• New accounts must set their own password before use; invitations and resets use single-use, expiring tokens stored only as hashes.
• A suspended or expired laboratory is refused at the server, not only in the interface.

4. Audit trail

Actions on records — registration, requests, specimen events, result entry, validation, amendments, delivery, payments, refunds, critical-value acknowledgements, staff and branch changes, site switches, support-access decisions — are written to an audit table that records who, what, which record and when. Result amendments keep the previous value. The trail is part of the laboratory’s record and is exportable.

5. Support access

Adeva staff have no standing read access to a laboratory’s records. When support needs to look, the laboratory’s administrator approves a support-access grant in the Console. The grant is time-limited and read-only, its use is recorded in the laboratory’s audit trail, and the administrator can revoke it at any time.

6. Infrastructure

• All connections use TLS. The product is served over HTTPS only.
• Application and database run on Railway; uploaded files are held in Cloudflare object storage and served only through authenticated, tenant-checked routes.
• Production, staging and development are separate environments with separate databases and credentials. Production data is never copied into staging or development; test fixtures are generated.
• Backups are managed by the hosting provider; deleted data leaves backups within its retention cycle.
• Errors are reported to Sentry with stack traces and request metadata, not record contents.

7. Change and release

Every change passes lint, type-check, the row-level-security coverage check and a build in continuous integration, is deployed to staging first, and reaches production only after a human approval. Security probes run against staging as real users, including attempts to reach another laboratory’s or another branch’s data, before a release is approved.

8. Reporting a vulnerability

If you believe you have found a security issue, email [email protected] with enough detail for us to reproduce it. We acknowledge within two working days, keep you informed, and do not pursue good-faith researchers who respect patient privacy and give us reasonable time to fix.