Privacy

What we do with your data.

A plain-English overview. The architecture is built to make privacy the default, not an afterthought.

Last updated: May 19, 2026

What we store

• Provider data: organisation profile, staff identities, beds, vehicles, equipment, fleet records.
• Patient data: demographics, contact information, medical history shared via SOSTRAVEL grants, cases, transfers, documents, invoices, agreements.
• Operational telemetry: bed status changes, dispatch events, payment records — to enable real-time coordination with Tourist SOS Operations.

• All data lives in Supabase Postgres with Row-Level Security (RLS) enforcing organisation isolation. Each query is scoped to the caller's organisation_id by both the application code and the database.
• File uploads land in private Supabase Storage buckets. URLs are short-lived signed links — no public files for patient records.
• Encryption at rest and in transit. TLS-only network access.
• Audit columns (created_by_user_id, last_status_change_by_user_id, archived_by_user_id, etc.) on every mutable table.

• Provider org staff see only their own organisation's records. Cross-org reads are blocked by RLS.
• Patient data shared via the SOSTRAVEL QR Medical ID is governed by patient-controlled consent grants. Providers see only the fields the patient has chosen to share, and the grant can be revoked at any time.
• Tourist SOS Operations service-role can read provider data needed for claim processing and dispatch coordination — never for marketing or third-party resale.

• Smart Insights is opt-in per organisation, off by default. You toggle it on in Settings → Smart Insights.
• When enabled, we send a structured summary to a third-party analysis service: your enabled modules, counts (beds, vehicles, crew, patients, cases, transfers, documents), and the last 20 entries from case_activity_log with actor names. We do NOT send raw patient records, free-form clinical notes, document file contents, or anything from your storage buckets.
• Our analysis vendor's terms state customer traffic is not used to train models. We will publish the specific vendor and link their policy on request.
• Turning Smart Insights off stops the calls immediately. The free-tier heuristic suggestions resume with no degradation.
• We don't log the full prompts or responses on our side beyond what's needed for billing audit. We never resell this traffic for any other purpose.

• Patients carry a Tourist SOS Medical ID. They control which fields (allergies, medications, conditions, emergency contacts, etc.) are shared with providers via per-grant permissions.
• Consent forms (Consent to Treat, Financial Responsibility, Assignment of Benefits) are e-signed inside SOSPRO, with the typed name, timestamp, IP address, and browser captured for audit.
• Revoking a grant invalidates provider access to the shared data, and SOSPRO's UI reflects the change in real time.

• Provider organisations retain their records for as long as their account is active. We do not delete patient records on cancellation; they remain in your org's scope.
• Soft-deletes (is_archived, status='terminated', etc.) preserve the audit trail. True hard-deletes are restricted to ops admins for legal removal requests.
• On request, providers can export their data via Supabase. Patients can request a copy of their shared records through Tourist SOS Operations.

• We design for HIPAA-like principles: minimum-necessary access, audit trails, encryption, RLS isolation. Whether the framework that applies to your facility is HIPAA, GDPR, or local Thai PDPA, the same architecture supports compliance work.
• We do not currently sign Business Associate Agreements (BAAs) under US HIPAA. If your jurisdiction requires that, talk to us — we can discuss roadmap and certification.
• We never sell data. Tourist SOS Operations uses provider data only to coordinate dispatch and claims for the patient flows that touch the network.

Questions? Get in touch — we'll walk through the specifics for your facility.