Security & compliance

This page describes the controls Medixar has in production today. We update it as our security posture evolves. For the formal contractual documents, customers can request our security questionnaire or DPA (Data Processing Addendum), and discuss a BAA (Business Associate Agreement) by arrangement for international-patient programmes, by writing to [email protected].

1. Architecture

Tenant isolation

Every clinic, hospital, or chain that signs up gets its own logical tenant. Inside our shared PostgreSQL cluster, each row in every business table carries a tenant_id column, and every row is protected by PostgreSQL row-level security policies. The application layer cannot, by construction, ever return data belonging to another tenant — even a logic bug in our code is caught by the database before the row leaves the server.

Cross-tenant queries (used only for our own platform admin dashboards) run on a separate superuser connection and are explicitly audited.

Encryption

• At rest — AES-256, full-disk encryption on database volumes and on encrypted backups.
• In transit — TLS 1.3 for all client-server traffic. HSTS enforced on app.medixar.ai and medixar.ai.
• Backups — encrypted snapshots written to object storage; the encryption keys are stored in AWS KMS with strict access control.

Authentication & authorisation

• Bcrypt password hashing (cost factor 12).
• JWT access tokens (15-minute lifetime) with rotating refresh tokens (7 days). A successful logout or password change revokes all active refresh tokens immediately.
• Account lockout after five failed login attempts; 15-minute cool-down.
• Role-based access control with 200+ fine-grained permissions across modules; tenant administrators decide who can read or modify what.
• Optional facility / department / org-unit scope on every endpoint, so a doctor in one branch never sees another branch's patients.
• "Break-the-glass" emergency access — when a clinician needs to reach a record outside their normal scope, they record a written justification, the action is logged, and the privacy officer reviews it within 72 hours.

Clinical and financial correctness

The homepage describes these in clinicians' terms; this is how they are built.

• Optimistic-locked autosave on clinical records — a save carries the version it was based on, so a concurrent edit is detected and surfaced instead of silently overwriting another clinician's work.
• Fail-closed drug-interaction checks — if the interaction service cannot answer, the prescription is held rather than signed unchecked.
• Compare-and-swap slot booking enforced in the database, so two receptionists booking the same slot at the same moment cannot both succeed.
• Decimal-precise money — amounts are stored and computed as exact decimals, never floating point, so totals reconcile to the paisa.
• Atomic invoice and prescription numbering — numbers are allocated in the same transaction as the document, so a series never skips or repeats.
• HMAC-verified, idempotent payment-gateway webhooks — a forged notification is rejected, and a duplicate delivery cannot mark a bill paid twice.

2. Audit & observability

• Every mutation to a clinical or financial record emits a domain event with the user, tenant, timestamp, and reason. These events feed an append-only audit log at the database level — even our own engineers cannot retroactively edit it.
• Every read of Protected Health Information (PHI) on a finalised record is logged with the same metadata, satisfying HIPAA §164.312(b).
• Logs are retained for seven years to meet compliance requirements.
• Application metrics, traces, and operational logs go to Prometheus, Grafana, and a structured JSON log pipeline. PHI is never used as a metric label or trace attribute — every observability surface is built to be safe to share with engineers and ops staff.

3. Data residency

Production data for Indian customers is hosted in AWS Mumbai (ap-south-1). Daily encrypted backups remain in the same region. Sub-processors that operate outside India (OpenAI and Anthropic for AI inference, Stripe for international payments) are governed by Standard Contractual Clauses; PHI sent to AI providers is processed transiently and is contractually excluded from training their models.

4. Compliance posture

Certificates (PDF): ISO 9001:2015, No. 1016Q663226 · ISO/IEC 27001:2022, No. 1016I663326

5. Vulnerability management & testing

• Dependencies are scanned on every build; we ship no critical or high-severity known vulnerabilities to production.
• Static analysis (TypeScript strict mode, ESLint security rules) runs on every commit.
• Automated tests verify multi-tenant isolation — every release is gated on integration tests that try, and fail, to read another tenant's data.
• External penetration testing is scheduled annually with a CERT-In empanelled vendor; the most recent report and remediation summary are available under NDA.

6. Incident response

• An on-call engineer and the security lead are paged on any production incident matching defined alert rules (latency SLO breach, error rate > 1%, security-sensitive events such as break-the-glass activation, role escalation, or webhook signature mismatch).
• A documented runbook governs detection, containment, eradication, recovery, and lessons-learned.
• For incidents that affect customer data, we notify the affected customer's named security contact within 72 hours of confirmed impact, with detail expanded as the investigation completes — meeting HIPAA, DPDPA 2023, and IT Rules requirements.
• If you discover a vulnerability, please report it to [email protected]. We commit to acknowledging within two business days and to keeping you informed through remediation. We do not pursue legal action against good-faith researchers who follow coordinated disclosure.

7. Personnel security

• Background checks for engineering staff who may handle production data.
• Principle of least privilege — production access is gated, audited, and granted per change rather than as standing permission.
• Mandatory laptop encryption, password manager, and MFA for every engineer.
• Annual security and privacy training for the whole team.

8. Business continuity

• Recovery time objective (RTO): 4 hours for the production application.
• Recovery point objective (RPO): 5 minutes for the production database (point-in-time recovery enabled).
• Backups are tested by restore on a regular cadence — a backup that has not been restored is not a backup.

9. Sub-processors

The current list of sub-processors is published on our privacy policy and updated when it changes. Customers can subscribe to advance notice of sub-processor changes by writing to [email protected].

10. Documents available on request

• Business Associate Agreement (BAA) — by arrangement for international-patient programmes.
• Data Processing Addendum (DPA) — covering DPDPA 2023 and Standard Contractual Clauses for cross-border transfer.
• Security questionnaire response (CAIQ-style).
• Penetration testing summary (under NDA).
• Subprocessor list and notification process.

Email [email protected] to request any of the above or to schedule a security review with the founding team.