DPDP for healthcare
Patient personal data sits at the highest sensitivity end of the DPDP scale. On top of DPDP, the Ayushman Bharat Digital Mission (ABDM) Health Data Management Policy imposes federated storage, consent-artefact-driven access, and India-only retention. This page maps how the two frameworks land together.
01Who this covers
Every entity processing digital personal data of Indian patients is a Data Fiduciary. That includes:
- Hospitals of any size, from single-doctor clinics to multi-city chains
- Diagnostic labs and pathology chains
- Radiology and imaging centres
- Telemedicine platforms (Practo, 1mg, Apollo 24/7, MFine, Tata 1mg)
- Health insurance companies and standalone health insurers
- Third-party administrators processing claims
- Health-tech SaaS operating hospital information systems (HIS), electronic medical records (EMR), pharmacy management systems, or lab information systems (LIS)
- ABDM ecosystem participants: Health Information Providers (HIPs), Health Information Users (HIUs), Health Facilities under HFR, Health Professionals under HPR
02ABDM already gave you a head start. Don't waste it.
The Health Data Management Policy under the Ayushman Bharat Digital Mission predates the DPDP Rules 2025 by four years. If you have implemented it properly, you are already most of the way to DPDP on the health-data side.
The HDM Policy is built around patient ownership of the record. The patient controls who sees which record and for how long. Under DPDP that maps neatly to the Consent Manager route in Section 6(3) and Rule 4, so the plumbing you already built for ABDM consent artefacts is reusable.
Federated storage is the second principle: records stay with the originating facility, they are not centralised. Every cross-facility fetch is a fresh access event needing a fresh consent artefact. That is stricter than DPDP itself but it makes the DPDP audit story simpler because access is already event-logged.
And the HDM Policy is India-only by design. Health data processed inside the ABDM ecosystem cannot leave India. That is a sectoral localisation layer sitting on top of DPDP Section 16's negative-list default. If you are inside ABDM, Section 16 is quieter for you; if you are outside ABDM, it is not.
03Consent, DPDP and clinical care
Consent under Section 6 of the DPDP Act is not the same as informed consent for treatment. You need both, and you cannot substitute one for the other.
Informed consent for a procedure covers the clinical decision. It does not, without more, cover the processing of the patient's personal data for research, marketing, insurance claims, or third-party sharing. Each processing purpose needs its own DPDP Sec. 6 consent, or a Section 7 legitimate use (medical emergency, court order, employment) that stands on its own.
Section 7(1)(d) allows processing for a medical emergency without consent. Section 7(1)(e) allows processing during a disaster. Beyond these, consent is required.
04What changes for a hospital
Patient consent notice
At registration, present a Rule 3 notice covering processing for treatment, records retention, billing, insurance, research, teaching, marketing. Separate consent for each. English plus any of 22 languages on request.
Sensitive data security
Encryption at rest for EMR, HIS, LIS. Access controls role-tuned (doctor sees, admin sees less, nurse sees the record they are working). Audit trails per record view.
Retention
Medical records retained under IMC regulations (typically 3 years for outpatient, longer for surgery). Layer DPDP erasure trigger on top. Publish the schedule.
Nomination
Patient can nominate a family member to exercise rights on death or incapacity. Update your records to hold nominee attribute. Especially relevant for terminal-care and geriatric wards.
05Research and archival exemptions
Health research is a common processing activity where DPDP consent is difficult to obtain retrospectively.
Section 17(2)(b) allows the Central Government to exempt processing for research, archival or statistical purposes from specific DPDP obligations. Rule 16 (effective 14 May 2027) will set the conditions: anonymisation, purpose limitation to research, publication of findings that do not identify Data Principals, and reasonable safeguards.
Do not treat Rule 16 as blanket permission. Publication-ready research on anonymised data is likely fine. Building a marketing dataset from clinical records under the "research" label is not.
06Breach handling in a health context
A health data breach can trigger the Rs. 250 crore security cap under Sec. 8(5) and the Rs. 200 crore notification cap under Sec. 8(6) simultaneously.
The Board is expected to treat health data as a category deserving of the higher end of each cap. Practical response requires four parallel notifications: to the Board under Rule 7, to CERT-In under the 6-hour Directions, to the affected patients (with clear language explaining what was exposed and remediation), and, if you are ABDM-registered, to the National Health Authority via the ABDM incident channel.
Note: if paediatric records are affected, the Sec. 9 children's data cap of Rs. 200 crore applies additionally.
07Ninety-day healthcare checklist
-
Redesign patient consent at registration
Separate consent per processing purpose. English default, 22 languages on request. Delete pre-ticked boxes.
-
Map every EMR, HIS, LIS access
Who accesses which record for which purpose. Turn this into your Rule 6 access-control baseline.
-
Publish the retention schedule
IMC medical records rules on the sectoral side, DPDP erasure trigger on the DPDP side. Publish on the hospital website.
-
Wire ABDM consent artefacts through your HIS
Every cross-facility record fetch needs a fresh consent artefact. HIS must present the artefact ID in the audit log.
-
Add a nomination field to patient records
Section 14 nomination is a DPDP-specific right. Especially relevant in terminal care and paediatrics.
-
Unified breach playbook
Four notifications from a single incident: Board, CERT-In, patients, ABDM. Practise the timelines.