The Digital Personal Data Protection Act 2023 (DPDP) is the first general-purpose privacy law India has ever had. There is no "small clinic" exemption: a two-doctor practice in a Tier-3 town and a 200-bed corporate group are subject to the same obligations the day the rules take effect. The good news: the obligations are practical, not impossible. The bad news: most EMRs pre-2024 were not designed around them.
Here are the five things a clinic owner actually has to operationalise, and what an EMR should be doing for each one.
1. Consent capture at registration
Section 6 of the Act requires that consent for processing personal data be specific, informed, unconditional, and free. For a clinic, this means at registration, the patient (or guardian) signs off on what data you will collect, why, and for how long — with a version number against your notice. Verbal "okay" is not consent.
What your EMR should do: prompt the receptionist with a consent screen at every new patient registration, store the consent version + timestamp on the patient record, and let an admin regenerate the consent text if the notice changes (without overwriting historical consents).
2. Audit trail that names names
DPDP requires that you can answer "who accessed this patient's record and when". That includes vendor employees. If your EMR vendor's support staff can read your records, those accesses must be logged in a separate stream you can query — not buried in the same table as your reception staff's actions.
Watch out for vendors who can't separate operator-side audit from clinic-staff audit. Under DPDP you need to know that "a vendor employee read this record" — not just "someone did".
3. Right to erasure
Patients can ask you to delete their data. You have to honour that within a reasonable period. The wrinkle: clinical-continuity records (encounters, prescriptions) often must be retained for years under medical-record rules. The right answer is redaction with continuity: personally identifiable fields are wiped, but the anonymised clinical record stays so future care isn't affected.
Your EMR should give an admin a one-click erasure flow that does exactly that, and write the request itself into the audit log (who asked, when, who approved, what fields were redacted).
4. Encryption — at rest, not just "the cloud handles it"
Cloud-provider disk encryption is the floor, not the ceiling. Sensitive identifiers — Aadhaar, ABHA, anything that singles a person out — should have an extra layer of column- level encryption with keys rotated independently of the database. That way an attacker who gets a database dump still cannot read the most sensitive fields.
Ask your vendor: where is column-level encryption documented? If the answer is "TLS in transit" only, the answer is incomplete.
5. Breach notification, in 72 hours
CERT-In norms require breach notification within 72 hours of detection. That is not a timeline you build a runbook for during the breach. Your vendor should have a written incident-response procedure, a named owner, a notification template, and a regular drill. If they don't, you are exposed.
How MedDeskOS handles each
Every patient registration triggers a versioned consent screen. The audit log captures every change with the user, the IP, the diff, and a separate stream for operator-side access. Right-to-erasure is built into the admin console. Aadhaar and ABHA columns are encrypted with AES-256-GCM, lookup-hashed for indexed search. The incident-response runbook lives in our operations docs, with quarterly drills.
For a deeper walkthrough, our EMR buying guide unpacks every criterion your vendor should be able to answer. Or if you want to see the compliance screens in action, the 20-minute demo walks through them with your clinic's data.