How MedSynq handles your data.

1. Introduction and Scope

1.1 Who We Are

MedSynq ("MedSynq", "we", "us", or "our") is an intelligence and operations platform built for dental clinics operating in India. We provide a multi-tenant software-as-a-service platform that helps dental clinics manage patient records, appointments, clinical workflows, billing, communication, and business analytics, and that surfaces the actions a clinic should take to recover revenue and run more efficiently.

• Legal entity: Medsynq Solutions Private Limited
• Registered office: New Delhi, India
• General contact: [email protected]
• Grievance Officer: Deepanshu Kumar, [email protected]
• Website: medsynqsolutions.com
• Application: app.medsynqsolutions.com

Our technology stack includes Supabase (Mumbai region, ap-south-1), Cloudflare, the WhatsApp Business Platform operated by Meta, and Razorpay.

1.2 What This Document Covers

This Privacy Policy explains how MedSynq collects, processes, stores, shares, and protects personal data. Our platform serves two distinct groups, and both deserve complete clarity: dental clinic staff who use our platform directly, and patients whose data is processed through our platform by their clinics.

This policy applies to our marketing website, our web application, our backend processing, the communication channels (WhatsApp, SMS, email) sent through our platform, and our third-party integrations.

1.3 Key Definitions

1.4 The Three-Party Data Relationship

Our platform involves three parties:

• For patient data: the dental clinic is the Data Fiduciary, MedSynq is the Data Processor. The clinic obtains consent from patients; MedSynq provides the tools to manage consent, access, correction, and erasure.
• For clinic staff data: MedSynq is the Data Fiduciary for data collected directly from clinic owners and staff.
• For lead data: MedSynq is the Data Fiduciary for data collected through the marketing website before a clinic becomes a customer.

Section labels: [STAFF] applies to clinic staff, [PATIENT] applies to patients, [ALL] applies to everyone, [LEADS] applies to prospects.

2. Data We Collect [ALL]

2.1 Identity and Contact Data

Full name, mobile number, email, date of birth, age, sex, address, alternate phone, occupation, GSTIN, doctor registration number, and where collected for clinic KYC, Aadhaar or PAN. Source: user input. Classification: Personal Data, with government identifiers treated as Sensitive Personal Data.

2.2 Professional Data [STAFF]

Clinic name, registration number, specialisation, staff role, seat limit, subscription plan and status, and branding assets. Used for tenant identification, role-based access, and account management.

2.3 Patient Health Data (PHI) — Highest Sensitivity [PATIENT]

This is the most sensitive data on our platform. Under the DPDP Act, health data is Sensitive Personal Data requiring explicit consent and enhanced security. It includes medical alerts, allergies, pregnancy status, chief complaint, diagnosis, treatment names and status, tooth numbers and surfaces, anaesthesia details, pain scores, session and visit notes, prescriptions, clinical photos, X-rays and scans, and lab orders.

Critical commitment: Patient-identifiable PHI is never used to train any AI or machine-learning model. The Clinic Health Score is computed only from clinic-level operational metadata and audit responses, never from individual patient records. No patient's name, contact, diagnosis, or treatment history ever feeds the model. This is enforced architecturally.

2.4 Financial Data

Bill amounts and GST breakdowns, payment mode, payment reference numbers, Razorpay order tokens, receipt numbers, and subscription billing data. MedSynq does not store, process, or transmit full payment card data. All card transactions are handled by Razorpay, which is PCI DSS Level 1 compliant. We store only Razorpay order IDs and transaction references.

2.5 Technical Data [ALL]

IP address, User-Agent, device type, session logs, authentication tokens, rate-limit records, and cookie identifiers. Collected automatically for security, logging, and session management.

2.6 Communication Data

WhatsApp opt-in status, message logs (channel, content, status), message templates, email content, do-not-call flag, and preferred language.

