DPDP Act 2023: what every hospital must do with patient data

The Digital Personal Data Protection Act 2023 is now law. It applies to every hospital that processes digital personal data — which is every hospital with a computer. Understanding the specific sections that actually govern day-to-day hospital operations, rather than treating the Act as one undifferentiated legal requirement, is what separates genuine compliance from a superficial policy document nobody actually follows.

Section 6 requires consent before processing personal data. For hospitals, this means capturing consent at registration with a clear statement of purpose. "We collect your data for treatment, billing and statutory compliance" — documented, timestamped, attributed.

Section 5 requires purpose limitation. Data collected for treatment cannot be repurposed for marketing or research without separate consent. This catches hospitals that share patient lists with pharma companies or use patient data for promotional communications — practices that may have been treated as routine business development in the past, but now carry direct legal exposure under the Act's purpose-limitation requirement specifically.

Sections 12 and 13 give data principals (patients) the right to access their data and request erasure. Hospitals must be able to produce a patient's records on request and process erasure requests — subject to retention obligations under other laws (MTP Act records, NABH documentation requirements, Income Tax Act for financial records).

Section 8 requires breach notification to the Data Protection Board. The audit trail in your ERP supports breach investigation — who accessed what, when, from where — and the completeness of that trail often determines how quickly a hospital can actually characterise a breach's scope when notification becomes necessary.

Section 33 provides for penalties up to ₹250 crore for significant breaches. This is not theoretical; the Board has enforcement powers.

Practical steps: capture consent at registration (not in a Terms & Conditions page nobody reads — at the counter, with purpose stated). Enforce role-based access control. Maintain an audit trail. Build a process for access and erasure requests. Encrypt data at rest and in transit.

OneCity captures consent at patient registration with purpose and timestamp, enforces RBAC by role, maintains a full audit trail and supports the patient portal for access requests. Erasure is processed per Sec 13, with retention obligations surfaced. This means a hospital using OneCity isn't building DPDP compliance as a separate project layered on top of its existing ERP — consent capture, access control, and audit logging are part of the same daily clinical and administrative workflow staff already use, which is exactly the difference between compliance evidence accumulating naturally and a hospital scrambling to reconstruct a defensible record after a complaint or inquiry has already been raised.

What counts as "personal data" and "processing" under the Act matters more than it first appears, since the definitions are deliberately broad. Personal data is any data that identifies an individual, directly or indirectly — a patient's name, of course, but also a UHID number, a phone number, or even a combination of otherwise-anonymous data points that together identify someone. Processing covers any operation performed on that data: collection, storage, use, sharing, or even simply viewing a record counts as processing. This breadth means a hospital's DPDP obligations don't just apply to the "patient database" in the abstract — they apply to every system that touches patient-identifying information, including billing software, a lab results portal, an SMS appointment reminder service, and any third-party vendor a hospital shares data with for any purpose.

Deemed consent under Section 7 is a real, specific exception worth understanding precisely, particularly for hospitals given how often it applies. The Act permits processing without explicit consent in specific circumstances, including for medical emergencies threatening life, and for public health purposes such as disease surveillance and outbreak response. This matters directly for emergency department workflows — a hospital doesn't need to pause and capture explicit consent from an unconscious trauma patient before beginning treatment and the record-keeping that treatment requires, since Section 7's deemed-consent provision covers exactly this situation. This is a narrow, purpose-specific exception, though, not a general licence to skip consent whenever it's inconvenient — it applies to the immediate emergency response, not to subsequent, non-emergency processing of the same patient's data once the immediate threat has passed.

Significant Data Fiduciary classification is a real possibility for larger hospitals and hospital groups specifically, and it carries meaningfully heavier obligations. The government can designate certain data fiduciaries as "Significant," based on factors including the volume and sensitivity of personal data processed, and health data is explicitly sensitive personal data under the Act's framework. A hospital classified as a Significant Data Fiduciary faces additional requirements: appointing a Data Protection Officer based in India, conducting periodic Data Protection Impact Assessments, and undergoing regular independent data audits. A large hospital group processing health data at scale across multiple facilities should treat this classification as a realistic possibility to plan for, not an obscure provision that only applies to giant technology companies.

Children's data carries specific, stricter requirements a paediatric hospital or paediatric department needs to plan for directly. The Act requires verifiable parental or guardian consent before processing a child's personal data, and prohibits tracking, behavioural monitoring, or targeted advertising directed at children entirely. For a hospital, this means a paediatric patient's registration and consent workflow can't simply mirror the adult workflow with a different form label — it needs actual verification that the consenting adult is genuinely the child's parent or legal guardian, not just a checkbox confirming someone claims that role. Hospitals running paediatric OPD or IPD services at meaningful volume should treat this as a distinct workflow requiring its own verification step, not an afterthought bolted onto standard registration.

