Your patients trust you with the most sensitive information in their lives. We take that responsibility seriously. Everything described on this page is on by default, for every clinic, from the first patient registered. Nothing to configure. Nothing to turn on.
Before we talk about encryption and servers, the most important thing to understand is this: MedSynq never gets between you and your patients.
Every message is sent as your clinic, under your name. MedSynq never contacts your patients directly, never markets to them, and never monetises their data in any form. Your patient list is the most valuable thing your clinic owns. It stays that way.
MedSynq identifies which patient needs attention and drafts the message. But every message is sent by your clinic, from your clinic's name, through your clinic's WhatsApp or phone. We operate no patient-facing channel of our own. We do not call, message, email, or notify your patients under the MedSynq name, ever, for any reason.
We will never send your patients promotions, offers, newsletters, or any communication created for our own benefit. Your patients are not our audience. They remain yours exclusively.
Your patients' personal information, contact details, treatment history, and clinical records are never sold to any third party. Never rented, never shared with advertisers, insurers, pharmaceutical companies, data brokers, or any other commercial entity.
Your patient list is isolated from every other clinic on MedSynq at the database level. We do not cross-reference, pool, or share patient identities between clinics. A patient who visits your clinic is never surfaced, suggested, or marketed to another clinic on the platform.
The intelligence that powers MedSynq is built on aggregate, anonymised patterns, never on your identifiable patient records. Your patients' names, histories, and clinical notes are never fed into any model, never used to improve any algorithm sold to anyone else.
All patient data belongs to your clinic, not to MedSynq. You can export it in full at any time. If you stop using MedSynq, you can take every record with you and request permanent deletion of everything we hold. We do not hold your data hostage.
We do not stand between you and your patients.
We stand behind you.
AES-256 is the Advanced Encryption Standard with a 256-bit key, recognised globally as the strongest widely-deployed symmetric encryption available. It is used by banks, defence organisations, and financial institutions. Every patient record, treatment note, clinical photo, prescription, and billing detail is encrypted before it is written to storage. The encryption key is managed separately from the data itself. In transit, everything moves over TLS 1.3. Encryption is on by default for every clinic from the moment their first patient is registered. There is nothing to configure and no option to turn it off.
Every create, update, delete, and read operation on patient data is written to an immutable audit log with the timestamp, the action type, the data affected, and the identity of the person who performed it. This applies to all roles: owner, doctor, receptionist, and assistant. If a staff member opens a patient record, it is logged. If they send a message, it is logged. If they change a treatment plan, the before and after states are logged. Logs are retained for a minimum of 12 months and are available to you on request at any time. In the event of a dispute or a data-rights request, you have a complete, verifiable record of every interaction with your clinic's data.
Row-Level Security (RLS) is enforced at the database level on every table that contains patient or clinic data. This means the database itself, not just the application code, rejects any query that attempts to access another clinic's records. Even if there were a bug in the application, even if a request were malformed, the database would return no data from another clinic's rows. No MedSynq employee can access your patient records without your explicit authorisation. No other clinic, and no API call, can cross the boundary between tenants. The isolation is structural and architectural, not a login restriction.
MedSynq's Clinic Health Score, benchmarking features, and action queue are powered by intelligence built on anonymised, aggregated clinic-level operational data, never on identifiable patient records. Your patients' names, contact details, diagnoses, treatment histories, and clinical notes are never used as training data, never used to fine-tune a model, and never shared with any external AI provider for any purpose. The intelligence layer and the patient data layer are architecturally separated. The model has zero access to patient tables. Your data runs your clinic. It does not improve anyone else's product.
We built MedSynq's infrastructure around one principle: patient health data stays in India.
All application data, patient records, clinical notes, billing, appointments, and documents are stored in Supabase's Mumbai region (AWS ap-south-1). Supabase is DPDP-compliant and operates dedicated infrastructure in India. Your patient data never leaves India in its primary form.
MedSynq uses Cloudflare for content delivery, DDoS protection, and web application firewall. Cloudflare processes non-sensitive data such as static assets, IP addresses, and TLS metadata at edge locations globally, which may be outside India. No patient health data or personally identifiable information is processed through Cloudflare. Cloudflare's DPA incorporates Standard Contractual Clauses.
Messages are sent through one of two models depending on your clinic's setup. If your clinic uses its own WhatsApp Business API, messages are sent directly from your account and never pass through MedSynq's infrastructure. If your clinic does not have its own API, MedSynq sends on your behalf via Meta's WhatsApp Business Platform, with your clinic displayed as the sender. In both cases, the patient sees only your clinic.
All payments are processed by Razorpay, which is PCI DSS Level 1 compliant and operates on Indian infrastructure. MedSynq does not store, process, or transmit full payment card data. We pass only the minimum required to Razorpay: bill amount, bill reference, and clinic identifier.
MedSynq is built around India's Digital Personal Data Protection Act, 2023. Not as a box to tick, but as a design principle.
MedSynq is designed to help your clinic comply with India's DPDP Act. Consent is captured at every data collection point with a timestamp. Patients have the right to access, correct, and erase their data. Your clinic is the Data Fiduciary for your patients' data, and MedSynq is your Data Processor. We have documented this responsibility in a Data Processing Agreement available on request.
Every patient who enters your clinic through MedSynq begins with a consent flow. They know what data is being collected, what it is used for, and that they can ask for it to be deleted at any time. Consent for personal data and consent for health data are captured as separate, explicit statements. Communication consent is granular, one toggle per channel, none pre-ticked.
We retain patient data for as long as your clinic requires, subject to legal minimums. Clinical records follow Dental Council of India record-keeping norms. Financial records are retained for 8 years as required by Indian tax law. When you cancel, your data is retained for a 30-day recovery window, then permanently deleted. You can request early deletion at any time.
Under the DPDP Act, we have designated a Grievance Officer to handle all data rights requests and complaints. Deepanshu Kumar can be reached at [email protected]. We acknowledge all requests within 48 hours and resolve grievances within 90 days.
Every clinic on MedSynq has its own isolated account with role-based access. The clinic owner controls who is invited, what role they hold, and what they can see.
Full access to everything: patient records, billing, analytics, health score, staff management, subscription, and data export. Only the owner can invite staff and change roles.
Access to their own patient records, appointments, casesheets, prescriptions, and lab orders. Cannot see billing, subscription, or other doctors' patients unless the owner grants additional permissions.
Access to the daily action queue, patient intake, appointment booking, and communication. Cannot see clinical records, billing totals, or analytics.
Limited access defined by the owner. Typically intake and scheduling only.
We hope it never happens. We plan as if it will.
In the event of a personal data breach, we follow a documented incident response process. We detect and contain the breach, notify the Data Protection Board of India without undue delay and submit a detailed report within 72 hours, and notify affected clinics where harm is likely, with a description of what happened, the data involved, the steps taken, and what you should do. Our Row-Level Security limits the blast radius of any incident by design. Supabase provides processor-level breach alerts. To report a suspected breach or security vulnerability, contact [email protected] immediately.
If you are a multi-chair clinic, a multi-location group, or a dental hospital with a compliance or legal team, we have documentation ready for you.
A formal DPA that sets out our roles and obligations as your Data Processor, available on request before you sign. Contact [email protected].
A full list of the third parties that process data on our behalf (Supabase, Cloudflare, Meta, Razorpay), with their roles, locations, and DPA status. Available on request.
For large clinic groups, we can provide a security summary to support your own compliance review. We do not grant on-site server access (which would compromise other clinics' data), but we provide documentation equivalent to an enterprise security review. Contact [email protected].
Security questions? Contact Deepanshu Kumar at [email protected]
Leave your details and our team will share the DPA with you within 24 hours.