Message storage commitment: When messages are sent through MedSynq, the conversation history (message content and patient replies) is stored inside your clinic's private, isolated, encrypted account so your clinic's own staff can see what was said. This history is visible only to your clinic. MedSynq does not read, mine, or analyse the content of these messages. Our intelligence and analytics features operate only on message metadata, that is, whether a message was sent, when, and whether a reply was received, never on the words inside.

2.7 Aggregated and Anonymised Operational Data (AI Features)

Aggregated appointment counts, chair utilisation, revenue aggregates, service-mix distribution, no-show rates, and audit responses. This data is used only for the Clinic Health Score and peer benchmarking. Individual patient records are never accessed, aggregated, or used in this algorithm. The score is derived exclusively from clinic-level operational metadata and the audit form.

3. How We Use Your Data

The DPDP Act mandates purpose limitation: data collected for one purpose cannot be used for another without fresh consent. Each category is used only for its stated purpose: patient registration and treatment, appointment and billing operations, follow-up communication (with consent), account and subscription management, security and fraud prevention, and legal compliance (GST and clinical record-keeping).

3.1 What We Do NOT Do With Your Data

4. Legal Basis for Processing

Under the DPDP Act, every processing activity must rest on either consent or a legitimate use.

4.1 Consent

Consent is obtained through clear affirmative action, never pre-ticked boxes, for: patient registration and storage of personal data, medical alerts and health data, WhatsApp and SMS and email communication, and marketing messages. Clinic staff consent to the Terms of Service and this Privacy Policy at account creation. The audit form captures DPDP consent with a timestamp. [confirm at launch: granular patient-registration consent checkboxes are live]

4.2 Legitimate Uses (No Consent Required)

We rely on legitimate uses for: data voluntarily provided by a lead for a specified purpose, processing health data in a medical emergency, security and fraud prevention (rate limiting, IP logging, audit trails), and legal compliance (GST retention, clinical record retention).

4.3 Consent Withdrawal

You may withdraw consent at any time, through a process as easy as giving it. WhatsApp and SMS can be stopped immediately by replying STOP or toggling off in the patient profile. Marketing can be stopped via the unsubscribe link. Data-processing withdrawal is handled by your clinic or our Grievance Officer. Withdrawal does not affect processing that already occurred and does not override legally required retention (such as financial records).

5. AI and Algorithmic Processing

5.1 What the Clinic Health Score Is

The Clinic Health Score evaluates a clinic's operational health across six dimensions: Conversion, Retention, Operations, Acquisition, Communication, and Business Maturity. It is presented relative to peer clinics with similar characteristics (city tier, volume, revenue band, dominant specialty).

5.2 What Data Feeds the Score

Only the 39-question clinic audit (self-reported, no patient PII) and anonymised operational aggregates such as no-show rates and chair utilisation. No patient PII is ever involved.

5.3 What Never Feeds the Score

Patient identity, patient health data, individual clinical records, individual billing records, and individual appointment records are all excluded by design.

5.4 Automated Decision-Making

The Clinic Health Score does not make automated decisions with legal or significant effects on patients. It is a business tool for clinic owners only. Patients are never scored, evaluated, or profiled, and the score has no bearing on their treatment, eligibility, insurance, or rights.

5.5 Future AI Features

Any future AI feature that processes personal data will be disclosed here before activation, will be opt-in, and will be documented with clear explanations of its inputs.

6. Data Sharing and Third Parties

6.1 Processor Table

6.1a WhatsApp Dual Delivery Model

MedSynq delivers WhatsApp communications through one of two models, depending on your clinic's setup:

Model A — Your clinic uses its own WhatsApp Business API. Messages are sent directly from your clinic's own WhatsApp Business account. Delivery does not pass through MedSynq's WhatsApp infrastructure; MedSynq only triggers the send. Storage and handling of these messages follow your own WhatsApp configuration.

Model B — Your clinic does not have its own WhatsApp Business API. MedSynq sends the message on your behalf through the WhatsApp Business Platform operated by Meta, displaying your clinic as the sender. In this model the message routes through MedSynq's WhatsApp infrastructure via Meta.

