Security and data protection.

• Each hospital is a separate tenant. Every read of patient data is scoped to the tenant of the person making the request, in the query itself — not only in the code that decided to run the query.
• Platform staff hold no clinical role. Our own administrators cannot open a patient record in any hospital, and that is enforced by a test that walks every endpoint in the application and fails the build if a new one is added without being classified.
• A new clinical API surface cannot ship until someone has explicitly declared whether it is clinical. Silence defaults to blocked, not to allowed.

• Authentication uses a signed token held in an httpOnly cookie. A token is never accepted from a URL, because URLs end up in access logs, proxy logs, browser history and cross-origin referrer headers.
• Sessions can be revoked centrally, and a password change revokes every existing session for that user.
• Any clinical role can open any patient within their own hospital. This is deliberate: a doctor who cannot open a chart at two in the morning is a patient-safety incident, not a security success.
• Opening a record you are not assigned to is permitted and recorded as a break-glass access, with the person, the patient, the time and the source address. The control is accountability, not obstruction.

• Every access to patient data writes an audit record, including the accesses that were refused.
• Audit records are written independently of the operation they describe, so an action that fails and rolls back still leaves its trace. An audit trail that disappears whenever something goes wrong is of no use precisely when it is needed.
• Reports are versioned through a state machine — draft, signed, amended, void. A signed report is never edited in place; an amendment is a new version that names the one it supersedes.

• Patient identifiers are encrypted at column level at rest, in addition to disk encryption. Traffic is TLS-only, with HSTS.
• Backups cover the database and the stored genomic files together, because restoring one without the other produces a system that reports success while every result points at a file that no longer exists.
• Restores are tested, not assumed. A backup that has never been restored is a file, not a backup.
• Where a hospital's data is stored, how long it is retained, and what happens to it at the end of the engagement are terms of that hospital's data agreement, agreed before any patient record exists.

A security page that lists only controls invites the reader to assume the rest. These are the things we are asked for and do not have:

• We do not hold ISO 27001, ISO 13485, SOC 2, HIPAA or any other security or quality certification.
• We have not been audited by an independent security assessor. No penetration test has been carried out by a third party.
• We are not a CDSCO-licensed medical device manufacturer, and NexaMed is not an approved or certified medical device.
• We are a small team. Where a hospital's requirements exceed what we can honestly evidence today, we would rather be told at the start than discovered at the end.