Encryption at rest
Live
Patient PII and all clinical notes, diagnoses, prescriptions and vitals are encrypted field-by-field with AES-256-GCM before they touch the database. A leaked database is ciphertext.
Trust & Security Center
Patient data, protected by design.
Hosvi is built for Indian hospitals with security and privacy as first-class requirements: encryption, strict tenant isolation, least-privilege access, and a compliance posture aligned to DPDP, ABDM and international standards.
AES-256 at rest, TLS in transit Tenant isolation Role-based access Designed to support DPDP obligations ABDM integration in progress
Security controls
What we do to protect data
Live implemented · Aligned by design · Roadmap in progress
Mapped control-by-control to the HIPAA Security Rule (NIST SP 800-66 Rev 2).
View full HIPAA control catalogEncryption in transit
Live
All traffic is served over TLS. HSTS, a strict Content-Security-Policy, X-Frame-Options and nosniff headers are set on every response.
Tenant isolation
Live
Every clinical record carries a clinicId. Each query is scoped to the signed-in user's hospital: one clinic can never read or write another's data.
Role-based access control
Live
Six roles (super-admin, admin, reception, doctor, pharmacist, patient) with least-privilege server-side checks on every route, not just hidden UI.
Strong authentication
Live
Patients authenticate by OTP (hashed at rest, attempt-limited, 5-minute expiry). Staff use password login with bcrypt. JWT secrets are enforced to 32+ chars in production.
Abuse & DDoS protection
Live
Per-IP and per-number rate limits on OTP, login, booking and payment endpoints; app-level throttles plus nginx edge limits documented for deployment.
Verified payments
Live
Razorpay orders are verified with HMAC-SHA256 signature checks and webhook signature validation before any appointment is confirmed. No client-trusted payment state.
Audit-ready actions
Live
Clinical and platform state transitions (queue, MAR give/hold, lab critical-value read-back, dispense, tenant suspend) are recorded with actor and timestamp.
Data minimisation
Live
Public queue boards expose only token numbers and timings; patient WhatsApp numbers are masked in every staff-facing log and response.
Backups & disaster recovery
Roadmap
Nightly encrypted database dumps with 14-day retention and off-box copy are documented; formal RPO/RTO targets and cross-region DR are on the roadmap.
Independent penetration testing
Roadmap
Annual third-party penetration tests and a coordinated vulnerability-disclosure programme are planned as we scale.
Breach notification readiness
Live
Incident runbook and patient/authority notification path are defined in line with India's DPDP Act timelines.
Compliance posture
Standards we align to
| Framework | Status | What it covers |
|---|---|---|
| India DPDP Act 2023 | Aligned | Consent, data-fiduciary duties, minimisation, breach notification. |
| ABDM / ABHA | Roadmap | ABHA linking and consent-first sharing built and tested against the ABDM sandbox; production milestones pending. |
| HIPAA safeguards | Aligned | Administrative, physical and technical safeguards for PHI (as a design reference). |
| ISO/IEC 27001 | Roadmap | ISMS control families implemented; formal certification in progress. |
| SOC 2 Type II | Roadmap | Security, availability & confidentiality criteria; audit planned. |
| NABL §7.5 (labs) | Live | Critical-value read-back acknowledgement enforced in the lab workflow. |
“Aligned” and “Roadmap” describe design intent and work in progress. They are not claims of active third-party certification. Formal certificates and our security whitepaper are available to customers under NDA on request.
Claim by claim
What each security claim rests on
Every claim on our sites maps to a row here. Where a milestone is not yet reached, the row says so.
| Claim | Supporting detail |
|---|---|
| Encryption | Patient identifiers and clinical fields (allergies, notes, diagnoses, prescriptions, vitals, addresses) are encrypted field by field with AES-256-GCM before they reach the database. Keys are held by the application environment, never in the database, and rotated by re-encryption. All connections use TLS. |
| Tenant isolation | Every clinical row carries the hospital's identifier. PostgreSQL row-level security policies are forced on every tenant table, and the application sets the tenant on each connection, so a query cannot read another hospital's rows even if the application code errs. |
| Backups | Daily encrypted database backups retained for at least 14 days. Restoration is exercised before each release that changes the schema. Formal recovery-time and recovery-point targets are provided to contracted customers. |
| Audit trail | Sign-ins, role and permission changes, clinical actions (queue, medication administration, critical-value read-back, dispensing, overrides), money movements and every family-access grant are recorded with actor, time and change. Hospital administrators and the platform team can read them; nobody can edit them. |
| ABDM | ABHA number and address linking, and consent-first record sharing, are built and tested against the ABDM sandbox. Production onboarding with the National Health Authority is in progress; we do not claim production approval until it is granted. |
| FHIR | Prescriptions are issued as FHIR R4 MedicationRequest bundles, and the record set (Patient, Encounter, Condition, MedicationRequest, Observation, DiagnosticReport, Invoice) exports to FHIR R4 on demand, alongside CSV. |
| Multi-factor authentication | Staff sign-ins complete with a one-time code to the registered mobile after the password; administrators can register a backup number. Patients sign in with a one-time code alone. Sessions time out after 15 minutes of inactivity. |
| Incident response | Vulnerability reports to security@hosvi.com are acknowledged within one business day. Affected hospitals are told what happened, what data was involved and what to do, and authorities are notified within the timelines India's DPDP rules require. |
| Data location | Application, database and document reading on Amazon Web Services in India. No patient data is stored outside India. |
| Subprocessors | Amazon Web Services (hosting, document reading), Razorpay (payments), Meta WhatsApp Cloud API (messages), and the SMS and email carriers the hospital configures. Listed below with their purpose and region. |
Trust Centre
The same answers on every Hosvi site
These topics are reachable from the Hosvi website and the hospital, patient and women's health sites. Claims are worded to what is in place today.
Privacy summary
We process patient data on behalf of the hospital that treats the patient. We do not sell it, and we do not use it for advertising. Reproductive-health events are never used for targeting.
Patient consent and family access
A family login never merges records. Minors are managed by a guardian; an adult joins a family only after answering a code on their own mobile, and can narrow or withdraw what the family sees at any time. Every grant and revocation is logged.
Children and guardian accounts
A child's record is opened by a verified parent or guardian. When the child turns 18, the record is handed over with a code on their own number, and sharing stops until they choose otherwise.
Women's and reproductive-health privacy
Cycle, fertility and pregnancy entries are excluded from family access by default, carry separate consent, and use neutral notification text. Sensitive actions ask you to sign in again.
Data hosting and residency
Hospital data is hosted on AWS in India. Document reading runs in India too. No patient data is stored outside India.
Encryption
AES-256 encryption at rest for patient identifiers and clinical fields, and TLS encryption in transit on every connection.
Tenant isolation
Every clinical row carries the hospital's identifier and the database enforces row-level isolation, so one hospital can never read or write another's data.
Authentication and MFA
Patients sign in with a one-time code to their mobile. Staff sign in with a password and a second factor. Sessions time out after inactivity.
Audit logging
Clinical and administrative actions are recorded with the actor, the time and the change, and cannot be edited afterwards.
Backups and recovery
Encrypted database backups are taken daily and kept for at least 14 days. Formal recovery-time and recovery-point targets are published to contracted customers.
Incident reporting
We acknowledge a reported vulnerability within one business day and notify affected hospitals and authorities in line with India's DPDP timelines.
Subprocessors
Listed below. Changes are announced to customers before they take effect.
Data export, correction and deletion
Hospitals export every record to FHIR R4 and CSV on demand. Patients ask their hospital to correct identity details; deletion follows clinical record-retention rules.
Clinical retention requirements
Clinical records are kept for the period the applicable regulations require, then deleted on the hospital's instruction.
ABDM integration status
ABHA linking and consent-first sharing are built and tested against the ABDM sandbox. Production onboarding is in progress; we do not claim production approval until it is granted.
Security contact and responsible disclosure
security@hosvi.com. We welcome responsible disclosure and never pursue good-faith researchers.
Transparency
Sub-processors
| Provider | Purpose | Data region |
|---|---|---|
| Razorpay | Payment processing (UPI, cards, netbanking) | India |
| WhatsApp Business API | Patient appointment & prescription notifications | Configurable |
| Amazon Web Services | Application and database hosting, document reading with Amazon Textract | India |
Security questions or a document request?
Hospitals evaluating Hosvi can request our security whitepaper, DPA and sub-processor list. Report a vulnerability responsibly and we'll acknowledge within one business day.