Data Protection & Compliance Overview

All browser-to-server and app-to-server communication is exclusively over HTTPS (TLS 1.2+). The header Strict-Transport-Security: max-age=31536000; includeSubDomains is sent on every response. All Supabase database communication also uses TLS.

All data stored in the Supabase-managed PostgreSQL database is encrypted at rest using AES-256 at the infrastructure level (managed by Supabase / AWS). Database-level encryption protects against physical storage compromise; Row Level Security protects against logical access by unauthorised users.

• ✓ Password handling delegated entirely to Supabase Auth (bcrypt hashing, session token issuance, token refresh).
• ✓ Sessions managed via cookies using the Supabase SSR library, refreshed automatically at the middleware layer on every request.
• ✓ iOS app supports biometric unlock preference, persisted in the device Keychain per user account.
• ✓ Staff invitations use single-use expiring tokens; expired tokens are automatically rejected.

Access control is enforced at the database layer using PostgreSQL Row Level Security. RLS is enabled across all core identity, clinical, finance, rights, and governance tables. Every SELECT, INSERT, UPDATE, and DELETE query is automatically filtered by policies checking the identity and role of the requesting user. Key boundaries enforced at the database level:

• ✓A patient can never read another patient's data
• ✓Doctor access is layered: author records, same-facility continuity records, referral handoff records, and consent-gated baseline history
• ✓A nurse can read clinical data only for patients at their assigned facility (or via explicit patient consent)
• ✓A receptionist can read patient demographics only for patients at their assigned facility
• ✓A facility manager is limited to assigned-facility finance, inventory, and audit log access — with no access to patient clinical data
• ✓A doctor can only see their own invoices and insurance claims — cross-doctor finance access is blocked at the database level
• ✓A facility manager's finance access is limited to their assigned facility
• ✓Soft-deleted accounts are invisible to all staff immediately after deletion is requested
• ✓Administrators can manage users, facilities, roles, and governance workflows — they cannot access patient clinical data (medical history, consultation notes, prescriptions, vitals, referrals, or documents)

Security-definer functions are hardened with explicit REVOKE ALL FROM PUBLIC followed by explicit grants to required roles, preventing privilege escalation through stored procedure invocation.

An append-only audit log is maintained in the audit_logs table. Records can be inserted but never modified or deleted. Every entry captures the requester's IP address and User-Agent string, extracted server-side. Clinical reads, writes, data exports, account deletions, finance exports, and consent events are all logged. Administrators can view, filter, search, and export the full log from the Admin → Activity Log page.

A dedicated breach_incidents table records data breach investigations with severity classification, investigation status, OIC notification tracking, affected user counts, and data category inventories. The table is accessible only to administrators via RLS, and every create or update event is written to audit_logs.

A documented Breach Notification Policy covers: breach definitions, roles and responsibilities, 72-hour OIC notification procedures, individual notification requirements, and 2-year record-keeping obligations. Request a copy.

All patient-facing notifications — push (Firebase Cloud Messaging) and email (Resend) — are generated by database trigger functions that explicitly exclude clinical content. Notifications are additionally gated by:

• ✓ Active doctor-patient consent relationship (absent consent → notification suppressed)
• ✓ Active processing restrictions (restriction present → notification suppressed)
• ✓ Patient channel preferences (push, email, SMS toggles respected per patient)
• ✓ Deduplication keys prevent duplicate dispatch of the same notification event
• ✓ 30-day rolling purge removes notification outbox entries on schedule

• ✓ iOS screen privacy overlay: the app detects app-switcher backgrounding and screen capture events and renders a privacy mask, preventing PHI from appearing in screenshots or the app switcher preview.
• ✓ Persisted privacy settings: all privacy/security preferences (biometric, analytics sharing, screen protection) are stored in user_privacy_security_settings and synchronised across sessions.
• ✓ iOS Keychain storage: biometric unlock preferences are stored in the device Keychain, not in application storage or iCloud.
• ✓ Android privacy settings: privacy settings, data export, and account deletion workflows are available natively on Android via dedicated screens.

Exceeding a limit returns HTTP 429. This protects against brute-force login attacks and automated scraping.

Patient medical documents are stored in a private Supabase Storage bucket (patient-documents). Not publicly accessible. Path structure: {doctor_id}/{patient_id}/{filename} — enforced by storage policies. Doctors can access their own folder only; patients can read their own subfolder only.

All API routes validate required fields, string lengths, enum values, and UUID formats before any database operation. PostgreSQL parameterised queries prevent SQL injection.

The Supabase service role key bypasses Row Level Security and has full database access. It is used only in server-side API routes and the notification dispatch endpoint, and is never sent to the browser or included in any mobile application binary.