1. Security principles

Psychiatry.Ink is designed around the following principles:

• minimise direct patient identifiers;
• keep patient identity mapping local where possible;
• use encryption in transit and at rest;
• restrict access by role and organisation;
• log relevant security and audit events;
• separate customer data where applicable;
• avoid sending unnecessary identifiers to AI providers;
• keep clinicians responsible for final review and approval of outputs.

2. Client-side (zero-knowledge) encryption

In the account-sync modes, sensitive data is end-to-end encrypted in the browser before it reaches our servers, using keys that never leave the clinician’s device:

• On first use, the app generates an RSA-OAEP-2048 key pair in the browser. The private key is stored only in the device’s local storage (IndexedDB) and is never sent to us; our servers receive at most the public key.
• Patient identifiers (name, date of birth) are encrypted with AES-GCM-256, and that content key is wrapped with the device’s public key.
• Case files (clinical notes, medication plans, findings) are stored and synced as ciphertext only. Age may sit inside the ciphertext; name and date of birth are not part of a synced case file.

Where the patient-to-case mapping lives

Each case is referenced by a random identifier (a UUID). The link between that identifier and the real patient — the name and date of birth — exists only as ciphertext: on the device in the encrypted vault; and, if the clinician enables encrypted account backup, on the server only inside a passphrase-encrypted blob.

Example. Our servers may store “case a1b2c3… has an encrypted snapshot of 12 KB, last updated 3 July.” They do not — and cannot — store that a1b2c3… is “Jane Doe, born 1980.” Resolving the identifier to a patient requires the private key on the clinician’s device (or, for the backup copy, the clinician’s recovery passphrase).

Scanned documents and PDFs

Uploaded PDFs and scans are stored encrypted on the clinician’s device (in the browser) and are not uploaded to our servers. They are never OCR’d or otherwise machine-read: a scan can carry identifiers in the image itself (letterheads, stamps) that cannot be reliably removed. The clinician can open and view the file and enters any structured data manually. Only text formats (DOCX, TXT, CSV, XLSX, JSON) are parsed.

What a server compromise would and would not reveal

Because the server holds ciphertext and non-identifying metadata only, a compromise of our infrastructure would reveal that an account exists, roughly how many cases it has (as random identifiers), and their sizes and timestamps; it would not reveal patient names or dates of birth, the identifier-to-patient mapping, the clinical contents of a case file, or any scanned document (which is not stored on the server at all).

The trust boundary is therefore the clinician’s device and recovery passphrase, not our servers. Loss of the device key or recovery passphrase can make encrypted data unrecoverable (see section 7), and the customer remains responsible for endpoint security.

3. Encryption

We use HTTPS/TLS for data in transit. Infrastructure providers may provide encryption at rest for stored data. Some local product components may use client-side encryption for sensitive mappings or local storage.

Encryption controls depend on the selected product configuration, browser, device, and infrastructure environment.

4. Access control

Psychiatry.Ink uses account-based access controls. Organisation features may include roles such as owner, admin, clinician, assistant, viewer, external consultant, or other role types depending on plan and configuration.

Users are responsible for protecting credentials, using strong passwords, enabling available authentication protections, and promptly removing users who should no longer have access.

5. Audit logging

The service may record audit and security logs such as login events, document actions, AI generation events, credit usage, access events, error events, and administrative actions. Audit log availability depends on plan and configuration.

6. AI data minimisation

AI features are designed to support drafting and documentation. Users should avoid unnecessary direct identifiers in prompts and source text. Where available, de-identification, privacy gates, or local-only modes should be used before sending clinical text to external AI providers.

AI output must always be reviewed by a qualified professional before clinical, legal, or administrative use.

7. Backups and recovery

Production infrastructure may include backups, snapshots, and recovery processes. Backup retention periods and recovery procedures depend on the final deployment configuration and customer plan.

Local encrypted vault data may not be recoverable by Psychiatry Ink Ltd if the user loses the local key, browser profile, or device storage.

8. Incident response

If we become aware of a security incident or personal data breach affecting customer data, we will investigate and notify affected customers where required by law and contract.

Security and data-protection contact:

data-protection@psychiatry.ink

9. Responsible disclosure

If you believe you have found a vulnerability, contact us before disclosing it publicly. Please include enough information to reproduce the issue. Do not access, modify, download, or disclose data that does not belong to you.

Report vulnerabilities to:

data-protection@psychiatry.ink

10. Current limitations

No software system is completely secure. Psychiatry.Ink should not be used for production patient data until the relevant deployment, DPA, sub-processor list, data-transfer safeguards, retention settings, access controls, and privacy configuration have been approved for the intended jurisdiction and organisation.