In both models, the patient experiences the message as coming from your clinic, never from MedSynq, and MedSynq never sends marketing or independent communications to your patients.

6.2 Razorpay Detail

Razorpay receives only the minimum needed to process a payment: amount, currency, receipt reference, and note fields (bill_id, patient_id, tenant_id, description). It does not receive patient name, mobile, clinical details, any PHI, or full card numbers. Razorpay is PCI DSS Level 1 compliant and acts as a Data Processor.

6.3 Cloudflare Cross-Border Disclosure

Cloudflare operates a global edge network. When a user accesses our site or app, the request may route through Cloudflare's nearest edge location, which may be outside India. Cloudflare processes IP addresses, TLS metadata, and cached static assets, never PHI. Its DPA incorporates Standard Contractual Clauses. We disclose this flow and rely on contractual safeguards as the lawful basis.

6.4 Future Integrations

SMS gateway and email service, if not live at launch, will require DPAs before activation. [confirm at launch which of these are live]

7. Cross-Border Data Transfers

7.1 Current Data Residency

All application data, file storage, authentication data, and edge functions are hosted in Supabase's Mumbai region (ap-south-1) in India. Marketing site and app hosting use Cloudflare's global edge. [confirm at launch: Supabase backup/replication region stays in India]

7.2 Cross-Border Flows

The only data leaving India is non-PHI: Cloudflare CDN caching (static assets, IP addresses) and Google Fonts loading (IP, User-Agent). Razorpay payment processing is on Indian infrastructure.

7.3 Data Localisation Commitment

All primary databases containing patient PHI are hosted in India. We have no plans to replicate patient PHI outside India. Cross-border flows are limited to non-PHI CDN caching and font delivery. Under DPDP Section 16, transfers are permitted to all countries except those restricted by Government notification; as of this update, no countries are on the restricted list, and we will update this disclosure if that changes.

8. Data Retention

8.1 Retention Schedule

8.2 Retention Exceptions

Data marked for deletion may be retained beyond the standard period if required by a court order, an ongoing grievance or dispute, legal proceedings, or Indian tax law. In such cases, the data is isolated from active processing and restricted to authorised compliance personnel.

8.3 Deletion Procedures

Erasure requests follow a soft-delete, then a 30-day recovery window, then permanent cryptographic erasure, with backups overwritten within 90 days. [confirm at launch: whether automated purge jobs are live, or deletion is handled manually via the Grievance Officer at launch]

9. Your Rights Under the DPDP Act

9.1 Right to Access (Section 11)

You can obtain a summary of the data we hold about you, the purposes and recipients of processing, and a description of your rights. Patients request this through their clinic or our Grievance Officer; staff through account settings. We acknowledge within 7 days and respond within 30 days (extendable to 60 for complex requests). The first request in any 12-month period is free.

9.2 Right to Correction and Completion (Section 12)

You can request correction, completion, or updating of your data. Patients contact their clinic; staff edit their profile. When we correct data, we intimate the correction to relevant processors.

9.3 Right to Erasure (Section 12)

You can request erasure where consent is withdrawn and no other legal basis exists, or where the data is no longer necessary. Erasure does not apply where retention is legally required (GST, clinical records), where there are ongoing legal proceedings, or where data is needed for legal claims. [confirm at launch: whether the patient "request deletion" feature is live, or handled manually via the Grievance Officer]

9.4 Right to Grievance Redressal (Section 13)

You can complain to our Grievance Officer. We acknowledge within 48 hours and resolve within 90 days. If unsatisfied, you may appeal to the Data Protection Board of India.

9.5 Right to Nominate (Section 14)

You can nominate another person to exercise your rights in the event of death or incapacity, by written nomination with identity verification.

9.6 Right to Withdraw Consent (Section 6(7))

