Security Statement

In short

• The strongest control in CliniPearls is architectural: there is no patient-identifiable dataset to lose. Identifiers are removed before anything is written to our database.
• Voice never leaves your device. Speech is transcribed by your own browser; no audio file is created or transmitted.
• Photographs are never stored. Images are processed in memory for text, then discarded.
• Data is hosted in the European Union (Republic of Ireland), encrypted in transit and at rest.
• Row-level security means one account cannot reach another account's records, even if the application itself has a fault.
• Your content is never used to train AI models — ours or our provider's.
• We never see or store your card details.

Report a security concern: contact@clinipearls.com

1. Why this page exists

This statement explains how CliniPearls protects the information you entrust to it. It is written for clinicians who need to satisfy themselves — and, where relevant, an employer's information governance team — that the Service handles data appropriately.

Read it alongside our Privacy Policy and Terms of Service.

2. Security by design: anonymisation first

The most important control in CliniPearls is not a technical setting. It is the shape of the system.

Patient identifiers are removed at the point of extraction, before any record is written to the database. When you capture a case by voice, photograph, or typing, the input is processed and stripped of identifiers first. Only the resulting anonymised, structured record is stored.

Two further design decisions reinforce this:

• Voice is transcribed on your device. Capture uses your browser's built-in speech recognition. Speech becomes text locally. No audio file is created, sent to our servers, or stored anywhere by us.
• Photographs are transient. Images are held in memory only long enough to extract the text, then discarded. The image is never written to our storage or database.

The practical consequence is that our database is designed to hold anonymised clinical learning content, not patient records. The blast radius of any incident is correspondingly small, because there is no store of recordings, photographs, or identifiable patient data to compromise.

This is a constraint we do not intend to relax.

Automated identifier removal is a strong control, not an absolute guarantee. You must not deliberately enter patient identifiers, and you should verify output before exporting or transferring it.

3. Where your data lives

• Our database, authentication system, and file storage run on Supabase infrastructure in the European Union (Republic of Ireland).
• Data is not stored in a jurisdiction lacking an adequacy decision or an equivalent safeguard.
• Some processing — AI extraction and payment handling in particular — involves providers that may operate outside the UK and EEA. Those transfers are covered by the safeguards described in our Privacy Policy.

4. Encryption

• In transit: all traffic between your device and the Service is encrypted using TLS 1.2 or above. HTTPS is enforced.
• At rest: stored data and uploaded files are encrypted at rest by our infrastructure provider using AES-256 or equivalent.
• Passwords: never stored in plain text. Stored only as salted cryptographic hashes, which means neither we nor anyone with database access can read or recover your password.

5. Access control and isolation between accounts

• Row-level security at the database layer. Every record — cases, pearls, uploads, tags, subscriptions — is bound to the account that owns it, and access policies are evaluated on every single query. One user cannot read another user's data even if the application layer has a bug. This is the single most important technical control in a multi-tenant system, and it is enforced below the application, not inside it.
• Private file storage. Evidence documents you upload are held in a private storage bucket that is not publicly addressable. Files are served only through short-lived signed URLs issued to the authenticated owner.
• Device-side isolation. Local caching is scoped to your user account and cleared on sign-out, so nothing persists into another account on a shared clinical computer.
• Least privilege internally. Administrative access to production systems is limited to those who need it operationally, protected by multi-factor authentication on the relevant provider consoles, and kept to the minimum necessary.

6. AI processing

• AI extraction, structuring, and anonymisation are performed via the Google Gemini API.
• We use a paid API tier under commercial terms that prohibit the use of your content to train Google's models.
• Processing is transient: content is sent, processed, and returned.
• We do not train any model on your content. We do not licence, sell, or share it for model development by anyone.
• API credentials are stored as encrypted secrets on the server side and are never exposed to the client application or your browser.

7. Payments

• Payments are processed by Stripe, a PCI DSS Level 1 certified provider.
• Card details are entered directly into Stripe-hosted components. We never receive, transmit, or store your card number, expiry date, or security code.
• We hold only the subscription metadata needed to determine your access status.

8. Availability, backups, and recovery

• Database backups are taken automatically by our infrastructure provider and are encrypted.
• Backups are retained for a defined period and used only for recovery.
• Uploaded files sit on redundant object storage.
• Deletion follows a soft-delete process, with permanent removal by an automated routine after a defined period. This means an accidental deletion can be recovered inside that window.

Because your case history accumulates and matters to your portfolio, also export anything critical to an imminent submission. The Service should not be your only copy of something you cannot afford to lose.

9. Monitoring and logging

• Application errors are captured to support rapid diagnosis and fixing.
• Authentication events and access logs are retained for a limited period for security and troubleshooting.
• Logging is configured to avoid capturing clinical content. Diagnostic data is kept to the minimum useful.

10. How we build

• Secrets and API keys are held in a secrets manager and never committed to source control.
• Changes are reviewed before release. Database schema and access-policy changes get particular scrutiny, because that is where a mistake would matter most.
• Third-party dependencies are kept current and security advisories affecting them are acted on.

11. Suppliers

Every third party with access to data is engaged under a written data processing agreement meeting UK GDPR Article 28 requirements, and is assessed for security posture and data location before use. The current list of suppliers and what each one does is maintained in our Privacy Policy.

12. If something goes wrong

If we identify a security incident we will:

• contain it, and assess its scope and severity;
• determine whether personal data has been affected;
• notify the Information Commissioner's Office within 72 hours of becoming aware, where the incident is likely to risk individuals' rights and freedoms;
• notify affected users without undue delay where the risk is high, explaining what happened, what was involved, and what to do; and
• establish the root cause and fix it.

13. Your part

Security is shared. Please:

• use a strong, unique password and do not reuse it elsewhere;
• keep your device locked, patched, and free of malware;
• sign out on shared or clinical computers;
• never deliberately enter patient identifiers, and check output before exporting;
• confirm your use of CliniPearls is consistent with your employer's information governance policy;
• tell us straight away if anything looks wrong.

14. Reporting a vulnerability

We welcome responsible disclosure. Email contact@clinipearls.com with enough detail to reproduce the issue.

Please do not publicly disclose it before we have responded, access or modify other users' data, or degrade the Service while testing. We will acknowledge your report and keep you updated.

15. What we do not do

• We do not sell your data.
• We do not share it with advertisers or data brokers.
• We do not train AI models on your content, and our providers are contractually barred from doing so.
• We do not store patient-identifiable data, by design.
• We do not store voice recordings or photographs.
• We do not store your card details.

16. Contact

Beverley Care Ltd
311 Regents Park Road
London N3 1DP

Security and privacy contact: contact@clinipearls.com