The DPDP Act for clinics: a plain-language checklist

This is a practical summary written by software people, not lawyers. It is a starting point for a conversation with your own advisor, not legal advice.

Where a clinic stands

Under the Digital Personal Data Protection Act, whoever decides why and how personal data is processed is the data fiduciary. For a clinic, that is the clinic. Your software vendor is a data processor acting on your instructions.

That distinction decides who answers the phone. When a patient asks what you hold about them, or asks you to delete it, the obligation is yours. The vendor's job is to give you the tools to answer — an export, a correction, a deletion — not to answer for you.

The checklist

1. Collect only what you need

Every field on the registration form should have a reason. A patient's occupation, marital status or full address may be clinically relevant in your speciality and pure liability in another. If you cannot say why you are collecting something, remove the field.

2. Tell people what it is for

A notice, in plain language, in English and the languages your patients actually read. It has to say what you collect, why, who else sees it, and how to complain. A printed card at the front desk and a page on your website is the usual arrangement.

3. Separate treatment from marketing

Processing necessary for treatment stands on its own footing. Sending a patient a WhatsApp reminder, a birthday message or a health-camp announcement does not — that needs consent, given freely, and recorded.

In practice: one tick box for appointment and report notifications, recorded against the patient with a date. Not a pre-ticked box, and not buried in a consent-to-treat form.

4. Make withdrawal as easy as consent

The Act is explicit that withdrawing consent must be as easy as giving it. If consent was one tick at the desk, withdrawal cannot require a written application. And it must take effect before the next message is composed, not merely before it is sent.

5. Be able to answer an access request

A patient may ask for a summary of what you hold and who it has been shared with. You need to be able to produce that — the record, the visits, the prescriptions, the invoices — without a week of work. If your software cannot export one patient's full history, you cannot meet this obligation.

6. Be able to correct and to erase

Correction is straightforward: a wrong date of birth gets fixed. Erasure is the harder one, because it collides with medical-record retention. Where you are required by law to keep a record, you keep it; where you are not, you erase on request. Know which is which for your speciality, and write the rule down before somebody asks.

7. Keep it only as long as you need it

Retention obligations for medical records vary by state, speciality and context — commonly three years for outpatient records, longer for medico-legal cases. Set a policy, and make sure your vendor's own deletion schedule does not quietly override it.

8. Have a breach plan before you need one

A personal data breach must be reported to the Data Protection Board and to affected people. Decide in advance who makes that call, who writes the notice, and how you would find out at all. "We would notice" is not a plan.

9. Put the vendor relationship in writing

Your contract with your software vendor should state, plainly:

• they process only on your instructions;
• where the data is stored;
• who their own sub-processors are;
• that they tell you about a breach quickly;
• that you can export everything at any time;
• what happens on termination, and when they delete.

10. Lock the doors you control

An individual login for every person, roles that limit what each can see, no shared passwords, and no clinical records on a personal WhatsApp. Most real breaches at a clinic are not sophisticated — they are a shared login and a laptop left open.

What to ask your software vendor

• Where is my patient data physically stored?
• Can another clinic on your system ever see my records, and what enforces that?
• Do you use my data for anything other than running my clinic?
• Can I export a single patient's full record on request?
• Do you check a patient's opt-out before composing a message, or before sending it?
• How quickly would you tell me about a breach?

Clinikr's security page answers each of those concretely. In the product itself: consent is recorded per purpose with a date and a method rather than as a single tick; one button produces a patient's entire record for an access request; requests go into a register with a thirty-day clock; retention periods are stated against the statutory minimums; and there is a breach register, because deciding who reports a breach during a breach is too late.