The Digital Personal Data Protection Act is law. For hospitals, that means consent flows, India data residency, 72-hour breach reporting and a real DPO function — not just a policy PDF.
What changed when DPDP became law
Healthcare data was already special before DPDP — it was just unprotected by anything more than a few policy documents. DPDP turns the policy into law. A hospital is now a 'data fiduciary' for the personal data it holds. That means specific, demonstrable obligations around what consent looks like, where the data lives, who can see it, what happens if it leaks, and how long it can be retained. For most Indian hospitals, the gap between current state and DPDP-ready is twelve to eighteen months of work — most of it in the EMR, some of it in policy, none of it optional.
Consent — the bit hospitals get wrong
A single 'I agree to the hospital's policies' tick on registration is no longer enough. DPDP consent must be specific, informed, free, unambiguous, and revocable. In practice that means consent should be decomposed by purpose — treatment, insurance, marketing, research, family-member access — and each one captured separately. A patient can revoke any one of those without revoking the rest, and the EMR has to honour the revocation immediately. Most current consent flows fail one or more of those tests.
Data residency: India-only is no longer optional
- All personal data of Indian patients must be stored on infrastructure located in India. Backups must also be in India.
- Cross-border transfer — even for backup or analytics — requires explicit consent and government notification.
- Logs, error traces and analytics events count as personal data if they contain patient identifiers. They cannot leak to overseas SaaS tools.
- This rules out most US-hosted analytics, error-tracking and CRM tools unless they have a verified India region.
Breach reporting in 72 hours
A 'personal data breach' is any unauthorised access, disclosure, alteration or loss. Once you become aware of one, the Data Protection Board must be notified within 72 hours, and so must each affected individual. To make that deadline you need to know — fast — which records were touched, who touched them, and what data was exposed. That's not a manual investigation. That's an audit log designed for the question.
The DPO function — who, what, how often
Significant data fiduciaries — a category most hospitals chains will fall into — must appoint a Data Protection Officer. The DPO is not a part-time IT manager wearing a hat. They are the named person the regulator and the patient can contact, they sit independently from IT operations, and they conduct periodic audits. Hospitals smaller than the threshold should still designate a DPO function even if they don't appoint a named DPO — the obligations apply, only the named role doesn't.
DPDP-ready EMR checklist
- Decomposed consent capture with revoke flow.
- India-only storage with documented infrastructure (cloud region, backup region).
- Row-level access enforced at the database, not just the UI.
- Audit log answering 'what records did user X view between dates A and B' in under a minute.
- Patient-facing data export — a patient can request and receive their full record digitally.
- Patient-facing deletion request workflow with retention-exception logging.
- Breach detection — anomaly alerts on bulk reads, after-hours access, or non-clinical roles touching clinical data.
What MyEMR does for you
MyEMR is India-hosted by default; the database has row-level security policies; the audit log is append-only and queryable by user, by record, by date; consent is captured by purpose; patient export is a single API call. We don't make compliance decisions for the hospital — that's between the hospital and its DPO. But the platform shouldn't be the bottleneck, and these features mean it isn't.