Trust
Your patients' data deserves serious answers.
Clinics don't get to outsource responsibility for patient data, under DPDP, they remain accountable. Our job is to make that responsibility easy to honour. Here is what we do, what we don't do, and what we're still working on.
Six commitments
The non-negotiables. If we ever fall short on one of these, we want you to be able to hold us to it.
Indian hosting for patient data
Clinic patient data will be hosted on Indian infrastructure, with no cross-border transfer. We're setting up that production hosting now, and no clinic stores patient data with us until it is live.
Encryption in layers
TLS in transit and encryption at rest, plus a second, column-level AES-256-GCM layer for Aadhaar and ABHA numbers.
No silent operator access
Our engineers don't read patient records by default. An operator-access log that the clinic admin can see for themselves is on our roadmap.
Audit trail by design
Changes to patient records, prescriptions and invoices are logged with the user, IP, timestamp and a diff, and every sign-in is recorded. The database only allows new audit rows, never edits or deletes.
DPDP-aligned consent + erasure
Versioned consent at registration; one-click right-to-erasure that redacts personal identifiers while preserving anonymised clinical continuity.
Written breach response
An incident-response runbook with notification templates: reporting to CERT-In within 6 hours, and notice to the Data Protection Board and affected clinics within 72 hours.
Where your data lives
Production hosting will keep the database, backups and logs in an Indian region. We're setting it up now and will name the provider and region here once it's live; until then no clinic's patient data is stored with us. Backups are encrypted, and we will publish retention and restore times after our first restore drill, not before. Where we stand on ISO 27001 and SOC 2 is set out below, and we will name a certification here only once it is issued.
- Indian-region hosting for production (being set up)
- Encrypted nightly backups
- A tested restore before the first clinic goes live
- Restore drills repeated on a schedule once live
How sensitive fields are protected
Disk-level encryption is the floor, not the ceiling. Identifiers that single a person out, Aadhaar, ABHA, get a second layer of column-level AES-256-GCM. Search on those fields uses a deterministic SHA-256 lookup hash, so a database dump on its own does not reveal the underlying value.
- AES-256-GCM at the column level for Aadhaar + ABHA
- SHA-256 lookup hash for indexed search without plaintext
- Encryption keys kept outside the database (moving to a managed KMS is planned)
- Postgres Row-Level Security so clinics can never see each other's data
Who can see your records
Clinic-staff access is governed by role-based permissions you configure, and the clinic admin can read the audit log of who did what. "A vendor employee read this record" is a question we want you to be able to answer in one click; the operator-access log that makes that possible is on our roadmap.
- Role-based access for clinic staff (Receptionist, Nurse, Doctor, Admin)
- Clinic-admin view of the audit log
- Planned: operator access only with the clinic's written authorisation
- Planned: an operator-access log the clinic admin can see
DPDP Act 2023 commitments
We treat DPDP as the baseline, not the goal. Consent is versioned and stored on the patient record. Erasure is a first-class admin action that redacts personal fields while keeping anonymised clinical continuity. Breach handling follows a written runbook: CERT-In within 6 hours, the Data Protection Board and affected clinics within 72 hours.
- Versioned consent capture at every new registration
- One-click right-to-erasure flow with audit
- Documented retention policy per data category
- Breach runbook with CERT-In (6-hour) and DPDP (72-hour) notification steps
Building, deploying, and operating securely
Security is enforced in the pipeline, not just at runtime. Every pull request runs typecheck, lint with a custom rule that flags un-tenanted database queries, and the full test suite, including a regression test that proves Row-Level Security blocks cross-tenant reads. Deploys follow a written runbook, and we rehearse a rollback before production launch.
- Custom ESLint rule blocking un-tenanted Prisma queries at PR time
- Cross-tenant RLS enforcement covered by a regression test
- Rate limits on sign-in and sensitive endpoints, plus account lockout after repeated failed logins
- Written deploy runbook; rollback rehearsed before production launch
Where we are, honestly
We'd rather under-promise than oversell certifications we haven't earned yet. Here is the actual posture today.
Built into the product today
TLS in transit, column encryption for Aadhaar/ABHA, append-only audit trail including sign-ins, role-based access, Row-Level Security with a regression test, custom lint rule, right-to-erasure, rate limits and login lockout, written breach runbook.
Currently being set up
Indian-region production hosting and a first restore drill; an external penetration test before the first clinic goes live; NHA sandbox access for ABDM (ABHA flows built on the v3 APIs, running in mock mode until then).
On the roadmap
Managed KMS for encryption keys; operator-access log visible to the clinic admin; SOC 2 Type II readiness; independent ISO 27001 certification; bug-bounty programme; customer-facing trust report (per-customer audit export).
Reporting a vulnerability
If you find a security issue, write to security@meddeskos.com. We acknowledge within one business day and respond with a triage outcome within five. We do not pursue good-faith researchers; please give us a reasonable window before public disclosure.
Want the deeper version?
The EMR buying guide and a 20-minute demo both go deeper. Pick whichever matches where you are.
See MedDeskOS running with your clinic's data.
A 20-minute screen share. We set up a sandbox with your service catalogue so you can click around without risk.