The DPDP Act and Your Dental Clinic — What Actually Changes for Patient Records

Most dentists first hear about the Digital Personal Data Protection Act from a software salesperson, which is unfortunate, because the salesperson usually gets the most important part backwards.

Here it is, plainly: your clinic is the Data Fiduciary for your patients' data. Your software vendor is a Data Processor acting on your instructions. The obligation to patients is yours. You can delegate the work; you cannot delegate the responsibility.

General information, not legal advice. DPDP rules and enforcement continue to develop, and anything with real consequences attached deserves a lawyer who knows your situation.

Why that distinction matters more than any feature

If a vendor tells you their product "makes you DPDP compliant", they are overselling. Software can give you the tools — consent records, an audit trail, a deletion path, access controls. It cannot give you the practice: who at your clinic is allowed to see what, what you tell patients, and what you do when someone asks for their data back.

A clinic with excellent software and no process is not compliant. A clinic with a paper register and a careful process is closer than it looks.

The four things that actually change at the desk

1. You have to tell patients what you collect and why

Not buried in a form nobody reads. A plain notice, in a language the patient actually speaks, covering what you hold, why, how long, and how they can ask about it. For most Indian clinics that means the notice needs to exist in the local language, not only English.

2. Consent has to be specific, and withdrawable

Consent for treatment is not consent to send marketing messages. If you want to send recall reminders or promotional offers, that is a separate ask, and the patient must be able to withdraw it as easily as they gave it. In practice that means recording, per patient, that they agreed and when — and honouring it when they say stop.

The "as easily as they gave it" part is the one clinics fail. If opting in was one tap and opting out requires phoning the clinic during working hours, that is not equivalent.

3. Patients can ask for their data — and for it to be erased

A patient can ask what you hold about them and, in defined circumstances, ask you to delete it. You need a route for that request to reach a named person, and a way to actually action it.

Note the tension: erasure sits against medical-record retention obligations, which do not disappear because someone asked. You cannot delete a clinical record you are required to keep. Knowing which is which for your practice is exactly the sort of thing to settle once with a professional rather than improvise when the request arrives.

4. You need to know where the data goes

If your software processes or stores data outside India, your patients' data leaves the country. You are the one disclosing that, because you are the Fiduciary. Which means you need your vendor to tell you plainly, in writing, where processing happens — and many will not.

What to ask a vendor, before you sign

Four questions. Ask them by email, so you have the answers in writing.

1. Will you sign a Data Processing Agreement? A vendor who will not is telling you they have not thought about this. This is the single most useful filter.
2. Where is the data processed and stored, including backups? "In the cloud" is not an answer. If any of it is outside India, you need to know so you can disclose it.
3. How do I export everything for one patient, and how do I erase them? Ask for the actual steps, not a reassurance.
4. Who are your sub-processors? Your email provider, your storage provider, your hosting provider — they are all handling your patients' data downstream.

What good looks like in the software

Concretely, the things worth having:

• Role-based logins, one per person. Shared accounts destroy your audit trail; if everyone is "reception", nobody is accountable.
• A recorded consent state per patient, with a timestamp, for anything beyond treatment.
• A working export — CSV or otherwise — so a patient access request is a five-minute task.
• An erasure path that handles the retention tension rather than pretending it does not exist.
• Encryption in transit, and at rest for backups and stored files. Ask specifically about backups; they are the copy people forget.

The uncomfortable, practical truth

Most small clinics will not be audited tomorrow. The realistic near-term risk is not a regulator — it is a disgruntled patient or a former employee who knows exactly which corner you cut, and a complaint that arrives with specifics.

The cheapest insurance is the boring stuff: individual logins, a written notice patients can actually read, a named person who handles requests, and a vendor who put their answers in an email you kept.

Where we stand

We tell clinics the same four answers we suggest you ask for. We will sign a DPA. Some processing happens outside India, and we say so in our documentation precisely because you cannot disclose to your patients what we have not disclosed to you. Logins are per-person by role. Consent state is recorded per patient with a timestamp.

We are not going to tell you our software makes you compliant. It does not. It gives you the tools; the practice is yours.