Cross-border data transfer restrictions matter for any hospital using cloud infrastructure or software vendors that process data outside India. The Act permits transfers to countries not specifically restricted by the central government, but a hospital using international cloud services, telemedicine platforms with offshore processing, or any vendor whose infrastructure sits outside India needs to confirm that country isn't on any restricted list, and should understand where its patient data actually resides physically, not just where the vendor's headquarters happen to be located. This is a genuine, practical due-diligence question to ask any software vendor a hospital is evaluating — "where does the data actually get stored and processed" — rather than assuming a vendor's marketing claim of "cloud-based" implies compliant data residency by default.

The Data Protection Board of India is the enforcement body Section 8's breach notification requirement reports to, and it's worth understanding what the Board actually does beyond receiving notifications. The Board investigates complaints, has the power to conduct inquiries into a data fiduciary's practices, and can impose penalties following its own adjudication process — it functions similarly to how other Indian regulatory bodies operate, with genuine investigative and enforcement authority, not merely an inbox that receives voluntary disclosures. A hospital experiencing a genuine data breach — unauthorised access, a lost device containing patient records, a vendor's security failure exposing hospital data — has a specific, time-bound obligation to notify the Board, and delaying that notification while internally assessing severity is itself a compliance risk independent of the breach's actual scope.

DPDP's own Consent Manager framework is a distinct concept from ABDM's Consent Manager, and the naming similarity causes real confusion worth clearing up directly. The DPDP Act allows for registered Consent Managers — intermediaries patients can use to manage consent across multiple data fiduciaries generally, not specific to health data. Our separate guide to ABDM and ABHA integration covers the health-data-specific Consent Manager that governs data exchange between hospitals under the Ayushman Bharat Digital Mission. A hospital's DPDP compliance obligations — consent capture, purpose limitation, breach notification — apply regardless of whether ABDM-specific data exchange is active, since DPDP is the general data-protection law and ABDM's consent framework is a health-sector-specific mechanism operating within that broader legal requirement, not a substitute for it.

Common compliance mistakes worth naming directly: treating the DPDP consent statement as boilerplate legal text buried in an admission form nobody reads, rather than a clear, specific statement of purpose presented at the actual point of registration. Assuming existing NABH or other regulatory documentation automatically satisfies DPDP's separate consent and access-rights requirements, when in practice these are related but distinct compliance obligations that need their own explicit workflow. Underestimating how broadly "personal data" and "processing" apply, and therefore leaving vendor systems — a billing platform, an SMS reminder service, a third-party lab-results portal — outside the scope of a hospital's DPDP compliance review, when each of these systems independently processes personal data covered by the Act. And treating erasure requests as simple deletion without checking retention obligations under other laws first — a patient's erasure request doesn't override a hospital's separate legal obligation to retain certain records under the NABH documentation standards, the Income Tax Act, or medico-legal record-keeping requirements specifically.

Where DPDP compliance connects to a hospital's broader technology and accreditation picture: NABH accreditation assessors increasingly expect to see genuine data-protection practice as part of quality review, not a separate legal compliance track disconnected from clinical governance. Telemedicine specifically carries its own DPDP overlap worth understanding — our guide to Telemedicine Practice Guidelines covers how remote-consultation data falls under the same DPDP consent and purpose-limitation obligations as any in-person patient record, not a lighter-touch standard because the interaction happened over video. And for hospitals sequencing DPDP compliance work alongside other technology priorities, our guide to realistic ERP implementation timelines covers how to fit data-protection groundwork into a broader rollout plan rather than treating it as an afterthought addressed only once a breach or complaint forces the issue.

A practical readiness check worth running now, rather than waiting for an actual Data Protection Board inquiry to reveal gaps: confirm consent is genuinely captured with a clear purpose statement at every registration point, not just the main OPD desk. Confirm role-based access control actually restricts who can view which records, rather than every staff login having broad access by default regardless of role. Confirm the audit trail captures enough detail — who accessed what record, when, from where — to actually support a breach investigation if one becomes necessary, not just a generic system log. Confirm someone specific owns responding to patient access and erasure requests within a reasonable timeframe, with retention obligations under other laws clearly documented so an erasure request gets handled correctly rather than either blocked entirely or granted without checking those obligations first. And confirm vendor contracts — billing software, SMS services, cloud infrastructure — include data-protection terms consistent with a hospital's own DPDP obligations, since a vendor's mishandling of patient data doesn't relieve the hospital of its own compliance responsibility for that same data.