Withdrawal is as easy as giving consent. WhatsApp, SMS, and email can be stopped immediately; data-processing withdrawal is handled within 30 days. Withdrawing consent may limit services that depend on that data.

10. Cookies, Analytics, and Error Tracking

We use strictly necessary cookies (authentication, security, session) which are exempt from consent. We do not use marketing or advertising cookies, and we do not sell or share any data for advertising. Third-party cookies may be set by Cloudflare (security), Google Fonts (delivery), Supabase (authentication), and Razorpay on its payment pages.

Product analytics (in-app). Inside the MedSynq web application we use PostHog (hosted in the European Union) to understand which features clinics use and where users click, so we can improve the product. This is processed on a legitimate-interest basis and is keyed to your clinic and user account by internal identifiers only (a user UUID, tenant ID, and role). It never includes patient information: page text and form inputs are masked before capture, we do not record sessions, and patient-bearing fields are never sent. We honour your browser's Do-Not-Track setting, and any signed-in user can switch product analytics off at any time under Settings → Privacy in the app.

Error tracking. We use Sentry to capture technical errors in the application so we can diagnose and fix them quickly. Error reports are scrubbed of patient data before they leave your browser and are tagged only with operational context such as the tenant ID and the user's role, never patient identifiers or clinical content.

11. Children's Data

The DPDP Act defines a child as anyone under 18. We do not knowingly process a child's data without verifiable parental or guardian consent, except for medical emergencies or legal compliance. Because dental clinics treat minors, our platform collects guardian details and consent at registration for any patient under 18, applies the highest security tier to children's health data, and never uses children's data for tracking, advertising, or AI training. Marketing messages are suppressed for patients under 18. If we discover a child's data collected without consent, we suspend processing, delete within 72 hours unless legal retention applies, and notify the clinic.

12. Data Security

12.1 Technical Measures

AES-256 encryption at rest, TLS 1.3 in transit, Row-Level Security enforcing tenant isolation on every table, bcrypt password and OTP hashing, IP and email rate limiting, input sanitisation, short-expiry JWT authentication, 30-minute idle auto-logout, full audit logging of every create, update, and delete, optional multi-factor authentication for clinic owners, and encrypted backups with 90-day rotation.

12.2 Organisational Measures

Role-based access control across four roles (owner, doctor, receptionist, assistant), an owner-controlled staff invitation system with expiring links, export restrictions with logging, a documented incident-response plan, vendor risk review, data localisation of all PHI in Supabase Mumbai, and architectural enforcement that the health-score algorithm has zero access to patient tables.

13. Data Breach Notification

A personal data breach is any unauthorised processing, accidental disclosure, acquisition, sharing, alteration, destruction, or loss of access to personal data. On discovering a breach we detect and contain, notify the Data Protection Board of India without undue delay and submit a detailed report within 72 hours, and notify affected Data Principals where harm is likely, with a description of what happened, the data involved, likely consequences, the steps we have taken, the steps they can take, and contact details. Our audit logs and Row-Level Security limit the scope and blast radius of any incident, and Supabase provides processor-level breach alerts. [confirm at launch: automated breach-detection and notification templates]

14. Grievance Officer

Under DPDP Section 13, we have designated a Grievance Officer.

MedSynq is not currently a Significant Data Fiduciary under the DPDP Act, and a dedicated Data Protection Officer is therefore not legally required at this stage. Our Grievance Officer fulfils all data-protection responsibilities. If MedSynq is designated a Significant Data Fiduciary in future, we will appoint a dedicated Data Protection Officer situated in India as required by law.

15. Changes to This Policy

We may update this policy to reflect changes in our practices, technology, or legal requirements. For material changes (new data uses, new processors, reduced rights) we will update the "Last Updated" date, email all registered clinic accounts at least 14 days in advance, and display a notice in the app and on the site. Non-material changes take effect on posting. Continued use after a material change takes effect constitutes acceptance.

16. Contact Us

If you are unsatisfied with our response to a grievance, you may lodge a complaint with the Data Protection Board of India.